Revision history [back]

Indeed, the parameter definition for the wheelbase is misleading. The wheelbase is defined as the distance between the rear and front axle. However, the wheelbase parameter is only used in case you are sending commands to a base controller dealing with a modified Twist message such as stage in the car mode (see Section 2.2.1 here). Which one of the axles is the actual drive shaft is not relevant for the teb_local_planner, since we ignore friction, slipping etc.

Regarding your navigation setup and questions:

First of all, the planner should work with both types of car-like robots (steering with the front or rear axle). But you need to revise your model in order to make it work. The car-like robot is considered as uni-cycle model with additional constraints (limiting turning rate etc.). Thus it is important that the center of rotation is defined properly by the location of the base-link frame. You are defining the frame at the center of the steering axle, but this is not the actual center of rotation of the robot. Refer to [1] for mathematical details. Here you can also find the theory on representing a car-like robot as uni-cycle model. Section 2.2. of the car-like robot tutorial shows an example image for robots with front-steering. The base_link frame must be located at the center of the rear-axle in order to work properly with the planner (accordingly, a robot with rear-steering requires base_link to be located at the front-axle).

In summary, the following steps should be performed:

• Front steering: locate base_link at the center of the rear-axle (rear-steering: base_link at front-axle)

• Set the desired minimum turning angle min_turning_radius (either try it out using rqt_reconfigure or calculate the value using the relations of transforming a car-like robot to a uni-cycle model: min_turning_radius = max_steering_angle=atan(wheelbase/min_turning_radius) (-> solve w.r.t. min_turning_radius).

• Depending of the base controller, you need to convert the twist message from the navigation stack to a message containing the linear velocity and the steering angle. Stage requires a twist message in which angular.z corresponds to the steering angle. In that case, the teb_local_planner provides an internal conversion if cmd_angle_instead_rotvel is activated. Only then, wheelbase is taken into account. The conversion is performed according to the relation mentioned above:

  steering_angle = atan(wheelbase*omega/v) if v!=0

  steering_angle = 0 if v==0

  However, sometimes it is preferable to set the steering_angle to the previous value for v=0. But in that case, you might implement your own small conversion script that subscribes to cmd_vel.

[1] [S. LaValle, Planning Algorithms, Cambridge University Press, 2016: Chapter 13](http://planning.cs.uiuc.edu/)

Indeed, the parameter definition for the wheelbase is misleading. The wheelbase is defined as the distance between the rear and front axle. However, the wheelbase parameter is only used in case you are sending commands to a base controller dealing with a modified Twist message such as stage in the car mode (see Section 2.2.1 here). Which one of the axles is the actual drive shaft is not relevant for the teb_local_planner, since we ignore friction, slipping etc.

Regarding your navigation setup and questions:

First of all, the planner should work with both types of car-like robots (steering with the front or rear axle). But you need to revise your model in order to make it work. The car-like robot is considered as uni-cycle model with additional constraints (limiting turning rate etc.). Thus it is important that the center of rotation is defined properly by the location of the base-link frame. You are defining the frame at the center of the steering axle, but this is not the actual center of rotation of the robot. Refer to [1] for mathematical details. Here you can also find the theory on representing a car-like robot as uni-cycle model. Section 2.2. of the car-like robot tutorial shows an example image for robots with front-steering. The base_link frame must be located at the center of the rear-axle in order to work properly with the planner (accordingly, a robot with rear-steering requires base_link to be located at the front-axle).

In summary, the following steps should be performed:

• Front steering: locate base_link at the center of the rear-axle (rear-steering: base_link at front-axle)

• Set the desired minimum turning angle min_turning_radius (either try it out using rqt_reconfigure or calculate the value using the relations of transforming a car-like robot to a uni-cycle model: min_turning_radius = max_steering_angle=atan(wheelbase/min_turning_radius) (-> solve w.r.t. min_turning_radius).

• Depending of on the base controller, you need to convert the twist message from the navigation stack to a message containing the linear velocity and the steering angle. Stage requires a twist message in which angular.z corresponds to the steering angle. In that case, the teb_local_planner provides an internal conversion if cmd_angle_instead_rotvel is activated. Only then, wheelbase is taken into account. The conversion is performed according to the relation mentioned above:

  steering_angle = atan(wheelbase*omega/v) if v!=0

  steering_angle = 0 if v==0

  However, sometimes it is preferable to set the steering_angle to the previous value for v=0. But in that case, you might implement your own small conversion script that subscribes to cmd_vel.

[1] [S. LaValle, Planning Algorithms, Cambridge University Press, 2016: Chapter 13](http://planning.cs.uiuc.edu/)

Indeed, the parameter definition for the wheelbase is misleading. The wheelbase is defined as the distance between the rear and front axle. However, the wheelbase parameter is only used in case you are sending commands to a base controller dealing with a modified Twist message such as stage in the car mode (see Section 2.2.1 here). Which one of the axles is the actual drive shaft is not relevant for the teb_local_planner, since we ignore friction, slipping etc.

Regarding your navigation setup and questions:

First of all, the planner should work with both types of car-like robots (steering with the front or rear axle). But you need to revise your model in order to make it work. The car-like robot is considered as uni-cycle model with additional constraints (limiting turning rate radius etc.). Thus it is important that the center of rotation is defined properly by the location of the base-link frame. You are defining the frame at the center of the steering axle, but this is not the actual center of rotation of the robot. Refer to [1] for mathematical details. Here you can also find the theory on representing a car-like robot as uni-cycle model. Section 2.2. of the car-like robot tutorial shows an example image for robots with front-steering. The base_link frame must be located at the center of the rear-axle in order to work properly with the planner (accordingly, a robot with rear-steering requires base_link to be located at the front-axle).

In summary, the following steps should be performed:

• Front steering: locate base_link at the center of the rear-axle (rear-steering: base_link at front-axle)

• Set the desired minimum turning angle radius min_turning_radius (either try it out using rqt_reconfigure or calculate the value using the relations of transforming a car-like robot to a uni-cycle model: max_steering_angle=atan(wheelbase/min_turning_radius) (-> solve w.r.t. min_turning_radius).

• Depending on the base controller, you need to convert the twist message from the navigation stack to a message containing the linear velocity and the steering angle. Stage requires a twist message in which angular.z corresponds to the steering angle. In that case, the teb_local_planner provides an internal conversion if cmd_angle_instead_rotvel is activated. Only then, wheelbase is taken into account. The conversion is performed according to the relation mentioned above:

  steering_angle = atan(wheelbase*omega/v) if v!=0

  steering_angle = 0 if v==0

  However, sometimes it is preferable to set the steering_angle to the previous value for v=0. But in that case, you might implement your own small conversion script that subscribes to cmd_vel.

[1] [S. LaValle, Planning Algorithms, Cambridge University Press, 2016: Chapter 13](http://planning.cs.uiuc.edu/)

Indeed, the parameter definition for the wheelbase is misleading. The wheelbase is defined as the distance between the rear and front axle. However, the wheelbase parameter is only used in case you are sending commands to a base controller dealing with a modified Twist message such as stage in the car mode (see Section 2.2.1 here). Which one of the axles is the actual drive shaft is not relevant for the teb_local_planner, since we ignore friction, slipping etc.

Regarding your navigation setup and questions:

First of all, the planner should work with both types of car-like robots (steering with the front or rear axle). But you need to revise your model in order to make it work. The car-like robot is considered as uni-cycle model with additional constraints (limiting turning radius etc.). Thus it is important that the center of rotation is defined properly by the location of the base-link frame. You are defining the frame at the center of the steering axle, but this is not the actual center of rotation of the robot. Refer to [1] for mathematical details. Here you can also find the theory on representing a car-like robot as uni-cycle model. Section 2.2. of the car-like robot tutorial shows an example image for robots with front-steering. The base_link frame must be located at the center of the rear-axle in order to work properly with the planner (accordingly, a robot with rear-steering requires base_link to be located at the front-axle).

In summary, the following steps should be performed:

• Front steering: locate base_link at the center of the rear-axle (rear-steering: base_link at front-axle)

• Set the desired minimum turning radius min_turning_radius (either try it out using rqt_reconfigure or calculate the value using the relations of transforming a car-like robot to a uni-cycle model: max_steering_angle=atan(wheelbase/min_turning_radius) (-> solve w.r.t. min_turning_radius).

• Depending on the base controller, you need to convert the twist message from the navigation stack to a message containing the linear velocity and the steering angle. Stage requires a twist message in which angular.z corresponds to the steering angle. In that case, the teb_local_planner provides an internal conversion if cmd_angle_instead_rotvel is activated. Only then, wheelbase is taken into account. The conversion is performed according to the relation mentioned above:

  steering_angle = atan(wheelbase*omega/v) if v!=0

  steering_angle = 0 if v==0

  However, sometimes it is preferable to set the steering_angle to the previous value for v=0. But in that case, you might implement your own small conversion script that subscribes to cmd_vel.

[1] [S. LaValle, Planning Algorithms, Cambridge University Press, 2016: 2006: Chapter 13](http://planning.cs.uiuc.edu/)