My friend Elisabeth was recently responsible for baking a layer of a wedding cake. Wedding cakes are not like normal cakes. They tend to be quite large and regarded as quite important. So Elisabeth did a couple of practice runs of baking this cake, which was good for the occupants of this house as there was much yummy cake to go round. During these practice sessions it became apparent that the temperature control of our kitchen’s cheap gas oven was not suited to mission-critical situations. Using hot water causes our on-demand boiler to come on, which lowers the gas pressure reaching the oven, resulting in it cooling down. I had a shower during the second attempt, which resulted in the pressure going so low that the oven turned itself completely off. It turns out that, like electronic components, cakes also have temperature profiles that should be stuck to when processing them!
Ideally the oven would control the amount of gas being burnt based on the difference between the temperature within the oven and the desired temperature. However, cheap ovens are cheap. They work on the assumption that the gas supply has a constant pressure, and the room temperature is constant over all time. Furthermore, again because they’re cheap, these ovens do nothing in response to differing thermal masses. It seems that our cheap oven’s “temperature” knob just adjusts the target pressure of a gas pressure regulator. The relationship between the position of the temperature knob and the gas pressure is extremely non-linear, and bears much resemblance to its close relative, the all-too-familiar and highly-sensitive shower temperature control.
I decided that was was needed was a better temperature controller for the oven. This was quite clearly a situation demanding the fusion of some amusing mechanical hacking and electronics. Pulling the knob off the oven revealed a brass rod with two flats on its sides. I decided that the easiest way for me to motorise this was to mount a pulley on it. With Jeff having recently moved to London, I’d been left particularly latheless and so scoured the internets for suitable pulleys. The online shopping experience for mechanical parts isn’t anything like the world of online shopping for electronic parts. It is a world pretty much completely devoid of parametric search, and is full of websites that feel like they’re still being served from the same BBC Micro they were designed on… (That’s not to say that online electronic component shopping is a gold standard however — it’s got an awful long way to go, and unfortunately competition is not fierce within it.) Also, one gets the disconcerting sense that there are still a lot of fax machines involved in the mechanical parts world. After pushing myself through the HPC Gears website, which is still very much adheres to ye olde “the paper catalogue is the one true way” line of thinking (sigh), I found the pulley I was looking for. I was pleasantly surprised to find that I could order a single pulley, rather than 9000.
So, it was Sunday evening. The cake needed to be baked on Wednesday. Everything I ordered at this point would arrive on Tuesday (because ubiquitous 24/7 UAV-based shipping networks still belong to the future…). So I spent a couple of hours making sure I’d either got or ordered all the bits I needed. This is the final list of things that I ended up using:
- Pololu Simple Motor Controller 18v7 — A USB-controlled motor controller.
- A 12-24V MFA/Como Drills 918D series motor with what I believe to be a 60:1 gearbox (I have quite a few of this range of motors hanging around — they’re quite a popular choice for Student Robotics activities — so establishing exactly which gearbox the one I used isn’t straightforward…)
- A pulley for the motor’s shaft from Technobots.
- A K-type thermocouple from Farnell
- A MAX6675 (from Farnell): A chip that bakes all the interface and calibration circuitry one could want for interacting with a K-type thermocouple into a single 8-pin SOIC chip. It’s pretty awesome: thermocouple in, SPI out.
- A FT232RL FTDI adapter to interact with the MAX6675.
Luckily, the postal service functioned well, and everything did indeed arrive by Tuesday. So on Tuesday evening, Johannes and I hacked the mechanical situation together:
Next came the electronic and software side of things. This was reasonably straightforward. The MAX6675 has a simple SPI interface, which we talked to using the FTDI adapter. Hacking this together at high-speed, I decided to just use the bit-bang mode of the adapter. This is the most conceptually simple mode, as one just sets, clears, and reads pins on the adapter. I could have got the FTDI module to perform all the clocking of the MAX6675 itself, but this additional complexity really wasn’t worth it for an unneeded efficiency/speed improvement.
Interfacing with the motor controller didn’t take too long. The documentation about the Pololu motor controller seems unnecessarily convoluted to me. All I wanted was a table of the different commands that I could send to it over its USB connection. Pololu give a long manual for the board, in which the different commands are spread out, and interlaced with screenshots of various graphical programs that I had no interest in using.
Initially, I had plans to add a AS5030 magnetic rotary to provide feedback on the position of the temperature knob. It turned out the end-stops of the oven’s knob were sufficient for us to drive into them a bit. So we could easily get to “min” and “max” without feedback. It was about three in the morning by the time we’d got the mechanical, motor control, and thermocouple situation configured. Pressure to ship combined with sleepy haze lead to us abandoning the AS5030 plan, which was OK because we could just oscillate between min and max to control the temperature. This is known as bang-bang control. Our testing convinced us that we could get the oven to stay within something like ±5°C, which was definitely accurate enough for what we wanted.
Whilst Elisabeth was busy mixing the cake, the control loop was set to heat the oven to 160°C and keep it there. The mixture was put in the oven, and the system was left to run for two and half hours. By “left” I mean that Johannes had a constant eye on it throughout the baking procedure — this was an important cake! All was well, and the cake baked successfully:
Bring On The Graphs!
Of course, whilst the cake was baking, we logged all the available data to disk (you can download it too… for some reason… find it at the bottom of this post). Below is a plot of the temperature of the oven read through the thermocouple throughout the whole process. The black line is the temperature, and the red shaded areas show where the knob was set to “max”. The knob was set to “min” in the white areas.
So you should be able to see from the above graph that the cake stayed around the temperature it should have throughout the whole process. There are a couple of more interesting events in there. If we zoom into the left-hand end of that graph (at the beginning of the baking experience), we can see what happened when the oven door was opened to put the cake in. Here you can see how quickly an oven will cool down when it is opened.
The other interesting bit is when the cake was removed from the oven. The control and logging stuff was turned off for a short period after the removal, so there’s a bit of a gap in the data as well:
So, now for some analysis of the above data. Here’s a histogram of the temperatures sampled during the periods of time when the oven door wasn’t open and the cake was installed:
Some stats from that:
- Minimum: 156.75°C
- Maximum: 168.25°C
- Mean: 160.54°C
- Standard deviation: 2.09°C
So, a range of 11.5°C. Not bad for a night’s hacking. Elisabeth decorated the layer of cake, and transported it to the wedding, where it was combined with two other layers of cake baked by different people. News on the grapevine is that Elisabeth will be posting some photos on her blog any day now ;-)
There are two repositories of source related to this project:
- therm.git: C utility for interacting with the MAX6675 through an FT232RL.
- control.git: Python script to perform the bang-bang control, by interacting with both the above therm utility and the Pololu motor controller.
And the data is available in this CSV file. The columns are as follows: time (seconds), temperature (°C), and whether the knob was on max or not. Enjoy.
When I started my electronic engineering degree, ECS presented me and my fellow coursemates with a logbook each. We were told these things would become invaluable assets. I remember that I was initially sceptical. As I started to follow roads that were more undocumented and experimental (i.e. everything I like to do these days…), I found the logbook more and more valuable. I don’t think I would have survived the final year of my course without it.
There are few places that I’ll go for more than a few hours without my logbook now. It’s a place to writes notes and thoughts about what I’m doing. If I go home to visit my parents for a weekend, it’ll go with me. It’ll go with me on holiday. Everywhere.
The Itch
So that experience has been good. However, there are a few things about my physical logbook that have been aggravating me for a few years now. You may have noticed that computers have become a significant part of our lives. Physical, paper logbooks are absolutely perfect for projects that involve limited interaction with computers (and those that don’t involve copying of lots of data). Writing notes on paper about projects that involve software is painful. It’s quite challenging to annotate source code that’s on a PC screen by writing in a logbook.
Getting copies of software configuration, source code and other bits of data into a logbook entry typically involves lots of printing, cutting and gluing. It’s tiresome and results in a logbook that’s twice as thick as it once was. The increased effort that one has to invest to write notes about these projects makes it much less likely that one will write them to start with. There are more problems from here on. Getting source code out of the logbook back into the PC is not going to happen.
I believe the solution to this problem is to move the logbook onto the machine.
Solution attempt 1
A few months ago, I decided to try a first quick and easy solution to this problem. I set up a git repository on a server, and put a text file called ‘log’ in it. For the next week or so, I wrote notes into it. This was OK, but I had to be very careful of keeping the machines I use it from in sync to avoid conflicts.
Solution 2
A couple of evenings ago, I started hacking away on a new solution to this problem. The result is a small tool called ‘logger’. This logbook-like application managed a chronologically-ordered list of entries. This list of entries can be synchronised between machines.
“That sounds like a versioning tool” I hear you say. Yes, Logger does use git as its backend. However, it tacks on some limitations about what you’re allowed to do to the stuff that’s in the repository once you’ve put it in. Once something’s in the log, it’s there for good. Logger doesn’t provide any features for editing things that are already in the log. There’s a good reason for this. By making log entries that already exist immutable, synchronisation between machines becomes a doddle.
You can get logger from the gitorious project I’ve set up for it:
git clone git://gitorious.org/logger/logger.git
Logger stores all log messages in a git repository, accessing it using GitPython. This means that it can use all of Git’s goodies to simplify its job.
The README file that comes with logger provides a short tutorial on its use.
(If you want gitpython for Fedora, I quickly hacked together an rpm for it. This contains the required patch to support empty commits. May submit it to the repos at some point, but not now.)
The future
I haven’t been using this situation very long yet, but it already feels like it’s a good solution. My housemate Tobias and I have been discussing how we might extend this tool. Introducing better search capabilities is something we’re both interested in. I’m also quite interested in doing “partial clones” of git repositories — so that some machines don’t have to have all of the log on them. Logger’s a command line application right now. A GUI for it would definitely be interesting.
Patches are most welcome.
Logger’s still very much an experimental tool. I’m still working out whether it fully meets my needs. We’ll see.
p.s. Oh yes, there are probably some who will say there’s some stuff to do with logbooks being legal documents. This might be soluble using something like the service I heard the Post Office provides for signing digital documents.
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.
What happens when you realise you have all the required components to do some fun chemistry? This happens:
That’s sulphuric acid added to sugar. Warning: If you do this, do it in a well ventilated area… Sorry, I didn’t really think about lighting when taking the video! Also, my camera battery went flat, which is why there’s a rather sudden ending.
Here’s the result in a higher resolution for closer analysis:
The rod of carbon didn’t noticeably grow any more after the photo. I measured the mug at 80 °C just after the photo.
Banks. Some parts of them are good, some are bad. Let’s ignore their really bad repossessing-your-home side for a while and concentrate on what they’re good at. Many years ago, some guy realised that he could make money by storing someone else’s for them and then lending it to other people whilst they weren’t using it, and so on. Many highly confusing methods of extracting more money out of other money have since derived from this original approach.
Amongst some of those crazy things that banks do lies trading. Trading on the stock market. Some banks do automated trading, which has led to the acceleration of the stock market, with banks now requiring low latency links to stock exchanges to get a competitive edge.
Whilst firing money that they don’t necessarily have around at high speed using automated money cannons, the banks move their customers’ money around at extremely slow speeds. Many of them insist on sending their customers bits of processed dead tree every month or so to remind them about their money. When the customer wants to move her/his money into someone else’s account, they invariably have to wait a few days before it arrives.
Banks repurpose old cannons to fire money around. Photo under CC license — from flickr user StarbuckGuy.
So banks seem to have two faces. One face is highly automated and fast, whilst the other is slow, regularly resorts to paperwork, and doesn’t have a automatable interface. Unfortunately, the majority of people are exposed to this slow moving face. Presumably this face is slow moving and not automated because the demand for speed is low. I think it’s really sad that people don’t see the potential to automate the really mundane parts of banking away.
I share a rented house with others. I do the house “accounts”. There’s a spreadsheet (don’t get me started on spreadsheets… that’s a rant for another time) that I carefully maintain that annotates each transaction that occurs in the house bank account with things like who is responsible for them. The spreadsheet divides bills between people in the house.
I tend to put more money into the house account than is needed because the manual transfer and annotation of data between my bank’s website and the spreadsheet is extremely boring. The insulation that this extra money gives allows me to spend less time doing it. If my bank provided some sort of API that’d allow me to extract useful information about my accounts, then this work would be much less tiresome. Another application of bank automation is paying rent every 3 months. I don’t think any of the banks that I have accounts with allow me to set up standing orders with arbitrary periods — they seem to assume that everyone wants to pay monthly. Again, an API would allow me to script my transfers and set up more “advanced” standing orders.
I have accounts with several banks. Filing all the paperwork they send me is a boring chore. Then there’s all the forms that need completing to transfer money between ISAs. Misery!
In his “How To Become A Hacker” document, Eric Raymond writes:
Hackers (and creative people in general) should never be bored or have to drudge at stupid repetitive work, because when this happens it means they aren’t doing what only they can do — solve new problems. This wastefulness hurts everybody. Therefore boredom and drudgery are not just unpleasant but actually evil.
To behave like a hacker, you have to believe this enough to want to automate away the boring bits as much as possible, not just for yourself but for everybody else (especially other hackers).
Are banks moving in the right direction for their clients to automate interaction with them? No. They’re distributing devices that require people to be present when they do things related to their bank. We can only hope that one day enough of their customers understand that scripting their banking is the way forwards. I severely doubt this will happen within the next 20 years.
Whilst on the topic of banks, has anyone else noticed that the barclaycard’s “contactless payment” scheme looks like one of the most insecure things ever devised!?
I’ve spent some time lately sorting out a utility to tile Gerber files. I’ve wanted a utility to do this for a while, but I couldn’t find a utility that would work for me. Then I came across libgerbv, which is the backend library of gerbv, a Gerber viewer.
Since then, I’ve submitted two patches to gerbv, which were both accepted really quickly (yay!).
I had some other issues with libgerbv that I have fixed locally, and I’m working on cleaning up my patch for submission. It needs to touch some more things than my last two, so it’ll take me a little longer. I’ll be talking about that more soon when it’s compatible with gerbv CVS (CVS == sneeze).
It was only after I’d written most of the utility and come across the first libgerbv bug that I discovered that gerbv can do Gerber file tiling when invoked from the command line. My utility has a slightly different than gerbv’s. Anyway, more on that later.
Spirals
I’ve also been working on making a utility to make spirals on PCBs. It’s available here. If you’re interested, you can build it like so:
git clone git://gitorious.org/pcb-spiral/mainline.git pcb-spiral cd pcb-spiral git submodule init git submodule update make
Maybe it’ll be useful to someone else too…
When I want to link someone to a part on the Farnell website, I get because the URLs are both horrible and also I have absolutely no guarantee from Farnell that the URL will exist for any given period of time. This is the sort of URL you get for a Farnell part:
http://uk.farnell.com/texas-instruments/cc2520rhdt/transceiver-rf-zigbee-28qfn/dp/1573887?_requestid=22638
There most important part of the above URL is the Farnell part number. The rest is superfluous.
So I created a small script that creates nicer URLs for Farnell’s parts:
http://xgoat.com/p/farnell/1573887
Besides just being generally shorter and easier to parse, these URLs potentially have a longer lifetime. When Farnell change their website and all their URLs change, I can just change my script to match whilst keeping these links valid.
Feel free to use this redirection service. Just stick the Farnell part number on the end of the URL:
http://xgoat.com/p/farnell/${PARTNUMBER}
I had thoughts about adding RS, but haven’t yet got around to it.
Tom was in search of a faster way of typing “cd ../../..” and friends. He wrote a bash function that took a numeric argument. So with his script:
cd ../../..
becomes
xs 3
which is a reduction from 12 keypresses, including “return”, down to 5.
I felt that there was more to be done here. I had a feeling something could be done with readline. So I had a look around the readline documentation (see “info readline”) and found how to define macros for it. Then I stuck this in my readline inputrc file:
"\C-x1": "cd ../\n" "\C-x2": "cd ../../\n" "\C-x3": "cd ../../../\n" "\C-x4": "cd ../../../../\n" "\C-x5": "cd ../../../../../\n" "\C-x6": "cd ../../../../../../\n" "\C-x7": "cd ../../../../../../../\n" "\C-x8": "cd ../../../../../../../../\n" "\C-x9": "cd ../../../../../../../../../\n"
Looks ugly doesn’t it?! I couldn’t find a way of using a numeric argument within a macro, so I resorted to generating this above list with this Python:
for x in range(1,10):
print '"\C-x%i": "cd %s\\n"'% (x, "../" * x)
So now with this, those 12 keypresses are further reduced to 3: Control-x 3. Note that the “enter” key doesn’t get pressed.
How to use
To use that, one needs to get it into an rc file for readline. On Fedora 10, this involves editing your “~/.bashrc” file to contain:
export INPUTRC="~/.inputrc"
Then sticking the following in “~/.inputrc”:
"\C-x1": "cd ../\n" "\C-x2": "cd ../../\n" "\C-x3": "cd ../../../\n" "\C-x4": "cd ../../../../\n" "\C-x5": "cd ../../../../../\n" "\C-x6": "cd ../../../../../../\n" "\C-x7": "cd ../../../../../../../\n" "\C-x8": "cd ../../../../../../../../\n" "\C-x9": "cd ../../../../../../../../../\n" $include /etc/inputrc
It feels like this should be possible to make this neater by hooking into bash/readline in some way.
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…
| Older Posts >> |
Site by Rob Gilton. © 2008 - 2019