Why Your Sensors Lie to You (And What To Do About It)

I spent three years debugging a robot arm that kept overshooting its target by exactly 12 millimeters on cold mornings. The model said it should be accurate to within 2mm. The physics said nothing was wrong. The sensor readings said nothing was wrong. The part just didn't land right until the shop heated up. The problem wasn't calibration or code. It was the gap between Sensing Feeling And Action — the space where raw data meets the decision to move. Most people treat it as three separate steps: measure something, decide what it means, then act. That's not how it works in practice. The sensing changes the feeling. The feeling changes the action. The action changes what you sense next. They're one system, not a pipeline.

The Sensing Feeling And Action Loop

Start with the loop, not the definitions. When you touch a hot stove, you don't first sense heat, then feel pain, then pull your hand away. You sense and feel at the same time, and the action is already unfolding before the "feeling" part finishes processing. The loop runs faster than your awareness of it. In engineering terms, this is a closed-loop control system with feedback latency. The "feeling" part is your model of what the sensing means relative to your goals. If your model is wrong, your action is wrong, even if your sensing is perfect. I ran into this when working with a pressure-sensing system for packaging. The sensors were calibrated to ±0.5% accuracy. The product kept getting crushed. Turns out the "feeling" model assumed uniform material stiffness, but the foam inserts varied by 40% between batches. The sensing was fine. The action (closing force) was fine. The model connecting them was wrong. We fixed it by adding a compliance test step that took 3 seconds per unit and eliminated the crushing entirely. The counter-intuitive part: better sensing often makes things worse if your feeling model hasn't caught up. More data doesn't help when your interpretation is off. I've seen teams add expensive LiDAR to a navigation problem that was actually solved by better weight distribution on the chassis. The sensing was the distraction.

Where This Breaks Down

Let me be blunt about the limitations. Closed-loop sensing-action systems fail in three common ways: Latency mismatch: If your action hardware is slower than your sensing refresh rate, you're making decisions based on stale data. A 10ms sensing delay on a system that actuates in 50ms means you're responding to where things were, not where they are. This shows up as oscillation — the system corrects too late, overcorrects, then corrects again. Model drift: Your "feeling" model degrades over time. Temperature changes wear components. Sensors age. I had a torque sensor that drifted 8% over six months without any alarm. The system kept compensating, but the compensation itself was based on incorrect assumptions about why the torque was changing. By month eight, the parts were being assembled with 15% variance instead of the target 3%. Over-sensing: Adding more sensors doesn't improve accuracy if your processing can't handle the data rate. I worked on a vision system that went from 4 cameras to 8 because "more data is better." It was worse. The processing latency doubled, and the action decisions came out 200ms later. The extra cameras only helped if you discarded half the frames anyway. The workaround for model drift: Run a daily self-test that exercises every sensor-actuator pair through a known sequence. Log the deviation. If it exceeds threshold, flag it for calibration but keep running. Don't shut down the line — just note that accuracy has degraded to X%, and adjust your tolerances accordingly.

Practical Debugging Steps

When Sensing Feeling And Action isn't working right, here's what I check, in order: 1. Verify the sensing chain first. Use a known input — a calibrated weight, a fixed temperature source, a reference voltage. Does the reading match? If not, the problem is upstream. If yes, move on. This takes 5 minutes and saves hours of blame-shifting. 2. Check the action chain. Command the actuator directly, bypassing the sensing model. Does it respond as expected? If the motor spins when commanded but the arm doesn't move, you have a mechanical issue, not a sensing or decision issue. 3. Isolate the feeling model. Feed it synthetic sensing data with known outputs. Does it produce the expected action? If it fails here, the model is wrong. If it passes, the model is fine and the problem is in the real-world data. 4. Measure latency end-to-end. Time from sensing event to action completion. Break it down: sensing latency, processing latency, command transmission latency, actuator response latency. Find which link is the bottleneck. 5. Check for feedback loops. Are you sensing the output of your action and using that to adjust? That's correct — it's called feedback. But are you also sensing the input to your action and using that to predict the output? That's called feedforward. Using both without proper coordination causes double-counting and oscillation. I learned this the hard way with a flow control system. The valve position was being adjusted based on flow rate (feedback), but the controller was also predicting flow based on valve position (feedforward). The prediction and measurement conflicted, and the valve would hunt between positions every 2 seconds. Switching to feedback-only stabilized it immediately. The feedforward model was nice in theory but added instability in practice. When to give up on a sensing approach: If you've verified the chain, isolated the model, and the system still behaves unpredictably, consider whether you're trying to sense something that shouldn't be sensed directly. Sometimes the solution is to sense a proxy variable and infer what you actually need. Temperature is easier to sense accurately than thermal stress. Voltage is easier than power delivery quality. Measure what's stable, calculate what's useful. The edge case nobody warns you about: Sensor saturation. Most sensors have a linear range and a saturation point. If your system occasionally hits saturation, the readings look fine until they don't. I had a force sensor that read correctly up to 95% of its range, then dropped off nonlinearly. The system was designed for 90% peak load, but transient spikes hit 110%. The sensor didn't alarm — it just reported lower values than reality. The action system responded to fake low readings and the mechanism failed at the 89th cycle. Add a saturation detector that flags readings above 95% range and treats them as unknown, not as valid low values.