Model submission for Trailer sensor config 1 by CTU-CRAS-Norlab

[peci1]

This PR adds a passive vehicle that carries a large comms node and can be dragged behind a UGV the same way car trailers do.

To get a better reward than being a large breadcrumb, I added an exception to subt comms broker for this robot. If (and only if) it is within 100 m from teambase, it uses a communication "side channel" that is not limited by bandwidth and that has almost no packet loss. When it leaves the 100 m radius, it uses standard subt comms model. This exception tries to mimick a 100 m-long 2-wire connection with the teambase.

The exception from comms broker is acknowledged based on the names of communicating endpoints and their distance. Teambase has to be named TEAMBASE and the trailer has to be named COMMS_EXTENDER. See the README.md of the commited package for instructions on how to test this.

I'm open to discussing how to best implement the exception in comms broker. What you see is the simplest option I came up with, but it e.g. allows any type of robot to utilize this property if it is named correctly.

The trailer is added as a possible marsupial child to many CTU-CRAS-Norlab UGVs. Opposite to UAVs, the best attachment point for the trailer is on the rear of the robot and not on its top. "Fortunately", none of our robots were allowed to carry children, so I specified the marsupial attachment point on their rear. But maybe (maybe?) we will want to also make MARV able to carry a UAV. Then it would need some more clever logic in the spawn script. But so far I leave it as it is.

[peci1]

[peci1]

I downgraded model.sdf to SDF version 1.6 as requested for all our models.

[angelacmaio]

We recognize the value of having a virtual representation of a communications tether, but there are some issues with the implementation as modeled in this PR.

• As you mentioned, robots assigned the names COMMS_EXTENDER and TEAMBASE would achieve 100m communication range. This reduces reconfigurability and could be exploited by assigning two movable robots these names.
• The Euclidean distance implementation is not restricted by a cable going around turns. A robot could travel loops (<100m from staging) infinitely and never lose communication.

This model will not be incorporated for the Virtual Competition, but we appreciate the effort to create a virtual analog for the detachable communications tether. In case other groups find it valuable to test with outside of competition, we would recommend uploading this model to Ignition Fuel (see instructions here) and linking to your forked repository in the model description.

[peci1]

@angelacmaio that's a pity... the implementation in this PR has been open for discussion. I'm ready to reimplement it in some safer ways. I just wanted your hints in what direction you would like the implementation to go as there are multiple ways. The rope could maybe be better simulated utilizing the precomputed communication distance map, but I didn't know how...

[angelacmaio]

Reopening this PR for consideration, especially if implementation changes can be recommended to improve realism.
cc: @nkoenig @caguero

[peci1]

One idea I had was to utilize the precomputed distance maps used for the comms model. But I don't know how to access them from the model.

[caguero]

Interesting idea @peci1 . I agree with @angelacmaio on the main two limitations. Below are some extra comments:

• About the naming: One idea could be to check if the name contains _EXTENDER. This could potentially allow multiple vehicles to be tethered. Although I'm not a huge fan of implementing behaviors based on naming, I recognize that this path might be easier to implement.
• About the Euclidean distance: Our comms model doesn't precompute distance, it precomputes a "visibility cost" that we artificially create based on the shapes of the tiles. I think this is far from trivial but one idea could be to modify VisibilityTable::PopulateVisibilityInfo() to include the path to be traversed from a source tile to a source destination. Then, knowing the list of tiles that the message traverses, you'll need a way to know the distance traveled for each tile. We could use bounding boxes to approximate that and precompute it, or we could manually add that information to the .dot files.