Saturday, 6 December 2014

Second prize overall!

"Steve" won second place in the over £75 category. Not fast and not massive, but good at most of the challenges. Hurrah!

Sumo final

Beaten by a tricky wedge. Very chuffed to get in to the final though.


Second place in code quality with 42/44. Damn those last minute hacks!

Sumo round 3 - Win!

Given two bys, due to competitors failing to present themselves, we entered straight in to round 3 against another Dagu Rover 5. Flashy Rover was built and run by one of our suppliers, Dawn Robotics. Evenly matched for some time, we managed to get under them and once in their back, it was game over.

Round 4 beckons.

Only sumo left!

Three point turn was interesting. Our practice run was a farce as the robot jiggled on the spot and then stopped. It turns out, upping the main control rate meant it was checking the distance remaining from the last command before the Arduino had processed it. This meant it always saw zero and ran all the motor commands in quick succession. A quick code tweak later and we were back in business. I thought our proper run was pretty poor, but the judge was happy and declared we were third so far that day!

Straight line speed test was a good as we could manage as our robot is quite slow.

The obstacle course, again, was about as good as we could do. No penalties and all obstacles cleared in 45 seconds would have been good in the morning, but a recent run at 25 seconds had set the bar very high.

Now we wait for the sumo, with a fresh set of cells in hand. Fingers crossed!

Two runs in!

So, not bad so far...

Our robot valiantly completed the line following challenge, but 2m47 over the 5m00 time limit. Great work by Matt Lane implementing an OpenCV based line following algorithm using the Raspberry Pi Camera. I'm calling that a moral victory, even if we were disqualified for being too slow.

Next up was the Proximity Challenge. The first run was a bit of a disaster - we stopped over 30cm from the board. Discussions ensued, and we demonstrated against a nearby door that our robot was capable of much better. We weren't allowed to modify the course, but we did move a few nearby shiny objects which we thought might be interfering. Our second run netted us 20.5mm (yes, millimetres). Result! The third run came in at 28mm. The runs are added together, so the failed run cost us quite a bit. We'll have to see if anyone else gets a failed run too.

Next up, Robot Golf at 11:35.

We're at PiWars

So Matt Lane, Matt Kingston and myself have spent the last few months putting together our entry for PiWars. We're very grateful to our bosses at for allowing us to indulge in our hobby and supporting us with some of the parts. Last night was pretty hectic. I left the guys at about 11pm to catch my bus, but they stayed well after that. There are various challenge we need to complete and we're there or thereabouts for most of them:

  • Line Following, autonomously
  • Drive up to a wall without hitting it
  • Chase a ball through a goal
  • Drive flat out in a straight line
  • Do a three point turn, autonomously
  • Sumo challenge
  • Aesthetics
  • Code quality
  • Obstacle course

Right now it's 10:40am and the we're up on the line following course at 10:55. I haven't seen many other tracked robots, so we're hopeful about the obstacle couse - assuming we survive the Sumo and don't blow the H-bridge!

The specs of our robot, named Steve for reasons we don't remember, are:

  • Raspberry Pi B+
  • Arduino Pro Mini (5V / 16MHz)
  • UBEC switch mode power supply
  • 6x 2500mAh AA Ni-MH cells
  • L298N H-bridge board
  • Seeedstudio Ultrasonic ranger
  • Raspberry Pi Camera
  • Dagu Rover 5 Chassis
  • SparkFun Nokia 5110 LCD

Wish us luck!


Wednesday, 20 August 2014

Pi Wars

I'm thinking about entering Pi Wars in December. It's a Raspberry Pi based robot competition.

So far, I've scrounged a few bits and pieces, and put together a really basic remote control system using a Playstation 3 controller, an L293 H-Bridge driver board and an Arduino. The Raspberry Pi can do PWM and USB/Bluetooth, so it can take the place of both the laptop and the Arduino, when I get that far.

There are a few bugs, as I mention in the video, related to input handling. Basically if I play with it too much, the motor gets stuck (usually at maximum speed) and I appear to stop getting events from the joystick char device. But for now, here's a short video.

Saturday, 16 August 2014


And now for something completely different.

Someone asked the question the other day - what's the CO2 cost of the concrete in a Wind Turbine?

You need 1000 tonnes of concrete to install a wind turbine
You create a total of 410 kg of CO2 per m3 of concrete
Concrete has a density of 2.4 tonnes per m3
=> One wind turbine requires 416 m3 of concrete
=> You can attribute 170 tonnes of CO2 to the wind turbine's concrete

Assume a turbine base lives for 20 years.
Assume the turbine generates 2MW watts max
Assume an average utilisation of 30%
=> in 20 years, the turbine will generate 105.2 GWh

=> concrete production adds around 1.6 tonnes per GWh (Or 1.6 grams per KWh) to wind power.

If you make electricity using an fossil fuel power station, you create:

Coal: 910 g/KWh
Gas: 390 g/KWh

(The UK average across all fuel types, including renewable and nuclear)
is 470 g/KWh.

So, the effect of the concrete on CO2 emissions is negligible, compared
to traditional power plants.

