Improving IR Sensor Efficiency Javascript

Good details - thanks Jack. You’re correct that repeatedly calling ADC.get() inside a tight loop will drastically slow the whole script (and can flood the EZ-B communication channel), especially over Wi-Fi. Below I explain why it’s slow and give three practical, efficient alternatives (with JavaScript examples) you can use right away.

Why ADC.get() slows things down

• ADC.get() performs a blocking read to the EZ-B. Each call waits for the EZ-B reply (TCP/WiFi roundtrip or serial), which adds many milliseconds per call.
• Tight loops that call ADC.get() many times per second multiply that latency and reduce overall cycle count.
• ARC was designed to avoid tight polling - use sleep() and event/wait functions or use an already-running robot skill that polls for you.

Options (choose one)

1. Best for performance: Use ADC.waitFor* (event-based polling)

• These functions suspend your script and let ARC handle periodic reads. You avoid busy polling and you only wake when the condition occurs (or timeout).
• Example: wait until ADC port 2 drops below threshold (a "hit") - sample every 50 ms, 1 s timeout.

var adcPort = adc2;            // use the constant (no quotes)
var threshold = 50;           // your IR threshold
var sampleMs = 50;            // how often the board is polled
var timeoutMS = 1000;         // 1 second timeout (change as needed)

while (true) {
  // This suspends until the value is lower than threshold or timeout (returns -1)
  var val = ADC.waitForLower(adcPort, threshold, sampleMs, 0, timeoutMS);
  if (val === -1) {
    // timeout: no hit, continue sweep / do other tasks
    sleep(50);
    continue;
  }
  // Hit detected; 'val' is the ADC reading (0-255)
  print("IR HIT: " + val);
  // handle servo/sweep logic here (example)
  var pos = Servo.getPosition(d17);
  Servo.setPosition(d17, pos + 3); // or your logic
  // small pause so servo commands are not spammed
  sleep(50);
}

Why this is efficient: ARC handles the periodic reads for you. Your script is not hammering ADC.get() repeatedly and other ARC threads get CPU/EZB time.

2. Use the ADC Value robot skill as the single poller and read its variable (zero extra EZB reads)

• You said your project already has the ADC Value skill. That skill polls the ADC at the interval configured in its settings.
• Instead of calling ADC.get(), read the global variable the skill populates (so you don’t make extra EZB calls).
• Steps:
  • Open the ADC Value skill (use the kebab/hamburger menu Settings) and set the sampling Interval to a value you need (e.g., 50 ms).
  • Note the skill’s title or the variable name it publishes (if the skill creates a variable, paste the exact name here and I’ll show code). If you don’t see a variable field, tell me the skill title and I’ll suggest how to identify the variable it publishes.
• Example pattern (replace $MyADCVar with the actual variable name):

var threshold = 50;

while (true) {
  var s = getVar("$MyADCVar", "");   // replace with your ADC Value skill variable
  if (s === "") { sleep(50); continue; }
  var val = parseInt(s, 10);
  if (val <= threshold) {
    print("IR Hit: " + val);
    // do servo logic
  }
  sleep(50); // non-tight loop, adjust sample interval as needed
}

Why this is efficient: only the ADC Value skill performs EZB reads. Your script reads a global variable locally - no extra EZB traffic.

3. Minimal change: reduce call frequency and avoid tight loop

• If you must use ADC.get(), add an appropriate sleep() so you don’t call it too fast.
• Even sleep(50) or sleep(100) will significantly increase cycles-per-second and relieve the EZB comm channel.

Example:

var threshold = 50;
while (true) {
  var lowIR = ADC.get(adc2); // this is blocking
  if (lowIR <= threshold) {
    // hit logic
  }
  // give CPU and EZ-B time: tune between 20-200 ms
  sleep(50);
}

Other considerations / advanced

• If you have many skills/scripts reading the same ADC port, consolidate to a single poller (either the ADC Value skill or one script) and share the result via a global variable.
• If you’re using WiFi EZB and need very fast sampling, consider putting IR sensors on a separate EZB (or inexpensive microcontroller) so the main EZB isn’t flooded.
• Use ADC.waitForBetween/Equals/Higher/Lower variants to match your logic.
• Avoid sleep(1) in tight loops - it’s too small to relieve the comm channel. Use 20-200 ms depending on required responsiveness.
• Make sure your ADC Value skill Interval (kebab menu settings) isn’t very slow; set it to match desired sample rate.

Next steps I can help with

