MPU9150 Polling Stalls On Turtlebot3

Yes - for the MPU9150 skill on an EZ-B v4, the pattern you’re using (RunOnce every 100 ms from a tight loop) is very likely the source of the stall.

What’s happening

The MPU9150 skill is designed for on-demand reads, not high-rate continuous polling from another script. Even though a single RunOnce works fine, repeatedly hammering ControlCommand(..., "RunOnce") can create a backlog of I2C requests and/or control messaging overhead. On Wi-Fi, that can show up as ping spikes and eventually the sensor values appear to stop updating until the loop is stopped.

Because the skill itself does not stream automatically, the safest approach is to:

• poll slower
• avoid a command loop that never yields
• only request a new reading when you actually need one
• optionally read the values after the skill updates them instead of immediately re-requesting

Recommended polling pattern

Instead of firing RunOnce at 10 Hz indefinitely, try a timed loop with a longer interval, like 250-500 ms, and make sure the loop includes a sleep.

JavaScript example

// Initialize once
ControlCommand("MPU9150", "Init");

while (true) {
  ControlCommand("MPU9150", "RunOnce");

  // Give ARC a moment to process the sensor read and update variables
  sleep(150);

  var yaw = getVar("$imuCompass", 0);
  print("Yaw: " + yaw);

  // Use your heading hold logic here...

  // Let the system breathe
  sleep(300);
}

Even better: use a slower sensor update task

If your heading-hold loop needs fast motor correction, you usually do not need to read the IMU every cycle.

A better architecture is:

• IMU update task every 250-500 ms
• heading control loop runs more frequently using the last known yaw
• only update the stored yaw variable when the sensor is refreshed

That keeps the robot responsive without overloading the I2C/control pipeline.

Why the OpenCR IMU may be a better long-term option

For a TurtleBot3, if the OpenCR already has the IMU wired into the platform, then reading the OpenCR side over USB/serial can be more stable for continuous sensor fusion than putting an extra IMU on the EZ-B v4 just for heading.

That said, whether you should switch depends on what you want:

Stay with EZ-B v4 IMU if:

• you only need occasional heading samples
• you want to keep the sensor on ARC/EZ-B logic
• your control loop can tolerate 250-500 ms updates

Consider OpenCR IMU if:

• you need reliable continuous yaw updates
• you want to keep all TurtleBot3 sensor fusion closer to the robot controller
• you’re already using OpenCR for drive and can expose the IMU cleanly over USB/serial

I would not recommend

• a 10 Hz ControlCommand("RunOnce") loop
• immediate back-to-back RunOnce calls without pauses
• reading the variable in the same instant you command the sensor to refresh

Practical next test

Try this first:

1. Keep Init
2. Change your polling interval to 500 ms
3. Add a short sleep(100-150) after RunOnce
4. Read the variable after that delay
5. See if ARC stays stable for 5-10 minutes

If that works, you can reduce the interval gradually until you find the highest stable rate.

One more thing to check

If you’re using the Variable Watcher heavily while looping, that can add a little overhead too. It usually isn’t the main cause, but for troubleshooting, test with it minimized or closed briefly to see if behavior changes.

Helpful links

• MPU9150 skill info:
  https://synthiam.com/Support/Skills/I2c/MPU9150-Accelerometer-Gyro-Temperature-Compass?id=16182

• ControlCommand documentation:
  https://synthiam.com/Support/Programming/control-command

• TurtleBot3 support page:
  https://synthiam.com/Support/Hardware/TurtleBot-3

My recommendation

For your current setup, I’d first try a slower, delayed polling loop before moving to a custom OpenCR plugin. If you need true continuous IMU fusion, then yes - reading the TurtleBot3/OpenCR IMU path is likely the better architecture.

If you want, I can help you build a stable ARC JavaScript heading-hold loop that:

• polls the MPU9150 safely,
• stores the latest yaw,
• and drives the TurtleBot3 with a proportional correction loop.