Robot Bringup And Unitree

This page explains how the final system is launched and how ROS navigation commands are turned into physical Go2 motion.

1. Final Entry Point

The practical runtime entry point is:

• robot_bringup/launch/1.launch

This file is the last stage of integration. It brings together:

• the Unitree ROS bridge
• HDL localization
• navigation
• navigation manager
• FAST-LIVO2 sensor and mapping bringup

The project therefore uses one top-level launch file to coordinate the whole stack.

2. Timed Startup Strategy

The launch file does not start every subsystem at the exact same time.

Instead, it uses timed launch includes to stagger startup:

• Unitree bridge
• HDL localization
• navigation
• navigation manager
• FAST-LIVO2 bringup

This is a practical engineering choice. In a multi-package robotics stack, startup timing often matters because:

• services may not be ready immediately
• map and localization nodes may need time to initialize
• navigation should not begin before the supporting layers are available

3. Unitree Bridge

The execution bridge is:

• unitree/scripts/go2_ros_bridge.py

This is a custom wrapper around the Unitree SDK2 Python interface.

It is not just a simple /cmd_vel forwarder.

4. What The Bridge Does

The bridge:

• initializes the Unitree SDK
• selects the network interface
• subscribes to /cmd_vel
• converts ROS velocity commands into Unitree movement commands
• applies velocity limits
• applies minimum velocity thresholds and deadbands
• runs a watchdog timeout
• performs a startup sequence
• controls the LiDAR power state through the Unitree DDS path

This means the bridge is both:

• a motion interface
• a safety/control wrapper

5. Execution Safeguards

Several FYP-specific behaviors make the bridge more practical than a raw SDK example.

5.1 Velocity Limits

The script defines:

• max forward velocity
• max lateral velocity
• max angular velocity
• minimum effective velocities
• deadbands for near-zero commands

This prevents tiny noisy commands from constantly moving the robot and bounds the command space sent to the Go2.

5.2 Watchdog

The script also implements a timeout watchdog.

If /cmd_vel stops arriving for too long, the bridge sends stop commands.

This is a critical runtime safety behavior and an important difference from a naive ROS-to-SDK adapter.

6. Startup Sequence

The bridge contains a startup sequence that is clearly customized for this robot:

• switch LiDAR off first
• stand down
• recovery stand
• switch to free walk

This is not generic ROS behavior. It is deployment-specific control logic for the Unitree Go2.

7. LiDAR Power Control

The bridge also publishes DDS commands for LiDAR switching.

Here, the LiDAR being switched is the Go2’s built-in LiDAR, not the external Livox MID-360 used by the FYP mapping pipeline.

Turning off the built-in Go2 LiDAR also disables the dog’s built-in obstacle avoidance, which is useful during stair climbing so the robot’s own avoidance logic does not interfere with the custom stair behavior.

This has no direct relationship to the external Livox MID-360 used elsewhere in the project.

8. Why These Changes Were Needed

Using the upstream Unitree SDK examples directly would not be enough for this FYP because the project needs:

• a ROS topic interface
• safe command limiting
• watchdog-based stopping
• a repeatable startup sequence
• control over the Go2 built-in sensor/avoidance behavior during operation

So the local bridge exists to make the Go2 behave like a controllable endpoint of the ROS navigation system.

9. Relationship To The Full Mission

The navigation stack can compute paths and the multi-floor manager can decide where to go, but none of that matters unless the robot can actually execute those commands safely.

That is the role of:

• robot_bringup
• unitree

They turn the rest of the codebase from a software pipeline into a physical robot workflow.