The Sinclair C5 as it Should Have Been

It began in 2013 when I went for an interview in Cambridge, UK and stopped over at a friends house to catch up. He’d gone and bought a working Sinclair C5 from a local collector for £250 and I had a ride around his road in it. Despite my head being at the same high as the wing mirrors of all the cars on his street it was hilarious, to be zipping along, that close to the ground, with such little effort. It was then I knew I wanted a silly electric vehicle to call my own!

One of the things that really struck me was how futuristic, and battered, but mainly futuristic it still looked despite being released in 1985. As my friend remarked, it looked “very future”. However that was only skin deep. The original motor had been the best in DC motor technology at the time but these days brushless motors are the ‘in’ thing. With their compact size and high power-to-weight ratios I knew I needed one in my silly electric vehicle.

I’d been wanting to build a go-kart for a number of years but finding the space and time to get started was difficult. I also lacked a welding setup to get the chassis made up. I decided that buying a Sinclair C5 was a nice way of getting a rolling chassis very quickly and I’d get a very cool looking vehicle I could upgrade.

My first bit of luck came when I found an eBay auction for 26 eBike batteries for spares or repairs. These broken batteries, a mix of 36V 10Ah, 12Ah and 16Ah packs, would be ideal for electric vehicles assuming enough working cells could be rescued. I won the auction for £125 and trekked over to the otherside of Milton Keynes to pick them up. Once I got them back to my local hackspace, Cambridge Makespace I started to test them and found that aside from 2 dead packs the rest only had damage to the enclosures, the batteries were fine and in some cases completely unused.

Now I had a power source I still needed the chassis. It took quite some time before a Sinclair C5 went up on eBay for a price I was willing to pay. As I was planning on replacing all of the electronics I was hoping I could get one for less than £150. Eventually, after a few failed bids I won an auction for a rather disheveled Sinclair C5 for £72. It was missing the lights, the storage boot and all the electronics but I figured it was just right! I ended up buying the boot a bit later on for £100 and the rear light for £20.

The first thing I replaced on the chassis was the front wheel. The original had standard bicycle caliper brakes and a plastic rim wheel. If you used the brake too much the plastic rim would melt and warp. The tyre would then blow out and you would have a very bad time™. So thanks again to eBay I bought an aftermarket modification that would give me a metal rim wheel and a disk brake.

It was now May 2016 and I wanted to get the C5 running in time for Electromagnetic Field, a hacker camp in the UK countryside held in early August. I already had a suitable motor, an Alien Power Systems 6374 170kv 3.2kW motor however this motor would be too fast.

Brushless motors are usually described with a ‘kv’ rating, this stands for Motor Constant which is the RPM per Volt. By powering my 170kv motor from my 10 cell battery packs I would get a nominal 6290 RPM. The original C5 had a reduction of 1:3.8 with 16” wheels which would theoretically get me up to 80 miles an hour. Except I just wouldn’t have the torque to get to that speed. So my urgent requirement was to build, and test, a mount for my motor that would fit the Sinclair C5 as well as reduce the motor speed by approximately half.

It took a few late nights but eventually I came up with a mad idea, the outside of the gearbox could fit into the original motor mount, and as long as the output shaft wasn’t central that would provide an easy way to tension the drive belt. The second mad idea was that the outside of the gearbox didn’t actually have to be metal, I could just make it from stacked laser-cut wooden sheet.

I found some 9mm laser plywood lying around the hackspace and I knocked up the design in Fusion 360. I integrated motor mounts, hall effect sensor mounts, holes for bearings, lightening holes which doubled as hand grips and securing holes. It held 2 steel gears together, one mounted to the motor shaft, one on an idler shaft. This gave me an 1:1.83 reduction ratio which would reduce the top speed to a slightly more achievable 43.3 miles per hour.

During EMF Camp this worked really well. I used the C5 off road every day of the camp and it handled it amazingly. Occasionally a few bolts needed re-tightening and the bearings required some bearing restraints stapling into the wood but that was it for maintenance. Once I got the C5 back to Cambridge it managed to get up to 27 miles per hour, 7 mph above the UK speed limit for electric bicycles. However the gearbox wasn’t sustainable. Even with the gear reduction I had to pedal start the C5 otherwise the drive belt would slip on the tiny drive pulley and make an outrageous farting noise. I started plans for a larger gear reduction, possibly even a planetary to handle most of the speed reduction so the belt would become more of a way of coupling drive power to the wheels.

But it was at this point Robot Wars was resurrected by the BBC and as something of a lifelong dream of mine I dropped everything to become a part of this. The Sinclair C5 project was on pause.

Eventually I managed to pull myself out of Robot Wars preparations. In the meantime I’d managed to buy a NEMA 23 5:1 gearbox with the intention of fitting it to the Sinclair C5 as the main speed reducer. I took it apart and built a model in Fusion 360 so I could accurately model brackets and adaptors. This was really helpful when I needed to make the first custom mount, something that would fix it to the 6374 brushless motor. Unfortunately I made a mistake and 2 of the 8 holes on the adaptor ring are drilled in the wrong places and just won’t line up with their counterparts, 6 bolts out of 8 is enough right?

This new gearbox promised great things, by having the main reduction done by gears before the drive belt there was a good chance I’d be able to do powered starts as well as quicker starts in general. But in order to realise this I needed a new motor mount bracket for the Sinclair C5. I spent a long time procrastinating over this; how should the belt be angled, what if I wanted to add a neat design feature etc.

It wasn’t until Tindie/Hackaday announced a meetup in Cambridge that I finally decided to get on with it. I wanted to show the Sinclair C5 off, so I just had to make the bracket as is. I did some work on it the week before the meetup but it was only until the actual week of the meetup arrived that I really buckled down. I worked pretty determinedly, eventually taking the day of the meetup off work so I could really get it working in plenty of time. Everything went pretty well, I had to restrain my desire to make it completely neat and polished simply to get it working. Occasionally I had to abandon my theoretical plan and just bodge a few things, but luckily this was kept to a minimum. However come 4pm of the day of the meetup it was done!

