[JTC] Setting start_with_holding to false has no effect (ROS2 version: iron)

[HPCLOL]

For some reason, I hope that my robot‘s joints will not start by holding position, but naturally move under the influence of gravity. Therefore, I set start_with_holding to false. But unfortunately I found that it didn't work, my joints still remained in the fixed position at the beginning. What can I do so that it doesn't start with holding position?
It is worth mentioning that the command interface I used is position, and when I changed the command interface to velocity or effort, the joints did not hold position at the beginning, that is what I want when I use position command interface.
Thank you very much!

[saikishor]

Hello!

Thanks for pointing out the issue. We are currently planning to remove this option in the upcoming releases. As per the discussion ([JTC] Need for start_with_holding option?), we agreed that a controller has to send commands upon activation, as you can always place your robot in a different configuration and then start the JTC to start controlling. I think it is a bad idea for the controller to have the position command interfaces and not send references, as in reality you can move the robot freely.

Please feel free to share your thoughts.

[christophfroehlich]

Are you using gazebo/gz or a custom hardware_component for your real robot? Currently, it should work (from the controlles perspective) also with position interface. But I agree with sai about questioning if this scenario should be supported at all.

[HPCLOL]

Are you using gazebo/gz or a custom hardware_component for your real robot? Currently, it should work (from the controlles perspective) also with position interface. But I agree with sai about questioning if this scenario should be supported at all.

Thank you for your reply! I using gazebo to simulate the robot.
Just now, I tried not to activate JTC when starting Gazebo, but to activate it later when I need to control it. When I haven't activated JTC, the joint moves naturally under the influence of gravity, but when I activate it after a few seconds, the joint suddenly jumpes from the current position to the starting position without any trajectory.

[christophfroehlich]

gazebo classic or gazebo (gazebo_ros2_control or gz_ros2_control)?

That is a strange behavior. The start position is taken at the time of activation, and should not jump to the position at the time of configuration.

If I understand, your problem is that it jumps at time of activation, not in general that it commands the robot at time of activation? So there is no need for start_with_holding = false (#839 got merged recently, and will be backported to iron) but maybe there is a bug in combination with gz/gazebo_ros2_control. I try to investigate your behavior.

Note: Be aware that position interface (at least in gazebo classic, modern gazebo will be similar) directly sets the position of the robot, there is no "dynamics" then between the command and the actual position.

[HPCLOL]

gazebo classic or gazebo (gazebo_ros2_control or gz_ros2_control)?

That is a strange behavior. The start position is taken at the time of activation, and should not jump to the position at the time of configuration.

If I understand, your problem is that it jumps at time of activation, not in general that it commands the robot at time of activation? So there is no need for start_with_holding = false (#839 got merged recently, and will be backported to iron) but maybe there is a bug in combination with gz/gazebo_ros2_control. I try to investigate your behavior.

Note: Be aware that position interface (at least in gazebo classic, modern gazebo will be similar) directly sets the position of the robot, there is no "dynamics" then between the command and the actual position.

Thank you for your reply! I use gazebo(ros2 _control) to control my robot.

I think your understanding may be correct. In fact, my request is to not let JTC have any influence on the position of joint when loading it, until I send it a position command.

The reason why I activated JTC later in my previous comment was I wanted to try a different way to control the robot after it reaches stability under the influence of gravity (Because I currently cannot achieve it by setting start_with_holding to false).

In other words, my robot needs to first reach a stable state under the influence of gravity, and then control it through JTC. Instead of letting JTC take effect from the beginning.

I don't know if you can understand what I mean. Forgive me for my poor expression skills. Thank you very much.

[christophfroehlich]

It's ok to activate JTC later, but the jump should not happen. I had a quick look, but was not able to reproduce it yet.

[HPCLOL]

It's ok to activate JTC later, but the jump should not happen. I had a quick look, but was not able to reproduce it yet.

Thank you, I will try to solve this problem again.

[HPCLOL]

gazebo classic or gazebo (gazebo_ros2_control or gz_ros2_control)?

That is a strange behavior. The start position is taken at the time of activation, and should not jump to the position at the time of configuration.

If I understand, your problem is that it jumps at time of activation, not in general that it commands the robot at time of activation? So there is no need for start_with_holding = false (#839 got merged recently, and will be backported to iron) but maybe there is a bug in combination with gz/gazebo_ros2_control. I try to investigate your behavior.

Note: Be aware that position interface (at least in gazebo classic, modern gazebo will be similar) directly sets the position of the robot, there is no "dynamics" then between the command and the actual position.

I'm sorry that I made a mistake in my previous comment. I use gazebo classic(gazebo_ros2_control) to simulate the robot.

[christophfroehlich]

I think I was able to reproduce it now: This is a "feature" of gazebo_ros2_control

• If you activate a controller using position commands, the perform_command_mode_switch method is called, the control method bit for position is set, and in the next call of the write method the command variable is sent. This one is initialized with 0 if not configured with an initial value in the ros2_control tag. As a consequence, it might happen at time of activation that it jumps to the initial pose if JTC does not send an update between activation and the first write-call (e.g., if the gazebo update rate is higher than that of the controller manager?).
• If you leave the controller in inactive state (independent if position or effort interface), then a zero velocity is commanded from gazebo_ros2_control since Various bug fixes gazebo_ros2_control#177. There is no "influence of gravity" simulation then.

This means that currently it is not supported what you want to simulate, and the problem is with gazebo_ros2_control and not with JTC. I'll see if I can propose a fix to gazebo_ros2_control.

[HPCLOL]

I think I was able to reproduce it now: This is a "feature" of gazebo_ros2_control

* If you activate a controller using position commands, the `perform_command_mode_switch` method is called, the control method bit for position is set, and in the next call of the write method the command variable is sent. This one is initialized with 0 if not configured with an initial value in the ros2_control tag. As a consequence, it might happen at time of activation that it jumps to the initial pose if JTC does not send an update between activation and the first write-call (e.g., if the gazebo update rate is higher than that of the controller manager?).

* If you leave the controller in inactive state (independent if position or effort interface), then a zero velocity is commanded from gazebo_ros2_control since [Various bug fixes gazebo_ros2_control#177](https://github.com/ros-controls/gazebo_ros2_control/pull/177). There is no "influence of gravity" simulation then.

This means that currently it is not supported what you want to simulate, and the problem is with gazebo_ros2_control and not with JTC. I'll see if I can propose a fix to gazebo_ros2_control.

Thank you very much for the attention and energy you put into this issue. I recently made a new discovery about this issue.

Since I didn't want JTC to control the robot joints at the beginning, when using the position command interface, I always set start_with_holding to false, and the joints would have the above-mentioned jump behavior. But recently when I set start_with_holding to true, the joint will hold the position when I activated JTC.

The reason why start_with_holding had no effect on this problem before was that there were some other reasons including structural characteristics and gazebo physical parameters caused joint oscillation. After I fixed them and set_hold_position to true, my problem was solved.

Your example in ros-controls/gazebo_ros2_control#251 perfectly demonstrates what I want to achieve. Thanks!