Real-time Detection of IRB 14050 Arm-Angle Discontinuities via ABB RWS (Replay Benchmark, EGM Next)

Hi everyone,

I am working on real-time detection of IRB 14050 arm-angle discontinuities and redundancy-resolution inconsistency using ABB Robot Web Services (RWS).

Why this specific topic?
For IRB 14050 / native 7-axis robots, arm angle is not just a theoretical quantity — it is part of how a robtarget is fully specified, and controller settings such as Arm-Angle Reference Direction can influence singularity behavior and motion consistency. That makes arm-angle continuity a practical monitoring target, not just a geometric curiosity.

>Figure. Replay benchmark of a read-only RWS-style probe for an IRB 14050-like 7-axis stream. The estimated TCP step remains nearly constant, while the NARH continuity score rises sharply within the same time window. Here, NARH (Non-Associative Residual Hypothesis) is used as an order-sensitive joint-space continuity metric to expose hidden redundancy-state discontinuities that may not be obvious from Cartesian monitoring alone. Replay benchmark only; not yet plant data.

I built a small Python audit probe called SIPA (Simulation Integrity & Physics Auditor).
It includes a NARH-based continuity metric, where NARH stands for Non-Associative Residual Hypothesis. In practical terms, I use it here as an order-sensitive joint-space continuity diagnostic for exposing hidden redundancy-state discontinuities that may remain invisible in Cartesian monitoring.
The current scope is intentionally conservative:

  • read-only
  • alarm-only
  • no controller intervention
  • RWS JSON input

RWS is a natural starting point because it allows non-intrusive controller-side observation before discussing anything lower-level.

Current replay benchmark

I now have a minimal RWS-style replay benchmark for an IRB 14050 / 7-axis stream. It demonstrates:

  • warm-up handling
  • joint-space associator / NARH score
  • estimated TCP step tracking
  • alarm-only behavior

Example output:​

[RWS-DEBUG] t= 1.213s assoc=   0.000 tcp_step_mm= 1.304 alarms=none
[RWS-DEBUG] t= 1.414s assoc=   0.429 tcp_step_mm= 1.304 alarms=none

# CRITICAL MOMENT: Capturing Arm-Angle Discontinuity
[RWS-DEBUG] t= 2.243s assoc=  3090.785 tcp_step_mm= 1.302 alarms=ALERT:associator_peak=3090.785
[RWS-DEBUG] t= 2.444s assoc= 11224.296 tcp_step_mm= 1.302 alarms=ALERT:associator_peak=11224.296

In this benchmark, the estimated TCP step remains small and smooth, while the joint-space associator spikes sharply during a synthetic redundant-axis discontinuity.

So the point is not “the TCP looks bad.”
The point is: the TCP may still look acceptable while the redundancy state has already become unstable or discontinuous.

Important note: the 11,000+ value is not a joint-velocity error and not a TCP tracking error. It is a joint-space continuity / instability indicator intended to expose hidden redundancy-state discontinuities.

This replay benchmark is a diagnostic demonstration, not yet a claim about production controller behavior under real plant data.

Repository / benchmark / code / NARH Theory : https://github.com/ZC502/SIPA.git

What I am looking for

To move from replay benchmark to controller-grade validation, I would be very interested in:​

  1. Real IRB 14050 / native 7-axis RWS traces, especially for:
    • high-speed arcs​
    • tight-space avoidance​
    • singularity-neighborhood motion​
    • redundancy-heavy assembly moves​

  2. Discussion with ABB / RobotWare / EGM users

    My current probe is RWS-only and read-only.

    Future work would be to evaluate whether the same continuity metric could also be useful in EGM-related workflows.

My goal here is not to push another plugin, but to ask a technical question:

Can arm-angle continuity be monitored early enough to flag redundancy-switch risk before it becomes a shop-floor problem?

If anyone has relevant RWS traces, IRB 14050 / YuMi experience, or EGM experience, I would be very interested in discussing it.

For those wondering why this algebraic residual (NARH) matters in a production environment: while the Cartesian path might look smooth, the underlying solver stability directly impacts the robot’s longevity and ‘Physical AI’ reliability.

Here is why the 7-axis IRB 14050/YuMi needs this level of auditing:

  • Arm-Angle Jitter: When redundancy resolution struggles with “Arm-Angle Reference Direction” (a common pain point in 7-axis tuning), the solver’s order-sensitivity spikes.

  • Hidden Redundancy Breaks: NARH captures these logical “breaks” in the joint-space even when the TCP looks perfectly stable in Cartesian monitoring.

  • Predictive Auditing: By monitoring the accumulation $\sum R_t \neq 0$, SIPA flags high-risk paths before they manifest as hardware wear, unexpected vibrations, or policy failures.

Has anyone else seen ‘unexplained’ joint oscillations during high-speed moves even if the path in RobotStudio looks perfect? I suspect these spikes are the culprit.