Troubleshooting Rovers IR Sensor Issue

Thanks Jack - good details. Below is a focused troubleshooting plan with tests (including a small ARC JavaScript loopback/latency test), likely causes, and next steps you can run right in ARC with the Serial Terminal and Connection Diagnostic skills you already have. I’ll also ask a few clarifying questions at the end so I can narrow it down.

Summary of likely causes

• Serial (UART) configuration or wiring mismatch (baud, wrong UART pins on Mega, or TX/RX crossed incorrectly).
• Arduino sketch using the wrong Serial port (Serial vs Serial1, Serial2 on Mega), or Serial port being blocked by other code.
• Power supply issues to servos (brownout -> sluggish servos).
• ARC/PC performance or COM driver issues (Windows driver/AV interfering) causing script timing jitter.
• Servo speed/acceleration settings or global servo limits in ARC.
• Timing/blocking code on the EZ-B or Arduino (long blocking loops in JS/C++ causing missed IR timing).

Immediate checks (do these first)

1. Wiring & signal levels

   • Confirm TX <-> RX crossing and common ground between Arduino and EZ-B.
   • If connected to the Mega hardware Serial ports (not USB Serial), ensure you’re using the correct pins:
     • Mega: Serial1 TX = pin 18, RX = pin 19; Serial2 pins 16/17, Serial3 pins 14/15. (Note: Serial (USB) is the virtual serial for PC USB.)
   • On EZ-B v4:
     • UART1 uses D5 (TX) / D6 (RX)
     • UART2 uses D18 (TX) / D19 (RX)
     • UART0 is on the expansion connector
   • Ensure Arduino RX is connected to the EZ-B TX pin and Arduino TX to EZ-B RX. Share GND.

2. Baud & parity

   • Match baud rate exactly on Arduino Serial.begin(baud) and on the EZ-B UART initialization or skill settings.
   • No flow control unless explicitly supported (keep default off).

3. Check power to servos

   • Measure servo supply voltage under load. Low voltage or sagging on battery -> slow/sluggish movement.
   • Test servos with a direct, known-good power supply (bench supply) and command a movement from ARC UI to see if they’re still slow.

4. Confirm which serial interface is used (USB vs EZB UART)

   • If Arduino is connected via USB to the PC and ARC is reading the COM port, use the Serial Terminal (PC) skill.
   • If Arduino is wired to the EZ-B UART pins, use the Serial Terminal (EZB) or the EZB UART functions.

Use the Connection Diagnostic skill

• Run Project -> Add robot skill -> General -> Connection Diagnostic (you already have it).
• Use the Ping EZ-B and view the verbose log. Look for repeated timeouts or connection re-negotiations.
• Copy the connection log and scan for repeated errors, timeouts, or re-connects.

Quick UART loopback / echo test ideas

1. Simple Arduino echo sketch (on the Mega) - verify the Arduino is receiving and echoing:

1. Upload this to the Arduino Mega (choose the Serial port you are using - Serial1 if using hardware pins 18/19):
   • Example (Arduino):
     • If using Serial1: Serial1.begin(115200); if (Serial1.available()) { char c = Serial1.read(); Serial1.write(c); }
2. Using ARC’s Serial Terminal (EZB for UART pins, PC for USB), send a short test string and verify it echoes immediately. If it doesn’t echo, the Arduino isn’t receiving.

2. ARC JavaScript UART round-trip test (EZB UART)

• Add a script robot skill (Project -> Add robot skill -> JavaScript).
• Update port names to match the UART you’re using. This example assumes using UART index 1 (EZB uart hardware port index differs in ARC API; if you use UART hardware functions, call the correct functions for your setup - below is a generic pseudo test using UART hardware functions available in ARC scripting):

// PSEUDO example - use ARC UART functions appropriate to the Terminal skill or hardware UART API you use.
// This demonstrates concept: write, wait, read, and print latency.

print("UART Loopback test start");

// Ensure you know which UART is being used (Serial1 / Serial2) and match in Arduino
// Example process:
// 1) Write test string
UART.hardwareUartWrite(1, "ECHO_TEST\n"); // uartIndex 1 example
print("Written ECHO_TEST");

// 2) Wait briefly for response
sleep(200); // ms

// 3) See available bytes
var available = UART.hardwareUartAvailable(1);
print("Bytes available: " + available);

// 4) Read string if available
if (available > 0) {
  var s = UART.hardwareUartReadStringAvailable(1);
  print("Received: " + s);
} else {
  print("No response received");
}

print("UART Loopback test end");

Notes:

• If ARC’s UART functions above are not present in your ARC build, use the Serial Terminal (EZB) to manually send and receive.
• If you do not get a response, try changing which UART you’re using (Serial1 vs Serial2 on Mega).

