For minimum latency and maximum bandwidth, or just to free your robot from reliance on the network, you can install run-time software directly to the on-board processor P3. There are three development pathways to choose from. We provide an example of each approach, below.
The easiest route is to write your control software in some interpreted language, which probably means python. There is no requirement to compile.
You can build your software in a compiled language and build it on-board using the installed toolchain. To do this, you have only to login to P3, write your code, compile it and run it.
However, the compile time will be much less if you use your workstation to cross-compile for the "target" (P3) and transfer the resulting binary to P3 for execution.
Whichever route you choose, you must start by configuring MIRO to seek the ROS master locally, i.e. running on the P3. To do this, login to MIRO, open up
~/.profile, and uncomment the two lines indicated at the top of the file.
Restart MIRO before continuing so that this change takes effect.
--onboardto the programmer when you Reprogram P3.
Run the master node
The ROS master node, aka
roscore, must be running on-board MIRO before you attempt to create your ROS network. It will make sense to start it from
~/bin/user_ready.sh eventually, but to begin with we can just start it manually.
Login to MIRO, and start
roscore in the terminal window.
The ROS master node is now running, and we can proceed to build our ROS network.
Run the bridge
The MIRO bridge,
miro_bridge, is so named because it "bridges" between the USB link to the platform itself (down to P2, actually) and the network. Running on-board, we won't be using the physical network, but we still use the bridge because we are treating the localhost (127.0.0.1) as a "network", and using the same network tools.
MIRO must be running the USB-ROS bridge in order to expose a ROS interface to the network. In normal operation, you will start the bridge using MIROapp, or use MIROapp to set it to autostart when MIRO boots. However, to make sure everything is working properly as you get started you might want to start the bridge manually first, as shown here, so you can check everything is configured correctly.
Log in to MIRO in a new terminal window, and run the single command below.
If your output looks like that above, the bridge is now running in that window and you should leave it open for now whilst you check you can send commands to the robot. If not, check the section Troubleshooting, below. Once everything is working correctly, you probably want to use MIROapp to enable autostart of the bridge.
Login to MIRO in a third terminal window, and use
rostopic to see if everything seems to be up and running. You should see a list of topics published by the bridge that expose the Interfaces to the network.
We provide an example interpreted Python Command-line Client on-board MIRO for you to use as a starting point. It also works to test that the preparations, above, have been performed correctly. Open a third terminal window, login to MIRO, and proceed as follows to start the python client.
The client's main thread produces tick, tock, periodically. Meanwhile, each time a message arrives from the bridge with updated
platform_sensors data, a message is sent back down, and the robot is driven in a forward-turn-forward-turn pattern, indefinitely.
An example compiled-language C++ Command-line Client is provided, namely
miro_ros_client, and it is pre-compiled. You can now run this to test the control of the robot. Open a third terminal window, login to MIRO, and proceed as follows.
show=f is causing each camera frame received by the client to be reported. The argument
drive=lean causes control signals to be sent to drive MIRO's joint to move.
Re-compile example client
The final step is to re-compile the client so that you can use it as a starting point for your own controller. To do this, change into the source directory and run
make, as follows.
Compiling the client on-board is really rather slow, even with a reduced level of optimization, so if you intend to do much development in a compiled language for on-board deployment, cross-compiling from your workstation will probably be a must. To prepare for this, you'll need to build the cross-compiler on your workstation, which takes a long while but only has to be done once.
Build the cross-compiler
The cross-compiler for MIRO is prepared along with the on-board Linux system. Therefore, to make it available on your workstation, you should build the on-board Linux system from source. Instructions for doing this are found at
~/mdk/extern/yocto/source/BUILD.txt. Follow the instructions there, now—the job is fairly straightforward, but the actual build will take a couple of hours. It will also require around 20 gigabytes of hard drive space. Make sure to complete the step "Build the cross-compiler" at the end, after building the system itself.
Compile example client
Exactly how you run the cross-compile on your workstation will depend on exactly where you installed the cross-compiler, so you may need to tweak the build; if so, you will probably want to modify the file
~/mdk/config/make/makefile.am335x-deb64. If you followed the recommendations in
BUILD.txt to the letter, that makefile should work as is.
You should change into the MDK source directory, and run
make for the target, as follows.
That step creates the executable at
The final step is to install that executable to your P3. You can do this using your preferred tools. One way is as follows.
Replace the token
192.168.1.101 with the IP address of your P3.
If you have set a password on your P3, use the following mouthful.
Replace the token
1234 with the required password.