Hi Dhruti,
Great to hear the explanation is helpful. Let's clear up the technical points:
1) What happens if J7 is missing?
For the current RoboDK 7-axis profile, SIPA should not silently invent a J7 value.
If the export is truly from a 6-DoF arm, the right thing to do is not to force that data into the current 7-axis workflow. Instead, it should be treated as a separate 6-axis case.
So for the current integration, the answer is:
• missing J7 = not valid for the current 7-axis profile
• it should be handled by a dedicated 6-axis audit profile, not by padding or guessing an extra joint
That said, this does not mean SIPA is limited to 7-axis robots only.
A dedicated 6-axis SIPA profile can still audit things like:
• TCP jump / Z-axis jitter
• joint acceleration spikes
• singularity-neighborhood transitions
• wrist-flip / posture discontinuity risk
So the distinction is:
• current RoboDK profile: optimized for native 7-axis trajectories
• overall SIPA concept: absolutely extensible to 6-axis robots as well
2) How do we reduce export-related TCP jumps?
Yes — the best way is to re-export the same program as a dense time-sampled joint stream, instead of only using the instruction-level CSV.
RoboDK’s `InstructionListJoints(...)` is the right tool for that. With `flags=4`, it includes the timing information and performs time-based splitting, and `time_step` sets the sampling step in seconds. RoboDK documents this output as a joint matrix with number of robot axes + 4 columns, so it works naturally for both 6-axis and 7-axis robots.Â
Here is a small example you can run inside RoboDK on the attached station:
Code:
from robodk.robolink import Robolink, ITEM_TYPE_PROGRAM
RDK = Robolink()
prog = RDK.ItemUserPick('Select a Program', ITEM_TYPE_PROGRAM)
if not prog.Valid():
  raise Exception("No program selected")
# Dense time-based export
status_msg, joint_list, status_code = prog.InstructionListJoints(
  mm_step=1,
  deg_step=1,
  save_to_file="dense_joint_stream.csv",
  collision_check=0,
  flags=4,
  time_step=0.002
)
print("Status code:", status_code)
print("Status message:", status_msg)
print("Saved to dense_joint_stream.csv")
If you send me that dense export, I can compare it against the first audit and separate:
- export-granularity effects
- versus true continuity / physical-consistency issues
3) About the station you attached
Yes, I’m comfortable using the same station as the reference case.
However, I can’t directly execute thesend me the resulting `.rdk` station on my side right now because I don’t have a RoboDK runtime in this environment. So the fastest path would be:
- open the attached station locally in RoboDK
- run the dense export snippet above
- send me the resulting `dense_joint_stream.csv` (and, if you like, the updated SIPA report)
That would let me do the second audit on the exact same case, but with much less export-related ambiguity.
If you want, once you generate that second CSV I can help compare both audits side by side.
P.S. A thought on the universality of NAR (Non-Associative Residual):
While we are focusing on the 7-axis case, it is important to note that the NAR problem is not a "7-axis quirk." It is a fundamental artifact of how modern simulators handle discrete-time integration.
Almost all current engines force associative logic (the belief that the order of algebraic composition doesn't matter) to gain computation speed. However, real-world physics is non-associative(Different orders lead to different results). When a solver "regroups" these operations over discrete steps, it leaves behind a residual.
In 6-DOF robots, this residual often hides inside Singularity transitions or Wrist Flips, leading to those unexplainable micro-jitters we see in high-precision tasks. My goal with NARH is to provide a unified metric to measure this "algebraic tax" across all kinematic structures, ensuring that what we see in RoboDK is what we get on the factory floor.
