So I decided to build a quadcopter recently, which turned out to be almost as much fun as flying it, and I got to get reacquainted with the smell of burning solder flux. A key component of a quadcopter (or any multirotor) is the “flight controller”, which takes the inputs from the receiver along with the readings from the onboard gyroscope and accelerometer and determines the correct speed for each of the motors to be running at in order to keep the craft stable in the air. The more fancy flight controllers have things like GPS and compasses to remove even more work from the pilot.
A labour of love (and elastic bands)
It turns out that a lot of the flight controllers about are based on the Atmel AVR series of microcontrollers, the same ones used by Arduinos. As always, “the community” has been keen to come out with improved and alternative firmware for the various controllers. I chose the KK2.1.5 for my build, which was no exception to this rule.
Something quick and interesting I did the other day was write a random tree generator at West London Hack Night. We chose to do it in C, which was a change from the normal higher-level languages. I was quite pleased that we ended up with something fairly simple and elegant and got it done within the allotted time. You can see the results up to that point on GitHub.
I have recently been playing around with Haskell, and after writing some small programs I thought I’d try something more medium sized. The idea of combining Haskell with trains was irresistible, so I created a project called tracks, which is a simulation that runs a number of trains on a rail network in real time.
I have got as far as loading up the rail network and service information from some files and then using Concurrent Haskell to run the trains on their own threads, with the signalling shared using STM. At the moment this just spits out the train events to stdout, but the plan is to do something a bit more pretty: to display a map of the network, with the trains shown running along the lines. Continue reading
I’ve updated my site with WordPress. As much fun as I’ve had writing my own CMS from scratch, my spare time is finding itself dedicated to other projects, and PHP just doesn’t have the same draw to me as it used to. So, in addition the new website launch, this is the official announcement of my latest project, Alice.
Alice is a widget library which I didn’t initially set out to write; it just sort of happened. In the process of working on a game, I realised that I needed something to create the assets. I needed characters, levels and eventually, music (there are plans for a synthesiser). Ideally I would have something that I could get some creative helpers to use. To start out with, I was using Blender with a few Python plugins, and then later also Inkscape. As the game engine developed, I needed to attach more data to the entities in the levels and it was getting more and more fiddly.
Having started to use and embrace Lua in the game engine, the natural solution seemed to be to build a widget library entirely from scratch. It would use C, SDL and OpenGL at its core, and Lua for the high level logic. It’s taken a while, but I’ve now got to the point where I can almost put together a complete model editor.
In the meantime, the Raspberry Pi was launched and as soon as I got my hands on one, I ported the code – the game engine and the widget library. With the Pi I could use EGL to take control of the display and run the entire thing as an kiosk-like appliance. No window managers for me.
As more ideas about how I could use my library on the Pi came to me, I split the widget code out from the game engine properly and gave it a name: Alice – Alice and Lua In Combination, Excellent – recursive, as all good project names are. I put the code up on GitHub about a month ago, but as I’ve recently built a working text box, now seems as good a time as any to officially announce the project to the world.
So here it is. Enjoy.