There are 3 projects that were successfully able to use the split ESC type. My ESC’s look a bit different then the ones in this project, so I’m going to verify the pinout and then try to modify the code to work. https://github.com/flo199213/Hoverboard-Firmware-Hack-Gen2
1 Like
Yes, I managed to flash this code and was working but every board is running only one motor, and for onewheel application they should be pretty sync, i didn’t try it yet but I am planning
1 Like
Do you have a working code for the single motherboard with 2 side boards version?
I flashed mine, but now my onewheel doesn’t work and I can’t find a code to flash it with to make it work again
@bula87
I think these boards (1 main board) are the best choice, and the price is good in our city for $10
5 Likes
Lol why is that pictures look so funny to me 
3 Likes
Sorry I was at long holidays, but I am back, today I bought another hoverboard with single mainboard. I am giving it the last chance, if it will explode again without any reason I will give up and buy VESC 
1 Like
Hello,
I have found this https://github.com/bipropellant/bipropellant-hoverboard-api . Has anyone tried to implement it for onewheel purposes? I am currently trying to find a way to use everything from hoverboard because prices skyrocketed for electronics and therefore there is no possibility to buy VESC… It would be great if there were understandable code for sideboards that we could modify with better balance features and control the angle/speed.
I remember that I tried this code but there was something wrong with it. Don’t remember what but in the end I gave up. The code for sideboards from official FOC firmware is pretty clean and there is a lot of cpu power to add more features
Well, my programming skills are not that good so it is kinda hard to experiment 
Currently, I have one sideboard which is connected to both inputs of the motherboard. So you are saying that I could flash the motherboard with FOC firmware as well as my sideboard and try to modify that sideboard firmware (from FOC GitHub for sideboards)? I would leave it as it is now, but it is very inconvenient to drive as for higher speeds the board needs to be at a pretty aggressive angle and it can nosedive anytime…
For now there is no any officially working balancing algorithm for foc firmware, so for now better to do not experiment with it, if my hardware won’t explode again, this weekend I will work a bit on this.
2 Likes
6 Likes
@bula87 look at it (“Arduino code” and “Side Projects”(lite version))
https://www.cammservices.com/projects/onewheelboard
it’s interesting to get data output from arduino to hoverboard, what do you think? in his program, the nose of the board rises when picking up speed
… or adapt this code to stm32
1 Like
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.
1 Like
@Zuen You’re right, it’s interesting to look at it. I think it is necessary to post the code on GitHub and what you said today to make an additional topic on GitHub. Together we can finally master this new firmware mode - OneWheel. If I can help in any way, please tell me.
Dear Vfear,
Will upload the firmware to my gh and post the link asap. I’ve seem to have hit a bit of a bump with proceeding with the FOC firmware. I wanted to flash the sideboard first, had a spare one so tried it (had an stm32f103 on it), unfortunatly i could not erase the chip, JFlash lite would not allow it. I suspected voltage issues, rewired some stuff, and ended up accidentally touching the 12v to the 3.3v line, and fried the sideboard… Then took a spare hoverboard, that one had the GD32 IC on the sideboards. Unfortunately same issue, unable to erase the chip.
Would you happen to know a solution to this issue? I’m using a jlink edu, and my sideboard is blue, with a green radio ic on a separate pcb that is mounted on the sideboard using headers. Silkscreen says: 2015.11.30 Ver 3.0
These are the main boards I’ve started to rewrite code for. That have the GD32 IC’s, if you have any interest in reprogramming them or helping rewrite some code base I’d sell you a set of ESC’s real cheap. I have 10+ sets that I want to turn into onewheel and go kart type projects. From what I read I thought it was best to use a st link and the st link application for flashing?
I suppose it might be better not to use the original side board for balance, but it would be better to make an external mpu6050 with a controller and send data via uart. Since I realized that there are compatibility issues with the side boards. Not all models of side boards are flashed, said the author of EFeru Foc. And this part of the program was never completed.