This page provides protocols for testing your robot if something seems to be wrong. Generally, troubleshooting robot operation will consist of identifying which item has failed, and checking the connections to it or, if required, changing it out. To this end, the following table is key.
Component and board associations
There follows a list of the installed boards along with their function; if a particular function is missing, suspect that the associated board not properly connected or even has failed.
|UC2||Neck lift (rack & pinion) and yaw (side-to-side)|
|UC5||Cliff & light sensors|
|UC6||Body touch sensors|
|UC8||LED display left|
|UC9||LED display right|
|UC10||Head pitch (up and down)|
|UC11||Head touch sensors|
If a board has worked once before, then board failure is very unlikely, so always suspect a loose connection first. Once you have isolated the failing board, unplug and replug all of its connections (not just the ones you are suspicious of) and give each a close visual inspection whilst it is apart. Reconnect everything and see if the problem is cleared. If not, board failure is a possibility—get in touch to discuss how to proceed.
If your MIRO starts to sound like a telephone, something on the I2C bus is playing up. You should go round your MIRO unplugging branches of the I2C tree, to isolate the problem. Start by pulling the front-most connector on the C1 board, which is the I2C umbilical to the head, to establish if the problem is in the head or, otherwise, in the body.
The easiest way to test your robot is to place it in demo mode, which works out most of the sensors and actuators. See Wrangling for an overview of how it should behave.
A more direct, and targeted, way to test individual components is to connect to the Python GUI Client. If you are a developer, this will be relatively straightforward since it is part of the "getting to know MIRO" experience to run this up. In this GUI, it will be very clear if an individual component is not working.
Processor board problems
If one of the processor boards is misbehaving, you may not be able to start demo mode or run the GUI, so some other approach may be needed. Below we list some clues you will need to help you find what's wrong.
|Mode 0.||(1) LEDs are pulsing red, green, blue in sequence and nothing else is happening.||P1 cannot reach the P2 board; P1 is running fine, but P2 is either missing, failed, or misconnected.|
|Mode 0, unplug either blue plug from C1 board.||LEDs are pulsing red, green, blue in sequence and nothing else is happening.||P1 is operating correctly (we've disconnected it from P2 deliberately, just to check this).|
|(2) LEDs on P2 board (UC7) in head are flashing alternately red, green, red, green.||P2 is running just fine.|
|Symptom (1) and (2) together.||P1 and P2 are not connected to one another—suspect the blue cable.|
|LED0 on P3 board (UC13) is flashing at 1Hz.||P3 is running just fine; if LED1 is lit, it is also connected to the network, which means the wifi, antenna, and network credentials are all good.|
|Red LED on Bluetooth board is lit.||Bluetooth module is powered and should be discoverable by pressing |
|Mode 12.||LEDs are pulsing white at turn-on.||P1 and P2 are both operating correctly, and can talk to each other fine.|
|LED0 on P3 board is flashing a "heartbeat" pattern (flicker, flicker, pause).||P3 is booting—if this continues indefinitely, boot has failed, and you should listen to the Debug Port to learn more or try reflashing the SD card to Reprogram P3.|
|LED0 on P3 board is not flashing.||The monitor daemon on P3 has crashed, been stopped, or never started—Login to MIRO or listen to the Debug Port to see what's what (logs are at |