stefanscherzinger
commented
2 months ago @shrutichakraborty
Thanks for investing your time in this! You are right, what you experience is the difference between closed loop control and open loop control. See my explanation to your previous question. And yes, closed loop only works if the robot is fast enough in tracking the target_frame. Tweak that behavior as desired.
You are also right that teleoperation should involve some sort of closed loop control. In many use cases, the human teleoperator does that implicitly, checking e.g. with visual feedback their control commands. For your mentioned reasons, I personally prefer to teleoperate my robots with the cartesian_force_controller. This is more intuitive and there's no delay. The robot stops when I stop. The example from the cartesian_controller_utilities package is here (ROS2).
shrutichakraborty
Hello! I had previously raised some concerns about recommended frequency for teleoperation #193, but upon further testing with the provided scripts I have noticed something quite strange :
In the
pose.pyscript that serves to republish twist messages from space mouse as pose stamped messages, the startup function initialises the starting pose of the robot and initialises theself.posandself.rotas follows :Throughout the teleoperation, the
self.posandself.rotvalues are updated, however the current real pose of the robot is not kept track of, therefore after a few time cycles we may not be properly synchronised with the robot.I reused this code to write a different test code that publishes pose stamped messages to the robot (to simulate having a teleop device that directly communicates pose information). In this test, I treid two approaches :
First method: I have a subscriber that subscribes to the
current_posetopic and I update the pose with a constant delta and publish this to the robot. I do not make any change to the orientation, and so it will stay the same as the initial orientation.In this test, the robot does not move. I tried delta values between 0.0009 to 0.05. I added a sleep of 1 second at the end as well, for a reasonably high delta (0.05 for instance) the robot move for a few mm, then stops moving.
2nd test : Comparatively, if I use exactly the code in
pose.pyand instead of resetting self.pos to current robot pose incremented by delta, then the robot moves as expected:So, I am wondering: why does the first method not work? Is it due to the fact that we are receiving and publishing at a high frequency, and if we republish the current position + increment, the robot fails to move to this position if the increment is quite small?
For the second method, this works but for teleoperation it is always better to have an idea of the current pose of the robot . For instance, if we make increments based on the initial pose of the robot, then after a few time cycles, isn't there a risk of loss of synchronisation between the real current pose of the robot and the theoretical one we update? For instance with the space mouse, teh robot doesn't immediately stop when no commands are sent, it sort of glides. Here are some numerical values from the test :
But something very strange is that there is a static error of about 35 cm between the real robot position and the theoretical one before the robot starts to move which seem really strange but I have noticed this in several tests..
Are there any suggestions from the team or anyone else who has tried teleoperation with these controllers? @stefanscherzinger
Thank you