Hardware isn’t generally my thing. When it comes to software, I like to break and create. But in my opinion, hardware should just work. But even though that’s another story altogether, it did explain my apprehension when I greeted the UPS guy one morning delivering a BeagleBone Black.
Let’s begin with the BBB. It’s a computer the size of a credit card, which isn’t that impressive if you realise that your phone is a computer. I find the best way to explain it is in terms of two other products, the Arduino and the Raspberry Pi. The Arduino is a similarly sized (comes in multiple sizes though) controller where you can upload scripts, plug in a hardware circuit (wires and lightbulb, that sort of thing), and have it control the circuit. Despite its power in hardware control, it only has a small scripting interface for you to do your programming. The Raspberry Pi is the opposite. It’s a full Linux computer (based off Debian), but does not have proper hardware controls out of the box. The BBB provides the best of both worlds: a full Linux system (Angstrom Linux, but of course you can flash your own), and a ridiculous number of IO pins to control circuits. All this awesome power at 45USD.
The next step upon receiving this wonderboard was obvious. Let’s build a swarm of robots. Along with two university friends, Lawrence Huang and Gloria Nam, we set out planning the system.
The base was to be constructed out of a 1200x1200mm wooden plywood board and cut it into a circle with a hole in the middle. This would be the “world” where the robot swarm would live on. This world would operate like a Lazy Susan, and would have a two depots filled with some sort of resource. One at the center, and one at the perimeter. This gave the colony a purpose: it would need to collect resources. Above the board was where we would put the computer, BBB, power supply, and cables to hook up to all the bots below.
We then had to determine the behavior and movement capabilities of the swarm. It had to act as one, but still remain separate entities. It also had to disperse to discover where the rotated resource depots were, and the swarm as a whole had a set of goals and quota limitations. Five movement types (along with the math) were worked out to allow the bots smooth and flexible movement across the terrain.
The overmind was next. We would use Blender‘s very flexible boid simulator along with custom Python scripts using Blender’s Python API to simulate the swarm behavior on the computer and set swarm goals. At the same time, a real-time top-down view could be generated and displayed. Due to budget reasons, we couldn’t build the entire swarm of robots, but instead settled on building just one bot in the swarm, and having this bot track the motions of a single bot on the computer screen, but still behave as part of the full 32-robot swarm on the screen. Viewers could then see on the screen the full swarm behavior, and physically see a single bots behavior in front of them.
The car itself was then built. It was relatively small and was barely enough to fit the two continuous-rotation servo motors that were required to power its left and right treads. It had a little tank on its top to hold resources, a depositing mechanism at its front, and dragged along a massive conveyor belt to collect resources behind it.
Now the fun part – calibrating the simulated swarm with the actual physical swarm behavior, and doing all the physical PWM circuits. Many sleepless nights later it was a success. Here we see the bot doing a weird parking job into the depot and collecting resources, going back to the center, and depositing it. Apologies for the lack of video.
And there we have it. A swarm of robots. Did it curb my fear of hardware? Not entirely.
For those interested in the actual system, here’s a macro overview:
A few extra fun things from the project:
- Calibration was not easy. Actually, it was very hard. No, it was stupidly hard. It was ridiculously hard. Real life has so many uncertainties.
- Each bot is tethered to the overmind via 8 wires (3 per tread, 2 for conveyor belt). Could it be made into a wireless swarm? Yes. Did we have the money? No.
- Could it be modified to move in 3D XYZ space like a swarm of helicopters? Yes. Would I do the math for it? No.
- The actual simulation was done on the computer via Blender + custom python scripts. The computer was then connected via a persistent master SSH connection, which was reused to send simple signals to the pin’s embedded controller. So all in all the BBB actually didn’t do much work. It was just a software->hardware adapter.
- Because the computer was doing all the work, it wasn’t hard to add network hooks. This meant we could actually control the system via our phones (which we did).
- Weirdest bug? When (and only when) we connected the computer to the university wifi, flicking a switch 10 meters away in a completely separate circuit (seriously, completely separate) would cause the BBB to die. Still completely confused and will accept any explanation.
- Timeframe for the project? 4 weeks along with other obligations.
- Prior hardware and circuit experience: none. Well. Hooking up a lightbulb to a battery. Or something like that.
- Casualties included at least three bot prototypes, a motor, and at least 50 Styrofoam rabbits (don’t ask)
- Why are all these diagrams on weird old paper backgrounds? Why not?
- At the time of the project, the BBB was less than a month old. This meant practically no documentation, and lack of coherent support in their IRC channels. As expected, this was hardly a good thing.
Project success. I hope you enjoyed it too :)
If you’re developing a web application, especially one that uses PHP, you should know about Behat.
Behat introduces itself as “a php framework for testing your business expectations”. And it does exactly that. You write down your business expectations of the application, and it automatically tests whether or not your application achieves them.
You begin every feature description with a three liner following the form:
Feature: Foo bar
In order to ... (achieve what goal?)
As a ... (what target audience?)
I need to ... (use what feature?)
This is then split up into individual scenarios of using this feature, all of which are described using natural English following the Gherkin syntax. It then uses Mink which is a browser abstraction layer to run these tests.
I’ve been enjoying Behat for quite some time now, and I’ve noticed certain tests I need to write that come up again and again which aren’t included in the default Mink definitions.
@mink:sahi, and now we can use the following definition:
* @Then /^"([^"]*)" should be visible$/
public function shouldBeVisible($selector)
$element = $this->getSession()->getPage()->find('css', $selector);
throw new Exception('Element "'.$selector.'" not found');
$display = $this->getSession()->evaluateScript(
if ($display === 'none')
throw new Exception('Element "'.$selector.'" is not visible');
… so you can now write …
Then "div" should be visible
Worth highlighting is the
->evaluateScript() function that is being called. This means that anything you can check with JQuery can be tested. This is pretty much everything.
Another useful query is dealing with images. Modern web apps have to handle image uploading quite a bit, and often this comes with resizing or cropping (for avatars, keeping to layout widths, thumbnails). Wouldn’t it be great if you could just write…
Given I have an image with width "500" and height "400" in "/tmp/foo.png"
Then the "img" element should display "/tmp/foo.png"
And the "img" element should be "500" by "400" pixels
… and of course, now you can. All this code is included in vtemplate under the FeatureContext file.
A few months ago I was walking in the park near my university and stumbled across a rather warped but stylish fallen branch. Immediately I knew that this branch was destined to become an oil lamp. A couple months later of on-and-off work, I had finished.
The lamp itself was made out of laminated rings of wood, which encased a copper oil container. A sculpted nozzle allows the wick to raise out of the wooden container and light up. The container is hinged and can be refilled whilst the lamp is burning. The nozzle was made out of laminated ply, whereas the alternating colours of the container were various hardwoods. The heat distributors were zinc (if I recall right), and the glass was cut out of an old soya bean milk bottle.
The branch itself didn’t become the lamp, but rather the stand for the lamp. The slight uneven and rustic look makes it suited more for the outdoors, placed on top of lawn.
The wick passes through a wick raising mechanism. The design for the mechanism, built from steel and aluminum, was actually taken by a patent advertised by the International Guild of Lamp Researchers (yes, you read that right).
It consists of two cogs, one with pointed teeth, and another indented so that they mesh together. These are encased inside a block with a two channels – one for the cogs to fit into, and one for the wick to pass between them. Turning the cog with teeth catches the wick, and allows you to raise and lower the wick. This feeds in extra wick when existing wick burns out, and allows you to “dim” and “brighten” the lamp.
Each cog spins on an axle, but the indented cog’s axle has a extended slot, and by twisting a screw outside, you can push the cogs closer to one another. This allows the wick mechanism to accommodate for differently sized wicks.
This entire project was built from scratch (with exception of the wick and metal fastener at the top with the ugly blue plastic which was bought), with thanks to the helpful folks over at the university workshop.
All in all, I call this project a success. I’ve learned a ton about woodwork and metalwork, and got myself a rather unique lamp in the process. I hope you all enjoyed taking a peek too :)
Any computer enthusiast will tell you that whereas computers in general have been getting better over the years, keyboards have been steadily degrading in their preference for design rather than build quality. Simply put, all keyboards nowadays (characterised by mushy rubber dome chicklet keys) are terrible. If all of this sounds like a weird geek fetish to you, stop reading now. Otherwise, read this series of posts which will give you a good general knowledge of the subject.
I had been debating for a while now whether or not to invest in a proper mechanical keyboard. Given that I am mostly mobile on a laptop, lugging around another keyboard would be a pain. But recently I stumbled across an IBM Model M back from 1991 (there is a birth certificate on its back).
After giving it a thorough cleaning, I have been using this for a month now and it is a beauty to type on — I doubt I’ll ever go back to using a regular keyboard again.
A few gotchas for the uninitiated:
- It’s loud. Loud loud loud. Fine for your bedroom, but can be annoying in the office (you will bring it into work, won’t you?). However it’ll make everyone aware that you’re definitely hard at work.
- It’s big. So big that it won’t neatly fit into any bag. You may want to consider a “Spacesaver” edition without the numpad.
- There is no super (windows) key. Annoying if you rely on it for shortcuts, but ultimately a small price to pay for angels tapdancing on your fingers.
- It’s not hard to press. Although the keys are bigger, it’s easier to type on this than on other keyboards.
- It uses a PS/2 cable. You will likely need to buy a PS/2 to USB adapter to use it.
For those who have had the same dilemma as I did, make the switch. You won’t regret it.
Two months have gone by without blogging. In that time, I’ve been wrapping up the first half of my uni year. There are plenty of stories to tell, but I’ll delay that just a little bit longer.
In the meantime, I wanted to share some basic scores I produced for piano. I teach piano in my spare time, and I find it quite irksome that there aren’t any nicely-engraved free scores for download online for basic exercises such as major and minor (both harmonic and melodic) scales.
The score is 5 pages long. The first two covers major scales, and the final three cover the minor scales, which alternate between harmonic and melodic. Fingering is included when there are fingering changes. The sheet has no copyright or attribution text that might get in the way of professionalism when presenting to students. The sheet is created using LilyPond, which is quite possibly the world’s best music engraving software.
Click here to download
The document is licensed under CC-BY. You are required to attribute (by linking to this page) should anyone ask or if you want to share this on your own website.