Environment Setup and Installation
1. Runtime assumptions
The current ros_base codebase mainly targets ROS2 Python workflows on Linux. The installation method should match the actual runtime scenario instead of being limited to one environment:
- Desktop development and
sim2simdebugging:RoboStack + Conda/Mambais convenient for isolated environments - Real-robot deployment: system-level ROS2 installation is usually a better fit and should stay aligned with the robot runtime
When launching nodes on a Unitree robot, it is recommended to run setup_id1.sh first. In practice this script usually does two things:
sourcethe system-level ROS2 environment- Set
ROS_DOMAIN_ID=1
This reduces the chance of DDS channel conflicts with the ROS/DDS stack used by the Unitree SDK.
Requirements
- A system-level ROS2 installation, or Miniforge / Mambaforge / another compatible Conda distribution
- Python 3
gittmuxif you plan to useBaseLauncher
Example:
2. Install ros_base
Option A: RoboStack for desktop and sim2sim
A common RoboStack-based setup looks like this:
mamba create -n rosbase python=3.10
conda activate rosbase
mamba install -c conda-forge -c robostack-humble ros-humble-desktop
source $CONDA_PREFIX/setup.bash
If your project uses a different ROS2 distribution, replace humble with the required release.
Then install ros_base:
This setup has several practical advantages:
- The ROS2 runtime stays isolated from the host system.
- It does not occupy a system directory such as
/opt/ros. - Different projects can keep different ROS2 dependency versions more easily.
Option B: system-level ROS2 for real-robot deployment
For real-robot deployment, it is often better to use the system-level ROS2 environment directly and install ros_base on top of it:
source /opt/ros/humble/setup.bash
cd ~/Project
git clone https://github.com/11chens/ros_base.git
cd ros_base
pip install -e .
If the real environment is not humble, or the robot already provides its own initialization script, replace the command accordingly.
For Unitree robots, it is usually better to centralize environment setup in setup_id1.sh, for example:
In practice, these two lines are often wrapped into one script and then sourced first by the launch script or by BaseLauncher.
3. Verify the installation
You can also verify one of the core modules directly:
4. Verify standalone node mode
Use the RealSense camera subscriber as an example. In standalone mode, rclpy must be initialized explicitly instead of running the file as a pure Python class.
This command is useful for quickly checking:
- Whether the ROS2 topic is available
- Whether images are arriving
- Whether standalone mode for
CamSubNodeworks as expected
5. Preview the documentation site locally
If you are maintaining ros_base_doc:
cd ~/Project
git clone https://github.com/11chens/ros_base_doc.git
cd ros_base_doc
pip install -r requirements.txt
mkdocs serve
The documentation site has lightweight dependencies. In practice, only these packages are required:
mkdocs-materialmkdocs-static-i18n