⚠
Warranty & Safety Notice:
Unofficial modifications or unapproved firmware changes may void your warranty and could cause hardware damage or injury. Always consult the manufacturer or a certified technician before performing repairs.
Workarounds listed below are community-sourced and provided without guarantee.
Multiple GR-3s interfere with each other, or Aurora will not start
Unique DDS domain ID per robot and per control device; the default is 123.
- Symptom
- Several GR-3s on one network respond to each other's SDK commands, or Aurora refuses to start.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-26
- Fix / Workaround
- Cause: two or more robots share a DDS domain ID, so their traffic collides.
Give every robot and every control device on the network its own domain ID. The robot ships on domain 123, set in /opt/fftai/fourier_config_center/general_config/infra.yaml, and the Aurora client must be created with the same value. A domain clash is silent: there is no error, discovery just fails or crosses over between robots. Check for duplicates first whenever Aurora will not launch.
No battery status or fault codes arriving
Check runtime, domain 123 and topic names; an empty fault topic on a healthy robot is expected.
- Symptom
- No battery status or fault codes are arriving from the robot.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-15
- Fix / Workaround
- Power and battery telemetry comes from the Fourierpower runtime on DDS domain 123, on topics hal_battery_monitor_status (BmsStatusMsg) and hal_bms_error_code (ErrorCodes, source=4). Confirm the runtime is up and the domain matches. If the subscriber matches but no callback fires, check the DDS environment variables, the runtime user and the dynamic library path. Fault codes only publish when there is an actual fault, so silence on hal_bms_error_code is normal on a healthy robot; verify against the status topic instead. bms_state_list[0] is the main battery and [1] the sub-battery; per-battery fields include voltage, current, temperature, MOS temperature, level, failure, battery_comm, and the input and output MOS states.
Runtime reports no hand connected
Power, e-stop, then ping the two hand IPs.
- Symptom
- The end-effector runtime reports that no hand device is connected.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-26
- Fix / Workaround
- Check three things in order: hand power, emergency-stop state, and network reachability to the hand IPs. The documented defaults are 192.168.137.19 (left) and 192.168.137.39 (right); ping both. Tactile data is a separate matter: only the FDH-12 hand reports a tactile matrix, and a hand without tactile support publishes an empty matrix rather than an error. Hand commands are routed by exact group name (left_end_effector, right_end_effector); a misspelt name is dropped silently.
Joint commands accepted but nothing moves
Enable actuator power; then check group names and joint limits.
- Symptom
- Joint commands are accepted by the SDK but nothing moves.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-15
- Fix / Workaround
- Cause: the actuator power path has not met its activation condition, so the runtime is still waiting on hal_fscb_status and never forwards commands to the physical actuators.
Confirm actuator power is on before commanding. Two other causes of silently dropped commands: a control-group name that does not match exactly (left_leg, right_leg, waist, head, left_manipulator, right_manipulator), and joint targets outside the body limits. Positions are in radians, velocity in rad/s, effort in N·m.
Commands right after a mode change do nothing
Sleep about a second after any FSM change, set the velocity source before set_velocity, and match group names exactly.
- Symptom
- Commands sent right after an FSM mode change do nothing.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-11
- Fix / Workaround
- Wait about one second after set_fsm_state(...) for the new task to load and stabilise; commanding too early is the most common cause of an ignored command. Three related traps. Stand-pose adjustment only takes effect in PdStand (FSM 2) or RL Locomotion (FSM 3) and is a no-op elsewhere. Velocity commands are silently discarded unless the velocity source was switched to 2 first; note that Fourier's velocity-control page labels value 2 "Navigation" while the RL Locomotion page labels it "client control". Group names route by exact match against hardware.json, so left_arm is not left_manipulator, and a mismatch is dropped without an error.
IMU or touch data missing while grsensor runs
Match domain, topic and message type exactly; run subscribers as root with the environment preserved.
- Symptom
- IMU or touch data is missing while the sensor process appears to be running.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-15
- Fix / Workaround
- Confirm grsensor is running and that both sides are on domain 123 with matching topic and message type: Imu_state pairs with fourier_msgs_pod/msg/Imu, body_sensor_state with fourier_msgs/msg/SensorState. A mismatch lets DDS discovery succeed while no valid data arrives, which looks like a hardware fault but is not. grsensor usually runs as root, so run local subscribers as root too, preserving PYTHONPATH and LD_LIBRARY_PATH, or DDS may match yet deliver no callback. For touch specifically, CommNodeUdpTouch and CommNodeDdsSensorState must both be enabled; the touch device sends UDP to grsensor:50001 before anything is republished on DDS.
LED or eye-screen commands have no effect
Right topic, an ID that exists in the action config, and fouriermedia running on domain 123.
- Symptom
- LED or eye-screen commands have no visible effect.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-15
- Fix / Workaround
- Cause: usually the wrong topic or an action ID that does not exist.
LED commands go to media_signal_led_cmd; eyes and sound have their own topics, and sending to the wrong one fails silently. LED and eye actions are config-backed by media_leds_action.json and media_eyes_action.json under /opt/fftai/fouriermedia/bin/cfg; an ID missing from those files is not executed. Confirm fouriermedia is running on domain 123.
Robot cuts power unexpectedly during teleoperation
Never teleoperate on the charger unprotected, and stop before the last battery bar.
- Symptom
- The robot cuts power unexpectedly during teleoperation.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-24
- Fix / Workaround
- Two documented causes. Operating while charging can cut power at the moment the battery reaches full charge, so do not run the robot on the charger without protection. Separately, power cutoff is a live risk once the battery is down to its last bar, so watch the level during use and land the robot before it gets there. Both cases drop the robot without warning, so keep it hoisted or clear of people whenever either applies.
Collecting diagnostics before contacting support
Open HMS Local at localhost:3000 on the robot, download the logs locally, and gather the seven items Fourier asks for.
- Symptom
- You need diagnostics before contacting support or a technician.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-26
- Fix / Workaround
- Every GR-3 ships with HMS Local, a health-monitoring and log tool reachable from the robot's own browser at http://localhost:3000. Its dashboard carries live data for the onboard computer, battery, head module, dexterous hands and actuators; winding temperature and MOS temperature show by default, with position, velocity, torque, current and voltage available. An alert panel surfaces anomalies from the heartbeat detection mechanism, filterable by type, module and time. Historical analysis defaults to the last hour; on-board logs are kept one week, then archived and reachable under HMS Data Archiving. Log Collection downloads all software and system logs in one click, and individual modules export separately; a "Folder currently inaccessible" prompt means that model or version has no logs there, not that something is broken. Cloud upload is currently unavailable, so local download is the only route. The HMS interface is Chinese-only at present, with an English version stated as in development.
Before contacting support, Fourier asks for: robot model, software version, Aurora version, time of occurrence, reproduction steps, system logs, and photos or screen recordings.
Robot stops accepting control commands mid-operation
Fix the posture or footing that tripped the safety mechanism, then reconnect.
- Symptom
- The robot stops accepting control commands mid-operation, with no error from the client.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-26
- Fix / Workaround
- Cause: the on-board safety mechanism detected an abnormal posture or unsafe condition and cut control.
Check the robot's posture and footing before anything else. Leaning, an unstable stance, or a hazardous position will all trigger it. Clear the condition, then reconnect and resume. This is distinct from Security Protection, which is an FSM state you enter deliberately (see the fault-code decoder entry on this page).
Control example misbehaves after switching to PD Stand
Wait until the robot is standing firm, and about a second after any FSM change, before commanding.
- Symptom
- A control example or application misbehaves after switching the robot to PD Stand mode.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-26
- Fix / Workaround
- Cause: the control program started before the robot had settled into a stable stand.
Confirm both feet are planted and the posture has stopped correcting, then launch the application. Fourier's own examples sleep for about one second after every FSM state change before sending velocity or joint commands; do the same.
Aurora will not launch after changing the hand or end effector
Match Aurora's expected hardware: power, network and device count for stock parts, a configuration profile for custom ones.
- Symptom
- Aurora will not launch after fitting a different dexterous hand, gripper, or end effector.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-26
- Fix / Workaround
- Cause: Aurora runs a hardware consistency check at startup and aborts when the hardware it finds does not match the hardware it expects.
Two cases. If nothing was customised: confirm every device is powered, the internal network is up, and the expected number of IP devices is being detected. If a custom end effector was fitted: it needs a matching software configuration and control profile before Aurora will accept it. Also re-check for duplicate DDS domain IDs, which cause startup failures too.
Actuator overheating, or the robot falls
Power off, cool down completely, inspect, then restart.
- Symptom
- Actuator temperature climbs abnormally, or the robot loses balance and falls.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-26
- Fix / Workaround
- Stop operating immediately and power the robot off. Let it cool fully before doing anything else; running on overheated actuators risks permanent hardware damage. Inspect the robot and the working area before restarting. Winding temperature and MOS temperature are the two figures to watch, and both are shown by default on the HMS Local dashboard (see the log-collection entry on this page).
Error pop-ups, frozen indicators, or the robot moving on its own
Stop the motion first, then restart the app, then the robot and controller.
- Symptom
- Error pop-ups, status indicators frozen, unresponsive controls, or the robot moving without input.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-26
- Fix / Workaround
- If the robot is moving on its own, stop it first: push the joystick hard in the opposite direction and confirm it has halted before troubleshooting anything. Then force-close and reopen the application and reconnect. If that does not clear it, restart the robot, then the controller or host device. Locking the controller into landscape orientation cuts down on accidental screen touches that trigger unintended commands.
Exiting teleoperation safely from an unknown state
Use the blue-button safe exit when you can; set fall protection before any forced or emergency stop.
- Symptom
- You need to exit teleoperation with the robot in an unknown or unsafe state.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-24
- Fix / Workaround
- Three exit routes, safest first. Safe exit (exoskeleton and both PCs connected normally): stand the robot firm, press the right blue button, enter Teleop Wake, hoist the robot, then shut teleoperation down; the algorithm holds the stand throughout. Forced shutdown (blue button unresponsive, PCs still connected): set fall protection, shut teleoperation down, then hoist; posture is held only briefly by motor default force. Physical emergency stop (emergency, or PC disconnection): set fall protection, press the red emergency stop at the rear, hoist, then restart the robot and the teleoperation client; motors lose power instantly and the robot cannot hold its stand. There is also a red emergency stop on the robot's waist and a remote emergency-stop controller. Do not swing the arms hard or release the handles suddenly during teleoperation, and avoid extreme postures: twisting the waist at maximum squat depth, walking at maximum squat depth for long periods, or lifting heavy objects at maximum squat depth can damage the robot.
DAQ software cannot obtain IP addresses
PCs on, router up, NUC relay on the router, then restart the PCs.
- Symptom
- The data-acquisition (DAQ) software cannot obtain IP addresses.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-24
- Fix / Workaround
- Work through the chain in order: confirm PC1 and PC3 are powered on, confirm the Xiaomi router is working, confirm the NUC relay is connected to that router, then restart PC1 and PC3.
Decoding a raw GR-3 fault code
Decode by module: bit-fields for power, hand and actuator faults; an enumerated table only for navigation.
- Symptom
- A raw fault code came off the robot and needs interpreting.
- Affected
- GR-3 developer docs v3.0.2; source page last updated 2026-06-11 to 2026-06-26
- Fix / Workaround
- GR-3 publishes faults as fourier_msgs/msg/ErrorCodes, where source names the module: 1 actuator (hal_actuator_error_code), 3 end effector (hal_endeffector_error_code), 4 power and battery (hal_bms_error_code). Each ErrorCode packs its meaning into high32. For power and battery: level = high32 & 0xF, code = (high32 >> 12) & 0xFFFF, type_flag = (high32 >> 28) & 0xF, where type_flag 0 is a BMS1 fault and 1 a BMS2 fault. For the end effector: bits 31–28 sub-module (currently 0), bits 27–12 the raw hardware error code, bits 11–4 the instance (0x13 left hand, 0x27 right hand), bits 3–0 the severity (1 status, 2 warning, 3 fault); low32 is always 0.
The navigation stack uses a different, fully enumerated scheme (fourier_msgs/msg/BaseErrorInfo; see the Error codes section on this page) with severity 0 healthy, 1 warn, 2 error, 4 fatal, and a component category in the high bits (1<<16 system, 2<<16 motion, 3<<16 sensor, 4<<16 software). The four codes Fourier defines, all at severity Error, are:
SENSOR_ERROR_LIDAR_DISCONNECTED — 0x02030100 — "LiDAR disconnected."
SOFTWARE_ERROR_RELOC_FAILED — 0x02040100 — "Relocalization failed."
SOFTWARE_ERROR_LOW_LOCALIZATION_QUALITY — 0x02040300 — "Localization quality is low."
SOFTWARE_ERROR_LOCALIZATION_FAILED — 0x02040400 — "Localization failed."
Aggregate navigation health is published on /Humanoid_nav/health at 10 Hz with has_warning, has_error and has_fatal flags.
Security Protection is a state, not a fault code: FSM state 9, entered by pressing LT and RT together on the joystick or by set_fsm_state(9). It applies damping for 2 seconds and then drops to zero torque. It is available while the robot is hanging, not while standing.
What Fourier has not published: the meaning of individual raw codes for the actuator, hand and battery modules. The documentation gives the decoding scheme only. The four navigation codes are the only enumerated fault codes on the site.