RoboParty ROBOTO ORIGIN Quick Start

ROBOTO ORIGIN is a highly dynamic biped robot. Before starting the real robot, safety requirements must always come first.

• You have read and understood the official Safety Operation Guide, Product Disclaimer, and Safety Notice.
• During first zero calibration, reset, and inference tests, the robot must use a reliable load-bearing suspension or safety rope.
• The battery voltage must not be lower than 50 V. If it is below this value, charge the battery first and do not continue debugging.
• The ankle links, main fasteners, limit parts, and wiring have no looseness, interference, or wear.
• The gamepad is paired, is in XInput mode, and the X button can be used to enable or disable the motors.
• Someone on site is ready to trigger emergency stop at any time. If the software loses control, prioritize the physical emergency stop to cut off main power.

New users should prioritize the V2.0 hardware materials. V2.0 is the currently recommended version. Compared with V1.0, it adds improvements such as structural reinforcement, an integrated board, waist limit parts, pin calibration, and a backplate switch. V1.0 is mainly for maintenance by existing users, and new reproduction projects are not recommended to start from V1.0.

If your goal is to run the real robot as quickly as possible, the RDK X5 route is recommended first.

1. Prepare the RDK X5, an SD card, two Type-C cables, RDK Studio, and the RDK X5 system image provided by RoboParty.
2. Follow the RDK X5 flashing process to enter flashing mode, then select the correct storage device in RDK Studio and flash the image.
3. After flashing, restart the main controller and create a device connection through RDK Studio.

The default username and password are usually both:

When debugging ROS 2 DDS and high-volume logs, Ethernet is recommended. The commonly used addresses in the official documentation are:

If SSH reports a host key conflict, clear the old record on the PC:

Orange Pi 5 Plus requires Ubuntu 22.04 and the 5.10 real-time kernel. After pulling the deployment repository, run the following commands in the repository root:

After installation, restart the main controller before continuing with real-time permission configuration.

Ethernet is also recommended when debugging Orange Pi 5 Plus. Connect the Orange Pi 5 Plus and the debugging PC to the same wired network, or configure both devices with fixed IP addresses in the same subnet. Check the Ethernet address on Orange Pi with ip a, then connect from the PC:

After installing Git on the main controller, pull the real-robot deployment repository and initialize its submodules.

After cloning, read the repository README first. This page keeps only the quick-start path; script names and dependency versions should follow the latest roboparty_deploy README. After installing ROS 2 Humble, install the deployment dependencies:

Configure real-time permissions:

Add the following two lines to the end of the file. Replace the username with the current main controller user. The default RDK X5 user is sunrise, and a common Orange Pi user is orangepi.

After restarting, verify the configuration:

If the output is 98, the real-time priority configuration is successful.

Before connecting the hardware, finish setting the motor IDs, IMU baud rate, and IMU frequency. For motor ID definitions, refer to the Product Installation Manual and the Damiao Motor Step-by-Step Debugging Process document, then write the IDs with the Damiao host software or the corresponding hardware vendor's host software. For robot wiring, refer to the Wiring Instructions.

• Default IMU baud rate: 921600.
• Default IMU frequency: 500 Hz.
• If you change to another frequency, it is recommended to keep it above 200 Hz.
• If you change the IMU baud rate, update src/inference/config/robot.yaml accordingly.

The default CAN mapping is shown below. The numbering follows the order in which USB-to-CAN devices are connected to the main controller:

Recommendations:

• Connect USB-to-CAN devices to USB 3.0 ports or a USB 3.0 hub.
• Connect the IMU and gamepad to USB 2.0 ports.
• Prefer using udev rules to fix device mapping and avoid CAN numbering changes caused by plug-in order. However, the repository-provided rules can be used directly only when the actual wiring is consistent with the Wiring Instructions.

If you only need to debug CAN manually, use:

In actual use, complete the configuration for can0, can1, can2, and can3.

Using the udev rules in the repository is recommended. RDK X5 uses 99-auto-up-devs-sunrise.rules, and Orange Pi uses 99-auto-up-devs-orangepi.rules. If the actual USB ports, hub, or wiring differ from the Wiring Instructions, use udevadm monitor to confirm the KERNELS value first, then update the rule file instead of applying the default rule directly. Example:

After restarting, check whether CAN is automatically brought up:

After first assembly, maintenance, motor replacement, or zero-position loss, zero calibration must be performed again. During zero calibration, the robot must be suspended, and its posture should be as close as possible to the zero position required by the official documentation.

• After manually moving the current motor to the zero position, press Enter to write the zero position.
• If the current motor zero position is already correct, press Space to skip it.
• Do not let the robot leave the suspension during calibration.

When the software has started and the motors have been initialized, you can also write the current zero position through ROS 2 services:

For first assembly, scripts/set_zero.py is still recommended because it is more suitable for manually confirming each motor one by one.

• The robot is still suspended or protected by a safety rope.
• The battery voltage is normal.
• Emergency stop is reachable.
• CAN, IMU, and gamepad are all connected.
• The motor_zero_offset in src/inference/config/robot.yaml matches the actual calibration method.

About the zero offset of waist yaw:

• If waist yaw was rotated to the limit block for calibration, keep the default offset value.
• If a printed part was used to fix waist yaw during calibration, set the corresponding offset to 0.0 as required by the deployment documentation.

The script automatically builds the workspace and starts background screen sessions:

Recommended first startup sequence:

1. Keep the robot suspended and start ./tools/start_robot.sh.
2. Check screen -r inference_session and confirm that the inference node has no obvious errors.
3. Press X to enable the motors and confirm that the motor lights and states are normal.
4. Press A to reset the joints and confirm that the robot posture is normal.
5. Slowly lower the suspension so the feet touch the ground while protection remains in place.
6. Press B to start inference. The operator should be ready to press X or trigger the physical emergency stop at any time.

1. Reconnect the suspension or safety rope.
2. Press X to disable the motors.
3. After confirming that the robot is stable, cut off the main power.

If you want to write scripts to control the hardware, first complete the build and source the environment:

The deployment repository provides three Python modules:

Common ROS 2 services:

In addition to basic deployment and real-robot startup, ROBOTO ORIGIN provides several application and extension modules for reference. This section mainly explains that each module exists, what it can roughly do, and where to look. For detailed installation, configuration, runtime commands, and parameters, refer to the corresponding repository or module README.

If this is your first time starting the robot, you do not need to read all these modules immediately. It is recommended to first complete environment setup, zero calibration, and startup according to this article. After confirming that the robot can run stably, choose the corresponding README for deeper study based on your goal.

Check whether the username in /etc/security/limits.conf is wrong. The default RDK X5 user is usually sunrise, and a common Orange Pi user is orangepi. Restart after making changes.

First check whether the USB-to-CAN device is recognized by the system:

If using udev rules, check whether the rule file has been copied to /etc/udev/rules.d/, then reload the rules and reconnect the device.

Check the following first:

• Whether CAN_H / CAN_L are reversed.
• Whether the 120 ohm termination resistors at both ends of the bus are correct.
• Whether the baud rate is 1 Mbps.
• Whether the CAN mapping matches the actual wiring.
• Whether the motor IDs match the configuration file.

Immediately press X to disable the motors, and use the physical emergency stop if necessary. Then check:

• Whether the zero position is correct.
• Whether motor_zero_offset matches the calibration method.
• Whether screen -r inference_session shows error logs.
• Whether the battery voltage and motor error codes are normal.
• Whether joints, links, or wiring have mechanical interference.

If the main controller has been reinstalled, the PC may have stored an old host key. This page recommends Ethernet debugging first. For RDK X5 Ethernet, clear the Ethernet address. If you actually use the board Wi-Fi hotspot, clear the hotspot address instead:

ROBOTO ORIGIN is the main repository and snapshot aggregation repository, making it convenient to pull all resources at once. Module-level issues, code changes, and PRs should be submitted to the corresponding sub-repositories instead of all being placed in the main repository.

Current materials may still contain legacy path identifiers. The product name is standardized as RPO; runtime deployment is roboparty_deploy, hardware materials are rpo_hardware, training materials are roboparty_train, and robot description is rpo_description.