clmnt shared

Public

Diagnosed Reachy Mini daemon crash and motor detectionPublic

Agent

Cursor

Model

Default

Started

Mar 30, 6:06 PM

Messages223

Downloads49

Summary

In Progress

Understand
Identified simulation crash and motor detection failure.
Understand
Build
Outlined fixes for missing library and motor reflash.
Build
Verify
Ran scans confirming no motors detected.
Verify
Edit
Generated detailed support ticket for hardware support.
Edit

I'm running into this issue with my mac app for my reachy mini. How can I fix?

Daemon started in simulation mode (mockup-sim) Enable motors Wake up animation HF OAuth start Start reachy_mini_testbench reachy_mini_testbench crashed: Process exited with code -5 Referenced from: /Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/site-packages/gstreamer_python/lib/gstreamer-1.0/libgstpython.dylib Reason: tried: '/Library/Frameworks/Python.framework/Versions/3.12/Python' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/Python.framework/Versions/3.12/Python' (no such file), '/Library/Frameworks/Python.framework/Versions/3.12/Python' (no such file)

(:1471): GStreamer-WARNING **: 15:15:20.348: Failed to load plugin '/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/site-packages/gstreamer_python/lib/gstreamer-1.0/libgstpython.dylib': dlopen(/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/site-packages/gstreamer_python/lib/gstreamer-1.0/libgstpython.dylib, 0x0005): Library not loaded: /Library/Frameworks/Python.framework/Versions/3.12/Python Referenced from: /Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/site-packages/gstreamer_python/lib/gstreamer-1.0/libgstpython.dylib Reason: tried: '/Library/Frameworks/Python.framework/Versions/3.12/Python' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/Python.framework/Versions/3.12/Python' (no such file), '/Library/Frameworks/Python.framework/Versions/3.12/Python' (no such file) INFO: Started server process [1471] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8042 (Press CTRL+C to quit) Daemon stop Enable motors Wake up animation 🪩 dance Set volume to 100% 😤 reprimand 🥁 polyrhythm combo ⚡ neck recoil 🎐 pendulum swing 🎭 chin lead 🫨 stumble and recover 🤖 grid snap 🙈 side peekaboo 🐓 chicken peck 🕴️ jackson square 🎐 pendulum swing 👁️ side glance flick 🥁 polyrhythm combo 🌀 interwoven spirals 😏 uh huh tilt 🐓 chicken peck 🤘 headbanger combo 🤘 headbanger combo 🙈 side peekaboo 💫 dizzy spin ⚡ neck recoil 🕺 dance 💪 proud 🦉 attentive 🫣 oops 🏆 proud 🏆 proud 🥳 enthusiastic 🤬 furious 💃 dance 💤 sleep ⚡ electric 🪩 dance Daemon stop Daemon started in simulation mode (mockup-sim) Enable motors Wake up animation Daemon stop 📍 Running from .app bundle, checking local venv... ✅ Local venv already configured at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" ✅ Using local venv at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" 📂 Running from "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" 🔧 Patching pyvenv.cfg at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/pyvenv.cfg" 🔍 Checking args: [".venv/bin/python3", "-m", "reachy_mini.daemon.app.main", "--desktop-app-daemon", "--no-wake-up-on-start", "--preload-datasets"] ✅ Detected Python executable: .venv/bin/python3 🔍 Resolved Python path: "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" 🐍 Direct Python execution: "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" with args: ["-m", "reachy_mini.daemon.app.main", "--desktop-app-daemon", "--no-wake-up-on-start", "--preload-datasets"] 📍 Added /Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini to PATH for subprocess 🚀 Launching process: PATH="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini:/usr/bin:/bin:/usr/sbin:/sbin" UV_PYTHON_INSTALL_DIR="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" UV_WORKING_DIR="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" "-m" "reachy_mini.daemon.app.main" "--desktop-app-daemon" "--no-wake-up-on-start" "--preload-datasets" 2026-03-30 13:29:07,893 - reachy_mini.daemon.daemon - INFO - Daemon version: 1.5.1 2026-03-30 13:29:07,925 - reachy_mini.motion.recorded_move - INFO - Pre-downloading dataset: pollen-robotics/reachy-mini-emotions-library 2026-03-30 13:29:07,925 - root - INFO - Dataset updater started (interval: 24.0h) 2026-03-30 13:29:07,925 - reachy_mini.daemon.daemon - INFO - Daemon start parameters: sim=False, mockup_sim=False, serialport=auto, scene=empty, localhost_only=True, wake_up_on_start=False, check_collision=False, kinematics_engine=AnalyticalKinematics, headless=False, hardware_config_filepath=/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/site-packages/reachy_mini/assets/config/hardware_config.yaml 2026-03-30 13:29:07,925 - reachy_mini.daemon.daemon - INFO - Starting Reachy Mini daemon... 2026-03-30 13:29:07,926 - reachy_mini.daemon.daemon - INFO - Found Reachy Mini serial port: /dev/cu.usbmodem5AAF2623821 2026-03-30 13:29:07,926 - reachy_mini.daemon.daemon - INFO - Creating RobotBackend with parameters: serialport=/dev/cu.usbmodem5AAF2623821, check_collision=False, kinematics_engine=AnalyticalKinematics Checking configuration... [INFO] Motor 'body_rotation' needs to be reflashed. Looking for motor with ID 10 on port /dev/cu.usbmodem5AAF2623821...[FAIL] 2026-03-30 13:29:07,957 - reachy_mini.daemon.daemon - ERROR - Failed to start daemon: Motor 'body_rotation' not found! 2026-03-30 13:29:08,189 - httpx - INFO - HTTP Request: GET https://huggingface.co/api/datasets/pollen-robotics/reachy-mini-emotions-library/revision/main "HTTP/1.1 200 OK" Fetching 163 files: 0%| | 0/163 [00:00<?, ?it/s] Fetching 163 files: 100%|██████████| 163/163 [00:00<00:00, 10174.14it/s] 2026-03-30 13:29:08,219 - reachy_mini.motion.recorded_move - INFO - Dataset pollen-robotics/reachy-mini-emotions-library cached at: /Users/clem/.cache/huggingface/hub/datasets--pollen-robotics--reachy-mini-emotions-library/snapshots/152e84b8f46b88c4b52dd34bbef6975637366177 2026-03-30 13:29:08,219 - reachy_mini.motion.recorded_move - INFO - Pre-downloading dataset: pollen-robotics/reachy-mini-dances-library 2026-03-30 13:29:08,344 - httpx - INFO - HTTP Request: GET https://huggingface.co/api/datasets/pollen-robotics/reachy-mini-dances-library/revision/main "HTTP/1.1 200 OK" Fetching 20 files: 0%| | 0/20 [00:00<?, ?it/s] Fetching 20 files: 100%|██████████| 20/20 [00:00<00:00, 6600.53it/s] 2026-03-30 13:29:08,351 - reachy_mini.motion.recorded_move - INFO - Dataset pollen-robotics/reachy-mini-dances-library cached at: /Users/clem/.cache/huggingface/hub/datasets--pollen-robotics--reachy-mini-dances-library/snapshots/a6a88333cb27c583d99d07ea4ba34b5c8c6d143d 2026-03-30 13:29:08,351 - root - INFO - Recorded move datasets pre-loaded successfully 2026-03-30 13:29:09,569 - reachy_mini.utils.discovery - INFO - mDNS service registered: reachy_mini on port 8000

