Navigation for Reachy 2023?

Users Reachy software
1

Hi Pollen Robotics team,

I was wondering for Reachy 2023 in the FAQ of the documentation, there is a part about autonomous navigation that says:

The current release does not come with an autonomous navigation stack. However, we have an internal (experimental) version where nav2 runs. If this is of interest to you, please let us know.

I’ve been working on building an autonomous navigation stack for Reachy 2023 so I was wondering if I’d like to try to run nav2 on Reachy 2023, would you have any instructions and things to be careful of (experimental)? I think on the Reachy 2023 we have, Nav2 is not yet installed, so my main questions are:

  1. Install: Exact packages + versions for experimental nav2 on Reachy 2023 (Humble) — is it just apt install ros-humble-navigation2 ros-humble-nav2-bringup ros-humble-slam-toolbox ros-humble-robot-localization, or specific versions / extra dependencies?
  2. Configs + bringup: Are the zuuu_description (nav2_params.yaml/slam.yaml/ekf.yaml/launches) configs/launches the correct version? Which launch is the canonical entry point, and is there a bringup guide or expected run order (map first → then localize + navigate)?
  3. Gotchas: Any known issues with — (a) SLAM/AMCL using /scan_filterd vs raw /scan, (b) the base IMU + ekf.yaml (is robot_localization required for usable odometry, or is wheel odom enough?), (b) use_sim_time (ships True — should it be False on the real robot?)
  4. Coexistence with the SDK: Can the nav2 run alongside mobile_base_server + reachy_sdk_server — Nav2 driving the base while we use the Python SDK for arms/head? Specifically, while nav2 is running, can we still call mobile_base.goto_async(…) for fine positioning, or must all base motion go through ROS2 (Nav2 goals / cmd_vel)? (We would like to use Nav2 for coarse navigation and localization but keep SDK goto_async for a final visual servo approach.)
  5. External control: Is there a supported way for an off-robot client (another computer on the same network that connects ReachySDK and can SSH connect to Reachy’s computer) to send NavigateToPose goals and read the robot’s map-frame pose, or does nav2 assume everything runs on-robot?

Thank you very much!

2

Hi Pollen Robotics team,

Just checking in about this question on nav2 for Reachy 2023 again, thank you!

3

Just checking in about this question again, thank you Pollen Robotics team!

4

Hello,

I’m the one who did the experimental nav stack back in the day, but I’m afraid it’s been a long time and I’ll be of little help. Some inputs:

  1. The repos I worked on are here:
    GitHub - pollen-robotics/zuuu_description · GitHub
    GitHub - pollen-robotics/zuuu_interfaces · GitHub

  2. The nav2 stack was tested quite a bit on the mobile base, so the values in the files should be good. All the main features worked well in my tests (path finding, obstacle avoidance, SLAM used to create a static map).

  3. Back then I didn’t even work on Humble, I was still on Foxy and it was painful. I bitterly remember all of the RViz crashes.

My advice would be to start over with a modern, stable version of nav2. Use our zuuu_hal module to abstract the hardware (it provides the standard I/O the ROS nav2 expects) and use our config files as examples (maybe to be retuned), and then let nav2 do its thing. I’d advice to do the nav2 tutorials to get the hang of it, after a while it become straightforward.

Some answers:

“map first → then localize + navigate?“ → Yes, the system requires a static map that’s typically created using a SLAM algorithm (I used cartographer) + a teleoperated robot. Then you start the nav2 stack, and provide a (rough) current location of the robot (you’ll see the AMCL particules teleport to the location you gave) (this can be done in the RViZ GUI or using CLI).

“a) SLAM/AMCL using /scan_filterd vs raw /scan, (b) the base IMU + ekf.yaml (is robot_localization required for usable odometry, or is wheel odom enough?)“ → use scan filtered otherwise you’ll have fixed LIDAR points on the self collisions with the mast. And yes, robot_localisation IS required (the odometry is surprisingly good, but using odometry as your localisation algorithm is a crime and if you do it I’ll end up knowing it and you’ll end up receiving an angry email from me).

“(b) use_sim_time (ships True — should it be False on the real robot?)“ AH GODDAMIT I hate this flag. Probably the worst regression from ROS1. I’ve battled this flag so much I don’t even remember the correct answer, the launch files I did back in the day should handle this though (rule of thumb is: try to make sure all nodes have the same flag state on this).

Another advice: you can start working on this using Gazebo. And when you’ll start on the real mobile base, be very careful. Always have the emergency stop button in your hand when running stuff (the mobile base is crazy powerful/fast).

“Coexistence with the SDK:“ This doesn’t exist and you’ll have to code it yourself, but it should be quite straightforward once the nav2 stuff works.

“External control“ Yes this will work as long as all of your computers are on the same network and use the same ROS_DOMAIN_ID. This is one of the perks of running ROS, you can spread out your nodes (but I’d be careful with it because WiFI is not always reliable).

Best of luck, keep us posted!

2 Likes