Analytics & ML · Study deck
Sensor Fusion Best Practices
Picture a greenhouse where two heat sensors disagree.
Data Dora is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The choice between these families is a design decision like any other: it should be written down, tested against labeled conflict cases, and revisited if the sensor mix or failure pattern changes.
- Explain: Survive a failed sensor is real only after the errors independent + exclusion rule rehearsed gate runs, and Shrink the error band depends on current calibration with no shared reference offset.
- Explain: A mathematically sound filter can still publish bad output if sensors are miscalibrated, timestamps describe different moments, uncertainty is misreported, or fallback rules keep stale sensors in the estimate.
- evaluate innovation-gate decisions
Major section
Start With the Story
One says the room is safe.
- The other says it is too hot.
- Taking the average may hide the bad sensor and start the wrong fan.
- More sensors do not guarantee more truth.
- A smooth combined value can still be late, biased, or built from two copies of the same error.
Major section
Start With the Story (continued)
The fallback is part of the design.
- The Practitioner section uses gates before a combined result may act.
- For example: both room sensors must be fresh, at least one must pass its self-test, and their gap must stay below the agreed limit.
- A reviewer should be able to repeat every choice without guessing.
Major section
Reviewable Fusion Evidence
Sensor fusion fails most often when the surrounding evidence contract is weak.
- A mathematically sound filter can still publish bad output if sensors are miscalibrated, timestamps describe different moments, uncertainty is misreported, or fallback rules keep stale sensors in the estimate.
- The practical goal is not to make the fused estimate look smooth.
Major section
Reviewable Fusion Evidence (continued)
Trust it only when the calibration, time alignment, validation gates, uncertainty, sensor-health checks, and fallback behavior are all recorded and tested.
- Best practice is to design the validation, calibration, timing, health, and retest rules at the same time as the fusion algorithm.
- The goal is to publish a state estimate with visible confidence and visible limits.
- When the record is missing, the system can still look stable while silently mixing incompatible evidence.
Major section
Reviewable Fusion Evidence (continued)
Every fused output should preserve enough metadata for a reviewer to answer which sensors contributed, which inputs were rejected, how fresh the evidence was, what uncertainty was reported, and what degraded mode was active.
- For example, a room occupancy service might fuse motion, door, camera, and CO2 evidence.
- The dashboard should not show only "occupied: yes".
- The first handoff preserves the count or register and its unit before a cleaning rule filters or rejects a spike.
Major section
Reviewable Fusion Evidence (continued)
It should also expose that the camera is in privacy-masked mode, the CO2 sensor is 11 minutes old, the door sensor was accepted, and the motion channel was rejected for a stuck-high heartbeat.
- That evidence boundary tells operators whether to trust the fused state, wait for recovery, or route the decision to manual review.
- That kind of combination question has more than one accepted mathematical answer, and naming which one a system uses is itself part of the evidence contract.
- The local decision records whether the result was sent, stored, or suppressed, together with its threshold or fallback rule.
Major section
Reviewable Fusion Evidence (continued)
The choice between these families is a design decision like any other: it should be written down, tested against labeled conflict cases, and revisited if the sensor mix or failure pattern changes.
- Survive a failed sensor is real only after the errors independent + exclusion rule rehearsed gate runs, and Shrink the error band depends on current calibration with no shared reference offset.
- When a fused result changes, that chain lets the team separate a changed signal from cleaning, calibration, or policy drift.
- Align TimeFuse measurements by event time, not arrival time, and define how stale or missing readings are handled.
Major section
Practitioner: Use Gates Before Actuation
Validation should happen before a fused estimate drives alerts, control, or actuation.
- In Kalman-style filters, this is often done with the innovation and its covariance.
- The gate output should be stored as operational evidence, not treated as a private filter detail.
- An accepted measurement records the innovation, threshold, timestamp, and calibration version that justified the update.
Major section
Practitioner: Use Gates Before Actuation (continued)
decision: For a one-dimensional 95 percent chi-square gate, the threshold is about 3.84.
- A rejected measurement records the same evidence plus the fallback state that was published instead.
- 18.0 is above that gate, so reject or quarantine this measurement.
- Raw value, unit, sensor id, firmware version, range limits, and rejection reason.
Major section
Fusion Needs a Retreat Plan
A production fusion system needs fault detection and exclusion, not just a best-effort estimate.
- Fault detection identifies suspect inputs through health, timing, residual, and consistency checks.
- Exclusion removes or downweights the suspect evidence.
- The retreat plan should be numeric enough to test.
- Normal mode requires at least two fresh sensors with residuals inside the gate.
Major section
Fusion Needs a Retreat Plan (continued)
Degraded mode allows one fresh sensor for at most 5 s if the diverter remains below 0.5 m/s and an operator alert is active.
- Those thresholds make the fallback behavior reproducible instead of dependent on whoever reads the alarm.
- Isolation should also record which state dimension was protected.
- The published state should then say "two-of-three range evidence, C excluded, position-only confidence widened" rather than simply "healthy".
Major section
Fusion Needs a Retreat Plan (continued)
If it returns once at 0.09 m and then jumps to 0.41 m, it stays quarantined and the maintenance record remains open.
- This prevents a single lucky sample from hiding a loose mount, bad reference, or intermittent cable.
- DetectUse residuals, innovation spikes, heartbeat loss, saturation flags, and cross-sensor disagreement to identify suspect inputs.
- DegradePublish a lower-confidence mode when fewer sensors remain observable.
Major section
Fusion Needs a Retreat Plan (continued)
Shared bias makes several sensors agree on a wrong value.
- Gates reject good evidence during legitimate motion or accept bad evidence during faults.
- The system keeps actuating after observability or confidence has fallen below the safe boundary.
- Good exclusion is also reversible only through a defined recovery path.
Deck summary
Key takeaways
One says the room is safe.
- The fallback is part of the design.
- Sensor fusion fails most often when the surrounding evidence contract is weak.
- Trust it only when the calibration, time alignment, validation gates, uncertainty, sensor-health checks, and fallback behavior are all recorded and tested.
- Every fused output should preserve enough metadata for a reviewer to answer which sensors contributed, which inputs were rejected, how fresh the evidence was, what uncertainty was reported, and what degraded mode was active.
Retrieval practice
Recall check 1 of 4
Data Dora says: answer from memory, then check your reasoning.
Q1Which evidence should travel with a fused sensor output in a reviewable IoT system?
Show answer
Answer: B Sensor fusion best practices keep the fused output and its supporting evidence together.
Retrieval practice
Recall check 2 of 4
Data Dora says: answer from memory, then check your reasoning.
Q2In the worked scalar gate, why is the 25.0 deg C measurement rejected?
Show answer
Answer: C Innovation gates reject measurements that are not plausible under the current prediction and uncertainty.
Retrieval practice
Recall check 3 of 4
Data Dora says: answer from memory, then check your reasoning.
Q3A sensor mount and axis map change after fusion validation. What should release review require?
Show answer
Answer: B Mount and axis changes can alter the evidence entering the fused state.
Retrieval practice
Recall check 4 of 4
Data Dora says: answer from memory, then check your reasoning.
Q4Why should a fusion system publish a degraded mode instead of only a fused value?
Show answer
Answer: A Fault detection, exclusion, and degraded-mode reporting make fusion behavior reviewable under failure.
Print reference
Answers
Answer key.
- B · Sensor fusion best practices keep the fused output and its supporting evidence together.
- C · Innovation gates reject measurements that are not plausible under the current prediction and uncertainty.
- B · Mount and axis changes can alter the evidence entering the fused state.
- A · Fault detection, exclusion, and degraded-mode reporting make fusion behavior reviewable under failure.