Woah, Student Robotics 2010 just happened! It was a lot of fun, and the robots were significantly better than they were last year. The atmosphere at the event was better too, and it was amazing to finally see some people actually cheering for autonomous robots!
Enjoy the timelapse:
More competition write-up coming soon!
At the last Student Robotics doing, Jeremy showed me an exceptionally vile piece of hardware. Here, I share with you the pictures that I took to raise general awareness of this sort of abuse.
Student Robotics hardware development is heating up. The support for the currently shipped kit has almost reached a point where we don’t need to spend all our time on it, and a bunch of people eager to get involved in developing the new stuff have joined the group.
After a summer of racing to get the old kit into a shippable state, the Student Robotics hardware schedule is finally (ok, almost) in line with the rest of the groups agenda! We get to think about the new hardware design at the beginning of the academic year, giving us the maximum amount of time to both get new people involved and develop the new kit.
One of the major targets for the 2011 kit (uh, the 2010 kit is currently shipping — think of it like magazines) is the I2C bus that connects all the peripheral boards together. It’s getting replaced. From almost day one the bus has been misery and pain. If you’re thinking about using I2C as an interconnect between boards on a robot platform, I encourage you to think in a different direction. Due to the capacitance of the bus in our kit, we’ve had to knock the bus down to something like 20KHz. Furthermore, this bus gets along abysmally with the RFI emitted by the robot’s motors, so many transactions get repeated over and over until the checksums align.
So, what’s going to replace our I2C interconnect? I’ve been thinking about this in the back of my mind for a while, and discussion recently began on the mailing list. Right now, we have two options in front of us: asynchronous serial over RS485 or USB. Both of these are differential buses, and both appear that they could serve us well.
The USB option involves the least explaining. We’d stick a USB-to-serial chip (probably a FT232RL) on each board that’d interface with the board’s microcontroller. All the boards would plug into a USB hub, which would end up plugged into the BeagleBoard.
RS485 feels like it’s been around since the beginning of time. I expect that somewhere there’s a wire-wrapped array of 555 timers (with the requisite heatsinks…) that are doing something they shouldn’t over RS485, or a central heating control system sitting in some large company’s basement brimming with valves rocking out to RS485. However, the fact it’s still around and is still used extensively in many industrial applications is a good thing. RS485 transceivers are cheap! RS485 is compatible with daisy-chaining, which means that one could just plug another board in without having to get hold of any additional hardware (e.g. a hub).
The downside of RS485 having been around for ages is that most of the cheap transceiver chips are 5V supply only. 5V went out with the dinosaurs. All the cool kids use 3.3V and lower these days. Somewhat surprisingly, it looks like it’s cheaper to get a 5V linear regulator and RS485 transceiver to suit, rather than a 3.3V transceiver. Sounds disgusting, but it’s cheaper and performs just as well.
If we went for a master-slave relationship like we had in I2C, then we’d be OK. However, I’ve always been annoyed that the boards connected to our robot can’t generate interrupts of their own. This simple code:
from sr import * def main(): yield io.pin == 1 print "Beans"
Results in the JointIO board being continuously polled over the I2C bus to see if pin 2 has gone high. This sucks in terms of latency. It gets worse when there’s more than one coroutine running on the robot, and latency goes through the roof. So, I’d really like a multi-master bus. One where boards can shout at the BeagleBoard with an interrupt. That interrupt message can contain information about what the interrupt was as well, so the BeagleBoard doesn’t have to ask it, resulting in a nice short interrupt response time.
However, with multiple-masters come collisions: two boards may try to both write to the bus at the same time. There are a variety of methods of dealing with collisions that we could use, and many of these involve things like random-backoff times and detecting whether the line was driven in the way it was supposed to etc. My current favourite is a token-ring like approach, where we add point-to-point connections between boards that are adjacent in the chain, and get them to act like a big shift register with a single ‘1’ bit passing through it. When a board has the ‘1’, a.k.a. “the token”, it’s the master of the bus. When it’s done with the token, it just passes it on to the next board in the line. This way, there are no collisions to deal with, and each board gets a chance to transmit its data.
Which will win?
I’m not sure which will win at the moment. The RS485 option seems safe, and USB could allow for future exciting expansions. I’ll be doing more reading on USB over the next week or two to try and work out how it’ll perform in noisy situations. A possible option is sticking both the USB and the RS485 transceivers on the PCB design, and only populating one of them when it’s time to ship. Depends on how costly the board space would be.
In preparation for some hacking on the Student Robotics motor feedback, I’ve written a script for generating PDFs containing rotary encoder patterns. I wrote a utility that used cairo in C a while back. I thought I’d try out pycairo. It was pretty much the same experience. I’ve put it up on gitorious. Run it like this:
% git clone git://gitorious.org/rotenc/rotenc.git % cd rotenc % ./rotenc Usage: rotenc INNER_DIAMETER OUTER_DIAMETER N_SEG OUT_FILE Where: INNER_DIAMETER is the diameter of the inner circle in millimetres. OUTER_DIAMETER is the diameter of the outer circle in millimetres. N_SEG is the number of segments to draw OUT_FILE is the name of the pdf file to write to. % ./rotenc 50 60 16 encoder.pdf %
Update:I thought I’d experiment with Thingiverse, and upload it there.
I discovered codeswarm earlier, and had to run it on the student robotics subversion repository. Enjoy:
Can’t see the video? Try here.
Still can’t see the video? Download the Ogg Theora.
Chris and I spent a few hours this afternoon converting the SR board designs over to a new BOM-generation compatible situation. The new system should let us script the generation of the BOMs, gerbers and orders for the next shipment of SR boards.
Whilst we were doing this, Chris gave me the idea of making a Farnell search plugin for Firefox. It turns out that Firefox supports something called OpenSearch. This lets you tell a browser how to use a search engine. You should find my Farnell search plugin embedded in this page. In Firefox, click the drop-down box at the left of the search menu. It’ll give you an option to add this search, as shown in the screenshot on the right.
After installation, you should be able to search Farnell. This plugin uses my Farnell permalink URLs to do the searches, so you can type a part number in and will be taken directly to the corresponding part’s page.
Recently I’ve been playing around with my BeagleBoard to get the software situation sorted out for SR 2010 by the time our hardware freeze hits. I really don’t want another year of using slugs (NSLU2s).
I set up a development tree to contain our work, and I’ve written instructions on our wiki on how to get started with the SR BeagleBoard software situation. The Beagle information on our wiki pages might be useful to others outside SR as well.
The Beagle beats the NSLU2 hands down when it comes to computation. That’s not the only advantage that it has over our old friend. We had to manually hack up the NSLU2 in unpleasant ways before we could ship it:
We’re building a board that will sit above the Beagle that’ll make use of its expansion connector. The interconnect on SR robots uses I2C (my hopes for SR 2011 are currently set on RS485). The Beagle will master our bus. One thing that is a definite advantage of the Beagle over the NSLU2 is that the NSLU2’s I2C was bit-banged; we actually have access to a proper I2C peripheral this time.
The Beagle’s serial ports are a major advantage too. We could only access one serial port on the NSLU2, which meant we had to sacrifice serial console (imagine building a kit car then testing it by driving it blindfold) for it to talk to the radio module. The Beagle has at least 2 serial ports accessible, so there’ll be no misery there!
I’m quite surprised by the current state of the BeagleBoard community. It’s relatively young in comparison to the Gumstix community, but it already feels like there are many more people contributing to it. The kernel seems to be driving the board OK now (USB host has only just become functional in 2.6.29 for me), but there are still a fair number of extra bits and pieces that still need cleaning up. The most crucial one of these (for SR) is the configuration of the multiplexed pins connected to the expansion header.
So my current SR task is to get up to speed with the OMAP technical reference manual and brew up some patches that let us use I2C.
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.
|<< Newer Posts
|Older Posts >>
Site by Rob Gilton. © 2008 - 2019