Build a Measurement Chain

Robots rarely use a raw sensor number directly. The number moves through conversions and decisions.

This lesson makes that chain visible.

Example: encoder to wheel distance

Assume:

• encoder: 2048 counts per motor revolution;
• gearbox: 4 motor revolutions per wheel revolution;
• wheel circumference: 0.50 m.

Counts per wheel revolution:

2048 × 4 = 8192 counts

Distance per count:

0.50 / 8192 ≈ 0.000061 m

If the encoder changes by 4096 counts:

4096 × 0.000061 ≈ 0.25 m

That estimate assumes the gearing and wheel geometry are correct and the wheel did not slip.

Add validation

A measurement chain should define impossible or suspicious conditions.

Example rules:

if count_delta is physically impossible for one cycle:
    reject or flag sample

if sensor timestamp is too old:
    do not treat it as current

if calibration is missing:
    mark measurement invalid

The exact response depends on the robot. The important part is that the behavior is deliberate.

Compare two sensors

Suppose you need to know whether a mobile robot is moving.

Possible evidence:

• wheel encoder rate;
• inertial measurement;
• optical flow;
• external camera.

Each sees a different part of reality.

A wheel encoder measures drivetrain motion. An IMU senses acceleration/rotation. Neither alone perfectly proves global position.

Build your chain

Choose one physical quantity:

• distance;
• angle;
• speed;
• force;
• temperature;
• object presence.

Draw:

physical quantity → sensor → raw value → conversion → filtered/calibrated value → decision

Add:

• units at every numeric stage;
• one invalid condition;
• one source of uncertainty;
• one second measurement that could challenge the first.

This becomes the sensor page in your systems dossier.

Trace one value from physics to decision

A measurement chain is easiest to debug when every conversion is visible.

Imagine a potentiometer measuring an arm angle:

arm rotates
   ↓
potentiometer voltage
   ↓
ADC sample: 0..4095
   ↓
normalized fraction
   ↓
angle in degrees
   ↓
limit / control logic

Suppose the raw ADC value is 2048 on a 12-bit converter whose usable range is 0..4095.

An approximate normalized value is:

2048 / 4095 ≈ 0.50

If the calibrated arm range is 20° to 140°, a simple linear model would place that reading near 80°.

The controller did not "measure 80 degrees" directly. Several transformations produced that value.

Put validity beside the value

A strong measurement object conceptually carries more than one number:

{
  "angle_deg": 80.1,
  "valid": true,
  "age_ms": 12,
  "source": "arm_pot"
}

A stale 80.1° reading should not be treated the same as a fresh 80.1° reading.

For your measurement chain, mark where each of these can fail:

• physical sensing;
• wiring/interface;
• conversion;
• calibration;
• timing;
• validity logic.

That map becomes the starting point when the robot later makes a wrong decision.