Fix Reachy Mini Motor Detection IssuePublic

I’ll pull up known fixes for the two error patterns you’re seeing: the libgstpython.dylib “missing Python.framework” crash on macOS, and the Reachy Mini “motor needs to be reflashed / body_rotation not found” startup failure. Then I’ll map them back into a concrete checklist for your setup (sim vs real hardware).

You’re hitting two separate problems in that log:

1. Simulation/testbench crash: gstreamer_python can’t load libgstpython.dylib because it’s linked against a missing macOS framework at
   /Library/Frameworks/Python.framework/Versions/3.12/Python
2. Real-hardware daemon startup fails: the daemon can’t detect the motor body_rotation (expects motor ID 10) and says it “needs to be reflashed”.

Below are concrete fixes for each.

1) Fix the GStreamer / libgstpython.dylib crash (simulation)

Run these checks on your Mac:

A. Verify whether that Python framework exists

• If this says “No such file or directory”, that’s exactly why libgstpython.dylib fails to load.

B. Install the missing Python.framework (most common fix)

Make sure you have Python 3.12 installed from python.org (the framework build that lives under /Library/Frameworks/...). After installing, try the app again.

C. If you already have Python 3.12, align the Reachy mini venv to it

Your Reachy mini app uses its own venv at:
/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv

If that venv was created with a different Python distribution than what gstreamer_python expects, you can fix it by recreating the venv (or reinstalling the GStreamer Python pieces inside it) so the native libgstpython.dylib links against an existing Python framework.

If you want, paste the output of:

and I’ll tell you the safest “recreate vs reinstall” approach for your exact setup.

2) Fix the body_rotation motor not found (real robot)

Your log shows:

• Motor 'body_rotation' needs to be reflashed.
• Looking for motor with ID 10 ... [FAIL]
• Motor 'body_rotation' not found!

This is a standard Reachy Mini issue: ID 10 isn’t responding with the expected firmware/config or the motor isn’t in the expected slot.

Do this in the Reachy Mini Testbench app

Follow the “Motors diagnosis” flow:

1. Power on the robot
2. Open Reachy Mini Testbench
3. Click “Scan Motors”
4. If motor ID 10 is missing:
   • Verify the motor is plugged in the correct location (the “body_rotation/foot” position)
   • Run the flow to update/reflash all motors (Testbench usually reflash-matches expected configs on restart)
   • Then click “Check all motors” again

Reference (mirrors what the app is telling you): Hugging Face Reachy Mini “Motors diagnosis” / troubleshooting docs and the Seeed Studio wiki troubleshooting guide.

Quick question (so I can narrow to the right fix)

Are you primarily trying to:

1. Run simulation (mockup) only, or
2. Run on the real robot?

If you tell me which one, I’ll prioritize the right path first. Also, if you run the ls command in section 1A and paste the result, I can usually pinpoint the exact next step immediately.

I can do the terminal-side fixes now. I’ll first check your Python/framework and Reachy Mini venv state, then apply the safest repair steps automatically.

I found the immediate root cause: your system Python framework symlink is broken and literally points to PASTE_THE_PATH_FROM_STEP_1. I’m going to try to repair that link automatically first; if macOS blocks it, I’ll give you a one-command sudo fallback.

I can’t write to /Library/Frameworks without admin rights, so I’m switching to a user-level fix: patching libgstpython.dylib to point directly at your local bundled Python dylib in your Reachy app folder (no sudo needed).

I applied the software fix on your machine for the GStreamer crash path.

What I changed

• Found the root cause: your system link is broken:
  • /Library/Frameworks/Python.framework/Versions/3.12/Python -> PASTE_THE_PATH_FROM_STEP_1
• Since I can’t write to /Library/Frameworks without admin privileges, I fixed it inside your Reachy app venv instead:
  • Backed up:
    • ~/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/site-packages/gstreamer_python/lib/gstreamer-1.0/libgstpython.dylib.bak
  • Patched:
    • libgstpython.dylib now links to:
      • ~/Library/Application Support/com.pollen-robotics.reachy-mini/cpython-3.12-macos-aarch64-none/lib/libpython3.12.dylib
  • Verified with otool -L that dependency was updated.

What you should do now

