Acoustic comms plugin

[adityapande-1995]

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

🎉 New feature

Summary

This plugin adds a simple acoustic comms plugin to gz-sim.

Test it

Added a small test case which contains 2 pairs of boxes which communicate with each other. One set in inside the max range of comms, and the other is outside it. The one outside the range should not receive any messages.

TODO

• The current calculation for distanceToTransmitter considers the current distance between the 2 bodies, when actually it should be the distance between current receiver position and position of the sender at the time at which the packet was sent, as the sender might be moving. This is not a big problem if the 2 bodies are at rest or moving slowly compared to speed of sound.

Since the packet does not contain a field related to position of sender at the time the packet was sent, I;m not sure how to implement this.

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

[codecov]

Codecov Report

Merging #1608 (96e9bea) into main (9d24893) will increase coverage by 0.06%.
The diff coverage is 94.64%.

❗ Current head 96e9bea differs from pull request most recent head 6aceed4. Consider uploading reports for the commit 6aceed4 to get more accurate results

@@            Coverage Diff             @@
##             main    #1608      +/-   ##
==========================================
+ Coverage   63.57%   63.63%   +0.06%     
==========================================
  Files         330      331       +1     
  Lines       25926    25981      +55     
==========================================
+ Hits        16482    16534      +52     
- Misses       9444     9447       +3     

Impacted Files	Coverage Δ
src/systems/acoustic_comms/AcousticComms.cc	94.64% <94.64%> (ø)
src/EntityComponentManager.cc	90.86% <0.00%> (-0.02%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[caguero]

At a high level, the code looks good to me and I like the strategy for deciding when to keep the message, drop it or deliver it.

My only suggestion is to try to remove the need for the transmitter to populate the message with its own pose. I think it would be way more elegant if that's something that the plugin can do automatically for us. We have access to the ECM and the entity ID of the sender, so it should be possible.

[adityapande-1995]

As per offline discussion with @caguero , we decided that making the users specify the position of the sender in the header file is cumbersome. Instead, what I have now is : The plugin will keep track the position of sender when a msg is first processed, and use that for distance calculations throughout the life of the message.

This means the difference between actual position of the sender (when the msg was sent) and the one we use will only differ by one spin cycle of the plugin, which is still good.

[caguero]

I think there's a situation that isn't covered here: If source and destination are initially at a distance > maxRange but the destination is moving closer to the sender (in the direction of the message). If I'm not wrong, you'll discard the message instantly but you're not accounting that potentially the destination might be within range eventually while the message is traveling.

[adityapande-1995]

I am actually, distanceToTransmitter is the distance between :

• Position of sender when the message was sent, (this is constant throughout the lifetime of the message)
• Current position of the destination. This is when the plugin is spinning, so always contains the current position of destination. So even if the destination has just moved towards the source, that distance should be reflected accurately.

I could add a test for this situation if needed.

[caguero]

You're right, the key is to use distanceCoveredByMessage to decide when to drop the message and not distanceToTransmitter as I originally thought you were using.

[chapulina]

Removed the Garden label because we're past feature freeze ❄️ .

This PR can either be merged into main and backported to gz-sim7 after the stable release, or retargeted to gz-sim7 and merged after the stable release (i.e. October).

[adityapande-1995]

@osrf-jenkins retest this please

[adityapande-1995]

I don't think the failures in CI are related to the changes made here.

[hidmic]

LGTM barring minor comments