Introduction

The first conversations on what kind of Robot we wanted to build started in Jan 2016.   Everyone on the team had wanted to build a spinning weapon Robot, having built a flipper last time.  There was also one other idea suggested that everyone on the team just loved, even though we all realised that getting from the idea to a working version would be more effort than every other part of the robot put together.  What that one other idea was we are going to stay very vague about until we are on Robot Wars and it’s been broadcast, after all nobody likes spoilers.

Following on from that first meeting the next month or two was spent doing the basic designs then we moved on through a prototyping and testing phase, finding many problems along the way, and discarding multiple solutions that did not work as hoped in practice.  Come Oct 2016 construction of the robot proper started.

One of the things everyone wanted to achieve with our robot was to build something original, something that has not been seen before.   We think we have achieved this with our robot, however it’s big unique feature is the part we are being vague about.   However there is lots of stuff under the hood that in some cases is unique and in others uncommon in Robot Wars.   Those under the hood bits we are going to talk about as we don’t think it will spoil the show for any one.

Electronics

The control system

Electronics, every combat robot has them, and the audience never see them (unless things go very very wrong).  Electronics are very important to the performance and reliability of a robot.

Our robots electronics have a number of key differences to the way things are commonly done.   We didn’t just do things differently for the sake of it, or because we think we know better than everyone else.  It’s just the common solution would not work for us (see that one big idea we are being vague about).

Commonly combat robotic electronics work on the following lines.  They have RC car/drone remote control system, this consists of a big radio transmitter you see people in robot wars using, and a receiver in the Robot.   The receiver controls the whole robot by a series of pulse width modulated (PWM) outputs.   Each of the receiver’s outputs is connected to a speed controller, which in turn drives a motor.   The longer each pulse the speed controller gets the more power it sends to the motor.   So when the person driving the Robot moves a stick on the transmitter, the pulse length on one of the outputs from the receiver changes length, and a motor goes faster or slower.   Which output(s) on the receiver link to which stick movements is setup on the transmitter.

Here is where our robot starts to differ from the rest, firstly our robot does not use an off the shelf RC car/drone remote system.  This is because the limited combinations of stick movements to receiver outputs would not work for us, also we need to take some real time data into account when calculating the speeds motors should be run at.

The main control system in our robot is based around a Raspberry pi.  This small computer has a number of custom boards we’v added (pi hats), that hold and connect up our radios, and provide the output to the speed controllers.    Unsurprising Robot Wars has rules about the control system of a robot, our system must meet those rules.  This is not just so we can get on the show, but because as all the team member enjoy being alive and would like to stay that way safety rules matter.

The rules for the radio gear cover the protocol and band it can use (DSSS and 2.4Ghz) and secondly you’re not encouraged to build your own radio gear (besides complying with all the RF emissions and testing legislation would be impractical), so we did not design/build our own radio gear rather we are using a radio module (complete with ic and radio amp) that is regulatory approved in both the EU and US.  This module is mostly used in RC gear for drones, planes, car and boats, as the equipment vendor quite often does not build the radios them selves but buys in a module.  That module is the mounted on the board they design that produces the outputs and handles the power regulation. We have followed the same route these manufactures follow, and designed and built a board that mounts and interfaces the radio modules to the pi.  We’ve then written a Linux kernel driver for the radios so we can talk to them.

The next part of the rules covers the behaviour of the system if it looses signal.   These rules are particularly important from a staying alive point of view, as heavy weight combat robots are 110kg in mass so you don’t want it going out of control.  If signal is lost the robot must effectively shutdown, in other words it should stop moving.   This feature can be written into the software, however the astute members of the audience will be thinking “what happens if the software crashes”.    This is one of the reasons we choose the pi, as it has a built in hardware watchdog.   This means if the software crashes the board resets killing all its outputs and shutting down the robot.  This infact gives us better protection than most RC radio gear as they in-fact do this protection in the software running on their micro controller (typically an atmel of some form), most micro controllers do not have a hardware watchdog so if the firmware enters and infinite loop the cutout on signal lost feature will not work.

