Skip to content

JTC does not stop velocity command after goal succeed #469

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tonynajjar opened this issue Nov 22, 2022 · 6 comments
Closed

JTC does not stop velocity command after goal succeed #469

tonynajjar opened this issue Nov 22, 2022 · 6 comments

Comments

@tonynajjar
Copy link
Contributor

tonynajjar commented Nov 22, 2022

Describe the bug

I'm using the JTC with a velocity command interface. After the trajectory goal succeeds, a small velocity command is still continuously sent to the hardware interface.

To Reproduce
setup JTC with velocity command and send a goal

Expected behavior

I would expect the velocity command to be reset to 0.

Environment (please complete the following information):

  • OS: Ubuntu Jammy
  • Version: master

Additional context

@tonynajjar tonynajjar added the bug label Nov 22, 2022
@tonynajjar tonynajjar changed the title JTC does not stop velocity command after goal succeeds or fails JTC does not stop velocity command after goal succeed Nov 22, 2022
@tonynajjar
Copy link
Contributor Author

tonynajjar commented Nov 23, 2022

I noticed that this only happens when use_closed_loop_pid_adapter_ = true, so when there is only a velocity command, which is my case

@christophfroehlich
Copy link
Contributor

Even worse (?): I realized now that JTC with use_closed_loop_pid_adapter_ does not stop the movement after a goal gets cancelled, but the last velocity is maintained.

@christophfroehlich
Copy link
Contributor

We have now two PRs addressing the hold-position at startup or after canceling a goal. I think now, that the issue of this PR has a different cause because set_hold_position() is not called after reaching the goal:

if (!outside_goal_tolerance)
{
auto res = std::make_shared<FollowJTrajAction::Result>();
res->set__error_code(FollowJTrajAction::Result::SUCCESSFUL);
active_goal->setSucceeded(res);
// TODO(matthew-reynolds): Need a lock-free write here
// See https://github.com/ros-controls/ros2_controllers/issues/168
rt_active_goal_.writeFromNonRT(RealtimeGoalHandlePtr());
RCLCPP_INFO(get_node()->get_logger(), "Goal reached, success!");
}

I tried different action goals, with velocity command interface (use_closed_loop_pid_adapter_ is true). I could not reproduce the behavior you described if the action goal has only position entries.
But if I add velocities to the points, where the last point is nonzero, the controller does not stop after reaching the goal. (behavior is depending on the combination of ff_velocity_scale and feedback gains)
https://github.com/christophfroehlich/gazebo_ros2_control/blob/66eabd30851847da2143714a586ec9524d79a73a/gazebo_ros2_control_demos/examples/example_position_with_velocity.cpp#L132-L137

Might that be your case? I'm not sure what the controller should do if the last received commanded velocity is different from zero. Should we call set_hold_position() then?

@tonynajjar
Copy link
Contributor Author

I moved on from this and don't use JTC anymore unfortunately, I won't be able to help

@christophfroehlich
Copy link
Contributor

Ok. If the problem was a nonzero velocity of the trajectory point at the end, it's maybe not a bug but some missing (optional) feature to automatically set it zero.

@christophfroehlich
Copy link
Contributor

Fixed with #558

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants