How do you validate a force/torque sensor's calibration in the field?
-
ethan.lewis5
- Posts: 65
- Joined: Sat Apr 04, 2026 7:35 pm
Re: How do you validate a force/torque sensor's calibration in the field?
@rtorres Slight correction, though the overall point stands:
LiDAR gives reliable, lighting-independent range data but is heavier, pricier, and gives sparser point clouds up close than stereo or depth cameras, which is why a lot of humanoids lean on stereo/depth cameras for near-field manipulation and reserve LiDAR (if present at all) for longer-range navigation. Multi-camera calibration drifts over time from thermal expansion, vibration, and mechanical wear, which is why production systems typically run periodic recalibration routines rather than assuming a one-time factory calibration holds forever.
Opinions my own, not my employer's.
Re: How do you validate a force/torque sensor's calibration in the field?
Here's what I know on this:
Multi-camera calibration drifts over time from thermal expansion, vibration, and mechanical wear, which is why production systems typically run periodic recalibration routines rather than assuming a one-time factory calibration holds forever.
Re: How do you validate a force/torque sensor's calibration in the field?
One nitpick -
Multi-camera calibration drifts over time from thermal expansion, vibration, and mechanical wear, which is why production systems typically run periodic recalibration routines rather than assuming a one-time factory calibration holds forever. Tactile skin arrays have improved a lot, but 'good enough to matter' really depends on the task - coarse contact detection across a large area is fairly mature, while fine, high-resolution force distribution sensing (like a human fingertip) is still the harder problem.
they/them
Re: How do you validate a force/torque sensor's calibration in the field?
@ivan22 Counterpoint:
Event cameras (which report per-pixel brightness changes rather than full frames) are still more of a research curiosity than a production sensor for humanoids, mainly because the software ecosystem and processing pipelines around them are far less mature than for standard frame-based cameras. SLAM in a working warehouse is harder than in a controlled lab mainly because the map keeps changing - pallets move, people walk through, lighting shifts near dock doors - so a lot of production systems lean on semi-static maps refreshed periodically rather than pure continuous SLAM.
they/them
Re: How do you validate a force/torque sensor's calibration in the field?
One nitpick -
Latency between a perceived event (like a slip) and a corrective control response matters enormously for balance - even 50-100ms of extra perception latency can be the difference between a smooth recovery and a fall, which is part of why a lot of balance-critical sensing is proprioceptive rather than vision-based.
she/her
Re: How do you validate a force/torque sensor's calibration in the field?
@erik_novi Short answer:
SLAM in a working warehouse is harder than in a controlled lab mainly because the map keeps changing - pallets move, people walk through, lighting shifts near dock doors - so a lot of production systems lean on semi-static maps refreshed periodically rather than pure continuous SLAM. Event cameras (which report per-pixel brightness changes rather than full frames) are still more of a research curiosity than a production sensor for humanoids, mainly because the software ecosystem and processing pipelines around them are far less mature than for standard frame-based cameras.
Watching this space closely since 2019.
-
freya.smith
- Posts: 72
- Joined: Wed Feb 11, 2026 5:28 pm
Re: How do you validate a force/torque sensor's calibration in the field?
Just to be precise about one thing:
Vibration is one of the most underrated sources of noisy IMU and tactile readings - mounting matters as much as sensor quality, and a poorly isolated mount can add more noise than the sensor's own datasheet specs would suggest. Proprioception (the robot's sense of its own joint angles, velocities, and forces) tends to get less attention than flashy vision systems, even though a lot of balance and manipulation failures trace back to proprioceptive noise or miscalibration rather than a vision problem.
she/her
Re: How do you validate a force/torque sensor's calibration in the field?
@freya.smith To answer this directly:
Latency between a perceived event (like a slip) and a corrective control response matters enormously for balance - even 50-100ms of extra perception latency can be the difference between a smooth recovery and a fall, which is part of why a lot of balance-critical sensing is proprioceptive rather than vision-based. SLAM in a working warehouse is harder than in a controlled lab mainly because the map keeps changing - pallets move, people walk through, lighting shifts near dock doors - so a lot of production systems lean on semi-static maps refreshed periodically rather than pure continuous SLAM.
-
mohammed.rossi
- Posts: 88
- Joined: Fri Nov 07, 2025 9:46 pm
Re: How do you validate a force/torque sensor's calibration in the field?
Short answer:
Unitree's Dex3-1 dexterous hand packs around 33 pressure/tactile sensors per hand across the fingers and palm, capable of sensing pressure roughly in the 10g-2500g range - a useful reference point for what 'production tactile sensing' looks like right now.
Re: How do you validate a force/torque sensor's calibration in the field?
@mohammed.rossi Worth being a little skeptical of the marketing angle here.
Latency between a perceived event (like a slip) and a corrective control response matters enormously for balance - even 50-100ms of extra perception latency can be the difference between a smooth recovery and a fall, which is part of why a lot of balance-critical sensing is proprioceptive rather than vision-based. Sensor fusion mostly earns its keep by covering for each individual sensor's weaknesses - vision struggles with occlusion and lighting, IMUs drift, force/torque sensors are noisy at low loads - fusing them gives a more robust estimate than any one source alone, independent of raw compute.