Robotics · 2026
ARGUS — Autonomous Radiation-Guided SLAM
A mecanum-wheeled robot that maps an unfamiliar indoor space, measures the radiation field as it drives, and refuses to cross ground it has measured as hot — or hasn't measured at all.

A note on confidentiality. This project was carried out on placement at a national research facility. Because of the sensitivity of the work and the environment it was built for, this write-up stays at the level of engineering ideas. Specific methods, measurements, configuration details, the facility, and the instruments involved are deliberately left out. What follows is the shape of the problem and how I approached it — not a manual, and not a data release.
The problem
Some indoor spaces can't be surveyed by walking through them with a meter in your hand — either because the layout is unknown, or because you'd rather a person weren't the one standing in the room while it's measured. The task I took on was to build a small mobile robot that could do the walk instead: drive itself around an unfamiliar indoor space, build a map of it as it went, measure the radiation field at every point it passed over, record those readings onto the map, and — crucially — refuse to drive across ground it had measured as contaminated, or had not measured at all.
That last clause is the whole trick. A robot that maps a hazard but then drives straight through it hasn't understood the hazard. Making the measurement actually constrain the movement is where most of the engineering went.
The platform
The robot — I called it ARGUS, for Autonomous Radiation-Guided Unified SLAM — is a compact mecanum-wheeled base, chosen so it can move sideways and rotate in place inside cluttered, narrow interiors. It carries a 360° LiDAR and a depth camera for mapping, and a hand-held survey meter for the radiation reading. Everything runs onboard on a single-board computer, inside a container, controllable either from a simple GUI panel or over a remote terminal — the goal being that someone without robotics expertise could actually operate it.

How it fits together
There are four ideas stacked on top of one another, and each only works because the one beneath it does.
Knowing where you are. Wheel encoders give a smooth but slowly drifting sense of position. LiDAR-based SLAM corrects that drift against a globally consistent map. Together they give every sensor reading an actual place in the world — which is the precondition for everything else.
Reading the field correctly. The survey meter speaks over its own link at roughly one reading per second. Decoding that stream into correctly scaled physical values — and, harder, keeping the link alive across a long mapping run without phantom dropouts — was more work than it sounds. The reference I validated against was the instrument's own display: internal consistency proves nothing, because a decoder that is wrong by a constant factor agrees with itself perfectly.

Putting the reading in the right place. A reading belongs where the detector was, not where the robot's centre was — those differ by a fixed offset in the geometry, and ignoring it smears the map. Corrected readings accumulate into two separate grids: a conservative one for human review that never guesses, and a strict one for the planner that has to.
Letting the map steer. The path planner treats a measured hot region as exactly as impassable as a wall, and treats unmeasured ground as off-limits too. On top of that sits frontier exploration: the robot repeatedly drives to the nearest unexplored boundary until there are none left, so the survey completes itself.

Operating it
A survey is started from a browser control panel rather than a terminal: begin a run, watch the map fill in, save the 2D and 3D maps, and open the accumulated readings as a heatmap. The point was that the robot should be usable by whoever needs the survey, not only by whoever built it.

What I learned
The most useful lesson wasn't about any one sensor — it was that in a layered system, a fault never shows up where it lives. Odometry that lies quietly at the bottom of the stack presents, several layers up, as a radiation-mapping bug, and you can lose a long time debugging it in the wrong place. I ended up validating the system strictly bottom-up: no layer was trusted until the one below it had passed a concrete, falsifiable test of its own. That discipline was the real deliverable.
Honest limits
The autonomous, radiation-aware behaviour was demonstrated working on the physical robot. I'm also careful, in the full internal writeup, to distinguish what was delivered from what was demonstrated during development — they weren't identical, and pretending otherwise would be the wrong kind of confidence. Portfolio pieces tend to round everything up to "it worked"; the more interesting story is usually in the caveats.
Documents
- Portfolio one-pager (PDF) — the project at a glance, with figures.
- Sanitised public report (PDF, 22 pages) — a redacted version of the internal final report: full chapters, with the facility, personnel, quantitative data, instrument protocol and reproduction appendices removed.
The detailed engineering, operations, and handover documentation is held confidentially and is not published here. Happy to talk about the approach in general terms.