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.
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 sent my “sendkey” script to Ivor. This script automates the injection of one’s ssh public key into a remote host’s authorized_keys file (to allow password-less login). It didn’t work very well when Ivor ran it. I’ve now updated the script:
#!/bin/bash KEY=`cat ~/.ssh/id_rsa.pub` ssh $1 bash <<EOF mkdir -p ~/.ssh chmod u=rwx,g=,o= ~/.ssh echo $KEY >> ~/.ssh/authorized_keys chmod u=rw,g=,o= ~/.ssh/authorized_keys EOF
It can be run like this:
% ./sendkey remoteusername@remotehost
15/02/2007 Update: I fixed the script so that it made the .ssh directory first… kind of important.
29/02/2007 Update: Klaus pointed out that it might be useful to write how to generate one’s ssh keys:
/usr/bin/ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''
I just wrote a udev rule that would make any userspace i2c devices be owned by the i2c group:
KERNEL=="i2c-[0-9]*", GROUP="i2c"
(You can stick that in a file in /etc/udev/rules.d if you’re using Fedora).
Recently I needed to log the calls to read() and write() calls that a program made, including the data that went through them. I hacked together a small program, called “iomon”. It runs on Linux (or at least on my Fedora 8 install anyway). What makes it exciting is that I can use it without modifying the program I’m monitoring.
It uses features of the dynamic linker (the thing that’s resposible for loading the shared libraries that a program needs during execution - see man ld.so) to interpose a monitoring function between a call to a library function and the actual library function. When read(), write() or open() are called, an event is logged.
You can get iomon by checking it out like so:
git clone http://xgoat.com/proj/fiu/iomon/iomon.git/
You can build it by just running “make”:
% cd iomon % make
You might need to install the glib 2.0 headers (in Fedora, they’re in the glib2-devel package).
Example Usage
I thought it might be useful to demonstrate how to use it with an example. After building iomon, build the following C program (also available here) using gcc:
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
int main( int argc, char** argv )
{
int f, g;
umask( 000 );
f = open("test-file1", O_RDWR | O_CREAT);
g = open("test-file2", O_RDWR | O_CREAT);
write(f, "test", 4);
write(g, "second file", 11);
return 0;
}
This is the program that we’re going to monitor. As you can probably see, the program just opens a file called “test-file1″ and another called “test-file2″. It then writes “test” and “second file” to the first and second file respectively. Not really a very useful program, but it will suffice for this demo.
The next thing to do is set the LD_PRELOAD environment variable to contain iomon.so. The dynamic linker needs to be able to find the shared object file, and so the easiest thing to do is to put the full path into LD_PRELOAD:
% cd iomon % export LD_PRELOAD=`pwd`/iomon.so
Now every time that you run a program in this shell, iomon.so will be loaded first. At the moment iomon will default to dumping all the read, write and open calls to standard output in raw format. I suggest that you don’t run anything in this mode… iomon is configured through the IOMON environment variable. This takes a list of arguments just like any command line program:
% IOMON="--help" cat /dev/null Usage: iomon [OPTION...] iomon Help Options: -?, --help Show help options Application Options: -f, --file File to monitor access to. -l, --log Log file -t, --text-log Log in text, instead of binary --times Include times in the log
There’s some helpful information on how to use it. I’ll explain the arguments in a little more detail:
- -f FILE, --file FILE
Instead of logging all file access, just log access to FILE. iomon will monitor calls to open() to get the file descriptor assigned to FILE, and will only log calls to read() and write() that use that file descriptor. At the moment, iomon only supports one file descriptor per file (patches welcome!). - -l FILE, --log FILE
Send log output to FILE, rather than standard output. - -t --text-log
This makes the log human-readable. All data is converted into readable hex strings before writing to the log file. - --times
Prepend every log event with a timestamp. The timestamps are relative to the first interposed function call. Only implemented for text-based output (--text-log)
Right! Now we can run the test program:
% IOMON="-t --times -f test-file2" ./test 0.000016 open: 74 65 73 74 2D 66 69 6C 65 32 0.000138 write: 73 65 63 6F 6E 64 20 66 69 6C 65
And there we see the call to open for test-file2, followed by the filename in hex. Then there’s the data sent to it through write() also in hex. The logged call to open() happened 16μs after the first call to open(), and the write() call we were interested in happened 122μs later.
Hopefully I’ll be writing about why I needed this utility later.
Site by Robert Spanton. ©2008