You’ve got two distinct failures in that log: (1) the simulation/testbench crashes because gstreamer_python can’t load libgstpython.dylib (it’s linked against a missing /Library/Frameworks/Python.framework/Versions/3.12/Python), and (2) the real-hardware daemon can’t find the body_rotation motor (expects motor ID 10). I’ll first inspect this repo/workspace for the exact commands/config used, then I’ll outline precise fixes for both problems.

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:

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
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:

Power on the robot
Open Reachy Mini Testbench
Click “Scan Motors”
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:

Run simulation (mockup) only, or
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.

can you do it for me?

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).

I get that

📍 Running from .app bundle, checking local venv... ✅ Local venv already configured at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" ✅ Using local venv at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" 📂 Running from "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" 🔧 Patching pyvenv.cfg at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/pyvenv.cfg" 🔍 Checking args: [".venv/bin/python3", "-m", "reachy_mini.daemon.app.main", "--desktop-app-daemon", "--no-wake-up-on-start", "--preload-datasets"] ✅ Detected Python executable: .venv/bin/python3 🔍 Resolved Python path: "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" 🐍 Direct Python execution: "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" with args: ["-m", "reachy_mini.daemon.app.main", "--desktop-app-daemon", "--no-wake-up-on-start", "--preload-datasets"] 📍 Added /Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini to PATH for subprocess 🚀 Launching process: PATH="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini:/usr/bin:/bin:/usr/sbin:/sbin" UV_PYTHON_INSTALL_DIR="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" UV_WORKING_DIR="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" "-m" "reachy_mini.daemon.app.main" "--desktop-app-daemon" "--no-wake-up-on-start" "--preload-datasets" 2026-03-30 13:35:47,324 - reachy_mini.daemon.daemon - INFO - Daemon version: 1.5.1 2026-03-30 13:35:47,356 - reachy_mini.motion.recorded_move - INFO - Pre-downloading dataset: pollen-robotics/reachy-mini-emotions-library 2026-03-30 13:35:47,356 - root - INFO - Dataset updater started (interval: 24.0h) 2026-03-30 13:35:47,356 - reachy_mini.daemon.daemon - INFO - Daemon start parameters: sim=False, mockup_sim=False, serialport=auto, scene=empty, localhost_only=True, wake_up_on_start=False, check_collision=False, kinematics_engine=AnalyticalKinematics, headless=False, hardware_config_filepath=/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/site-packages/reachy_mini/assets/config/hardware_config.yaml 2026-03-30 13:35:47,356 - reachy_mini.daemon.daemon - INFO - Starting Reachy Mini daemon... 2026-03-30 13:35:47,357 - reachy_mini.daemon.daemon - INFO - Found Reachy Mini serial port: /dev/cu.usbmodem5AAF2623821 2026-03-30 13:35:47,357 - reachy_mini.daemon.daemon - INFO - Creating RobotBackend with parameters: serialport=/dev/cu.usbmodem5AAF2623821, check_collision=False, kinematics_engine=AnalyticalKinematics Checking configuration... [INFO] Motor 'body_rotation' needs to be reflashed. Looking for motor with ID 10 on port /dev/cu.usbmodem5AAF2623821...[FAIL] 2026-03-30 13:35:47,388 - reachy_mini.daemon.daemon - ERROR - Failed to start daemon: Motor 'body_rotation' not found! 2026-03-30 13:35:47,639 - httpx - INFO - HTTP Request: GET https://huggingface.co/api/datasets/pollen-robotics/reachy-mini-emotions-library/revision/main "HTTP/1.1 200 OK" Fetching 163 files: 0%| | 0/163 [00:00<?, ?it/s] Fetching 163 files: 100%|██████████| 163/163 [00:00<00:00, 10071.62it/s] 2026-03-30 13:35:47,669 - reachy_mini.motion.recorded_move - INFO - Dataset pollen-robotics/reachy-mini-emotions-library cached at: /Users/clem/.cache/huggingface/hub/datasets--pollen-robotics--reachy-mini-emotions-library/snapshots/152e84b8f46b88c4b52dd34bbef6975637366177 2026-03-30 13:35:47,669 - reachy_mini.motion.recorded_move - INFO - Pre-downloading dataset: pollen-robotics/reachy-mini-dances-library 2026-03-30 13:35:47,806 - httpx - INFO - HTTP Request: GET https://huggingface.co/api/datasets/pollen-robotics/reachy-mini-dances-library/revision/main "HTTP/1.1 200 OK" Fetching 20 files: 0%| | 0/20 [00:00<?, ?it/s] Fetching 20 files: 100%|██████████| 20/20 [00:00<00:00, 15372.20it/s] 2026-03-30 13:35:47,809 - reachy_mini.motion.recorded_move - INFO - Dataset pollen-robotics/reachy-mini-dances-library cached at: /Users/clem/.cache/huggingface/hub/datasets--pollen-robotics--reachy-mini-dances-library/snapshots/a6a88333cb27c583d99d07ea4ba34b5c8c6d143d 2026-03-30 13:35:47,809 - root - INFO - Recorded move datasets pre-loaded successfully 2026-03-30 13:35:49,060 - reachy_mini.utils.discovery - INFO - mDNS service registered: reachy_mini on port 8000

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)

