Robot Wars 2003

Tuesday 19th August, 5:45PM

Greg: “We’re all sorted. I’m trying to sort out either a Ford pick-up or a Land Rover, but we’ve definitely got a vehicle of some sort.”

Jim: “Great, anything you can find with a decent boot size would be great. I’ll see you on Thursday night, then?”

Greg: “Friday night?”

Jim: “No, Thursday, we need to be in Nottingham on Friday.”

Greg: “Er…”

Cue frantic searching for Robot Wars’ phone number. I’ve got about ten minutes before they close and they’re travelling to the site tomorrow. Luckily, they’re in and are able to reschedule us for 9:30 on Saturday.

Friday 22nd August, 13:00

The weapon is only moving intermittently. With Greg arriving in a few hours, and no idea as to the cause of the problem I’m starting to feel very worried that is going to be a long day.

After a lot of inspection I find the BC108 transistors are getting hot, in fact too hot to touch. These are the first stage of a darlington driver and shouldn’t be handling any current to speak of. The base and collector legs of the transistors are connected via 10k resistors to other parts of the circuit. At 12V, these resistors could conduct a maximum of 1.2mA into each transistor, nowhere near enough to make them overheat.

After checking everything thoroughly the only thing I can think of is that the 12V linear regulator is generating lots of high frequency noise. I solder a capacitor across the output of the linear regulator to smooth it out, and the weapon works perfectly. However, whether I’ve actually fixed it, or that the transistors have just cooled off while I was modifying it remains to be seen. I’m confident enough that the interface will work for long enough to demonstrate the weapon during the tech check, though.

16:00>

Greg arrives with a small tank. Try to put the top armour on the robot which seems to have shrunk. After fifteen minutes of shoving, ratchet compression and hammering, all eight bolts go in. Ish. Set off for Nottingham. It's been three solid days of sawing, drilling and heavy lifting, so sitting in the passenger seat for an unhurried journey down the A6 is very relaxing.

Saturday 23rd August, 7:00

Eat uninspiring but functional breakfast at the hotel and delightedly discover that thieves haven’t broken into the landy and nicked the robot. I have nightmares of finding the robot on sale in the local second hand shop for 50 quid.

9:00 AM

We arrive at the hangar in RAF Newton. I feel somewhat glad that we’re not the only team whose manufacturing skills are not quite up to Razer’s.

Excuse the lack of pictures from here on - I was a bit busy

10:00

Cayene is sitting on the bench in bay 17. Briefly consider taking the top armour off to push one of the drive axle bearings back into place, but think better of it. Manage to push it back into place by sliding a plastic ruler between the wheels and armour.

10:30ish

Tech check performed; passes without any problems.

Time zero: called in

Alan Gribble checks the failsafe works OK. It does, but there’s something not right with the rear right speed controller. The zero area on the controller seems to have shrunk to nothing, so it’s hard to persuade it to stop moving completely, and it seems to be sticking in forward drive when it should be going in reverse.
The front right wheel is working correctly, so on some occasions we seem to have the wheels on the right hand side rotating in opposite directions; going nowhere fast.

T + 10 minutes

Push Cayenne into the loading bay. Realising that the link is on the wrong side, we have to rotate it to put the links in, but it won’t rotate back under its own power due to the same direction problem. Grab one of the spikes and rotate it to face the arena by hand. Drive out into the arena. Get called a tart by one of the tech crew for the message board.

T + 15 minutes

Up in the competitor booth, Cayenne decides to start playing and works perfectly. We drive over to the far corner of the arena and do a few test maneuvers, and spin on the spot a bit to turn the message board to face the judges. No problems. Here goes nothing.

T + 16 minutes

Horn sounds. Drive immediately over to the other side of the arena, so we have our backs to Disconstructor. They follow and we move backwars to ram them, miss them and we end up side by side, trying to turn around each other. We break off and move out halfway down the arena to get enough room to build up for another ram on Disconstructor. But something’s wrong; we’re not moving fast enough, and soon enough we were stopped completely. Frantically shake the controller and transmitter but we’re not going anywhere. Disconstructor move in for the kill and our message board is wiped out instantly (8mm polycarbonate). They circle around and take another swipe at the front of the robot, knocking the crusher jaws back into the frame of the robot, and smack a final hit on the right side of the robot. Cease is called.
The time from us being immobilised to being hit by Disconstructor was very small, so I think the damage they dealt out was fair.

T + 18 minutes

Kim Davies bulldozes Cayenne out of the arena. One of the judges (I think) asks us if we can repair it, which could have meant a discretionary place was on the cards. But from the look of things we’re not going to be running again this week.

A lot later…

Quickly surveying the damage, it doesn’t look like any of the internals have been badly damaged. Two of the rear spikes have been ripped off, the linear actuator’s clevis has been sheared off and one of the chassis beams has been bent, putting the right front axle out of alignment.

