Force-Rate Capture on the BLO LAB Glove: The Signal Chain

A capture instrument is not just a sensor. It is a pipeline. Between the piezoresistive element on an operator's fingertip and the tensor a policy sees at training time there are calibration passes, per-operator fit corrections, alignment with pose and video, packet loss handling, and a serialization format that a foundation-model team can load without re-inventing anything. Every step in this chain either preserves the signal or destroys it, and the interesting engineering is in the chain more than in the sensor.

This piece is a plain description of what happens end to end on the BLO LAB glove. It is more product-detailed than most of what we publish because the questions we hear most often from customers are pipeline questions, not sensor questions.

Each fingertip carries a small array of pressure-sensitive elements arranged so that both the aggregate normal force and the approximate pressure distribution across the pad can be recovered. Additional elements sit along the volar side of each finger and across the palm to capture the contact events that happen off the tip during whole-hand grasps. The design goal is not maximum spatial resolution, that is the vision-tactile job, but full coverage of the surfaces that actually make contact during ordinary manipulation.

Pose is captured in parallel by a low-drift inertial-plus-flex-sensor stack integrated into the glove textile. First-person video is captured by the operator's headband unit and synchronized against the glove clock at packet level. All three streams share a common time base with sub-millisecond alignment, which is the property downstream consumers care about far more than raw fidelity of any individual stream.

Force sampling runs at rates high enough to preserve the transients that skilled manipulation actually contains. Human contact events, the moment a fingertip touches an object, the moment a grip begins to slip, the moment a correction takes effect, carry energy above what video-rate sampling can resolve. Pose runs at rates typical of high-quality inertial capture. Video runs at the highest rate the operator hardware supports.

Rate matters because the interesting training signal is in the derivatives, not the values. A policy that learns from force needs to see the shape of the force ramp during a grasp closure, not just the steady-state force after the object is held. That shape lives in the first few hundred milliseconds around contact, and it survives only when the sampling rate is set with that window in mind.

Two operators wearing the same glove size do not produce identical force readings on the same object. Skin compliance, glove fit, grip strength, and even hand temperature shift the raw values. A dataset that ignores this delivers a policy trained on operator-specific quirks rather than on real physics.

Calibration happens in three places. At session start, a short protocol pass has the operator perform a small set of standard grips against known reference objects. The pass yields per-finger scale and offset corrections that persist for the session. During the session, drift is monitored and flagged when it exceeds a threshold. Between sessions, a global calibration model trained across the operator population normalizes remaining differences so that a force reading of five newtons on one operator represents the same physical event as five newtons on another.

The output the customer sees is calibrated force in physical units, with per-frame confidence, and with the calibration lineage recorded in metadata so that any downstream retraining can inspect it.

A foundation-model team should not have to reverse-engineer a capture format. Our deliveries are structured so that force is a first-class tensor of the same rank and time base as the pose and video streams, with a documented schema, per-episode metadata, and standard splits. Loading is a one-line operation in the frameworks foundation-model teams actually use.

The metadata carries what the model implicitly needs and the researcher explicitly wants: task label, operator identifier hashed for privacy, calibration lineage, sensor firmware version, session and environment tags, and any human-authored annotations. The point is to make it possible to train and to audit at the same time, because audits are the shape of dataset quality control that is going to matter in the next regulatory cycle.

With a calibrated, high-rate, aligned force stream in the loader, several training recipes become straightforward that were previously ad hoc. Auxiliary losses on slip prediction. Force-conditioned action heads. Contact-event curricula. Failure labeling from physical rather than visual cues. None of these require exotic architecture. All of them require that the underlying data actually contain what the recipe assumes.

The reason we describe the pipeline in this much detail is that the pipeline is the product. The glove is the visible artifact; the signal chain behind it is what determines whether the data a customer receives can actually train the policies they need. Getting the glove right was the first year. Getting the chain right has been the harder work and is what makes the resulting datasets worth licensing.