My name is Hean Beng Hoe and I'm a former project engineer from the automotive industry, currently doing a Masters in Robotics. I worked with a UR5e robotics arm from Universal Robots (UR) and built RideScan’s independent robot behaviour analysis AI on UR’s official simulator (Polyscope X). I built and integrated an AI agent using a URCap plugin that installs directly on the robot controller. It is a plug-and-play it can be installed on a real UR robot and starts working, with no changes to the robot's existing program.
I used a pick-and-place cycle, a highly common and repetitive industrial task, which is a suitable application for RideScan. Detecting anomalies while having a baseline healthy behaviour to compare against. Safety monitoring matters here because the failures that hurt most are the silent ones. Some examples include, a gearbox wearing out, a tool drifting out of alignment, a motor slowly losing torque, etc. These don't stop the line and they degrade the machine little by little until something expensive breaks. The question I wanted to answer was simple: if my UR robotic arm starts to fail, will RideScan detect it?
The URCap plugin installs directly onto the robot controller via the pendant, reading robot telemetry in real time via RTDE and streaming it to the RideScan API. It runs entirely on the robot, plug and play, with no external PC or separate data logger required.
Capture and upload run on two separate threads. The capture thread reads RTDE and writes each cycle's telemetry to disk. The upload thread batches those files to the API independently. If an upload fails, the files remain on disk rather than being lost. This is an architecture built for factory networks, where dropped connections are routine. Upload batching is configurable, so users can control how many files are sent per batch. Logging is also built in where integration reports and raw upload-failure logs are available for debugging.
What I have built beyond the minimum path was a controlled fault study, where five different faults are injected into one baseline program. This is to obtain sufficient proof and ground truth to test whether the RideScan AI actually detects faults, and how consistent/accurate is it?
Below shows all the 5 faults introduced in order.
The fault simulates a gearbox progressively wearing out. Graph above shows the risk scores obtained grows steadily worse. The progressive upwards trend is evident that the RideScan AI is able to detect anomalies even at lower training epochs.
The fault here simulates a collision to the robot arm’s shoulder on every 4th cycle after a period of normal operations (10 cycles). The arm receives a high impact from an external force, causing it to deflect and it is forced to recover back to its position. This graph shows the consistency and accuracy of RideScan AI as it captures the collision every cycle without fail and produces the same risk score for this particular fault.
This fault also simulates a collision but instead of the arm, it is a collision to the end-effector of the robotic arm which results in a permanent displacement. RideScan AI was able to capture the point at which the collision happened as a collision usually disrupts robot operations in between causing additional delay or path deviation. However, it does not identify the permanent displacement of the tool as RideScan only works with the joint angles of the robotic arm. It identified the collision as it impacted the robot as a whole (joint angles included), but if the joint angles in the subsequent cycles were not affected it will then identify them as normal behaviour.
This fault simulates motor losing torque over time with no action taken. RideScan AI accurately detects this anomaly up until the point of complete motor failure.
This fault simulates a similar motor losing torque scenario, but it received a replacement during maintenance (at the 60th cycle). The graph shows a sharp drop and subsequent low risk scores which are consistent with the risk scores before the motor started losing torque (0-30 cycles). This highlights RideScan AI’s scoring consistency as well.
Severity tracking is can be improved. Training with higher epochs smoothed the wear curve but didn't fix the compression or the mid-run dips, suggesting that the behaviour is structural rather than a matter of under training.
The model only sees six joint angles, in the robotic arm industry most of the bigger problems are found in the end-effector failing to grip/secure the target object. If the end-effector offset had been present from the 1st cycle, there would’ve been no alert.
The deliverable is a working, plug-and-play URCap that is ready for installation and testing on real hardware which does not require an external computer to run. The next steps follow directly from the findings: widen the telemetry beyond joint angles to cover the fault classes currently outside the model's view, and add a severity-calibrated signal so the risk score can answer not just "is something wrong" but "how severe is it and how long do I have till it fails”.
