Between 2nd February 2018 and 27th April 2018 I worked in a group to compete in the University of Brighton's Robot Wars assignment, as part of XE220 - Engineering Design, Innovation and Management.

This page details the process of researching, designing and building a featherweight fighting robot, that met the build rules of the FRA (Fighting Robots Association) and the specification set by the university. As the only electrical student in the group, this page focuses more on the electrical aspects of the robot. In the battle on the 25th April 2018, our robot won against group 19, and placed 3rd in the winners' melee, both times driven my myself. I'll explain why we didn't win in the melee later on.

Safety, rules and regulations

Before getting too in-depth, it is worth expressing how dangerous fighting robots can be. There are many activities associated with building and operating a fighting robot that are hazardous. I will go through some of the risks below:

• A soldering iron can burn you if you touch the wrong end of it. Mistakes do happen and if you do end up touching the tip of the soldering iron, or anything else that burns you, run the burn under cold water for about 10 minutes and seek medical attention if you don't think you'll be able to walk it off. Simply put, If it smells like chicken... You're holding it wrong.
• Solder fumes are toxic, so use an extractor fan when you can. A face mask or holding your breath won't help, because being able to breathe is recommended.
• The flux in solder can spit sometimes, be careful of your eyes. Wearing glasses is advised. Squinting will reduce the likelihood of hot flux coming into contact with your eyeball, but it's not ideal.
• With some solder being made using lead, you should wash your hands after handling it. In extreme cases handling solder can cause hand infection/dermatitis.
• Lithium-based batteries are extremely powerful and must be handled with care. Assume they will spontaneously combust at any time.
• While charging a lithium-based battery, a proper charger with battery management system should be used. The battery should be stored in a battery safe bag while charging.
• Furthermore, the battery should be stored in a battery safe bag while unsupervised/in storage.
• Do not let the batteries short-circuit. They are very powerful and very capable of overheating and igniting.

Fighting Robot Association (FRA)

To ensure all robots competing in the University fight had a minimum amount of safety features and were within the same general specification, the groups were advised to look over the Fighting Robot Association’s latest build rules and regulations document. Key points that were picked up on within the FRA rules and regulations were:

• 1.5 – Any sharp objects had to have a safety cover over them when not in use.
• 1.6 – Spinning weapons have to have a locking bar.
• 2.1 – Being a featherweight robot, the robot has to be a maximum of 13.6kg.
• 4.1.5 – Only specific radio frequencies are allowed. The 2.4GHz transmitter/receiver provided by the university is an allowed frequency.
• 4.2.1 – The robot must have a failsafe to completely stop the robot if signal to the transmitter is interrupted.
• 4.3 – It is advised that a light indicates when the robot is in failsafe mode.
• 4.4 – It is advised that robots have the ability to be shut off remotely (aka. Remote kill switch).
• 6.1.1 – The robot must have a removable link that cuts all power from the robot.
• 6.4 – The robot must have a power light.

These are just some of the rules that stood out; other rules applied that the robot naturally conformed to, for example, weapon RPM and battery voltages. Despite being told that we need to adhere to the FRA rules, it turns out that many groups did not implement many of the required safety features.

The FRA rules can be found here.

University Specific Rules

On top of all of the reiteration of the adherence of the FRA Build Rules, it was required that the robot was able to fit into a University of Brighton locker.

Research

The group researched previous years' fights that had been held at the university by watching YouTube videos. There are a number of videos you can watch by searching for "Robot Wars Brighton" on YouTube. Looking at how previous robots performed helped us decide on the design of our robot. An honourable mention goes to Charles Hoile who wrote The Ultimate XE221 Robot Building Guide, answered any questions I had about the university Robot Wars event and gave me a lot of relevant advice.

As well as videos recorded at the university, there are also featherweight robot fighting events held around the world, so we looked into some of the more exotic featherweight robots that fight in these events. Knowing that our robot would be fighting against students with much the same recourses as us, we didn't prioritise making our robot as destructive as we'd originally wanted to. Besides, building a robot deemed too dangerous would have meant we couldn't have fought it on the fight day. We would have got full marks for building a very dangerous robot, but where's the fun in not being able to fight it?

Mechanical side of things