I hopped in, zoomed out of Makespace, and drove across Cambridge, UK attracting quite a few stares and made it to the meetup! The power from the motor cut out a few times on the way there, at the time I felt that the motor had just overheated and needed a bit of a rest. Of course this wasn’t the whole story but I wouldn’t realise this until later...

It turned out that I’d got to the meetup a couple of hours too early, oh well, I’m in a pub, waiting for a meetup, time for a pint! After an excellent meetup hosted by Jenny List and Jasmine Beckett of HackADay and Tindie respectively where I met lots of equally mad people it was time to head home. The motor wouldn’t work the whole way home and so I had to arduously pedal the C5 back to Makespace. Pedaling the C5 is not like pedaling a normal bike, it sucks, really really sucks.

Finally I made it back to Makespace and it was time to inspect the chassis and see why it’d stopped working.

Oh, that’d do it...

I'd knacked the chassis, bent it like a banana, the cheap, weak Sinclair C5 chassis. It turns out a motor with 14 times more power that the chassis was designed for is a little brutal. I’d also mashed the rear axle bearing in addition to the chassis which explains why the rear axel had completely locked up.

Everything looked recoverable but I’d have to buy a new bearing and while I could bend the chassis back into the correct shape I’d actually popped 2 of the spot welds so it would just bend out of alignment again.

My list of things next to upgrade now included:

• Replace the busted rear axle bearing
• Add a brace for the rear axle and chassis
• Improve the rear drum brake, possibly swap it for a disk brake
• Add a display to report on things like battery capacity and motor temperature

As can be seen I only seem to get any productive work done on the Sinclair C5 when I have a deadline so I will be aiming to enter Hacky Racers at EMF Camp 2018.

Acknowledgements

Thanks to Makespace for the facilities and storage
Brian Corteil for the transport, advice and mocking
Mark Mellors for advice and mocking as well
Alec Wright for the idea

Bourbon at the UWE Beetle Brawl Feb 2018

The University of West England held a Beetle Brawl on the 10th Feburary 2018. I managed to secure a place for 'Bourbon' and competed. This was to be the first time I'd get to use my newly designed wubber drum. A drum spinner with the motor driving the drum via a rubber wub to isolate the motor from impacts and shocks.

The Heats

Bourbon's first fight was against 'Puns & Roses' a robot I'd helped to build. As 'Puns' was a wedge bot it was my drum bot's natural enemy. We were both quite evenly matched in our drive power so couldn't out push each other. Eventually I managed to attack from behind and get some bite into the HDPE chassis of 'Puns' resulting in them being flipped out of the arena into the trench.

The second fight in my heat was against a student bot 'Critical Failure'. This bot had two spinning blades but they were too high up to actually hit 'Bourbon' so did no damage. Due to the thin mild steel chassis and vertical sides I was able to quickly get a good bite and throw it around. It went out as I managed to beach it on its back immobilising it.



After winning both my fights I was though to the 2nd Round

The 2nd Round

The first fight was against another student bot, 'Crabsolutely Clawful' which was my favorite bot in the competition. Even if I won I'd be knocking an awesome bot out! It was a HDPE chassis with 3D printed claw arms, I managed to throw it around and eventually broke one of the claw linkages when the driver tapped out. Luckily I hadn't caused any damage he couldn't repair so everything was okay!



The second fight was against 'Dr. Bees'. I knew this fight was going to be nasty as 'Dr. Bees' was a powerful horizontal spinner with a large Hardox bar. At the time I figured that by aggressively attacking with my new wubber drum I'd cause more damage to him than myself. This was partially correct, I managed to stop his spinning bar and stop one of his drive motors at the cost of flipping 'Bourbon' over, jamming the drum and dislodging one of 'Bourbon's Hardox teeth. I won due to immobilisation as I was able to still "move" (more like crab) around the arena.



However this is the fight that caused the biggest problems. I needed to strip 'Bourbon' down and see why the drum stopped, fix it and put it back together. But due to the event running rather late I was pressured in to quickly throwing my spare, old style drum, onto 'Bourbon' not checking if it worked before going back into the arena.

The Finals

I was up against 'Incomplete Control' a ridiculously good 4WD pusher. Honestly I wasn't expecting to win this fight. The driver was better than me, 'Incomplete Control' can out push 'Bourbon' and I was rushing due to almost no fixing time. When the match started I attempted to spin the drum up but due to my rush I had tighten the bulkheads too tight and the drum was unable to spin. The hope was I'd be able to flip 'Incomplete Control' away enough times to give me a fighting chance, instead I was quickly pushed in to the pit for a very unsatisfying end.



However all was not lost, I then fell though to a losers melee where I could redeem myself and fight off two other bots for a return to the running for 3rd/4th place. I went downstairs for a chance to look over my robot and try and get the drum running before I was immediately called back to the arena. Luckily I was able to get the drum working and actually had a weapon for this match.

I managed to get some really good hits in before getting flipped by a poorly considered attack on 'Swag Daemon'. The drum had dislodged on the last hit and kept me propped up such that I was unable to move. The remaining bot in the melee 'Mr Cat’s Mouse House' took the victory as the remaining moving robot.

Conclusion

'Bourbon' is a very nasty little drum spinner that can both deal out massive hits as well as take them. However its biggest weakness is being flipped upside down which means it has poor manoeuvrability. I didn't have any major drive problems and the wubber drum worked superbly. In fact once the competition was finished I was able to inspect the drum properly and found that it was still operation but the idler bearing had dislodged which had jammed the drum.

In the end I came in 6th place out of 36 robots so I am very pleased with that result as I felt I ought to get into the top 10, and had a good chance at the top 3. On the other hand I am very frustrated that I was given insufficient time to properly inspect and repair 'Bourbon' after 'Dr. Bees' and so ended up fighting a match without a weapon.

