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.
USB
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
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[2] == 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.
Image used under CC license from flickr user viriyincy.
My good friends Joe and Lou left for Morocco in a modded Transit van in early July. Since then, they’ve been performing copious amounts of windsurfing and kite surfing and probably some other water-sports that I’m unaware of. They made it to Morocco a while back and are now on their way back. This week they had a guest appearance on their blog.
In the month running up to their departure, Joe worked really hard at modding the interior of his van so that they could sleep and cook in it and store all the equipment they’d need — including windsurf boards, sails, bikes, kites and many more things. It was an impressive feat, and it was finished days before they were due to leave.
Earlier this year, in February I think, I subscribed to fitting a dimmed LED lighting system into the back of the van for Joe. I didn’t actually get around to doing this until about a week before Lou and Joe were due to leave. At this time I was working for ECS and was due to leave for Iceland in a few weeks. Unfortunately, the electronics that we needed to take to Iceland really needed a few more months until I’d certify it as shippable — so I was already working reasonably long hours (the extremely long hours didn’t start until the week before we left for Iceland, but I’ll leave this story to another time) and only had a few hours each evening to work on it. Thus I had to bodge the dimmer together fairly quickly.
The dimmer was an MSP430F2002 connected to two FETs and two pots. The MSP430 used PWM to control the lights. Joe and I put the circuit into wall-mounted dual-knob dimmer switch casing and recycled its pots. I bunged the circuit onto stripboard in an ad-hoc manner and then Joe and I gave it a test in the van. There were two major problems:
- The lights would flicker. Due to the hardware limitations of the chip I was using, the PWM outputs had to be switched on and off by the software from a timer interrupt. I realised that I’d been suffering from a similar problem Alexis and I had before on the SR PWM board, and moved all other functionality out of the interrupt routines so that nothing could add noise to the PWM timing. This mostly solved the problem, but not completely. I think there was quite a lot of noise in the readings from the pots, but I didn’t get to the bottom of this in time. In the end, I added two filters — a moving average and an IIR filter that both acted to low-pass the readings from the pots.
- The MSP430 would brown-out sometimes when the board was initially switched on. This meant that the electricity supply to the back of the van needed power cycling every time this happened (there is a switch on the dashboard). This was really annoying and could have been solved by a reset controller. Unfortunately, I had none.
-
The pots turned out to be non-linear. In my initial investigation of the pots, I’d put my multi-meter across it’s terminals and seen a linear change in resistance. I obviously hadn’t investigated this thoroughly enough, as when I came to fit the pots into the circuit I found that the thing acted non-linearly. On closer examination, the resistance changed linearly between two terminals of the pot and the other two were linked by a fixed resistance. If you do your sums, you’ll find that this results in a non-linear change in output voltage if you just use this thing as a voltage divider.
I went mad. Then Jeff took apart one of the pots. We looked at it. We cried. We scratched off some of the resistive track that formed the fixed resistance. If we could reconnect the now free terminal to one end of the track then we’d be done. After a rather unsuccessful attempt at doing this with a rivet, we gave up on that approach.
If we could get our hands on the innards of a linear pot that was the right size, then maybe everything would turn out alright. We ferreted around in the pots we had lying around. It turned out that a pot that I had from a project we’d been doing about four years ago was exactly the right size. And I had two of them. Perfect. Jeff spent a few of the early hours in the morning cutting away bits of the pot casing to fit the new ones in. Success. The first pot was now linear. Then came the second pot. I was dead at this point, so I went to bed. Something went wrong with the second pot mod. Luckily, Maplin still sell a pot that’s of a compatible size! Joe went there the next day. Problem solved.
Jeff also spent the last few days in the run-up to Lou and Joe’s departure building a dashboard-mounted battery monitor for them. I’m sure he’ll blog about it soon.
Then they left. I heard very little about my precious LED controller for two months. Jeff heard nothing of his battery monitor either. We were worried. Was the electronics working? Lou and Joe were blogging, but about the wrong things! They were talking about wind surfing, kite surfing and camp sites. Were they avoiding blogging about the electronics because it had stopped working? It was great to hear about their progress along the way, but come on guys! Where were the electronics posts?! All Jeff and I could think about whilst we were walking around on an Icelandic glacier was “is the van electronics still working?”*.
So. September began. Jeff decided that he was going to fly out and stay with Joe and Lou for a week. Obviously he chose to do this to find out how the electronics was doing. And pretty soon after his arrival he provided me with an update. Now he’s managed to get the required information into their blog.
And the moral of the story is: if you need to find out about the status of a remote system you’ve put together, send an Engineer. Wait, that’s not entirely connect. Perhaps this is better: If you need to find out about the status of a remote system you’ve put together, sending an Engineer works.
* OK. So that’s not entirely true.
Justyn alerted me to the existence of this LinuxDevices article about the Beagle Board. This platform looks like a good candidate for the robot controller for Student Robotics 2010! If it stays at $150 that is.
We’re about a month into the new semester now (argh!), and the work is piling up. However, it’s all really interesting this semester. There’s no managementy goo courses that we have to take, so it’s a semester of continuous technology and knowledge pumping. Excellent.
One really exciting course is Biologically Inspired Robotics (ELEC6087). For this we have to build robots that are in some way biologically inspired. I’m in a group with Jeff, Steve, Alexis and Jo. Our project is called “Formica”. We’re going to build a lot of really cool and small robots that will hopefully exhibit some sort of emergent behaviour from simple rules.
We built this prototype over the weekend:
The prototype is made from bits that we had lying around the place, but it’s pretty true to the design that we had in mind for the final platform. The motors are pager motors, the big chip on top is an MSP430 and there’s a Li-ion battery attached to the underside. We spent some time trying to find two pager motors that had similar characteristics, and in the end resorted to removing the motor from my mobile and the motor from my Dad’s old phone (which is the same model as mine). So if you try to phone me at the moment when my phone’s on silent, I almost certainly won’t answer. Jeff had a stroke of genius and extracted the battery from his bluetooth headset (it could be a Li-ion Polymer and not just a Li-ion, I’m not sure). The wheels are formed using a magic tool that Jeff lathed up, I’m sure he’ll blog about that soon…
The concept of having around 50 of these things driving around and interacting is pretty amazing. I can’t wait until it’s a reality!
I’ve been using various I2C things in Linux for the past year and a bit, and I’ve learnt a few things about it from that. Here I hope to collate some of this information.
Since our robotics kit uses an I2C bus, it would be really handy for me to have a USB-to-I2C adapter. With the addition of a simple RJ11 adapter, I’d be able just plug in a module and start hacking on it without the annoying set-up times, that involve sorting out the Slug and power board combo. If Student Robotics had several of these adapters, then any member could just grab a module and start hacking on some code.
i2c-tiny-usb:
I’ve just come across Till Harbaum’s i2c-tiny-usb design. Rather surprisingly this uses a relatively cheap ATtiny45 Atmel AVR and nothing else. It bitbangs the USB protocol. Apparently, this works rather well. What’s even more exciting, is that there’s a kernel driver available for the i2c-tiny-usb. This makes it behave as a proper Linux i2c bus device, so interacting with it from software couldn’t be simpler. This board can be an I2C master with clock speeds of up to 50KHz.
OSIF
The Open Source InterFace (OSIF) is part of the OpenServo project, and I believe was designed by Barry Carter. Carter took the i2c-tiny-usb design, and adapted it to use an AVR with more pins, and upped the maximum I2C clock speed to 400KHz. Furthermore, the board has support for serial (I think UART), 6 GPIO lines and an ADC channel. Barry Carter sells the OSIF for £20 a board.
Carter also provides a kernel driver for the OSIF as well :-D
I bought an OSIF earlier today. I like the way that the OSIF uses work from two previous open hardware projects to create
- Add 4 lines to the firmware for the MSP430s that sequence the stepper motor drivers so that they half-step (so that there are sometimes two active coils).
- One’s resolution has doubled.
- Dance.
- Push changes up to public firmware git repository.
We did have a resolution of 0.2mm per step. Now we have 0.1mm. w00t.
I just wrote some code for the MSP430F2011/2/3 to control two H-bridges connected to a bipolar stepper motor. Available in git form here:
git clone http://users.ecs.soton.ac.uk/rds204/git/stepper-driver.git
Takes a STEP and a DIRECTION signal – ready for connecting to a parallel port for use with EMC.
As for what it’s driving – it’s amazing. More on that later!
Just been browsing Maxim’s range of switch-mode controllers. The MAX1724 [datasheet] looks really good. It requires only two external caps and one inductor to operate. Input voltage range: 0.8v to 5.5v. 0.8v!
I should also mention that it’s in SOT23-5…..
/me attempts to find somewhere to buy lots of them…
| Older Posts >> |
Site by Rob Gilton. © 2008 - 2019