This page is something like an FAQ about problems you may encounter with your robot for which the solutions would otherwise be difficult to intuit. If your query does not appear on this page, please have a look at Testing to see if anything is wrong with the hardware of your robot before getting in touch.

If you don't find what you need on any of these pages, you can open a support ticket.


Why can my robot not contact the ROS master?

If ROS_MASTER_IP is set incorrectly, the bridge will fail to start with an error message "could not contact ROS master". If trying to start the bridge using MIROapp, this will manifest as the bridge appearing to start, and then being "not running" a few seconds later, when refresh is pressed. In this case, make sure ROS_MASTER_IP is set correctly in ~/.profile on-board MIRO, to the IP address of the computer running the ROS master, and try pinging that address from MIRO.

Why is nothing published from my robot?

In this case, it may be that ROS_IP is not set correctly as miro_bridge starts—it must carry the IP address that MIRO has been assigned, if ROS comms is to work correctly. If it is not, outgoing messages are dropped silently, even if the topics MIRO publishes are visible on a remote host. Usually, ROS_IP is obtained automatically by the script ~/bin/run_bridge_ros.sh on-board MIRO. Check if this is working correctly: if not, you can always assign your MIRO a static IP address and set ROS_IP in ~/.profile equal to this static address.

Why does "rostopic echo" produce nothing?

Similarly, when logged in to MIRO, rostopic list may list a remote topic, but nothing appears when rostopic hz or rostopic echo is run on the same topic. If MIRO is to receive messages from a topic publisher on a remote host, the topic publisher must share its contact details correctly. On a network without proper name lookup, this may not happen automatically. On the remote host, set ROS_IP equal to the remote host IP, then restart the publisher. See this page for more.


Why does my MIRO not boot?

Generally, we should give MIRO about a minute to boot up or shut down when we turn the power switch one way or the other, just as we would for any computer. Sometimes we forget about this and turn MIRO on again when shutdown has not completed, which can cause the power controller to lock up.

If this has happened to your MIRO, the symptoms are as follows. The blue light on its left flank will remain lit, no matter what you do with the power switch. MIRO will go through the usual calibration procedure (the neck, head and eyelids move a little) each time you power on. MIRO's system will not boot, no matter what you do with the power switch.

To reset the power controller and clear the fault, just pop the batteries out and then back in. You might check that the batteries are fully charged, at the same time, since this problem occurs more frequently if the batteries are low.

Why can I not connect using MIROapp?

In order to connect using MIROapp your Android device must support Bluetooth "Low Energy" (BLE), which was merged into the standard as of Bluetooth 4.0, circa 2010; any fairly new device, then, is very likely to be equipped.

One of the things BLE is used for is as a clue to your device location; therefore, unless location services are enabled, your device will not be able to use BLE. You may see a symbol like that pictured, left. Make sure location services are enabled in your device settings and try again.

Unsolicited sounds

Why does my robot sound like a satellite?

This sound indicates the main battery voltage is low (below 4.4V). You should recharge MIRO's batteries.

Do not ignore the low battery alarm—the NiMH batteries may be damaged if they are drained beyond this point.

Why does my robot sound like a telephone?

This sound indicates a fault on the I2C bus. This is the bus running all around MIRO with red plugs and sockets on a 4-way cable (with red, yellow, brown and black cables).

If you hear this alarm, first ask what you just did—could this have compromised the bus? Did you pull on a cable, or attach a new module?

Next, check all connections visually, and by physically wiggling connectors where possible. Do this whilst the alarm is sounding—an attempt is made to reset the bus once per second.

If the alarm continues to sound, one of the I2C cables or peripheral boards may be damaged. You can easily isolate the problem device, by disconnecting single boards, or collections of boards, until the alarm stops. Now try reconnecting boards one by one until you determine which cable or board is causing the fault. Visually or technically inspect these components. A useful check is to pull out the umbilical to the head which is the front-most connector on board C1; if this makes the sound stop, the failure is in the head, and vice versa.

Why does my robot sound like a pirate?

Sounds like this indicates a problem with one of MIRO's cameras. If only one of MIRO's cameras is delivering data to the P2 board, MIRO will indicate that one of the eyes is "shut" by randomly making pirate noises.

Thanks to occasional voice artist Brenton Strine (brentonstrine.com) for his kind permission to use these sound samples.

The pirate warning sounds are silenced in CONSERVATIVE mode.