Diablo Saukele: Taking Autonomous Navigation from Simulation to a Real Robot on Our Diablo Platform

Diablo Saukele: Taking Autonomous Navigation from Simulation to a Real Robot on Our Diablo Platform

Our team explains Diablo Saukele, a workflow that takes autonomous navigation from simulation to a real Diablo wheeled-leg robot, and what makes the handoff work.

Inside Diablo: A Direct-Drive Self-Balancing Wheeled-Leg Robot Platform 読む Diablo Saukele: Taking Autonomous Navigation from Simulation to a Real Robot on Our Diablo Platform 7 分

At Direct Drive Tech, we wanted to show how an autonomous navigation system can be tested in a virtual world first, then moved onto a physical robot with minimal friction.

Diablo Saukele is an open-source navigation stack built by a Carnegie Mellon team on top of our Diablo robot. It includes our diablo_ros2 driver for motion control, which means teams can test the full navigation pipeline in simulation on a laptop, then run the same software on a real Diablo without rewriting it.

The project also connects to a longer research path in lidar-based autonomy. In 2024, Carnegie Mellon systems scientist Ji Zhang received the Robotics: Science and Systems Test of Time Award for LOAM: Lidar Odometry and Mapping in Real-Time, the influential 2014 RSS paper co-authored with Sanjiv Singh. That recognition speaks to the lasting impact of lidar odometry and mapping research on systems like Diablo Saukele.

RSS 2024 Test of Time Award page showing Ji Zhang and Sanjiv Singh receiving recognition for their LOAM lidar odometry and mapping paper.

Why simulation comes first

Simulation gives teams a lower-risk way to test autonomous navigation before running the robot in a real environment. In a Unity-based virtual scene, developers can check how the navigation stack responds to corridors, turns, obstacles, dead ends, and different waypoint settings without risking damage to the physical robot or interrupting hardware time.

This is especially useful in shared research labs and early-stage integration projects. A university lab may have several students working with one Diablo robot, so simulation lets more teams continue testing while the hardware is in use. For inspection, mapping, or delivery applications, integrators can evaluate route behavior in software first, then move to real-world testing with fewer unknowns.

What the system is made of

Diablo Saukele combines perception, mapping, planning, and motion control into a single autonomous navigation workflow. The Livox Mid-360 lidar provides the main distance measurements around the robot, while the SLAM module uses that data to estimate the robot's position and build a map of the surrounding environment. The route planner calculates a path toward a defined goal, and the exploration planner supports autonomous coverage of unknown areas for mapping tasks.

These modules are supported by a base autonomy system that evaluates terrain traversability, avoids obstacles, and follows waypoints. On the Diablo platform, the diablo_ros2 driver connects this navigation stack to the robot's motion control, allowing the same framework to move from simulation testing to real-world deployment.

What real-world deployment adds

After the system moves from simulation to the physical Diablo robot, the main differences come from sensor coverage, motion, and site conditions. In this sensor configuration, the lidar does not cover roughly 1.2 m of ground directly in front of the robot, so very low objects in that area may not be detected. During longer runs, SLAM drift may also appear and affect the terrain map or obstacle avoidance behavior. When that happens, the terrain map can be cleared from the controller before continuing the test.

The deployment parameters also need to match the site. Obstacle height thresholds, travel speeds, and indoor or outdoor planner settings can all be adjusted in the launch files. The default values in the repository are based on this specific Diablo setup, so teams should tune them for their own environment. The upper electronics use a separate pair of batteries from the robot drive system and last around 1.5 hours in this configuration. Because the batteries are hot-swappable, teams can continue mapping or testing with limited downtime.

Why the robot platform matters

In autonomous navigation, the quality of the physical platform directly affects the quality of perception and planning. If the robot shakes heavily during movement, that motion is reflected in the lidar data, which can make SLAM and obstacle avoidance less stable. This is one of the key differences between simulation and real-world deployment: in simulation, the sensor data is clean by default, while on a real robot it depends on how steadily the platform moves.

Diablo's direct-drive wheeled-leg design helps reduce this gap. The robot can keep its head level while walking, jumping, and crossing obstacles, without relying on a gimbal or additional compensation code. This gives the SLAM module cleaner point cloud data to work with during field testing. Six M1502D direct-drive joints provide smooth and responsive motion, and the gearbox-free structure helps keep operation below 49 dB, which is useful in indoor environments such as offices, laboratories, hospitals, and public facilities.

The platform also gives the planner more usable movement options. Diablo can travel on wheels at up to 2 m/s on flat ground, while its articulated legs help it handle steps, thresholds, and uneven surfaces. In creeping mode, it can carry up to 80 kg, leaving room for sensors, computing hardware, cargo boxes, or other application modules mounted on the robot.

Who can build on Diablo Saukele

Diablo Saukele is designed for teams working in robotics research, education, inspection, mapping, delivery, and mobile robot integration. In laboratories and universities, it gives students and researchers a platform for testing navigation algorithms, building extensions, and running experiments with ROS 1 and ROS 2 support. For inspection and mapping teams, the system can support repeated routes through industrial parks, campuses, residential areas, and other semi-structured environments.

Delivery and mobile service projects can also build on the same platform. Diablo's payload capacity and quiet direct-drive system make it suitable for warehouse, campus, and indoor delivery scenarios where additional modules such as a cargo box, computing unit, or robotic arm may be added. For teams that need more computing power, the repository also includes an option to transmit data over WiFi to a nearby base station, allowing heavier AI models to run off-board while sending navigation instructions back to the robot.

"In mobile autonomy, the transition from simulation to hardware depends on both the algorithm and the platform underneath it," our engineering team notes. "By keeping motion smooth, stable, and quiet at the joint level, Diablo gives the perception stack cleaner data to work with during real-world deployment."

Where to find everything

The full autonomy stack, with hardware setup files and bracket CAD models, sits in the GitHub repository, and our Diablo SDK documentation covers the development side. Diablo ships with an open SDK and is available from our Diablo product page. Our team is happy to talk through a setup with anyone weighing it up.

About Direct Drive Tech

We develop and manufacture direct-drive motors and robots in our own facility. Our range covers the M06 and M15 direct-drive motor series for AGV, AMR, inspection, delivery, and cleaning platforms, along with the Diablo wheeled-leg robot, the eight degree of freedom TITA, and the modular D1. Everything is at shop.directdrive.com.

コメントを書く

全てのコメントは、掲載前にモデレートされます

このサイトはhCaptchaによって保護されており、hCaptchaプライバシーポリシーおよび利用規約が適用されます。