• Fully quit and relaunch the Reachy Mini app.
• Re-run the simulation/testbench flow and confirm the libgstpython.dylib error is gone.

Remaining issue (hardware)

Your daemon still reports:

• Motor 'body_rotation' needs to be reflashed
• Motor 'body_rotation' not found! (ID 10)

I can’t fix that part purely from terminal because it requires robot-level motor detection/reflash.
Please do in Reachy Mini Testbench:

• Scan Motors
• Reflash/update motors
• Check all motors
• Verify motor ID 10 appears

Optional stronger permanent fix (needs your admin password)

If you want, I can give you one sudo command to repair the broken /Library/Frameworks/.../Python symlink globally too (outside the venv patch).

Perfect, this confirms the Python/GStreamer crash is gone and only the hardware motor issue remains. I’ll now check whether the Reachy tooling in your local venv can scan/reflash motor 10 directly from terminal so I can do as much as possible for you automatically.

I found a second packaging issue: the helper CLI scripts have broken shebangs, so I’m going to call the underlying Python modules directly to run a motor reflash from the venv.

I ran a direct bus scan: currently no motor IDs respond at any baudrate, which means this is now below the software layer (serial is visible, but motor bus is not). I’ll still run the reflash command once directly so we have a definitive result.

You’re fully past the Python/GStreamer issue now. I just ran the motor tools directly on your machine, and this is the hard result:

• Serial device is detected: /dev/cu.usbmodem5AAF2623821
• Bus scan finds no motors at any baudrate
• Forced reflash call fails exactly at motor body_rotation (ID 10) with Motor 'body_rotation' not found!

So at this point, software is doing the right thing; the motor bus is not reachable.

What I need you to do physically (then I can continue)

1. Power off Reachy Mini and unplug USB.
2. Reseat the body_rotation motor cable and nearby hub/board connectors.
3. Make sure that motor is in the correct slot (ID 10 expected by config).
4. Power on robot first, then reconnect USB.
5. Try another USB cable/port (data-capable cable).

After that, tell me “ready” and I’ll immediately rerun the scan/reflash commands for you from terminal.

Optional quick check in app

In Testbench:

• Scan Motors
• Check all motors

If ID 10 still missing after reseating/cable swap, it’s likely a hardware fault on that motor/cable/port and you’ll need support replacement for that part.

Great — I’ll rerun the low-level motor scan and then re-attempt reflashing on the detected port now.

Still failing the same way after reseat:

• Port is present: /dev/cu.usbmodem5AAF2623821
• Scan result: no motor IDs detected at any baudrate
• Reflash result: Motor 'body_rotation' not found!

This confirms the issue is not the Mac app anymore; it’s hardware communication on the motor bus.

Next concrete actions

• Try a different known-good USB data cable (not charge-only) and a different USB port/hub path.
• Power-cycle Reachy Mini fully (off 10s, on again).
• Recheck internal motor harness from controller board to body_rotation motor.
• If possible, swap the suspected motor/cable with another known-good one to isolate motor vs cable vs board port.

Support handoff (recommended now)

Open a support ticket with:

• This exact error: Motor 'body_rotation' not found! (ID 10)
• Your daemon version: 1.5.1
• Evidence that serial port is detected but bus scan returns no motors
• Your robot serial shown in USB hwid: SER=5AAF262382

If you want, I can draft a ready-to-send support message you can paste directly.

I’ll quickly check the Reachy Mini GitHub repos/issues for this exact motor-ID/reflash failure and pull the most relevant troubleshooting items.

Yes — there is at least one related GitHub issue in pollen-robotics/reachy_mini:

• Motor communication error · Issue #591

And for troubleshooting, the project ecosystem points to these official guides (not GitHub issues, but directly relevant to your exact failure):

• Motors diagnosis
• Troubleshooting & FAQ

Given your logs (body_rotation ID 10 not found + no motors detected at any baudrate), the “motors diagnosis” path is the right one, and if it still fails after cable/connector checks, opening a new GitHub issue in pollen-robotics/reachy_mini with your full logs is appropriate.

If you want, I can draft a ready-to-post GitHub issue body tailored to your exact outputs.