Check Arduino sketch Serial port selection

• Many people upload sketches that print to the USB Serial (Serial) but wire to Serial1/Serial2 pins - mismatch causes silence.
• Confirm you used Serial1.begin(baud) if you are using hardware pins 18/19, not Serial.begin().

Servo and ARC settings to check

• In ARC, check each servo control/robot skill:
  • Servo speed setting (Servo.setSpeed). Lower speed value = faster movement; high speed parameter (0-10) is "slowest". Double-check values.
  • Global servo min/max limits: Servo.setMinPositionLimit / setMaxPositionLimit could restrict movement.
  • FineTune offsets may cause odd positions - check getFineTuneOffset.
  • If using Dynamixel or other virtual servo plugins, check velocity/acceleration settings with setVelocity/setAcceleration.

Power and supply

• Sluggish servo motions are often power-related. Check:
  • Battery health (age, internal resistance).
  • Voltage under load with the motors/servos moving.
  • Try bench powering servos with a regulated supply (7.4V recommended for many EZ servos). If movement improves, replace or charge the battery or increase capacity.

Windows 11 and ARC performance

• Windows 11 itself is unlikely to randomly corrupt UART comms, but:
  • Check Task Manager for CPU spikes or antivirus/backup processes that might pause ARC/JS execution.
  • Update USB drivers for any USB -> TTL adapters (CH340, FTDI, Prolific). Old drivers can be flaky.
  • Try on another PC (even a laptop) or boot ARC on a different Windows machine to compare behavior. If it works elsewhere, it’s PC-specific.
  • Try an older ARC version (your last working backup) to verify whether ARC update introduced behavior change - keep your project backup.

Blocking code and timing

• Long blocking loops in Arduino or JS (e.g., delays that ignore UART) can cause missed IR pulses. In Arduino prefer non-blocking code or short delays.
• On EZ-B JS, avoid long synchronous blocking operations that may delay tasks. Use sleep(milliseconds) sparingly and keep time-critical work in efficient loops.

Use a logic analyzer or serial monitor for deeper inspection

• If you have a USB logic analyzer (Saleae or cheap clone), capture TX/RX to verify timing and missing bytes.
• A protocol monitor will show whether Arduino sends but EZ-B misses, or vice versa.

Suggested test sequence (step-by-step)

1. Upload a simple Arduino echo sketch to the Mega for the specific Serial port you plan to use (Serial1 or Serial2).
2. On the EZ-B side, run an ARC UART loopback/echo test (or use Serial Terminal EZB).
3. If echo fails, swap cables and pins and confirm TX/RX wired correctly and common ground.
4. If echo works reliably, send IR sensor data (or test pattern) and see if any bytes are dropped or delayed.
5. Test servos from ARC UI (Movement/Servo control) directly - if still slow, check power/voltage.
6. Use Connection Diagnostic to check for EZ-B reconnects/timeouts.
7. If comms are flaky only when motors run, check noise and ground separation - EMI from motors can corrupt UART. Use twisted pairs, ferrite beads, or separate power grounds with proper common return.

Example Arduino echo sketch (Serial1)

void setup() {
  Serial1.begin(115200); // Use baud you configured on ARC
}

void loop() {
  if (Serial1.available()) {
    char c = Serial1.read();
    Serial1.write(c); // Echo back
  }
}

Questions to help me narrow down

1. How is the Arduino connected to the EZ-B? (USB to PC COM or direct wiring to EZ-B UART pins D5/D6 or D18/D19 or expansion?)
2. Which UART (index) and baud rate are you using on both sides?
3. Which Arduino Serial port does your sketch use? (Serial, Serial1, Serial2, Serial3)
4. Do sluggish servos happen when controlled directly from ARC (manual move from UI) or only when the Arduino/EZ-B are communicating?
5. Do you see errors/timeouts in the Connection Diagnostic log? If so, paste the exact log text (I can’t view images).
6. What servo model and supply voltage are you using? How old is the battery?

Helpful links

• ARC downloads and info: https://synthiam.com/Products/ARC
• Serial Terminal skill: https://synthiam.com/Support/Skills/Communication/Serial-Terminal?id=16071
• Connection Diagnostic skill: https://synthiam.com/Support/Skills/Communication/Connection-Diagnostic?id=16164
• EZ-B v4 manual & UART mapping: https://synthiam.com/Support/Hardware/EZ-B-v4

If you run the loopback echo tests and paste the connection diagnostic log text or the Serial Terminal output here, I’ll analyze it and suggest the exact next step. Want me to provide a specific ARC JavaScript skill you can paste into ARC for automated UART testing and servo timing/latency checks?