Builder Case Study

The problem you set out to solve

The primary scenario was a collaborative food-processing task, specifically a "Sandwich Making Café" operation. The objective was to investigate whether increasing a robot's operating speed results in measurable changes in telemetry, execution characteristics, and RideScan's risk assessment. Safety monitoring is particularly important in this context because a robot may continue to complete its task successfully while its underlying motion behavior changes. This study therefore aimed to determine whether higher operating speeds inherently lead to proportionally higher operational risks.

Your integration with RideScan

• Telemetry Pipeline: I developed a custom ROS 2 telemetry logger to record robot behavior at approximately 10 Hz.
• Data Sent: The collected data included TCP position (X, Y, Z), TCP orientation (Roll, Pitch, Yaw), six joint positions, six joint velocities, the RG2 gripper position, and exact timestamps.
• Mission Structure & Calibration: I recorded healthy robot executions and uploaded the CSV telemetry logs via the /api/calibrate endpoint so RideScan could learn normal behavior and establish a healthy operational baseline.
• Inference Process: I uploaded active runs to the /api/process endpoint using unique blob names to generate risk scores by comparing the execution against the calibrated baseline.
• Beyond the Minimum Path: Because there was no ready ROS2 Humble package for the RG2 gripper, I built custom URDF/Xacro models and integrated the gripper manually. Additionally, I developed a custom Gazebo plugin and adapted a link-attacher service to handle complex grasping physics.

What the RideScan data showed

• Risk Variability: The data revealed significant run-to-run risk score variability, showing some low-risk executions alongside high-risk peaks.
• Early Wear: The system successfully triggered an "Early Wear Detected" indication during the analysis period.
• Velocity vs. Risk: Crucially, testing across velocity scaling factors of 0.5, 0.7, and 1.0 proved there is no simple linear increase in risk as velocity increases.
• Outcome: The data confirmed that higher speed alone does not determine risk; rather, RideScan evaluates the overall execution signature, heavily influenced by joint velocity behavior, TCP trajectory changes, pose deviations, and execution consistency.

5. Limitations and honest findings

• Physics Synchronization: MoveIt does not directly control Gazebo physics, which forced me to use fake controllers for planning and real controllers to synchronize execution.
• Grasping Physics: Gazebo grasping physics were highly unreliable, causing objects to slip or jitter. I had to heavily tune friction, damping, and inertia parameters, and ultimately rely on a LinkAttacher plugin.
• Collision Modeling: The robot initially collided with objects despite collision models, requiring me to manually update and synchronize the planning scene between MoveIt and Gazebo.
• Dependency Issues: I faced severe version conflicts and broken repositories, requiring me to manually fix dependency versions and rebuild packages from the source.

6. Results and what is next

• Integration Success: I successfully integrated UR5e ROS 2 telemetry with RideScan APIs for automated calibration and inference processing.
• Testing Volume: I successfully uploaded 90 out of 90 targeted inference runs across three different velocity conditions.
• Operational Insight: RideScan successfully enabled monitoring far beyond simple mission success or failure, proving its ability to help identify underlying behavioral changes and potential operational risks before a critical failure occurs.