Message layouts

What every element of every ExoStack message means, with its standard type and an example.

ExoStack uses only standard message types, so no interface package has to be built, not even for micro-ROS. The meaning therefore lies in the layout: which element of a message carries what. The same Float32MultiArray carries a profile on one topic and a cost on another. Each layout below names its standard type, linked to the official definition, and lists every element.

• Hub message: LaserScan
• Sync trigger: Int32
• Synchronized channels: Float32MultiArray
• Gait event: Int32
• Estimator inputs: Float32
• Assistance profile: Float32MultiArray
• Actuator set-point: Float32
• Profile status: Float32MultiArray
• Manual override: Int32
• Cost: Float32MultiArray
• HIL candidate: Float32MultiArray
• External sensors: Float32MultiArray
• Additional gait marker: Int32

Hub message

One message carries every channel of a board, so the hubs need no custom message type. ESA sets four fields; the others keep their defaults.

header:
  stamp: {sec: 12, nanosec: 340000000}     # 12.34 s since the last /sync_trigger
  frame_id: ''
range_min: 5.0                             # devices: 2 IMUs, 2 load cells, 1 FSR
range_max: 21.0                            # channels
intensities: [4.1, -12.6, 87.0, ...]       # 21 values, in device-list order

Sync trigger

A time reference rather than data: the value is not read.

data: 0

Synchronized channels

The channels of every hub listed in sensors.yaml, concatenated hub by hub in the file's order, each hub's channels in its sensors order. Algorithms never index this array: they ask for [hub, channel] pairs and SensorUtil finds the index.

Index map with the shipped sensors.yaml

Two hubs, hubl on /hub_left and hubr on /hub_right, publish the same 21 channels, so /synced_sensors carries 42 values.

data: [3.2, -1.4, 0.6, ..., 41.8, 0.0, 2.9]    # 42 values

Gait event

A pulse: one message per detected event, nothing in between.

data: 1

Estimator inputs

Three scalar inputs share this layout; their meaning comes from the topic they are sent on.

data: 3.5

Assistance profile

The profile the planner plays after the next gait event. Its first and last elements frame what the builder produced.

What the builders put in the body

List builders add the default value 20 at the start and end of the window. The input is a lookup-table row in Deployment or the candidate's parameters in HIL.

In v1.0, type-2 profiles do not run (see Known limitations).

data: [0, 1, 50, 50, 20, 200, 500, 600, 500, 800, 20, 800, 0]
# k = 0 (Deployment), type = 1 (list), start = 50
# waypoints (t, value): (50, 20) (200, 500) (600, 500) (800, 20)
# end = 800, stop = 0

Actuator set-point

The only message an actuator receives. The actuation hub keeps the latest value per actuator and applies it in every actuate().

data: 412.5

Profile status

Sent at every gait event, it tells the cost evaluator which candidate is being played and how many cycles of it have passed.

data: [3.0, 4.0]      # candidate 3, fourth gait cycle

Manual override

Two topics per planner let you drive the actuator by hand, e.g. to test it. The command shares the Float32 set-point layout.

ros2 topic pub --once /right_hip_extension/manual_mode std_msgs/msg/Int32 "{data: 1}"
ros2 topic pub --once /right_hip_extension/manual_cmd  std_msgs/msg/Float32 "{data: 150.0}" 

Cost

One message per evaluated candidate.

data: [3.0, 27.4]

HIL candidate

The next parameter set to try. Its parameters are the builder's inputs, in the order of mean and bounds in hil_hyperparams.

data: [3, 50, 200, 200, 400, 200, 700]
# -> profile node (Builder2_List):  [3, 1, 50, 50, 20, 200, 200, 400, 200, 700, 20, 700, 0]

External sensors

Signals that are not on a hub, e.g. a metabolic system or an EMG amplifier, reach the cost plug-in through this topic.

data: [312.0, 0.84]      # e.g. metabolic power (W), respiratory quotient

Additional gait marker

A marker for events the cost plug-in needs inside a cycle, e.g. the flexion–extension split.

data: 1