BotBrain: a ROS 2 web brain for Unitree Go2, G1 and Tita robots

What BotBrain actually replaces on a legged robot

Getting a quadruped to walk is the easy part. The hard part is everything around it: a teleoperation view with low enough latency to steer, a map that survives a room change, a waypoint runner that stops when the battery drops, and a health panel that tells you whether the Jetson is thermal throttling or the WiFi dropped. Teams usually assemble that from separate ROS 2 packages, a Foxglove or rviz session, and a shell script that launches nodes in the right order.

BotBrain is a single repository that ships those pieces together. The README describes it as a modular collection of open source software and hardware components for driving, seeing, mapping, navigating, monitoring and managing legged or wheeled ROS 2 robots from a web UI. The audience is narrow and identifiable: people who own a Unitree Go2, Go2-W, G1 or DirectDrive Tita, or who are willing to write a package for their own ROS 2 platform. The repository lists go2_pkg, go2w_pkg, g1_pkg and tita_pkg as build targets, which is the clearest statement of who this is for.

The second half of the pitch is physical. The hardware directory holds 3D-printable mounts and an enclosure designed around the Intel RealSense D435i and the NVIDIA Jetson line, with snap-fit adapters for Go2, G1 and Tita. The README claims a robot can be running with BotBrain in less than 30 minutes, which is a claim about assembly, not about software configuration.

How the modules fit together: Docker services, CycloneDDS and a state machine

The docker-compose.yaml is the most informative file in the repository. Every service extends a base image, botbotrobotics/botbrain:base, which runs with network_mode: host, ipc: host, privileged: true and the NVIDIA runtime, and reserves all GPUs through the deploy block. That design choice matters: privileged mode plus /dev mounted into the container means the container has direct access to the robot's serial and USB devices, which is what makes a single image work across robots. It also means the container boundary is a packaging convenience, not a security boundary.

Communication is pinned to CycloneDDS. The base service sets RMW_IMPLEMENTATION to rmw_cyclonedds_cpp and CYCLONEDDS_URI to file:///botbrain_ws/cyclonedds_config.xml, so the DDS configuration lives in the workspace rather than in the image. If you change middleware settings, that file is where they belong.

The build is split from the run. The builder_base service runs colcon build --packages-select against an explicit list: go2_pkg, tita_pkg, bot_bringup, bot_description, bot_custom_interfaces, joystick_bot, bot_localization, bot_navigation, bot_localization_interfaces, bot_state_machine, bot_jetson_stats, bot_jetson_stats_interfaces, bot_rosa, g1_pkg and go2w_pkg. The naming shows the layering: a bringup package, a description package, custom interfaces, then localization, navigation, state machine and Jetson stats as separate units.

The runtime services are one process group per concern. state_machine runs ros2 launch bot_state_machine state_machine.launch.py, bringup runs bot_bringup bringup.launch.py, and localization runs bot_localization localization.launch.py, each with restart: always. The README describes priority-based velocity control with six levels of arbitration where joystick outranks navigation, which outranks AI, plus a dead-man switch and an emergency stop sequence. That arbitration has to sit somewhere, and the state machine service is the plausible home for it.

The frontend is a separate Next.js 15 application in the frontend directory, which is why the repository's primary language is TypeScript despite the ROS 2 core. The README lists CockPit as a fixed control page with front and back camera feeds, a 3D model, the map and quick actions, and My UI as a drag-and-drop dashboard with resizable widgets. Both read from the same backend.

Installing BotBrain on a Jetson and reaching the web UI

The repository ships install.sh at the top level and two systemd units, botbrain.service and web_server.service, so the intended deployment is a Jetson that starts the stack on boot. The README does not spell out the install sequence in the excerpt available here, so treat install.sh and the service files as the source of truth and read them before running anything.

The container workflow is documented through docker-compose.yaml. The dev service is defined to extend base, set user: root and override the command to bash, so it drops you into an interactive shell where /botbrain_ws maps to the repository's botbrain_ws directory and /dev is passed through. Its command is the one shown in the compose file:

command: ["bash", "-lc", "bash"]

The build is a separate service. builder_base extends base and runs colcon build --packages-select with the fixed package list, so running it produces an install directory inside the mounted workspace. Its command, as written in the compose file, is:

command: ["bash", "-lc", "colcon build --packages-select \
      go2_pkg \
      tita_pkg \
      bot_bringup \
      bot_description \
      bot_custom_interfaces \
      joystick_bot \
      bot_localization \
      bot_navigation \
      bot_localization_interfaces \
      bot_state_machine \
      bot_jetson_stats \
      bot_jetson_stats_interfaces \
      bot_rosa \
      g1_pkg \
      go2w_pkg"]

The long-running services each source install/setup.bash and launch their own file. The bringup service, for example, uses this command from the compose file:

command: ["bash", "-lc", "source install/setup.bash && ros2 launch bot_bringup bringup.launch.py"]