We didn’t notice for quite a while that one of Disconstructor’s teeth was still stuck in our armour (highlighted on the picture to the right). Disconstructor said the teeth were such a hard grade of steel that they couldn’t angle grind them, so I considered it quite an achievement that we’d managed to break one of them off. It took a lot of persuasion with a 4lb hammer to remove it.

We had been extremely lucky with the speed controllers. One of our interfaces, which are mounted inside the speed controller enclosure, had been hit and the interface microprocessor was cut clean in half. I’m used to getting segmentation faults in my programs, but not quite this severe. Another inch and they would have cut the speed controller in two. The interface comprises less than ten pounds worth of components, so we had a lucky escape there.

Reasons for the failure…

As far as I could tell both halves of the robot were working fine until we lost power. This means we probably had a ‘common mode failure’ - a fault in the design of each system rather than a random component failure. A gradual reduction in power would be what you’d expect from a flat battery, but all the batteries were still pretty much fully charged - we measured them at about 12.7 volts each after we’d got them home. The most likely culprit I can think of at the moment is the darlington driver circuit which holds the speed controllers’ ignition relays on. The circuit is identical to that used in the weapon interface, which we knew was overheating. On previous tests (when we’d been running for a good five minutes) we were running without the top armour on, so the ventilation would have been much better. This is just theory at the moment, we haven’t had time to retest everything.

Reflection (19th September 2007)

I never did find out what was wrong with that incarnation of Cayenne. Two of the speed controllers were found to be broken; the other two are still in Cayenne to this day and the broken ones were replaced with a RoboteQ controller. I could have done better given an extra day to tune up and debug, but that is always the case. No further series of Robot Wars were filmed, so I never got a chance to have another go. Still, I’m very glad I got to stand in the famous booth with a working robot, if only for a short while. It’s very tempting to give up the night before a fight, when nothing seems to be working and you’re covered in cuts and grazes from rapid, haphazard metalwork.

Disconstructor unfortunately drove into the pit in the first televised round. It was a good robot which could have gone a lot further with better luck, but it would have been nice to get knocked out by someone better recognised.

Cayenne was dismantled after the fight and rebuilt with a completely new chassis as Jalapeno. It went on to fight at Magna and held its own quite well in a one-on-one fight with Tornado at Preston.

LED Message board hacking

LED message boards look nice, and are much more eye-catching than a LCD or TFT screen. However, proper message boards are expensive - about £150 - so you’d need a good reason to justify buying one.

Maplin occasionally have ‘toy’ message boards on sale much cheaper - around £25. However, these can only hold a short message and this has to be programmed in via a small built-in keyboard. They are not quite so well built as the proper message boards, and have slightly smaller displays, but apart from that they only differ in terms of control electronics.

Under the hood

Maplin’s message board is called a ‘GM Light’. This produces no useful results in Google, other than lots of pages for GM Light Trucks and a pistol of some sort. However, pulling the device apart reveals some more interesting information. There are eight ICs on board. There are five of one sort, which can be easily identified by the part number printed on them. The relevant code is 74HC574, which identifies it as a latch. Two more are 74HC164, a shift register. The remaining chip is oddly packaged, looking like another piece of PCB with a resin blob in the middle where the chip presumably is. There are no markings on it, so presumably it is an ASIC, and its use will remain a mystery.

By tracing some of the tracks on the board, it’s possible to figure out how the board should work.

How it works

The board is divided horizontally into 4 blocks of 16 columns and one block of 8 columns. One of the latch chips drives each of these blocks. One latch chip drives a whole row in each block. The latch chips all share the same data bus, so the latch clock lines must be triggered individually to load different data into each latch.

The shift registers are joined together so that the highest bit output of one shift register is the data input for the second. This effectively daisy-chains both chips, enabling a bit pattern to propagate through them.

From this information I could figure out one way in which the board could work. This may not be the way the ASIC does it, but that doesn’t matter.

By loading a single pulse into the shift register at a time (i.e. 1 every 16 clock cycles), all the outputs of the shift registers will turn on sequentially. Each output from the shift registers is connected to a transistor which, when on, conducts the cathode of each LED to ground. Consequently, one column in each block is activated on each clock cycle. The inital pulse to the shift registers must be regenerated every sixteen cycles.

The latch chips control the rows, so data loaded into them will control the pattern of LEDs seen in the currently activated column. By loading new data into each latch for each new column, a pattern can be displayed. Note that there is no ‘output enable’ (or at least if there is, we didn’t use it) but the latches can be loaded so quickly that any glitch is invisible.

Rewiring

