Hello,
We’ve been using two UR10e robots with the Universal Robots ROS Driver to realize some compliance control experiments using cartesian controllers. One of them is ceiling-mounted and the other is wall-mounted.
We’ve been trying to understand the behavior of the F/T Sensor. Here are a few issues I would like to ask about:
I’ve been running the external_control URCaps use it with ROS, whilst recording the FT Sensor data over a topic without starting any ros controllers. Were using Polycope 5.9.
1. Drift:
I recorded readings of both the FT sensors on the robots mainting the robots in a fixed pose (with the flange facing downwards) with a known payload mounted (setting appropriately the TCP, COM, and Payload mass). At the beginning, the FT sensor values start from zero, but over time, it seems to keep increasing. I observed this behaviour on both the robots:
In the picture above, note that the “zeroing” that happens after the first and the second increase (saw-tooth like form) also happened automatically. I didn’t stop or restart the program. This automatic “zeroing” also seems unpredictable, I repeated the tests for similar long durations, but this zeroing did not happen in all of them. For instance, I repeated this experiment another day with no payload, in the same configuration as in the previous experiment and these are the results:
I’ve also repeated the test without having any payload attached, and the drifts were even larger than expected (it sloped up, going up to 25 N, which I think is a lot). Again both FT sensors seemed to exhibit somewhat similar behaviour
2. Changing Force values for wrist_3_joint rotation:
In this test, the robot kept a certain pose, but only wrist_3 joint was rotated by 45 degree increments and mainted the new position for a few seconds. During this time there seems to be a change in the force sensor readings as seen below:
3. Shift in the baseline post interaction
Other common phenomenon I’ve observed is that after interaction, the reading don’t return right away to the range of force values prior to interaction. My wild guess is hysterisis. Could someone confirm it for me?
Which brings me to the main question. Is there anyway all this can be remedied? I initially thought, it was something wrong with the admittance control algorithm, however, running the algorithm in a Gazebo simulation (with a simulated force/torque sensor) it seemed to work alright.
I’ve come across [this] (Universal_Robots_ROS_Driver/ur_robot_driver/doc/ROS_INTERFACE.md at master · UniversalRobots/Universal_Robots_ROS_Driver · GitHub), but I don’t think it’s of much help when using external_control?
For now, we’ve been limiting our experiments for a short time-span, during which the drift is minimal. However, we need to do more elaborate experiments involving more time which I am afraid won’t be feasible if this isn;t figured out.
So any suggestions, insights would be really helpful; and appreciated.
Thank you