I’ve just around to uploading my photos from Student Robotics 2009. This means that I can tell everyone about the fantastic cake that Lou presented us with when we got home:
Thanks Lou :-D
It took us over 12 hours to set-up the Cube for the Student Robotics 2009 competition, and something like 3 to clear it up. Similarly, Lou spent much longer creating this cake than it took to eat. Good things take longer to create than to destroy!
I present you with the Student Robotics Competition 2009 in one minute and eighteen seconds:
Can’t see the video? Try here.
Get the video in Ogg Theora here.
Unfortunately something went wrong with the timelapse set-up, and so we don’t have the first few hours of arena construction :-( Oh yea, I shortened the night-time section of the video, because it was somewhere around a minute long.
The second Student Robotics competition happened on Sunday. I thoroughly enjoyed it, and I hope all the students involved enjoyed it too.
We have a meeting later today in which there will be much discussion about what will be happening for next year. I’m writing this blog post so that I can get my thoughts down about what has happened without them being too tainted by that discussion.
Firstly, I think the electronics kit was in a much better shape than last year. Last year, there were a couple of fundamental issues that didn’t get fixed at the competition. There were problems with controlling servos, and there were fundamental issues with reading inputs. This year there weren’t any bugs that seriously blocked the teams’ progress.
We found two bugs during the event — neither of which was preventing the teams from actually progressing with their robots. The bug was that the serial lines connecting the slugs to their radios were swapped over. The circumstances leading up to this situation were rather amusing. The prototype of the board that connected the slug to the radio (the “power board”) had its serial lines accidentally crossed. In order to continue development, Tom had, quite reasonably, switched the serial lines over on his slug “umbilical”. Unfortunately, that modded slug got mixed in with some others and ended up being used as a template for modding all the other slugs.
Anyway, this required a really minor change to all robots. Tom and Jeff raced through modifying all the slugs at the competition in around 45 minutes. Luckily this didn’t delay any matches, as teams were still frantically tinkering with their robots.
The second bug that happened became known as the “one second” bug. We shipped out a firmware update to the power board. This update contained some changes that were required to make the radio work. Unfortunately, it hadn’t been thoroughly tested enough and contained a bug that meant the power delivered to the motors would be switched off after one second when in debug mode (teams can fake a radio “start” signal by pressing a button on the power board). Tom patched this quickly and we got it out in an update.
That second bug affected people more than the first, but I don’t think it resulted in too much pain.
We were let down by the internet connection to the event. Last year, I’d routed all traffic through the wireless on my laptop; I don’t recall any problems with it. I had naively assumed that it would be the same this year. Unfortunately there were frequent wireless drop-outs, which resulted in frequent misery on my part, as many of the competition features relied on it.
There were loads of “blue shirts” (volunteer helpers) who attended the competition, and I believe that every single one of them got thoroughly involved with what was going on. That was awesome. However, I’d prefer to see some of that enthusiasm spread out over the rest of the year!
I’m looking forward to Student Robotics 2010. I want it to be bigger, better and more insane. If you are an engineering student or engineer and you’re reading this, please do get involved. Get in contact with us, and we’ll go from there. You’ll need to find some sixth-form students that you can guide through the competition, so start looking for schools and colleges in your area. You don’t have to be from the University of Southampton.
I’ve been hacking away at fetproxy for the past couple of days. I’m now at this stage:
[rob@prefect fetproxy]$ msp430-gdb -n GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=msp430". (gdb) target remote localhost:2000 Remote debugging using localhost:2000 0x0000f800 in ?? () (gdb) info r pc/r0: f800 sp/r1: 7a00 sr/r2: 0000 r3: 0000 fp/r4: 7a00 r5: ff00 r6: 7f00 r7: ff00 r8: ff00 r9: ff00 r10: bf00 r11: f700 r12: bf00 r13: ff00 r14: fd00 r15: 0000 (gdb)
That’s where it’s at right now on my machine. gdb can now read the registers of the target device. The “continue” command’s next…
Site by Rob Gilton. © 2008 - 2019