Sumo robot electronics

So you want to build a sumo robot. Great. Go grab some coffee and make yourself comfortable because there are lots of things you should know about the electronics involved. When I started designing mine, I got in touch with a team that had already had a few years of experience. That’s something that you should consider as well. They were really open to sharing their ideas, designs and even mistakes so that we didn’t have to start from scratch. I thought I should take this a step further by documenting here some of the key points of designing a sumo robot. That’s the key to building a decent sumo robot on your first attempt.

Typical block diagram

Power supply

The battery used for the robot cannot power the other electronics directly, because usually the voltage of the battery is too high. The power supply unit has to provide the right voltages for the microcontroller board, the sensors and any other peripherals that might be on the robot. Here I’d like to start with two approaches that I don’t like.

One of them is linear regulators. This was the way to go in the 1980s, but it’s not wrong because it’s old. It’s a bad idea because it’s very inefficient. The higher the voltage difference between the input and the output and the higher the current, the more energy gets wasted as heat. Moreover, regulators like the LM7805 have an input voltage upper limit that is too low for the typical battery voltage used in these robots (32 V or more).

Another approach that I often see and I don’t like is a separate battery for the microcontroller. This is bad because it takes up a lot of space, adds significant weight and is yet another element to take care of. The robot might behave unexpectedly if this battery fails.

The solution : use a buck converter. Or more. I won’t get into any details of how it works, but let’s just say it’s far more efficient than any other solution when it comes to energy, weight and volume. It also has a wider input voltage range.

If you want to design custom electronics for the robot, you could make your own, but there are a lot of modules available online.

The microcontroller board

This could be an endless paragraph. However, I will try to give you some basic guidelines.

You should choose your board based on your level of expertise. The most obvious choice is the Arduino. It is by far the easiest to use, it has a huge community and lots of hardware and software resources that make life easier. This simplicity comes with a cost, which in this case is lack of performance. On the long run, I think Arduino encourages bad software and hardware practices, so you should consider something else if you’re more advanced.

The first alternative that I like is the mbed. The mbed compatible boards are based on ARM Cortex microcontrollers. They are a lot more powerful than AVR based Arduinos. They also offer a platform that simplifies software development by abstracting low level code, offering a HAL, RTOS and lots of libraries. The code is mostly portable and there are plenty of hardware options from low power Cortex M0+ boards to Cortex M4 ones.

If you’re brave enough (or skilled, actually), you can make your own board. This solution is the most effective as weight and volume. It solves the issue of having a mess of wires that come out of your robot as soon as you remove the top cover. It should include a microcontroller and all the custom hardware needs that you have, so other modules like the sensors or the motor driver should just plug into your main board. You could even make a hybrid that includes an Arduino or something similar and your custom hardware. However, if you’ve never done this before, I wouldn’t suggest choosing this as your first PCB layout.

Sensors

A robot needs sensors for two main reasons : It has to detect the other robot and it has to detect the white border of the ring, so that it turns in order to stay in the ring.

Enemy sensors are typically industrial reflective sensors. They emit light and detect the light that bounces off reflective objects. They usually have open collector outputs, meaning that they have an internal output transistor that has it’s collector exposed as an output.

This type of output requires external hardware in order to be read correctly by a microcontroller. The external hardware depends on the type of output (NPN or PNP). If it’s an NPN output, you need a pullup resistor, which pulls the output up when the transistor is not conducting. This results in two voltage levels : one close to ground and one close to the voltage that the resistor is connected to. The advantage of NPN outputs is that you get to choose the logic level, so the pullup resistor should be connected to the IO voltage of the microcontroller (5 V for most Arduinos or 3,3 V for ARM microcontrollers). If you’re using a PNP output sensor, you need a pulldown resistor. The big disadvantage of PNP outputs is that you can’t choose the logic level, and the output will swing up to the sensor’s supply voltage, which is too high for any microcontroller (usually 12–30 V). However, if you still want to use sensors with PNP outputs, you can use a voltage divider (but I wouldn’t recommend it) or some sort of logic level shifter to make sure you are not exceeding the IO voltage of the microcontroller.

One such sensor is the Omron E3Z-D82.

Border sensors are reflective sensors too. The main difference is that they have a lot less range compared with enemy sensors, so they can be a lot smaller. You can use a sensor that has the LED and the phototransistor in one capsule, like the TCRT1000. It needs external hardware to work (two resistors, nothing fancy), but it is easy to use. Another option is to use a module that includes a similar sensor, so you don’t have to deal with external hardware. Here’s one example : the QTR-1RC.

The motor driver

Building your own requires some serious power electronics knowledge. If you’ve never built a motor driver before, don’t build the first one for your sumo robot. It will be a frustrating experience.

There are lots of options online. You have to choose the motors first, decide what voltage you want to run them at, estimate the maximum current based on the motor’s datasheet and then choose a driver that fits. One popular option is the Sabertooth. You could also use Roboclaw.

Interfacing

