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

Projects
1

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

Engineering guide: ROS 2 Tactile Sensing Pipeline Guide for Robot Skin Data | RoboSkin.ai

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.

ROS News for the Week of August 24th, 2026
2

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 and 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.