Evgeniia Slepynina, Senior Robotics Software Engineer with 10+ years across research and industry, developing autonomous vehicles, mobile robots, and distributed real-time systems. Worked with a Clearpath Husky A200 fleet, simulated in Gazebo Classic 11 under ROS 2 Humble. The platform itself was existing; what I built for this hackathon was the AI-monitoring layer on top of it — the mission orchestration, telemetry pipeline, and full RideScan API integration for a repeatable multi-robot inspection scenario.
Autonomous ground patrol of a tank farm: a standard piece of oil-and-gas infrastructure where distributed surface assets need visual inspection between scheduled human rounds. A fleet of three Husky A200 robots traverses predefined waypoints across six sectors, stops at each tank for two seconds, reads simulated pressure and methane values, and outputs a continue / flag / escalate decision per inspection.
Safety monitoring matters here because the failure modes are subtle: a drive that starts skid-steering off nominal, a dwell that stretches by half a second, an acceleration profile that shifts by a few percent. None of these will trip a hard rule, but any of them can be the first sign of a mechanical fault or a controller regression on a fleet meant to run unattended for weeks. Rule-based monitoring cannot catch this class of drift. A baseline-learned anomaly detector, in principle, can.
I built the full API pipeline as a sequence of 15 small, single-purpose Python scripts, mirroring the RideScan API surface: robot registration, mission creation, calibration file upload, calibration trigger and polling, inference upload and polling. Each stage writes its output IDs to environment variables, so the pipeline is resumable and each script is independently testable.
The robot was registered as type WHEELED_MOBILE and the mission as a deterministic tank inspection: identical waypoints, thresholds, and decisions across each of the 15 required calibration runs. Determinism was enforced in the scenario runner code — same PD-controller parameters, same dwell timing, same threshold logic, because RideScan calibration expects a single task replicated 15 times.
Telemetry was captured as ROS 2 rosbag2 in MCAP format and converted to CSV via a custom mcap_to_csv.py converter. Three key technical decisions shaped the pipeline. First, sim-time as the base timeline: mission barriers are published in wall-time; odometry, IMU, and GPS carry sim-time in the header. The converter uses /clock to build a wall-to-sim mapping and trim the mission window in sim-time, then interpolates sensor streams onto odometry timestamps. This gives a physically coherent timeline where timestamp in the output CSV is sim-seconds relative to mission start.
Second, the full 9-feature WHEELED_MOBILE schema: pose (x/y/z + roll/pitch/yaw), twist (linear + angular), linear acceleration, and GPS. All 15 exported files passed validation with zero NaN or Inf. Third, synchronization barriers: a mission_orchestrator node ensures all three robots start simultaneously (after all have reported first odom) and stop cleanly, so telemetry can be trimmed to exact mission boundaries.
Beyond the minimum path, I built statistical analysis tooling (compare_runs.py and analyze_risk_patterns.py) for pairwise trajectory comparison and z-score analysis — this became critical for interpreting the results.
Inference results across three file categories: calibration runs 01–05 and 10–15 scored 0.00–0.01 (normal); calibration runs 06–09 scored 22.7–32.9 (attention); the 2× speed anomaly scored 100.0; a control run (identical config, unseen by the model) scored 97.81.
The 2× speed anomaly was cleanly detected at 100.0 — the model does catch a real behavioral deviation. Three files in the calibration set itself scored 22–33, which points to insufficient model convergence rather than clean baseline learning.
The most instructive finding was the control run. I generated a 16th run with the same mission configuration and fed it through inference. It scored 97.81 — almost as high as the true anomaly. Statistical comparison against the calibration set showed all aggregate features matched within 2%, but the mission duration z-score was +2.18, indicating the control run was outside the tight baseline distribution. Gazebo cold-start non-determinism creates enough micro-variation to push a normal run into anomaly territory.
RideScan team confirmed in a follow-up call that the model was undertrained — 100 epochs on 15 near-identical points memorize rather than generalize. Reducing to 30 epochs brought the control score to 86.62 but raised calibration variance to 37–55, a reverse trade-off.
My side: I planned a re-calibration with fresh baseline runs that had realistic variance (varied start delays, warm-up runs, controlled parameter jitter). I hit a hard blocker in my custom batch recorder — a signal-handling bug in telemetry_recorder accumulated zombie ros2 bag record processes over long sessions. I found and fixed the bug (SIGINT direct to subprocess with SIGTERM/SIGKILL fallback), but by then laptop state had degraded enough that fresh runs were unreliable. Fifteen fresh baseline runs were not collected, and the Stage 3 video was not delivered on time.
Interface with RideScan: the 15-identical-runs calibration requirement collides with any simulator with cold-start non-determinism. Hypothesis: in practice you need to intentionally inject realistic variance for the baseline distribution to be useful.
Honestly: no visibility into architecture, epoch count, loss curve, or per-file reconstruction error made it hard to diagnose the undertraining until after the organizer explained it.
A working end-to-end RideScan API integration on a WHEELED_MOBILE platform, with a reproducible calibration set and a clear diagnostic of a subtle baseline-modeling failure mode.
The next research direction I would like to pursue is a channel-degradation study using Temporis, an in-house tool for simulating communication link deterioration (latency, jitter, packet loss, out-of-order delivery, clock drift). The question is whether a baseline anomaly detector can distinguish robot behavior that is anomalous from a data channel that is degraded — two operationally distinct scenarios that require different dispatcher responses. Temporis can inject deterministic distortion into the ROS 2 message stream before recording, generating labeled corrupted datasets from a single clean run without re-simulating the mission.
