Revision history [back]

As convention, the cmd_vel topic is producing commands in body-fixed frame, not as steering commands for the ackermann angular rates. Simple kinematics can be done below RPP to convert body-fixed angular velocities into steering angle velocities based on the kinematics of your particular vehicle.

Because cmd_vel has to be general for all types of robot systems, this is a long standing convention. It is convenient that differential drive and (most) omni platforms share the same frame of reference for control, but that’s not a limitation of the cmd_vel topic. At the end of the day, its on a robot developer to convert a Twist into motor commands (true of diff/omni as well) based on the particulars of your vehicle, so ackermann is actually not treated any differently.

As convention, the cmd_vel topic is producing commands in body-fixed frame, not as steering commands for the ackermann angular rates. Simple kinematics can be done below RPP to convert body-fixed angular velocities into steering angle velocities based on the kinematics of your particular vehicle.

Because cmd_vel has to be general for all types of robot systems, this is a long standing convention. It is convenient that differential drive and (most) omni platforms share the same frame of reference for control, but that’s not a limitation of the cmd_vel topic. At the end of the day, its on a robot developer to convert a Twist into motor commands (true of diff/omni as well) based on the particulars of your vehicle, so ackermann is actually not treated any differently. You’d like to move at some velocity with some turning rate, the way you interpret that is linked to where your motors are located, in what configuration, and with what wheel radii.

As convention, the cmd_vel topic is producing commands in body-fixed frame, not as steering commands for the ackermann angular rates. Simple kinematics can be done below RPP to convert body-fixed angular velocities into steering angle velocities based on the kinematics of your particular vehicle.

Because cmd_vel has to be general for all types of robot systems, this is a long standing convention. It is convenient that differential drive and (most) omni platforms share the same frame of reference for control, but that’s not a limitation of the cmd_vel topic. topic or a problem for supporting other vehicles. Diff/omni are just especially simple cases.

At the end of the day, its on a robot developer has to convert a Twist into motor commands (true of diff/omni as well) based on the particulars of your vehicle, so ackermann is actually not treated any differently. You’d like to move at some velocity with some turning rate, the way you interpret that is linked to where your motors are located, in what configuration, and with what wheel radii.radii. Every type of robot model has different kinematics and parameters, but all can take in a linear and angular velocity vector to do.

As convention, the cmd_vel topic is producing commands in body-fixed frame, not as steering commands for the ackermann angular rates. Simple kinematics can be done below RPP to convert body-fixed angular velocities into steering angle velocities based on the kinematics of your particular vehicle.

Because cmd_vel has to be general for all types of robot systems, this is a long standing convention. It is convenient that differential drive and (most) omni platforms share the same frame of reference for control, but that’s not a limitation of the cmd_vel topic or a problem for supporting other vehicles. Diff/omni are just especially simple cases.

At the end of the day, a robot developer has to convert a Twist into motor commands (true of diff/omni as well) based on the particulars of your vehicle, so ackermann is actually not treated any differently. You’d like to move at some velocity with some turning rate, the way you interpret that is linked to where your motors are located, in what configuration, and with what wheel radii. Every type of robot model has different kinematics and parameters, but all can take in a linear and angular velocity vector to do.

As convention, the cmd_vel topic is producing commands in body-fixed frame, not as steering commands for the ackermann angular rates. Simple kinematics can be done below RPP to convert body-fixed angular velocities into steering angle velocities based on the kinematics of your particular vehicle.

Because cmd_vel has to be general for all types of robot systems, this is a long standing convention. It is convenient that differential drive and (most) omni platforms share the same frame of reference for control, but that’s not a limitation of the cmd_vel topic or a problem for supporting other vehicles. Diff/omni are just especially simple cases.

At the end of the day, a robot developer has to convert a Twist into motor commands (true of diff/omni as well) based on the particulars of your vehicle, so ackermann is actually not treated any differently. You’d like to move at some velocity with some turning rate, the way you interpret that is linked to where your motors are located, in what configuration, and with what wheel radii. Every type of robot model has different kinematics and parameters, but all can take in a linear and angular velocity vector to do.

I can’t speak to the particulars of the controller you mention however, that’s outside of the navigation project. I will admit, an open-source node to shim Body-fixed Twists to some Ackermann-steering-centric Twists given the relevant kinematic parameters would be valuable.