Robots that work fine in a demo often fail for very specific, very unglamorous reasons once they’re actually deployed. A docking system that relies only on wheel odometry can’t hit millimeter precision, so teams end up bolting on extra sensors just to compensate. A 2D LiDAR only sees a single flat plane, usually around knee height, so it has no way of detecting a forklift’s raised arm until the robot has already driven into it. A localization stack built on wheel odometry and a static map starts to drift the moment people and carts move through the scene, because it was designed for an environment that doesn’t change. And a CPU-based motion planner can take hundreds of milliseconds to recalculate a path around a new obstacle, which is too slow when that obstacle is a person walking by.
These are four different problems, but they show up constantly in industrial and warehouse robots. They’re also exactly what the four demos below are built to solve, one problem each, using NVIDIA Isaac ROS CUDA-accelerated computing packages.
Why these four, and why we can’t show you the client
Each demo below started as a real problem we ran into on a client project. We can’t show you those systems, NDAs are NDAs, but we can show you the underlying technical problem, rebuilt from scratch in NVIDIA Isaac Sim, running the same Isaac ROS package we used to solve it. Every setup and every number below is real.
We picked these four because, together, they cover most of what breaks in autonomous mobile robots and manipulators once they leave the demo floor: localization that degrades around moving obstacles, obstacles a 2D sensor physically cannot see, motion plans that can’t be recomputed fast enough, and docking precision that used to depend on IR sensors alone. We’ve spent 14+ years building navigation, simulation, and perception stacks for robotics companies. We maintain ROS infrastructure, sit on the ROS 2 Technical Governance Committee, and are an OSRA founding member. These demos were as much an evaluation for us as for the teams we build alongside: we wanted to know, concretely, where GPU acceleration earns its added complexity and where it doesn’t.
1. Docking without depending on wheel odometry alone: isaac_ros_apriltag
The problem: A warehouse AMR needs to dock at a charging station with millimeter precision, without relying on wheel odometry to get it there. One client had forklifts driving to charging stations using nothing but IR sensors. The moment they added cameras to the fleet, IR became something they wanted to remove entirely, not maintain alongside a second sensing system.
The setup: A forklift with a forward-facing monocular camera, driving towards a charging station with tag36h11 family AprilTags.
What it shows: isaac_ros_apriltag processes the camera frames on GPU and publishes the tag’s pose straight to /tf as tag_to_camera, standard ROS 2 output that drops into any nav stack. The robot drives toward the tag using nav2 and corrects its final position and orientation with the information provided by isaac_ros_apriltag integrating opennav_docking, the official nav2 docking server.
Why it matters: Isaac ROS packages are optimized for NVIDIA hardware specifically. The client’s stack was already running on NVIDIA Jetson, so this package came already optimized for their platform without extra tuning.
2. Seeing the obstacle a 2D LiDAR walks straight past: isaac_ros_nvblox
The problem: A forklift keeps colliding with shelves or arms from other forklifts. Its 2D LiDAR scans at a single fixed height, so anything that overhangs above or below that plane, (a tabletop, a pallet arm, a low-hanging pipe), simply doesn’t exist as far as the robot’s costmap is concerned.
The setup: A forklift robot with an RGB-D depth camera (we simulated an Intel RealSense) moving through a warehouse with shelves full of boxes that might have not been there when mapping.
What it shows: isaac_ros_nvblox builds a real-time 3D TSDF mesh of the environment on GPU as the robot moves, then projects that mesh into Nav2’s 2D costmap as an obstacle layer. In RViz you can see the map update the instant isaac_ros_nvblox detects the shelves, and how Nav2 recomputes a route around it.
Why it matters: TSDF integration and ESDF generation run entirely in CUDA, so the costmap updates in real time as the robot drives. The costmap layer itself is a standard nav2_costmap_2d plugin (nvblox::nav2::NvbloxCostmapLayer), so it drops into an existing Nav2 deployment as a config change, not a rewrite. And since the client’s stack was already running on NVIDIA Jetson, the package came already optimized for their hardware without extra tuning.
3. Localization that doesn’t fall apart when the scene keeps moving: isaac_ros_visual_slam
The problem: The client’s navigation stack leaned on classic SLAM: LiDAR, wheel odometry, and largely static maps. In a real warehouse, people, carts, and pallets move through the scene constantly, and any one of those localization sources can degrade the moment the environment stops matching the map.
The setup: A Nova Carter AMR teleoperated through a dynamic indoor environment, with stereo cameras for cuVSLAM, a synthetic IMU, 3D LiDAR, and multiple human agents crossing its path on repeatable trajectories.
What it shows: isaac_ros_visual_slam (cuVSLAM) estimates the robot’s trajectory and maintains a map of visual landmarks independently of the LiDAR-based localization running in parallel. In RViz, the VSLAM trajectory and landmark cloud sit alongside the raw LiDAR point cloud, a direct geometric reference for how consistent the visual estimate stays while people keep walking through the frame.
Why it matters: This isn’t a replacement project: it’s the first data point in a longer benchmarking effort comparing a classic SLAM and navigation stack against a GPU-accelerated, perception-based one. cuVSLAM’s landmarks, pose graph, and loop closure don’t depend on wheel encoders or LiDAR scan matching, which makes it a genuinely independent localization source rather than a redundant one. Getting there also has hardware implications: GPU-accelerated VSLAM, and the AI-based perception it can eventually support, needs a compute platform most existing navigation stacks weren’t built around.
4. Replanning around obstacles in milliseconds, not hundreds of them: isaac_ros_cumotion
The problem: An industrial arm in a manufacturing cell needs to pick and place parts while avoiding obstacles that move between cycles, without pausing visibly to replan. The client already had a high-fidelity Isaac Sim setup for visual validation of a navigation stack, but the CPU-based planner behind it wasn’t fast enough to keep up.
The setup: A manipulator (we used a UR10e-class arm) over a table, with an object to pick up and a static or repositioned obstacle in its path.
What it shows: A goal pose is sent to the cuMotion server. Where a traditional CPU planner takes hundreds of milliseconds to compute a collision-free path, isaac_ros_cumotion solves it on GPU in roughly 2 to 5 milliseconds, fast enough that the resulting motion in simulation looks continuous rather than stop-and-recompute.
Why it matters: Swapping isaac_ros_cumotion into the client’s existing Isaac Sim setup led to a much quicker process than the previous navigation algorithm, without having to rebuild the simulation itself.
The pattern underneath all four
Different sensors, different packages, different failure modes, but the same shape of problem: a robot that has to perceive, localize, or replan inside a time budget that CPU-bound approaches weren’t built to hit. That’s the specific niche Isaac ROS occupies: GPU-accelerated ROS 2 packages that drop into existing navigation stacks (Nav2, standard /tf, standard costmaps) instead of asking teams to rebuild around them. For teams already committed to NVIDIA hardware at the edge, that turns out to be a meaningfully lower-friction upgrade path than it looks like on paper.
We built all four of these on the current generation of Isaac ROS, and we’ve been on it since the previous release. NVIDIA announced Isaac ROS 5.0, the next version at ROSCon this week, and we’re genuinely looking forward to getting these same four demos running on it.
Talk to the team that built these
We’re at ROSCon 2026 this week (Sheraton Centre, Toronto, September 20–26), Booth 20. If any of these four problems sound familiar, or you want to see the code behind them, stop by and talk to us.
Not at ROSCon? Get in touch with our team and we’ll walk you through what we built, and whether the same approach applies to what you’re running today.