Robot
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 does my robot just keep going round in circles?
Updating
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 update 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.
[logged in to MIRO]
$ cd ~/lib/miro2_release
$ git reset --hardStep 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.
[logged in to MIRO]
$ cd ~/lib/miro2_release
$ git statusDemo
Why does my robot just keep going round in circles?
By default, the demo controller will avoid cliffs that it detects using MiRo's cliff sensors. The cliff sensors do not work properly on some surfaces—notably, dark or fluffy carpets. Restore normal behaviour by visiting the Controller page of MiRoApp and checking the two options "Disable cliff reflex" and "Disable shun cliffs".
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.
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.
MiRoApp
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:
[logged in to WORKSTATION]
$ 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 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 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.
[logged in to WORKSTATION]
$ 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:
[logged in to WORKSTATION]
$ miro_info | grep ROS_IP
ROS_IP=x.x.x.xROS_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. On some surfaces (such as dark or fluffy carpets) the cliff sensors alway see a cliff, and—accordingly—MiRo will refuse to move forward, but will happily move backward.
You can diagnose this by using the GUI client (see Examples).
You can disable the cliff reflex temporarily (until you reboot) by sending a flag to the control/flags topic. See the Example client_template, which will do this if it receives the argument "--no-cliff".
You can disable the cliff reflex permanently by setting the same flag to be present during start-up. To do this, edit the on-board configuration file user_setup.bash and set MIRO_BRIDGE_FLAGS=r (see the section Bridge flags on the Configure Robot page). Reboot to activate the setting.
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:
Ease the load of your own application on the network by using smaller camera frames or a lower frame rate.
Use a wifi sniffer app to move your wireless network to a channel in a less crowded part of the spectrum.
Try to find a less busy location or time of day to work with your robot.
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:
You are using different versions of the MDK on your robot and on your workstation: update both to the latest MDK.
You have multiple versions of the MDK installed on your workstation, and you have sourced
setup.bashfrom one that does not match the one on your robot: check in your.bashrc.
Gazebo
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.