Being an electrical student, I left most of the mechanical side of things to the students studying Mechanical Engineering and Aeronautical Engineering, but I did not shy away from getting involved with things I knew I had the tools and experience to help out with, especially as time was running out nearer the end.

Wheels

My friend, Charles, gave me a set of 4 wheels he suggested I use for the robot. He had them left over from when he was building his robot last year, but didn't have time to implement the wheels into his design. I showed the wheels to the group and we all agreed that they would be suitable for use on our robot. The wheels are available on eBay for £16.80 at the time of writing this. A link can be found here but they may no longer be available due to being clearance stock. The important specs are as follows:

• Material: Blue elastic rubber
• Wheel diameter: 125mm
• Tread/tyre width: 32mm
• Bore: 15mm
• Load rating: 200kg/600kg over 4 wheels

A rotary tool (Dremel) was used to bore out the centre of the wheel so that the motor bosses that the university supplied could be attached to the wheels. Someone else in my group did this and bolted the bosses to the wheels. He said it took him a long time, but I think he did a good job and they’re definitely attached well enough. There were a few groups who had wheels fall off during the fights.

Design

Knowing the size of the wheels enabled the design of the rest of the robot to be worked on. The size of the wheels determined the height of the robot, as we wanted the robot to be able to be driven upside-down if needed, but still have enough ground clearance, for slightly un-level terrain.

Weapon

The rules stated that we needed an active weapon, however, in videos of previous years we noticed that there were a lot of robots that didn’t have an active weapon. Their main weapon was (apparently) manoeuvrability, however, in some cases, this could have been seen as a weakness, due to how uncontrollable some of them seem. Although this would have been easy to achieve, as a group we decided that we wanted to have an active weapon to at least tick the box, of having an active weapon.

Despite choosing to have an active weapon, we still focused on the robot’s manoeuvrability as being the main weapon, as such.

We decided to use a fifth drill motor to spin a small saw blade. The drill motor was not the same as the motors used for the wheels, as it was taken from an older generation Argos cordless drill.

Chassis and armour

The chassis was designed to use 12mm x 4mm steel bar; cut and welded into shape. This was purchased from Wickes. Although this was not the cheapest option, it was the quickest way we could get the material without having to drive to a warehouse miles away or wait for a delivery from an online store.

The armour was made using mild steel sheet provided by the university. We knew this wouldn’t be the strongest, but figured most groups would be using the university provided steel or just MDF wood, without a weapon powerful enough to moderately damage the steel.

The base was a simple 18mm MDF sheet from Wickes, cut to size with a few holes cut and drilled in it.

The model below shows the robot Solidworks model:

Wheel control

Many different robots use a myriad of different control methods, but we decided on a differential drive system. This was because it was easy to implement and understand. This method worked very well with our robot, helped by the fact that it was four-wheel drive. Most groups only used two-wheel drive and used castor wheels at the front of their robot. Even though this worked, the robots that implemented this approach didn’t seem like the easiest to control, especially when the wheel-base became longer and narrower on some designs.

Differential drive means that the robot drives like a tank. It is more effective and efficient when used with only one wheel per side, but since the motors have enough power, the wheels skidding is acceptable and the trade-off of having better grip, more pushing force and motor redundancy outweighed the extra wear and tear on the tires.

Electrical

Transmitter/Receiver

The university provided a Turnigy 9X transmitter with accompanying receiver. Although it is entirely possible to use a different transmitter/receiver combo, or even a DIY control solution, it made sense to use one already tried and tested by students in previous years. The transmitter was also capable of mixing channel 1 and channel 2, so that the left and right motors would function together, rather than independently on each channel. This is called v-tail mixing.

Motor choice

The university provided 2x Argos Simple Value Cordless Drills. This made choosing the motor an easy decision as to buy the remaining two motors would only require the purchase of another two of these readily available cordless drills, for £20.99 each. The drills also inluded a suitable gearbox.

The drills are easily disassembled using two Torx drivers; T? for the casing and T? for the chuck. A university lab technician was on hand to take the drill chucks off. I let him take the drill chucks off of the university provided drills, but decided to attempt the chuck removal myself with the additionally purchased drills. There is an interesting forum post by Alex from Team Nuts (of BBC’s Robot Wars), who disassembles the Argos drill and discusses mounting options and other interesting aspects, like the battery chemistry: http://www.fightingrobots.co.uk/threads/13461-new-style-argos-drill-motors-a-look-inside-and-review. Thankfully, we didn’t need to worry about how we would mount the motors, as the university provided motor mounts and bosses to accompany the drills. Having an extra two motors meant we had to acquire an extra two mounts and bosses. Someone in my group got these off of another group who did not need them.

