# RoboSkin ROS 2 tactile-array starter kit: message contract, synthetic publisher, and rosbag2 example

**URL:** <https://discourse.openrobotics.org/t/roboskin-ros-2-tactile-array-starter-kit-message-contract-synthetic-publisher-and-rosbag2-example/57650>\
**Category:** Projects\
**Created:** [August 25, 2026, 3:03am UTC](https://discourse.openrobotics.org/t/roboskin-ros-2-tactile-array-starter-kit-message-contract-synthetic-publisher-and-rosbag2-example/57650 "2026-08-25T03:03:41Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![steven\_yang](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/steven_yang/32/35169_2.png) [@steven\_yang](https://discourse.openrobotics.org/u/steven_yang)\
**Post date:** [August 25, 2026, 3:03am UTC](https://discourse.openrobotics.org/t/roboskin-ros-2-tactile-array-starter-kit-message-contract-synthetic-publisher-and-rosbag2-example/57650/1 "2026-08-25T03:03:41Z")

</div>

Hi everyone,

I maintain RoboSkin.ai and have released v0.1.0 of a small Apache-2.0 ROS 2 tactile-array starter kit. The goal is not to propose an official message standard or claim hardware compatibility; it is a hardware-neutral reference for teams that need a typed message contract, a deterministic test stream, and a record/replay path before connecting a real tactile sensor.

It includes:

- an experimental `TactileArray` interface with timestamp, frame and sensor IDs, taxel-grid dimensions, channel names and units, channel-major values, and a validity mask;
- a deterministic synthetic publisher and contract monitor;
- launch parameters and a rosbag2 QoS override example;
- a sample CSV, message-contract documentation, `CITATION.cff`, and dependency-free contract tests;
- a CI build against ROS 2 Lyrical.

Code and v0.1.0 release: [GitHub - roboskin-ai/ros2-tactile-starter-kit: Hardware-neutral ROS 2 tactile array contract, synthetic publisher, rosbag2 QoS, and calibration metadata examples. · GitHub](https://github.com/roboskin-ai/ros2-tactile-starter-kit)

Engineering guide: [ROS 2 Tactile Sensing Pipeline Guide for Robot Skin Data | RoboSkin.ai](https://roboskin.ai/guides/ros2-tactile-sensing)

Evidence boundary: all bundled values are synthetic. The project makes no latency, accuracy, force-range, sampling-rate, robustness, or real-hardware performance claim.

I would particularly value feedback on the message semantics, invalid-taxel handling, channel-major layout, and the QoS and recording defaults.

---

<div class="post-metadata">

**Author:** ![steven\_yang](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/steven_yang/32/35169_2.png) [@steven\_yang](https://discourse.openrobotics.org/u/steven_yang)\
**Post date:** [September 12, 2026, 1:33pm UTC](https://discourse.openrobotics.org/t/roboskin-ros-2-tactile-array-starter-kit-message-contract-synthetic-publisher-and-rosbag2-example/57650/2 "2026-09-12T13:33:34Z")

</div>

A documentation follow-up for anyone moving from the synthetic stream to a physical sensor. I maintain RoboSkin.ai and have added source-linked notes on the acquisition and calibration boundaries for [DIGIT](https://roboskin.ai/sensors/digit) and [ReSkin](https://roboskin.ai/sensors/reskin).

The distinction that matters for this message contract is **raw observation versus calibrated quantity** :

- DIGIT exposes camera frames. A force, depth or slip estimate is a separate processing result; an RGB frame should not acquire force units simply because it comes from a tactile sensor.
- ReSkin exposes magnetic-field measurements and temperature channels. Those channels are not direct force readings or a regular pressure-taxel grid. A bridge needs to preserve their channel meanings and physical layout.

For a hardware bridge, I would record the device and skin identity, acquisition configuration, clock/timestamp convention, channel units, unloaded reference, and calibration/model revision alongside the rosbag. Keep raw and derived outputs distinguishable, and record invalid or missing samples explicitly. A capture rate alone does not establish sensor-to-controller latency.

The two notes link to the original papers and released interfaces, including their maintenance and reuse conditions. They are documentation reviews, not connected-device tests. The starter kit remains a synthetic reference; this update does not establish DIGIT or ReSkin driver support.

If you have used a tactile message contract with mixed image and non-image observations, feedback on where you keep calibration provenance—message fields, a metadata topic, or a recording manifest—would help refine this example.