When a coding robot will not connect
Change one layer at a time. Start with power and the documented connection method, then isolate permissions, pairing state, software, firmware, cable, and device compatibility without erasing projects prematurely.
The short answer
Charge both devices, confirm the exact app and supported operating system, identify whether the robot uses in-app Bluetooth, system pairing, Wi‑Fi, local network, or USB, and grant only the permissions documented for that workflow. Restart the app and robot, remove nearby competing connections, test a known-good cable if applicable, and record versions before updating or resetting.
First, preserve what matters
Before signing out, reinstalling, clearing storage, updating firmware, or factory-resetting, determine where projects are saved and whether they can be exported. Record the robot model and revision, app version, device model, operating-system version, firmware version if visible, indicator-light pattern, and exact error message.
Use the product’s current support instructions when they conflict with this general sequence. Do not interrupt firmware installation, open sealed battery areas, or use an unapproved power source.
Identify the actual connection
| Method | Common confusion | First check |
|---|---|---|
| Bluetooth through app | Pairing in system settings when the app must discover the toy | Manufacturer’s connection screen and Bluetooth permission |
| System Bluetooth pairing | App cannot see a robot already linked elsewhere | Saved devices and active connections |
| Local Wi‑Fi/network | Internet works but local-device access is denied | Same network and local-network permission |
| Robot hotspot | Phone leaves a network that has no internet | Stay-connected setting and setup instructions |
| USB | Charge-only cable powers the robot but carries no data | Known-good data cable, port, and connector condition |
Run the lowest-risk sequence
- Power: charge both devices and confirm the robot’s documented ready indicator.
- Distance: place devices close together and remove physical obstructions.
- Contention: close the control app on other nearby devices and disconnect old sessions.
- Compatibility: verify the exact device and operating-system version against current support pages.
- Permissions: review Bluetooth, Nearby devices, local network, and any documented location permission.
- App state: fully close and reopen the correct app; restart both devices if instructed.
- Connection state: remove a stale pairing only when the manufacturer directs re-pairing.
- Isolation: test one known-supported device or cable without changing several variables.
Understand permission names
On current Android versions, apps can request Nearby devices permission for Bluetooth discovery and connection. Apple requires apps to ask for Bluetooth access and separately controls local-network access. Permission names and paths vary by operating-system version.
A denied permission can look like broken hardware. Grant only what the manufacturer explains, then test the core function. If the requested access seems unrelated, stop and ask the vendor. Our app-requirements guide covers the privacy questions.
Firmware and updates
Update only after basic power, compatibility, and permission checks—and only with stable power and the documented method. Record the current version first. If the problem began immediately after an app or operating-system update, search the vendor’s current support notices rather than repeatedly resetting hardware.
For several classroom units, test the update on one robot and one supported device. Preserve a working device until the new combination is verified.
USB troubleshooting
- Use the supplied cable or a verified data cable.
- Connect directly rather than through an unverified hub or adapter.
- Inspect the port and connector without forcing them.
- Try one other known-working port.
- Confirm any board, port, drive, or device selection in the editor.
- Check whether a managed computer blocks external storage or USB devices.
If power appears but the device is never detected, the cable may be charge-only. Label known-good data cables and keep them with the kit.
When to stop
Stop if the battery is swollen, leaking, unusually hot, damaged, or smells abnormal; if the charging port is loose or scorched; if liquid entered the device; or if the vendor instructs discontinuing use. Move the unit away from children and follow manufacturer and local safety guidance.
Escalate to support with the recorded versions, exact sequence, indicator pattern, tests performed, and purchase information. A precise report is more useful than “Bluetooth is broken.”
Connection checklist
- Projects and account access are protected before destructive steps.
- The exact robot, app, device, OS, and firmware versions are recorded.
- Both devices have stable power.
- The documented connection method is identified.
- Other devices are not holding the active connection.
- The exact control device remains officially supported.
- Required Bluetooth, Nearby devices, or local-network permissions are enabled.
- The correct app is open and both devices were restarted safely.
- A known-good data cable and direct port were tested when applicable.
- Only one variable changed per test.
- Factory reset remains a last documented step.
- Support receives exact symptoms and completed tests.
The decision rule
Move from physical state to connection method to permission to software, changing one thing per trial. Do not use repeated resets as diagnosis. If one supported control device connects and another does not, focus on the device configuration; if none connect after documented recovery, focus on the robot, firmware, or vendor support.
Sources and evidence notes
Interface names change. Use the current instructions for the exact robot and operating system.
- Apple Support: Bluetooth privacy settings
- Apple Support: local-network access
- Google Android Help: app permissions
- Android Developers: Bluetooth permissions
Corrections: See our corrections policy.