This page provides instructions on how to reconfigure the MIRO platform.
Configure the platform through the bridge
miro_bridge, accepts a broad set of arguments to configure its own behaviour and/or that of the platform—run it without arguments to list them. You can test a new configuration by using these parameters at the command-line, and then make it sticky by modifying the script that is usually used to run the bridge,
~/bin/run_bridge_ros.sh. Once this is done, future instantiations of the bridge through MIROapp will use the new configuration.
The remainder of this section discusses each parameter in turn.
stop_bridge.shfrom MIRO's prompt. You can run
miro_bridgewithout arguments at any time to see help for all the available options.
MIRO's default name as exposed to the network is "rob01" (the default name for a simulated MIRO is "sim01"). That will cause MIRO to publish/subscribe ROS topics under
/miro/rob01. If you are using only one MIRO in your environment, that will do fine. If you need to use more than one, you can set their names to anything you like (though "rob02", "rob03", etc., would be our suggestion).
The bridge accepts an argument
robot=<robot_name> which sets this name. Typical syntax would be
miro_bridge net=ros name=rob02, though of course you may prefer a name that makes sense to you.
platform/configmessage downstream; however, having the bridge start with your preferred camera configuration may be simpler.
You can choose the camera frame size and delivery rate through the arguments
frame_rate. The range of sizes and rates available is illustrated in the following table—if not specified, the default used is 320x240 @ 4fps.
MIRO will publish camera frames at the typical rate shown for each frame size with only very occasional dropped frames. The fast rate will offer a higher overall data rate at the cost of reduced reliability (some frames will be dropped), whilst the slow rate will offer improved reliability and reduced load on the receiver at the cost of a reduced data rate. You can choose any frame rate you like, these are just to give an idea of the range.
Typical syntax would be
miro_bridge net=ros frame_size=192 frame_rate=15. You can add the additional argument
show=f to see the actual frames being delivered, but you don't need that argument for normal operation. The actual frame rate selected will be the available rate closest to the specified target rate.
The default sync rate is every three cycles of the 50Hz base clock (i.e. at 50/3Hz), delivering three 50Hz packets at once, with a maximum latency therefore of two cycles (40 msec). You should not generally need to change this setting.
If your application requires that data be delivered in a more timely fashion, you can set a faster sync rate using the option
sync_interval (set to 1 for zero latency delivery), but this may reduce the stability of other data streams (video, audio) depending on how they themselves are configured. We recommend that you do not select a value larger than three for the sync rate, though values up to six are available, mysteriously.
Usually, audio from MIRO's ear microphones is delivered through
/miro/rob01/platform/mics, and camera frames through
camr. If you are not using one or both of these signal streams, you can reduce the load on the bridge by passing one or both of the flags
m (do not publish mics) and
c (do not publish cameras) through the argument
bridge (for example, use
bridge=mc to turn off publishing of both).
platform=mc, or some other combination.
MIRO is equipped with a loudspeaker and can vocalise and/or, at your request, play your favourite music to entertain you while you solder and/or code. The bridge provides streaming audio functionality through loading sample files from the SD card. You can trigger their delivery down to the platform by sending the message
bridge/stream to the bridge. If you need this functionality, the bridge will need to be able to find the sound files at startup.
An example sound library of public domain music clips is installed on your MIRO already at
/home/root/sound. To have the bridge load this, the argument
sound=/home/root/sound needs to be on the command line (it already is in
~/bin/start_bridge.sh). You will then be able to play these sounds through the GUI client. For details of how to create and install your own sound library to MIRO, see Bridge Interface.
log_level=verboseto the bridge.
To get some feedback on the traffic coming upstream through the bridge, you can use the
show argument, which accepts a string of any number of characters (run
miro_bridge without arguments to see what is available). For instance, pass
show=v to get periodic readouts of the main battery voltage—the MIRO below will need its batteries changing soon...
show argument can be useful while you are getting to know the bridge, but should not be used for normal operation.
Once you have decided on your command line for the bridge, you can configure it to start when MIRO boots so that MIRO will be "ROS ready" right after being switched on. Whilst still logged in to MIRO, edit the file at
nano are available on-board), which runs once the boot process is complete. Uncomment the line that launches
start_bridge.sh, as shown below, and the bridge will now start at boot, as configured in
Now reboot your MIRO. As the robot reboots, if you watch the LED indicators on the P3 board, you should see that the bridge is now starting automatically (LED2 will light when the bridge is running). Run
rostopic list on your workstation to check that MIRO has exported the expected ROS topics.
If the topics are not listed as expected, or the LEDs do not light up as expected, log in to P3 again. Check if the bridge is up using
ps aux | grep miro, and check the contents of
/tmp/log/miro_bridge.* for clues as to what has gone wrong.
In some circumstances, it may be useful to be able to uniquely identify a physical MIRO from a remote client. One way to do this is using the argument
miro_bridge, so that the ROS topic exposed carries the identity information. Alternatively, you can set the serial number of the robot and it can then be read back from the
platform_state message content, field
To do this, login to your MIRO and use the provided script
set_platform_serial_number.sh, as follows.
As can be seen,
get_platform_info.sh now returns the serial number