Skip to content

Animation, support services and monitoring

Blender animation runtime

The unified ROS image carries the Blender runtime source at /opt/hansonrobotics/tools/blender. Configuration supplies the selected character/robot assets. The main launch enables Blender separately from the ROS nodes that publish animation requests; a running animation publisher does not establish a functioning Blender sink.

Animation requests include expression, gesture, arm-animation, head tilt, face target, gaze target and viseme/cancel channels. The generated PAU state feeds physical actuator mappings and the Unity streamer. Keep virtual rig tuning and physical motor calibration separate even when they consume the same animation state.

The launch's enable_blender and blender_background settings control process selection. Diagnose missing assets, import errors and frame rate before changing motor settings to compensate for an animation problem.

ROS support nodes

Node/function Responsibility and operational consequence
robot_state_publisher Publishes robot geometry/TF from the selected robot description
Camera angle transform publisher Computes camera transform from defaults/motor angle or IMU; can also command the configured camera motor
arms_control Arm configuration/control integration; can drive physical behavior
arms_alive Optional ambient arm motion, off by default in main launch
Favorite animations Selects configured animation options
TTS suggestions Supplies operator speech suggestions
Language detector Text language detection service
WebSocket streamer Publishes animation packets to Unity clients

The support-node reference enumerates ROS registrations, source locations and exact parameter expressions. Each node's activation is controlled by current launch/configuration; the main launch has separate enable flags rather than one switch for every support service.

Camera transform detail

The camera angle node subscribes to /hr/sensors/vision/realsense/camera/imu and publishes a transform from realsense_mount to realsense. It smooths five IMU samples when IMU mode is enabled; otherwise it combines default angle with motor angle and scale. Configuration namespace is /hr/perception/camera_angle.

It also publishes TargetPosture to /hr/actuators/pose for the selected camera motor, initially/config-change and periodically. The default motor name is Camera; absence of that configured motor causes a warning and skipped motion publication. This is not a read-only transform node. Its IMU topic differs from perception's color/depth topic namespace; verify the active sensor topics rather than assuming all RealSense streams share a prefix.

QoS and graph tools

The platform helpers use best-effort, volatile, keep-last for ordinary and sensor/stream topics. The named retained-state profile is best-effort, transient-local, depth one. ROS services use default service QoS. Subscriber reliability/durability must match publisher capabilities.

ros2 node list
ros2 node info /NODE_NAME
ros2 topic list -t
ros2 topic info -v /TOPIC_NAME
ros2 service list -t
ros2 action list -t

These commands inspect the graph; they do not establish physical response. Use appropriate network/domain settings and installed message definitions on the inspecting machine.

Monitoring surfaces

Use the System Console for host CPU/memory/disk, systemd status, audio/network/USB and Jetson management. Use Robot WebUI's monitor status for adapter/robot alerts and Blender/runtime information. Health, graph discovery, provider state and hardware feedback are independent checks.

The current WebUI monitor filters active alert types and excludes some source templates that are not part of its active ROS 2 monitoring path. Do not treat a template string in source as a guaranteed emitted alert. Inspect the current monitor.status result for the deployment.

The unified Dockerfile explicitly builds ten ROS packages. The documentation's ROS reference follows that build selection plus current perception, rather than assuming every source directory is installed. WebUI and Blender are included through their separate image/runtime paths.

Persistent data services

Current deployment Compose includes Redis, MongoDB and MySQL with named volumes. Redis stores live configuration/parameters and supports runtime coordination. MongoDB/MySQL serve enabled conversation/data functions. Defaults in an example Compose are not a production access-control policy. Host-networked database listeners and published ports must be reviewed in the real deployment.

Back up databases consistently with their engine, retain configuration/stack metadata alongside them, and test restore to an isolated environment. Do not assume a file copy of a running database volume is a valid consistent backup.

Evidence: head-ros-nodes/Dockerfile, ros/hr_ros2/{launch/interaction_stack.launch.py,src/hr_ros2/qos.py}, ros/ros_misc/nodes, ros/webui/api/webui_api/monitoring.py, and hrsdk_configs/main.yaml.