Designing a mobile rover with a top-mounted manipulator without degrading 2D LiDAR-based SLAM and Nav2 performance

[Sushant_Niraula]

Best practices for integrating a robotic arm on a mobile rover using 2D LiDAR SLAM (Nav2 / ROS 2)

Hello everyone,

I am working on a ROS 2 (Jazzy) based autonomous agricultural rover that uses 2D LiDAR-based SLAM and Nav2 for navigation in outdoor, unstructured environments. I would like to get feedback from the community on design and integration best practices before finalizing the mechanical layout.

Current setup

• Differential / rocker-bogie style wheeled rover

• 2D LiDAR (e.g. RPLIDAR-class sensor) for SLAM and obstacle avoidance

• IMU + wheel encoders fused using robot_localization

• Navigation using slam_toolbox and nav2

• URDF/Xacro-based robot description

• Planning to add a small 4-DOF robotic arm for tasks like crop inspection, watering, and weed control

Core concern

The robotic arm will be mounted on the top chassis plate, and I want to avoid degrading LiDAR-based SLAM and navigation performance.

Specifically, I am concerned about:

1. The arm occluding or reflecting LiDAR beams

2. Moving arm links being perceived as obstacles or mapped into the environment

3. Best mechanical placement of the arm relative to the LiDAR scan plane

4. Whether the arm should be considered part of the navigation robot or treated as a separate subsystem operationally

   Questions

   1. From experience, is it best practice to:

      • Mount the LiDAR above the arm’s maximum swept volume, or

      • Keep the arm entirely below the LiDAR scan plane and enforce a navigation-safe stowed pose?

   2. When using 2D SLAM, do most mobile manipulators:

      • Pause SLAM updates while the arm is moving?

      • Rely purely on self-filtering via the robot model in the costmaps?

      • Or physically ensure the arm never intersects the LiDAR plane?

   3. In terms of development workflow:

      • Is it better to fully stabilize the rover + navigation stack first and integrate the arm later?

      • Or to include the arm in the URDF early (even if unused initially) to avoid later TF and geometry changes?

   4. Are there any well-documented open-source ROS 2 robots (mobile manipulators) you would recommend studying specifically for LiDAR + Nav2 integration?

   I am intentionally keeping the system conservative (base stops while the arm operates) rather than attempting full mobile manipulation.

   Any insights, design rules, or references from real-world systems would be greatly appreciated.

   Thank you for your time.

[peci1]

@Sushant_Niraula

Moving arm links being perceived as obstacles or mapped into the environment

Use robot_body_filter to directly filter the scans before passing them to the costmap builder. However, the ROS 2 branch is not yet fully working.

[smac]

For all of these questions, there isn’t a ‘best’ but here’s some thoughts:

@Sushant_Niraula

From experience, is it best practice to:

• Mount the LiDAR above the arm’s maximum swept volume, or
• Keep the arm entirely below the LiDAR scan plane and enforce a navigation-safe stowed pose?

If mechanically you’re going to have something that far above the arm, I say why not! If you’re not and you’re just putting up a tall boom for the lidar’s sake, then I’d not go down Option 1.

@Sushant_Niraula

When using 2D SLAM, do most mobile manipulators:

• Pause SLAM updates while the arm is moving?
• Rely purely on self-filtering via the robot model in the costmaps?
• Or physically ensure the arm never intersects the LiDAR plane?

You said later that you weren’t planning on navigating while the robot is moving, this seems a little moot, no? But in general, I’d say self filtering. That also depends on the nature of the arm though. If its very long / outside of the bounds of the vehicle while navigating, maybe a simple solution isn’t the right one. But if its short and/or generally inside the chassis footprint while navigating, I’d say that’s an easy solution. Some occlusion is fine. Just don’t give it a little tiny window of visibility.

If your environment is large and your lidar is long-range, then even just filtering to a minimum range for SLAM is also an easy way to go about it. Don’t worry about a meter or two around the vehicle to get started with with a range filter.

@Sushant_Niraula

In terms of development workflow:

• Is it better to fully stabilize the rover + navigation stack first and integrate the arm later?
• Or to include the arm in the URDF early (even if unused initially) to avoid later TF and geometry changes?

Doesn’t matter. I’d say work on one problem at a time. If you’re not using the arm for the first while, I’d leave that for another time. Modifying URDFs isn’t a big deal.

In general, keep things simple until you prove to yourself the solution can’t handle simple.