Because Orcad Capture’s “DSN” files aren’t a free or open format, I’ve converted the beagleboard schematics into a PDF on Uni machines. Enjoy. The PDF file is a derivative work of the files produced by the beagleboard project, and is licensed under a Creative Commons Attribution-Share Alike 3.0 license.
Our house used to have a shed that looked like this:
Jeff and I decided that we needed to upgrade the shed. So we removed the old shed, which we think may have been an Anderson shelter — although it seems to differ a bit from the description on wikipedia. So we chopped it up:
Then we shoved it in Jeff’s car and took it to the dump:
Next came the clearing of the area for the new shed. There was a lot of bits of dead tree and stuff in this area, which we burnt. We wanted to burn these really quickly as we had a lot of stuff to get through — so we raised the fire, in the shopping trolley that we found under a tree in the garden, in order to give it more ventilation. Faye generously leant us her hairdryer, which was then attached to some tubing that we pointed into middle of the fire. This made the fire insanely hot:
(That’s a marshmallow on a stick). Jeff melted some aluminium in the middle of the fire, and then managed to get some steel red hot in it (see the flickr pics). It’s surprising what you can do with a hair dryer and some wood!
Jeff and I were contractually obliged to give Justyn a single unsalted roasted peanut. I won’t go into the details too much here, but there was a bet that involved university wifi and our house. Jeff and I lost, hence the peanut.
Unfortunately, it was difficult to purchase an unsalted roasted peanut from the shops, so I roasted it myself.
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.
We’ve finally got around to releasing the designs and code for the Formica robots. You can find a technical report over at Jeff’s website Warranty Void if Removed. The hardware designs are under a CC license, and we’ve GPL’ed the firmware.
I’ve made the firmware available here. To build this, you’ll need to have an install of mspgcc that’s been built (and probably patched) to compile for the MSP430F2254. If you’re using Fedora 9, then you should be able to use my mspgcc RPMs.
Compilation
Compiling it is as should be as simple as running “make”:
[rob@zarniwoop formica-fw-r468]$ make ./freq.py 500 3500 3 > freq.c cp .freq.h freq.h sed -i -e "s/_NFREQ/`echo "$(((1 << 3) + 2))"`/" freq.h sed -i -e "s/_NBITS/3/" freq.h sed -i -e "s/_MIN_PERIOD/500/" freq.h sed -i -e "s/_MAX_PERIOD/3500/" freq.h sed -i -e "s/_SYMBOLS_PER_BYTE/`./.sym_per_bit.py 3`/" freq.h curl -s http://users.ecs.soton.ac.uk/rds204/formica/rev.php > .fw_ver msp430-gcc -o main -mmcu=msp430x2254 -g -Wall -Os -mendup-at=main -DRAND_WALK_SPEED=3 -DFW_VER=`cat .fw_ver` main.c ir-rx.c freq.c net-rx.c opamp-1.c ir-tx.c ir-tx-data.c net-tx.c adc10.c random.c motor.c virus.c smbus_pec.c battery.c ir.c food.c bearing.c flash.c behav/braitenberg.c time.c behav/parking.c behav/watchdog.c -Wl,-T,lkr/msp430x2254-lower.x Firmware revision 485 msp430-gcc -o main-top -mmcu=msp430x2254 -g -Wall -Os -mendup-at=main -DRAND_WALK_SPEED=3 -DFW_VER=`cat .fw_ver` main.c ir-rx.c freq.c net-rx.c opamp-1.c ir-tx.c ir-tx-data.c net-tx.c adc10.c random.c motor.c virus.c smbus_pec.c battery.c ir.c food.c bearing.c flash.c behav/braitenberg.c time.c behav/parking.c behav/watchdog.c -Wl,-T,lkr/msp430x2254-upper.x Firmware revision 485 cp -f freq.h .freq.h.win cp -f freq.c .freq.c.win [rob@zarniwoop formica-fw-r468]$
This will generate two binaries: main and main-top. These contain the same code but they are linked into different regions of the flash. You can load either one of them into the robot’s MSP430. However, when you start working on getting them to flash each other over IR, you’ll need to make sure that you’ve got the right ones loaded.
You may notice that there’s a curl in that make output. This grabs a firmware version number from the web. Obviously you can change the URL this grabs it from, but feel free to use the one that I’ve set up in my ECS account.
p.s. I should add that none of the stuff from the Alife conference has involved the title “Formica” or our logo, which was a little dissapointing. So, let me point out that this is the same project as in all of these news stories.
Rhythmbox’s last.fm plugin appears to work properly!
Thank you rhythmbox developers :-D
I got fed up with having to run through the build procedure for mspgcc with others. I think I must have done it four times now. So, I’ve packaged it into some RPMs that I’ve built for Fedora 9. I’m trying to get them into the Fedora repositories, but for now you can download them from here. These include the patches for the msp430f2xx, and the other patches that the mspgcc guys recommend.
I haven’t done GDB yet, but hope to over the next few days.
A message on the Student Robotics mailing list had cast some doubt as to whether it would be possible for teams to launch balls from a robot. Jeff and I strongly disagreed with this pure conjecture. Having been involved previously with building a ball launcher for a FIRST robot, we knew that it was possible (video here) with much larger balls than SR is going to be using.
But we felt that further conjecture about the situation wouldn’t have helped. Just after I’d digested what the mailing list post had said Jeff and I started hacking up a demonstration device from stuff that we’d got lying around the place.
We built a launcher from a battery-powered drill, a random wheel Jeff had lying around, a coach bolt, numerous wood screws and a few bits of wood. The most complex part involved was a turned insert for adapting the wheel’s hole to the coach bolt diameter. The result of this build was a little disappointing:
Can’t see the video? Click here
After considering the situation for a few minutes, we decided that this didn’t sufficiently demonstrate that balls could be launched. We could either increase the wheel diameter or increase the rotational speed. Since we didn’t have a bigger wheel available and Jeff had got a suitable motor from a printer, we changed the motor. This involved putting the wheel on bearings made from chopping board and coupling the motor to the shaft with plastic tubing:
We connected this motor up to my power supply. This motor had previously been pulled from a printer so we were unaware of its specs. Sticking 36V into it from my bench PSU worked pretty well. The performance with the faster motor was much improved:
Can’t see the video? Click here
We pointed it upwards to find out how far up it would go. Unfortunately, our measurement system became saturated:
Can’t see the video? Click here
We made a point of timing how long it took us to do this prototyping: 4 hours and 49 minutes. That’s two prototypes and dinner. Not bad, considering that we got a definite answer about whether one can build a ball launcher. There are a few more photos and videos on Flickr.
Once again, the value of actually getting one’s hands dirty and actually building something has been demonstrated.
P.S. I’m back from Iceland, but more on that later…
I’ve been in Iceland now for over a week, along with the glacsweb team — including Jeff and Tom. We’ve just moved into our third accommodation, which has a free wifi connection that makes it highly compatible with our high bandwidth requirements. I took a couple videos. The first is of our previous (and second) hacking situation:
Yesterday, Jeff and I finally got to go to the glacier (we were locked in the above shed for about 5 days and gradually became more and more insane).
At the moment we’re fighting a battle against failing probes. When we start looking at one, it fails! Argh!
I’ll try and stick more up here later.
I got fairly distracted experimenting with an idea I had about the Student Robotics wiki logo:
Still very much a work in progress…
| Older Posts >> |
Site by Robert Spanton. ©2008