Wheeltec R550 mini_tank

Robonix deployment for the SysWonder Wheeltec R550 mini_tank: Jetson Orin, LSLIDAR N10P, Orbbec Astra S, RTAB-Map, Scene, Nav2, and VLM pilot.

The deployment uses native ROS 2 packages on Jetson. Each package entry selects its own package_manifest*.yaml, so architecture and native/container choices are package properties rather than global environment variables.

Hardware

The exact provider IDs, device addresses, sensor profiles, and runtime options are defined in robonix_manifest.yaml. The robot body, component hierarchy, footprint, and provider-to-component mapping are defined in soma.yaml.

Robot-specific algorithm configuration is also deployment-owned:

• config/rtabmap_params.yaml contains the full R550 RTAB-Map parameter set.
• config/param_mini_tank.yaml contains the complete R550 Nav2 configuration.
• config/navigate.xml contains the R550 navigation BehaviorTree.
• urdf/mini_tank_robot.urdf is the kinematic model consumed by robot_description. The manifest references this deployment asset through absolute path so a clone does not depend on a cache path or another checkout.

The manifest references these files with paths relative to this repository. The Mapping and Navigation provider repositories contain templates only; do not move R550 dimensions, sensor limits, or controller policy upstream.

Package target selection and algorithm configuration are separate. A package's manifest: chooses a build/start implementation such as Jetson native or a container. Robot-specific runtime values remain in this repository's parameter files (or documented config overrides) and do not create a new upstream profile.

Scene is pinned to the front Astra S provider astra_s_camera. That provider supplies RGB, depth, and camera intrinsics for visual scene queries. Scene obtains the robot's globally corrected pose from the Mapping robonix/service/map/pose contract and combines it with the complete URDF camera transform published by robot_description.

Prepare

# 1. Install Robonix toolchain
cd ~/robonix
git switch dev
git pull --ff-only origin dev
make install

# 2. Install ROS 2 system dependencies
sudo apt install ros-humble-rtabmap-ros \
  ros-humble-navigation2 ros-humble-nav2-bringup \
  ros-humble-imu-filter-madgwick

# 3. Source the Wheeltec ROS 2 workspace
source ~/wheeltec_ros2/install/setup.bash

Set VLM credentials in your shell before boot (or edit boot.sh):

export VLM_BASE_URL="https://your-llm-endpoint/v1"
export VLM_API_KEY="sk-..."
export VLM_MODEL="qwen-vl-max"

Build and boot

bash boot.sh

The wrapper sources ROS Humble, runs pre-flight checks (rbnx CLI, ROS 2, turn_on_wheeltec_robot, rtabmap_slam, imu_filter_madgwick), and then execs rbnx boot -f robonix_manifest.yaml. --no-build skips the build step for repeated boots. --shutdown tears down a running stack.

Operator pages:

• Mapping: http://<robot-host>:8091/
• Liaison for Robonix Client: <robot-host>:50081

RViz

The deploy keeps a complete RViz configuration with laser scans, map, costmap, TF tree, and robot model displays.

source /opt/ros/humble/setup.bash
rviz2 -d config/wheeltec.rviz

Safety and bring-up order

The checked-in full manifest includes the chassis, lidar, camera, mapping, and Nav2; starting it exposes physical motion capabilities. Keep the hardware emergency stop available and clear the workspace before full bring-up.

After the chassis is powered on:

1. Verify odometry is publishing: ros2 topic hz /odom_combined
2. Send zero Twist and confirm the watchdog holds the base stopped.
3. Use a low-speed, short-duration command in a clear area.
4. Verify Mapping pose and Nav2 costmaps before sending a nearby goal.

Robot description

soma.yaml and urdf/mini_tank_robot.urdf are served by Soma. The description contains the body footprint and sensor tree used by Pilot and other consumers. Mount transforms remain calibration-sensitive; update the body URDF after physical measurement rather than compensating in Scene or Mapping.

The component tree in soma.yaml nests sensors under their physical mount:

base (mobile_base, base_link)
  ├── lidar (lidar_2d, laser)
  ├── imu (imu, gyro_link)
  └── front_rgbd (rgbd_camera, camera_link)

Capability contracts

Provider dependency graph

robot_description                     ← no deps, must boot first
    │  /robot_description (URDF) → TF tree
    ▼
r550_chassis                          ← needs /robot_description for joint states
    │  /odom_combined  /imu_data  /cmd_vel
    │  TF: base_footprint → base_link, base_footprint → gyro_link
    │
    ├──► n10p_lslidar                 ← needs base_link TF
    │       /scan (LaserScan, frame_id=laser)
    │
    └──► astra_s_camera               ← needs camera_link TF
            /camera/color/image_raw   /camera/depth/image_raw
            + snapshot MCP tools
            │
            ├──► mapping              ← lidar2d + odom
            │       /map  /rtabmap/cloud_map  /robonix/map/pose
            │       Web UI → :8091
            │
            ├──► nav2                 ← map + odom + scan
            │       navigation/{navigate, status, cancel}
            │
            └──► scene                ← camera (astra_s_camera)
                    scene/{list_objects, goal_near}

Boot order follows this dependency chain: system caps first (atlas → soma → executor → pilot → liaison → scene), then primitives in declaration order (robot_description → chassis → lidar → camera), then services (mapping → nav2). Services use the Atlas defer-queue: nav2 waits for mapping, which waits for lidar + chassis.

Verification

# Capability status — all non-skill caps should show ACTIVE
rbnx caps -v

# Registered contracts
rbnx contracts

# Sensor health
ros2 topic hz /scan                    # ~10 Hz
ros2 topic hz /odom_combined           # ~30 Hz
ros2 topic hz /imu_data                # ~200 Hz
ros2 topic hz /camera/color/image_raw  # ~30 Hz
ros2 topic hz /camera/depth/image_raw  # ~30 Hz
ros2 topic hz /map                     # ~1 Hz

# Pose
ros2 topic echo /robonix/map/pose --once

# Chat
rbnx chat