DD-Wheel with Hoverboard Motor

Did some test drive last night. The only moment I can feel a little torque ripple is when I turn away from the force very fast. I also had issues with the encoder missing steps when the wheel spin very fast. Until now I have solved it with continuous sync against the hall elements, but I have already new code working that uses the stm32:s built in encoder/timer function. I wont be home for about 10 days, but I may make some video when I'm back.

I also tried to generate some SVPWM sine curves, but that didn't make any difference, maybe slightly more torque ripple...
(The PWM is mid aligned...)

The biggest difference to the MY1020, is that I realize now that the force is quite unlinear with the MY1020, because I don't have any closed loop to control the current. I always raised the caster on the cars to get more resistance when turning the wheel, but on the other hand, hitting kurbs felt to much... Now I lower the caster...

Such a shame that I spent a lot of time building my own hardware when I had the perfect one laying in front of my nose. although I didn't know that the official stm32 core for arduino was that good. The whole HAL library is exposed, so you can use STM32cubeMX for setting up the hardware and at the same time you can write simple arduino code.

https://github.com/stm32duino/Arduino_Core_STM32/tree/1.7.0

The latest 1.8.0 didn't work in Visual Studio/Micro. but 1.7.0 did. (1.8.0 worked in the standard Arduino IED)

Just thought about this the other night when I saw Vedder putting an encoder on the VESC hall sensor input. Very interesting indeed!
What do you flash the hoverboard card with?
(sorry if that was made clear in an earlier port, maybe I just didn’t understand)

super cool build!

I'm flashing the board with a ST-link V2 adapter. The firmware is now mostly made by myself. I began with this: https://github.com/NiklasFauth/hoverboard-firmware-hack just to see that I could compile HAL code in the Arduino/Visual micro environment and get it to work. After that I have used the STM32CubeMX software and almost rebuilt the project from start. I'm using vJoy as interface to the game. (Currently only rFactor2 works 100%, but I think I have found the problem with constant force with direction data now)

Thanks for that!

There is a fork from that FW that implements FOC control and one that implements PWM control. If those could be combined with your encoder FW, that would be the perfect match for an MMOS..

I have already implemented my own code with sinusoidal commutation and PI loop for the current. Unfortunately the hardware supported PWM input pins are already used, so a PWM control may require a interrupt driven task (Maybe it's possible to use two Capture compare channels, but I haven't looked into that so deeply yet...), but may be doable if you set the PWM frequency to 2.8 khz in the MMOS. My plan is to take a Arduino micro Pro for the USB to Serial part, and than it can also be used to convert the PWM signal from MMOS.

What are you using the inputs for? I guess you mean those where the two gyro boards used to be connected, right?
The second (unused) hall sensor connection can’t be used?
PWM seems to be an impractical signal to receive on uc’s.. It could also have to do with my highly limited knowledge..

I'm using the unused hall sensor inputs for the rotary encoder. I still have the second uart free, but neither of this are connected to pins that supports hardware pwm input.
But as I wrote before, I need a USB to serial converter anyway for my use, and if I let a Leonardo Pro micro serve that task (Or better a STM32 bluepill that on it's way to me), I could implement the pwm input there also. My hope is that I can solve everything with vJoy, and than there is no need for the MMOS. It's already working perfect with rfactor2. The only backside with vJoy is that the ordinarie developer doesn't work with it anymore. But what I understand, other people have made changes just to keep up compatibility with Windows 10 updates.

Some update of my (un)progress:
Was quite happy with my simple sinusoidal solution, and actually did an online race with it. Then the day after when I started to drive again, one of the NFET (high-side) drivers fried... My theory is that it fried because I used only 12 VDC. I read something on the github page where I got the hoverboard hack that the high-side NFET had 15 VDC source for the gates. (The NFET driver is built with discrete components) So I changed to 24 VDC after that, and connected the motor to the other side. Unfortunately, the DC current wasn't near that good as it was on the first side, the noise was more like it was on my esp32 solution. So I downloaded the FOC version, which is a fork on the first hack, and compiled it in the arduino environment. It works very good, except on very high forces, the torque ripple get high. (It's not sinusoidal commutation) . The last week I have gone deep into the stm tools for motor drives. I realized that it should be possible to use their tools to make a sinusoidal FOC firmware for the hoverboard circuit. I got some help from Benu, but it wasn't that easy to get it work like I expected, probably because of some bugs with custom boards. When I started with a standard board, I started to get some progress, but then I fried a NFET again...

I have decided to stop working on a solution for the original board at the moment, and will order https://www.st.com/en/evaluation-tools/b-g431b-esc1.html . That board is actually cheaper or at least same price like a hoverboard circuit board. Hopefully, I will not frie any more NFET:s before I get that card...

The decision to stop is mostly because I'm not 100% sure why the NFET fries. They are very powerful, and haven't even been near hot when I have driven for over a hour. I have also limited the current to 10 A.

If someone is interested in the FOC version, I may clean it up and share it. There is not possible to make a good pwm input solution, because the available connections is not connected to a hardware-pwm-input supported pin.
Therefore, the only solution is to send the torque value by serial to the card.

Would the FOC version accurately control a stepper motor? I've seen so many stepper projects get started, but they seem to hit a wall at some point and are abandoned.

The solutions discussed here would not work with a stepper motor.