Power off Reachy Mini and unplug USB.
Reseat the body_rotation motor cable and nearby hub/board connectors.
Make sure that motor is in the correct slot (ID 10 expected by config).
Power on robot first, then reconnect USB.
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.

ready

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.

any troubleshooting item related to that in the reachy mini github?

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):

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.

latest logs. Can you help fix?

2026-03-30 13:46:29,101 - httpx - INFO - HTTP Request: GET https://huggingface.co/api/datasets/pollen-robotics/reachy-mini-emotions-library/revision/main "HTTP/1.1 200 OK" Fetching 163 files: 0%| | 0/163 [00:00<?, ?it/s] Fetching 163 files: 100%|██████████| 163/163 [00:00<00:00, 9433.86it/s] 2026-03-30 13:46:29,134 - reachy_mini.motion.recorded_move - INFO - Dataset pollen-robotics/reachy-mini-emotions-library cached at: /Users/clem/.cache/huggingface/hub/datasets--pollen-robotics--reachy-mini-emotions-library/snapshots/152e84b8f46b88c4b52dd34bbef6975637366177 2026-03-30 13:46:29,134 - reachy_mini.motion.recorded_move - INFO - Pre-downloading dataset: pollen-robotics/reachy-mini-dances-library 2026-03-30 13:46:29,266 - httpx - INFO - HTTP Request: GET https://huggingface.co/api/datasets/pollen-robotics/reachy-mini-dances-library/revision/main "HTTP/1.1 200 OK" Fetching 20 files: 0%| | 0/20 [00:00<?, ?it/s] Fetching 20 files: 100%|██████████| 20/20 [00:00<00:00, 14891.90it/s] 2026-03-30 13:46:29,270 - reachy_mini.motion.recorded_move - INFO - Dataset pollen-robotics/reachy-mini-dances-library cached at: /Users/clem/.cache/huggingface/hub/datasets--pollen-robotics--reachy-mini-dances-library/snapshots/a6a88333cb27c583d99d07ea4ba34b5c8c6d143d 2026-03-30 13:46:29,270 - root - INFO - Recorded move datasets pre-loaded successfully 2026-03-30 13:46:30,461 - reachy_mini.utils.discovery - INFO - mDNS service registered: reachy_mini on port 8000 2026-03-30 13:46:55,563 - reachy_mini.apps.manager.runner - INFO - Starting app reachy_mini_testbench 2026-03-30 13:46:55,572 - reachy_mini.apps.manager.runner - INFO - App reachy_mini_testbench is running 2026-03-30 13:47:05,912 - root - INFO - Dataset updater task cancelled 2026-03-30 13:47:05,913 - reachy_mini.utils.discovery - INFO - mDNS service unregistered: reachy_mini 2026-03-30 13:47:06,166 - root - INFO - Shutting down app manager... 2026-03-30 13:47:06,166 - reachy_mini.apps.manager.runner - INFO - Stopping app reachy_mini_testbench 2026-03-30 13:47:06,166 - reachy_mini.apps.manager.runner - WARNING - Could not connect to daemon: Could not connect to daemon on localhost. Is the Reachy Mini daemon running? 2026-03-30 13:47:06,267 - reachy_mini.apps.manager.runner - WARNING - INFO: Shutting down /Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/multiprocessing/resource_tracker.py:279: UserWarning: resource_tracker: There appear to be 1 leaked semaphore objects to clean up at shutdown warnings.warn('resource_tracker: There appear to be %d ' 📍 Running from .app bundle, checking local venv... ✅ Local venv already configured at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" ✅ Using local venv at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" 📂 Running from "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" 🔧 Patching pyvenv.cfg at "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/pyvenv.cfg" 🔍 Checking args: [".venv/bin/python3", "-m", "reachy_mini.daemon.app.main", "--desktop-app-daemon", "--no-wake-up-on-start", "--preload-datasets"] ✅ Detected Python executable: .venv/bin/python3 🔍 Resolved Python path: "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" 🐍 Direct Python execution: "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" with args: ["-m", "reachy_mini.daemon.app.main", "--desktop-app-daemon", "--no-wake-up-on-start", "--preload-datasets"] 📍 Added /Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini to PATH for subprocess 🚀 Launching process: PATH="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini:/usr/bin:/bin:/usr/sbin:/sbin" UV_PYTHON_INSTALL_DIR="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" UV_WORKING_DIR="/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini" "/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" "-m" "reachy_mini.daemon.app.main" "--desktop-app-daemon" "--no-wake-up-on-start" "--preload-datasets" 2026-03-30 13:47:08,690 - reachy_mini.daemon.daemon - INFO - Daemon version: 1.5.1 2026-03-30 13:47:08,719 - reachy_mini.motion.recorded_move - INFO - Pre-downloading dataset: pollen-robotics/reachy-mini-emotions-library 2026-03-30 13:47:08,719 - root - INFO - Dataset updater started (interval: 24.0h) 2026-03-30 13:47:08,719 - reachy_mini.daemon.daemon - INFO - Daemon start parameters: sim=False, mockup_sim=False, serialport=auto, scene=empty, localhost_only=True, wake_up_on_start=False, check_collision=False, kinematics_engine=AnalyticalKinematics, headless=False, hardware_config_filepath=/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/lib/python3.12/site-packages/reachy_mini/assets/config/hardware_config.yaml 2026-03-30 13:47:08,719 - reachy_mini.daemon.daemon - INFO - Starting Reachy Mini daemon... 2026-03-30 13:47:08,720 - reachy_mini.daemon.daemon - INFO - Found Reachy Mini serial port: /dev/cu.usbmodem5AAF2623821 2026-03-30 13:47:08,720 - reachy_mini.daemon.daemon - INFO - Creating RobotBackend with parameters: serialport=/dev/cu.usbmodem5AAF2623821, check_collision=False, kinematics_engine=AnalyticalKinematics Checking configuration... [INFO] Motor 'body_rotation' needs to be reflashed. Looking for motor with ID 10 on port /dev/cu.usbmodem5AAF2623821...[FAIL] 2026-03-30 13:47:08,751 - reachy_mini.daemon.daemon - ERROR - Failed to start daemon: Motor 'body_rotation' not found! 2026-03-30 13:47:08,978 - httpx - INFO - HTTP Request: GET https://huggingface.co/api/datasets/pollen-robotics/reachy-mini-emotions-library/revision/main "HTTP/1.1 200 OK" Fetching 163 files: 0%| | 0/163 [00:00<?, ?it/s] Fetching 163 files: 100%|██████████| 163/163 [00:00<00:00, 9371.53it/s] 2026-03-30 13:47:09,011 - reachy_mini.motion.recorded_move - INFO - Dataset pollen-robotics/reachy-mini-emotions-library cached at: /Users/clem/.cache/huggingface/hub/datasets--pollen-robotics--reachy-mini-emotions-library/snapshots/152e84b8f46b88c4b52dd34bbef6975637366177 2026-03-30 13:47:09,011 - reachy_mini.motion.recorded_move - INFO - Pre-downloading dataset: pollen-robotics/reachy-mini-dances-library 2026-03-30 13:47:09,216 - httpx - INFO - HTTP Request: GET https://huggingface.co/api/datasets/pollen-robotics/reachy-mini-dances-library/revision/main "HTTP/1.1 200 OK" Fetching 20 files: 0%| | 0/20 [00:00<?, ?it/s] Fetching 20 files: 100%|██████████| 20/20 [00:00<00:00, 10649.50it/s] 2026-03-30 13:47:09,222 - reachy_mini.motion.recorded_move - INFO - Dataset pollen-robotics/reachy-mini-dances-library cached at: /Users/clem/.cache/huggingface/hub/datasets--pollen-robotics--reachy-mini-dances-library/snapshots/a6a88333cb27c583d99d07ea4ba34b5c8c6d143d 2026-03-30 13:47:09,222 - root - INFO - Recorded move datasets pre-loaded successfully 2026-03-30 13:47:10,443 - reachy_mini.utils.discovery - INFO - mDNS service registered: reachy_mini on port 8000

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)

