Navigation and Arm Movement

Ask
1

Hi hello robot team,

I am trying to run the nav2 mapping stack while also running the visual servoing demo. I am running into the issue where both processes can’t get access to the robot body at the same time. Is there a clean way to get around this limitation?

I wrapped the servoing demo as a ROS2 node so I can start and stop it with a topic subscriber. But, ideally we would not want to have to start the nav2, nav to the object, stop nav2, start the pick up script, stop the pickup script, start nav2, move to next location.

2

Hi @gregory_sin,

Thanks for reaching out, this is a really interesting setup.

Before diving too deep, could you share a bit more detail on what you’re launching? Specifically:

  • The exact commands or launch files for Nav2 and your servoing setup
  • Any logs you’re seeing when the conflict happens

One possibility is that both processes are trying to access the Stretch body at the same time (it only allows a single active controller), but it would be helpful to confirm your setup first.

Happy to take a closer look once we have a bit more context.

Best,
Jason

3

Hello @Jason_Koubi ,

I am using the same launch command as in the Mapping & Navigation demo from the Stretch 3 documentation (with our specific map):

ros2 launch stretch_nav2 navigation.launch.py map:=${HELLO_FLEET_PATH}/maps/my_demo_map.yaml

The visual servoing demo is similar with or without the modification make it a ROS 2 node. It prints out the line saying that the robot is in use and need to free the robot process. It only happens if the nav2 is running first. If I free the process after starting nav2 and before the servoing, the nav2 stops working.

I did dig to see that the free robot process checks for a file written with the pid of the process using the robot’s body. Is is possible to avoid this check or is it strictly necessary to prevent issues?

4

Hi @gregory_sin,

You’re correct that the PID/file check is what prevents multiple processes from accessing the robot body at the same time. We wouldn’t recommend bypassing it. Even if you do, you’ll likely run into OS-level errors (e.g., “USB device is busy”) since one process will already be holding the hardware connection.

The root issue is that the visual servoing demo initializes Stretch Body directly, while Nav2 uses stretch_driver (which also owns Stretch Body).

The cleanest solution is to keep a single owner of the robot body, typically stretch_driver when using ROS 2, and move the visual servoing logic into ROS. That means:

  • Avoid running the standalone visual_servoing_demo.py alongside Nav2
  • Refactor the servoing behavior into a ROS 2 node that publishes commands (instead of initializing stretch_body directly)
  • Coordinate between navigation and servoing at a higher level

Best,
Jason