Trouble Using Arduinocoms I2C With Six

RoboKenji wrote (original post):

I’m adding an Arduino Nano as an I2C co-processor on my EZ-Robot Six Hexapod to offload a couple of distance sensors and some gait math. The Nano is wired to the EZ-B v4’s I2C header (SDA/SCL), common ground, and I’m powering the Nano from a separate 5V buck with ground tied to the EZ-B. I added the ArduinoComs robot skill in ARC, set the slave address to 0x08 (per the Help tab), and tried simple read/write tests. The ARC I2C scanner sees a device at 0x08 reliably, but ArduinoComs never shows valid data and my Arduino onReceive handler never fires; onRequest fires only occasionally. Here’s the minimal sketch I’m using:

#include <Wire.h>
volatile byte lastCmd = 0;
void receiveEvent(int howMany){ while (Wire.available()) lastCmd = Wire.read(); }
void requestEvent(){ Wire.write(lastCmd + 1); }
void setup(){ Serial.begin(115200); Wire.begin(0x08); Wire.onReceive(receiveEvent); Wire.onRequest(requestEvent); Serial.println("I2C slave ready"); }
void loop(){}

What I’ve tried: external 4.7k pull-ups on SDA/SCL, rerouting wires away from servo leads, bench testing with Six’s legs supported (low servo load), separate Arduino power, and swapping Nanos. Same behavior. A logic probe shows start/stop and ACKs during the ARC scanner sweep, but when I attempt a write/read from ArduinoComs, I see a write followed by a repeated start and a read without my onReceive triggering. Does ArduinoComs use 7-bit or 8-bit addressing and does it expect a register byte framing before reads, plus what I2C clock speed does the EZ-B v4 master use and could someone share a known-working Arduino sketch and the exact ArduinoComs settings for a simple echo test on a Six?

I'd say don't use arduinocomms at all. it hasn't been maintained in several years and to be frank, i don't really know what it's purpose was at the start. But i'd use just the regular UART script commands. Having the arduino act as a way to obtain distance sensors values is smart because the ezb delays when reading, so it slows things down a bit.

just make a protocol where there's a start bit, a bunch of distance values, and a parity bit.

You’re right to question ArduinoComs here - the proven approach in ARC is to avoid that skill unless you absolutely need it.

Short answer

• ArduinoComs is old and not a recommended path
• For a Six Hexapod, a simple custom I2C protocol is a better design
• Your logic trace showing write + repeated start + read is consistent with a master-request pattern, which means your Arduino sketch must be written to handle that style of transaction properly
• If you only need distance values and a few control bytes, the cleanest solution is usually:
  • I2C with a small custom protocol, or
  • UART if you want easier debugging and reliability

Why your current sketch is likely failing

Your sketch:

#include <Wire.h>

volatile byte lastCmd = 0;

void receiveEvent(int howMany) {
  while (Wire.available()) lastCmd = Wire.read();
}

void requestEvent() {
  Wire.write(lastCmd + 1);
}

void setup() {
  Serial.begin(115200);
  Wire.begin(0x08);
  Wire.onReceive(receiveEvent);
  Wire.onRequest(requestEvent);
  Serial.println("I2C slave ready");
}

void loop() {}

This is fine for a basic slave echo test, but if ARC/ArduinoComs is doing a write followed immediately by a read, then:

• your onReceive() may get only a command byte
• your onRequest() must already have the next response prepared
• if the master expects a framing protocol or more bytes than you provide, the transaction will look "alive" but still fail logically

Also, on the Arduino Nano, I2C slaves are 7-bit addressed.
So 0x08 is correct as a 7-bit slave address.

Important ARC note

The EZ-B v4 I2C master typically uses the standard I2C bus behavior and the default ARC I2C timing is generally 100 kHz unless changed in the connection settings. That’s the first thing I’d standardize on for troubleshooting.

Recommended path: use a simple custom I2C protocol

Instead of ArduinoComs, do this:

1. Nano stores sensor values in a buffer
2. ARC writes a command byte
3. ARC reads back a fixed-length packet
4. Include:
   • start byte
   • data bytes
   • checksum or parity byte

That is much more robust than relying on ArduinoComs behavior.

Known-good Arduino slave example

Here’s a simple I2C slave that supports:

• one command byte from ARC
• a 3-byte response: start, value, checksum

#include <Wire.h>

#define I2C_ADDR 0x08

volatile byte commandByte = 0;
volatile byte responseValue = 0;

void receiveEvent(int howMany) {
  while (Wire.available()) {
    commandByte = Wire.read();
  }

  // Example: update a value based on command
  // Replace this with your sensor/gait data logic
  responseValue = commandByte + 1;
}

void requestEvent() {
  byte startByte = 0xAA;
  byte checksum = startByte ^ responseValue;

  Wire.write(startByte);
  Wire.write(responseValue);
  Wire.write(checksum);
}

void setup() {
  Wire.begin(I2C_ADDR);
  Wire.onReceive(receiveEvent);
  Wire.onRequest(requestEvent);
}

void loop() {
  // Keep loop lightweight
}

ARC side approach

In ARC, instead of ArduinoComs, use scripting with the normal I2C methods.

Example JavaScript:

var addr = 0x08;

// Send command byte 5
I2C.write(addr, [5]);

sleep(10);

// Read 3 bytes back
var data = I2C.read(addr, 3);

print("Raw response length: " + data.length);
print("Start: " + data[0]);
print("Value: " + data[1]);
print("Checksum: " + data[2]);

If you want to validate the checksum:

var startByte = data[0];
var value = data[1];
var checksum = data[2];

if ((startByte ^ value) == checksum) {
  print("Checksum OK");
} else {
  print("Checksum FAIL");
}

Settings to verify in ARC

In the EZB Connection skill for the EZ-B v4:

• Leave I2C speed at 100000 for testing
• Use Connection Index 0 unless you intentionally use another index
• Make sure the Nano is on the same physical I2C bus the skill is using

You can adjust these in the skill’s kebab menu if needed.

Why I’d avoid UART for this specific use case

UART is great for logging and debugging, but since you’re already wired for I2C and need multiple sensor values on a shared bus, I2C is still a valid choice - just with a clean protocol.

Best practice for Six

For a hexapod, don’t use the co-processor to "control gait math" unless you have a strong reason. In ARC, it’s usually better to:

• keep gait logic in ARC
• let the Nano handle sensor acquisition or time-critical peripheral tasks
• send compact data packets back to ARC

That keeps the project easier to debug and maintain.

Questions so I can point you to the right setup

1. Are you trying to use the Nano mainly for:

   • distance sensor aggregation
   • gait timing
   • or both?

2. In ARC, are you reading from the Nano using ArduinoComs only, or have you tried the built-in I2C commands in a script?

3. What exact sensor(s) are connected to the Nano?

If you want, I can give you a complete ARC JavaScript master script + Nano sketch pair for a reliable echo/read test on Six.