RPP-related Improvements/questions

[mini-1235]

Hi, I have recently tried RPP on my omnidirectional robot, according to the tuning guide https://docs.nav2.org/tuning/index.html, it is not supported for omnidirectional robot, so I have tried to modify the code and played with it for a couple of hours.

I have two questions about it:

• Are there any reason that RPP cannot support omnidirectional robot? I tried to add linear.y in the following part:
  

  navigation2/nav2_regulated_pure_pursuit_controller/src/regulated_pure_pursuit_controller.cpp

  Lines 133 to 143 in 7f561b0

  	double RegulatedPurePursuitController::getLookAheadDistance(
  	const geometry_msgs::msg::Twist & speed)
  	{
  	// If using velocity-scaled look ahead distances, find and clamp the dist
  	// Else, use the static look ahead distance
  	double lookahead_dist = params_->lookahead_dist;
  	if (params_->use_velocity_scaled_lookahead_dist) {
  	lookahead_dist = fabs(speed.linear.x) * params_->lookahead_time;
  	lookahead_dist = std::clamp(
  	lookahead_dist, params_->min_lookahead_dist, params_->max_lookahead_dist);
  	}

  
  

  navigation2/nav2_regulated_pure_pursuit_controller/src/regulated_pure_pursuit_controller.cpp

  Lines 288 to 292 in 7f561b0

  	geometry_msgs::msg::TwistStamped cmd_vel;
  	cmd_vel.header = pose.header;
  	cmd_vel.twist.linear.x = linear_vel;
  	cmd_vel.twist.angular.z = angular_vel;
  	return cmd_vel;

  
  and set the allow_reversing as true, it seems that it is working properly on my robot, I can share a video and my config if needed

• The only thing I noticed is, since my robot has a ~3.0rad/s angular velocity, the orientation turns a little bit more than my goal and does not always match with the yaw_tolerance in goal checker, for xy, we have approach_velocity_scaling_dist that slows down the robot if close enough to the goal, is it reasonable to do the same thing for wz?

[SteveMacenski]

Are there any reason that RPP cannot support omnidirectional robot?

Mostly that the Pure Pursuit technique doesn't have a Y component. If how you added this doesn't break theory, I'm happy to include it as a configuration option for supporting omni platforms :-) I'd have to see how you split up the X vs Y component of velocity. The main question I'd have is how you handle orientations. If you have split into X and Y components, how are you handling rotations (since before we rotate to the path's heading, but if you can move in Y, that rotation is not strictly necessary) and/or break up the motions. For example, you could technically keep the orientation always the same and move with X/Y without rotating, which probably (?) isn't what you want at all times. I assume there's some kind of trade off that needs to happen about rotating vs Y moving.

I can share a video and my config if needed

Please!

we have approach_velocity_scaling_dist that slows down the robot if close enough to the goal, is it reasonable to do the same thing for wz?

Is that in the rotate to heading bit or the control law's actual computation? If the rotate to heading,we could just add this term to slow down on approach instead which is just following basic kinematics: https://github.com/ros-navigation/navigation2/blob/main/nav2_rotation_shim_controller/src/nav2_rotation_shim_controller.cpp#L334-L337

[mini-1235]

I can share a video and my config if needed

Please!

Can we chat on slack for this, I am pretty busy this week, so I will probably send you the videos next week!

Is that in the rotate to heading bit or the control law's actual computation? If the rotate to heading,we could just add this term to slow down on approach instead which is just following basic kinematics: https://github.com/ros-navigation/navigation2/blob/main/nav2_rotation_shim_controller/src/nav2_rotation_shim_controller.cpp#L334-L337

It's the rotate to heading part, I tried to add that but that does not really help for my case, I will try to check why