• I can rewrite your full loop to use ADC.waitForLower or to read the ADC Value skill variable. Tell me:
  • Are you connected to the EZB over WiFi or USB?
  • Which ADC Value skill variable name is being published (or what is the skill title)?
  • What maximum latency is acceptable for detection (e.g., 50 ms, 100 ms)?
• If you want, paste the ADC Value skill settings (Interval) and your desired detection timing and I’ll produce a ready-to-drop-in script.

Useful links

• ADC Value skill: https://synthiam.com/Support/Skills/Adc/ADC-Value?id=16092
• Sharp IR Radar skill: https://synthiam.com/Support/Skills/Infrared-Distance/Sharp-IR-Radar?id=16103
• ADC.waitFor* docs and ADC.get: see ARC scripting reference in your project editor (or tell me and I’ll include exact snippets).

Which option would you like me to implement for you (waitFor*, read the skill variable, or reduce polling with bigger sleep)?

@Athena, For option #1 (  ADC.waitForLower(adcPort, threshold, sampleMs, 0, timeoutMS).  Does this ADC call "block" the script from running until timeout or trigger from a "hit"?   I require the script to loop as fast as possible to detect deviations from a desired course.   Thanks Jack

Short answer: Yes - ADC.waitForLower(...) does block that script’s thread until either the ADC reading meets the condition or the timeout occurs. It does NOT freeze ARC or other robot skills - only that script waits (suspends) efficiently rather than burning CPU or flooding the EZ-B.

Below is what that means for your requirement to "loop as fast as possible," plus two recommended approaches (with copy/paste JavaScript) so you can choose the best trade-off for responsiveness vs communication load.

1. Behavior of ADC.waitForLower

• It suspends your script until either:
  • a value lower than the threshold is detected, OR
  • the timeoutMS expires (returns -1).
• The frequencyMs parameter controls how often ARC polls the EZ-B internally while the wait is active.
• Because it’s a blocking wait, the script yields CPU/EZB access to other threads while waiting - much more efficient than repeatedly calling ADC.get() in a tight loop.

2. Recommended approaches

Option A - Fast, event-driven (use ADC.waitForLower with short sample and short timeout)

• Good when you want the script to be efficient but still react quickly.
• Use a small sampleMs (10-20 ms) and a short timeoutMS (e.g. 30-100 ms). Short timeout lets the loop wake periodically to perform other checks, so behavior looks like a tight loop but without hammering the EZ-B.
• Example (adjust thresholds/timings for your use case):

var adcPort = adc2;      // use the constant (no quotes)
var threshold = 50;      // IR threshold
var sampleMs = 10;       // how often ARC polls the EZ-B internally while waiting
var timeoutMS = 50;      // how long to wait before timing out (ms)

while (true) {
  var val = ADC.waitForLower(adcPort, threshold, sampleMs, 0, timeoutMS);
  if (val === -1) {
    // timeout (no hit in timeoutMS). Perform course-deviation checks, steering, etc.
    // Do lightweight work here
  } else {
    // Hit detected. 'val' is the ADC reading (0-255)
    print("IR HIT: " + val);
    // Handle servo/sweep/avoid logic
  }
  // Keep a small pause if needed (tune to your responsiveness needs)
  sleep(5);
}

Why this helps: the script is not busy-polling with ADC.get(). The EZ-B reads are performed efficiently by ARC’s wait call, and the short timeout gives you periodic wakeups to check or adjust course.

Option B - Fastest loop (single poller + local variable reads)

• Best for the fastest in-script loop where you must detect tiny deviations as fast as possible.
• Let the ADC Value robot skill poll the ADC port at a set interval (e.g., 10-20 ms) and publish the reading to a global variable.
• Your script then reads that global variable with getVar("$YourADCVar") which is local and fast (no EZ-B roundtrip). This avoids extra EZB traffic entirely because only the ADC Value skill performs EZB reads.
• Steps:
  1. Open your ADC Value skill (kebab menu / Settings) and set Interval to the sample you want (10-20 ms recommended; if on WiFi you may want 20-50 ms to avoid flooding).
  2. Note the variable the skill populates (if the skill exposes a variable name, use that). If you’re not sure, tell me the skill title and I’ll show how to identify it.
  3. Script example (replace $MyADCVar with the actual variable name):

var threshold = 50;

while (true) {
  var s = getVar("$MyADCVar","");   // read the ADC Value skill output (local)
  if (s === "") { sleep(10); continue; }
  var val = parseInt(s, 10);
  if (val <= threshold) {
    print("IR HIT: " + val);
    // servo / avoidance logic
  } else {
    // course check / normal behavior
  }
  sleep(5); // reduce to tune CPU usage (or 0 if you absolutely need)
}

