XV11 LIDAR On Six False Hits

Yes - the better ARC approach is to gate the LIDAR during gait motion and use a small history filter, rather than trying to "trust" raw front-sector readings while the legs are inside the scan plane.

What you’re seeing is very common on hexapods: the robot’s own legs briefly appear as obstacles, especially in the forward arc. For Six, the best practice is:

Recommended approach

1) Don’t stop on a single low reading

Use a debounce / persistence filter:

• require the obstacle to be present for N consecutive scans
• or require the minimum distance to stay below threshold for X ms

This prevents one bad leg echo from stopping the gait.

2) Use a gait-state gate

Instead of setting $IsSwinging inside individual frame scripts, drive the filter from the movement state:

• when Auto Position is moving, treat forward-sector LIDAR as untrusted
• only enforce stop logic during the stance / safe phase
• or hold the last valid forward distance during the swing phase

If your gait is frame-based, the cleaner pattern is to set a global like:

• $GaitActive = 1 when walking starts
• $GaitActive = 0 when walking stops

Then let your obstacle script decide what to do based on that state.

3) Mask the robot body mechanically and in software

Mechanical masking is still useful:

• mount the LIDAR higher
• tilt it slightly upward if possible
• narrow the trusted forward wedge further

But software masking is usually better than trying to tune the sensor geometry forever.

4) Sample on a timer, not inside frame scripts

The most stable integration is:

• let Auto Position run the gait
• run a separate timed script that samples LIDAR every 50-100 ms
• only act on values after filtering

That keeps sensing independent from animation timing.

A proven ARC pattern

Use a scan buffer and only stop if the filtered minimum stays low for multiple samples.

Here’s a JavaScript example you can adapt in ARC:

// LIDAR obstacle filter for Six
// Requires XV11 LIDAR skill publishing $LIDARDistance or equivalent.
// Adjust array access if your skill exposes distances differently.

var thresholdMm = 400;
var consecutiveHitsNeeded = 3;
var hitCountVar = "$LidarHitCount";
var gaitVar = "$GaitActive";

// Read forward sector distances from your variables here
// Example assumes you already have an array of forward distances:
var minDist = 9999;

// Replace this with however your XV11 skill exposes readings
// Example pseudo-loop:
for (var i = 0; i < 360; i++) {
  var d = getVar("$LIDARDistance[" + i + "]", 9999);
  if (d > 50 && d < minDist) {
    minDist = d;
  }
}

var gaitActive = getVar(gaitVar, 0);

// Ignore self-echoes while gait is active if you want to be aggressive:
if (gaitActive == 1) {
  // Keep a softer threshold or require more persistence
  if (minDist < thresholdMm) {
    var hits = getVar(hitCountVar, 0);
    hits++;
    setVar(hitCountVar, hits);
    print("LIDAR hit count: " + hits + " minDist=" + minDist);
    
    if (hits >= consecutiveHitsNeeded) {
      ControlCommand("Auto Position", "AutoPositionStop");
      print("Stopped: persistent obstacle detected.");
    }
  } else {
    setVar(hitCountVar, 0);
  }
} else {
  // Normal mode: stop faster when not walking
  if (minDist < thresholdMm) {
    ControlCommand("Auto Position", "AutoPositionStop");
    print("Stopped: obstacle detected.");
  }
}

Better sync method with Auto Position

If you want tighter coordination, use action scripts only to set state flags, not to make the decision directly.

For example:

• Start of Walk action: set $GaitActive = 1
• Stop action: set $GaitActive = 0

Then your obstacle-check script runs independently and reads that state.

That is much more reliable than flipping $IsSwinging inside every frame, because frame scripts can be delayed, skipped, or out of phase with sensor timing.

If you want a cleaner "ARC-native" setup

The best structure is:

1. Auto Position for the gait
2. XV11 LIDAR for sensing
3. Script skill on a timer for filtering
4. Use ControlCommand("Auto Position", "AutoPositionStop") only after the filter confirms a real obstacle
5. Optionally publish your filtered distance to a custom global variable like $FrontClearanceMm

That gives you a much more robust system than reacting directly to raw sensor data.

Important note about your current logic

Your current approach:

if ($IsSwinging = 0 and $min < 400) ...

is too fragile because:

• it depends on perfect frame timing
• it assumes the leg echoes always line up with swing phases
• it reacts to a single minimum value instead of a trend

A filtered state machine is the standard solution here.

My recommendation for Six specifically

For a hexapod, I’d do this:

• define a trusted forward zone only when the robot is in a known stance phase
• require 3 consecutive low readings before stopping
• ignore readings below a minimum distance threshold that are likely self-echoes unless they persist
• run the LIDAR check from a timer script, not inside frame scripts

If you want, I can help you build a complete ARC JavaScript filter script for the XV11 skill you’re using, including the exact variable names and a timed checker that works alongside Auto Position.
What is your overall goal with Six - just safe forward walking, or do you want full autonomous obstacle avoidance and turning too?

Also, questions like this are often easiest to refine with ARC’s AI Assistant right inside the script editor: https://synthiam.com/Products/AI-Assistant