While waiting for the https://www.st.com/en/evaluation-tools/b-g431b-esc1.html I could not stop myself continue working with the original hoverboard circuit board. I took the ADC configuration from The FOC fork https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC and used the current inputs that uses the NFET:s RDS On as shunts (2 phase measurement which gave me a lot more resolution) together with my PI loop and the result was very similar to the FOC fork, but still had some torque ripple despite the sine commutation. I must admit that it was more luck than skill, but I just made a half sine wave curve in a array that I use to compensate the current measurement every 60° of electrical angle, and almost all of the ripple is gone. When I realized that I finally had a acceptable solution, I started to fine-tune the PI loop. What surprised me a lot, was when I had tuned the loop so I reached the current setpoint in about 1 ms, the wheel went useless when driving with it. It was just to much noise and rattle... Then I went in the opposite direction and made everything slower. So now it needs about 10 ms to reach the current setpoint, but it feels great driving with it. All the details is there but at the same time smooth as silk as long as I keep the car on the tarmac. I have already started to clean up the code, and will probably merge everything in a single ino file so people can work with it in the standard Arduino IDE. Visual Micro is no longer a "free for non commercial use" software. (I finally bought it myself because it's a very good peace of software...)

That's a really good progress!
So the original hoverboard circuit boards are indeed usable for our goal. That is nice.
Eager to hear how it compares to B-G432-ESC1.

The solution is still not perfect, the torque ripple is there on higher torque values, but I'm satisfied with it. I still haven't received the https://www.st.com/en/evaluation-tools/b-g431b-esc1.html board, so I probably will wait with the switch until the next season (racing league).
Anyway, here's the code. Maybe someone have some idea to improve it. The current calculation for example may be incorrect, and may be the reason why I have the torque ripple.

https://drive.google.com/open?id=1uyBBD_m-eVHD08xK0WUsiY5y-lVQBOJ-

(I wasn't able to make it compile in the Arduino IDE, so you need Visual Micro and Visual Studio)

Finally a video of the final solution. I haven't checked the max torque, but the max current is about 6 Amps like I have it now and I see no need for more. As I told before, it got much better when I slowed down the PI loop. I searched a little about it, and it seems like the most DD wheel ("Real ones..") owners must put some FFB smoothing in rfactor2. My current rfactor2 setting is 0.25 multiplier and 3 in FFB smoothing. I tried to go back to a more aggressive PI loop setting, and increased the smoothing in rfactor2 instead, but the result was the same.

I realize that the PWM input solution in my code can be done usable if someone want to use it together with MMOS. I configured the interrupt with "arduino" code, but if you do it the "HAL" way, you can configure the PWM input so it interrupts the ongoing DMA interrupt, and that should solve the glitches I had. The https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC do actually have code that could be modified for this purpose. (Cleaned it out quite early and didn't think so much of what it was ment for...)

https://photos.app.goo.gl/G93A1xHfnviVtgZ66

Benu:s solution up and running with the B-G431B-ESC1 card. Just did some short driving test and tuned the PI loop similar to what I have in my own solution, but still need to solve the problem with PS tripping because of Back EMF. I think the easiest way is to just change to 24 VDC, but the one I have is kind of noisy. I have som laptop power adapters that should be enough if you connect two of them in parallel. The output is about 19 volt / 5 Amps, so it should work quite well. Currently I have limited the max current to 10 Amps, which seems to work pretty well with the small cooler I have attached.
The OVP diodes works, but it's no long term solution. Burned a couple before I changed to 24 volts...
A reverse diod against the PS is a alternative solution, but I think I need a big capacitor then, otherwise the voltage may get so high so it destroys the electronics on the card.

The impressions so far is that is better than my solution because of the no existing torque ripple, but on the other hand, that's nothing I notice when I drive. The biggest drawback with this card is that it seems to have some strange behavior with the encoder input. The input A pullup voltage drops from 3.3 volt to 2.2 volt when the motor activates, and messes upp the encoder reading. I solved it first by activating the built-in pullup first which worked, but I changed that to an external 10k resistor just to be on the safe side. (The built in is about 40k I think) I bought two cards, and both behave the same. The other thing is that is much smaller that I expected, and it was bit of challenge to solder the wires for the encoder. No holes for mounting, so I printed a holder which is better than nothing...

So Finally made the brake resistor circuit. This is the final solution, and I'm 100% satisfied. Have tested drive over 1 hour, and the small cooler seems to do the job. I have limited the current to 9 A.

That looks like a great solution! Very small footprint. The IHM08M1 + Nucleo board needs more space and is more expensive.

Found such a fella )

https://www.solomotorcontroller.com/solo-specifications/

• Wide input voltage supply range starting from 8V to 58 V
• The continuous output current of 32A, Max Current of 100A
• Capable of controlling DC, BLDC, PMSM and ACIM motors
• Over-current, Over-voltage, Over-Temperature, Under-voltage and Reverse Polarity Protection
• Selectable output PWM frequency from 10kHz to 80kHz
• Automatic self-tuning and identification of Motor parameters
• Open-loop or Closed-loop Control modes
• Speed, Torque or Position control
• Advanced Sensor-less and Sensor-based Control
• Advance Field Oriented Control
• PWM and Analogue voltage input for Controlling Speed and Torque
• USB, UART, and CAN protocols enabled
• SVPWM modulation
• Encoder and Hall Sensor Input with +5V supply
• +5V/1A (5W) output to supply external modules
• Updatable Firmware
• Heatsink mounted on the back of the board to enhance the thermal behavior
• 1820µF onboard BUS capacitance

Is there any chance you could post up details regarding the wiring and code for your setup?
I just created this post with my build and really need to sort out a motor driver for it. Any input would be appreciated
https://www.xsimulator.net/community/threads/3d-printed-hoverboard-motor-wheel.14454/

This may be the most perfect cheap direct drive solution
If the full settings are announced, I can't wait to try to make