Feeding Rplidar Front Distance Into EZ Gauge Chart

Yes - the recommended way is to read the RPLidar robot skill’s exposed variables rather than trying to "subscribe" to NMS directly in script.

The RPLidar skill publishes scan data into NMS, but ARC scripts generally don’t read raw NMS packets directly. Instead, many skills expose project variables and/or commands that you can use from JavaScript or Python.

Best approach

1) Check the RPLidar skill’s variables

Open the RPLidar skill’s kebab menu and look at its configuration/variables section. The manual shows it can expose the most recent:

• nearest distance
• nearest degree
• furthest distance
• furthest degree
• running status

That’s the easiest source for scripting.

If you enable "Set variables with location data" in the RPLidar settings, you should see variables appear in ARC’s variable list.
Reference:
https://synthiam.com/Support/Skills/Navigation/RPLidar?id=20980

2) If you need a "front cone" value, compute it in JavaScript

Since you want the nearest obstacle in a heading window like -20 to +20 degrees, the usual method is:

1. Read the lidar scan or the scan-derived variables
2. Filter samples whose angle is in the front window
3. Pick the minimum distance
4. Send that to the gauge

Important note

The built-in RPLidar skill documentation doesn’t show a public script API for iterating every scan point from NMS. So if you need raw scan samples, the cleanest route is often to:

• use the RPLidar skill for scanning/display/NMS
• and create a custom robot skill if you want to directly expose a front-distance metric in a reusable way

You can create your own skill here:
https://synthiam.com/Support/Create-Robot-Skill/Overview

3) Practical workaround

If your goal is simply "show nearest object in front," and the RPLidar skill exposes a nearest degree/distance pair, you can use that only if the nearest object is likely in front.

But if you truly need front-only, then you need access to the scan points. If the skill doesn’t expose them individually, then a custom skill is the right solution.

Example ARC JavaScript pattern

If the RPLidar skill exposes variables for nearest point data, you can do something like this:

// Example only: adjust variable names to whatever RPLidar exposes in your project
var dist = getVar("$RPLidarNearestDistance", -1);
var deg = getVar("$RPLidarNearestDegree", -1);

if (dist >= 0 && deg >= -20 && deg <= 20) {
  controlCommand("EZ Gauge Chart", "SetValue", dist);
}

If the degree is reported as 0-359 instead of -180-180, then you’d usually convert the front window like this:

• front = 0..20
• and 340..359

var dist = getVar("$RPLidarNearestDistance", -1);
var deg = getVar("$RPLidarNearestDegree", -1);

if (dist >= 0) {
  if ((deg >= 0 && deg <= 20) || (deg >= 340 && deg <= 359)) {
    controlCommand("EZ Gauge Chart", "SetValue", dist);
  }
}

If you need all scan points

If you specifically want to compute the minimum distance inside a cone from the full scan, then a custom robot skill is the right path. ARC’s NMS is designed for skills to publish/consume navigation data, but the easiest way to make that data script-friendly is to create a skill that exposes a single variable like:

• $FrontObstacleCm

Then your gauge script becomes trivial:

var frontCm = getVar("$FrontObstacleCm", -1);

if (frontCm >= 0) {
  controlCommand("EZ Gauge Chart", "SetValue", frontCm);
}

What I’d suggest next

Please check one thing for me:

1. In the RPLidar skill, do you see any variables after enabling Set variables with location data?
2. If yes, what are the exact variable names?
3. Are you using 0-359 degrees, or do you already have scan data normalized another way?

If you share those variable names, I can help you write the exact JavaScript to drive the EZ Gauge Chart.

Also, for code-heavy workflows like this, the built-in ARC AI Assistant can be really handy because it can rewrite the script right inside ARC:
https://synthiam.com/Products/AI-Assistant