Motor control

There are four methods of controlling the drill motors that were considered.

Mechanical speed controller

This speed controller is provided for free by the university, making it a good choice to reduce the overall cost of the robot, but the reliability of this speed controller is below my desired level.

Building the mechanical speed controller is relatively straightforward, but it doesn’t allow for much speed control, as this speed controller only allows for full speed and half speed control. It is a mechanical solution to an electrical problem, as expressed by the module leader. Below is a picture of the mechanical speed controller:

Electronic H-bridge design using relays

This speed controller allows for the motors to be controlled electronically. It would be reasonably easy to build, with most parts available from the university upon request, except for the relays.

One major drawback of this design is that there would be no granular control of the speed, as the relays would switch the motors on or off, full-speed or no-speed, without any middle-ground. I considered this unacceptable.

Electronic H-bridge design using MOSFETS

This design is by far the most challenging speed controller to build, but it would allow for the greatest range of speed among the “DIY” speed controllers. With it being designed and built by myself, I had a high level of control over the design, making it very desirable. Despite being the most challenging to implement, this type of speed controller is highly desirable.

I attempted to design an H-bridge using MOSFETs as I had enough time to learn the theory behind how an H-bridge and MOSFETS work. The schematic below is the final design of the H-bridge. It completes the “half” H-bridge that was provided on StudentCentral, by the module leader, Ian Watts.

Unlike the design on StudentCentral that was designed to use Ian Watt’s PIC chip, that decodes the PPM signal from the RC receiver, this design was intended to be used with an ATMEGA328P chip, that functions much the same. Unlike “Ian’s PIC”, as it is called among fellow students, there is no control over the design and behaviour of the software embedded on the chip, as it has been pre-programmed and the code is unobtainable. Ian is also very precious over his code; rightfully so. By programming an Atmel chip with my own code, I am able to control every aspect of the controller, as well as add features at will. I also have a lot of experience with dealing with Atmel chips, something that I cannot say about my experience with PICs; which is relatively minimal.

With some help from a couple of members from the Electrical Engineering section of StackExchange, I was able to populate the design with the correct components and understand their purpose. I have no shame in asking for help with this as, without the help, I would not have learned as much as I did.

My original StackExchange question can be found here.

The purpose of the NME1215SC DC to DC converter is to provide an isolated supply to drive the top-side transistors at a gate-source voltage greater than the DC power rail voltage of the drains. This is because the top-side MOSFETs are connected as voltage followers, and to adequately ensure that they turn on to a low impedance (drain connected to source internally), the gate has to rise above the drain voltage by several volts.

A bonus of supplying the MOSFETs with 15V, as opposed to 12V, is that a higher gate-source voltage reduces conduction losses.

D4, D5, D6 and D8 are 15V Zener diodes. Their purpose is to protect the gate-source from a possible over-voltage. To accompany the Zener diodes, a 22Ω resistor is connected in series to limit current into the Zener, protecting them from overload.

Diodes D1, D2, D3 and D7 and resistors R3, R7, R10 and R14 increase the turn-off time of each MOSFET, by extracting current from the gate capacitance quicker than what would be extracted by the 22Ω resistors alone.

The 220kΩ resistors are to ensure that the MOSFETs are turned-off when power is removed. They do this by discharging the gate-source capacitance.

I designed the PCB to be double-sided, due to the complex nature of the circuit. The board was printed using the etching method, by a university lab technician. Unfortunately, too much of the copper was etched away in some places, and it was made inverted, despite the Proteus file being set up correctly and it even included text, which would give away the correct orientation of the design.

This was the fault of the university lab technician. Despite this setback, I continued populating the PCB with the components. However, this was difficult due to the fact that the board was designed to be optimally soldered on the bottom, with most components on the top and only a few simple components being soldered from the top.

With the time frame given to get the H-bridge with MOSFETS working coming to an end, and the supply of components depleting and becoming damaged, due to soldering and probably design errors, we decided, as a group, to consider a different option. Here is a video of the speed controller releasing the magic smoke, during one of the tests:

