Allow using the actual torques as joint efforts

[urfeex]

Add the option to use the joint_torques reported through RTDE as joint efforts as discussed in #1468.

This will not run on robots with software version < 5.23.0 / 10.11.0, hence the draft. The RTDE output for actual joints doesn't exist before. We would need to find a solution for that. Possible solutions are:

• Keep a separate output recipe and leave passing a compatible recipe file when this option is enabled to the user (I don't quite like that)
• read the recipe file in the driver, append the torque field if requested and save it as a temporary file that gets passed to the driver object
• Extend the driver config to accept a string vector, as well. Then, we can easily append the field in the hardware interface

[codecov]

Codecov Report

❌ Patch coverage is 0% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 4.71%. Comparing base (1b121b7) to head (2d6cbeb).
⚠️ Report is 607 commits behind head on main.

Files with missing lines	Patch %	Lines
ur_robot_driver/src/hardware_interface.cpp	0.00%	18 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##            main   #1551      +/-   ##
========================================
+ Coverage   3.59%   4.71%   +1.12%     
========================================
  Files         13      35      +22     
  Lines        947    4517    +3570     
  Branches     152     535     +383     
========================================
+ Hits          34     213     +179     
- Misses       843    4299    +3456     
+ Partials      70       5      -65     

Flag	Coverage Δ
unittests	4.71% <0.00%> (+1.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ndunkelb-nasa]

Hi @urfeex , is there any intention to get this merged in the near future? As we are thinking about sim2real implementation, it makes it hard to compare between simulation and hardware. We get most of the information we need time synchronized from /joint_states, but having the effort be incorrect according to the sensor_msgs definition adds an extra layer of annoyance. We can of course strap something together from existing tools, like the RTDE publisher, or building this from source, but just figured I would see the status of this MR bc it is already out there.

[urfeex]

This just hasn't been a priority since I drafted out the concept for this. This is basically the case, since there seemingly was no interest in having this available. But I think, I should be able to get this to a mergeable state pretty quickly.

• read the recipe file in the driver, append the torque field if requested and save it as a temporary file that gets passed to the driver object
• Extend the driver config to accept a string vector, as well. Then, we can easily append the field in the hardware interface

We can actually make a combination of both. Since reading the recipe file to a string vector is actually a static method, we can read it in the hardware interface, append the field if possible and then setup the UrDriver object with that vector.

[ndunkelb-nasa]

That would be great! It seems like this change shouldn't negatively affect anything, so it would be awesome to have as an option! Thanks for taking a look!

[urfeex]

I think the state that it currently is in should be mergeable. This PR needs some polishing, especially on the documentation side, though.

We will be branching out for lyrical pretty soon (before merging #1808), then we can also make this the default on Rolling from that point on.