Once we have the pi and it’s control software and the radio board with the modules (b52/channel/z) we need to add a board to provide the PWM outputs to the speed controllers.   This is  the second board we designed/built (b52/roam).   This board connects to the PWM inputs of all the speed controllers, it also has a CAN bus interface so we can read data back from the speed controllers and the power management system, and a number of other sensors.  The pi it’s self generates the PWM signals (using the DMA controller), the electronics on the output board (b52/roam) are there to protect the pi hardware.  So for example if power is accidentally connected to the PWM output the pi will not get fried.

The controller

As we’ve dropped the normal RC receiver from the robot and gone with our own system, we also need todo the same for the transmitter.  As our control system does not consist of a movement of the stick changes the pulse length on one or more outputs on the receiver.  Rather the controller tells the robot what it should do (forwards, backawards, turn left etc) and the on-board computer figures out how to make that happen with the motors it has available.

The controller consists of a second raspberry pi, the same radio module (b52/channel/z) that is in the robot and a usb controller (Mike our driver selected the original xbox controller as he really likes it).   All of this is wrapped up in a neat case with a battery pack to power it.

One of the advantages of building our own solution to control the robot is that the link between controller and robot can be bi-directional.  The robot can send status data back to the controller.   The most important data it can send back is about the quality of the link between robot and the controller, this way the transmitters amp can be turned down automatically if the signal is distorting.   We can also tell if the robot is receiving the command we are sending it, and reset hardware (e.g. speed controller) if we know the robot is getting commands but it not moving.  This also means we can tell if our removable link has come out or not.

Other side befits

Our different control system has some nice side benefits.   Firstly adding input from sensors is simple for us todo, this means we can improve the safety and performance of the robot.  For example if battery temperatures start to get too high we can automatically shutdown and preventing the batteries catching fire, rather than just seeing white smoke pouring from the robot like it’s picked the next pope.

The control system can run over the radios, but also over tcp/ip, this means we can control the robot from a laptop.  This has allowed us to write test scripts for the robot so we can perform the same tests time and time again to see how well any improvements have worked, this same system can be used to check the robot for damage in between fights.

The ramp rates for the motors can be customised.  Rather than trying to instantly change the motors speed from one speed to the next, we can change the speed in increments.  This protects the motor as the physical and electrical stress is reduced.

Other novel features

If you’ve just read the above section, firstly well done that’s a lot of fairly dry dense technical text, which means either your quite interested in this stuff or you have way too much time on your hands.  Secondly you may be thinking “Well ok I’ve not seen a Raspberry pi in use in robot wars that’s sort of interesting, but it’s not a cool new mega death weapon of some form or another.”  Your possibly thinking “What other novel stuff do you have, I was promised unique or un-common robot features, so far all you’ve got is a raspberry pi and something you won’t tell us about, come on spill the beans.”.

Well I’m still not going to tell you what the big unique feature is (spoilers), I will a list some of novel or un-common features of the robot without all the details (as you’ve read more than enough text by now) below.

• Brushless motors
• Twin weapons motor (if we lose one the weapon keeps working, it just does not spin up as fast)
• Our own power regulation system with redundant power for the control system (not just using the BEC from the speed controller)
• An amount of power conditioning to stop heavy power consumption in one or more speed controller from effecting the rest
• Logs temperature, power (amps/voltage) of all the motors and speed controllers for later analysis
• We can lose a significant number of drive motors and speed controls and still be fully drive-able
• We can switch off a number of motors and speed controller during a fight and bring them back in again to prevent damage from going over temperature
• The robot can tell if its upside down or the right way up, so our control scheme does not change when its upside down. In other words left on the control stick turns the robot left even when it’s upside down.
• Based on information other teams have stated publicly we think have one the most powerful spinner weapons in RW