I did eventually manage to get the system working with just a forward direction. Here is a video of that:

Electronic speed controller

Although this may be considered to be one of the easier options, there is still the factor of having to understand how to interface with an off the shelf speed controller. There is an extra cost associated with using ESCs purchased online, which could be used to fund the purchase of other parts for the robot. Also, having to wait for the ESCs to arrive in the post adds time to the overall time to completion.

There are many ESCs available online, with varying price ranges and current capabilities. An example of an ESC at the high end of the scale is the Wotty 360EV, designed and individually built by Ian Watts himself. He also makes other power rated ESCs, but information about these online is very sparce. A photograph of the Wotty 360EV is below:

After some research, I settled on the Hobbywing QuicRun WP 1060 ESC for the following reasons:

• Relatively inexpensive (less than £15).
• Waterproof.
• Capable of running two drill motors with one ESC, however, each motor was powered with their own ESCs to avoid “fatigue” of running the ESCs close to their design limit.
• Built-in battery protection circuit (i.e. cuts out the battery supply when the voltage falls below a safe value, based on the battery setting set with the jumpers on the device).
• Forward and reverse ability.
• Compact and robust design.
• Easy enough to swap out if any problems occur.

I modified the ESCs to replace the existing TAMIYA and bullet power connectors with XT60 connectors, which are used throughout the robot’s electrical design.

Battery Choice

The batteries provided with the drills are suitable to power the robot. They are lithium based and as such require care during storage, use and charging. Taking the batteries housing apart reveals 3x 18350 cells connected to a charge/protection circuit. Although marked as being 18350 cells, their dimensions are much more like an 18650 cell, whereas, upon searching for 18350 cells online reveals cells half the size of 18650 cells. There is not much information online about the specific cells used inside of the drill battery. The comparison below compares a standard 18350 cell, the drill 18350 cell and a standard 18650 cell:

On the Fighting Robot Association’s Forum post mentioned earlier, there is information referring to these cells. The post claims that the cells’ chemistry is LiNiMnCoO2, making these safer than LiPo batteries, but they are not an approved battery chemistry, according to the FRA’s rule set. The university has however allowed the use of these cells during the event. Each of the four drills came with their own separate batteries and chargers, while all four of these could be wired in parallel, I decided to strip the batteries down to individual cells, so I could make a more-compact battery. Disassembly was straightforward, with only 4 standard Phillips screws keeping the battery within the housing and only a few wires and nickel strips that needed snipping off to free the cells from the charge/protection PCB.

Each of the cells were individually charged to ensure that they were all at the same voltage so that when they were combined, the difference in voltage did not damage them.

To charge the cells, I used a cheap Li-ion battery charger I purchased off of Amazon for £13.99.

I combined the cells together according to the following schematic, and they were wrapped in heat-shrink and electrical tape for added protection.

I connected a balance lead between each set of cells so that the battery could be charged properly with a lithium battery balance charger. Personally, I use a IMAX B6 DC Charger as it is cheap and easy to use.

Although other battery types are readily available, the decision was made to use the batteries already provided by the drill motors. Purchasing a different battery would incur an additional cost to the group, and the benefit of a higher capacity battery, such as a LiPo battery, would not be fully taken advantage of, due to the small timeframe that the battery will be used. Furthermore, there are additional precautions that would have to be put into place while using the more-volatile Lithium Polymer battery type.

Failsafe

According to rule 4.2.1 of the FRA rule set, the robot must have a failsafe to bring the robot to a complete stop if the signal from the transmitter is interrupted. Many transmitters and receivers have the ability to program a failsafe mode, but unfortunately, the Turnigy 9X does not have this feature. In the case of the Turnigy 9X receiver, when the signal from the transmitter is interrupted, the receiver will maintain channel 1 and channel 2’s last known values, until the signal is re-established. This is not safe, as the robot will continue moving if the signal is interrupted.

