My name is Abhiroop Bhavsar, a Mechanical Engineering graduate from IIT Jodhpur with a strong interest in robotics, autonomous systems and AI-driven robotic systems.
I chose the TurtleBot3 Waffle AMR running entirely in Gazebo simulation. Instead of designing a robot from scratch, my focus was on building a complete telemetry collection and RideScan integration workflow that could be reused on similar ROS2-based autonomous mobile robots.
The robot performs warehouse inventory scanning by following a predefined route through storage aisles and over a ramp. This mission was selected because every run follows the same path, speed, and operating conditions, providing the repeatability required for reliable RideScan calibration.
Warehouse inventory robots are expected to repeat the same task hundreds of times every day. Although a mission may complete successfully, gradual degradation in robot behaviour such as wheel slip, navigation drift, or unstable motion can silently reduce inventory accuracy without generating an obvious failure. I wanted to explore whether RideScan could continuously monitor telemetry from an autonomous warehouse robot and identify behavioural changes before they become operational problems.
The warehouse environment also included a ramp so that the robot naturally experienced changes in pitch and vertical motion. This introduced richer telemetry while still representing a realistic warehouse scenario rather than an artificially created anomaly.
The project was built around a fully automated integration pipeline. A TurtleBot3 Waffle was simulated in Gazebo while a custom ROS2 Python logger subscribed to the /odom and /imu topics. Using ApproximateTimeSynchronizer, both streams were synchronised and recorded into CSV files.
Fifteen repeatable missions were recorded for calibration and sixty additional missions were generated for inference.
Before automation, every RideScan API endpoint was manually verified in Postman.
I then developed a Python command-line tool that automated the complete workflow: robot creation, mission creation, calibration file upload, calibration, process file upload, inference execution, and status monitoring. The tool also included batching, retry logic, and progress tracking so that large mission datasets could be processed with minimal manual intervention.
After automation, I continued verifying calibration and inference responses through Postman to validate that the automated workflow produced the expected API behaviour.
My objective was not only to complete the hackathon but also to create a reproducible integration workflow that another ROS2 developer could easily adopt.
RideScan successfully calibrated the uploaded baseline data and generated risk scores for the inference missions. The dashboard provided historical mission analytics, allowing trends to be visualised over time instead of evaluating isolated runs.
The observation was that the normal warehouse missions produced more variation than expected despite following an identical path. The result show an unexpected oscillating risk-score trend despite identical robot behaviour across runs.
To validate that the pipeline itself was functioning correctly, I created a dedicated extreme anomaly file. RideScan assigned it a Risk Score of 100 exactly as expected, confirming that calibration, inference, and API integration were operating correctly. Because the deliberately created extreme anomaly received the expected Risk Score of 100, I concluded that the integration pipeline was functioning correctly. The remaining variation was therefore more likely caused by simulation characteristics than by failures in the RideScan integration.
One unexpected observation was a Peak Score of 5660/100 together with oscillating risk-score behaviour, despite repeatable robot motion. Investigating this became an important part of validating the integration.
Experienced the oscillation behavior in risk score graph.
Uploading all sixty mission files together caused the processing task to exceed the server timeout limit (2000 seconds). I redesigned the workflow in my python script by batching uploads into groups of five with delays between batches, allowing the complete dataset to be processed successfully.
By the end of Phase 3, I had a complete RideScan pipeline for the AMR: a calibrated robot and mission, cleaned calibration data, 60 ordered process runs, inference results in the RideScan dashboard, and local scripts that another engineer can run or adapt. Next I would connect the same flow to live ROS 2 logging, add camera-side scan-count metrics, and test on a physical AMR so RideScan can compare real wheel slip, payload changes.
