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
| Sensor | Physical quantity / input | What software may estimate from it |
|---|---|---|
| Gyroscope | angular rate | attitude change |
| Accelerometer | specific force / acceleration effects | tilt and motion estimates when combined with other information |
| Magnetometer | magnetic field | heading reference under suitable conditions |
| Barometer | air pressure | altitude change estimate |
| GNSS receiver | satellite-derived position/time data | geographic position, speed, time |
| Range sensor | distance along sensing direction | height above surface or obstacle distance |
| Camera | light intensity across pixels | features, 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:
| Sensor | Direct measurement | Derived claim | Reference/frame | Likely error source | Verification evidence |
|---|---|---|---|---|---|
| example: barometer | air pressure | altitude trend | pressure reference | weather/airflow/bias | compare 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.