This FAQ may answer your question before you have to contact support. If your query does not appear on this page, please check that you have the latest software installed, and then have a look at Bugs, before getting in touch with support.


Why does my robot sound like a satellite?

This sound indicates 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 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.


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 do the example MDK clients not drive the robot?

Usually, this is because the network address is not set correctly. See the section "Network address" on the page Configure MDK.

For more information, see Why does my robot (or simulator) ignore ROS signals?


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

In some circumstances, the network card may briefly assign itself an address before it is assigned one by DHCP, and the robot will use this temporary address to start network services. When the correct address is then assigned (by DHCP) you cannot communicate with the ROS master.

You can identify this problem using MiRoapp—under System Information on the Management 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 Constraining accepted dynamic address on the Configure MDK page.

Why does my robot (or simulator) ignore ROS signals?

By far the most common cause of this problem is that the network address environment variable ROS_IP is not set correctly. 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:

$ env | grep ROS_IP ...

Usually, this is configured automatically in setup.bash. See Why do the example MDK clients not drive the robot?

If this is set correctly, check also the value of ROS_MASTER_URI. This should specify where to find the ROS master on your network to which your target (robot or simulator) is also connected.

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 halt with errors like OgreRenderSystem?

Perhaps you are running Gazebo under a Virtual Machine (VM Linux, hosted on Windows, say)?

Gazebo may not run well under a Virtual Host. Install Linux native (e.g. as a dual-boot) and you should get along better.