I learned recently that the neighborhood high school will be participating in the US FIRST robotics competition. I've known about FIRST for a while, as one of the profs with whom I worked at OSU was a mentor for the organization, and had taken several teams to various competitions over the years. It didn't take me too long to decide to get involved.
The 2013 competition is called "Ultimate Ascent." The primary objective for the robots is to throw frisbees into various targets, thereby scoring points. At the end of the competition, robots can try to climb a pyramid, scoring more points the higher off the ground they can get. This last bit changes the robot design quite a bit: if a robot only has to throw frisbees, its design will necessarily be different than a robot that can climb.
There are about two dozen students on the team, with varying levels of interest and ability. The core team of active participants is about a dozen and these are divided into various working groups, each tackling a different aspect of the robot design. The team is planning to use a PandaBoard and one (or more) Playstation EyeToy cameras to detect the various goals. With my history of Linux, it was natural that I be assigned to the student working on this aspect of the robot.
Freddy, the student with whom I'm working, has some passing experience with Ubuntu. His laptop is dual-booting Windows and Ubuntu, and he'd made decent progress getting Ubuntu 11.04 installed onto an SD card for the PandaBoard. He had followed one set of instructions, but ran into problems configuring the OMAP4 add-ons. Watching over his shoulder, I asked him to start from the beginning, so that I could double check his work. He politely obliged, and we ended up at the same place: unable to install the OMAP4 add-ons. We tried yet again, this time using Ubuntu 12.04, with no more success.
"Well," I thought, "there's more than one way to skin a cat." So using Firefox I tired to browse the contents of the TI OMAP PPA to see if we could manually download the necessary files. This was met with an unhelpful message from the school's proxy informing me that the site I was trying to access was blocked. This proxy would end up causing all manner of trouble for us.
We had basically four options available to us:
Option #4 was clearly the option of last resort, as too many things could go wrong with the PandaBoard outside of the school. Option #3 was undesirable because Freddy was unfamiliar with Fedora and XFCE. We tried Option #1, but abandoned it when we didn't achieve immediate success. That left us with Option #2: install Ubuntu 12.10.
We now faced a new hurdle: there is no precompiled Ubuntu 12.10 image available to flash onto an SD card. Instead, we had to use the same install process as used by traditional desktops. This further meant that we couldn't easily install to the SD card that contained the boot image. Unfortunately, the PandaBoard only boots from the SD card, and not from USB. So we needed to flash the SD card with the install image, boot from that, and install to a USB stick.
All of that worked, but was exceedingly slow. Whether we used a slow USB stick, or the USB bus itself was slow, or some other factor was to blame, I don't know. But we realized that it was not going to be acceptable. The solution, thankfully, was extremely simple.
The PandaBoard uses a small 100MB FAT32 filesystem for its boot loader. The root image to load was defined in a simple text file on this partition. I simply repartitioned the SD card, leaving the DOS partition intact but creating two new partitions: one for an ext4 filesystem and one for a Linux swap partition. Using Freddy's laptop, we then copied the contents of the USB stick over to the new partition on the SD card. I edited /etc/fstab on the SD card's partition, updated the DOS partition's text file to point to the new partition, and that was it. The system booted Ubuntu 12.10 from the SD card without a hitch, and ran noticeably faster as well.
All of the above took several hours to complete, due to slow download speeds, lots of false starts, and a trip back home to fetch a USB stick of sufficient capacity. We decided to stop there, and would pick up the rest of the Ubuntu configuration the next time we met.
My biggest challenge through all of this was: how much do I let Freddy figure out for himself, and how much do I just do on my own to get it done. Clearly horsing around with Linux installation, partitions, and filesystems is not helpful to the overall construction of the robot; nor does knowing about any of this stuff help them win the competition. But at the same time, Freddy is clearly interested in the underlying technology and would benefit from a hands-on Linux education.
I decided to do most of the work, and explain as best I could what I was doing. Without a functional PandaBoard, much of the remainder of the robot construction was stalled, and we'd already taken a lot more time than I thought we'd need to get past our initial hurdles. Freddy was extremely patient and good humored about the whole thing. I didn't want to distract from the larger goal (ie: a working robot) with a bunch of yak shaving. Hopefully now that we have a functional Ubuntu installation, I can spend a little more time with Freddy on some of the more important Linux-based activities, and provide a more useful roadmap to Linux expertise for him.
Our next challenge will be to get the camera(s) connected and working, and to find how to identify the frisbee targets.
home / contact / flickr / github / keybase / linkedin / twitter
The contents of skippy are licensed under a Creative Commons Attribution 4.0 International License.