Reachy2 stops reacting after a while - NeckOrbita3d is in fault state

Hello,

I have noticed that after restarting the system and, for example play the awake movement, the robot stops reacting, although all services are shown as active and running. An error about NeckOrbita is in fault state can be read. Then the awake movement or any other movement is not possible.

Here are the core logs that are repeating forever after the robot halts:

core | [ethercat_master_server-1] [2025-09-25T11:39:25Z INFO server] GRPC EtherCAT Slave 0 | states sent 499.9954 req/s
core | [hal-4] [WARN]: Battery voltage OK (25.7V)
core | [ethercat_master_server-1] [2025-09-25T11:39:20Z WARN server] Sending emergency stop on all slaves!
core | [ethercat_master_server-1] }
core | [ethercat_master_server-1] homing_error_flags: ,
core | [ethercat_master_server-1] ],
core | [ethercat_master_server-1] ,
core | [ethercat_master_server-1] ,
core | [ethercat_master_server-1] ],
core | [ethercat_master_server-1] DriverFault,
core | [ethercat_master_server-1] [
core | [ethercat_master_server-1] motor_error_flags: [
core | [ethercat_master_server-1] ErrorFlags {
core | [ethercat_master_server-1] [2025-09-25T11:39:20Z ERROR server] Slave 0 (name NeckOrbita3d) is in fault state for 135s,
core | [ethercat_master_server-1] [2025-09-25T11:39:17Z INFO ethercat_controller::ethercat_controller] EtherCAT loop: 927.21 Hz
core | [ethercat_master_server-1] [2025-09-25T11:39:14Z WARN server] Sending emergency stop on all slaves!
core | [ethercat_master_server-1] }
core | [ethercat_master_server-1] homing_error_flags: ,
core | [ethercat_master_server-1] ],
core | [ethercat_master_server-1] ,
core | [ethercat_master_server-1] ,
core | [ethercat_master_server-1] ],
core | [ethercat_master_server-1] DriverFault,
core | [ethercat_master_server-1] [
core | [ethercat_master_server-1] motor_error_flags: [
core | [ethercat_master_server-1] ErrorFlags {
core | [ethercat_master_server-1] [2025-09-25T11:39:14Z ERROR server] Slave 0 (name NeckOrbita3d) is in fault state for 130s,
core | [ethercat_master_server-1] [2025-09-25T11:39:08Z WARN server] Sending emergency stop on all slaves!

… (repeats in loop)

Thanks for your help,

Alexandros

Hi @alexandros,

The error you reported for NeckOrbita3d seems to be about homing (cf homing_error_flags). Homing is the low level procedure performed by each orbita 3d on the robot when the motors are powered up (before the core service is even started).

When you release the emergency button, you should see a init sequence where each orbita 3d moves a bit from side to side: it is used to set the initial position of the actuator so that you don’t have to precisely place the actuator on its zero position.

Sometimes when the orbita 3d is powered too far from the zero position, the homing fails and the error you pointed appears. Could you make sure that the head looks forward before you release the emergency button and then restart the core service (using either the dashboard or by rebooting the bedrock aka Reachy’s computer) ?

We just tested on one of our robot in our office and we reproduced this error by powering up the motors with the head looking down at boot.

Let me know if the problem persists!

Hi @Simon ,

the error is not present when the head is in the default forward position.

  • For your backlog: Why not have a shutdown procedure to move every part of the robot to the desired position and be ready for the next error-free power up? Just a thought.

Thank you for the help!

Dear @Simon the error persits. Even when doing nothing with Reachy2, after a while (sometimes 3 Minutes, sometimes 25 Minutes) the arms and head fail and I can only use the mobile base.

At first I thought this happens when the Robot is out of Wifi Range, but then tested extensively and found out that this happens regardless.

Can you help? I have not been able to use the robot for more then half hour without this error coming up.

Hi @alexandros,

For some reasons the copy/paste of your error log includes some special characters… “

Could you please take a screenshot instead? Just to be sure we are not missing something?