To circumvent this problem, I first analysed the state of each channel when the transmitter is switched off. I did this by connecting each channel to an Arduino and printed the value of each channel to the serial monitor. I found that the only channel that changed when the transmitter was switched off was channel 3, the throttle. This makes sense, as the transmitter is primarily designed for RC aeroplane. Cutting power to the aeroplane propeller and maintaining the aileron and rudder signals should allow the plane to glide until the signal is re-established. Other transmitter/receiver kits allow for specific aileron and rudder (channel 1 and channel 2) values to be set. In the case of an aeroplane, this could be set so the aeroplane would glide in a spiral, slowly to the ground, until a signal is regained or it gracefully crashes into the ground. For the robot, this would be set to stop both motor pairs and the weapon.

Back to the Turnigy 9X. When switched off, channel 3 assumed a value outside of the normal range of the throttle stick on the transmitter, lower than the zero position on the transmitter’s throttle stick. I built a circuit to exploit this feature, by checking if channel 3 was below a certain value. This would determine whether the receiver was receiving a signal from the transmitter. Additionally, I programmed one of the switches on the transmitter to control channel 5. This was also compared along with channel 3. The addition of the switch adds the ability to remotely activate the failsafe mode, thus, satisfying the advisory rule 4.4 on the FRA rule set.

The way in which the Turnigy 9X transmitter works is that it does not allow itself to be fully switched on until all switched are in the off position. The user is greeted with a “SWITCH ERROR” if any of the switches are active.

The schematic below shows how I attempted to connect an ATMEGA328P microcontroller to the receiver channels and 5 optoisolators. The optoisolators were connected to the power switches of the Hobbywing QuicRun 1060 ESCs. By completing the circuit, the ESCs activate.

I designed a PCB according to the schematic and populated it with all of the necessary components:

Upon testing my DIY failsafe module, it kind of worked with inconsistent results until it just stopped working, with one or two of the optoisolators getting extremely hot. I decided to abandon the idea of having a failsafe, as I knew that no other group would be implementing a failsafe, let alone a removable safety link, or even a power indicator! Despite undesired results, it was a good learning experience.

An alternative method of implementing a failsafe that I considered was having the ATMEGA328P microcontroller controlling the state of a high-current 12V relay, connected between the battery and ESCs. This would have made the schematic simpler, but this failsafe circuit used components already available from the university technicians, minus the Atmel chip. A relay would have to be purchased separately and would eventually suffer from mechanical fatigue and arcing of the high-current DC power.

Timeline

I understand that the layout of this page does not explain much about the timings of each stage of the project, so I will try to address this now.

Beginning of project – 02/02/18

We were put into groups based on how our peers had marked us in our statements of relevance (SoR) at the end of the pasta bridge project. From there, my group setup a Whatsapp group chat, so that we could easily communicate with each other while working on the pin up proposal material.

Pinup proposal – 15/02/18

We had just under 2 weeks to cobble together some research and draft designs of our robot, to show and be marked by the rest of our class. It is not marked by the module leader. The pinup proposal was worth 20% of the overall project mark. Here is a photograph of how our pinup turned out:

Motor controller test – 01/03/18

Dedicating quite a lot of my time to getting the electronic speed controller using MOSFETs working, which was unsuccessful, the night before I knocked up a combination of the semi-working DIY ESC with a make-shift mechanical speed controller. My DIY ESC was okay with going forward, but the magic smoke escaped when I tried to run a motor in reverse. To add a reverse capability, I made a mechanical speed controller (of sorts) that controlled the motor connection polarity. This was made up the night before the assessment, so was not the prettiest.

I originally planned to control the position of the servo using the same Arduino that controlled my ESC board, but I soon learned that including the servo library interfered with the timers the ATMEGA328P chip uses to perform pulse width modulation (PWM). As a quick solution, I connected the polarity changer servo (mechanical speed controller) to channel 3 of the receiver and controlled the direction using the throttle stick on the transmitter.

It was far from pretty, but it was a far greater effort than a lot of other groups; with every other group using the bog-standard mechanical speed controller. If I was to do this again, I would have built a mechanical speed controller as a backup, at least so I could have used it for changing the motor polarity, rather than making one up, the night before, using bits and bobs I had laying around my flat. This assessment formed 10% of the overall project mark.

Show & tell – 08/03/18

This was not marked, so did not count towards the overall project mark, but it was beneficial to attend as it meant that we could get a feel for what we were going up against, the ones that were worth worrying about, as the groups that did not attend didn’t fare so well during other assessments during the project, including the final fights.

