Skip to content
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

Steering controllers (ackermann, bicycle, tricycle) respecting joint limits #675

Open
ARK3r opened this issue Jun 16, 2023 · 6 comments
Open

Comments

@ARK3r
Copy link
Contributor

ARK3r commented Jun 16, 2023

Setting up a demo for the Ackermann controller I keep noticing that when I send turn commands the steering keeps turning until it reaches unreasonable angles and then the model starts to jerk around uncontrollably after the steering angles get out of proportion to each other:

Screencast.from.06-16-2023.12.08.30.PM.webm

I think the 3 of steering controllers could use a steering limit parameter in their yaml configuration files to stop giving commands farther than the limits.

This feature is mostly needed for the software's understanding of what the robot is doing and calculating odometry, considering in the real world the robot would just physically be unable to turn more than the limits but if the software doesn't know this, the software's understanding of the state of the robot could start drifting from the reality of the physical state of the robot.

@christophfroehlich
Copy link
Contributor

Are you sure that this isnt the same behavior as we found out with ros-controls/ros2_control_demos#316? (velocity vs position command if).

As you describe that the real robot is limiting the steering angles, wouldn't it make sense to implement that in your hardware component? Then all should be fine if you are not in open_loop mode. I agree that the limits should also be considered inside the steering lib (especially for open_loop mode).

@ARK3r
Copy link
Contributor Author

ARK3r commented Oct 10, 2023

I think the controller should not overshoot the realistic limits of steering anyway, even if open_loop is true, otherwise the robot description gets to unusable states.

I do think however this issue will become more clear as we figure out how to configure velocity for rear drive and position for steering.

@cschindlbeck
Copy link

We have an ackermann-type robot with steering angle joint limits +/- 45 deg, this would be highly useful

@christophfroehlich
Copy link
Contributor

We have an ackermann-type robot with steering angle joint limits +/- 45 deg, this would be highly useful

This means that your commanded twist is not feasible. Shouldn't this be considered by the path controller on top of the steering controllers?

@cschindlbeck
Copy link

We have an ackermann-type robot with steering angle joint limits +/- 45 deg, this would be highly useful

This means that your commanded twist is not feasible. Shouldn't this be considered by the path controller on top of the steering controllers?

so far, we have only connected a joypad controller which does not have any limits imposed, we will set the limit on the motor controller and in future we will use nav2 for path creation.

diff drive has limits on linear x and angular z, wouldn't this make sense for the steering controllers as well?

@christophfroehlich
Copy link
Contributor

christophfroehlich commented Aug 27, 2024

diff drive has limits on linear x and angular z, wouldn't this make sense for the steering controllers as well?

yes and no. There is something similar with the tricycle controller, and this should be merged in to the steering controller library. But I still think this is not necessarily a thing that controllers should implement on their own: Limits will be considered with the ressource manager in the future as followup of ros-controls/ros2_control#1526 (you can speed that up with reviews of the PR).

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

No branches or pull requests

3 participants