Hi All
I’ve used the bipropellant firmware to flash the hoverboard controller of my self build onewheel. The onewheel uses two joined hoverboard hub motors. The bipropellant firmware did indeed seem to have some issues. I ended up removing most code, rewired some phase and hall cables, and then the motors started spinning 
Although the codebase looks big, the ‘hoverboard’ functionallity only comes down to one line in main.c:
pwms[i] = CLAMP(dirs[i]*(sensor_data[i].complete.Angle - sensor_data[i].Center)/3, -FlashContent.HoverboardPWMLimit, FlashContent.HoverboardPWMLimit);
That is technically only proportional control so, angle == speed.
There are a couple of improvements that i’m experimenting with that should mimic the onewheel more (although i’ve never opportunity to ride one). One of the things i noticed when riding with the original hoverboard firmware and the bipropellant firmware was that you have to keep the nose down to maintain speed, this leads to a rather uncomfortable drive. Quick fixes like multiplying the measured angle by a number will allow you to reduce the amount of tilt required for a given speed, but the board will feel ‘stiff’ afterwards. Giving it an offset tilts the nose, but then the board wants to keep you at that angle, also not nice. Maybe the following could help, and looks to be in line with the Arduino firmware from the latest post:
- pid control of the angle, output is acceleration (not speed!)
- pid control of the speed, output is acceleration (not speed!)
Then summing the outputs of both pid’s yields a number that can be added to the current motor pwm. The desired ‘throttle’ is determined from the I component of the balance control pid.
With initial tweaking, i found that the board was quite ridable, and when the speed loop picks up, the board changes in feel from skateboarding to surfing. This system acts like a horizontal cruise control, with the added benefit that the board becomes relatively terrain independent. The same nose tilt for the same time will give you the same speed, regardless of terrain/motor effort. Another added benefit is that the motor will maintain roughly the same speed, even when not touching the ground, so landing a drop becomes way easier.
Pushback is implemented by looking at the pwm duty cycle (and motor speed). The balance algo simply gets a new target angle 2 deg instead of 0. This raises the nose.
My findings after a 10 km test run: the sinusoidal control (3rd harmonic) from the bipropellant firmware makes the motor feel as if its ‘grinding’ all the time, like the board encounters friction (motors do not heat up, and spin near frictionless when not controlled), accompanied by a hum sound. Only after a certain speed, it seems to change drive settings and becomes butter smooth and silent.
The board is still uncomfortable to ride past 10 km/h, for some reason, you ‘feel’ that the board will not have te power to keep you balanced, im not sure if this is true, because pushback was not activated at this point, so i had at least 10% duty cycle left over, technically enough to balance at speed, given no unexpected humps.
My hypothesis is that the feeling of the board is due to the way the motor is controlled. FOC in torque mode should give more torque at higher speeds, and allow you to ‘coast’ smoothly because the motor can be left freewheeling.
What I will do today: take the FOC branch from Bula87, and port my current code from the bipropellant repo to this one. It should give FOC torque mode, the control loops should be able to remain the same, except for the pid values.
Let me know if anyone is interested in the bipropellant software version, ill put it on github then.
Will give that combo a try this afternoon.