Indoor Tracking

Problem

Around 2016, computational design had architects hungry for evidence: if you could measure how a building was actually used, you could argue for how the next one should be designed. The catch was getting the data. GPS stops at the front door, and there was no cheap, deployable way to answer indoor questions like which desks are occupied, how people move between zones, or where the crowding is.

In my honours year at the University of New South Wales I got to work on exactly that with Arup and BVN: design, build, and deploy an indoor positioning system out of off-the-shelf parts, cheap enough to scatter through a real office. The research team was three students; the positioning system was my responsibility.

Approach

After surveying the options we settled on Bluetooth Low Energy (BLE) as the cheapest, most ubiquitous technology with a proven method behind it. The system has two device types:

• Beacons are small battery-powered tags that constantly broadcast a unique ID, worn by each participating employee, and
• Agents are Raspberry Pis in custom enclosures that scan for those broadcasts and upload each beacon ID with its signal strength.

Signal strength gives a rough distance, so with a map of where every agent sits, a beacon’s position can be estimated. Each agent forwards its readings to a small AWS pipeline (a live store for current positions, a time-series store for history) which a floor-plan view reads from. Querying the history surfaced occupancy hotspots in the office; the live store gave the near-realtime position of an individual.

Decisions

BLE over the alternatives. Wi-Fi RSSI meant leaning on infrastructure we didn’t control; ultra-wideband was accurate but expensive per node; camera-based tracking dragged in privacy problems we didn’t want near people’s desks. BLE was the pragmatic floor: cheap tags, cheap scanners, good-enough resolution for occupancy-scale questions.

Raspberry Pi agents over microcontrollers. A full Linux box per scanning point costs more than an ESP32, but it bought a real OS, Wi-Fi, Python, and remote SSH, so an agent in the field could be debugged and updated without a site visit. Given how many of these were going onto walls and poles, that mattered more than the unit price.

Custom enclosures. Each agent was 3D-printed and named, so a unit could be identified on sight when something went wrong in the field.

Outcome

The system was deployed at multiple client sites, scanning live across working offices and feeding the floor-plan visualisation.

The honest takeaway: I went in underprepared for what it takes to run a fleet of distributed hardware. The positioning maths was the easy part. The real lessons were in troubleshooting flaky units remotely, pushing software updates to machines I couldn’t reach, and keeping the database healthy as readings piled up. It reshaped how I think about anything that has to stay running rather than just demo once.

References

Student research at UNSW, in collaboration with Arup and BVN.