Some Musings on Member's Storage

A friend of my mine posted a tweet about member storage in hackspaces/makerspaces and I've written some thoughts about it:

I'm a member of Cambridge Makespace (where I live) and London Hackspace (where I used to live). Both spaces are fairly mature and have a reasonable number of members for their available space. At a Makespace new member induction each new member is told that they may have a Really Useful 35 litre box to store items in (less solvents/flammables). This works really well as they are cheap (~£13), robust and store quite a lot of stuff. We have shelving units in our corridors which take ~15 of these boxes so storing the 200-odd boxes doesn't take up too much room.

However we now have enough members that problems with the system are beginning to show. These seem to be: claiming of permanent workstations, excessive personal storage and large item storage. The first two problems largely seem to be solved with tellings off, we've not progressed to formal disciplinary actions yet. We're currently working on using some unused underfloor 'rooms' as large project storage. You get given a trolley and your project lives on the trolley and is kept in the storage area. This plan is pretty new and I'm sure we'll be finalising the process to include things like project end dates and such.

London Hackspace is quite a bit larger and older than Cambridge Makespace so I've been keeping an eye on their storage processes. They too have members boxes, as well as tightly regimented procedure for storing large items. I like their form for requesting item storage with fields to fill out including contact details, description and end dates however the amount of noise it generates in their Google Group and the lack of a specific place for items to go concerns me. I imagine Makespace will probably 'borrow' the idea of the form and label generation/printing for our system.

One thing I've found invaluable in keeping Makespace usable is the room we call the 'Trove' which is where donated bits and the junk left on tables or over from projects gets stored. It gives a place for items that slot into the 'crap but could be useful, to someone' category can be dumped without cluttering the main work areas. Whenever we run a 'Tidy the Space' event (2-4 times a year) this room gets a clean out. Of course a few people see the room full of junk and think we should get rid of the room and it's contents. Great in theory but then where will the junk end up? Scattered all over the space making it cramped and unusable. By giving it a space it can get thrown in there until it gets sorted.

Claymore's Chassis

It's been a long time since I last updated this blog. In that time the designs for Claymore have changed quite a bit. I've settled on a sensor layout as well as discarding the whole idea of a lasercut chassis. The biggest driver in the decision to discard the laser cut chassis was me finally accepting that the Faulhaber motor gearboxes were unworkable in their current state. They were in a prime position to be the main mounting point but due to their thin all-plastic design there was no way to mount to them satisfactorily.

Chassis

Since becoming a member of Cambridge Makespace one of the more amazing tools I've had access to is the Metal Mill. This tool cuts through aluminium and steel like a dream and is the main driver behind my decision to build the chassis out of milled aluminium. As the electronics is designed to fit inside the chassis this then requires a redesign of the electronics too.

Motor Mounts

The first thing I re-designed was the motor mounts, the dimension are largely copied from the plastic originals however I added more thickness to the base to allow me to drill and tap these for mounting. Unlike the laser cut chassis the motors mount to the base of the chassis rather than the top. This allows the electronics to drop in from the top and the battery to be held in with gravity.

Rather than to screw directly into the aluminium which is quite soft and will strip after a few remove/replace cycles I used Helicoils. These spring-like stainless steel inserts screw into an over size tapped hole and have an internal thread which is the sized to fit your bolts, in my case M3. This allows me to remove/replace parts repeatedly with no loss of strength.

Base Plate

The base of the chassis is made out of 1.6mm thick aluminium sheet that is cut and bent into an "L" shape. This reduces the need for an awkward mounting system in the rear of the chassis where the motors will mount and also stiffens the chassis a bit. To mount the sides to the chassis base I made up some small aluminium blocks that had 5 helicoiled threaded holes. These mount to the chassis with 2 bolts, to the sides with 2 bolts and attach to the PCB with 1 nylon standoff.

Chassis Front

The front of the chassis is one large aluminium block to ensure that the front of the robot is kept down during high acceleration as well as to provide a ridgid mounting point for the sensors. Before I re-designed this block I bought some of the sensors I will use (Sharp GP2Y0D340K, Datasheet) and measured their range and detection pattern. I found that by spacing 3 sensors ~15° apart I could cover a 90° arc in front of the robot out to ~300mm.

Skid and Sensors

To keep the front of the robot from damaging the dohyo surface I machined a skid out of an engineering plastic called Delrin. This plastic is tough yet slippy so should be ideal for this. To detect the edge of the dohyo I added 2 edge sensors right on the front most edges of my robot. These should detect the transition from the black of the main dohyo surface to the white of the 25mm thick edge strip.

Ascetics

As plain aluminium is very shiny which will reflect infra-red light very well I will need to darken the exposed aluminium surfaces. Ideally I'd anodize the aluminium however I don't think I'll get a great finish and it would be tricky to do myself. Instead I'm planning to use a matt black vinyl wrap to cover the aluminium surfaces. This should be a simple process but should give a good finish.

As the electronics will be mounted on top of the motors & aluminium blocks I need a top cover to protect them. I've decided that I will laser cut a 3mm translucent acrylic top with holes for buttons. This should looks good and provide enough protections from falls to the electronics.

Electronics

The main change has been the PCB shape, in order to fit the battery the PCB is now a "U" shape with angled cut outs for the sensors. Unfortunately as this is a small PCB with lots of components and some very narrow places I'm still trying to route tracks.

Power Handing

One key aspect of the chassis redesign was the dimensions of the battery. The battery is a key component of the mini-sumo as without it nothing will run. I've now decided to use Venom 10C 3 cell LiPoly batteries and have bought 2 to allow one to charge while one is being used. They're quite popular so there should be a ready supply of spares if required. They weigh 45grams and their dimensions are 68mm x 26mm x 18mm. It is important to note that a fully charged 3 cell LiPoly battery will have a pack voltage of 12.6V.

