Avoiding mismatches in robot model between drivers and actual robot

thettasch commented 1 year ago

Context

I am controlling a simulated robot from ROS2 and found there was a significant mismatch (in the order of centimetres) between the cartesian position of the tcp on the simulated teach pendant compared to the output from tf2.

I went down a whole rabbit hole trying to fix the issue, including ensuring that there were no tcp offsets, that I was using the correct tf frames, etc.; however this only caused more confusion.

I am using the docker image of UR Sim and the UR ROS2 driver binaries to control the simulated robot. I ran the following commands to start the simulator and drivers:

docker run --rm -it -e ROBOT_MODEL=UR10e universalrobots/ursim_e-series

ros2 launch ur_robot_driver ur10e.launch.py robot_ip:=172.17.0.2

What I was doing wrong

The issue turned out to be a mismatch in robot model between the simulator and ROS. I was passing ROBOT_MODEL=UR10e to ur sim, however this caused it to default to using a UR5, since the parameter should not include the trailing "e". Neither UR Sim nor the ROS2 drivers gave any warning or indication of the mismatch in robot model.

What could be added to prevent this issue in future

It may be worthwhile to look into adding some checks into the drivers to ensure that the loaded URDF model of the robot actually matches the robot that the drivers are connecting to. This would avoid user error such as mine and could protect from more dangerous situations where a real robot is controlled with completely incorrect kinematics.

I talked to @gavanderhoorn while looking into the issue and he may be able to also give some input with regards to potential improvements to the drivers in this regard.

fmauch commented 1 year ago

Thank you for your feedback. Just to ensure: You did see the big fat warning during startup?

 [ERROR] [1697532375.479429100] [URPositionHardwareInterface]: The calibration parameters of the connected robot 
don't match the ones from the given kinematics config file. Please be aware that this can lead to critical inaccuracies of 
tcp positions. Use the ur_calibration tool to extract the correct calibration from the robot and pass that into the 
description. See
[https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/blob/main/ur_calibration/README.md] for details.

What would be your suggestion to handle this differently? What kind of behavior would you expect?

The ideas I currently come up with:

We could exit the driver if the calibration sum mismatches. However, this would force everybody to actually calibrate their robots before "trying out things" (as we actually suggest in the docs). I'm not totally against this but I believe this would be seen as a barrier for getting started by some users.
We could add a check for the actual robot model. But then our description would also have to be aware of the robot model.
We could calculate the distance between the forward kinematics and the tcp pose reported by the robot controller. However, the lowest required threshold with this could also be close to possible deviations due to an uncalibrated model (think about the difference between a ur3 and a ur3e, I don't know the actual difference by heart tbh.

thettasch commented 1 year ago

Thank you for your reply.

I missed the warning because it was not being colourised and got buried between other ur_ros2_control_node info messages (setting RCUTILS_COLORIZED_OUTPUT=1 fixed this). However, since the warning is about calibration and not robot model, I'm not sure I would have immediately realised that this was the problem.

I agree that there are cases where it may be useful to be able to test a robot with the default calibration files, however there is a significant difference between a slight calibration mismatch (a few millimetres at the TCP) and a mismatch in robot model (potentially many centimetres at the TCP). As such I think your second bullet point may be most applicable, which is to check that the robot model matches (and keep the warning behaviour for when the calibration is mismatched).

As for the exact implementation I am uncertain of the best path forward, however the xacro macros for generating the robot description urdfs are already aware of the robot type, so it should be possible to add that into the urdf without too much difficulty.

fmauch commented 7 months ago

I'll add an enhancement label to that but we currently do not prioritize implementing that.

UniversalRobots / Universal_Robots_ROS2_Driver