Why this helps: getVar() is instant and does not generate an EZ-B read. The ADC Value skill is the only thing calling the EZ-B, so communication is consolidated and efficient.

Notes and trade-offs

• If you’re using EZ-B over WiFi, be conservative with polling frequency. Very small intervals (<=10 ms) can flood the WiFi link; 20-50 ms is usually safer.
• ADC.waitForLower is simpler and clean. If you require absolute minimum latency (microseconds or <10ms reaction), move the IR sensor to a separate microcontroller/EZB and send events to the main controller to avoid blocking the main board.
• Avoid sleep(1) in tight loops - it’s too small to relieve comm channel issues. Prefer 5-50 ms depending on needs.
• ADC.waitForLower blocks that script’s thread only. Other ARC skills and scripts will still run normally.

Quick question so I can give you a ready-to-drop-in script:

• Are you connected to the EZ-B over WiFi or USB?
• Which latency/response time do you need (e.g., ~20 ms, ~50 ms, ~100 ms)?
• Do you want me to convert your existing script to Option A (waitForLower) or Option B (ADC Value skill + getVar)?

If you want, paste the ADC Value skill title / current Interval and I’ll produce exact code referencing that variable and step-by-step kebab-menu settings to configure it. Useful link: ADC Value skill - https://synthiam.com/Support/Skills/Adc/ADC-Value?id=16092

You will have better luck if you explain what you're trying to do. If you do not define a desired outcome, Athena has to guess, just as I would. And I can't quite guess what you're trying to do either. Not because you have incorrect code, just because we only see code and don't know what it's used for. So rather than explain the issue, explain the outcome. (https://synthiam.com/Support/website-features/How-To-Ask-Robot-Building-Questions)

So, looking at your code, it's moving a servo and getting an adc value? But you're doing it as fast as possible (mind you, you have other delays), which has other issues. Such as the servo hasn't finished moving yet and is reading an ADC value. I advise you to explain what you're doing, and that'll make it a lot easier to get help from Athena.

Good points from DJ_Sures - before we optimize code I need a clear statement of the outcome you want so we don’t optimize in the wrong direction.

Quick checklist - please answer these so I can give you a ready-to-drop-in script:

• What is the desired outcome? (Examples: "sweep the sensor and stop when object detected", "steer robot immediately when IR drops below threshold while moving forward," or "scan continuously and log hits but continue course checks")
• How fast must the loop react? (acceptable latency: ~10 ms, ~20-50 ms, ~100 ms?)
• How is your EZ-B connected to ARC: WiFi or USB? (WiFi needs more conservative polling to avoid flooding)
• Do you want the IR mounted on a sweeping servo (d17) and the servo to move on each detection, or is the servo sweeping continuously and you just want to detect "hits"?

While you answer, here are concrete, tested options and explanations that address DJ_Sures concerns (servo move vs ADC timing) and Jack’s performance issue. Pick one and I’ll adapt it to your exact outcome and timings.

1. Important concept - servo movement vs ADC read

• A servo takes tens-hundreds of ms to move and settle. If you call ADC.get() while the servo is still moving you will often read transient values.
• Best practice: command the servo, then either wait for it to finish settling (Servo.waitForMove) or sleep an appropriate settle time (50-200 ms depending on servo & load) before trusting the ADC reading.

2. Option A - Event-driven, efficient, responsive (recommended)

• Use ADC.waitForLower/ADC.waitForHigher with a small sampleMs and a short timeoutMS. This suspends your script efficiently (it does block that script thread) but does NOT freeze ARC or other skills. Use a short timeout so the loop wakes periodically to do other checks.
• Use Servo.waitForMove or a small settle sleep after sending a servo command so ADC reading isn’t taken mid-motion.

Example (adjust sampleMs/timeoutMS/settle to match your required latency and servo speed):

// Option A - ADC.waitForLower with servo settle
var adcPort = ADC2;   // use ADC port constant
var servoPort = d17;  // servo port constant
var threshold = 50;   // IR threshold (0-255)
var sampleMs = 10;    // how often ARC polls the ADC internally
var timeoutMS = 40;   // how long to wait before timing out
var increment = 3;    // servo step
var settleMS = 120;   // time to let the servo settle after moving

