ROS 2 Adapter

The ROS 2 adapter subscribes only to status frames from the information hub and consumes their shared MocapState. It does not listen on IMU UDP ports and does not duplicate calibration, common-timeline, or claw solving.

Start

Start the information hub first. To publish IMU and skeleton data at roughly 50 Hz, set the status frame rate to 50 Hz too:

python3 SOFTWARE/信息中枢/mocap_ws_hub.py --status-hz 50

In a terminal where ROS 2 has been sourced:

source /opt/ros/<distro>/setup.bash
python3 -m pip install -r SOFTWARE/信息中枢/requirements.txt
python3 adapters/ros2/mocap_ros2_node.py

Outputs

  • /motion_tracker/state_json (std_msgs/String): full MocapState JSON.

  • /motion_tracker/control_json (std_msgs/String): yaw, roll, pitch, distance, z, claw, calibration state, and synchronization quality.

  • /motion_tracker/imu/<node_id> (sensor_msgs/Imu): raw node quaternion; offline nodes are not published.

  • /motion_tracker/skeleton/{shoulder,elbow,wrist,palm,fingertip} (geometry_msgs/PoseStamped): skeleton point positions.

  • tf2: body_rh -> shoulder -> elbow -> wrist -> palm -> fingertip.

Every Imu, PoseStamped, and tf header.stamp is strictly derived from frame_time_ns. When the common timeline is invalid and frame_time_ns=null, the adapter publishes only JSON state/control; it never substitutes WebSocket receive time or solved_time_ns as a ROS timestamp.

The body_rh axes remain X forward, Y left, Z up. The ROS adapter performs no axis inversion.

ROS 1 Boundary

This repository has no required ROS 1 integration, so it does not ship a second ROS 1 mocap core. If ROS 1 becomes necessary, its bridge must subscribe to information-hub JSON state or bridge this ROS 2 node. It must not reopen IMU UDP sockets, copy human calibration, or change MocapState numeric semantics.