16 Sensor Fusion Foundations
16.1 Start With the Story
Picture an IoT team using the ideas in Sensor Fusion Foundations during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.
Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.
Phoebe’s Why
The complementary filter below fuses two numbers that never measured the same electrical property. The accelerometer’s “8.0 deg” comes from a proof mass sagging under gravity: tilt the device and gravity’s component along the sense axis changes, so the mass shifts a few nanometres and a capacitor gap changes with it – an equilibrium reading, slow but driftless. The gyroscope’s “20.0 deg/s” comes from a completely different trick: a proof mass is driven to vibrate continuously, and the Coriolis force from rotation deflects that vibration sideways by an amount proportional to rotation rate, sensed the same way – as a capacitance change – but of a rate, not a position. Fusion works here because one sensor’s blind spot (the gyro drifts over time) is the other sensor’s strength (the accelerometer has no time-dependent drift, only motion noise).
The Derivation
Accelerometer: Newton’s second law and Hooke’s law fix how far the proof mass moves under the gravity component along its axis, and that displacement sets the capacitance change a charge amplifier reads:
\[x = \frac{ma}{k}, \qquad \frac{\Delta C}{C_0} \approx \frac{x}{d_0}, \qquad a_x = g\sin\theta\]
Gyroscope: a proof mass driven at velocity \(v_{drive}\) along one axis experiences a Coriolis acceleration when the case rotates at rate \(\Omega\) about the sense axis, deflecting the mass sideways by an amount the same capacitive read-out picks up:
\[\vec{a}_{Coriolis} = -2\vec{\Omega}\times\vec{v}_{drive}\]
Both chains end at the same kind of read-out (\(\Delta C/C_0\) into a voltage), but the physical quantity each one inverts back to – a position from gravity, or a velocity deflection from rotation rate – is different, which is exactly why one drifts and the other does not.
Worked Numbers: This Chapter’s Own Tilt Update
- Accelerometer’s 8.0 deg, worked backward: \(a_x = g\sin(8.0^\circ) = 9.81\times0.1392 = 1.37\) m/s\(^2\) – the raw signal behind the chapter’s “accelerometer tilt estimate.” For a catalog-typical consumer MEMS proof mass (\(m=3.0\times10^{-8}\) kg) on a \(k=8.0\) N/m spring, that acceleration moves the mass \(x=ma/k=5.12\) nm – sub-10-nanometre motion is why capacitive sensing, not a strain gauge, is used.
- Gyro prediction step: \(10.0 + (20.0\times0.020) = 10.4\) deg – the chapter’s own arithmetic, confirmed.
- Fused angle: \((0.98\times10.4) + (0.02\times8.0) = 10.192 + 0.160 = 10.352\) deg – matches the chapter’s own result to 3 s.f.
- Sampling behind the 0.020 s step: \(f_s = 1/0.020 = 50.0\) Hz, Nyquist limit \(25.0\) Hz. Catalog-typical handheld/wearable motion content runs up to roughly 10-12 Hz, so 50 Hz sampling leaves about a 2x margin – tight enough that a firmware change lengthening the update interval should be re-checked against the actual motion bandwidth, not assumed safe.
16.2 Fusion Combines Evidence
Sensor fusion combines measurements, features, or decisions from more than one source so an IoT system can estimate state with a clearer evidence boundary than any single sensor can provide. A fusion design should name what each sensor contributes, how time is aligned, how uncertainty is represented, and what the system does when sensors disagree or disappear.
The most common beginner mistake is treating fusion as simple averaging. Averaging can reduce random noise when sensors measure the same quantity with independent errors, but many IoT systems need complementary evidence. A GPS receiver provides slow absolute position; an IMU provides fast motion changes but drifts. A camera gives rich scene evidence but is sensitive to lighting; radar can keep range evidence under different visual conditions. Fusion is the discipline of combining those strengths while keeping their failure modes visible.
If you only need the intuition, this layer is enough: fusion is a documented evidence contract. Record the state being estimated, the sensor role, the fusion level, timing rules, uncertainty, conflict policy, and validation target before trusting the fused output.
The contract starts with a state sentence that is narrow enough to test. “Estimate the temperature field in a greenhouse bay every 60 seconds” is reviewable; “understand the greenhouse” is not. Once the state is named, each sensor gets a role: one may provide absolute correction, another may provide fast relative change, and another may act as a fault witness when the first two disagree. This prevents a fusion design from mixing every available channel simply because data exists.
Fusion level is the next choice. Signal-level fusion combines readings close to the sensor. Feature-level fusion waits until useful features have been extracted. Decision-level fusion combines detector outputs when raw evidence cannot be shared. State fusion tracks a quantity over time, carrying uncertainty and health state forward from one update to the next.
A practical input-output view makes the same choice more concrete. Data-in/data-out fusion keeps the output as data, such as filtering raw image or sensor samples with a Gaussian, median, or total-variation-style filter. Data-in/feature-out fusion turns raw data into features, such as extracting labelled connected components from image pixels. Feature-in/feature-out fusion combines already-derived features, such as video and audio features for an activity window. Feature-in/decision-out or data-in/decision-out fusion drives pattern or object recognition. Decision-in/decision-out fusion combines separate recognizer outputs, votes, or incident labels. The review question is always what evidence was lost, summarized, or made harder to replay at that level.
Classical multisensor fusion also includes related information, not only live sensor streams. A calibration table, floor plan, map, equipment database, or known user context can make a fused estimate more accurate or more specific than one sensor could make alone. The review record should therefore name every source of evidence and whether it is measured now, looked up from an associated database, or assumed from the deployment model.
Source relationships give that record a useful first classification. Complementary fusion combines sources that see different parts of the problem, such as cameras with different fields of view. Redundant fusion combines sources that observe the same target so confidence or fault tolerance can improve. Cooperative fusion combines sources whose joint interpretation creates new information, such as using an accelerometer, gyroscope, and magnetometer together to estimate rotational angles.
The benefit of multiple sensors should be stated in that same evidence language. Redundancy can let a system survive one failed sensor; independent uncertainty can increase confidence; different sensor dimensions can describe more of the environment or process; and denser or differently placed sensors can improve spatial or temporal resolution. None of those benefits is automatic, so the design still has to prove independence, placement, calibration, and degraded-mode behavior.
The first practical challenge is often not the algorithm but making the inputs comparable. A fusion record should say whether evidence arrived as analogue voltage, digital counts, text, audio, image, or video; which coordinate frame, unit, sample frequency, and timestamp each source uses; and how clock skew, buffering, or propagation delay is handled before samples are combined. Without that record, a fused estimate can quietly mix different dimensions, different coordinate systems, or measurements that describe different physical moments.
Raw Data Fusion
Combine synchronized measurements before feature extraction, such as weighted temperature readings or position updates.
Feature Fusion
Combine extracted features, such as motion features plus heart-rate features for activity context.
Decision Fusion
Combine outputs from separate detectors, such as independent obstacle and object decisions.
State Fusion
Track a changing state over time with methods such as complementary filters, Kalman filters, or particle filters.
Overview Knowledge Check
16.3 Roles and Complementary Filter
A good introductory fusion design begins with the state variable. For a small IMU example, the state may be device tilt angle. The gyroscope updates quickly and captures short-term motion, but integrated gyro rate drifts over time. The accelerometer can estimate gravity direction over longer intervals, but it is noisy during vibration or acceleration. A complementary filter combines the short-term gyro estimate with the long-term accelerometer correction.
Worked example: one complementary-filter tilt update previous fused angle: 10.0 deg gyro rate: 20.0 deg/second time step: 0.020 second accelerometer tilt estimate: 8.0 deg alpha: 0.98 gyro prediction: 10.0 + (20.0 x 0.020) = 10.4 deg fused angle: (0.98 x 10.4) + (0.02 x 8.0) = 10.352 deg interpretation: The gyro carries most of the fast motion for this update. The accelerometer gently pulls the estimate back toward gravity. The alpha value is a design choice that must be validated for the device, motion pattern, vibration, and latency target.
Practitioner Knowledge Check
16.4 Fusion Quality Constraints
Fusion improves decisions only when the inputs carry useful, timely, and sufficiently independent evidence. If two sensors share the same bias, combining them can make the estimate look more confident without making it more correct. If timestamps are misaligned, a fast sensor and a slow sensor may describe different physical moments. If a sensor health state is hidden, the fused result can keep using stale or invalid evidence.
The independence assumption is easy to overstate. Suppose sensor A reports 10.0 units with random uncertainty of about 0.5 units and sensor B reports 10.4 units with the same uncertainty. If their errors are independent, a simple average gives 10.2 units and the random uncertainty can shrink because the noise sources partly cancel. But if both sensors were calibrated with the same offset reference that is +0.4 units high, the average is still biased. The fused output may display a smaller random-error band while the real value remains shifted in the same direction.
Shared-bias example sensor A: 10.0 units, random uncertainty about 0.5 sensor B: 10.4 units, random uncertainty about 0.5 simple average: (10.0 + 10.4) / 2 = 10.2 if errors are independent: random noise is reduced by averaging if both sensors share a +0.4 calibration bias: the average still carries the same hidden offset publish the common calibration source as a risk, not just the smaller-looking random uncertainty
Timing can create a different kind of false confidence. An IMU may update at 100 Hz while GPS updates at 1 Hz. A valid fusion design states whether it buffers, interpolates, predicts the slow measurement forward, or rejects stale evidence. Without that rule, the filter may combine a current acceleration sample with a position fix from a different maneuver and then blame the disagreement on sensor noise.
Under the hood, every fused estimate should therefore carry three kinds of evidence: the measurement values, the timing relationship among them, and the error relationship among them. That record is what allows a later reviewer to separate random noise, shared calibration bias, stale input, saturation, and true state change.
Timing
Fusion needs timestamp rules, buffering, interpolation, or rejection so inputs represent the same state interval.
Uncertainty
Weights and filters should reflect noise, drift, calibration quality, missing data, and current operating conditions.
Independence
Redundant sensors help most when their errors are not driven by the same cause. Shared bias can defeat simple averaging.
Observability
The selected sensors must actually provide enough information to estimate the state; otherwise the model may infer more than the evidence supports.
Under-the-Hood Knowledge Check
16.5 Summary
Sensor fusion improves IoT estimates by combining evidence from sensors that see different parts of the system state. The durable starting point is not an algorithm name; it is a fusion contract that records the state, sensor roles, fusion level, timing, uncertainty, conflict policy, validation target, and degraded modes. Complementary filters, Kalman filters, particle filters, weighted estimates, and decision voting are useful only when those boundaries are explicit.
Fusion is trustworthy when it keeps uncertainty visible. A fused output should say what state was estimated, which evidence contributed, how timing and conflicts were handled, and when the estimate must be retested.
16.6 See Also
Data Fusion Architectures
Place fusion at the device, gateway, cloud, or application layer with clear ownership.
Complementary Filters for IMU Data
Extend the introductory complementary-filter example into IMU orientation practice.
Kalman Filter for IoT
Track state and uncertainty when the system model and measurement model are explicit.
Data Fusion Best Practices
Review validation, degraded modes, calibration, and production monitoring for fusion systems.