Auto Position Jitter With XV11 LIDAR

Yes - the stutter is very likely coming from the monitor script repeatedly reissuing movement/action commands, not from OpenCR or the XV11 itself.

What’s happening

In ARC, Auto Position (Movement Panel) is happiest when it is told to start an action once, then allowed to run.
If your script keeps doing this every loop:

• AutoPosition Action walk_fwd
• Stop
• AutoPosition Action sidestep_left

then ARC is constantly interrupting/restarting the gait thread, which can cause the hesitation you’re seeing.

Also, Stop in Auto Position is not an instant "preempt everything right now" hard kill in the middle of a transition. It often stops on the next safe boundary, which is why you’re seeing it finish another frame.

Recommended ARC pattern

1) Start the gait once

Don’t keep sending walk_fwd in a loop.

Use a state variable so you only command the action when the state changes:

• clear path start walk_fwd once
• obstacle stop once, then start sidestep_left once

2) Use a "state change" monitor, not a spam loop

Your LIDAR loop should only issue commands when the condition changes.

Example idea:

• $obstacle = true/false
• $currentMode = "walk" or "sidestep"

If the mode is already "walk", don’t send the walk command again.

3) Poll less often, but more intelligently

If you’re checking the XV11 array every 100 ms and issuing commands every pass, that will absolutely interfere with smooth gait timing.

Try:

• scan LIDAR data at ~100-200 ms
• only react when the state flips
• add a small hysteresis band so it doesn’t bounce near 300 mm

Example:

• obstacle on: < 300
• obstacle clear: > 350

That prevents rapid toggling.

Better scripting pattern

Since you’re using JavaScript or Python would be better than EZ-Script for this kind of logic, but if you keep the monitor in script form, the key is only command on transitions.

Example logic concept

• If obstacle detected and you’re not already sidestepping:
  • stop gait
  • start sidestep
  • set mode = sidestep
• If clear and you’re not already walking:
  • stop sidestep
  • start walk forward
  • set mode = walk

Important note about immediate stop

If you need the fastest possible stop, you have two options:

Option A: Use Auto Position’s panic/stop behavior

Best for normal use, but still not guaranteed to interrupt mid-frame instantly.

Option B: Make the gait itself sensor-aware

Instead of another script trying to interrupt it, put the obstacle check into:

• the Auto Position start script
• the action script
• or a timed script inside the action

That way the gait can self-terminate between frames more cleanly.

Suggested architecture

Best practice for ARC:

• Auto Position handles gait
• One monitor script watches LIDAR
• Monitor script only changes state on threshold crossings
• Use hysteresis
• Use a shared global variable to prevent repeated action calls

Example of the kind of state logic you want

If you want, I can help convert this into JavaScript for ARC, which would be cleaner than EZ-Script.

Pseudo-logic:

if (minDist < 300) {
  if (getVar("$mode") != "sidestep") {
    controlCommand("Auto Position", "AutoPositionStop");
    sleep(50);
    controlCommand("Auto Position", "AutoPositionFrame", "sidestep_left");
    setVar("$mode", "sidestep");
  }
} else {
  if (getVar("$mode") != "walk") {
    controlCommand("Auto Position", "AutoPositionFrame", "walk_fwd");
    setVar("$mode", "walk");
  }
}

The important part is the if (mode != ...) guard so the command isn’t spammed every cycle.

One more thing to check

Because the XV11 skill is updating arrays continuously, also confirm whether your monitor script is reading:

• every single LIDAR update
• or the whole cone each loop

If you’re scanning many array values every 100 ms, try reducing the work:

• read fewer values
• average the cone
• only react after 2-3 consecutive obstacle detections

That will reduce false triggers and motion interruptions.

My recommendation

For your setup, I’d do this:

1. Keep Auto Position walking continuously
2. Use a separate monitor script
3. Only send commands when obstacle state changes
4. Add hysteresis
5. Avoid repeatedly calling walk_fwd every loop
6. If you want faster/more reliable control, move the logic to JavaScript

If you want, I can write you a complete ARC JavaScript monitor script for:

• the XV11 cone check
• hysteresis
• one-time action switching
• clean recovery back to walk_fwd

If you’d like that, tell me the exact robot skill title of your Auto Position panel and whether you want the cone scan to use 330-359 + 0-30 exactly or a different range.