Let’s assume you want to integrate a new component in an existing robot. When putting hardware components or modules together, there are several aspects to consider :

• Power

Is the voltage required for the new component present in the system ? If it is, check the maximum current of the new component and make sure you are not exceeding the current rating of the power supply. If not, you need to add a power supply that outputs the required voltage. (Go back to the power supply paragraph.)

• Logic levels

When connecting two modules or components, make sure that their logic levels match. Also, the maximum input voltage on any pin (of a microcontroller or any peripheral) should not exceed the VCC voltage of that module.

Example : If a module requires 3.3 V to run, an input signal that goes up to 5 V can damage the module or the source of the signal.

The solution : Try to use a single logic level for the whole system. If that’s not possible, use a logic level shifter for digital pins.

More details here.

• Pin assignment

When connecting something to the microcontroller, you have to choose the pins based on the interface. Some pins have special purposes, some are dedicated to a specific interface like UART, SPI, I2C, some are connected to the ADC etc. When connecting a simple switch or sensor, try to use a general purpose pin (that has none of these functionalities). When connecting a device that communicates on a specific interface like SPI or UART, usually you cannot use any pin, so use the pins that support the required interface. You have to be aware of the pinout constraints of the microcontroller or develpment board before designing the robot, so read the datasheet first.

Here’s an example :

This is the pinout of the mbed LPC1768 board. Let’s say you want to connect a sensor on the SPI bus. You have to use one of these groups of pins : (p5, p6, p7) or (p11, p12, p13), as shown in the above diagram.

Practical aspects

First of all, you must have a high level view of what the robot will do and how complex you want it to be. Then, you have to choose the components you want to include and also make sure they are compatible, based on the topics mentioned above.

Draw a block diagram of how the modules or components interconnect and make sure to include the pins of the microcontroller that they occupy. Make sure to include the power supplies as well.

Use a step by step approach to test the hardware before putting it all together. For testing purposes, everything can be built on a breadboard. On the actual robot you have to use something more ‘permanent’ than a breadboard. You could use a perfboard and solder all the components on it and keep in mind that the robot will take some serious impacts, so everything has to be well secured inside. The best option would be making your own PCB that holds all the components.

I can’t stress enough how the step by step approach can prevent the magic smoke from being released. Take great care with any power line. Make sure there are no shorts on any of the power lines and that the right voltages go to the right pins. This can be done before applying power using a multimeter and checking for continuity. Use connectors that lock in. General purpose pin headers will disconnect themselves due to vibration and impacts.

Prototyping

Here’s what me and my team have been using before the PCBs were ready. This crude setup allowed us to write software while waiting for the PCBs. We also spotted some hardware mistakes which were corrected before making the final version of the electronics. We started by making a few prototypes on perf boards. One of them is the board that includes the DIP version of the Atmega644, the main microcontroller used on our robot. Another board includes the Atmega328, which we intended to use in our motor driver. On the right, there is the USBASP programmer, used to load the code onto the microcontrollers, and the FTDI, which enables microcontrollers to communicate with the PC via USB. It even has motors and wheels, but they can’t be seen in this photo because they are under the wooden board.

Debugging

Is it a hardware or a software problem ?

While building your robot, chances are you will experience the most commonly heard question in embedded systems development : “ Is it a hardware or a software problem ?”. I’m sure there are better troubleshooting guides available online, but I will try to summarize my way of debugging.

Recent changes

Think about the recent changes that you’ve made, because they might be the cause of the failure.

Power supplies

One of the first steps in hardware debugging is making sure that the right voltages are present in the circuit. Check all the voltages present at the outputs of the power supplies and make sure all the modules are properly powered. One missing or abnormal voltage should help you narrow down the possibilities.

Here’s an example :

If one voltage is missing, disconnect the load from the power supply and see if the power supply works on its own. If it does, than something is overloading it so you have to look for short circuits. If it doesn’t work, than the power supply needs to be changed.

Use testing equipment

If the circuit is behaving unexpectedly, you certainly need a different perspective to find the problem. Here’s where testing equipment comes in handy.

Example : Let’s say you are trying to read some sensors and the values that the microcontroller reads are abnormal. Use a multimeter to measure the voltage on the pin and check if there is a mismatch. This way you can separate a hardware issue from a software one.

Example project

This is the first hardware version that me and my team have designed. Except for the motor driver, it works and it was used in a few competitions. It is based on the modules from the prototyping section above, but it has some extra features : I/O ports for sensors and external boards, comparators for the white line sensors, short circuit protection on the sensor ports, etc.

Finally, here’s the whole thing in action. Our robot, Anvil (on the left in the video) took part in the BattleLab Robotica contest in 2016 powered by this version of the electronics.

Although this article might be a little too subjective, I really hope it is a good starting point for anyone who’s interested in robotics and sumo robots in particular. Feel free to respond with your opinions and suggestions for improving this article.

Article written by Stelian Saracut, BLR 2016 and 2017 contestant and winner of the local phase of BattleLab Robotica 2017 with Anvil.

a