Thoughts on /navigate_to_position and /wall_follow action servers

[slowrunner]

RE: /navigate_to_position

• The explanation states "The robot will take a rotate -> translate -> rotate approach to achieve the goal position. First rotating from its current heading to face the goal position, then driving straight to the goal position, then optionally rotating to achieve the goal heading." but does not indicate how or if hazards (bump, IR obstacle detection, wheel slippage) affect the behavior.
• The /navigate_to_position action server appears to block all external /cmd_vel topics. On one invocation I noticed, after the initial rotate to the goal position action, that the translate segment would be blocked by an obstacle. I attempted to "assist" the navigation via teleop_twist_joy /cmd_vel messages, with the hope that the /navigate_to_position action server would simply adjust the PID control to resolve heading to the goal (and not initial heading), but my "assistance" was blocked/ignored.
• Perhaps the simplest "assisted navigation" would be to "Fail Due To External Command", stopping the action when any /cmd_vel is received while navigating.

RE: /wall_follow

• The /wall_follow action server operates at a frantic pace
• It speeds so fast that it cannot avoid bumping into the wall it is trying to detect. The speed during the initial "find wall" should be slower to not "overrun its headlights" (IR obstacle sensor update rate)
• The /wall_follow action would be more useful if it had a "termination_distance" in addition to the "duration" parameter. This would allow wall following along a wall of known length, then DR navigation away from the wall to another wall following segment.
• The target distance (side_left or right IR intensity target value) is very close to the wall. This is impressive when following a normal wall with a baseboard, but fails catastrophically if the user has mounted anything on top of the Create3.
  If the /wall_follow action allowed an optional "clearance" modifier in the range of {0..4} that would increase the wall following target distance, with clearance:4 equal to IR intensity < 50, the wall follow distance to wall would increase to 150-300mm allowing for wall following in typical kitchen areas with cabinets. Combined with slowing down the speed during the wall detect phase, the clearance modifier would greatly enhance the utility of the /wall_follow action server.

[alsora]

Hi @slowrunner, I'll try to respond in order.

RE: /navigate_to_position

but does not indicate how or if hazards (bump, IR obstacle detection, wheel slippage) affect the behavior.

If the robot has some active reflexes, these will "take over" the motion control in case of bumps/cliffs/proximity.
However, the behavior is meant to be used in an obstacle-free environment. Indeed it doesn't do any path planning and it assumes that the goal is reachable via a straight line motion.
It's not on the Create 3 roadmap to provide a more advanced behavior that integrates obstacle detection, although this would be an interesting project for the community. Note that it's doable to implement such behaviors using the ROS 2 sensor data exposed by the robot.
Slippage is accounted for in the odometry computation done on board of the robot.

The /navigate_to_position action server appears to block all external /cmd_vel topics.

Yes, this is on purpose and it won't change.
We don't allow users to control the robot while an autonomous behavior provided by us is running in the background.
Note that it's fairly straight forward to re-implement a behavior like this.
We provide an open-source implementation in C++ in the create3 simulator repository: https://github.com/iRobotEducation/create3_sim/blob/main/irobot_create_common/irobot_create_nodes/src/motion_control/drive_goal_behaviors.cpp
You could do the following:
Create a ROS 2 node that exposes an action server named wali_navigate_to_position.
This should publish the velocity commands to the cmd_vel topic, and thus controlling the robot.
You can then further modify your node, by adding a wali_cmd_vel topic subscription.
You can publish your commands there to help the robot.
Note how we use new names to not collide with the names used by the robot.

Perhaps the simplest "assisted navigation" would be to "Fail Due To External Command", stopping the action when any /cmd_vel

You can already do this from your code.
The ROS 2 code where you send the ROS 2 action goal to navigate_to_position can also subscribe to cmd_vel and when it sees that someone is publishing on that topic, can issue a cancel action goal request.

RE: /wall_follow

The /wall_follow action server operates at a frantic pace

We could expose a parameter to control the speed in a future release.

The /wall_follow action would be more useful if it had a "termination_distance" in addition to the "duration" parameter.

Again, we can expose a parameter for that in a future release.
Note that similarly to the "assisted navigation" point above, you can already implement something similar by monitoring the odometry topic and measuring how much the robot has traveled and then issue a request to cancel wall_follow.

The target distance (side_left or right IR intensity target value) is very close to the wall. This is impressive when following a normal wall with a baseboard, but fails catastrophically if the user has mounted anything on top of the Create3.

Yes, the behavior is not meant to be run if the robot has stuff mounted on top and the wall has gaps where the robot can fit.
We will add a note in the documentation about this

[slowrunner]

Thank you for your responses - good points consistent with my growing thoughts that the more I offload to my controller the more responsive the Create3 will appear. It seems the create3 processes /cmd_vel topics very promptly but actions much less so.