As expected, the Bexley robot was not selected to join a team for the elimination rounds, so we were done competing when the qualification rounds ended. The kids all seemed to take this fairly well.
I'm really glad I attended the event, and wandered around the pits, because it let me see a lot of things that aren't obvious about this competition. First, the word "competition" is something of a misnomer. Sure, each team is vying for a top spot, but the teams were genuinely working together in their alliances, and were genuinely happy for (and with) one another after each victory. I didn't see any gloating; nor did I see any trash talk. The level of sportsmanship seemed very high to me.
Indeed, one team had a banner that read "coopertition", which pretty adequately summarizes this event. Many of the teams had buttons and stickers to share. I saw more than a few kids walking around adorned in every single button they could find. Whether there was some higher purpose to collecting all the available swag or not, it was nice enough to see folks interacting and visiting other team's pits.
I was quite surprised by the quantity of big-name sponsors. NASA, Boeing, General Motors, various industrial manufacturers, software companies, and more. It's not clear to me how "sponsorship" relates to "mentorship", because some of these teams had very sophisticated setups, beyond what I'd expect from a group of high school students. But I suppose if your parents, and your friends' parents, all work at NASA and GM and Boeing, you're all likely to pick up a lot more from your everyday home life than if your parents work at, say, a bank.
Some things I saw were of the "Oh, why didn't we think of that!" variety, like the team that had a pit crew check list for all the things to check before and after every match: check for loose wheel bolts, grease third stage gear, battery charged, etc. Other things were of the "Hmmm... did students really do that on their own?" One team had animated CAD models demonstrating the function of various parts of their robot. I didn't get a chance to ask these guys if they did this before, during, or after the construction of their robot.
One of the most refreshing things I saw in the pits was the diversity of participants. It wasn't just boys building robots. There were two all-girl teams: the Girls of Steel, with their Rosie the Riveter motif, and the SWAT Girl With Wrench team. I think I only saw one team comprised of only boys, and if I remember correctly this team was from an all-boys school. All of the other teams had a healthy mix of male and female participants; and most teams clearly had girls involved in the construction of the robot.
On the drive home my brain was full of ideas on how to improve the Bexley team's effort for next year. I don't want to subvert the students' initiative in this, but I would like to encourage a more continuous effort throughout the year, rather than just a six week sprint during the competition period. I'd also like to see the incorporation of lessons learned from this event, and the traits of successful robots. Those that don't learn from the past, and all that...
Today was a full day of qualifying rounds for the 2014 US FIRST regional competition in California, PA.
I didn't investigate the arrangement, or the rules, too closely, but picked up a few things throughout the day. Each team alternates between the "Blue Alliance" and the "Red Alliance", and each round has these alliances comprised of different team members. In this way, each team gets to work with and compete against various permutations of all the other teams. This arrangement provided for some very interesting matches, as some robots complimented others extremely well. Similarly, some robots provided better defense against others.
As I understand it, all of the teams on the winning alliance earn points. This allows strong teams to carry weaker ones. I like this, because it avoids penalizing a weaker (or perhaps junior) team, while still allowing for competition and the element of surprise. The top eight teams at the end of all of the qualification rounds then get to pick teammates for the final rounds. This is where the "all teams play with and against each other" format pays off: a team might not have scored consistently well, but they may compliment a high-scoring team's tactics and thus be selected to join them.
Without a doubt most of the teams played strong offense today. As the day progressed, the skill of the robot drivers improved, and the quality (and quantity) of shots taken also improved. Most of the teams avoided any kind of aggressive defense until the afternoon rounds. Whether this was a function of learning the other teams playing styles (and strengths), or gaining a better understanding of what the referees would count as a foul, the end results were much more interesting afternoon matches.
The Bexley team made a conscious decision to make a defensive robot. Their thinking was that they could block opponents shots, and provide a valuable service to the other teams who had focused on offensive robots. This approach actually would have served them quite well, except for three major problems.
First, the Bexley robot was tall and thin, leading to some balance issues. During one match, the robot zoomed forward and toppled over onto its face, rendering it completely inoperative. The entire auditorium let out a gasp of surprise and shared frustration as the robot fell over.
Second, the Bexley robot wasn't a very effective blocker. The goal was to quickly hoist a pole into the air to block the upper goals. The competition rules placed firm limits on a robot's height, but permitted a telescoping arm of some sort to be extended for short periods. For several reasons the Bexley robot simply couldn't hoist the arm high enough to effectively block shots.
Third, the Bexley robot was pretty flimsy. Furious repair work was performed after almost every round. The other robots were almost all short and squat, which yields a number of competitive advantages. Those robots that weren't short or squat had superior design and construction.
Each match is played in two phases: a 30 second autonomous phase in which the robot does it own (pre-programmed) thing, and a teleoperated phase, in which a human driver controls the functions of the robot. Some of the autonomous sequences were nothing short of amazing. One team managed to score two aerial goals in that 30 seconds, all under the robot's own control. Other autonomous phases were absolutely comical, as a robot would spin in circles and lob a playing piece out into the audience.
During one of the later matches, the Bexley team placed their robot into position at the start of the match, and then stood back for the autonomous round. Their robot quickly extended its blocking arm, and managed to successfully block a shot from an opposing robot. It was actually quite a treat to see the robot perform as desired, and there was an awful lot of cheering (and laughter) from our section.
I'm impressed with the organization of this event. The FIRST people have been doing this for two decades or more, and it shows. Teams are queued up well before their match. The matches are executed in quick succession. And there's little wasted time after a match: the teams that just played haul their robots off the playing field as the next contestants are hauling their robots on.
The pit areas are a flurry of activity. There's a strong focus on safety, and pit access requires safety glasses. Simple prescription spectacles are not sufficient.
I've learned an awful lot about what makes a successful robot, as well as some of the traits of a successful team. I'm more energized than ever before to volunteer to help Bexley with next year's competition.
There are more qualifying rounds tomorrow morning. Then lunch, and then the real competition starts. I doubt anyone will pick the Bexley robot as a teammate, but we may be surprised tomorrow! I'm really looking forward to seeing how this concludes.
Jonah is a member of his high school's US FIRST robotics team. We joined him in Uniontown, PA for his team's chance to compete against other schools.
I helped Jonah and his teammates a bit at the beginning of their season by providing some guidance on Linux. It wasn't much, but it somehow earned me the title of "mentor." Maybe I can live up to that title next year.
On the few occasions I participated, I was generally impressed with their robot, and the speed with which they assembled it.
Walking into the competition area today, though, gave me a whole new perspective. The other schools' robots are all extremely well done. Dauntingly so. Watching some of the practice rounds was nothing short of awe-inspiring. While I was smoking cigarettes and listening to death metal at 16, these kids have figured out hydraulics, electronics, and computer vision systems, not to mention basic mechanical skills that I still lack!
Jonah's team's robot had some problems today, and was utterly unable to move during its practice round. I helped investigate the situation afterwards, and it appeared to me to be a networking issue between the control station and the robot. Due to time constraints (and some rather inflexible rules), they were unable to verify that they resolved this problem, so they'll be going into tomorrow's competition with more than a little trepidation.
Despite this, and despite the odds being against them in light of some of the competition, Jonah and his team are in pretty good spirits. They're pretty realistic about their chances, and are looking to enjoy the experience, as well as to pick up a few ideas for next year's competition.
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.