ForceTorque system: write WrenchMeasured to ECM

[scpeters]

🎉 New feature

Part of #2268 and #2391, requires gazebosim/gz-sensors#449 and targets the branch for #2487

Summary

This adds a new WrenchMeasured component and writes to it on the force-torque sensor entities in the ECM. The ForceTorque sensor configuration is changed to call sensor updates even when the gz-transport topic has no subscribers, so that the latest wrench data will be in the ECM. This also adds Model::ModelCount and Model::ModelByName APIs to gz/sim/Model.hh to support the new test.

Test it

Build from source and run ctest -R INTEGRATION_force_torque_system

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.

[scpeters]

gazebosim/gz-sensors#449 has been merged and nightlies rebuilt, rerunning CI now

[iche033]

does it make sense for users to indicate that they want data to be written to ECM by creating a components::WrenchMeasured component? here we would just check for the presence of that component, e.g.

    if (sensor->NextDataUpdateTime() <= _info.simTime &&
        (sensor->HasConnections() ||
        _ecm.Component<components::WrenchMeasured>(sensorEntity) != nullptr))

Probably not going to make much perf difference for this system since the sensor Update call should be relatively fast and same for writing force torque values to ECM. It would be nice to keep things consistent if we do decide to port this functionality to other sensors, e.g. contact or rendering sensors

[scpeters]

ooh, I like that. Let me give that a try

[scpeters]

c6fedb1

[scpeters]

I noticed a python test failing in #2500 and realized I didn't set priority on its test file, so I've done so in ba5408f

I'm guessing it will fail, since the python test implicitly assumes that its on_pre_update_cb will execute after the ForceTorque::PreUpdate, but that is now changed. I think the python test should be updated to account for this ordering, which shouldn't be too hard

[scpeters]

I noticed a python test failing in #2500 and realized I didn't set priority on its test file, so I've done so in ba5408f

I'm guessing it will fail, since the python test implicitly assumes that its on_pre_update_cb will execute after the ForceTorque::PreUpdate, but that is now changed. I think the python test should be updated to account for this ordering, which shouldn't be too hard

the test should be fixed by 1f76c6a, though it's hard for me to run these tests on my machine, so I'll wait for CI to confirm

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 66.07%. Comparing base (098085b) to head (9a7785e).
Report is 75 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2494      +/-   ##
==========================================
+ Coverage   65.95%   66.07%   +0.12%     
==========================================
  Files         327      329       +2     
  Lines       31319    31801     +482     
==========================================
+ Hits        20655    21012     +357     
- Misses      10664    10789     +125     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iche033]

looks good to me.

I noticed some windows tests were failing. I think they are flaky as I've seen a couple of them fail before. I just triggered another build to double check.