Deploying SLAM from 12,000 Km away

‍

Autonomous navigation remains one of robotics' biggest promises. From indoor robots to self-driving cars and off-road vehicles, there are many efforts and resources dedicated to solving this problem.

Simultaneous localization and mapping (SLAM) is fundamental to solving the autonomy problem, but insufficient; robots also need a way to interpret the map and determine how to navigate the environment. That’s where Nav2 comes into play: it enables mobile robots to navigate complex environments and complete user-defined application tasks with nearly any robot class.

While the challenge of applying the mentioned technology is complex enough on its own, our team's hybrid development approach required us to develop and deploy these algorithms on a robot that was standing (literally, as it’s a quadruped) 12,000 Km away from our office. This post describes the strategies, takeaways, and learned lessons from adapting RTAB-Map (one of the many SLAM solutions) on a Unitree Go2 EDU, using its onboard NVIDIA Jetson Orin.

‍

Start in simulation (but with deployment in mind)

‍

We setup a devcontainer with everything needed to spin up our virtual robot. ROS, Gazebo, Rviz and other dependencies were included in the Dockerfile, while our code was mounted as a volume at run time. This approach allowed us to later deploy on the robot smoothly, providing the application with the necessary environment to run.

As good as this approach is, running the simulation to test every change in the mapping and navigation stack was time consuming. Recording ROS bags alleviates that pain, and becomes a substantial time optimization of the development process, at the same time that it provides a reproducible benchmark.

‍

‍

Close the loop with Nav2 in simulation

‍

Once we generated a usable map of the environment, we wanted to test it with the Nav2 stack and see our simulated robot navigate. This is where reality hits: you find there are many parameters to configure in Nav2, such as costmaps, robot footprint, speed thresholds, sensor topics, velocity command topics, and more. After a lot of tuning, we reached a configuration that worked reliably.

So far, RViz has helped us visualize the robot’s sensors and map in real-time and publish the goal pose to the navigation stack, as shown in the simplified image below.

‍

‍

‍

Reality check: bags from the real robot

‍

In this project, the physical robot was on a different continent, so after sorting out the connectivity, we managed to SSH into the robot and collect a ROS bag locally while driving it around the place (with some local assistance), then we applied offline processing to test how our parameter tuning performed with real world data. Once again, ROS bags helped us save robot battery and give the operator a brake while figuring out the parameters.

This step reinforced a classic lesson: the sim–to–real gap matters.

Initially, the goal was to equip the robot with high-end third-party LiDAR and RGB-D camera, so we focused on simulating those, and performed all the setup on the simulated data, as it would transfer fairly easily to the real world. In reality, the expected sensors weren't available, and we had to rely on the robot’s onboard sensors, which provided lower data resolution. That meant re-tuning both RTAB-Map and Nav2.

‍

‍

We processed the ROS bags onboard the robot, which also helped validate the hardware performance under real workloads. To accommodate for the sparse point-cloud we buffered multiple LiDAR scans which allowed us to generate a usable map, although this came with a speed limit at which we could drive the robot to keep the data consistent.

‍

‍

Running everything onboard — remotely

‍

In robotics, the most fun comes when all your work converges on getting the robot ready and running your algorithm. Since our robot was kilometers away and we were connecting to it through a windows PC with no ROS or Rviz installed, we leveraged Foxglove Studio. By running Foxglove Bridge on the robot, we got:

• Real-time visualization
• “Click-and-go” navigation goals
• No ROS installation on the user device

This provided a nice and easy to setup interface for the user side, which allows for real-time data visualization and teleop commands, among other cool features.

‍

‍

Summary

‍

Let’s summarize our approach, and highlight some learned lessons along this project.

‍

‍

• Docker is a superpower for robotics deployment — from workstation to robot.
• Simulation pays off most when it’s close to reality, but even imperfect sims are invaluable for understanding system behavior.
• Sensor assumptions matter — mismatches can cost more time than expected.
• Remote-first robotics development is no longer a corner case.

‍

Legged robots, onboard autonomy, and remote deployment are converging faster than ever — and it’s exciting to be building at that intersection.

‍

‍

‍

‍