In most circumstances you will be able to configure your robot using MiRoapp. If you need more control, this page details the options available.
If you are having trouble configuring your robot—for example, its connection to the network—have a look through this page in case one of the options here is what you need.
Note that there is also a Web interface for configuring some aspects of the robot.
The settings below are stored on-board at
~/.miro2/config/user_setup.bash. This file is also used in off-board installations of the MDK, and by MiRoapp—you can safely ignore comments and settings that are not described on this page.
Constrain accepted dynamic address
In some conditions, your local network DHCP may briefly assign a bogus IP address to the robot before assigning a valid one. If network services are started on the robot using this bogus address, they will not work correctly after the valid address has been assigned. In this case, you will see that the ROS master is unreachable. There are two approaches to solving this problem.
 The bogus IP may be of the form
Use static network address mode
The first is to use MiRoapp to switch Network address mode to "static", and to specify the valid address in advance. Visit the Management page, open the ROS Network dialog, and change Network addressing mode to static and provide Static network address.
Constrain valid dynamic address
If you can't do this (because you want to use a dynamic address), the second approach is to restrict the set of valid IP addresses that the robot will accept at boot time by modifying the setting
user_setup.bash. The robot will then wait for a matching address before starting network services.
For example, to allow only addresses that take the form
192.x.x.x, use the setting below.
MIRO_DYNAMIC_IP_MATCHwas introduced at R190407—if the variable is not present in your
user_setup.bash, add it manually using the template at
Various configuration options are available through the ROS topic control/flags, which allows configuring the robot "per-session", i.e. until a reboot. Controllers that need to first configure the robot should do so at the beginning of their execution—see the example client_template for an example of this (search for "--no-cliff").
These control/flags can, alternatively, be set permanently on-board the robot. To do this, find the setting
user_setup.bash, and use the following table to choose a value.
For example, disable the cliff reflex and the automatic idling of kinematic servos by setting
NB: The default setting is
MIRO_BRIDGE_FLAGS=l—you should retain the
l flag, or the status LEDs will light up across MiRos PCBs, which is usually unhelpful.
|!||Any flags appearing before this marker (the exclamation mark) will be locked—that is, clients will be unable to release them through the ROS topic control/flags.|