Overview

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.

Always start Testing with fresh batteries; it may save you some time.

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.

Board Function
UC1Wheel motors
UC2Neck lift (rack & pinion) and yaw (side-to-side)
UC4Spinal processor
UC5Cliff & light sensors
UC6Body touch sensors
UC7Brainstem processor
UC8LED display left
UC9LED display right
UC10Head pitch (up and down)
UC11Head touch sensors
UC12Sonar ranger
UC13Forebrain processor
UC14Tail motors
UC15Ear motors
UC18Eyelid motors

Procedure

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.

Warning warble

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.

Demo mode

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.

Python GUI

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.

Preparation Observation Implication
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 SCAN in MIROapp.
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 /tmp/log).