This section of the documentation provides resources to help out when you get into trouble.

Apart from the FAQ (this page) you should be aware of the following resources.

Labs website

The Consequential Laboratories website is the starting point for documentation, downloads, and support.

Support channel

Open a support ticket by emailing support.


This FAQ may answer your question before you have to contact support. If you are frequently encountering a question that isn't on this page, please let us know.


Why does my robot sound like a satellite?

This sound indicates that the main battery voltage is low. 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 an airport?

This sound indicates that the system is being updated over the network. You should try and be patient—very difficult in this fast, modern world.

Do not turn on the power switch unless all lights are extinguished.
Do not turn off the power switch unless the blue power state light is lit steadily.

Why does my robot sound like an alarm clock?

This sound indicates that the cliff sensors are misbehaving. See the related FAQ Why will my robot move backward but not forward?


Why is update not working (with error message "git pull failed")?

Updating the on-board software requires that your robot is connected to the open internet. If not, you should connect your robot to a network by providing network credentials and rebooting, then check that it has a valid IP address, and finally ensure that the network to which it is connected is also connected to the internet. Now try the update again.

Why is update not working (with error message "lock could not be acquired")?

Older software versions performed automatic system updates periodically. These are now performed during robot software updates, but if a system update is running you cannot perform a robot software update. Please be patient—the update will finish in due course (typically in just a few minutes) and you will then be able to proceed.

It is best NOT to reboot in this situation, but wait for the updates to complete, to avoid system corruption. After updating, system updates will then only be performed on demand, avoiding this situation.

Why is update not working (with error message "server certificate verification failed")?

This happens usually because the on-board computer failed to update its system time, and thus remote certificates cannot be verified. This might happen if the network to which the robot is connected blocks NTP (time server) packets.

You can either talk to your system administrator about this issue, or connect via SSH and set the time manually. Support for setting the time from MiRoapp will be added in the near future, to provide another route for dealing with this issue.

Why is update not working (software state is "modified")?

You are encouraged not to make any changes in the MDK directory on-board your robot. If you do, the software "State" will be shown as "modified" on the Software manager page, and a software update will not be permitted.

You can fix this by logging in to your robot to undo any changes to the MDK directory. Please make sure to save any files you want to keep first, and then proceed as follows.

Step one is to reset the MDK repository to its normal state.

$ cd ~/lib/miro2_release $ git reset --hard

Step two is to remove any additional files you have placed in the MDK directory. You can find them as follows—you should delete them manually.

$ cd ~/lib/miro2_release $ git status


Why does my robot just keep going round in circles?

See the related FAQ, Why will my robot move backward but not forward?

Why does my robot just sit there wagging its tail with its eyes half-closed?

MiRo's touch sensors auto-calibrate when you turn it on. When you restart MiRo, please touch only the grey (lower) parts of the case, to avoid mis-calibration of these sensors.

If you are having this problem, you can quickly recalibrate the sensors as follows. Touching only the grey parts of the case, perform an Embedded reset.


Why can I not detect my robot using MIROapp scan?

MiRoapp connects to your robot using Bluetooth Low Energy (BLE). BLE can be used to give a clue to your device's location. Therefore, if location services are disabled, your device will not allow scanning for BLE connections. If you cannot detect your robot, please check that location services is enabled.

On some devices, you will see a symbol like that pictured, left, when the service is disabled—on others, you will not be warned. You can enable location services in your device settings.

Working off-board

Why do I get error "ImportError: No module named ****"?

There are a few system packages that are dependencies of the MDK—please check you have installed these, they are listed at the top of the page Install MDK.

If the error is specifically ImportError: No module named miro2_msg.msg, this usually indicates that you have sourced setup.bash for ROS after sourcing setup.bash for the MDK in your .bashrc script. There is no need to do so—the ROS setup.bash is sourced automatically by the MDK setup.bash—and the ROS script stamps on some of the MDK's settings. You can, if desired, safely source the ROS setup.bash before sourcing that for the MDK.

Why can I not reach the on-board ROS master?

Once your environment is configured correctly you will be able to query the ROS master on the robot to see a list of ROS topics advertised by the robot. Instead you might get this:

$ rostopic list ERROR: Unable to communicate with master!