As the motors will be separated by the battery it will be hard to route a single motor controller chip like the TB6612FNG to both motors. Thus I have chosen to use  separate motor drivers, however I also need the motor driver chips to be compact as I do not have much space on the PCB. The motor chips I have chosen are Texas Instruments DRV8838 however these motor driver chips cannot handle power supplies of greater than 11 Volts. To protect the DRV8838s I've placed a large diode in series with the battery that has a Vfwd of 1.6 Volts which should drop the voltage satisfactorily.

Another problem is that while the motors will be running at 11 Volts, the GP2Y0D340K sensors require 5 Volts to work, and the rest of the logic requires 3.3 Volts to work. I decided to solve this by using a switch mode power supply to convert the battery Voltage down to a stable 5 Volts for the range sensors and then I am using a linear regulator to convert from 5 Volts down to 3.3 Volts. This minimises the board space required while maintaining a high efficiency. This should cost too much nor generate too much heat.

Sensors

The GP2Y0D340K range sensors will plug into turned pin sockets mounted directly to PCB at the right 15° angles. This allows me to change sensors if they get damaged but also provides a secure method of fastening them to the chassis via the PCB.

The QRE1113 floor sensors will be mounted in Sparkfun breakout boards which bolt to the front block as seen in the picture above. They will have wire pigtails that connect to the PCB via tiny 3way JST SH connectors. I've still not quite decided where on the PCB these will mount but they don't take up much room at all.

Interfacing

As this is an autonomous combat robot I will need to change the code regularly to alter and improve tactics. The best way to do this is by including an ARM mbed compatible chip that can be programmed via a built in USB bootloader. The NXP LPC1347 ARM Cortex-M3 microcontroller fits these requirements perfectly. To avoid cutting holes in the chassis the USB connector is placed pointing forwards between 2 of the range sensors. The buttons to reset and put the chip into bootloader mode will peek out through laser cut holes in the acrylic top cover.


To provide detailed status information I've added a monochrome 128px x 32px I²C OLED screen to the PCB. This currently shows battery and build information on boot up and then motor and sensor status during the match.

The Unnamed Electronic Systems

While I'm working on mechanical structure of The Unnamed I also need to consider how I will control the final robot. The rules state that there need to be 2 elements before my robot is allowed to enter:

• Removable link
• Powered indicator

Of course the robot will need other items to operate such as:

• Battery
• Motor Drivers
• Radio Control Receiver

Removable Link

The idea behind requiring a removable link is simple, it provides a guaranteed way of cutting of the power in case of emergency. It must be located in an accessible place and may only be covered by a clearly marked, and easily moved cover. In many robots the removable link also does double duty as the master power switch.

They are commonly made out of a high power collector that has the male plug pins shorted together and the female receptacle pins in line with the battery power leads. The female connector is used in line with the main power wiring to reduce the chances of a short circuit activating the robot unexpectedly.

Powered Indicator

The powered indicator must be a steady indicator that is lit when the robot is powered, it cannot be a filament bulb. This gives a clear indication if the robot is powered.

As it cannot be a filament bulb LEDs are often used. It will need to be connected into the removable link side of the robot so that it will only light if the link is in place and the robot is active.

Motor Drivers

I'm planning to have 3 motors in my robot, 2 for drive and 1 for the weapon, in all 3 cases I will need to control the motors in both directions. As the motors I shall be using are powerful I will need motor drivers that can withstand high voltages and currents continuously as well as far higher peak currents. Of course despite these requirements they need to be compact but affordable as I don't want to spend all my money on awesome motor controller only to not have enough money for a weapon, or worse, no money for a chassis. One other important feature is reliability, often many robots lose a bout simply because their motor controller suffered a fault, burnt out or became disconnected, I do not want that to be the case for my robot.

For the moment I'm planning to use modified TZ-85A brushless speed controllers.

Movement

I will be using two Gimson GR02 18 Volt 1:24 motors to drive two wheels each via a High Torque Drive (HTD) belt. The motors will pull approximately 8 Amps under load but will pull up to 62 Amps when stalled which means I will ideally want a motor controller that can take 10 Amps continuously and withstand short spikes of up to 65 Amps.

As I shall be using differential steering to control my robot I will need some way of mixing a remote control channel with left and right signals with a remote control channel with forward and backwards signals. This can be done either with a suitably intelligent dual channel motor controller or by using a V-Tail mixer to combine the signals.

Weapon

My current plans for a weapon call for an electrically powered actuator as part of a four-bar-lifter. I'm expecting the actuator to be a Gimson GLA-S 100mm linear actuator. Gimson state that the expected stall current is 62 Amps and the expected load current is 23 Amps, this means ideally I want a motor controller than can survive 62 Amps peak but I'll definitely want to be able to manage 30 Amps continuously. This actuator should reach full extension (205mm to 305mm) in approximately 5 seconds under load which could be too slow however this will require further work before I am certain.

Linear actuators do not spin continuously and will reach a limit where they cannot travel any further without damaging the motor or the actuator, to signal when the actuator has hit these points limit switches are installed. While limit switches are built into the SLA-S actuator they are not connected to the motor directly as they would not be able to handle the current, this requires me to add a circuit to detect inputs from these switches and control the motor accordingly.

Battery

To power the motors in the robot a battery is needed, its characteristics such as voltage and capacity are defined by what I need it to power. The Unnamed has:

Qty	Description	Load Current (Amps)	Sub-Total (Amps)	Stall Current (Amps)	Sub-Total (Amps)
2	Gimson GR02	8	16	62	124
1	Gimson GLA-S	23	23	62	62
1	Misc Electronics	0.2	0.2	0.2	0.2
Totals:			39.2		186.2

Assuming a bout lasts 10 minutes then I will need a battery capacity of 6.6 Amp hours (Ah) if all the motors are constantly operating, the absolute worst case suggests I'd need a 31 Ah battery if the motors were continuously stalled. Neither of these estimates are particularly realistic as I will not be driving at top speed for all of a bout, and nor will the lifter be constantly extending and retracting.

