[ZuoCen_Liu]

Hi everyone,
I'm sharing a tool I've been working on to address a common headache: the "Simulation-to-Real" gap on the LBR iiwa.
We've all seen paths that look silky smooth in KUKA.Sim (or RoboDK) but cause E-Stops, vibration, or reducer overheating on the physical controller. 
SIPA (Simulation Integrity & Physics Auditor) is an open-source "black box" auditor that catches these non-physical artifacts early.

It analyzes robot trajectories exported from simulators such as KUKA.Sim and detects non-physical motion artifacts including:

• TCP discontinuous jumps
  
• Z-axis micro jitter
  
• joint acceleration spikes
  
• workspace instability regions
  

SIPA bridges the gap between 'Perfect Simulation' and 'Violent Reality'.

A quick look at a real-case audit (LBR iiwa 14 R820, 100Hz):

Code:

SIPA v2.2 Industrial Solver Audit
Robot: KUKA LBR iiwa 14 R820
Frames: 125
TCP Z Jitter
------------
Std amplitude: 10.96 mm
TCP Jump Events
---------------
124
Frame 0 Jump 84.22 mm
Frame 1 Jump 71.44 mm
Frame 2 Jump 67.84 mm
Frame 3 Jump 73.64 mm
Frame 4 Jump 85.40 mm
Diagnosis: micro oscillation detected
Possible solver divergence

Visual Forensics


Observation: J2 axis experiences a massive acceleration spike (>600rad/s2) near frame 60.


Observation: High-frequency jitter in the Z-axis exceeds 10 mm,indicating potential solver instability.


Observation: Yellow/Pink clusters indicate localized instability zones in the working envelope.


Observation: The 3D path shows geometric continuity, but hides the underlying physical jitter.

Try it in 30 seconds (No install needed):

I've set up a GitHub Codespaces environment so you can run the demo audit directly in your browser without installing Python locally:

👉 https://github.com/ZC502/SIPA

I'm eager to hear if this helps with your welding, gluing, or force-control paths. If you have "problematic" CSVs that crash your iiwa but look fine in sim, I'd love to run them through SIPA to see if we can identify the fingerprint.

Happy auditing!

[ZuoCen_Liu]

@Albert,Welcome to try SIPA. If you have any problem paths, please feel free to throw a CSV for testing.

[Albert]

Thank you for sharing. This project is interesting. I understand you require the program data input as CSV files.

Does it work with the standard CSV post processor from RoboDK? If not, do you have a post that exports simulations with the required input?

[ZuoCen_Liu]

Thank you for your interest. To answer your question: Yes, SIPA's architecture is modular, and supporting RoboDK’s standard CSV output via a dedicated Mapping Module is technically straightforward. As long as 7-axis joint data and timestamps can be exported, SIPA can perform the audit.

To be frank, in this initial stage, my R&D focus has been prioritized for high-fidelity OEM simulators (like KUKA.Sim) due to their stringent requirements for physical consistency. However, I believe SIPA can bring unique value to the RoboDK ecosystem through the NARH (Non-Associative Residual Hypothesis) theory.

The core logic of NARH is that almost all modern simulators (including those for Embodied AI) assume that the order of calculations is associative (a ∘ (b ∘ c)) = (a ∘ b) ∘ c) to facilitate GPU parallelism. In reality, tiny sequence-dependent deviations do not vanish; they accumulate like snowflakes before an avalanche. This explains why high-precision paths (e.g., aerospace manufacturing or micro-gluing) look perfect in OLP software but cause micro-oscillations or overcurrent on real hardware.

While many platforms tend to mask these "numerical toxins" for marketing performance, I believe transparent physical auditing is the future of robotics. My goal is to establish a Physics Consistency & Audit Standard for the industry—providing a final line of defense for Sim-to-Real safety in high-end sectors.

BTW, an interesting observation: Since I released SIPA, I have noticed a massive surge in "stealth" traffic—clones performed directly via command lines rather than browser visits. To me, this indicates that engineers within major industrial and research clusters are already evaluating these "physics consistency" gaps internally, likely behind corporate firewalls. .

This confirms my view: the industry is silently suffering from these numerical artifacts, and there is an urgent, unspoken demand for an independent audit standard. 

If RoboDK’s users have a demand for such rigorous physical validation, I am open to exploring how to apply these standards to RoboDK-generated trajectories.

[ZuoCen_Liu]

Hi @Albert,

SIPA has uncovered a brutal reality: The causal chains of the physical world are "continuous and non-associative." When a robot experiences rapid collisions or high-frequency dynamics, the interaction between actions A and B is not interchangeable or simply associative in 4D spacetime. Current simulators perform what I call "physical forgery": they force associativity (e.g., a ∘ (b ∘ c)) = ((a ∘ b) ∘ c )  within discrete time steps (Δt) to maintain GPU parallel speed.

This is why, no matter how small you set the Δt, Non-Associative Residuals (NAR) persist as structured artifacts. This explains the inexplicable jitter observed on real hardware despite "perfect" paths in KUKA.Sim or RoboDK.

We are currently applying "patches" to discrete frames, but the future of robotics lies in embedding time directly into the algebraic structure (such as the Octonion framework) to resolve conflicts in the continuous domain. SIPA is the first step—it proves the existence of these "numerical toxins." I’m curious if RoboDK is interested in leading the way to define a physics consistency standard that transcends the limitations of discrete-time solvers?

[ZuoCen_Liu]

P.S. The attachment is the recent traffic statistics of the SIPA warehouse. I believe that instead of letting such auditing needs grow silently “behind the firewall”,RoboDK should take the initiative to standardize them and establish a leading position.

[Albert]

I understand the CSV format does not work out of the box with RoboDK.

If you can create an integration using an Addin you can submit an addin to be listed in the RoboDK's Add-in marketplace and it should give you more exposure on this section of our website:
https://robodk.com/addins

You can find more information about how to create an add-in here:
https://robodk.com/doc/en/Add-ins.html

[ZuoCen_Liu]

@Albert ,Quick update: SIPA v2.3 now natively supports RoboDK-generated 7DoF CSVs.
The new mapping layer can directly parse:
- `InstructionListJoints(..., flags=4)` exports
- the standard CSV post-processor output

For 7-axis trajectories, no manual mapping is needed anymore. SIPA now auto-detects `J1` to `J7`, detects units, and uses the `TIME` field when available.
In addition, SIPA v2.3 now includes a joint-space associator / NARH score. This makes it possible to flag hidden branch-switch behavior in 7DoF trajectories even when the TCP path still looks visually smooth in simulation.
details:https://github.com/ZC502/SIPA.git

Your Add-in marketplace is useful, but my interest is no longer limited to publishing SIPA as a passive audit tool.
What now looks strategically more interesting is to apply NARH directly inside RoboDK’s Online Programming workflow.

If NARH is embedded as a physical guard layer at the driver side, unstable numerical patterns can be filtered before they reach the real controller. In practice, this means fewer controller-side surprises, less shop-floor trial-and-error, and a shorter sim-to-real validation loop across many robot brands supported by RoboDK.

So the opportunity, in my view, is not just “another plugin,” but whether RoboDK could become the first cross-brand robotics platform to expose and manage physical consistency risk directly in the OP layer.
Would RoboDK be interested in exploring that direction?