Controller manager

To return to the Home page, click the red exit symbol.

Controller status

This section indicates what the on-board controller manager is currently doing, and will update automatically as you send requests.

Stop controller

Click the stop button to stop the running controller, if there is one.

Start ... controller

Press any of the "start" buttons to start one of the test controllers running. A short description of each is given on the page in MiRoapp.

See Demo mode for more description of the behaviour when you start this controller.

The robot may move, and you should prepare for this—in particular, make sure it is not able to fall!

Demo controller options

The demo controller has various configuration options, which can be changed either before or whilst the controller is running.

For information on how to "wrangle" a MiRo in demo mode, see the Wrangling page.

Demo flags

Flags modify the demo controller's behaviour—some are intended to account for user preferences, some for an unpredictable environment, and some may be relevant only to particular use cases.

Autostart demo at boot
Causes the demo controller to be started automatically at boot time.
Disable vocalisation
Turn off MiRo's voice.
Disable translation
Prevent MiRo from moving from the spot. This allows reduced supervision, but do not rely on perfect performance at staying put (e.g. do not trust MiRo to stay safely on a table!).
Disable rotation
(Also) prevent MiRo from rotating its body around the spot.
Disable neck
Prevent MiRo from moving its neck (this does not imply disable translation or rotation).
Disable sleep
Prevent MiRo from falling asleep.
Disable cliff reflex
MiRo will no longer protect itself from driving over cliffs; this can be useful in environments where there are no cliffs, and where the floor surface is causing the cliff detectors to misbehave.
Disable shun cliffs
Unless this flag is set, MiRo will actively turn away from cliffs when deciding what to do; with this flag set, MiRo will turn away only when something else gets its attention.
Disable affect from sound
Make MiRo deaf for the purposes of affect (otherwise, loud sounds will make MiRo unhappy); useful in noisy environments such as exhibitions
Disable attend motion
Do not attend moving objects detected by the cameras.
Disable attend sounds
Do not attend to audio events such as hand claps or voices; useful in noisy environments such as exhibitions.
Disable attend faces
Ignore human faces when deciding where to look.
Disable attend ball
Do not attend to MiRo's toy blue ball.
Disable express through tail
Turn off expression through the tail.
Disable express through light
Turn off expression through the (illumination) lights.
Disable express through ears
Turn off expression through the ears (rotation).
Disable express through eyelids
Turn off expression through the eyelids (blinking etc.).
Disable unhappiness
Prevent MiRo from reaching less than neutral happiness.
Disable move away
Prevent MiRo from performing actions that cause it to "turn away" from what it is attending; together with the above flag, this renders MiRo rather positive in character.
Disable stall detection
Automatic wheel stall detection will usually cause MiRo to reverse and try something else; you will see this as the eyes are held briefly closed. Disable this if your floor surface is triggering the stall detector in error.
Disable sonar modulation
Without this flag, MiRo will use the nose-mounted sonar to reduce the incidence of running into obstacles in the environment; disable this if the sonar is faulty, to restore other functions.
Debug sonar modulation
Use this flag to determine if the sonar is operating correctly ("submarine" sonar pings indicate the measured range to an obstacle, whilst the frequency and amplitude of "trilling" indicates that MiRo is resisting forward motion because it detects an obstacle ahead).
Debug detection
This rather crass flag will cause MiRo to make an annoying noise when it detects a face or its toy ball.

Cliff sensor sensitivity

Readings from the cliff sensors will vary a fair bit depending on the environment in which MiRo is used. Cliff sensors are used both to drive the cliff reflex (try not to fall off edges) and to favour actions in the demo that move away from cliffs that have already been detected.

A meter is provided—click "Enable sensor readings" and the slider below will indicate the average cliff sensor reading across the two sides. You can move your MiRo to a cliff, and to a safe place without a cliff, to measure what the cliff sensors see in the two cases.

Having done that, you can now—if necessary—adjust the graduated slider to set the cliff threshold to midway between these two readings. MiRo will now detect cliffs as accurately as possible, for the given floor surface and lighting conditions.

Either or both of the cliff-sensor driven operations can be disabled using the flags "Disable cliff reflex" and "Disable shun cliffs".
When the demo is not running, the cliff sensor threshold set here is still used by the embedded software to run the cliff reflex, and the "Disable cliff reflex" flag of the demo does not have any effect. If you need to disable the cliff reflex in normal use, send PLATFORM_D_FLAG_DISABLE_CLIFF_REFLEX to the control/flags ROS topic (see client_test).
Cliff sensors can be fooled by varying lighting conditions and/or presence of unrelated objects and by backwards motion; users should not assume they will be sufficient to prevent the robot driving off edges.

Behavioural probability

"Behavioural probability" can be adjusted between 0 and 100% and controls two things. First, for each action MiRo selects (such as "orient" or "approach"), a dice is rolled, and the action is executed with the specified probability (otherwise, no action is taken). Second, every few seconds (by default, ten), a dice is rolled, and MiRo is responsive to user interaction (touch) for that period with the specified probability. Together, these effects control the degree to which MiRo is responsive to interactions with the user. This setting is used to probe the impact of this responsiveness on user-robot relationships.