Thanks for sharing this — it confirms the app is healthy but the daemon keeps exiting on the same hardware check (body_rotation ID 10 missing). I’ll quickly check whether we can force simulation mode as a temporary workaround so your app stays usable while hardware is fixed.

I spotted one potentially fixable thing: the daemon uses /dev/cu.usbmodem..., but some serial stacks only work reliably on /dev/tty.usbmodem.... I’m going to test motor scan on the tty device right now.

Yes — and your latest logs are consistent with the same root cause:

• Daemon launches fine
• It detects USB serial
• It fails at motor config check:
  • Motor 'body_rotation' needs to be reflashed
  • Motor 'body_rotation' not found!

I re-tested from terminal again (including /dev/tty.usbmodem...), and motor scan still returns no responding IDs at any baudrate.
So this is now a hardware-bus issue, not an app/venv issue.

What is fixed already

• The previous GStreamer/Python crash is resolved.
• Daemon works in software terms (I confirmed it can start successfully in --mockup-sim mode).

What to do now (real hardware fix path)

1. Full power cycle robot (off 10s, on).
2. Use a different USB data cable + different Mac port.
3. Reseat motor harness/connectors on the control board and body_rotation motor.
4. In Testbench: Scan Motors -> Check all motors -> reflash if offered.
5. If ID 10 still missing: likely bad motor/cable/board port and needs support replacement.

Temporary workaround (to keep using app features)

You can run daemon in simulation:

(If port 8000 is already used, stop existing daemon first.)

If you want, I can now draft a support ticket message with your exact logs and tests so you can send it immediately.

Understood — if it worked minutes ago, this is likely a daemon/app startup state issue (or serial lock), not dead hardware. I’ll launch Testbench directly from its own venv and bypass your desktop app so you can access diagnostics immediately.

I’ve got Testbench running standalone now in off-mode, so we can use it without the desktop app. I’m going to run its built-in motor scan API next to see if the motor is showing up on another ID/baudrate and reflash it automatically if found.

Yes — I set it up so you can use Testbench without opening the desktop app.

• Standalone Testbench is running at: http://127.0.0.1:8042
• It’s reachable and in off mode (daemon not required).

I also ran its own deep scan endpoint:

• /api/motors/scan_baudrates -> 0 motors found on all baudrates
• So even outside the app, the motor bus is currently not responding.

What this means

You were right that this is not “app can’t open testbench” anymore — we bypassed that.
Right now the blocker is lower-level bus visibility at this instant.

Do this quick reset sequence (most likely to recover if it was working minutes ago)

1. Quit desktop app completely.
2. Unplug USB from robot.
3. Power robot fully off for 10s, then on.
4. Reconnect USB directly to Mac (no hub).
5. Refresh http://127.0.0.1:8042 and run motor scan again.

If you want, I can keep this running and you just tell me “rescanned” after step 4 — I’ll immediately re-run scan/reflash commands for you from terminal.

Useful commands I can run for you anytime

• Stop standalone testbench: pkill -f "reachy_mini_testbench.main"
• Start standalone testbench again:
  "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/reachy_mini_testbench_venv/bin/python3" -m reachy_mini_testbench.main

Great — I’ll re-run the standalone Testbench motor scans now and, if any ID appears, I’ll try targeted reflash immediately.

Rescan completed — still the same result right now:

• Serial is available: /dev/cu.usbmodem5AAF2623821
• Quick scan @ 1000000: 0 motors found
• Full baudrate scan: 0 motors found across all baudrates

So there’s still nothing for me to reflash yet (no reachable motor ID).

One last software-side thing we can try immediately

Sometimes the USB serial endpoint is up but stale at kernel/device level. Do this sequence:

1. Close desktop app + unplug USB
2. Power off robot 10s
3. Reboot Mac
4. Power robot on, wait 10s, plug USB directly
5. Run standalone testbench again and rescan

If you want, I can keep doing the scan for you; just say “ready after reboot” and I’ll run it immediately.

If it still shows 0 after reboot

Then this is almost certainly physical bus path (board<->motor chain or board state), even if intermittent. At that point, best next step is support with your scan evidence. I can draft a strong support ticket in 30 seconds.

Perfect — I’ll restart standalone Testbench if needed and run serial + quick/full motor scans again right now.