gazebo_system.cpp crashes when trying to change multiple joint's PID values

[cco-seasony]

Hi,

I am trying to test the simulated RRBOT robot without moveit! and I am facing some issues when trying to adjust the PID paremeters through the xacro file. As a disclaimer, I followed the documentation provided with the difference of having a 2 DOF robot instead of using the slider_to_cart (which I tested and it works fine).

I believe everything is set up correctly including having only one joint per transmission. I can indeed adjust the PID parameters for the first joint but it fails when trying to declare the parameters inside of the gazebo_system.cpp.
More specifically I am working in the branch ahcorde/update/foxy created by @ahcorde .

On https://github.com/ros-simulation/gazebo_ros2_control/blob/7334f06cb849cc49b222f9ce674c8bbd87a7ab28/gazebo_ros2_control/src/gazebo_system.cpp I can see that the DOF, transmissions and the names of the joints are correctly retrieved from the .xacro file that I am using.

On line 61, when the iterator j is equal to 0 it will declare the PID parameters and initialize the PID for that joint. That works. Then when j is equal to 1, an exception rises. More specifically I believe that it crashes on line 180

A quick test that I did to avoid the issue was to comment out line 164, line 165, line 166, line 167, line 168, line 169 and instead declaring the PID parameters in a different loop just before line 61.
Something like this:

  for (unsigned int k = 0; k < this->n_dof_; k++) {
    nh_->declare_parameter(transmissions[k].joints[0].name + ".p");
    RCLCPP_WARN_STREAM(nh_->get_logger(),"--------------" << k);
    nh_->declare_parameter(transmissions[k].joints[0].name + ".i");
    RCLCPP_WARN_STREAM(nh_->get_logger(),"--------------" << k);
    nh_->declare_parameter(transmissions[k].joints[0].name + ".d");
    RCLCPP_WARN_STREAM(nh_->get_logger(),"--------------" << k);
    nh_->declare_parameter(transmissions[k].joints[0].name + ".i_clamp_max");
    RCLCPP_WARN_STREAM(nh_->get_logger(),"--------------" << k);
    nh_->declare_parameter(transmissions[k].joints[0].name + ".i_clamp_min");
    RCLCPP_WARN_STREAM(nh_->get_logger(),"--------------" << k);
    nh_->declare_parameter(transmissions[k].joints[0].name + ".antiwindup", false);
    RCLCPP_WARN_STREAM(nh_->get_logger(),"--------------" << k);
  }

Of course this is not the most efficient way but it does the job of initializing the PIDs for both joints. I am not sure if the problem is coming from the control_toolbox package or something related to gazebo_ros2_control.

Anyone going through a similar issue?

Thanks in advance for the help.

Kind regards,
Carlos

[ahcorde]

PID was removed from gazebo_ros2_control. See this PR plugin #44

[cco-seasony]

@ahcorde I can see another issue that might be related to this one.

I am also experiencing something similar. I will write it here but if you think it's better I will open a new issue.

Basically I have two simple links trying to perform a vertical movement (just going up and down like an elevator), with a velocity controller. I am experiencing that when I set the /velocity_controller/command to positive it goes up, when is negative it goes down but if I wanted to stop it at a certain level I cannot achieve that. Once I send velocity 0, the top link starts moving down (gravity I guess) and the joint_state velocity topic does not match with the actual zero velocity that was sent.

I am using the velocity_controllers/JointGroupVelocityController and I am not sure if there is a new way to set up a PID in order to solve my issue.

Any recommendations?

Thanks in advance.

[shonigmann]

@ahcorde - can you give any context on why PID was removed from gazebo_ros2_control? I looked through the PR comments and couldn't find much justification.

I also couldn't find much documentation into how you would be expected to tune a controller to achieve the desired behavior of a simulated actuator (or if you even need to)?

[Briancbn]

Once I send velocity 0, the top link starts moving down (gravity I guess) and the joint_state velocity topic does not match with the actual zero velocity that was sent.

Please check the temporary solution 1 suggested here. It's likely that there is no force limit set for you joint.