As an aside, if your electric car requires 120 V / 15 A for one hour to
get 8 km of charge (these are the numbers for a Tesla Model S), you use
225 Wh of electricity per km at the wall socket. Given distribution,
that's about 240 Wh. Or, in the UK, 112.8 g/km of CO2. Which on a petrol
car is around 58 mpg.

But it's not that simple as that's only at the tailpipe and doesn't
account for refining and transport. A rough figure would be 6KWh used
per gallon of petrol in refining, for example, which is all coal based
in the UK

6 KWh per gallon of petrol
910 g/KWh for coal power
=> 5.46 kg/gallon of petrol

Assuming 58 miles per gallon of petrol (from above)
=> 94.1 g/mile CO2 emissions for refining petrol (consumed at @ 58 mpg)
=> 58.8 g/km CO2 emissions for refining petrol (consumed at @ 58 mpg)

This increases to 136.5 g/km at 25 mpg, on top of the 261 g/km the car
produces. Basically, add 52% to the tailpipe CO2 to compensate for the
refinery process. Plus a bit for the truck to take it to the petrol
station, and the ship to take it to the refinery, and the well to dig it
out of the ground.

So how many mpg does your petrol car actually have to do to match a
Telsa Model S for CO2, accounting for refining (but not transport)? 88

Tuesday, 11 February 2014

A quick word on fonts

I mentioned before that I might patch the font render to handle proportional as well as monospace. The eagle eyed will notice from the last post that I did. I also changed the font to something a little less CGA and a little more 21st century.

The font fix was easy - add a byte to the start of each glyph describing the actual width of the glyph. I then wrote a tool which worked out the maximum width of each glyph, to save a lot of tedious calculation. Fun arose when I found out the font I was using had glyphs centered in the box rather than left aligned like a sane person might do. Nothing some 16-bit left shifts couldn't fix though.

The font I'm using is Hallfetica Normal from

TFT up and running

Some success!

I'd been flailing around for a few days, trying to debug the more analog parts of my PCB. I was seeing a 5V rail at around 2V and my board reset when the backlight was connected, but fine without the backlight. This was all not helped by the fact I found I have at least two brand new micro USB cables that don't work (board lights up, CPU just resets - different cable, works perfectly).

So, I've removed the three MIC2005 high side switches and soldered some nice fat wire between the 3.3v input of the LCD and the 3.3v output of the Launchpad, and between the 5V input, Launchpad 5V pin and the backlight power pin.


If I can't get the load switches to work, it's possible I can get the LCD power consumption down to a manageable level electronically. If that's too high to remain on all the time, I'll probably need to build and off-board power control circuit. I have a spare output pin I can use to indicate "Do not power off" and with a few diodes and a small relay I'll have something that comes on with the ignition and turns off when the micro is happy to turn off.

Booting up! Apologies for the terrible brightness issues.

Saturday, 25 January 2014

DAB radio module

Leaving the dashboard for a moment and going back to the in-car entertainment, I've noticed that DAB modules are quite expensive. Much more expensive than desktop DAB radios in fact.

I was in Tesco today and saw a DAB alarm/clock/radio for £5. Five pounds. Well, that's got to be worth a poke - even if it lasts 10 minutes before I've blown it up it'll be good value.

Inside there are three boards. The smallest board takes 5V in and offers a headphone out via an 8-pin TSOP amplifier. The largest board runs the MMI and houses the screen and all of the buttons. That's connected via a 14-pin ribbon to the main event - a Gyro-1130E DAB module from GyroSignal Technology Co Ltd.

This FM/DAB module drives the single speaker directly, sends a 5 pin (differential) stereo audio to the headphone amplifier and carries a ton of plated through holes along each of, 14 of which go the MMI board as I mentioned before. The interesting bits are mostly hidden under a large can labelled 'Tunbow', but you can see an FC2507 (PDF) tri-band downmixer from Future Communications Integrated circuit Inc. I might try and lift the can at some point, but there's a whole lot of solder holding it down.

The "Tunbow" label on the can was odd, so I looked it up. It turns out, they make DAB radios and in fact make a radio in an identical case - the a Tunbow E80012. The only difference is in the picture, that has a segmented LCD, whereas mine has a dot matrix (which is actually as described in the specification, so perhaps the picture is just wrong).

Anyway, the audio quality isn't bad and I've seen references to a Gyro-1128 module receive praise in a full-size Audiolab 8200-T DAB receiver. This is quite promising. If I see another, I'll buy it so I can destructively lift the can and see what's underneath.

Monday, 20 January 2014

The dashboard is coming along...

So I can tie input waveform sampling to LCD updates, plus the menu system will reset the various trip values on demand.

What remains is storing the trip values on shutdown, handling day/night mode, tidying up the MMI and making the PCB.

Wednesday, 15 January 2014


I've elected to stay with 8-bit mode as I need the pins as GPIO. Text rendering works well provided you are careful to over print a region rather than blanking it first (which causes a flicker).

The fonts came from UTFT. I might patch them to add proportional support but monospace is fine for now. I've knocked up a basic menu system too.

Tired of all the wires the prototype, I ordered some PCBs from $50 for three, they should be here any day now.