Full power cycle robot (off 10s, on).
Use a different USB data cable + different Mac port.
Reseat motor harness/connectors on the control board and body_rotation motor.
In Testbench: Scan Motors -> Check all motors -> reflash if offered.
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:

bash

"/Users/clem/Library/Application Support/com.pollen-robotics.reachy-mini/.venv/bin/python3" -m reachy_mini.daemon.app.main --desktop-app-daemon --mockup-sim --no-wake-up-on-start --preload-datasets --localhost-only

(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.

the robot worked a few minutes ago so not a motor problem. I can't access testbench without my app opening

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)

Quit desktop app completely.
Unplug USB from robot.
Power robot fully off for 10s, then on.
Reconnect USB directly to Mac (no hub).
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

rescanned

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:

Close desktop app + unplug USB
Power off robot 10s
Reboot Mac
Power robot on, wait 10s, plug USB directly
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.

ready after reboot

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

what approval do you need

No extra approval needed from you right now.

I already have the permissions I need to run the scans.
The last failure (Command failed to spawn: Aborted) was a tooling/process glitch on my side, not a permission prompt.

What I need from you is just:

keep the robot plugged in and powered on,
then say “run again” and I’ll re-run the full scan immediately.

run again

Running it again now: I’ll do quick scan + full baudrate scan from standalone Testbench and report exactly what it sees.

