<- Back to news

DexSuite brings tactile simulation to dexterous learning: what the released data contains

The new DexSuite paper links simulation, teleoperation and evaluation. We inspect one public tactile subset and separate framework claims from verified file metadata.

Preprint and official documentation reviewed; one pinned dataset manifest and metadata files inspected. No trajectory replay, training or hardware validation.Source date: Read the primary source ↗
DexSuitetactile simulationLeRobot datasetdexterous manipulationtactile datasets
Editorial diagram separating a simulation framework, a benchmark and a versioned dataset with distinct verification gates.
Original RoboSkin.ai evidence map. Counts and performance are not encoded in this conceptual diagram; it is not a DexSuite experiment figure.

DexSuite's October 27, 2026 preprint presents a Genesis-based manipulation framework connecting robot configurations, teleoperation, simulated touch and evaluation. For a team looking for a LeRobot dataset with tactile channels, the immediate opportunity is a concrete file inspection: determine which subset contains the required observations and how its recorded actions should be interpreted before starting a training run.

RoboSkin reviewed the paper and official documentation, then fetched the public manifest, dataset card and JSON metadata for one version-pinned scripted Lift subset on October 31. This is a metadata inspection. We did not download its trajectory shards or videos, execute the simulator, replay an episode, train a policy or test real hardware.

Three scopes that should not be collapsed

The v1 paper reports 30 framework tasks, 10 arms and 12 end-effectors. Its benchmark contains 16 task-embodiment pairs; the associated corpus contains 4,700 successful simulated episodes. Those are three different scopes: configurable environments, evaluated combinations and recorded demonstrations. None is a count of independently verified real-robot deployments.

The official project page separates the corpus into 700 human-teleoperated, 1,200 scripted and 2,800 machine-generated episodes. Human teleoperation here still controls a simulated robot. Preserve collection origin when assembling a training mixture; the word human does not convert a simulated contact signal into a physical measurement.

There is also a version boundary. The documentation landing page displayed 26 tasks, 16 arms and robots, and 11 end-effectors in the October 31 review. The repository README, read November 4, advertises 31 tasks, ten arms plus six integrated robots, and eleven end-effectors. These are dated inventories with different categories, not a single fixed benchmark count. We have not enumerated an installed release; the paper's 16 evaluated task-embodiment pairs remain a separate scope.

What we could inspect directly

The concrete dataset is dexsuite/lift_franka_franka_umi_tacticle_scripted, pinned to revision f4be6e95af40843da39cd5a88d8bd736393dd59c. The spelling tacticle is part of the upstream repository identifier and is retained in the link.

Its card describes scripted successful Lift demonstrations with a Franka arm and UMI-style tactile gripper. The license metadata is Apache-2.0. That statement is scoped to this dataset card; it is not a verified license for every simulator asset, package or dataset in the wider project.

Inspected fileRecorded valueWhat the inspection establishes
meta/info.jsonLeRobot v3.0; 20 Hz; 200 episodes; 15,030 framesDeclared metadata, not an independent recount of trajectory rows
Feature schemaLeft and right force_grid arrays: 12 by 32, float32The named tactile feature and shape are declared
Feature schemaFront and wrist RGB video: 224 by 224Camera shape is declared; video decoding was not tested
meta/action_layout.jsonNine action values: seven manipulator values and two gripper valuesController segments are explicit; the nine values are not nine robot joint angles
Public file manifestParquet data and episode metadata, JSON metadata and MP4 filesFile paths exist in the listing; payload completeness remains untested

The action-layout file names OSCPoseAbsoluteQuatController for the manipulator segment and JointPositionController for the gripper segment. A trainer must preserve that distinction. Matching tensor width alone is insufficient to establish matching action meaning.

The observation-action boundary is a practical trap

The dataset card states that frame t stores the observation before action t. Its final success flag describes the transition triggered by the last action; the terminal state itself is not stored. That is a small documentation detail with a large consequence for any code that expects every action to have a following observation in the same episode.

RoboSkin analysis: do not silently pair the final action with the first observation of the next episode. Decide explicitly whether the loader drops that transition, represents the next observation as unavailable, or obtains it through a separately validated replay. A padded terminal observation may be useful to a particular model, but it should stay marked as padding rather than recorded evidence.

