Fisch´s Projekte-Seite

Last updated: May 2021

E-Bobby Car Controller (Teensy)




2019 I build a STM32 Bluepill Microcontroller into the bobby car as a way of centralized motor control. Controling the hoverboard mainboards via USART was very easy thanks to the multiple hardware USART ports of the STM32F103C. If my mind serves me correclty I had some minor bugs and issues which lead me to use a Teensy 3.2 in the end. Programming is done directly via USB. Hard- and software seemed to me a bit more sophisticated, .. this was enough pro arguments for me.

In the meantime the analog shoulder button from an X-Box controller was used again, but this time for the brake. Using my index finger for the throttle and the middle finger on the brake lever was very usable for me. This way the left hand is still kept free to carry stuff or to spontaneously grab tighter on the steering wheel.


As mentioned the Teensy is pretty simple and fast programmed via USB. For faster access a Mini USB Connector is build into the fuel tank cap. The "Engine Start" button is now also hot glued in place. Vibrations during driving unscrew pretty much every nut.


This is the new heart of the bobbycar, a Teens 3.2. First I thought about etching a PCB to neatly route every connection. But especially here I except a lot of changes to be made in the future. Also these are nearly all direct connections from the connectors to the microcontroller.
Most of the circuit diagram of the Bobby Car Controller is still valid. For space, usability and safety reasons I abandoned the use of the relais-hoverboard-turn-on part. Startup now includes plugging in the XT90 antispark, turning on the teensy with the "Engine Start" button followed by pressing both hoverboard power buttons.
This perfboard sits then, isolated by a plastic bag against short circuits, inside the bobbycar surrounded by a mess of wires.


After some more intese test driving the hole for the steering rod had been opened somewhat. I used this opportunity to turn a bushing out of POM to fit in the further drilled opening. A short piece of rubber tubing at the lower end of the steering rod decreased the play quite a lot. After using a healthy amount of grease at the sliding and rubbing parts of the steering mechanism the repair was finished. Before the cable coming from the steering wheel was held in place by zip ties, now 3D printed cableclips can be found in their place.




I was able to wire out a spare hardware serial port for live-debugging output. Over this I print out debugging values as csv format with variable rates up to 50 Hz. A hacked together piece of Processing software is used to visualize all of it.
I would liked to use wireless data transmission, but the HC-12 866 MHz modules didn't gave me sufficient range with only 2m. This had likely something to do with the bad positioning of the antennas at the very rear of the bobby car.


Here I plotted the commanded value "cmd" which is sent to the motor controllers (on the x axis) in relation to the resulting freewheeling rotational speed of the four motors. Here my assumption got confirmed that the front left motor doesn't turn as fast as the others. What I saw as a lower rpm in this freewheeling test showed itself as recuperation during driving at this wheel. While three wheels consume current to accelerate the vehicle one wheel puts some of that energy back into the battery. Sadly I did not achieve to build a perpetuum mobile. Rather I felt the steering always to pull a bit to the left.
Indeed the culprit looked a bit different regarding the tire profile, compared to the others. If this is really an indication I can't say for sure.
After a wheel swap the motor was still not as fast as the others, but recuperation during acceleration was fixed.


If live logging does't work at least I can record these values. For this a Sparkfun OpenLog was connected. It records data into a TXT file. Starting the teensy first prints out the header for the csv. Then the data follows for every row. With this the resulting file can be directly read or analyzed.


Here a screenshot, how visualization of a logfile looks like. The colorful timeline at the bottom serves as an overview. Throttle, brake and current are used to determine the color.


Meanwhile I went away from using torque mode at the hoveraboardcontroller in favor of sinusoidal motor control. The reason for this was that driving didn't felt as "direct" as it did without. For torque mode a current control is implemented inside the STM of the hoverboard PCB. With this mode enabled acceleration feels generally more natural, because throttle controls the power of the motors.
On of the very early versions of the hoverboard-firmware-hack implemented either communation or sinusoidal mode, where by releasing the throttle the motors did freewheel. As far as I understand this was not a feature but a bug. In all the current versions these simpler control modes brake very strongly when releasing the throttle. If I would use the throttle without further filtering/processing it would quickly result in a bent steering rod.

A compromise between direct sinusoidal control and current control would be nice. This I implemented at the teensy side. The hoverboard boards are still just used as ESCs.
The idea was to use the throttle value during acceleration (new poti value > old poti value). As soon as the throttle is lower than the current commanded value to the motor controlers, the speed should be reduces slowly to "simulate" freewheeling. This "simulated freewheeling by constantly reducing speed" pushed me unerringly into the wall. Braking with my feet was ignored completely. Information about these external braking forces can be obtained by looking at the motor current. As soon as the current increases the sent value should be reduced faster. Both of these ideas were implemented. Mainly to make sure that if for some reason current can't be measured acurately or sent to the teensy braking is still possible. Because therese now a braking lever available it's position is used to scale these calculations proportionally.
Now slow-paced and not so slow-paced driving was again possible. Freewheeling was working perfectly, only braking was mostly very abrupt. Lowering the parameters for braking resulted at the same time in a longer braking distance when trying to emergency brake. I reckon the cause to be the delay between hitting the brake until the motors finally slow down enough to feel it. A solution could be to allow the current control to raise the speed values. This however would lead to an implementation of full current control like it would be with torque mode.
The principle of "ducking", as known from music production, helped me in this case. Applied to the bobby car this means further lowering the speed value when pushing the brake lever, but only temporarily. Releasing the brake restores some amout of the speed value. Initial braking is not changed really, but the motors do not slow down as much as before when releasing the brake early.
Lastly I applied an exponential curve to the brake position and it now drives better than ever.


10 Ah Battery

Since the bobbycar is now working again I took it out a few times for a ride. The values for maximum current and thus power shouldn't be too different from what I had a few years earlier. But the controllers were starting to beep very early because of low voltage when going faster even though the battery had just been charged up. Looking at the log files the voltage starts at around 49V (4.1V/cell * 12 cells) but drops below 42V during acceleration. It was possible to drive a good amount of time this way but since I used old hoverboard 18650 cells it was time for a new battery pack.

I really wanted to go cheap and rip apart an e-bike battery or something but haven't had any at hand. Looking forward to a fun summer I bit the bullet and bought a bunch of refurbished LG ICR18650-HE4 2500mAh cells from nkon.nl. To have a drop in replacement I again went for two packs of 6S4P which sums up to 48 individual cells costing almost 200 €. Thats more than the whole bobbycar so far I think, Ouch!


Placement and routing is the same as the first battery pack. This time I added some protective sheets betweend the cells that have not the same voltage potential on their metal casing. Also covering the finished spot-welds when placing a new nickel strip is a good advice. Shorting the wrong things really can end in a nasty fire.


I added some foam to protect the solder connections and surrounded everything with tape. This battery pack has now twice the capacity as the last one and is theoretically capable of delivering 80 Amps (4P * 20A). The bobbycar is software limited to 2*15A = 30A.
A quick driving test showed that with the voltage staying at 47V at full throttle the maximum speed was 38 km/h instead of 32 km/h. Not that speed increase was my goal in the first place.