08/21/2018 at 14:53 •
Two weeks before the EMFcamp 2018 I learned on Twitter about Hacky Racer. And because I'm quite into moving objects, I had to join the race. I already have some moving objects, a BobbyCar, a moving armchair, but all of these are rather unpractical to comply with the Rules of HackyRacer.
So I decided to build something new. I had anything I could possible need laying around, like tons of hoverboard motors, ESCs, batteries... All I needed to buy was a kids toy:
I wanted to have all-wheel drive, because why not. On the same day I started planning the vehicle:
It had to comply with the rules of HackyRacer, and one of them is that the batteries need to be contained in a metal box. That is what the ammo box on the back is used for. Apart from that, I replaced the front wheel with a BLDC motor of a Ninebot Mini Scooter, and milled an aluminium sheet as the main body to sit on:
Then I welded a longer steel pipe onto the existing frame of the kids tricycle and added a better seat from a broken chair.
Usually to get highest possible speed I would have used a 13s (13x 3.8V = 49.4V) LiIon battery for this tricycle. However, per rules a maximum voltage of 48V is allowed. To I decided to go with 12s 16Ah LiPo. Also per rule, there must be a main switch to completely turn of the vehicle. So I added a 400VAC 25A machine switch to the battery box. This is a 3ph switch, so it has 3 switching contacts. I connected them all in series to ensure safe circuit braking in case there is an arc between one of the contacts while opening under load. Also there is a generic protection pcb inside the box that monitors the individual cell voltages and does some balancing during charging.
For everyone who knows me, it is probably obvious what motors I used for this tricycle. I did lots of hoverboard hacking during the last year, so I still have lots of these motors laying around. They are very great because they are cheap, they are really reliably and tough, and they have lots of power. These typical hoverboard motors come in three sizes, 6 inch with solid rubber, 8 inch with solid rubber, and 10 inch with an air tube. They all have 350W at 36V so depending on the size you get more or less torque, but also more speed for bigger diameters. At 12s however you can get more than 1000W out of these motors for a short period of time. Of you overload them for too long, the copper winding burns or the internal hall sensors start to desolder.
For the back, I wanted to have the air tubed wheels because I have no other shock absorption and it would probably be quite hurtful to have an offroad race with the solid rubber wheels. Unfortunately I only had two of these left so I had to use a wheel of a Ninebot scooter. These are identical to hoverboard motors on the first glance, however when I configured the ESCs I noticed the motor parameters are quite different and the current PID that worked fine for hoverboard motors started to oscillate. Also, after fixing this, the motor still was way slower than the hoverboard motors (420rpm vs 730rpm at 48V without load).
After some research I found out that these Ninebot scooters run at 15s batteries, and turning apart one of the wheels also revealed that they are indeed a bit different:
(Left Ninebot, right generic hoverboard motor)
That ninebot motor (left) definitely has more copper in it than the hoverboard motors. Unfortunately that doesn't reduce resistance, it rather adds some more windings to match the higher battery voltage. Nice if you drive it with 60V but a huge disadvantage for 12s operation. More windings at given parameters = more back EMF. More BEMF means that at a given speed and given voltage, you get less current in the motor. Vice versa at a given voltage, the speed at which motor current is zero because back EMF = VBUS is less with more windings. Luckily, there is a simple solution to that: Originally, these motors are connected in Y configuration. You can simply take them apart and change to connection to Δ configuration to lower the operation voltage by a factor of root of three.
Because the hoverboard mainboard is controlled by the front wheel ESC, I added a RS485 transceiver to convert the differential control signal to TTL UART. The firmware is configured to receive data with 500Hz at 250kbaud from the front controller.
Mainboard with the MAX485 addon
For the front wheel, I didn't want to waste a full mainboard for only one motor, so I decided to use OtterControl. OtterControl is an ESC I developed about two years ago because I found the Vedder ESC to be too expensive, and hoverboards weren't that popular back then. If you're interested you can check out the designfiles on github: https://github.com/NiklasFauth/ottercontrol/ However I don't support this project any longer.
The nice thing about OtterControl is that is has more IOs than the hoverboard mainboard. WIth the STM32F303 on it I can measure two temperatures, motor current, and three spare ADC inputs. It also has RS485 to communicate with the mainbaord in the back.
The three ADC inputs are used to measure the throttle control, buttons and the steering angle because I might want to add dynamic steering using the motors in the back.
One temperature sensor measures the onboard temperature of the OtterControl The other one will be used to measure the fuse temperature. Per Hackyracer rules, at 48V a fuse with 30A current capacity must be in place to limit maximum power. To get most out of this I want to measure the fuse temperature to make sure it doesn't blow it at high currents.
(Sidenote about this rule: I do understand the point of this fuse, first to equalize different battery voltages (eg. at 12V a 125A fuse is allowed, so everyone starts with the same available power), and second for safety reasons. Unfortunately, adding a melting fuse can be a higher safety risk than not using one. For DC brushed motors, it is probably safe to use one because they are usually not controlled in fourquadrant mode (eg for breaking). This means, if the fuse blows, there is no more energy behind the fuse and everything is safe. For BLDC motors, things are quite different. Usually, you can imagine BLDC controllers as DCDC converters that supply energy from the batteries to the coils of the motor (you can literally imagine the motor windings as the inductor in a DCDC topology) for positive current (normal driving) and energy from the motor back in the battery for negative current (breaking). Especially during field weakening, a lot of energy is pumped into the motor to created a counter magnetic field that weaks the permanent magnets field to archive less back EMF and thus higher speeds. If the fuse breaks at full speed, there can be energy in the range of kilojoules stored in the BLDC motors, plus the momentum of your vehicle. As the fuse breaks, you start to decelerate, and all that energy has to go somewhere. It can't go back into the battery, so the bus voltage rises. I've seen cases where a single hoverboard motor stops at full speed while being supplied by a lab bench power supply that usually can't dissipate external energy so voltage rose to >200V . This ripped apart the bus capacitors with a big bang and of course killed every single semiconductor on that ESC. Another safety issue is that after the fuse blow you're unable to break electrically as you would normally do with BLDC motors (if you don't apply throttle, you simply decelerate by yourself). Per rules, a working mechanical brake must be in place, however I could imagine that it would take me quite a while after a big bang in my back to realize I have this option, especially if I'm used to brake electrically.
The way better option to a melting fuse is to use a proper BMS with overcurrent detection. These pcb's are available for <10€ and they brake the circuit using mosfets. This is super nice, because it protects against shorts and overload, however even in switched off state, the reversed body diode of the mosfets still allows energy to flow back into the battery.)
I'm using a throttle control from an ebike that outputs 0-3.3V. This voltage is measured by OtterControl and is used as the main control signal. This information is also sent to the motors in the back via RS485. I'm using two rather different control modes for the back and the front wheel: The front wheel is controlled in "current mode". That means I control the current in the motor, independently of the motors speed. This corresponds to a constant torque, with more or less rpm depending on the load on the motor. The back motors are controlled in "voltage mode". This means I apply a constant voltage to the motors, which corresponds to a constant velocity that is more or less independent of the load.
I do this for two reasons: First, to "sync" the speed between front and back. With the front motor in this kind of "freerunning" mode, it always supplies positive force to the tricycle, independently of the speed that is controlled by the back motors. Also, this is important for breaking. In current mode, zero amps means no torque, so the motor is basically freerunning and doesn't take any brake force. Zero volts in voltage mode, like during breaking in the back, however, means "no speed". This created high brake forces that are well spread via the solid back plate where most of the weight, me, the driver, is located. The front fork is rather weak so I do this to avoid brake forces that might brake my front wheel suspension.
So far without additional tuning: 31km/h on flat street.
Enough torque to spin the wheels.
Every single byte of firmware on this tricylce is self developed and fully open source, for the front ESC also the hardware is self-developed and OSHW.