Dual-Axis Compass Jitter On Leonardo

Yes - the Leonardo + EZ-Genuino firmware + ARC I2C path is generally compatible, so the behavior you’re describing points more toward sensor interference / calibration / magnetic environment than a Leonardo communication problem.

A few things stand out from your description:

What I’m seeing

• Works better with motors off strong sign of EMI / magnetic interference
• Off by 60-70 from a known heading likely mounting/orientation offset and/or sensor calibration issue
• Only ~250 change during a full 360 rotation that suggests the sensor is not seeing a clean magnetic sweep, often because of:
  • nearby metal
  • motor magnets / motor current field
  • misalignment of the sensor board relative to the robot
  • the sensor itself needing calibration or a different placement

Important note about the Dual-Axis Compass skill

The Dual-Axis Compass skill is designed for the Sure Electronics DC-SS503V100 sensor, but it’s still a magnetic heading sensor, not a GPS compass. That means it can be affected heavily by:

• motors
• steel screws/chassis parts
• battery packs
• speaker magnets
• wiring currents

Even with the sensor on a mast, a 2WD rover with L298N + DC motors can still distort the field enough to make headings jump.

About calibration / offset in ARC

If the skill UI doesn’t expose calibration or declination controls, ARC won’t magically correct the magnetic environment for you in that skill. The usual approach is:

1. Apply a heading offset in your own logic

If the sensor is consistently off by a fixed amount, you can subtract/add an offset in an ARC script or behavior.

For example, in JavaScript:

var heading = /* read heading from the compass skill */;
var corrected = heading + 65;

if (corrected >= 360) {
  corrected -= 360;
}

print("Raw heading: " + heading);
print("Corrected heading: " + corrected);

If the skill exposes the heading as a variable or value you can read, you can use that in a script and then normalize it.

2. Smooth/jitter-filter the value

For motor noise, you can average several samples before using the heading:

var total = 0;
var samples = 10;

for (var i = 0; i < samples; i++) {
  var h = /* read compass heading here */;
  total += h;
  sleep(20);
}

var avg = total / samples;
print("Average heading: " + avg);

If the heading wraps around 359/0, a simple average can be misleading, so a circular average is better if you want I can help you build that.

3. Use a servo fine-tune / global offset if you’re mapping the reading to a pose

If you’re using the heading as part of a robot behavior rather than direct navigation, you may be able to use a global offset approach in your control script instead of trying to modify the skill itself.

What I would try next

A. Verify the sensor orientation

Make sure the sensor board is mounted:

• flat
• stable
• not rotated oddly relative to the robot frame

A 60-70 constant offset often means the robot "forward" and sensor "forward" aren’t aligned the way you think.

B. Test the sensor with motors physically disconnected

Not just "not commanded", but actually unplugged from the driver if possible.
If jitter disappears, it’s interference from motor current or the driver wiring.

C. Increase distance from motors/driver/battery

A mast helps, but sometimes the problem is the magnetic field from the wiring loop itself, not just the motor bodies.

D. Keep I2C wiring very short and away from motor power

Even though you already shortened it, I’d still route SDA/SCL away from:

• motor leads
• battery leads
• L298N board

E. Consider whether this sensor is the right choice for a rover

For a differential-drive rover, a compass can be useful, but it’s often hard to make stable near motors. In many cases an IMU / gyro-based heading solution is more reliable for short-term heading hold.

About the -1 readings

If the skill is returning -1, that usually means the sensor reading is failing or timing out in the skill path. Under load, that can happen if:

• the I2C bus is getting noisy
• the sensor briefly loses communication
• power dips are affecting the sensor or Leonardo

Even though you have separate motor power, check whether the 5V rail to the sensor stays solid when the motors start.

ARC-specific recommendation

If you want to make this usable in ARC right now, I’d recommend:

1. Keep the compass skill for raw heading
2. Add a small JavaScript skill to:
   • read the compass value
   • apply a fixed offset
   • smooth the value
   • ignore brief invalid spikes like -1

If you want, I can help you write that script once you tell me how you’re reading the heading from the skill in ARC.

Best next question

Can you share:

1. the exact name of the heading property/variable the Dual-Axis Compass skill exposes in ARC, and
2. whether the sensor board has any printed orientation markings or a datasheet link?

If you want, I can also help you build a JavaScript heading filter in ARC to smooth the jitter and apply a constant offset. The ARC AI Assistant built into ARC is also great for this kind of script work since it can rewrite and debug the code right in the editor:
https://synthiam.com/Products/AI-Assistant