[ros-users] [Discourse.ros.org] [ROS Projects] Tricycle Plugin Fixed!

[Daniel Elbirt]

I've rewritten the tricycle plugin so that it now produces good navigation using rqt commands in Gazebo, with good correspondence to maps produced in rviz using rtabmap. You can download my code to experiment with [here](https://app.box.com/s/v5a9wvnojg1bp87d2q6ivzvj5i3bqt0w) :)

My inspiration came from the Instantaneous Centre of Rotation discussion [here](http://msl.cs.uiuc.edu/mobile/mch2.pdf).

Input is greatly appreciated! Let me know if there are other files you need in order to play around with it.

ONGOING ISSUES:

1) I'm concerned that my sign conventions for x and y seem to be reversed (compared to what I imagined them to be) in the code (see line 357 onward).

- Motion looks good in simulations, but I worry that this is producing the troubles I've experienced reaching 2D nav goals in rviz (aborts goals, tries to "back in" to them).

- It could be a deeper problem with the teb_local_planner not really being designed for Ackerman robots, but I definitely don't see it helping if the robot wants to "back in" to all sent goals.

- From what I can tell, the conversion from angular velocity commands to steering angle that is built into the teb_local_planner is incorrect when applied to Ackerman robots: it ought to be angle = asin(omega / v * wheelbase), as opposed to angle = atan(omega / v * wheelbase).

- This change would move the point of interest for angular velocity commands from the midpoint of the rear wheels (as in a diff drive robot), to the point of contact with the ground of the steering wheel.

2) Possibly related is the fact the velocities in odom seem to be given in the global frame. With the differential drive plugin, you only ever see linear x velocity being non-zero (linear y velocity = 0 always).

- Could this be because the odom updates (for the steering wheel location/orientation) are being defined by reference to the "special point" between the rear wheels (see line 401)?

- Also possibly related is an apparent (systematic) mismatch between the twist message in odom and the cmd_vel values? These values match when using the differential drive plugin, but does the difference in kinematics for an Ackerman robot make a mismatch here totally normal?

3) Another concern is drift. Errors accumulate when switching between hard clockwise and counterclockwise turns. There may be an issue with how I've handled setting the steering angle to avoid jittering around angle = 0 (see line 288).

- Alternatively, it might be a problem with the friction in my model?






---
[Visit Topic](https://discourse.ros.org/t/tricycle-plugin-fixed/1044/1) or reply to this email to respond.