The 6.6 Ah figures is closer to being realistic so I will aim to have a battery that is close to this. Another consideration is the voltage of the battery, the GR02s and the GLA-S are both rated at 18 Volts however I'm planning to overvolt them by using a 5 cell Li-Poly battery at 18.5 Volt nominal.

Radio Control Receiver

To control the robot I am planning to use a DSM2 compatible transmitter and receiver set, DSM2 is a 2.4GHz standard that allows different receivers and transmitter from different manufacturers to work together. My robot will require a minimum of 3 channels, one for each drive motor and one for the weapon. I could use a further 4th channel to enable inverted control for when my robot is flipped over or to enable other functions remotely.

My Solution

With these considerations in mind I came up with the following circuit:

I've chosen a 5 cell 4.7 AmpHour 30C Lithium Polymer battery from OptiPower, this should provide enough power for long enough to last a bout. It will be capable of sourcing 141 Amps (30C × 4.7AHr) continuously with peaks of 376 Amps (80C × 4.7AHr).

To protect the motor drivers and RC electronics I've put a 100 Amp automotive Maxi Fuse. As it is a cartridge fuse it's easy to replace if it gets blown but is also robust enough to act as a removable link. By choosing an automotive fuse cartridge it should be easy to buy spares and even replacement fuses with smaller ratings.

I'm going to use a high power red LED to indicate that the robot is powered, this will be connected after the fuse such that if the fuse blows the LED will not light.

The terminal block is ideal for the central connection node of my electronics system. The screw clamps will allow me to easily make and remove connections whilst securely grabbing any cable and holding it tight. It should also allow me to keep the wiring neat and tidy which will help me in maintaining the robot.

I've omitted the connectors from this diagram to keep it simple, however I'm planning to use XT60 connectors like the ones above left to join the motors to the speed controllers. The battery will connect to the wire link with an XT90 connector, show above right, which is a the bigger brother of the XT60. By containerising these key parts of the system it enables me to quickly re-configure the robot for maintenance or debugging. They're polarised so I cannot plug things in backwards as well as gendered so I can ensure that the parts of the system that supply power have female plugs to reduce the chances of shorts.

Rules of Thumb for Designing 4-bar Lifters

The main weapon for The Unnamed is a 4-bar lifter. It takes its name from the Four-bar Linkage used to move the lifting arm

One of the most famous 4-bar lifter robots is the American Biohazard, it coupled a very low robot with the ability to lift the opponent very high. Below is a video of it defeating Greenspan in May 2002.

As I'm trying to emulate the weapon of Biohazard for The Unnamed I need design my own 4-bar lifter.

Design

While it is called a 4-bar linkage one of the bars is actually the robots chassis so this is fixed from a design point of view. The other 3 bars however are very much up to the designer, and because of this the number of variables it is very hard to work out the "best" design.

I began my design with a number of aims:

• It needs to fit into an area roughly 300mm by 50mm to stay inside the robot
• It needs to be reasonably fast, ~2 seconds to complete a lift

To do this I used SketchUp to position the bars which allowed me to easily get the lengths and angles. These lengths and angles where then inputted into "Four Bar", a 4-bar lifter calculated written by Adam Wrigley and available from here.

Note: This software is old and will need an older version of dotNet in order to install.

Rules of Thumb

After playing around with it a lot I've decided on these rules of thumb, I'm not a mechanical engineer so there is no theoretical justification, just what's happened when I've altered it.

• The rear bar controls how far forwards or backwards the lifter throws
• if it's at a 45° angle then you will have a vertical lift with little forward or backwards throw
• if it's less than a 45° angle then the lifter blade will move forward during the lift
• if it's more than a 45° angle then the lifter blade will move backwards during the lift
• The forward bar controls the height the lifter reaches at the end of a throw
• the longer the forward bar is, the higher the lifter will be able to reach
• the shorter the forward bar is, the less height the lifter will be able to reach

 After spending quite some time playing around with the lengths and angles I finally came up with a design that produced a result I was happy with.

 Note: The calculator uses the units that you enter, in my case millimetres and kilograms.

The drawing on the left shows the lowered position in red and the raised position in blue. The tip of the lifter is traced through the entire range with the pink line. As you can see the lifter raises 22.5 centimetres and also moves forwards by 5.0 centimetres, this the advantage of using a 4-bar linkage compared to a simpler flipper.

The graph on the right shows that the front arm is originally 12° from horizontal and rotates until it is 58° from the horizontal. The height increases linearly with rotation which should help the control of the lifter. The torque curve is constant around 39 Newton Meters for the majority of the lifter's movement however for the last 7 centimetres the torque rises very sharply to 129 Newton Meters. The torque figures are calculated assuming a 15 kg weight (opponent) on the tip of the lifter however increases to this mass (multiple opponents, the arena wall) will cause the torque requirements to increase.

Powering the Lifter

Of course just having a mechanical design for the lifter bars is great, most of the work in fact, however I still need a way to power the lifter. Using the calculator above I need to provide more than 150 Newton metres of torque to the front arm of the lifter. Looking back to Biohazard it uses 2 electronic linear actuators to push against the front arms.

Pneumatics

One of the main advantages of lifters is that they are very similar to a flipper but without the high impulse power that can be provided by pneumatics. It would be possible to drive the 4-bar lifter with a pneumatic ram however I don't feel like I have enough knowledge and understanding of pneumatic systems to do this safely and will save this for a future robot.

Motors

An alternative to linear actuators is to have a very high torque motor to drive one of the linkages directly. This was the approach taken by Charles Guan with his Test Bot 4.5 MCE. This would be more difficult for me to implement as I do not have lots of space and I need to source or design a suitable gear box. I will probably avoid this approach.

Linear Actuators

These are a popular method of driving lifters, although they're much rarer in HeavyWeight robots, Biohazard was an exception rather than a rule. A recent featherweight combat robot that made use of a lifter powered by linear actuators was Loki who did quite well for themselves in the 2014 Featherweight Championships.

