Your Building Is GPS-Denied

This week the robotics research community published a new framework called HUNT. It solves a specific problem: how do you build a drone that can navigate autonomously when GPS isn't available?

The answer, it turns out, has nothing to do with finding a better GPS. HUNT works by replacing the idea of a single authoritative position source with something more honest: a continuous estimate rebuilt from multiple imperfect signals. Inertial attitude. Barometric altitude. Visual motion cues. Target geometry. The drone doesn't know exactly where it is. It knows approximately where it is, updated constantly, from sensors that each tell a partial story.

I read that and thought: that's exactly what a building is.

The Single-Sensor Trap

Most building monitoring starts with one signal. A temperature sensor on the HVAC. A water detector near the sump. A smart plug measuring wattage on a pump motor. The technology is cheap, the installation is simple, and the initial data is genuinely useful.

But single-sensor monitoring has a ceiling. And it's lower than people expect.

Here's what I mean. A temperature sensor tells you the air temperature. That's it. It doesn't tell you whether the temperature is abnormal for the current occupancy level, the outdoor conditions, or the time of year. Without context, a 68-degree reading is just a number. With context, it's either normal or a sign that your HVAC is fighting a losing battle against something you haven't found yet.

A power monitoring plug on a sump pump is the same story. The pump draws current. The current fluctuates. Is that fluctuation a problem or just normal variation? A single-sensor system can set a threshold and alert you when the number exceeds it. But thresholds are blunt instruments. They miss slow-developing failures. They trigger false alarms on normal load variation. And they can't tell the difference between "motor is cycling strangely because the float switch is sticking" and "motor is cycling strangely because it's raining hard."

GPS-denied navigation has been trying to solve this exact problem for twenty years. The insight that finally worked isn't better hardware. It's better reasoning across imperfect hardware.

The Sump Pump Was GPS-Denied

I'll tell you what actually happened at the building I monitor.

The sump pump had a float switch issue. The motor was running under load without actually moving water — the float was sticking intermittently, making the pump think the pit was full when it wasn't. The motor wasn't burning out fast. It was burning out slowly. Not enough to trip a breaker. Enough to fail in about nine months if nobody caught it.

A single power monitoring sensor would have seen elevated wattage and either ignored it (below threshold) or alerted nonstop (threshold too low). Neither response is useful.

What the monitoring system actually did was correlate: power draw over time, time of day, outdoor rainfall data from a local weather API, and historical pump cycle baselines. When it flagged the issue at 3am, it wasn't because the current was above a number. It was because the pattern of that current over the previous 72 hours didn't match anything the system had seen before, given everything else it knew about that specific night.

That's sensor fusion. Not in the robotics-textbook sense of Kalman filters and state vectors. In the practical sense of asking: what does this reading mean given everything else I know right now?

The HVAC Problem Was the Same

The community center I monitor has forty devices across the facility. Early in the deployment, the building's energy bill was a mystery. The HVAC seemed to be working fine. No alarms. No obvious failures. Just a stubbornly high electricity cost that nobody could explain.

The answer surfaced after about six weeks of cross-referencing data. The HVAC was running at full capacity on weekends. Not because anything was broken — because nobody had ever correlated the booking calendar with the HVAC schedule. The building was conditioning air for 200 people on Saturday mornings when occupancy was near zero.

No single sensor could have caught that. The temperature readings looked fine. The power readings were within normal range. The HVAC status reported "operating normally" because it was operating exactly as scheduled. The problem was that the schedule was wrong, and the only way to see that was to look at three signals together: occupancy (from the booking calendar), power consumption (from the smart plugs), and HVAC runtime (from the building controller).

Fixing it cut energy costs by 42%.

What the Robotics Research Is Actually Telling You

The HUNT framework isn't interesting because it solves a drone problem. It's interesting because it formalizes something that good physical AI practitioners already do intuitively: reason from partial, noisy, overlapping signals rather than waiting for a definitive truth from a single authoritative source.

Buildings never give you a definitive truth. They give you temperature, power, humidity, occupancy, weather, schedule, history, and a dozen other partial pictures. The job of building intelligence is to build the best possible current estimate of what's actually happening from all of those partial pictures — and update that estimate continuously.

That's what HUNT does for drones. That's what good monitoring does for buildings.

This week also saw the release of FusionCore, an open-source ROS2-based sensor fusion SDK that handles exactly this kind of multi-source state estimation for robotics applications. The tools for this kind of reasoning are now open-source and accessible. The hardware to run them locally is cheaper than a monthly streaming subscription.

Where This Is Going

The edge AI hardware market hit its inflection point this year. The global market was $24.91 billion in 2025 and is projected to reach $118 billion by 2033. The reason isn't just raw capability — it's that the economics of routing sensor data to a cloud for analysis have permanently shifted against the old model. On-device inference is now cheaper and faster for most building monitoring tasks.

What that means practically: the $25 smart plug and $15 temperature sensor you're deploying today will have successors in 18-24 months that run small anomaly detection models on-device. The sensor fusion reasoning that currently requires a local server will move onto the sensor itself.

The buildings that are ready for that transition are the ones that have been collecting correlated, multi-sensor data long enough to have baselines. The buildings that aren't ready are the ones still running single-sensor threshold monitoring and calling it smart.

What I Do About It

Every building I instrument starts with a multi-signal baseline period. I don't tell the system what to look for. I let it build a picture of what normal looks like across power, temperature, occupancy, and time — usually for four to six weeks before I start trusting alerts as meaningful.

The alerts that come after that period are different in character from threshold alarms. They're anomalies in context: this reading is unusual given these other readings and this history. They're specific enough to act on and rare enough to trust.

That's the difference between a GPS and a GPS-denied navigator. One tells you where you are. The other tells you where you probably are, why, and how confident it is. For buildings, as for drones, the second answer is more useful than the first.