The Competition

As everyone is waiting for the answer of how we did in the competition. We’ll get to point: WE WON!! At least one of the three first matches ;-). Which meant we couldn’t compete in the next round.

This isn’t because the competition was too good, it’s just that Fanny wasn’t what it could and should be. We have all the hardware to make a “killer” robot but we didn’t had the time to get everything working as it should.
Before this competition we have participated in the same competition already two times and ended in the top 3 each time. We started this when we were students and had a lot of time. But everyone graduated and got a job and we just underestimated how much time we had left after work.

We lost lots of time by trying and learning new things:
1. We tried to 3D print our own gearboxes (will be continued for sure)
2. Programming a new processor we had no prior experience with
3. Working with a new kind of motor drive
4. Adding our own sensors to the motors for closed loop control (which costed the most of our time)
5. Working with new sensors

Instead of adding features and improving the robot we were stuck in a loop of fixing things and troubleshooting. We did learn a lot from this project. And you can definitely expect a comeback from us!

And a big thank you to all our sponsors and partners who supported us through this!!
See you in two years!!

Wheels 2.0

The previous wheels had the problem that the wheel hub was able to slip inside the silicone cast. If this would happen while the robot is pushing this means we won’t be able to utilize the full pushing force of the robot. With this in mind we designed new wheels in FreeCAD. Fortunately we had some silicone left over that we got from VOSSCHEMIE.

Re-doing the hall sensors

During our first test run we discovered that the hot glue was not sufficient to keep the hall sensors in place. When the motors get hot (this happens when they stall) the hot glue easily melts and the sensors get loose.

Dismantled motor

We dismantled the whole robot and the motors. After separating the rotor and stater it was easy to glue the hall sensors back in, but this time using epoxy. The epoxy glue should have a higher melting temperature.

Finished soldering the sensors

After soldering wires to the hall sensors the motors are put back together. Using our scope we could see they are working normally again! Hopefully they won’t come loose this time! ^.^

The birth of a wheel

As we mentioned before one of the most important parts of the robot are the wheels. The wheels are needed to transfer the motor power into pushing power. Without good wheels the wheels will slip and the motor power will be useless.For this reason we will make our own custom wheels with silicone rubber from VOSSCHEMIE.

It all starts by designing the wheel in 3D, for this we use FreeCAD.

The wheel consists of 3 separate parts over-molded with silicone.

To cast the wheel we need to have a mold for this we also use FreeCAD.

The 3 designed parts needed for the mold.

Next step is to 3D print everything.

Now we can finally start casting the wheels. For this we use 2 part silicone: SICOVOSS from our sponsor VOSSCHEMIE. Part A and B need to be mixed in a 1:1 ratio by weight. First we calculated the needed volume to fill the mold and calculated the desired mass we needed to fill the mold.

And then the mess could begin!

And here is the result after waiting a long time, the de-molding time would be between 6-7 hours but for this cast the time needed before be-molding took much longer. Probably because of the pigment used.

Final result !!

Thanks again VOSSCHEMIE for being our sponsor for the second time in a row!!!

STMicroelectronics: Sponsorship

For previous robots we relied on Arduino for the controlling unit. But this time we wanted to go to the next level and use a really advanced and capable microcontroller. Fast robots require fast brains, so we need a fast microcontroller. Last year I was a volunteer at The Things Conference from The Things Network. At the conference I was lucky enough to meet Benjamin Guilloud one of the Technical Marketing Engineers from STMicroelectronics.

STMicroelectronics is the only European microcontroller manufacturer and they have a big range of products, from microcontrollers to sensors.

I contacted Benjamin and asked if ST would like to support us by giving a development board and maybe a few of their Time Of Flight sensors. And yes they did, they send us a few development boards, a few Time Of Flight sensors and even some of their high-end microcontrollers.
This sponsorship will not only give our robot the brains we need but also the eyes to find our opponents.

Thank you very much Benjamin and STMicroelectronics, your support is truly appreciated.

Getting started with BLDC motors – ODrive

The past Sumo contests we saw a lot of different robots in all shapes and sizes. Some used an Arduino Uno board others a went with a Raspberry Pi, detection was done using infrared or ultrasonic,…
Many different combinations and techniques. But one thing was missing. There was (almost) no one using BLDC motors. All the robots I saw used standard brushed DC-motors driven by an H-bridge.

After I saw this I started annoying Bruce by constantly asking why he wasn’t using BLDC motors for his next robot (Thierry). At the time I was experimenting with quadcopters and those use BLDC motors. The power those things have is incredible!
So after a while we agreed to try out BLDCs for the next robot if I would join the development. My nagging stopped and so here we are trying to figure if it is possible to use BLDC motors on the sumo robot.