Obviously we can’t write to the latches or shift registers ourselves while the ASIC is trying to do the same, so the ASIC has to go. A more patient person might use a solder pump or wick to unsolder the ASIC from the motherboard, but I went for the brute force and ignorance approach. I jammed a knife under one end of the ASIC and ran a soldering iron down each side of the chip repeatedly until it came away (it’s effectively surface mounted). Unfortunately, some tracks on the board are routed through pads for the ASIC, and my approach ripped a few tracks up, so I had to patch the PCB back together again. The yellow wire on this photo is one of the patch wires.


Once the ASIC was gone, the remaining rather fiddly job was to attach wires to the appropriate chip pins - 7 to the latch data lines, one to each latch’s clock line, one to the first shift register’s data line, and one to the shift registers’ clock.

It’s then a relatively simple job to hook up all the lines to a PIC16F871. I put all the lines through a 1k resistor to avoid damage due to contention - although all the lines should be inputs to the message board PCB, there might be something else on there driving a line that I hadn’t noticed.

Programming

The next step was programming the PIC16F871 to drive the appropriate lines. The code to multiplex the display has to run quickly to maintain a reasonable image, so I allocated a ’screen buffer’ to hold the current pattern for the LEDs. With one byte for each of the five 16-column blocks, this is 80 bytes - a lot for a PIC16F871 which has very limited on-board RAM. This leaves only 16 bytes free in the main page. Actually, the display only uses 7 bits of each byte, and the last half of the fifth byte is invisible (off the edge of the display) but it makes the software much simpler to consider it as an 80*8 bit array. In fact, the eight columns which are invisible are useful - they can be used as an offscreen buffer to download the next character into.

Once the code to display a multiplexed pattern is done, the next stage is to make the pattern change. The two important jobs are to scroll the display (simple) and to insert new characters into the pattern (difficult). Scrolling just involves running through the buffer and copying each location to the location further down. This happens much more slowly than the multiplexing code.

To insert new characters, we need to know what the next character should be, and also what bitmap makes up this character. The font is held in the PIC16F871’s program memory. Program memory is much more plentiful on the 16F871 than RAM, but requires some memory-mapped IO in order to retrieve it. There is a slight time penalty, but this isn’t so important as a new character only needs to be fetched infrequently, with respect to the speed that multiplexing occurs.

Getting all the timing and character downloading right took a long time, but eventually I had a scrolling message on the display. This was the majority of the work for version 1.0.

Version 1.0

Version 1.0 of the message board had a message hard-coded into program memory. I loaded it with an insulting message, and attached the whole board to the back of my combat robot, Cayenne

Unfortunately, I don’t have any pictures of Cayenne with the message board attached. A couple of days later, I took Cayenne to the qualifying sessions for Robot Wars 7. There is never enough time to do what you want at a robot combat event, and taking photos is a fairly low priority. There are, however, several pictures of Cayenne with the bits of the message board that were swept out of the arena after the fight.

Version 1.1

Once my enthusiasm returned, I thought of another use for a message board.

Using several ‘talkers’ (chat rooms) on a laptop with a small display poses a problem - how to keep track of all the messages arriving from several sources at once, especially when you’re working on something that requires the full display. Sure, you can make each terminal beep when it receives a message, but you still don’t know which window it came from, or if it’s important enough to switch away from your main application.

So, why not get all the messages from your talkers displayed on a scrolling LED display? To do this, I added serial communication to the original display, so it would display any text sent to the serial port of a PC. The PIC16F871 has a serial port on board, but it only works on TTL voltage levels. Help comes in the shape of the wonderful MAX232 chip, which generates the +/- 12V required by RS232 from a 5V source.

Serial communications

Cunningly, I initially wired it up in TX-TX and RX-RX configuration. Luckily, I used my £10 laptop for testing and the MAX232 chip didn’t explode, so after a bit of debugging I swapped it for the more conventional TX-RX, RX-TX configuration and connected it to my server. Now, my server could talk to the message board.

I implemented a 16-byte rolling buffer on the 16F871 - the only memory available on the chip - and got it to send XON/XOFF bytes to stop the server sending too much data at once. There were a lot of problems with the buffer - mostly due to my own incompetency, assigning two variables to the same address, and not preserving variables in the serial recieve interrupt routine. Debugging was tricky as Microchip’s MPLAB can’t simulate the serial port. However, after a few irritating nights, the message board worked as planned.

From the talker to the display

In order to use talkers as normal, I use the unix tee command to split off output. For example,

telnet example.org 8080 | tee -a example.log

Then a separate process runs tail -n 0 -f example.log > /dev/ttyS0 - having set up ttyS0 for 300 baud communication with xon/xoff flow control. Why 300 baud? That’s the speed my robots’ radio control system runs at, and I copied the code directly from the receiver. 300 baud is still faster than the message board can cope with.

This displays everything coming through the talker on the message board. Of course, it would be better to filter this. I currently have a sed script to remove ANSI codes, and this could be expanded to check for interesting messages (new message posted, user login etc)