dot_generator tweaks for tunnels

[caguero]

This patch modifies the way we assign costs in the dot file. In particular, it reduces the cost when two connected tiles are tunnel segments. To maintain backwards compatibility, a new parameter --finals needs to be passed to dot_generator to enable the new behavior.

To run it:

rosrun subt_ign dot_generator /home/caguero/subt_ws/src/subt/subt_ign/worlds/finals_qual.sdf --finals > /home/caguero/subt_ws/src/subt/subt_ign/worlds/finals_qual.dot
catkin_make install

Here are the results of dropping some breadcrumbs along the tunnel section.

Previous behavior:

New behavior:

[acschang]

Before this adjustment:

After this adjustment:

After this adjustment + moving the breadcrumb to intersection in the tunnel sections:

[angelacmaio]

The commsFadingExponent is set lower for Finals and Cave worlds, so comms range in urban segments of Finals worlds appear to be extended compared to the same tiles in an urban world.
Does it make sense to set the commsFadingExponent to 2.5 for all worlds and adjust cost for the cave tiles accordingly?

[caguero]

The commsFadingExponent is set lower for Finals and Cave worlds, so comms range in urban segments of Finals worlds appear to be extended compared to the same tiles in an urban world.
Does it make sense to set the commsFadingExponent to 2.5 for all worlds and adjust cost for the cave tiles accordingly?

@angelacmaio , I was doing some experiments and a value of 1.5 for commsFadingExponent seems to be better tuned for our current comms model. We used 2.5 before the last big comms revision. Your suggestion to unify the parameter across circuits makes a lot of sense. My suggestion is to do what you suggest with 1.5. Our comms model is a bit more restrictive in terms of coverage than the past revision, that's why 1.5 seems better suited. If you give us the thumbs up, I'll push the new commit and it will be ready to review.

[angelacmaio]

@caguero I like the plan of unifying and defer to your recommendation for the value. If you have a couple example results we can see, that would be great. Or if this requires regenerating dots for all worlds, if you make the changes to 1 or 2 worlds per type then we could test a few before expanding to all worlds.

[caguero]

@caguero I like the plan of unifying and defer to your recommendation for the value. If you have a couple example results we can see, that would be great. Or if this requires regenerating dots for all worlds, if you make the changes to 1 or 2 worlds per type then we could test a few before expanding to all worlds.

Side note: A change in the parameters doesn't require to regenerate the dot or dat file. That's only needed when there's a physical change in the layout of the world.

For reference, I'm adding here the results with this new set of parameters for the three simple_tunnel worlds.

simple_tunnel_01 with commsFadingExponent 1.5:

simple_tunnel_02 with commsFadingExponent 1.5:

simple_tunnel_03 with commsFadingExponent 1.5:

For comparison purposes, here's the simple_tunnel_03 again with commsFadingExponent 2.5:

As you can see, a value of 2.5 for these worlds seems a bit richer, however 1.5 it's still OK in my opinion. The reason for not observing the "yellow" and "red" areas is because the Gaussian function that CommsFadingExponent controls is wider when using 1.5. Then, the comms drop because of the visibility mainly. When using 2.5 the Gaussian is narrower and actually covers the distant tiles.

Having said that, this is the behavior in the tunnel circuit dominated by small tiles. In other circuits with bigger tiles, 1.5 behaves better because 2.5 causes the comms to drop very close to the message sender. That's the reason for me to recommend 1.5 because in the worst case scenario we can still communicate.

Out of curiosity I also tested a value of CommsFadingExponent 2.5 in the finals and reduced the visibility cost of the tiles. However it wasn't enough and I still saw many communication holes. I recommend this approach to also minimize the number of further changes reducing risk.

[acschang]

Here's what the updated values look like in Tunnel and Urban simple environments 1-3

Tunnel:

Urban:

Note: The lack of communication range with the placement of the last two breadcrumbs is a little surprising but not unreasonable considering the range of the overall chain.


Note: The red colored tile in the bottom right corner is a visual bug. I manually inspected the communication in this tile and found the throughput to be similar to that of the tiles above and below.

I think the updated comms look promising with significant drop-off around corners when line-of-sight is lost.