Looking on Gimson Robotics they have the GLA750-S which seems like exactly what I need. It is capable of 2300 Newtons of force, 50 millimetres of throw, and a top speed of 37 millimetres per second. However I will need more than just a motor controller to drive this as I need it to stop at the lower and upper end points else it will lock itself together.

Control

The GLA750-S uses the same motor (RS 550) as the GR02 gear motors, therefore it makes a bit of sense to use the same motor controller, the TZ-85A. However I need to add some way of stopping the linear actuator when it has reached the minimum and maximum lengths. Typically actuator have end stop switches built in which are connected as shown below in the image from Gimson Robotics:

However for the GLA750-S the motor current is too high and will cause the switches to fail, even under no load conditions. This means I'd have to construct my own limit switches, most likely due to the currents the limit switches would then operate relays or MOSFETs to limit the motor.

Another option is to further modify the TZ-85A but not re-programming with the stock brushed DC motor control firmware. Instead further modifying the firmware to accept an analogue input and connecting a variable resistor or potentiometer to it. The potentiometer would vary in relation to the position of the linear actuator and would be in effect be a super sized servo. The advantage of this is that the RC pulses no longer specify a speed but a position which the linear actuator will always try and match. This way should external forces move the actuator out of position, it would apply more power (if available) until it matched the requested position again. This would require understanding the current modified firmware as well as extensive testing. Any mistakes could cause the linear actuator to irreparably damage itself.

That would be bad.

Mini-Sumo Claymore

Whilst visiting the Birmingham TechFest in 2011 with a few classmates from university I saw people with small autonomous robots, the robots were attempting to push each other out of a black circle. It turned out that this was a mini-sumo competition. The robots had to be autonomous, weight less than 500 grams and must fit in a 100mm cube. This sounded like an interesting challenge so I have tried to make my own.

Rules

The official rules are listed here in PDF however the important points are:

• Matches take place in a Dohyo
• This is a circular arena with a diameter of 77 centimetres painted black
• It has a white line on the border 2.5 centimetres wide
• There is nothing else surrounding the Dohyo for at least 50 centimetres
• The robot must:
• Fit in a box 10 centimetres wide and 10 centimetres deep, there is no height restriction
• It must not weight more than 500 grams
• Autonomous robots must begin a match 5 seconds after a button is pressed
• No jammers or damaging weapons allowed
• But a flipper is not ruled out...

Objectives

Like The Unnamed I've set down some initial starting goals:

• It must weight 500 grams
• Fit inside the 100 mm cube
• Try and be less than 30mm high
• I want to focus on intelligence rather than brute force
• But it helps to have brute force too
• Use 2 opponent sensors and 2 edge sensors
• Use 'modern' construction methods
• This includes 3D printers and laser cutters

Parts

I started by collecting some parts for the robot. Normally I try and fully design a robot before ordering parts, this stops me from wasting money on things that won't fit with the final design, however more often than now I find myself never quite finishing it. This time I decided that as the robot will be rather small I may as well buy parts that look like they'll fit and then design a chassis around them.

Drive System

I figured the first step would be to organise a decent drive system after all the point of this robot is to push other robots out of the ring, it needs to be a solid system as it is my only offensive weapon. I started by trying to find motors from Faulhaber or Maxxon, both very high quality, very high cost precision motors. Googling for Faulhaber lead me to a Robot Room post which then lead me to a surplus website selling them here. A couple of important things to note about these motors which made them ideal; they have pre-built right angle gearboxes already attached, they have encoders mounted on the rear to count rotations and while they're rated for 6 Volts they seem capable of handling ~12 Volts.

I'm planning to run the motors in a closed loop control system, this means that rather than setting a PWM value as is the standard I will instead set a counts per interval then the code will attempt to match that value by varying the speed of the motor. This means that should something slow me down, either battery levels draining or an opponent in front of me the controller will increase the PWM value until the counts per interval matches. The only downside to this method is that it is more complex and requires a decently powerful microcontroller, however I was planning to add one anyway so this is acceptable.

The motors at 6 Volts only rotate 80 times a minute or 1.3 times a second which is not very quick at all, if I instead run these motors at 12 Volts then I should get 170 Rotations per Minute (RPM) or 2.8 times a second. This is much better and coupled with the right wheels will make for a fast robot. To provide this 12 Volts I need a powerful but compact battery, I'm not too concerned about weight, but the smaller I can make my robot the harder it will be to sense. With that in mind I've chosen a Lithium Polymer (LiPoly) battery made up of 3 cells for a battery voltage of +11.1 Volts and a capacity of 800 milliamp hours, it measures 75mm x 23mm x 15mm and weights under 63 grams.

The final component of the drive system are the wheels. I want a robot that is around 30mm high so cannot choose wheels larger than that, they also need to maintain good grip on the floor to help push other robots around. I ended up buying a pair of Solarbotics RW2 wheels. These have a diameter of 31.2mm which translates to a top speed of 277 mm per second which would be fast enough for this purpose.

Sensors

The robot will require 2 types of sensors, one set to detect opponents and manoeuvre them off the edge of the Dohyo and another set to detect the edge of the Dohyo and avoid it.

The distance sensors should have a long range, but to avoid detecting things outside the Dohyo the maximum range must be limited to 50 centimetres + 2.5 centimetres = 52.5 centimetres but should be more than 77 centimetres  - 10 centimetres - 10 centimetres = 57 centimetres to ensure that the opponent can be sensed at all ranges. The minimum range should be as close to 0 centimetres as possible to avoid missing the opponent when it is directly in front. The (IR) distance sensors from Sharp are very popular as they fit nicely into this range bracket. I've chosen the GP2Y0D340K as it has a minimum range of 1.5 centimetres and a maximum range of 40-42.5 centimetres. The maximum range should be acceptable as the robot will be moving around as it scans for the opponent which will reduce the chances of the worst case scenario happening.