Re-ran both scans — unchanged:

Quick scan @ 1000000: 0 motors
Full scan all baudrates: 0 motors across all baudrates

At this point, software path is exhausted. The USB CDC device exists, but the Dynamixel motor bus behind it is silent.

If you want, I can now generate a precise support ticket text including:

exact scan outputs,
daemon logs,
steps we already tried (reboot, standalone testbench, reflash attempts), so you can send it quickly and get hardware-level guidance/replacement.

yes

Use this as your support ticket:

Subject: Reachy Mini Lite: daemon fails (body_rotation ID 10 not found), motor bus scan finds 0 motors

Hi Reachy team,

I’m on macOS and my Reachy Mini Lite suddenly stopped working after previously working.

Environment

Desktop app / daemon version: 1.5.1
Robot detected over USB as:
- /dev/cu.usbmodem5AAF2623821
- VID:PID 1A86:55D3
- SER 5AAF262382

Main error

Daemon startup fails with:

Motor 'body_rotation' needs to be reflashed.
Looking for motor with ID 10 on port /dev/cu.usbmodem5AAF2623821...[FAIL]
Failed to start daemon: Motor 'body_rotation' not found!

Important context

Earlier I also had a macOS Python/GStreamer issue, now fixed.
App and daemon launch path is now stable, but hardware start still fails on motor detection.