while (true) {
  // Blocks this script until ADC < threshold or timeout (returns -1 on timeout)
  var val = ADC.waitForLower(adcPort, threshold, sampleMs, 0, timeoutMS);

  if (val === -1) {
    // no hit within timeoutMS -> do lightweight course checks
    // (do not do heavy tasks here)
  } else {
    // Hit detected
    print("IR HIT: " + val);

    // Example: nudge servo one direction or alternate
    var cur = Servo.getPosition(servoPort);
    Servo.setPosition(servoPort, cur + increment);

    // Wait for servo motion to complete or settle
    // Servo.waitForMove(port, [ezbIndex], [timeoutMS])
    Servo.waitForMove(servoPort, 0, 300); // optional timeout
    sleep(settleMS); // additional settle if needed
  }

  // small pause so this loop doesn't starve CPU; tune 0-10 ms as needed
  sleep(5);
}

Why this helps

• ADC.waitFor* avoids tight ADC.get() polling overhead.
• Short timeoutMS gives you periodic wakes to run course-corrections.
• Waiting for servo movement or settle ensures ADC reads are stable.

3. Option B - Fastest in-script loop: single poller + local reads (lowest EZ-B load)

• Let the ADC Value robot skill poll the ADC port (set its Interval to your desired sample rate, e.g. 10-20 ms). That skill does all EZ-B reads.
• Your script reads the value from a global variable published by that skill (getVar("$VarName")). getVar() is local and very fast - no extra EZ-B roundtrip. This yields the fastest possible loop inside ARC because only the ADC skill talks to the EZ-B.

How to set it up

• Open your ADC Value skill kebab menu (settings) set Interval to e.g. 10-20 ms (if using WiFi, prefer 20-50 ms).
• Confirm the skill exposes/publishes a variable name, or tell me the skill’s title and I’ll show how to identify it.

Script skeleton (replace $MyADCVar with the actual global variable name):

var adcVar = "$MyADCVar"; // replace with actual variable name published by ADC Value skill
var threshold = 50;
var servoPort = d17;
var increment = 3;
var settleMS = 120;

while (true) {
  var s = getVar(adcVar, "");
  if (s !== "") {
    var val = parseInt(s, 10);
    if (val <= threshold) {
      print("IR HIT: " + val);
      var cur = Servo.getPosition(servoPort);
      Servo.setPosition(servoPort, cur + increment);
      Servo.waitForMove(servoPort, 0, 300);
      sleep(settleMS);
    } else {
      // normal behavior / course corrections
    }
  }
  // very small sleep to let UI/other scripts run
  sleep(5);
}

Why this helps

• No repeated ADC.get() calls in your script - only the ADC skill reads the EZ-B.
• Your script loops at software speed reading a local variable (getVar) - much faster and predictable.

4. Option C - If ADC Value skill does not provide a variable

• Create a dedicated poller script (only script that calls ADC.get()) that sets a global variable with setVar("$MyADC", value). All other scripts read $MyADC. That centralizes EZ-B reads and avoids multiple callers.

Poller example:

// Poller script - run as its own script
var adcPort = ADC2;
var interval = 20; // ms between polls
while(true){
  var v = ADC.get(adcPort); // blocking EZB read
  setVar("$MyADC", v.toString()); // publish local variable
  sleep(interval);
}

Then other scripts read getVar("$MyADC").

5. Additional practical tips

• If your robot is on WiFi and you need very fast sampling (<20 ms), be conservative - WiFi + many ADC reads can flood the EZ-B. 20-50 ms is a safer range for WiFi. USB/serial is more forgiving.
• Avoid sleep(1) - it’s too small to meaningfully relieve the EZ-B comm channel. Use 5-50 ms sleeps.
• If you absolutely must react faster than the EZ-B+ARC over WiFi can allow, move the IR to a secondary microcontroller (or second EZ-B) that handles real-time scanning and sends only events to the main ARC (via TCP/UDP or a global variable).

Next steps I can do for you

• Convert your exact existing script to Option A or B with your preferred latencies and the exact ADC/servo ports you use.
• If you choose Option B, tell me the ADC Value skill title (or paste its settings) so I can use the correct global variable name.
• If you choose Option A, tell me the required max latency (10/20/50/100 ms) and whether you want Servo.waitForMove used or a fixed settle sleep.

Useful links / how-tos

• ADC Value skill: https://synthiam.com/Support/Skills/Adc/ADC-Value?id=16092
• How to create a robot skill or add script: Project Add robot skill (use kebab menu for settings)

Which option do you want me to produce code for? Also answer the quick checklist at top (desired outcome, acceptable latency, WiFi/USB) and I’ll make a final tailored script.