Overview

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.

Configuration files

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.

Network

Constrain accepted dynamic address

See the related FAQ: Why can I not reach the on-board ROS master?

In some conditions, your local network DHCP may briefly assign a bogus IP address[1] 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.

[1] The bogus IP may be of the form 169.x.x.x.

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 MIRO_DYNAMIC_IP_MATCH in 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.

export MIRO_DYNAMIC_IP_MATCH='^192\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$'
The setting MIRO_DYNAMIC_IP_MATCH was introduced at R190407—if the variable is not present in your user_setup.bash, add it manually using the template at ~/mdk/share/config/user_setup.bash.

Bridge flags

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 MIRO_BRIDGE_FLAGS in 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 MIRO_BRIDGE_FLAGS=rk.

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.

lPLATFORM_D_FLAG_DISABLE_STATUS_LEDS
sPLATFORM_D_FLAG_DISABLE_SPEAKER
wPLATFORM_D_FLAG_DISABLE_WHEEL_CONTROL
oPLATFORM_D_FLAG_DISABLE_OPTO
pPLATFORM_D_FLAG_DISABLE_SERVO_POWER
fPLATFORM_D_FLAG_DISABLE_I2C_FAIL_WARN
rPLATFORM_D_FLAG_DISABLE_CLIFF_REFLEX
kPLATFORM_D_FLAG_DISABLE_KIN_IDLE
tPLATFORM_D_FLAG_DISABLE_TRANSLATION
!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.