Background: MSc AI student at the University of Edinburgh with a background in robot learning, computer vision, and computer science.
Platform: ANYmal C quadruped industrial inspection robot, simulated in NVIDIA Isaac Sim.
What I built: AI capabilities built on top of an existing inspection platform. RideScan remains the core anomaly detector, while I developed additional layers for fault diagnosis, spatial risk localisation, and fleet-level monitoring using its risk scores.
ANYmal C quadruped runs a fixed inspection patrol, similar to the continuous and repeatable routes used by industrial robots in chemical plants and warehouses. Safety monitoring is critical because many failures develop slowly and silently like a bearing wearing out, a sensor drifting, or a motor weakening, remaining undetected until they become catastrophic. However, knowing that a patrol is “risky” is not enough to take action. Two key questions remain unanswered: what is actually wrong, which component has failed and why, so technicians know what to inspect; and where did it happen, so the robot can identify the exact location of a hazard along its route. This transforms the patrol from simply detecting robot degradation into an active inspection of the environment itself.
A lightweight Python client connects to each RideScan REST endpoint. The pipeline is simulation-agnostic and follows a documented telemetry interface, which allows me to work with Isaac Sim today and a real ANYmal running ROS 2 in the future without changing the integration layer.
The system collects 100 Hz robot telemetry, including 12 joint positions, velocities, and torques, IMU data, four foot-contact forces, and base pose. This data is converted into RideScan's LEGGED_MOBILE schema and validated before upload.
The workflow follows RideScan's structure: Robot → Mission → Instance → Calibration → Inference. A robot and mission are registered, healthy patrol runs are uploaded as the calibration baseline, and fault runs are then evaluated to obtain risk scores.
Some Key design decisions include:
Six robots produced distinct risk scores (13.5–43.97), reflecting different injected wear conditions. The highest-risk robot was immediately identifiable from the fleet view.
One robot exceeded the alert threshold before an acute fault occurred, so I hypothesise that gradual wear can be detected early. Other robots remained below the threshold during a full 90-second patrol.
Window-based scoring identified the exact route location of an injected hazard, and produced a clear risk spike while remaining low across healthy sections of the patrol.
The diagnosis layer achieved 89.4% top-1 fault classification accuracy across 1,368 labelled runs, and identified both the fault type and affected joint with confidence estimates.
I found that diagnosis accuracy depends on the severity range seen during training. The model performed well at moderate severity (~0.6), but when pushed to higher severity (~0.85), outside its training range, confidence and accuracy decreased.
I observed that localisation varies by fault type. Bearing faults were localised accurately (~99%), while actuator weakening was harder because the controller compensated through neighbouring joints, making the true fault location less obvious.
I also found limits in explaining RideScan's scores. Black-box tests that modified individual joint signals did not reliably reveal which components contributed to the risk.
Finally, inference latency varied significantly, from seconds to several minutes, which made robust retries and resumable processing necessary for deployment. I had to maintain a cache to show results.
