Builder Case Study
Davies Iyanuoluwa Ogunsina is a Robotics Engineer, Roboticist, Consultant, and open-source robotics advocate based in Lagos, Nigeria, with over four years of experience designing, developing, and deploying autonomous robotic systems. His expertise spans ROS 2, Nav2, SLAM, Gazebo simulation, sensor fusion, robot perception, vehicle control, autonomous navigation, hardware integration, and safety-critical robotics, with hands-on experience building and deploying solutions on both simulated and physical robotic platforms.
A motivated and goal-oriented engineer, Davies is passionate about advancing robotics and autonomous systems through robust, production-ready software. His technical background covers the complete robotics stack, including control, perception, mapping, localization, navigation, manipulation, and autonomous decision-making. He has extensive experience with Simultaneous Localization and Mapping (SLAM), ROS, ROS 2, Nav2, Gazebo, and real-world robotic deployments, enabling him to contribute across the full lifecycle of robotic system development from architecture and simulation to hardware integration and field deployment.
His contributions to the global robotics community have been recognized through his selection as a two-time ROSCon Diversity Scholar, attending ROSCon 2023 in New Orleans, USA, and ROSCon 2024 in Odense, Denmark. He also presented at ROSDev Day 2023, where he shared advanced robotics methodologies and practical solutions for autonomous systems, demonstrating both technical depth and a commitment to advancing open-source robotics.
Professionally, Davies has worked as a Robotics Engineer and Roboticist across multiple organizations, contributing to the design and development of autonomous robotic systems that solve real-world problems. His experience spans robot software architecture, perception pipelines, navigation systems, control algorithms, simulation environments, hardware integration, and autonomous robot deployment across research and industry applications.
Beyond traditional mobile robotics, his current work focuses on perception-aware navigation, vehicle control, autonomous driving technologies, and safety-critical systems that enable reliable autonomous operation on existing vehicle platforms. He is particularly interested in building robust autonomy stacks capable of operating safely in complex, dynamic environments while integrating seamlessly with real hardware and vehicle dynamics.
In addition to his technical expertise, Davies is a strong advocate for collaborative innovation, open-source software, and inclusive growth within the robotics ecosystem. He is passionate about mentoring aspiring roboticists, fostering technical excellence, and empowering the next generation of engineers across Nigeria and Africa through knowledge sharing, community engagement, and technical leadership.
For the RideScan Integration Challenge, Davies built upon Davie, his differential-drive mobile robot platform based on ROS 2 Humble, extending an existing Nav2 + SLAM Toolbox architecture that he had previously developed. Rather than building a robotics platform from scratch, he customized the platform specifically for the challenge, creating the mission-focused robot Davie-Perimeter-Bot. The project demonstrated autonomous perimeter patrol capabilities integrated with RideScan's safety platform, combining localization, navigation, telemetry collection, mission execution, and autonomous safety monitoring into a production-style robotics workflow.
The problem you set out to solve
Warehouse perimeter inspection, a robot autonomously patrolling a fixed boundary loop, checking access points and flagging anomalies without supervision, is one of the highest-frequency real-world autonomous robot deployments today, with single facilities running 50–200 loops a day, unsupervised for hours at a time. Safety monitoring matters here precisely because degradation in these deployments is gradual and often invisible until it causes a missed anomaly, a hardware failure, or a safety incident. A robot's own control stack has no way to notice that it's behaving differently from how it behaved yesterday, it can only notice if something breaks outright. That gap is what I wanted RideScan to fill.
Your integration with RideScan
The integration has two stages. Stage 2 established a calibration baseline: Davie ran the same waypoint perimeter loop 15 times under deterministic simulation conditions, while a bridge node subscribed to /odom, /scan, and /cmd_vel and wrote each run out as a single timestamped CSV, one Mission Instance per run. Keeping the route, environment, and starting pose identical across all 15 runs was a deliberate choice: it meant RideScan learned a tight behavioral fingerprint rather than a wide, averaged envelope, since the only variation between runs was floating-point noise in Nav2's path execution.
Stage 3 turned that baseline into a live safety system. A ridescan_safety_monitor_node buffers /odom telemetry into rolling 30-second batches, derives linear acceleration via finite difference of consecutive velocity readings (avoiding a dependency on a physical IMU topic), and uploads each batch to RideScan's process_file endpoint. The returned risk score is published to /ridescan/risk_score, and if it meets or exceeds a locally configured threshold, the node publishes True to /ridescan/safety_stop. The waypoint follower subscribes to that topic and immediately zeroes /cmd_vel, pausing the mission until the score drops back down, at which point it resumes on its own, no human decision required in the loop.
The key technical decision I'd highlight: my local risk_threshold is set to 40, deliberately below RideScan's own platform-defined Critical Threshold of 50. That was intentional: it biases the system toward earlier intervention, stopping the robot before RideScan's own dashboard would even classify the run as critical, rather than waiting for the platform's official designation. Beyond the minimum integration path, I also built a real-time matplotlib path visualiser that renders Davie's trajectory live and overlays red diamond markers at the exact coordinates where a risk score breached threshold, and wired Twilio SMS alerting for both stop and recovery events so a human operator is notified the moment something goes wrong.
What the RideScan data showed
On RideScan's own dashboard, the Warehouse-Perimeter-Inspection mission's risk curve started around 20 at execution cycle 0 and climbed steadily, crossing the platform's Critical Threshold of 50 by cycle 1 and peaking near 100 by cycle 5. RideScan's predictive layer also flagged the mission with an 'Early Wear Detected' warning, a trend-level signal sitting around 76 to 80, distinct from any single threshold breach. Rather than treat these elevated scores as a fluke, I traced them to two concrete, expected causes: a live run driving faster than the calibrated cruise velocity (which shifts acceleration, turn timing, and deceleration signatures away from the baseline), and odometry wheel slip, where commanded motion and reported odometry diverge in a way the calibration baseline doesn't expect. Both are exactly the kind of subtle, correlated deviations a learned behavioral baseline is designed to catch that a simple rule-based check would miss.
Limitations and honest findings
The primary limitation of this project is that it was developed and validated entirely in a Gazebo simulation environment. While the simulation provided a controlled and repeatable setting for calibration, mission execution, and RideScan integration, it does not fully capture real-world conditions such as wheel slip, sensor noise, communication latency, or varying terrain. As a result, the next step would be to deploy the system on physical hardware to evaluate its performance under real operating conditions.
During development, I also encountered intermittent HTTP 502 gateway responses from the RideScan API while uploading telemetry. To make the integration more robust, I implemented verification logic to distinguish temporary server-side errors from successful uploads, ensuring telemetry files were not treated as failed submissions when they had already been received. This improved the reliability of the upload pipeline without affecting mission execution or telemetry collection.
Overall, the project successfully demonstrated autonomous mission execution, telemetry collection, and integration with the RideScan safety platform in simulation, providing a solid foundation for future validation on real robotic hardware.
6. Results and what is next
Stage 3 closes cleanly end to end: live telemetry streams to RideScan, risk scores return in near real time, the robot autonomously halts on a breach and resumes on recovery, and a human is alerted by SMS throughout. Next, I'd add automated drift detection that flags a multi-batch upward trend even before any single batch crosses the safety-stop threshold, per-phase thresholds that use the calibration data's own phase structure (dock exit, straights, turns, arrival) rather than one global cutoff, a graduated response that tries reducing velocity before a full stop for borderline scores, and real-hardware validation to see how the platform's insight holds up outside simulation.
