Use when integrating Aria Gen 2 sensor streams with ROS2 – publishing raw Aria sensor data through ROS2 topics, decoding it in subscriber nodes, sharing device calibration across nodes.
Use when integrating Aria Gen 2 sensor streams with ROS2 - publishing raw Aria sensor data through ROS2 topics, decoding it in subscriber nodes, sharing device calibration across nodes.This is the skill's description: the text your AI reads to decide when the skill applies.
aria-client-sdk-ros2-integration/SKILL.md
---
name: client-sdk-ros2-integration
description: Use when integrating Aria Gen 2 sensor streams with ROS2 — publishing raw Aria sensor data through ROS2 topics, decoding it in subscriber nodes, sharing device calibration across nodes. The integration uses a custom `AriaRaw` message (a thin FlatBuffer wrapper) and a required `aria_data_types` package name. Use whenever the user asks about Aria + ROS2, publishing Aria data to topics, or building ROS2 nodes around Aria sensors.
---
# Aria + ROS2 Integration
The Client SDK ships an example ROS2 publisher / subscriber pair that streams raw Aria sensor data through ROS2 topics. Sensor messages stay in FlatBuffer format end-to-end — a thin custom message type (`AriaRaw`) carries them on the wire, and the SDK's data converter decodes them in the subscriber.
> Reference + full code walkthrough: https://facebookresearch.github.io/projectaria_tools/gen2/ark/client-sdk/python-sdk/ros2-example
## Why a custom message type
Aria streams data in FlatBuffer format. Re-encoding into standard `sensor_msgs/*` types would:
1. Lose timing precision — nanosecond timestamps survive better in raw bytes.
2. Force one publisher per sensor type — Aria has many sensors, that's a lot of plumbing.
3. Break when new sensor types are added.
So the example uses **one** `AriaRaw` topic for all sensors, carrying:
```msg
int64 id # SDK message type ID (indicates which sensor / message type)
uint8[] payload # raw FlatBuffer bytes
```