How a single command can unify GelSight, PaXini, Daimon, ToucHD, and 5 other tactile sensor formats into training-ready data.
If you work in tactile robotics research, you've been here before:
A collaborator sends you a dataset collected with a PaXini PXCap force array. Your pipeline expects GelSight .pkl files. Your colleague's LeRobot training code needs Zarr. Someone else is publishing results on a Daimon DM-TacClaw in .parquet format.
Three sensors. Three formats. Three days of writing ad-hoc parsing scripts that you'll delete next week.
Tactile sensing is having a moment β multiple billion-dollar funding rounds in embodied AI have poured attention (and capital) into the field in 2026. But while hardware is advancing fast, data interoperability is still a mess. Every sensor vendor ships data in a proprietary format, and there's no common lingua franca for tactile manipulation datasets.
TLabel is an open-source project that tackles exactly this problem. And with the maturation of its CLI and adapter architecture through v0.18.x, the workflow for converting between tactile dataset formats has gotten dramatically simpler.
What TLabel Actually Does
Before diving into commands, let's set expectations. TLabel is a data pipeline standardization layer. It does not:
Interface with hardware or collect data
Run inference or train models
Replace your training pipeline
It does:
Define a 14-dimension semantic annotation schema (covering contact, force, slip, texture, deformation, and more)
Provide adapter implementations that translate sensor-specific formats into that schema
Export annotated data into training-ready formats (LeRobot, FTP-1 Zarr, JSON, CSV)
Think of it as the Unicode for tactile data β one standard schema, every sensor.
The Adapter Landscape
TLabel currently ships with 12 built-in adapters covering 9 dataset formats and 3 real-time sensor interfaces:
Dataset Adapters (Offline Data )
<> β GelSight Mini / DIGIT, visuo-tactile, .pkl, L3
<> β PaXini PXCap, force array, .h5, L2
<> β Daimon DM-TacClaw, multimodal, .parquet, L3
<> β ToucHD, visuo-tactile, .hdf5, L3
<> β UniVTAC, visuo-tactile, .hdf5, L3
<> β VTouch, visuo-tactile, .h5, L3
<> β YCB-Slide, visuo-tactile, .npy, L3
<> β TacQuad (AnyTouch), multi-sensor, directory, L3
<> β TLabel native, meta format, .json, L1βL4
Real-Time Sensor Adapters
<> β PaXini GEN3, force array, SDK connection, L2
<> β Daimon DM-Tac, visuo-tactile, USB / .avi, L3
<> β PaXini PX6D, 6-axis force, placeholder, L2
That covers the majority of tactile sensors used in manipulation research today.
Getting Started
Install is straightforward:
pip install tlabel
pip install tlabel[gelsight] # GelSight / DIGIT (.pkl)
pip install tlabel[paxini] # PaXini PXCap (.h5)
pip install tlabel[daimon] # Daimon DM-TacClaw (.parquet)
pip install tlabel[ftp1] # FTP-1 export (zarr)
pip install tlabel[all] # Everything
Exploring Adapters from the CLI
Once installed, you can inspect what's available without writing any code:
tlabel list
This prints all dataset and real-time adapters with their type, native format, and compliance level. It's the first command I run when working with a new dataset.
For details on a specific adapter:
tlabel info gelsight
This shows the adapter's capability declaration β which of the 14 semantic dimensions it can annotate, its compliance level, and any format-specific notes. For example, GelSight outputs force_vector (L3) but not temperature (L4), while a simple resistive sensor might only declare L1 fields like contact and slip_event.
This capability declaration system is one of TLabel's key design decisions. Rather than forcing every sensor to produce all 14 dimensions (which would mean fabricating data it can't actually measure), each adapter honestly declares what it can and cannot provide.
Validating Your Data
Before converting, it's worth checking that your data passes schema validation:
tlabel validate data.json
This runs a compliance check against the 14-dimension Schema V2 and reports any issues. Catching format problems early saves debugging time downstream.
Converting Between Formats
Here's where things get practical. TLabel provides two paths for format conversion: CLI for quick checks and the Python API for full control.
Quick Conversion via CLI
For simple cases β say you have a single GelSight .pkl file and want a JSON summary:
tlabel export --input grasp_data.pkl --format json --output annotations.json
This reads the GelSight data through its adapter, applies the Schema V2 annotation, and writes a clean JSON file with all 14 semantic dimensions (at the appropriate compliance level for the sensor).
Full Conversion Pipeline via Python
For the heavy lifting β converting entire datasets into training-ready formats β the Python API gives you the most control:
import tlabel
from tlabel.converters import tlabel_to_lerobot
data = tlabel.load("path/to/paxini_data.h5")
print(data.describe())
data.export("output.json")
data.export_ftp1("output.zarr")
tlabel_to_lerobot("annotations.json", "lerobot_episode/")
Here's a concrete example that walks through a realistic workflow β PaXini force array data, validating annotations, and exporting to both LeRobot and FTP-1 formats:
import tlabel
from tlabel.converters import tlabel_to_lerobot
data = tlabel.load("experiment_01.h5")
data.validate_annotations()
data.annotate_events_auto()
data.export("experiment_01.json") # Analysis
data.export_ftp1("experiment_01.zarr") # Foundation model training
tlabel_to_lerobot("experiment_01.json", # LeRobot pipeline
"lerobot_episode/")
Batch Processing Multiple Files
When you're dealing with an entire experiment directory (which is the typical case β real manipulation datasets have hundreds of episodes), you can batch-load and convert:
import glob
import tlabel
files = glob.glob("raw_data/*.h5")
for f in files:
data = tlabel.load(f)
data.validate_annotations()
data.export(f"annotated/{data.sensor}_{data.num_frames}f.json")
print(f"Converted {f} -> {data.sensor} (L{data.compliance_level})")
Understanding the Architecture
The adapter system sits in a three-layer architecture:
βββββββββββββββββββββββββββββββββββββββββββββββββββ
β Layer 1: Schema β
β 14 semantic dimensions + Compliance Level L1-L4 β
βββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Layer 2: Adapters β
β DataAdapterBase β SensorAdapterBase β
βββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Layer 3: Downstream β
β Feature derivation Β· Export Β· Augmentation β
β FTP-1 Β· LeRobot Β· RLDS Β· ROS2 β
βββββββββββββββββββββββββββββββββββββββββββββββββββ
Layer 1 is the schema itself β 14 semantic dimensions covering spatial perception (contact, centroid, region), mechanics (force magnitude, force vector, torque), dynamics (slip event, slip velocity, manipulation phase), surface properties (texture class), and meta-perceptions (deformation, temperature, confidence, compliance level).
Layer 2 is where adapters live. There are two base classes:
DataAdapterBase β for offline dataset files (sublcass this to add support for a new sensor format, takes ~30 minutes)
SensorAdapterBase β for real-time hardware connections (streaming data from a live sensor)
Both produce output conforming to the same Schema V2, which means Layer 3 downstream tools work identically regardless of which sensor the data came from.
Layer 3 handles everything after annotation: feature derivation, data augmentation, and export into training frameworks. This is where the LeRobot converter, FTP-1 Zarr exporter, and RLDS bridge live.
The Compliance Level System
One concept worth explaining in more detail: Compliance Levels (L1βL4). This is TLabel's answer to the question "what if my sensor can't measure temperature or 6-axis force?"
L1 β Basic Tactile: contact, centroid, slip, confidence. Examples: Single-point resistive, proximity sensors
L2 β Force-Aware: L1 + force_magnitude. Examples: PaXini, YCB-Slide, GelSight
L3 β Full-Vector: L2 + force_vector. Examples: ToucHD, calibrated DM-TAC
L4 β Rich-Semantic: L3 + all optional fields. Examples: BioTac, next-gen multimodal sensors
The key insight: a PaXini at L2 and a ToucHD at L3 both produce valid TLabel output. They just populate different subsets of the 14 dimensions. Downstream code can check compliance_level to decide what it can and cannot use, rather than writing sensor-specific branches.
This is what makes cross-sensor comparison possible. You can train a model on GelSight data (L3) and evaluate it on PaXini data (L2), knowing exactly which fields are comparable and which aren't.
What About My Sensor?
TLabel is designed for extensibility. If your sensor isn't supported yet, adding an adapter takes about 30 minutes:
Fork the adapter template from contrib/adapter-template/
Subclass DataAdapterBase (for datasets) or SensorAdapterBase (for hardware)
Implement the required methods and declare your compliance level
Submit a PR or publish as a standalone package
The project also supports register_external_adapter() and entry_points auto-discovery, so third-party adapters can be published independently.
How This Fits Into the Embodied AI Pipeline
The broader context matters. Foundation models for robotics β like those being built on top of LeRobot, Open X-Embodiment, and similar frameworks β need diverse, standardized training data. But tactile data has been a bottleneck:
Collection is sensor-specific (hardware-dependent)
Annotation has been ad-hoc (no standard schema)
Training expects uniform input formats
TLabel deliberately addresses step 2 and 3 only. It's a standardization layer that sits between your raw sensor data and your training pipeline. By providing a common schema with honest capability declarations, it enables:
Cross-sensor training: Mix data from different sensors in the same training batch
Capability-aware models: Train models that know what information is available at each compliance level
Reproducible research: Compare results across labs using different hardware
The project is also actively contributing tactile data format support upstream to LeRobot via PR #4032, which signals growing recognition that tactile data standards are needed in the broader robotics ecosystem.
Quick Reference
See all supported adapters β tlabel list
Get adapter details β tlabel info gelsight
Validate a data file β tlabel validate data.json
Export to JSON β data.export("out.json")
Export to FTP-1 Zarr β data.export_ftp1("out.zarr")
Convert to LeRobot format β tlabel_to_lerobot(src, dst)
Load any sensor data β tlabel.load("file")
Try a demo (no files needed) β tlabel.demo("gelsight")
Wrapping Up
Tactile data interoperability isn't glamorous work β it's infrastructure. But it's the kind of infrastructure that determines whether the field can scale beyond lab-specific pipelines to shared, reproducible, cross-sensor research.
TLabel's adapter architecture and CLI tools won't solve every data problem in tactile robotics. But they provide a concrete, working answer to the question: "How do I get data from sensor X into format Y without writing a custom parser?"
That question used to take a weekend. Now it takes one line.
Links:
GitHub: https://github.com/liesliy/tlabel
PyPI: https://pypi.org/project/tlabel/
TLabel Paper: PDF on GitHub
Schema V2 Spec: docs/tlabel-format.md
Adapter Template: contrib/adapter-template
Contributing Guide: CONTRIBUTING.md
LeRobot PR #4032: huggingface/lerobot#4032
Previous Dev.to post: TLabel: Unifying Tactile Data Annotation for Robotics
Open X-Embodiment: robotics-transformer-x.github.io
OpenTouch: opentouch.ai
TL;DR β TLabel is the Unicode for tactile data: one standard schema, every sensor. Install with pip install tlabel, run tlabel list to see what's supported.