fzi-forschungszentrum-informatik / cartesian_controllers

A set of Cartesian controllers for the ROS1 and ROS2-control framework.
BSD 3-Clause "New" or "Revised" License
397 stars 119 forks source link

Recommendation for frequency of publishing messages for teleoperation in compliance mode #193

Closed shrutichakraborty closed 5 months ago

shrutichakraborty commented 7 months ago

Hi authours, I am using the cartesian compliance controller with UR10e on Ubuntu 20.04 ROS1 noetic, and teleoperating the robot by publishing pose_stamped messages to the controller. I am using a custom device for the teleoperation and I would like to know what is the recommended frequency at which I should be publishing messages to the controller for a smooth teleoperation?

From my tests, I was first calculating the displacement of my teleop device, incrementing robot position and orientation and then publishing it as soon as the calculations are done. This resulted in the robot not moving at all. I suspect this was because there was an overflow of commands published and the robot did not move. I then tested the same by adding a random 1 second sleep and now the robot was reacting but with some latency. Therefore, it would be great to know what kind of frequency you recommend from your teleoperation tests.

Thanks!

shrutichakraborty commented 7 months ago

Hi authours, I am using the cartesian compliance controller with UR10e on Ubuntu 20.04 ROS1 noetic, and teleoperating the robot by publishing pose_stamped messages to the controller. I am using a custom device for the teleoperation and I would like to know what is the recommended frequency at which I should be publishing messages to the controller for a smooth teleoperation?

From my tests, I was first calculating the displacement of my teleop device, incrementing robot position and orientation and then publishing it as soon as the calculations are done. This resulted in the robot not moving at all. I suspect this was because there was an overflow of commands published and the robot did not move. I then tested the same by adding a random 1 second sleep and now the robot was reacting but with some latency. Therefore, it would be great to know what kind of frequency you recommend from your teleoperation tests.

Thanks!

If anyone has had any feedback on this issue it would be great.

I have done many tests with different frequencies of publishing between 10 to 30 Hz, and the robot is not reactive at all. I have tried the space mouse example and the spacenav_to_pose example, which works well. The space_nav twist messag is published at 30 Hz and the /target_frame seems to be published at 100 Hz. I am using a similar publisher to the one in the utilities of this repository that converts twist to pose, but in my case I calculate the dispacements to the robot pose and publish those directly to /target_frame.

stefanscherzinger commented 6 months ago

Hi @shrutichakraborty

I have tried the space mouse example and the spacenav_to_pose example, which works well.

Alright, this shows that your setup is working, and that the robot is connected correctly. I have an idea what could be the problem in your case. If you calculate the displacement to the robot pose and publish that delta to steer the robot, the robot might not move fast enough and so that the small delta has no real effect. That's a closed loop approach. You could make it open loop and publish the target_frame no matter what the robot does. This is what happens in the spacenav_to_pose example.

Regarding your first question, all controllers interpolate for you and work with any publishing frequency. Details are explained here. If you want to publish displacements to the current robot pose, I suggest you increase the error_scale and iterations parameter. The edge case would be a reactive controller that directly jumps to each target_frame, as if it was a pure inverse kinematics solver. For this configuration, however, you need to publish with a sufficiently high frequency (~100 Hz) or you might observe jerky motion.

stefanscherzinger commented 5 months ago

Please reopen if still unclear.