Week 06 · lesson

Sensors Measure, They Do Not Know

A sensor does not know altitude.

It does not know north. It does not know whether the drone is level. It does not know that a tree is an obstacle.

A sensor converts some physical effect into a signal. The flight system gives that signal meaning.

That distinction is small enough to miss and important enough to break autonomous systems.

Measurement is a chain

Use this model:

physical world
→ sensing element
→ electrical / digital signal
→ calibration
→ units and reference frame
→ software interpretation
→ decision

Every step can add uncertainty.

If the sensing element is noisy, the number can jump. If calibration is wrong, the number can be consistently biased. If the units are mislabeled, a correct value can be interpreted incorrectly. If the reference frame is wrong, a direction can be valid and still point somewhere the software did not expect.

Five properties of a measurement

When a sensor value appears on a screen, ask about more than the value.

Accuracy

How close is the measurement to the accepted reference value?

Precision

How consistently does the sensor produce similar values under the same condition?

Resolution

What is the smallest change the system can represent or meaningfully detect?

Bias

Is there a consistent offset from the reference?

Noise

How much random variation appears around the underlying signal?

A sensor can be precise and inaccurate. It can repeatedly report almost the same wrong value.

Worked example: the “perfectly stable” sensor

A fictional altitude sensor is placed at a known 2.00 m reference height in a simulator. It reports:

2.18 m
2.17 m
2.18 m
2.18 m
2.17 m

The readings are tightly grouped. That is good precision.

They are also about 0.17–0.18 m above the reference. That suggests a bias.

If a student says, “The sensor is accurate because the readings are stable,” they are mixing precision with accuracy.

That is exactly the kind of mistake autonomous systems can amplify.

Reference frames change meaning

Direction measurements require a frame.

Imagine an accelerometer reports motion along its positive X axis. What does positive X mean?

  • forward relative to the sensor board?
  • forward relative to the aircraft frame?
  • east in a world frame?

Those are different coordinate systems.

If a sensor is mounted rotated 90 degrees and the software still assumes the old orientation, a physically correct measurement can be mapped to the wrong aircraft axis.

Nothing is “wrong” with the sensor. The frame transformation is wrong.

Common drone sensors and what they actually sense

SensorPhysical quantity / inputWhat software may estimate from it
Gyroscopeangular rateattitude change
Accelerometerspecific force / acceleration effectstilt and motion estimates when combined with other information
Magnetometermagnetic fieldheading reference under suitable conditions
Barometerair pressurealtitude change estimate
GNSS receiversatellite-derived position/time datageographic position, speed, time
Range sensordistance along sensing directionheight above surface or obstacle distance
Cameralight intensity across pixelsfeatures, objects, motion, maps, measurements

The right column is usually derived information, not what the sensor directly “knows.”

Sensors can disagree without either one being broken

Suppose GNSS-derived altitude and barometric altitude differ.

That does not automatically mean one sensor failed.

They are based on different physical measurements and reference models. Their noise, update rate, resolution, and environmental sensitivity differ.

A flight system may combine multiple sources because each one has strengths and weaknesses.

This is called sensor fusion in many systems: combining information to produce a stronger state estimate than one measurement source can provide by itself.

Evidence packet: identify the measurement problem

You receive four fictional traces.

Trace A: stable readings with a constant offset.
Likely issue to investigate: bias or calibration.

Trace B: values jump randomly around the expected value.
Likely issue to investigate: noise, vibration, electrical disturbance, or unstable environment.

Trace C: values are smooth but change slowly after the real condition changes.
Likely issue to investigate: update rate, filtering, or latency.

Trace D: pitch movement appears on the roll channel.
Likely issue to investigate: orientation or axis mapping.

These are not final diagnoses. They are signal patterns that point toward different parts of the measurement chain.

Build a sensor claim table

Choose three sensors from the course and fill out:

SensorDirect measurementDerived claimReference/frameLikely error sourceVerification evidence
example: barometerair pressurealtitude trendpressure referenceweather/airflow/biascompare against supplied reference trace

Your “derived claim” column should not simply repeat the sensor name.

If the device is a magnetometer, “measures heading” is too loose. It measures magnetic field; heading is an interpretation built from that measurement and system orientation.

Misconception: digital means objective

A clean number on a screen feels authoritative.

But the number has a history:

  • a physical effect reached the sensor;
  • hardware converted it;
  • firmware processed it;
  • calibration modified it;
  • software labeled it;
  • a reference frame gave it direction;
  • a human or controller used it to decide something.

Any weak link can produce a confident-looking wrong answer.

The lesson to keep

Sensors are measurement devices, not truth machines.

Before trusting a sensor-derived claim, ask:

What was directly measured, how was it calibrated, which frame and units give the value meaning, and what evidence says the measurement is good enough for this mission?

That question is the foundation for the calibration and payload-readiness work that follows.