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.
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.
To get started with the ODrive just follow the Getting Started guide in the ODrive documentation: https://docs.odriverobotics.com/
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: https://docs.odriverobotics.com/odrivetool.html#flashing-with-an-stlink
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.
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: https://odriverobotics.com/shop/cui-amt-102
One interesting option that has already been explored (https://github.com/madcowswe/ODrive/blob/devel/docs/hoverboard.md) 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.
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.
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