Building NavBot-D1: From Parts, Jetson, and ROS 2 to Reinforcement-Learning Locomotion

A developer built NavBot-D1, an open-source quadruped robot platform that integrates mechanical design, Jetson Orin Nano Super, ROS 2, CAN bus, and reinforcement-learning locomotion. The platform is designed for industrial inspection, safety, field operation, and robotics research, with a focus on reproducibility and modular validation. The build process is structured into four layers: hardware bring-up, actuator bring-up, standing test, and locomotion test.

NavBot-D1 is an open quadruped robotics platform for developers. Its value is not just that it can walk, but that it connects mechanical design, actuators, onboard computing, ROS 2, CAN bus, remote control, and reinforcement-learning locomotion into a system that can be reproduced, modified, and extended. NavBot-D1 is positioned as an open development platform rather than a closed consumer robot dog. It is designed for industrial-grade development, inspection, safety, field operation, and robotics research. The product page lists several key specifications: This article follows the build as an engineering reproduction guide. We will start from the system goal, then walk through the hardware list and architecture, and finally connect mechanical assembly, Jetson bring-up, ROS 2, IMU/CAN validation, actuator IDs, calibration, and reinforcement-learning gait testing into one reproducible path. NavBot-D1 can be understood as a complete 12-DOF quadruped robot development kit. Its basic control loop looks like this: Remote input / LoRa ↓Jetson Orin Nano Super 8G ↓ROS 2 drivers, state estimation, RL locomotion policy ↓USB-CAN / CAN bus ↓12 joint actuators ↓IMU feedback + physical locomotion If you have built ROS 2 rovers, robotic arms, or desktop robots before, the main difference with NavBot-D1 is that this is not a slow wheeled chassis. It is a dynamic legged system. A wheeled robot can usually stop in place when control goes wrong. A quadruped with incorrect joint direction, ID mapping, zero position, or policy output can fall immediately. For NavBot-D1, the engineering sequence matters more than any single command. I recommend splitting the reproduction process into four layers: | Stage | Goal | Success Criteria | |---|---|---| | Hardware bring-up | Mechanical structure, power, main board, Jetson, IMU, and CAN all work | Stable power-on, working emergency stop, SSH access | | Actuator bring-up | 12 actuator IDs, directions, and zero positions are correct | Each leg moves consistently with the body coordinate frame | | Standing test | The robot can stand and switch modes reliably | Repeated power cycles lead to repeatable standing behavior | | Locomotion test | The RL policy drives controlled quadruped motion | Forward, backward, turning, and speed commands match remote input | This is also how the rest of this article is structured. We will not treat NavBot-D1 as a pile of parts. We will treat it as a layered robot system that must be validated step by step. The diagram below reorganizes the BOM by function. This is also how I recommend managing the parts during a real reproduction, because each layer has a different failure mode. | Module | Main Parts | Role | Reproduction Focus | |---|---|---|---| | Mechanical load-bearing layer | Body frame, upper/lower legs, support posts, limiters, battery bay | Carries the body, battery, actuators, and impact loads | Hole alignment, orientation, stiffness, limit range | | Actuation and transmission layer | 12 actuators, knee connectors, bearings, linkages | Provides 12 leg joints | ID, direction, zero position, linkage interference | | Onboard compute layer | Jetson Orin Nano Super 8G, main board, cooling | Runs ROS 2, drivers, and RL policy | Flashing, networking, SSH, thermals | | Sensing and bus layer | IMU, USB-CAN, CAN wiring | Provides attitude feedback and actuator communication | Device enumeration, permissions, data rate | | Communication layer | Remote controller, LoRa, GPS, image transmission module | Supports indoor/outdoor control and longer-range operation | Frequency, distance, open-area testing, antenna mounting | | Power and safety layer | Battery, BMS, power button, emergency stop, power distribution | Powers Jetson, peripherals, and actuators | Battery state, emergency stop, wire gauge, connector retention | One common mistake is to treat the BOM as a purchase list only. For a quadruped robot, every component should be tied to a validation action. For example, validating the IMU does not mean it is physically plugged in. It means you can read reasonable roll, pitch, yaw, or raw IMU data from the software stack. Validating CAN does not mean the USB-CAN adapter lights up. It means the adapter is detected, the bitrate is configured, and messages can be exchanged with the actuators. The NavBot-D1 system can be divided into three main paths: A few terms should be normalized before we continue: | Ambiguous Expression | Engineering Meaning | |---|---| | accurator | actuator / joint actuator | | canvas | CAN bus | | Nora | LoRa module | | resource learning | reinforcement learning | | Jet Nano / Jettison | Jetson Orin Nano Super 8G | All later steps follow these three paths: make the hardware mechanically reliable, make Jetson maintainable, bring up ROS 2 and CAN, then move to standing and gait testing. The mechanical build should begin with parts inspection, not immediate assembly. Once a quadruped is half assembled, discovering that a bearing, spacer, screw, or linkage is oriented incorrectly can cost a lot of time. I recommend laying out and checking parts in this order: Here is a practical rule: do not wait until actuator ID writing to decide where each actuator belongs. Before mechanical assembly, label each actuator temporarily, such as FL-HIP , FL-THIGH , and FL-CALF . This makes later ID writing, CAN wiring, and zero calibration much less error-prone. The first parts to secure are the actuators and the main frame. Three details are especially important: You can assemble one side first and then mirror the process on the other side. Each leg should be checked for: For a quadruped, mechanical limiters are not decorative parts. They prevent joints from rotating into dangerous positions during software faults, manual handling, or falls. Mechanical limits and software limits should both exist. Do not rely on the control policy alone. After the mechanical loop is closed, the next step is wiring. A useful rule is: power first, signals second; secure first, debug later. A typical connection structure looks like this: Battery ├── BMS / power management ├── Emergency stop / power switch ├── Main board power input ├── Jetson power ├── External module power └── Actuator power path​Jetson ├── USB → IMU ├── USB → USB-CAN adapter ├── USB → LoRa / receiver module ├── HDMI / keyboard / mouse for first boot └── Ethernet / Wi-Fi for SSH Cable routing is one of the easiest areas to underestimate. NavBot-D1 runs, turns, and absorbs impact from the ground. Every cable should satisfy three requirements: Power should be validated separately. For the first power-on, do not enable the actuators immediately. Confirm: The first software task is to turn Jetson into a maintainable compute node. Do not rush into robot code. Recommended flow: Why switch to SSH early? Later steps involve ROS 2 setup, dependency installation, driver builds, and log inspection. SSH makes command reuse and log capture much easier than working directly from an attached monitor. The acceptance criteria for this stage are simple: Host computer → SSH → JetsonJetson → Internet / local networkJetson → can reboot and reconnect Only after these are stable should you move to ROS 2 and driver installation. Once the base Jetson system is ready, the next layer is the robotics runtime stack. This usually includes: It is better not to hard-code a one-time command sequence here, because JetPack, ROS 2, kernel versions, and project scripts may change. A more reliable approach is to preserve the flow and validation points: | Subsystem | Goal | Validation | |---|---|---| | Wi-Fi | Jetson joins the local network wirelessly | SSH still works after unplugging Ethernet | | ROS 2 | Base environment is usable | Environment can be sourced and base tests run | | Device tree | Hardware interfaces are recognized | Device nodes remain stable after reboot | | Dependencies | Project can be built | Workspace build completes without key errors | | IMU | Attitude data can be read | Roll/pitch/yaw or raw IMU data changes reasonably | | USB-CAN | CAN adapter is usable | Device enumeration, bitrate setup, and send/receive tests pass | Logs matter during quadruped bring-up. Save the output of every build, driver installation, and device test, especially logs related to the CAN adapter, IMU, and actuators. If gait fails later, the policy is not always the problem. The lower-level interface may be unstable. CAN bus is the execution path of NavBot-D1. Jetson produces joint targets, but the 12 actuators on the CAN bus are what actually move the legs. Before entering reinforcement-learning control, each actuator must be handled individually: Do not connect all 12 actuators and then guess which one is which. For a quadruped, an ID mistake is direct: software may think it is controlling the front-left hip while the rear-right knee is moving. Create an actuator mapping table: | Leg | Joint | Temporary Label | Final ID | Direction | Zero Position | |---|---|---|---|---|---| | Front Left | Hip | FL-HIP | Follow official docs | To verify | To calibrate | | Front Left | Thigh | FL-THIGH | Follow official docs | To verify | To calibrate | | Front Left | Calf | FL-CALF | Follow official docs | To verify | To calibrate | | Front Right | Hip | FR-HIP | Follow official docs | To verify | To calibrate | | Rear Left | Hip | RL-HIP | Follow official docs | To verify | To calibrate | | Rear Right | Hip | RR-HIP | Follow official docs | To verify | To calibrate | This table is not paperwork. It binds mechanical placement, wiring, software coordinate frames, and debugging records together. If one leg moves in the wrong direction later, this table helps isolate whether the issue is ID mapping, motor direction, zero position, or control output. Calibration is a hard gate before real locomotion. A 12-DOF quadruped cannot rely on a rough “looks close enough” mechanical pose. Recommended calibration order: Before standing, answer these questions: If these questions are not answered, entering RL mode is not responsible engineering. After mechanical assembly, power, Jetson, ROS 2, IMU, CAN, and actuator mapping all pass validation, the robot can enter reinforcement-learning locomotion testing. Recommended first run: The goal is not to run fast on the first attempt. The goal is to create a repeatable test procedure. After every run, record: Only with enough test records can you responsibly tune policies, change mechanics, adjust parameters, or optimize gait behavior. Actuator direction is one of the most common bring-up problems. Even if the ID is correct, a reversed direction makes the policy output the wrong physical motion. Each joint should be tested independently with a small command. Use a small amount of thread locker around actuators, linkages, support posts, and frame joints. Do not overuse it, or later maintenance becomes difficult. Do not skip it either, because long-duration locomotion can loosen fasteners. Cables should not sit close to rotating joints, pass through crush zones, or rely on connectors to absorb pulling force. CAN, power, USB, and antenna cables all need fixed routing points. Emergency stop is not decorative. Validate it before the first actuator enable. If a quadruped fails during standing, human reaction time is usually not enough. CAN bus issues often appear as intermittent motion loss or one joint dropping offline. Check bitrate, termination, cable length, loose connectors, USB-CAN driver behavior, and device permissions. LoRa is useful for longer-range operation in open areas. For indoor or short-range bring-up, a local remote controller or ROS 2 control interface is usually more convenient. Do not assume the long-range link is stable in a closed or cluttered environment. Jetson runs ROS 2, drivers, and the RL policy at the same time, so power and cooling matter. Poor cooling can cause throttling. Unstable power can cause random reboots or peripheral dropouts. | Problem | Check First | |---|---| | No power-on | Battery, power button, emergency stop, BMS, main board input | | Cannot log into Jetson | First boot via HDMI, IP address, Ethernet/Wi-Fi, SSH service | | SSH disconnects often | Wi-Fi driver, power stability, Jetson temperature, network quality | | No IMU data | USB connection, device node, permissions, driver, ROS 2 topic | | CAN device unavailable | USB-CAN driver, enumeration, bitrate, permissions | | One actuator does not respond | ID, power, CAN wiring, control mode, parameter reload | | Shaking during standing | Zero position, direction, IMU attitude, leg interference, control gains | | Wrong forward direction | Body coordinate frame, remote mapping, joint direction, policy input | | Turning behaves incorrectly | Left/right leg mapping, yaw command direction, IMU frame | | Outdoor test is unstable | Ground friction, grass resistance, battery level, communication distance, actuator temperature | Do not change multiple variables at once. Quadruped failure chains are long. If you change wiring, ID mapping, policy, and remote mapping simultaneously, it becomes hard to know which change actually fixed the issue. After completing the process above, NavBot-D1 should have the following capabilities: More importantly, the developer now has an extensible quadruped platform. The next steps can include local development tooling, simulation, reinforcement-learning training, perception modules, navigation modules, and remote operation systems. If you plan to reproduce or extend NavBot-D1, I recommend the following priorities: NavBot-D1 matters because it provides a sufficiently complete real robot platform. It has mechanical complexity, onboard compute, and RL locomotion. It supports hardware integration, software control, and simulation research. For robotics developers, this kind of platform is ideal for building end-to-end engineering capability across CAD, BOM, wiring, ROS 2, CAN, calibration, and policy deployment. Video Source: https://youtu.be/Raj1pK31hU4 https://youtu.be/Raj1pK31hU4 , or watch it right here. The post Building NavBot-D1: From Parts, Jetson, and ROS 2 to Reinforcement-Learning Locomotion https://frankfu.blog/openai/building-navbot-d1-from-parts-jetson-and-ros-2-to-reinforcement-learning-locomotion/ appeared first on Frank Fu's Blog https://frankfu.blog .