The LeRobot v3 documentation explains that episode boundaries are reconstructed from metadata while multiple episodes share storage files. Counting Parquet files therefore cannot recover the episode count. Inspect the episode index and offsets, then check how the chosen loader resolves temporal windows near both ends of a sequence.

Simulated tactile values need a simulation-specific interpretation

The paper describes FlexiTac-style simulated pads and says tactile observations are included in scripted tactile configurations. It does not justify assuming that every episode in every release has the same contact channels. Our file check narrows that claim to one named subset with explicit tactile features.

For an experiment, record how the simulated quantity maps to the intended input. A spatial array can support a contact-learning study without being interchangeable with an optical fingertip image or a calibrated physical force sensor. Shape compatibility is only the first check. Coordinate frame, normalization, contact law, sample timing and the controller's response all affect what a learned model can use.

Our recommendation is to begin with a channel-level inspection before a full policy comparison. Plot unloaded intervals and contact intervals, compare left and right pads, and check whether the signal changes at the same step as the relevant action and object motion. Those are proposed checks; we have not performed them on the trajectory payload in this review.

Successful demonstrations are not a measured deployment success rate

A collection selected for successful episodes is a training resource. It cannot by itself estimate the probability of success across all attempted rollouts. That estimate needs the evaluation protocol and an attempt denominator that includes failures and interventions. Keep collection yield, training-set size and policy success in separate fields in a report.

For a fair contact ablation, we would hold the task, embodiment, visual inputs, training episodes and evaluation seeds fixed while changing access to tactile inputs. Compare the same policy family under the same compute budget. Also check whether ground-truth simulator state is available to one model but not another; a state-based baseline and an image-based policy are different observation conditions.

Keep each task's result visible before averaging. A model that improves pickup while failing release may have a different practical value from one that makes a small improvement across the entire sequence. Report the failure stage and intervention rule alongside the final success fraction. This is an evaluation design recommendation, not a new DexSuite result.

Match the held-out unit to the claim

An episode split asks whether a policy handles new episodes from the represented collection process. A collector split asks a different question: whether behavior transfers beyond the demonstrator or policy that generated the training data. An embodiment split changes the robot and action interpretation as well. Label the intended generalization before selecting the split.

Our proposed review would list the task, embodiment, collection tier and collector revision for each group. Keep all frames from an episode together, then decide which additional groups must remain unseen. If a subset lacks the metadata needed for that separation, report the limit instead of describing a random frame split as cross-collector transfer. This is an evaluation design, not evidence that leakage occurred in the published benchmark. See the LeRobot format guide for the separate storage and sequence-boundary checks.

A bounded adoption sequence

First, freeze the dataset revision and the intended simulator/package version. Save the schema, action layout, card and license evidence with the experiment configuration. The repository returned 404 during our October 31 review, but the official project now links a readable source repository, checked November 4. That changes its access status; it does not establish a successful installation or reproduction.

The repository's LICENSE identifies MIT for its software. Its third-party notice separately lists model and asset terms, including non-commercial research/education restrictions for PartNet-Mobility objects. Do not apply the software license to every scene asset or to the separately versioned dataset. This review reads the notices; it does not clear a particular commercial use.

Second, inspect one complete episode with the chosen loader. Confirm lengths, timestamps, action meanings, terminal handling and the tactile feature values. Define a held-out split by episode or the relevant collection grouping before training; random adjacent frames do not form an independent contact evaluation. The inspected metadata declares a train split covering all 200 episodes, so a research split remains an explicit experiment choice.

Third, run a small reproducibility experiment and preserve failures. Only after those checks should a team scale the training mixture or investigate physical transfer. A simulation result can guide that work, but the real robot introduces a separate sensor, controller and contact environment that must be tested.

The DexSuite entry in our tactile dataset directory now preserves this subset's format, license marker and inspection limits. Use the benchmark guide to plan comparisons, and the Tactus glove evidence review for the complementary problem of qualifying physical human-demonstration measurements.

Evidence and editorial review: November 4, 2026. Original publication date retained.

Continue the topic

Tactile simulationTactileLab: what simulated tactile flow adds to robot manipulationTactile simulationTouchTherm gives digital twins tactile texture and cooling dynamicsHaptic teleoperationDITTO-X makes a robot hand align the operator before takeover