Project start: January 2019
Last updated: July 2022
Since the Bobbycar
now works I wanted to implement more features like differential steering, esp, abs etc.
Because two hoverboardcontrollers are used to drive the four wheels and I didn't want to mess around with critical parts of the software I am probably going to use a separate controller to control both baords via serial.
The bobbycar is rather compact on the inside and it gets really difficult to change things around a lot.
Together with the fact that it surely wont't work the first or second time a new vehicle as a platform to experiment and test out different things seemed like a useful idea.
Using a plank and attaching wheels to it was already implemented in the "TranspOtter"
Like the TranspOtter my Hoverbrett can be used as a vehicle to transport things, but also to test out concepts of control systems engineering and robotics.
It can't get much simpler than mounting the aluminium frame together with the two wheels/motors under a plank.
With the swivel casters in the front the mechanics are finished. Later I will evenually rebuild this, but for this is has to be able to drive first.
The mainboard of the hoverboard, which contains both motor drivers, was put in a case of an old arcor router. The elkos didn't quite fit, thats why they now stick though the top cover.
It will be controlled by a STM32F103C "Bluepill" in a D-Link accesspoint case.
First I successfully used a FrSky RC Receiver, but I then went for a NRF24 because I wanted to build a very small radio.
The battery is the one from the Hoverboard (10S2P) which had to go on top because it didn't fit underneath.
Under "hoverboard firmware hack"
I described how the STM32 on the hoverboardmainboard can be reprogrammed. The Software can be found here: Github NiklasFauth/hoverboard-firmware-hack
The afore-mentioned radio should be as small as possible.
On the search for a small joystick I noticed the lenovo "nipple" (I think they're called Trackpoint).
I got one from a broken Thinkpad, thanks to Fionera.
Obviously I'm not the first to reuse this superb input device: Github feklee/usb-trackpoint
The module was not exactly the same. I got the correct pinout from martin-prochnow.de
Data for x and y movement are transmitted as 8 Bit values each over some proprietary serial protocol.
To read the data from the trackpoint and send then wirelessly via a NRF24L01 module I used an Atmega328 with Arduino as a Pro Mini at 16Mhz.
With its needed additional components, a selfholding power on circuit (like the one I used for the lightmeter
) and two transistors forming a touch sensor it got tight with the layout.
I wanted to etch the PCB myself and because the bottom side needed to be flat I designed some bridges to use enameled copper wire.
Together with some footprints that didn't quite fit it is only about 10% botchy.
Coating raw copper with photoresist and expose and etch them is really easy. Documentation here: wiki.ctdo.de
For the Atmega328 the arduino bootloader was needed. For this I soldered on some wires to connect an usbasp. Further software changes can be flashed as usual via serial. For this there is an header on the side. Link to the repository for software and pcb at the bottom of the page.
The trackpoint and the NRF24 module were then attached. A 820mAh lipo with the ubiquitous 1S lipo charger module are connected from beneath.
Next a case was needed, on which I haven't spent any thoughts yet.
The result was a bottom part out of pcb material with two separated copper parts. These will be used as touch sensor to sense, if the remote is still held.
2mm plexiglas was lasered to make up frame parts which got stacked and glued together with superglue.
With the battery at the bottom and the circuit board on top the top cover came at last. To attach it to the rest hotglue was used so it can be removed later by heating it up a bit.
At last I sanded the sided carefully on the belt sander and finished them with fine sandpaper manually.
The radio has two buttons. The lower one turns the thing on. The upper button can be used for changing modes and for turning off.
Everyone who has tried it until now confirmed that it is really intuitive.
I just built a 12S6P Batterypack
out of old E-Bike and Laptop cells.
This got a bit bigger than a typical hoverboard battery, which made it necessary to move the router and accesspoint aka hoverboardmainboard and controller.
I also didn't like the way the wheels are higher than the actual board.
Some wooden pieces between the board and the boverboardcase fix this problem. At the same time a perfect place for the routercase was found.
The batterypack in the green box is held in place by a metal bar. The four pins of the box sit flush in some holes in the board, so that it can't slide around.
As soon as I plugged the 50V Battery in one of the electrolytic caps of the hoverboardmainboard exploded. After that I measured 50V at the output of a 15V stepdown converter, where once the 25V cap used to live.
I assume the current of the added controllers with their added capacitors was too much.
Now a LM2597HVS is added to get from 50V down to 5V and from there linearly down to 3.3V as before.
Also a XT90 Antispark can now be found to reduce the spark-factor when connecting the battery.
Like the principle of a Transpotter
my board should get a gametrak-string too.
For 15€ incl. Shipping I got a Gametrak Controller. The Gametrak was a VR attempt for the PS2, which makes use of two fishing lines attached to gloves.
Direction is measured by a joystick like mechanism, length can be obtained by a roll-up mechanism and a potentiometer attached to it.
For a Transpotter on of the halfs of the gametrak needs to be disassembled and the white module to be taken out.
After measuring the pinout, I extended the cable and connected the three outputs to some unused ADC inputs of the STM32F103C microcontroller.
- Brown = GND
- Green = VCC
- Red = Vertical
- Orange = Length (rolled up is near VCC, extended near GND)
- Yellow = Horizontal
The gametrak module is mountet at the front. Most of the time the rope is pulled out upwards. Because of that is it advisable to angle the module a bit.
A recess in the board should save the thing from breaking when driving into a wall.
If the remote is powered off, the board can now be pulled. A simple proportional controller is implemented to set speed and direction.
Driving backwards is possible, but makes it hard to turn it off again.
It doesn't always have to be the full blown 1/2 kWh battery. A standard hoverboard battery fits also with a bit of packing material.
And again a new usage: transporting rc flying stuff.
Fast forward three years (2022) the potentiometer from the gametrak controller had to be replaced. Scratching potis are common place in audio devices, but when they are responsible for controlling the speed of a driving platform they can be dangerous.
I noticed this by paying the prices of a few broken bottles of beer when it suddenly started braking and accelerating.
In industrial applications DPDT (Double Pole Double Thow) switches are often used for safety relevant functions, such as emergency off, acknowledgement buttons or safety fences.
One physical button operates two mechanically and electronically independant switches. If the signales received at the controller differ by a certain amount an error is triggered.
Applying this to the gametrak means to use a stereo potentiometer and routing the signals of the wipers to two ADC inputs.
In software filtering can therefore be improved but more importantly a (soft) safety off can be initiated when the analog values are too far off.
After impoving the gametraks safety the remote control had to be taken care of next.
When holding the nipple to the top right corner for a few seconds the read values sometimes got "stuck". Rather inconventient when you're sitting on top.
The fix was to reduce the polling frequency and adjusting the transitting frequency accordingly. Confidently I sad down, drove 1-2 minutes around until it drove me uncontrollably into the wall and sitched off shortly after.
Gone was my confidency again.
The time until the board switched itself off correlated to the TIMETOUT, configured in the hoverboard firmware. The behaviour could be replicated by disconnecting the STM32 bluepill controller.
Suspecting a defective LM7805 (supplying the Bluepill) I desoldered it from the perfboard when one of the legs fell off. Aha!
Who knew that a free hanging TO-220 and an attached heatsink can't handle the vibrations from driving outside.
With the bobbycar I recently replaced the Bluepill with a Teensy 3.2 and this was now the point to let the hoverbrett follow.
As classy as the arcord router and the D-Link accesspoint cases are, they had to go as well.
With some 3D printed spacer parts the hoverboard mainboard fits quite well in a bought ABS box. The air between the aluminium plate and the bottom is there for better air cooling.
Power button and a XT60 connector are attached on the left side. 5V from a HV Step-Down for the Teensy come out the other side.
Later I discovered that the mosfets were getting quite warm, such that the board starts beeping above 60 °C. The board temperature is measured at the STM.
With the closed box without any air ventilation it was next to impossible to get it to cool down.
Therefore two 5V 40mm fans were mounted inside the box. I have not tested the temperatures with enabled field weakening or phase advance.
To protect the wired to the motors from getting caught on something on the ground a PET foil is screwed to the hoverbard chassis.
The dimensions were drawn off the board with a paper sheet and a pencil. Drawing Download (Dimensions are not exact!): hoverbrett_hoverboardbase_cover.svg
First the Teensy 3.2, the NRF24 module and an OLED display were attached to a perfboard.
Latest Code and Kicad files for the controller, remote and own changes to the hoverboardhack-firmware: https://repos.ctdo.de/interfisch/hoverbrett