Added missing RTDE data packages and fixed incorrect names

[remi-siffert-ocado]

Updated the list of RTDE data packages for consistency with https://www.universal-robots.com/articles/ur/interface-communication/real-time-data-exchange-rtde-guide/.

Tested with URSim running Polyscope 5.17.2 with the following RTDE output recipe:

timestamp
target_q
target_qd
target_qdd
target_current
target_moment
actual_q
actual_qd
actual_current
actual_current_window
joint_control_output
actual_TCP_pose
actual_TCP_speed
actual_TCP_force
target_TCP_pose
target_TCP_speed
actual_digital_input_bits
joint_temperatures
actual_execution_time
robot_mode
joint_mode
safety_mode
safety_status
actual_tool_accelerometer
speed_scaling
target_speed_fraction
actual_momentum
actual_main_voltage
actual_robot_voltage
actual_robot_current
actual_joint_voltage
actual_digital_output_bits
runtime_state
elbow_position
elbow_velocity
robot_status_bits
safety_status_bits
analog_io_types
standard_analog_input0
standard_analog_input1
standard_analog_output0
standard_analog_output1
io_current
euromap67_input_bits
euromap67_output_bits
euromap67_24V_voltage
euromap67_24V_current
tool_mode
tool_analog_input_types
tool_analog_input0
tool_analog_input1
tool_output_voltage
tool_output_current
tool_temperature
tcp_force_scalar
tool_output_mode
tool_digital_output0_mode
tool_digital_output1_mode
payload
payload_cog
payload_inertia
script_control_line
ft_raw_wrench
joint_position_deviation_ratio
collision_detection_ratio
time_scale_source

I have not updated the test_ur_driver to use this new output recipe but I'd be happy to if you think it's useful.

[remi-siffert-ocado]

I am a bit confused with tool_digital_output_mask. It's not mentioned in https://www.universal-robots.com/articles/ur/interface-communication/real-time-data-exchange-rtde-guide/ but seems required for the tests to pass.
Does the documentation need to be updated?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.68%. Comparing base (d21a402) to head (bb45713).
Report is 26 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #213      +/-   ##
==========================================
- Coverage   72.05%   71.68%   -0.38%     
==========================================
  Files          71       71              
  Lines        2652     2649       -3     
  Branches      337      337              
==========================================
- Hits         1911     1899      -12     
- Misses        555      566      +11     
+ Partials      186      184       -2     

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

[fmauch]

Thank you for providing this. Indeed I think we never touched this since we initially created it from the interface back then. I'll double-check things but it seems to look fine on a first glance.

I am a bit confused with tool_digital_output_mask. It's not mentioned in https://www.universal-robots.com/articles/ur/interface-communication/real-time-data-exchange-rtde-guide/ but seems required for the tests to pass. Does the documentation need to be updated?

I do understand your confusion, but it isn't only used inside the tests, we also use it inside the ROS drivers to set digital outputs. @urrsk we probably discussed this a couple of years ago, but I agree: Is that missing in the docs?

[fmauch]

This seems to be in line with the upstream documentation. Thank you @remi-siffert-ocado

[fmauch]

I have not updated the test_ur_driver to use this new output recipe but I'd be happy to if you think it's useful.

I think it would indeed be beneficial to have a test trying to claim all the possible RTDE fields to ensure they all actually exist. If you could find the time to provide such a test, that would be awesome! Note though, that this test will have to assemble the recipe based on the robot software version. We currently run the minimum required version in CI but it would be nice to add other entries, at least for the latest version, as well.

It might be beneficial to actually put that into a separate test, I think.

@remi-siffert-ocado please let me know whether you would like to implement such a test and if you would like to this as a part of this PR or a separate one.

[remi-siffert-ocado]

@fmauch Sure I can give a shot at writing the test you suggest for this PR.
I am not sure how easy it is to customize the test based on the robot software version but I'll look into it.

[fmauch]

@fmauch Sure I can give a shot at writing the test you suggest for this PR. I am not sure how easy it is to customize the test based on the robot software version but I'll look into it.

In the test itself it is possible to get the robot software version directly from the RTDEClient. You probably would have to setup the test with a small recipe to initialize the communication and then reset the client with the assembled version-sensitive recipe.

To actually run the tests with the respective versions in CI, we would only need to modify the build matrix that I linked earlier.

[remi-siffert-ocado]

Added a test as suggested @fmauch. Let me know how this looks, thanks!

[fmauch]

This is looking great! What I don't like is that we effectively have two lists of field names. Maybe we can merge the version information into the g_type_list?

Please tell me, if you think, I am starting feature-creeping ;-) We can always move tasks to follow-up PRs.

[fmauch]

Thank you @remi-siffert-ocado for this great addition!

[urrsk]

@remi-siffert-ocado Thanks for the help