FAQ
It falls immediately after I release it.
Check:
- Was the robot held vertical during startup?
- Is the battery charged?
- Is
imu_zeroreasonable?
- Are left and right motors connected correctly?
- Do motor direction and encoder feedback match firmware assumptions?
- Is the desk flat?
- Are printed parts, motor mounts, and wheels loose or blocked?
It reboots after Wi-Fi setup and falls. Is that normal?
Yes, it may reboot after network setup. Hold the robot during setup and reboot.
It keeps turning or drifting.
Possible causes:
- Uneven wheel friction.
- Left/right motor mapping mismatch.
- Head angle not centered.
- IMU zero-angle offset.
- Yaw target or yaw gain mismatch.
The screen is abnormal.
Power off and check the display FPC:
- Contact direction.
- Full insertion.
- Locked connector.
- FPC damage.
- Display pin configuration if using a modified PCB.
The head does not move.
Check:
- EM3 servo wiring order.
- Servo ID is 3.
- Head shell does not block the servo.
- UART bus is working.
target_head_poschanges through MCP or Web debug.
Can I use ordinary DC geared motors?
No. RIG-Hover needs closed-loop FOC hub motors with encoder feedback. Ordinary geared motors do not provide the response and feedback quality needed for self-balancing.
Does it support 5 GHz Wi-Fi?
No. ESP32-S3 uses 2.4 GHz Wi-Fi.
Where are the 3D models?
The final open hardware release should provide STL, STEP, exploded views, assembly drawings, and recommended print settings. If a model download page is provided separately, keep its link in the README and replication guide.
The Web debug page cannot open.
Check:
- Is the robot connected to Wi-Fi?
- Is your computer or phone on the same LAN?
- Is the IP address correct?
- Did firmware call
hover_debug_server_start()?
- Is another service using port 80 in a modified firmware?
Why are variable names in English?
Source paths, function names, and variables must match the firmware. Examples: xgo_control(), imu_zero, stable_pos, stable_yaw, and lqr_k.