ODrive BLDC motor controller

While exploring the options for BLDC motor control, we came across an interesting open source/hardware project, the ODrive:

This project aims to replace stepper motors with the much more powerfull BLDC motors. The people behind this project have put a lot of effort in making this amazing controller board that can control two BLDC motors simultaneously. All the hardware and software is fully open source!

For our robot they were very happy to provide us with one of their boards so we could start experimenting with it.

Picture of the ODrive from the official website.

The heart of the board is an STM32F405 micrcontroller. It is possible to communicate with it in many different ways (CAN, SPI, USB,…). To start we used the odrivetool which is written in Python and runs on the PC. It can be used to configure the ODrive through a command line.

Getting started

To get started with the ODrive just follow the Getting Started guide in the ODrive documentation:
It was very difficult in the beginning to get the ODrive working as it did not want to communicate with the PC and upgrading the firmware through the PC didn’t work either.
To get everything working we flashed the latest firmware in the STM32 using an STLink programmer. It is not very hard to do and is well documented here:
Once this firmware was flashed we confirmed that everything was working by doing a dfu through the PC. Once that was possible, the ODrive shows up in the odrivetool.

The ODrive shows up in the ODrivetool

Sensored brushless motor

The strength of the ODrive is that it has the option to use an encoder for feedback. This way the ODrive knows at what speed the motor is spinning and even at what position the motor shaft is exactly. So it is possible to use a brushless motor in applications like a 3D-printer when using the ODrive.

For the robot the only thing we are interested in is the motor velocity. By accurately controlling the velocity, the robot can push against heavy objects without the motors stalling suddenly (if the motor can deliver enough torque to move the object of course).

In order to implement feedback something is needed that measures what position the motor shaft is in. There are a lot of options to do this for example use a capacitive rotary encoder:

Example of an optical rotary encoder. Photo by Rrudzik. Picture relased under GNU Free documentation License and CC.

One interesting option that has already been explored ( is the use of hall sensors. There are brushless motors out there that have these built-in. Most of these motors are inrunner motors used in RC cars. For the robot we decided to use an outrunner BLDC motor and glue some hall sensors into the windings.

Mounting the hall sensors in the windings

On the market there are inrunner brushless motors that have hall sensors built in. However we decided to give outrunner brushless motors a try and mount the hall sensors ourself.

To mount the hall sensors onto an outrunner there are two options. The sensors can be placed very close to the outer rotating shell of the motor. In order for this to work the sensors need to be placed a certain amount of degrees spaced from eachother. It is not hard to calculate this distance, but mounting the sensors space e.g. 3.12deg from eachother is not that easy…
Also the sensors are not directly attached to the motor so when the motor starts vibrating this could easily introduce noise.

Hall sensors glued into the motor windings.

The second and in my opinion better option is to mount the sensors in between the motor windings. Above you can see our work of art with wires and a lot of hot glue…

Connecting the hall sensors

Connecting the hall sensors is pretty easy because the ODrive has onboard pull-up resistors. So the open drain outputs of the sensors can be directly connected to the A,B and Z inputs.

Directly connect the hall sensors to the ODrive.

The only thing that requires some attention is the supply voltage. For the SS41 to work correctly it needs at least 4,5V. So these sensors need to be connected to the 5V line of the ODrive. Connecting them to 3,3V will not work.
Because the sensors have an open drain output the supply voltage has no effect on the voltage levels seen on the GPIOs of the ODrive and thus no level shifters are necessary.

Setting up the hall sensors

Setting up the ODrive to use the hall sensors for feedback is pretty straight forward when looking at the hoverboard example. The only problem with the article is that in the latest firmware this command doesn’t work:

odrv0.axis0.encoder.config.mode = ENCODER_MODE_HALL

The command doesn’t work because the constant “ENCODER_MODE_HALL” doesn’t exist. When looking at the source code in “encoder.hpp” we can see that the encoder mode is an enumeration. The hall encoder mode gets assigned the integer number “1”. So we can tell the ODrive that we will hook up hall sensors by setting the encoder mode to “1”:

odrv0.axis0.encoder.config.mode = 1

Now if everything is Okay it is possible to see if the hall encoder is working by typing:


Try manually turning your motor and see the “hall_state” changing. Normally the “hall_state” should follow Table 1 on page 9 of this application note. If you don’t want to convert the binary values to decimal this is the states the encoder should follow:
3 -> 2 -> 6 -> 4 -> 5 -> 1