Some groups had prototypes and even partially built robots, none of which were functional yet, but it was enlightening to see the approaches different groups were taking. My group did not have anything to show to the class, but we were all ready for questions that were fired towards us. Seeing other groups’ progress, hearing their answers to some of the questions asked and having to think about and answer questions asked to my group definitely helped us when progressing further, with our robot design.

Functionality test – 15/03/18

I was given a piece of wood that was cut to size for the robot, that I attached the motors to the wood using some wood screws. With the design being drawn up on CAD by a group member, with millimetre precision, there wasn’t any slack for inaccuracies with the piece of wood or the position of the holes I had to drill. All of this combined meant that the motors were literally touching each other.

This wasn’t ideal, but its what we had to work with. I continued to wire up all of the electronics, ready for the functionality test. By now I had purchased two Hobbywing Quicrun 1060 ESCs, which appeared to run two motors each okay.

The functionality test consisted of driving the robot in a figure of 8 around two cones in the lecture theatre forwards and then backwards, all while avoiding crashing into the cones or the walls, as doing so would knock 10% off of the functionality test mark. A breakdown of the marking criteria is as follows:

• Late? -10% per 5 minutes
• Figure of 8 completed forwards, +50%
• Figure of 8 completed backwards, +50%
• Crashes, -10% per crash
• Wheels fall off? -25% per wheel

Despite being quite nervous not to crash and let my team down, I managed to complete the course with ease, getting 100% for this. The functionality test made up 10% of the overall project mark.

Battle - 18/04/18

The mechanical engineering students in the group set about welding the frame. Having trouble accessing the workshops, my group was only able to weld one side panel on to the chassis, leaving me to have to attach the rest of the side panels using some nuts and bolts I purchased from Tool Station down the road.

I took my time drilling holes in the chassis and panels, allowing the bolts to slide straight through, with a nut on the other end securing it. Once the panels were attached I gave the robot a spray of black Poundland spray paint. The robot was now ready to fight.

I practised driving the robot outside Charles’ house, with his robot, to test the reliability, control and how robust it is. Once satisfied with everything, I deemed the robot ready for the fight. Here is my group’s robot with Charles’ robot:

Charles' robot with my robot.

Similar, don’t you think? ;-)

Here is a picture of the insides of my robot:

On the day of the fight, there was quite a bit of waiting around, with having to queue up for weighing the robot, having a group picture taken and waiting for our fight with group 19.

When it was time, I entered the arena with the opposing robot and fought.

As you can see in the video, I won the fight. Some observations of this fight are as follows:

• The crowd seemed impressed with my robot. Up until this point, there had only been two other fights and they weren’t that entertaining.
• The robot got stuck on Ian’s house robot, but the saw blade (thankfully) acted as an extra wheel to move it off.
• The saw blade was useless as a weapon and ended up dragging along the floor, causing the robot to judder towards the end of the fight.

In the end, it turns out that my brute-force driving, which I knew the robot could handle thanks to testing it with Charles’ robot, was too much for group 19’s wooden robot and ended up dislodging one of the motors. Interestingly, group 19’s robot was also four wheel drive, something that was quite rare among the other robots.

While waiting for the winners’ melee, my group and I checked over the robot and tightened up some nuts and bolts that became loose during the first fight. There was a bit of waiting around until the winners’ melee.

When the time came, most of the winners from the individual fights entered the arena. Some did not participate due to their robots becoming too damaged or batteries becoming flat because they were driving it around outside of the arena (something that Ian expressed was not allowed). Nevertheless, I entered the arena and fought. The videos below show the fight:

I very much enjoyed taking part in the winners’ melee. I am a bit disappointed that the robot didn’t last until the end, with the link being knocked out, but it was still fun to be able to push the other robots around. Looking back on the video, I can see that there are a lot of opportunities I missed, in terms of being able to knock people off and damage people. I remember focusing on just driving the robot and going after something that caught my eye, rather than actively looking for things to target.

If I was to continue developing the robot I would improve the weapon, make the armour stronger and get the dimensions of the robot closer to that of the original SolidWorks drawing. I would also improve my driving by practising more and being more aware of what was going on around me.

I hope you have enjoyed reading this article. If you have any questions about this project, or any others on my site get in touch!