The edge detection sensors don't need quite so much range but they need to detect the change from the black Dohyo floor to the white edge border cleanly. The edge sensors I choose will need to sense the change quickly, if the robot is travelling at its top speed of 277 millimetres per second then the robot has 1.1 seconds to come to a halt to avoid driving off the edge. The popular sensors for this task are the TCRT1000 from Vishay. The TCRT1000 combines an Infra-Red (IR) transmitter receiver pair in a single package, correctly biased they be set up to give a digital output that ranges when the border is detected, this can then set off an interrupt to stop the robot.

Logic

To control the robot I will need some logic to receive inputs, process them and then act upon them, as I want the strength of my robot to be the processor this is where I need to choose a fast and powerful microcontroller. I will use the faster microcontroller to get inside my opponents Observe, Orientate, Decide, Act loop (OODA), this is done by cycling through the loop faster than the opponent, causing the opponent to act upon a situation that has already changed.

For fast powerful microcontrollers that are still compact the ARM architecture is the most prevalent and of these I have the most experience with the LPC1343. This will be a good choice as it has enough input/output pins for the robot and runs at 72 Megahertz which will allow it to react quickly to changes in its environment. Unfortunately it does not have any non-volatile memory so I may have to include an external EEPROM chip to provide the memory that will exist between power cycles.

The motors will require a specialised chip to drive them as the microcontroller outputs will not be sufficient. This chip will need to work with a +11.1 Volt supply from the battery for the motors and accept control signals  that are +3.3 Volts. The motors will pull approximately 0.4 Amps when stalled so the chip ideally needs to be able to handle approximately 1 Amp of current to be safe. There are a few available chips such as the TB6612FNG or the A4950 I will choose a suitable one as the space constraints are discovered.

The LPC1343 requires a +3.3 Volt power supply, the sensors require a +5 Volt power supply, I have a +11.1 Volts battery on my robot, this means I will need to include 2 stages of regulation, one to +5V and another to +3V3. The best way to drop the +11.1 Volts down to +5 Volts is to use a Switch Mode Power Supply (SMPS), these are typically very efficient and generate very little heat. I will then use a linear regulator to drop from +5 Volts down to +3.3 Volts this will give me a very stable, noise free supply for the sensitive microcontroller.

Chassis

These disparate parts require a chassis to act as glue holding them together. As none of the robots opponents will be able to cause physical damage there is no need to armour my robot however the chassis will need to be stiff enough to withstand pushing and being pushed by other robots. By making at low as possible I reduce the cross sectional area that an opponent can detect, depending on my opponents sensors I can also construct my robot to further reduce my chances of being detected. For robots that use sonar sensors I can either deflect the ultrasound or absorb it to reduce the returned ultrasound levels, for IR sensors I can do the same but with different materials. I however will not construct my robot to take advantage of this in the first mini-sumo, however for my next robot I may look into "stealth" techniques.

The minimum height I can build my robot is set by my wheels, 31.2mm, the minimum width of my robot is set by the width of 2 wheels, 2 motors and the battery, 87mm, the minimum length of my robot is set by the length of the motors, 72mm. The total weight of those 5 components is ~200 grams. This means I have approximately 300 grams to fit the logic circuitry, sensors and chassis in. To accurately plan how I would do this I used SketchUp as a Computer Aided Design (CAD) program, it's not as functional as Solidworks or AutoCAD but it is far easier to use.

After many design ideas and tweaks I came up with an idea:

It was to be built out of laser cut 6mm plastic, ideally Delrin, Acetal, or Polycarbonate (preferably not acrylic) using Pettis joints to hold it together with hex cap screw and square nuts. These joins have proven them selves to be very rigid and very easy to cut out with a laser cutter.

The motors, not having any mounting attachments, would be zip-tied in custom 3D printed motor clips which had nut traps so they could be bolted onto the top plate of the chassis. This would form a monocoque structure which would be easy to fabricate, construct and dismantle for repairs/upgrades.

To aid in the pushing of opponents a metal plate was added, this had a lip on the front that would protrude out and down. The idea being that as an opponent was found, engaged and pushed the lip would get underneath the opponent and raise their wheels reducing the contact with the ground degrading the grip.

Testing

Once version 1 of the chassis was laser cut and the parts installed the first problem was noted, the chassis was in fact cut out of 5mm acrylic, the design was for 6mm plastic. This difference was enough to completely ruin the strength of the structure however it was acceptable enough for testing. Another initial problem was that I was already using my LPC1343 development board in another project and could not remove it however I had recently bought a Teensy 3 from the Kickstarter. To control the motors I use a TB6612FNG breakout board I had available.

I connected everything up, wrote a quick program to control the motors and loaded it onto the Teensy 3. The first problem was the amount of noise that came from the motors, I thought something had gone horribly wrong, they shouldn't be that loud! Looking at the information on the Teensy 3's PWM it turns out the default frequency is 488.28 Hertz, this is far too slow and is well with in the human audible range. I changed the frequency to 18 kilohertz this is at the very top end of the audible frequency range and reduced the noise completely.
I've started to implement the code to read the number of counts per interval however I've yet to verify the numbers nor do anything useful with them.

/* Pin Map */
#define MOTOR_L_IN_1    16
#define MOTOR_L_IN_2    15
#define MOTOR_L_PWM     22
#define MOTOR_STBY      14
#define MOTOR_R_IN_1    17
#define MOTOR_R_IN_2    18
#define MOTOR_R_PWM     23
#define MOTOR_L_A       11
#define MOTOR_L_B       12
#define MOTOR_R_A       2
#define MOTOR_R_B       3
#define LED_STATUS      13
#define SENSOR_OPP_L    0
#define SENSOR_OPP_R    0
#define SENSOR_FLR_L    0
#define SENSOR_FLR_R    0
#define RUN             0