Each of those services is set to restart: always. The README does not document a rollback path if a launch file fails, so keep the previous workspace if you are upgrading in place.

Once the backend is running, the web server is the Next.js frontend in frontend/, started by web_server.service on the device. The README shows the entry points as CockPit, My UI, Missions and Health, and the first real task is usually opening CockPit, confirming the camera feeds and the 3D model, then using click-to-navigate on the map to send a single goal before building a multi-waypoint mission.

Where BotBrain stops being the right tool

The README is explicit that the perception layer is not finished. YOLOv8/v11 object detection with TensorRT optimization, detection history with image logging, and ROSA natural-language control are all labelled coming soon. If object detection is the reason you are looking at a robot brain, this repository does not deliver it yet, and the README says so rather than hiding it.

Hardware scope is the second boundary. The supported boards are Jetson Nano and Jetson Orin Nano, with AGX and Thor described as coming soon, and the README notes that some heavy AI modules require Orin AGX. That is a contradiction worth reading carefully: the board that would run the heavy modules is not on the officially supported list yet. Sensors are assumed to be Intel RealSense D435i, used for viewing and for SLAM and navigation, and the mounts are cut for that camera. A different depth camera means new mounts and probably changes to the localization configuration.

Robot support is a hard list, not a general promise. Unitree Go2 and Go2-W, Unitree G1 with upper-body pose control and FSM transitions, and DirectDrive Tita are wired up. The README calls the framework extensible for custom ROS 2 platforms, but extensibility here means writing a package in the style of go2_pkg and adding it to the colcon build list, which is real work.

Finally, the deployment model assumes a dedicated machine. privileged: true, host networking, /dev passthrough and the NVIDIA runtime are all reasonable on a robot's onboard computer and wrong on a shared server. The README does not document a multi-tenant or cloud deployment, and the docker-compose.yaml gives no indication that one is intended.

BotBrain against rolling your own ROS 2 stack

The alternative most teams actually weigh is not another product but the manual assembly: Nav2 and RTABMap launched from your own files, rviz or Foxglove for visualization, and a hand-written node for the robot's SDK. That path gives you exactly the nodes you want and nothing else, and it is the right answer if you already have a working bringup and only need one more capability.

The difference in approach is orchestration versus composition. BotBrain's value is in bot_state_machine, bot_bringup and the lifecycle ordering that the README describes as coordinated node startup and shutdown with dependency ordering, plus the six-level velocity arbitration and the dead-man switch. Those are the parts that are tedious to write and easy to get subtly wrong, and they are the parts the docker-compose services encode as separate restartable units. The cost is that you inherit the package structure, the CycloneDDS configuration and the Docker assumptions.

A second alternative is the vendor's own application. Unitree ships control software for the Go2, and for basic walking and camera viewing it works without any additional hardware. BotBrain's argument over that is the mapping and mission layer, the health panel that reads Jetson stats, and the fact that the same UI covers Go2, G1 and Tita. If you only ever own one Go2 and never map anything, the vendor tooling plus a manual joystick session covers more of your day than BotBrain does.

Maintenance, licensing and the upgrade question

The repository is MIT licensed, and the LICENSE file sits at the top level. MIT is permissive: you can modify, redistribute and use the code commercially, provided the copyright notice and permission notice are retained. The hardware files under hardware/ fall under the same repository licence unless the directory states otherwise, which is worth checking before you print and sell mounts. Nothing here is legal advice; read the licence text and any per-directory notice yourself.

The last push to the default branch was on 2026-06-16, which is three months before today. That is recent enough that the project is not abandoned, but the README does not publish a release cadence or a support window, and no releases were retrieved. Upgrades are the real cost. Because the stack runs as Docker services built from botbotrobotics/botbrain:base with a fixed colcon package list, a version bump can move the base image and the workspace at the same time. The repository does not document a rollback procedure, and the services are set to restart: always, so a broken launch file will loop rather than fail visibly.

Practical upgrade hygiene follows from the files themselves: pin the base image tag rather than tracking it, keep botbrain_ws under version control separately from the image, and re-run the builder_base service after pulling so the install directory matches the new sources. The cyclonedds_config.xml inside the workspace is part of what you are versioning, since CYCLONEDDS_URI points at it.

Editorial conclusion

Adopt BotBrain if you already own a Unitree Go2, Go2-W, G1 or DirectDrive Tita and a Jetson Orin Nano or Nano with a RealSense D435i, because those are the platforms the repository actually wires up. Skip it if you need YOLO detection or ROSA natural-language control today, since the README marks both as coming soon, or if your robot is not one of the four supported models and you do not want to write a new hardware package. Before buying hardware, open botbrain_ws and confirm a package exists for your robot, then check whether the launch files under bot_bringup match your firmware, because the README does not document rollback or a version compatibility matrix.

Frequently asked questions

Official sources

1. botbotrobotics/BotBrain on GitHub
2. Issues
3. License: MIT
4. Project website
5. README