The most likely problem is that the variable ROS_MASTER_URI is not set correctly—typically, that it does not hold the address of your robot. See Off-board to learn how to set this correctly.

Another problem is that in some circumstances the network card on the robot may briefly be assigned an invalid address during start-up and the robot will use this temporary address to start network services, including the ROS master. When the correct address is then assigned (by DHCP) you cannot communicate with the ROS master because it was started at the wrong address.

You can identify this problem using MiRoapp—under System Information on the Home page, "ROS master" will indicate the IP address that was current when it was started. If this reads "not running" or an IP address that does not match the one indicated above at "IP address" (often, this bogus address will take the form 169.x.x.x), then the ROS master will be unreachable.

To solve this problem, look at the section Constrain accepted dynamic address on the Configure Robot page.

Why do the example MDK clients not drive the robot?

If rostopic list is not working, first see Why can I not reach the on-board ROS master?

Once everything is configured correctly you can run a test client as follows.

$ cd mdk/bin/shared/ $ ./client_test.py yaw ('publish', '/miro/control/cmd_vel') ('publish', '/miro/control/kinematic_joints') ('publish', '/miro/control/cosmetic_joints') ('publish', '/miro/control/illum') ('publish', '/miro/core/mpg/push') ('publish', '/miro/control/flags') ('subscribe', '/miro/sensors/package') wait for connect...

If that fails silently, usually the network address environment variable ROS_IP is not set correctly (it should point at your workstation). Confirm, before starting your ROS client (e.g. controller), that it is set to the network address on which the robot or simulator can find your workstation, as follows:

$ miro_info | grep ROS_IP ROS_IP=x.x.x.x

ROS_IP should be configured automatically in setup.bash. See the section "Network address" on the page Configure MDK if this is not working.

Why will my robot move backward but not forward?

By default, MiRo has a "cliff reflex" enabled. This reflex behaviour runs within the firmware, and prevents each wheel from turning forwards if the corresponding cliff sensor is indicating a cliff. This helps to protect the robot from driving over edges, but if the reflex fires erroneously the robot will move backward but not forward.

Surfaces that reflect light poorly (such as dark or fluffy carpets) may be perceived by the cliff sensors as a cliff. For some surfaces, an adjustment to the sensitivity will fix the problem; for some others, the cliff reflex must be disabled.

There are two ways to diagnose the cliff sensor signals.

To correct the problem, you can either adjust the Cliff sensor sensitivity, or disable the reflex.

If the cliff sensors are erroneously detecting cliffs, this will manifest in the demo as turning constantly in circles, and/or moving backwards a lot.
You will hear this warning sound if your cliff sensors are constantly seeing a cliff in front of the robot when the demo is running.
One user has reported that a cliff sensor was not working, until they cleaned the sensor port with a cotton bud, after which it started working again. So, check for lint.

Why is communication with my robot intermittent?

One of the most trying problems when working with networked robots is data transport jitter. Common causes are either high volumes of traffic on your own wireless network (is someone next to you streaming a movie?) or competition with multiple wireless networks in the same area (are you in a busy IT environment?).

There is no general fix for networking issues of this sort but under good conditions they should occur only very infrequently. If you do face problems, some suggestions are:

Why do I get error "wants topic ... to have datatype ..."?

ROS topic data types may change between releases of the MDK. If you encounter this error, then with overwhelming likelihood one of two things is wrong:

  1. You are using different versions of the MDK on your robot and on your workstation: update both to the latest MDK.
  2. You have multiple versions of the MDK installed on your workstation, and you have sourced setup.bash from one that does not match the one on your robot: check in your .bashrc.


Why does Gazebo not run in a VM?

Why does Gazebo halt with errors like OgreRenderSystem?

Why does Gazebo exit without error message immediately after start-up?

Perhaps you are running Gazebo under a Virtual Machine (VM Linux, hosted on Windows, say)? Gazebo may not run well, or even at all, under a Virtual Host, because of problems with some graphics drivers. Install Linux native (e.g. as a dual-boot) and you should get along better.

Alternatively, Gazebo may not start correctly owing to problems with your video hardware drivers. This problem would show up just running the command gazebo at the terminal prompt.