/* Global Variables */
volatile unsigned long leftCounter = 0x00000000UL;
volatile unsigned long rightCounter = 0x00000000UL;
volatile char oldLeft, oldRight, newLeft = 0, newRight = 0;
static char encoderQuadrature[16] = {0,-1,1,2,1,0,2,-1,-1,2,0,1,2,1,-1,0};

/* Global Functions */
void leftMotorA(void) {
  oldLeft = newLeft;
  newLeft = (digitalRead(MOTOR_L_A) * 2) + digitalRead(MOTOR_L_B);
  leftCounter += encoderQuadrature[(oldLeft * 4) + newLeft];
}

void leftMotorB(void) {
  oldLeft = newLeft;
  newLeft = (digitalRead(MOTOR_L_A) * 2) + digitalRead(MOTOR_L_B);
  leftCounter += encoderQuadrature[(oldLeft * 4) + newLeft];
}

void rightMotorA(void) {
  oldRight = newRight;
  newRight = (digitalRead(MOTOR_R_A) * 2) + digitalRead(MOTOR_R_B);
  rightCounter += encoderQuadrature[(oldRight * 4) + newRight];
}
void rightMotorB(void) {
  oldRight = newRight;
  newRight = (digitalRead(MOTOR_R_A) * 2) + digitalRead(MOTOR_R_B);
  rightCounter += encoderQuadrature[(oldRight * 4) + newRight];
}

void getMotorSpeed(int &leftSpeed, int &rightSpeed) {
  static unsigned long elapsed = 0x00000000UL;
  unsigned int localLeftCounter = leftCounter;
  unsigned int localRightCounter = rightCounter;
  leftCounter = 0x00UL;
  rightCounter = 0x00UL;
  elapsed = micros() - elapsed;
  leftSpeed = (localLeftCounter * 60000000)/elapsed;
  rightSpeed = (localRightCounter * 60000000)/elapsed;
  return;
}

void setMotorSpeed(int leftSpeed, int rightSpeed) {
  if(leftSpeed > 0)
  {
    digitalWrite(MOTOR_L_IN_1, LOW);
    digitalWrite(MOTOR_L_IN_2, HIGH);
  }
  else if(leftSpeed < 0)
  {
    digitalWrite(MOTOR_L_IN_1, HIGH);
    digitalWrite(MOTOR_L_IN_2, LOW);
  }
  else
  {
    digitalWrite(MOTOR_L_IN_1, HIGH);
    digitalWrite(MOTOR_L_IN_2, HIGH);
  }
  analogWrite(MOTOR_L_PWM, leftSpeed);

  if(rightSpeed > 0)
  {
    digitalWrite(MOTOR_R_IN_1, LOW);
    digitalWrite(MOTOR_R_IN_2, HIGH);
  }
  else if(rightSpeed < 0)
  {
    digitalWrite(MOTOR_R_IN_1, HIGH);
    digitalWrite(MOTOR_R_IN_2, LOW);
  }
  else
  {
    digitalWrite(MOTOR_R_IN_1, HIGH);
    digitalWrite(MOTOR_R_IN_2, HIGH);
  }
  analogWrite(MOTOR_R_PWM, rightSpeed);

  return;
}

void setup(void) {

  Serial.begin(115200);

  pinMode(MOTOR_L_IN_1, OUTPUT);
  pinMode(MOTOR_L_IN_2, OUTPUT);
  pinMode(MOTOR_L_PWM, OUTPUT);
  pinMode(MOTOR_R_IN_1, OUTPUT);
  pinMode(MOTOR_R_IN_2, OUTPUT);
  pinMode(MOTOR_L_PWM, OUTPUT);
  pinMode(MOTOR_STBY, OUTPUT);
  pinMode(LED_STATUS, OUTPUT);
  pinMode(MOTOR_L_A, INPUT);
  pinMode(MOTOR_L_B, INPUT);
  pinMode(MOTOR_R_A, INPUT);
  pinMode(MOTOR_R_B, INPUT);
  pinMode(SENSOR_OPP_L, INPUT);
  pinMode(SENSOR_OPP_R, INPUT);
  pinMode(SENSOR_FLR_L, INPUT);
  pinMode(SENSOR_FLR_R, INPUT);
  pinMode(RUN, INPUT_PULLUP);

  digitalWrite(MOTOR_L_IN_1, LOW);
  digitalWrite(MOTOR_L_IN_2, LOW);
  digitalWrite(MOTOR_L_PWM, LOW);
  digitalWrite(MOTOR_R_IN_1, LOW);
  digitalWrite(MOTOR_R_IN_2, LOW);
  digitalWrite(MOTOR_R_PWM, LOW);
  digitalWrite(MOTOR_STBY, LOW);
  digitalWrite(LED_STATUS, LOW);

  attachInterrupt(MOTOR_L_A, leftMotorA, CHANGE);
  attachInterrupt(MOTOR_L_B, leftMotorB, CHANGE);
  attachInterrupt(MOTOR_R_A, rightMotorA, CHANGE);
  attachInterrupt(MOTOR_R_B, rightMotorB, CHANGE);

  analogWriteFrequency(MOTOR_L_PWM, 18000);

}

void loop(void) {
  int left, right;

  digitalWrite(MOTOR_STBY, HIGH); // enable motors
  setMotorSpeed(200, 200);

  while(1)
  {
    getMotorSpeed(left, right);
    Serial.print("\f\rCounts/minute is: ");
    Serial.print(right, DEC);
    digitalWrite(LED_STATUS, !digitalRead(LED_STATUS));
    delay(2000);
  }
}

Next Steps

The next steps forward from this point would be to sort out the chassis, either re-design it to take advantage of 5mm plastics or get it cut from 6mm plastic. Once I've finalised my chassis design and actually have it I then can finish the logic board layout and get it sent off to be manufactured. Another step I can take in parallel would be see about implementing the closed loop control in the Teensy 3 or using my LPC1343 development board. I'm planning on running this robot at the June 2014 Birmingham Tech Fest so I'll consider May 2014 to be my final deadline for a completed robot.