Robot Tactile Sensor Models: Specs and Selection

A robot tactile sensor is a device that measures contact at a robot surface and exposes a signal for perception or control. Robot tactile sensor selection depends on the contact geometry, force range, sampling path and integration interface. The model library below preserves the source-review date for each record and separates published specifications from missing information.

Last updated:

Part of tactile sensing: compare sensing principles before selecting a model or end effector.

Published | Updated by

November 4, 2026: reviewed model-library interpretation and added a specification-to-interface handoff. Existing 17 records retain their individual source dates; no device testing or live stock check.

Layered tactile sensor surface sending signals through processing boards and robot-ready data views.
Technology visual showing tactile sensing layers and signal flow.
3
sections
2
questions
3
next routes

17 sensor models tracked

Tracked manufacturer and research models. Source-reviewed records retain their actual evidence dates. Manual review follows a checked release or correction; no automatic refresh. Unknown values remain Not published.

Robot tactile sensor models, integration and source dates
ModelTypeForce rangeSampling rateInterfaceVendor / groupSource / reviewed
Loomia Smart SkinFlexible capacitive and resistive sensingNot publishedComponent-specific; see the dated profile specification table.Not publishedLoomia TechnologiesLoomia Smart Skin source
Robotiq TSF-85Capacitive tactile array with dynamic and inertial sensingNot publishedPressure array: 60 Hz. Dynamic signal: 1000 Hz. The SDK describes a 1 kHz USB stream per finger; transport rate is not pressure refresh rate.USB; C++ SDK and Python toolsRobotiqRobotiq TSF-85 source
Melexis TactaxisMagnetic tactile sensing with a Triaxis Hall-effect IC5 N normal / 2 N shear; extended 15 N range at reduced accuracy (2025 taxel)Not published. Not publicly specified in the reviewed Melexis e-guide or 2026 module announcement.Not publishedMelexisMelexis Tactaxis source
ViTai VT-GF225Marker-based vision tactile sensing with a compliant gel interface30 N maximum normal and tangential force (manufacturer-reported)30 Hz for the standard version according to the reviewed manufacturer pageUSB 2.0ViTai RoboticsViTai VT-GF225 source
DIGITVision-based tactile sensingNot publishedThe 2020 paper reports 60 FPS at 640 × 480; the official Python interface defaults to 640 × 480 at 30 FPS. Verify the stream supported by the actual unit.USB camera; Python digit-interfaceMeta AI Research / GelSightDIGIT source
Digit 360Multimodal vision-based tactile sensingNot publishedNot published. Not publicly stated on the reviewed repository overviewNot publishedMeta AI Research / GelSightDigit 360 source
GelSight MiniVision-based tactile sensingNot published25 FPS in the reviewed official datasheetUSB; image acquisition and reconstruction softwareGelSightGelSight Mini source
ReSkinMagnetic tactile skinNot publishedUp to 400 Hz reported by MetaMagnetometer acquisition; version-specific hardwareMeta AI Research / Carnegie Mellon UniversityReSkin source
AnySkinMagnetic tactile skinNot publishedNot published. Not publicly stated on the reviewed project pageNot publishedNew York University / Carnegie Mellon University / Columbia University / MetaAnySkin source
GelSlim 4.0Vision-based tactile sensingNot publishedNot published. Not publicly stated in the reviewed abstractNot publishedUniversity of Michigan MMint LabGelSlim 4.0 source
TacTipBiomimetic optical tactile sensingNot publishedDepends on the camera and TacTip variant; no single rate is stated for the full familyNot publishedBristol Robotics Laboratory / University of BristolTacTip source
BioTacFluid-filled biomimetic multimodal sensingNot publishedNo single cross-modality rate is used in this directory; BioTac signal channels and hardware revisions must be checked separately.Not publishedSynTouchBioTac source
uSkinDistributed magnetic three-axis force sensingNot publishedUp to 500 Hz for the uSPa 11 model in the reviewed catalogNot publishedXELA RoboticsuSkin source
DenseTact 2.0Vision-based optical tactile sensingNot publishedNot published. Not publicly stated in the reviewed abstractNot publishedStanford University ARM LabDenseTact 2.0 source
9DTactVision-based tactile sensing with translucent gelNot publishedNot published. Not publicly stated on the reviewed project pageNot publishedShanghai Qi Zhi Institute / Tsinghua University / HUST / Shanghai AI Laboratory9DTact source
InsightVision-based haptic sensingNot publishedNot published. Not publicly stated on the reviewed project pageNot publishedMax Planck Institute for Intelligent SystemsInsight source
AllSightVision-based optical tactile sensingNot publishedNot published. Not publicly stated in the reviewed abstractNot publishedBen-Gurion University research teamAllSight source

