MPU9150 Polling Freezes PCA9685 Servos

Yes - this sounds much more like an I2C bus lock/blocking issue on the Arduino + EZB firmware side than a PCA9685 servo problem.

What your symptoms suggest

• PCA9685 runs fine for hours until IMU polling starts
• Freezing gets worse with more frequent RunOnce calls
• Arduino becomes unresponsive until reset
• Stopping IMU polling makes the problem disappear

That pattern usually means the MPU9150 read is occasionally hanging the I2C bus or the firmware thread, and once that happens the PCA9685 updates stop too because they share the same controller/bus path.

Why this happens

On a shared I2C bus:

• The PCA9685 is being written repeatedly for servo PWM
• The MPU9150 skill is periodically reading sensor data over the same bus
• If the IMU read stalls, NACKs, or the device/bus gets into a bad state, the firmware can lock waiting on I2C
• Once the Arduino firmware is blocked, all ARC communication can appear frozen

So even though the servo driver and IMU have different addresses, they still depend on the same I2C bus transaction flow.

Most likely fixes

1) Use the PCA9685 servo Driver robot skill instead of Arduino firmware I2C for servos

This is the recommended path now.

The big advantage is that ARC manages the PCA9685 through the skill layer, which tends to behave better than mixing multiple I2C devices through older firmware paths.

• PCA9685 servo Driver skill:
  https://synthiam.com/Support/Skills/Servo/PCA9685-Servo-Driver?id=23154

If your servos are on the PCA9685, I’d strongly recommend moving them to that skill and keeping the IMU separate in how it’s polled/handled.

2) Lower the I2C clock speed

If the IMU and PCA9685 must share the same bus, reducing I2C speed can improve reliability.

In ARC, the I2C clock can be set through script:

I2C.setClockSpeed(100000)

You can also try:

I2C.setClockSpeed(50000)

If the bus is marginal, slower is often more stable.

3) Poll less aggressively and avoid tight loops

Your 100 ms loop is reasonable, but if the device occasionally stalls, frequent reads increase the chance of hitting the failure window.

Try:

• 250 ms or 500 ms
• Add a fail-safe delay if readings stop changing
• Avoid doing servo writes immediately after every IMU read unless necessary

4) Rework the logic so servo updates don’t depend directly on every IMU read

Instead of reading IMU and commanding servos in one tight loop, split responsibilities:

• one loop updates IMU values
• another loop applies servo positions at a slower rate

That can help reduce I2C pressure.

Important note about your current script

This part is suspicious:

Servo(D0, 90 + ($roll*2))
Servo(D1, 90 + ($pitch*2))

If these servos are actually on the PCA9685, they should usually be virtual ports like v0, v1, etc., not d0 and d1, unless you truly have native servo outputs on the Arduino firmware ports.

If those are PCA9685 channels, it should look more like:

Servo(v0, 90 + ($roll * 2))
Servo(v1, 90 + ($pitch * 2))

That matters because the port type determines whether ARC is talking through the correct servo subsystem.

What I would test next

1. Confirm whether the PCA9685 servos are on virtual ports in ARC, not D ports
2. Set I2C speed to 100000, then try 50000
3. Change IMU polling to 250-500 ms
4. If possible, move the servos to the PCA9685 servo Driver robot skill
5. Test with the IMU loop only, then servos only, then both together

My recommendation

If this were my setup, I would:

• migrate the PCA9685 to the PCA9685 servo Driver robot skill
• keep the IMU on the bus only if needed
• reduce I2C speed if instability remains
• confirm all servo commands are using the correct V ports

That gives you the best chance of avoiding the bus lock.

Helpful links

• PCA9685 servo Driver skill:
  https://synthiam.com/Support/Skills/Servo/PCA9685-Servo-Driver?id=23154
• ARC downloads:
  https://synthiam.com/Products/ARC
• ARC AI Assistant for rewriting/debugging scripts inside ARC:
  https://synthiam.com/Products/AI-Assistant

If you want, I can help you rewrite that script for the PCA9685 skill using V0/V1 ports and show a safer architecture for the IMU polling loop.