Sensor Fusion Calculator
Several sensors, several answers. This combines them into one estimate weighted by how much each can be trusted, and tells you when they disagree more than they should.
Inputs
One row per sensor, all measuring the same thing in the same units. The error column is how far that sensor is typically off, which you get by taking a few readings of a known value and seeing how much they scatter.
Results
Combined estimate
—
Its expected error
—±
Best single sensor
—
Better than that alone by
—%
Do they agree?
—
Most out of line
—
If you just averaged them
—
Sources
—
How much each one counts
| Source | Reading | Error ± | Weight | Off the combined | In its own error terms |
|---|
How this is calculated
Averaging sensors treats them as equals, which throws away the best thing you know: some of them are better than others. A tracking wheel accurate to a millimetre should not be outvoted by a GPS that wanders by three centimetres.
Weight by confidence, not by count
The right weighting is by the inverse of each sensor's variance, which is its error squared:
weight = 1 ÷ error² combined = Σ(weight × reading) ÷ Σ(weight) its error = √(1 ÷ Σ(weight))With your numbers
Squaring is what makes this decisive. A sensor three times more accurate than another gets nine times the say. That is not arbitrary; it is the combination that minimises the expected error of the result, and no other weighting does better.
Combining beats every individual sensor
The result is always at least as good as your best single source, and usually better. Even a mediocre sensor adds a little information, so long as its error is honest and independent of the others.
That last condition matters. Two encoders on the same slipping wheel are not independent: they will agree with each other and be wrong together, and this maths will report false confidence. Independence is what makes fusion work, so prefer sources that fail in different ways.
Disagreement is information
If a sensor sits several of its own error bars away from the combined answer, one of two things is true: the sensor has failed, or the error you gave it is too optimistic. Either way it is worth knowing mid-match, and it is the cheapest fault detection available.
The usual response is not to discard the outlier automatically, but to stop trusting the fused answer until the sources agree again.
Getting the error figures right
Everything here depends on those numbers, and a sensor given an unrealistically small error will dominate the result and drag it wrong. Measure them: put the robot at a known position, take twenty readings from each source, and use the spread. Guessing them defeats the purpose.
Sources & assumptions
No VEX data is used. This is inverse-variance weighting, the standard result for combining independent estimates, applied to your own numbers.
Assumes the sources are independent and unbiased, and that the error figures are realistic. It cannot detect a sensor that is consistently wrong in the same direction, because a steady bias looks identical to a correct reading from the outside.
This is the static case. A real robot also has motion between readings, which is what a Kalman filter adds on top of exactly this calculation.
Save this run, and compare
Keeps what is on screen so you can change something and see both sides of the change. Saved in this browser only, never uploaded.
Save this as evidence
Collects what you entered, what came out, how it was worked out, and anything the tool flagged, with a timestamp and a version so someone else can reproduce it.
This is evidence, not a notebook entry. It deliberately does not write your problem statement, your reasoning, or your conclusion, because under RECF rules an Engineering Notebook has to be the students' own work and no tool may generate or organise its content. Take the numbers, decide what matters, and write it yourself.