Short answer

What you need to know

  1. 1

    The library contains 17 existing sensor records. It is a tracked set, not a complete market census.

  2. 2

    Specifications are taken from the linked manufacturer documentation or original research sources. No unreported rate, interface or force range is inferred from a related product.

  3. 3

    Review is manual and event-driven: check a record when its source release changes or a correction arrives. There is no automatic refresh; the date on each row records the evidence actually reviewed.

Topic 01

Turn a specification row into a usable interface requirement

The 17 records below are dated source summaries. A page-level revision does not mean every manufacturer specification has been freshly measured or that every device is currently in stock. Begin with the exact model and revision, then follow the linked profile or primary source for the conditions behind a field.

The DIGIT and TSF-85 records illustrate why a single rate column is not enough. DIGIT’s paper and interface describe camera acquisition settings; TSF-85 distinguishes pressure-array refresh, dynamic sensing and USB transport. Neither field alone is the rate of a calibrated force estimate or the bandwidth of an external robot controller.

RequirementRecord from the exact configurationReject this shortcut
Quantity and unitsRaw image/count/field or calibrated force, pressure or geometryInterpreting a numeric SDK output as newtons without a calibration contract
Spatial footprintActual active area, element layout, blind regions and contact geometryComparing image pixels directly with independent three-axis sensing elements
TimingAcquisition configuration, complete sample interval, timestamps and processing delayUsing interface throughput as full-array refresh or action frequency
Mechanical compatibilityMount, cover, allowable deformation and replacement methodTransferring a flat-sample result to a curved mounted surface unchanged
Software and reuseSupported hardware revision, pinned driver/model and relevant termsAssuming a public repository licenses every asset or supports every variant

Resolve unknown fields before making them requirements

Not published in this directory means the reviewed evidence did not establish that field. It is neither a zero value nor proof that a supplier has never documented it. Record the exact question and source revision, and leave the field unresolved until documentation or a measurement addresses it.

For a force-based task, specify loading direction, contact geometry, calibration range and acceptable error before comparing candidates. For a slip task, define an independently labelled slip event and acceptable false alarms and delays. The correct choice follows the required observation and failure cost, not the largest number in a specification table.

Topic 02

Choose the model after defining the measurement

Start with the required contact footprint and signal: a taxel array, a reconstructed surface, an estimated force or a dynamic vibration channel. Compare normal and shear force only when calibration, loading geometry and units match.

An image frame rate, USB transport rate and calibrated force update rate are different values. If the source does not establish the quantity required by your controller, record it as an unresolved integration requirement.

FieldWhat to compareWhat not to assume
TypeTransduction principle and contact surface geometryAll sensors in one family have the same spatial resolution
Force rangeNormal and shear limits with the calibration conditionsA raw pressure count is calibrated force
Sampling rateSensor refresh, transport and processing rate separatelyA fast transport stream proves the same closed-loop bandwidth
InterfaceElectrical connection, API and timestamp behaviourA public repository supports every hardware revision
Vendor or research groupExact model, release and available documentationA laboratory prototype is currently orderable

Topic 03

Verify a candidate in the intended contact task

Use a reference load and a repeatable fixture to record the unloaded baseline, loading and unloading curves, repeatability and drift. Check timestamp alignment with the robot state before comparing a policy result.

For slip detection, use independently labelled slip events. For insertion, record geometry and contact-force limits. Keep these task measurements alongside the model revision and mounting details so another run can reproduce the conditions.

Common questions

FAQ for this topic

01

Why do some sensor fields say Not published?

No applicable value was established in the reviewed source. This does not mean zero capability, nor that the manufacturer has no additional private documentation.

02

Are the model rows ranked?

No. They have different contact areas, sensing outputs and test protocols. The table is a selection record, not a shared performance leaderboard.