Having the Arduino onboard the UDOO is a godsend. It removes the need for a separate (and bulky) Arduino to act as an intermediary. The Arduino shows up as a standard serial device in Linux. In fact, it can be used just as if it was over USB.
Using the Arduino with the official IDE appears to be straightforward, set it up just as you would any other Arduino device, selecting the right board and COM port and then upload your sketch.
However, I very quickly ran into a rather difficult issue. We’re trying to keep the robot running as minimalist as possible, in terms of what software is running on the robot. For this reason, we don’t have an x11 (graphical desktop) server running. This means everything we do is from the Linux command line.
For no reasons whatsoever, the Arduino IDE requires an x11 server, even though it can be ran completely from the command line like so:
1 | arduino --board Intel:arc32:arduino_101 --port /dev/ttyACM0 --upload skynet.ino |
It doesn’t really make much sense, and I’m sure they’ll fix it someday, but until then, a solution needed to be found as we would be uploading many Arduino sketches, and having an x11 server running just for that would be a pain.
Thankfully, I found this, a guide to running the IDE headless. It uses Xvfb to create a minimal x11 server, runs the Arduino IDE, once it has uploaded, it kills the server.
Xvfb or X virtual framebuffer is a display server implementing the X11 display server protocol. In contrast to other display servers, Xvfb performs all graphical operations in virtual memory without showing any screen output. (From Wikipedia, CC-BY-SA)
Very clever.
I created the script, and placed it in our Arduino directory.
1 2 3 4 5 6 7 8 9 10 11 | #!/bin/bash SCREEN=3 Xvfb :$SCREEN -nolisten tcp -screen :$SCREEN 1280x800x24 & xvfb="$!" DISPLAY=:$SCREEN /home/sart/Arduino/arduino-1.8.5/arduino $@ kill -9 $xvfb |
If you are using an Arduino 101 / Intel Curie, like us, you will need to install the specific packages required to upload to the board. I ended up installing an x11 server, mainly to set up the board and to install the packages through the IDE, but have since found a way to install it through the command-line:
1 | ./arduino-headless --install-boards Intel:arc32 |
Because we’re uploading sketches pretty often, I created another script that calls the previous one, with some default values.
1 2 3 | #!/bin/sh /home/sart/Arduino/arduino-headless --board Intel:arc32:arduino_101 --port /dev/ttyACM0 --upload $1 |
I also copied the script to a path directory, so we can call it from anywhere like this:
1 | arduino-upload sketch.ino |
Easy! Now we just need to write some sketches.
The integrated Arduino really does sound fantastic! Far less can go wrong with that implementation.
It looks like you have a good workaround for running the Arduino IDE, but I just wanted to thow out an alternative view on the idea of keeping the robot minimalist (in terms of other processes). We barely utilized the NUC with the amount of processing we did on the S.A.R.T. v2, and remember that you guys have twice the RAM and an almost 20% increase in CPU clock speed. So is there any harm in doing some processing on the robot? I would think that the more you do on the robot and the less raw data you stream directly to the interface, the better wireless performance you’re going to get.
Then again, now that you have 4 motion streams, the robot may take more of a performance hit. Then again, now that you have 4 motion streams, wireless throughput will be at an even higher premium! I guess you’re going to have to find the middle ground here. 🙂