What I tested

Rebooted Mac
Power-cycled robot multiple times
Reseated/replugged USB
Started standalone testbench (without desktop app)
Ran motor scans via testbench API:
- GET /api/motors/scan?baudrate=1000000 -> motors_found: 0
- GET /api/motors/scan_baudrates -> 0 motors found at all baudrates [9600, 57600, 115200, 1000000, 2000000, 3000000, 4000000]
Ran direct reflash function in venv:
- fails with RuntimeError: Motor 'body_rotation' not found!

Representative logs

Found Reachy Mini serial port: /dev/cu.usbmodem5AAF2623821
Creating RobotBackend with parameters: serialport=/dev/cu.usbmodem5AAF2623821 ...
Checking configuration...
[INFO] Motor 'body_rotation' needs to be reflashed.
Looking for motor with ID 10 ... [FAIL]
ERROR - Failed to start daemon: Motor 'body_rotation' not found!

Could you advise next hardware-level diagnostics (motor chain, controller board, expected LED states), and whether this points to a likely motor/cable/controller failure requiring replacement?

Thanks.

If you want, I can also produce a shorter version formatted for a GitHub issue instead of support email.

Summary

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

A. Verify whether that Python framework exists

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

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

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

Do this in the Reachy Mini Testbench app

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

What I changed

What you should do now

Remaining issue (hardware)

Optional stronger permanent fix (needs your admin password)

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

Optional quick check in app

Next concrete actions

Support handoff (recommended now)

What is fixed already

What to do now (real hardware fix path)

Temporary workaround (to keep using app features)

What this means

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

Useful commands I can run for you anytime

One last software-side thing we can try immediately

If it still shows 0 after reboot

Environment

Main error

Important context

What I tested

Representative logs

Summary

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

A. Verify whether that Python framework exists

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

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

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

Do this in the Reachy Mini Testbench app

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

What I changed

What you should do now

Remaining issue (hardware)

Optional stronger permanent fix (needs your admin password)

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

Optional quick check in app

Next concrete actions

Support handoff (recommended now)

What is fixed already

What to do now (real hardware fix path)

Temporary workaround (to keep using app features)

What this means

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

Useful commands I can run for you anytime

One last software-side thing we can try immediately

If it still shows 0 after reboot

Environment

Main error

Important context

What I tested

Representative logs

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

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

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

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