This section of the documentation provides resources to help out when you get into trouble.
Apart from the(this page) you should be aware of the following resources.
The Consequential Laboratories website is the starting point for documentation, downloads, and support.
Open a support ticket by emailing support.
Thismay 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.
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.
Why does my robot sound like an alarm clock?
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.
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.
Why does my robot just keep going round in circles?
See the related 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.
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.
ImportError: No module named miro2_msg.msg, this usually indicates that you have sourced
setup.bashfor ROS after sourcing
setup.bashfor the MDK in your
.bashrcscript. There is no need to do so—the ROS
setup.bashis 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.bashbefore 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:
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.
Why do the example MDK clients not drive the robot?
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.
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:
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.
- Using MiRoapp, look at the Cliff sensor sensitivity section on the Controller page. Turn on the sensor reading mode to discover what the cliff sensors are seeing.
- Using the GUI client (see Examples), you can see directly what the cliff sensors are seeing, and try moving the robot explicitly forwards and backwards to confirm the problem.
To correct the problem, you can either adjust the Cliff sensor sensitivity, or disable the reflex.
- Using MiRoapp, look at the Cliff sensor sensitivity section on the Controller page. Adjust the threshold value as appropriate for the floor surface.
- For the demo only, visit the Controller page of MiRoapp and check the two flags "Disable cliff reflex" and "Disable shun cliffs", to completely ignore the cliff sensors whilst the demo is running.
- You can disable the cliff reflex temporarily (until you reboot) by sending a flag to the control/flags topic. See client_template under Examples, 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
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
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.