DD-Wheel with Hoverboard Motor

You could try the ESC @RSP found. The B-G431B-ESC1 from ST is working with the firmware modifications I did for the IHM01M1. RSP had it up and running but did not use it for racing yet, due to time contraints. The board is just 18 € and available at major distributors.

Thanks for your inputs. In that case I'm hoping that I will solve my "clearance" issue with it. This could be done with a analog circuit, but I will use a ADC input and the unused half-bridge just to test it first.

@Etienne_GameSeed I asked you about 18 month ago already, but I try asking again, is there any possibility that you can share the latest source of the AIWave? The last time I wanted to change just one of the PWM output because I ordered a Micro Pro instead of the Leonardo without the knowledge that one of the PWM pins was not connected. This time I just want to try to squeeze in my BLDC code and make a "one-card" solution, even if I know already that I probably must remove the ADC reads for gas, brake, clutch etc to keep the cycle time to a minimum.

@Benu it is great to read you and @RSP had success with the board he found!
Would be possible for you to do an HowTo Guide for those stuck in deep blue water like me?

No sorry, I'm not sharing my sources anymore, I've already shared too much considering what happen to them (long story, I won't detail here). I should provide a new solution in a few month that will be much more powerful and that will be perfect for DIY. It will be closed source but I'll provide support and answer to requests.

@Benu, thanks for the info about the B-G431B-ESC1 board. The problem is that the voltage is too low to drive 36V or 48V motors.

Ok, It didn't cost me anything trying again... I'm using vJoy for my wireless steering wheel which work great. Have spent several hours trying to get some ffb data from there but with no success. The development is ended since some year ago, and from the minimal information I have found there seems that they never got the ffb to work properly. My current solution right now for the ffb is that I send the torque values directly from rfactor2 to a serial port which works perfect. But I'm afraid that solution isn't future proof. Sim-racing grows, and sooner or later I think the ability to writing plugins so you can access all different in-game values will be limited because of the risk that people can make "cheating" code with it.

Must correct myself,. Realized that it was some time since I searched vjoy. Found a updated version only 4 month old. Will check this up when I'm back home...

Couldn't wait... I connected remotely to my home computer and did some tests with wheelcheck and it actually seems that it works. I had almost the newest SDK, but I have read an old documentation before. Now I found the correct helper function for constant force and now I get magnitude values! Will write a test application and test against the real wheel when I'm back home, but as I can see for the moment it should work. If so, there is no need for HID supported hardware, just a serial connection!

I think may have too much latency with serial transfers to do proper damper/friction/inertia effects, but that's worth the trial.
You probably saw that, but I've made available again the original 0.3 FW sources, and they've been forked :
The original project I published in 2015 : http://www.electroseed.fr/downloads/ESP_WHEEL_0.3.zip
Other forks of this project :
https://github.com/fernandoigor/BRWheel
https://github.com/barsk/BRWheel

Hope this helps.

I was aware of that, have the fernando version already. Personally I have no use for it right now because I take the torque values directly from rfactor2 over serial and there is no problem at all with latency. Leonardo is limited in computing capacity, so I probably will not spend more hours on it. Sending 2 bytes over 115 kbit takes about 180 us. I actually transfer 6 additional bytes now with max rotation etc, and I haven't noticed any difference at all. rFactor2 has what I know the fastest ffb update on the market with 400 Hz (2.5 ms) rate. But you may be right, you have worked a long time with this, so you should have more experience. Thanks anyway

In fact usb virtual serial ports work at 12 MB/s (at least they do on Teensy) so it should not be limited by the speed you set when you open the port on windows (it's on boards like UNO that the serial speed is limited as it communicates with the MCU via a real serial port and with a 32U16).
The limit is the USB 1.1 full speed limit which is 1 ms minimum interval, but it should be enough, especially if RF2 updates are at 2.5 ms.

If you like to give it a try, I can send you a firmware file for the B-G431B-ESC1. That will be the easiest way for you. You can flash that firmware to the ESC, just like RSP did. You'll need the free ST-Link utility from STs website.
All I need from you is some parameters for the drive configuration. Parameters of my setup are in ( ... ).
Either you know these parameters for your motor or you can get them with Motor Profiler in STM MCSDK. MCSDK and Motor Profiler are available for free here. You do not need the full version.

1. Output voltage of the power supply (12V)
2. Encoder ppr (16364)
3. Max power of the motor (250W)
4. Pole pairs of motor (15)
5. Nominal Current (14.98A)
6. Phase resistance of motor (0.17 Ohm)
7. Phase inductance of motor (0.311 mH)

I surly need the first 2 values. The the other values seem to be in the same ball park for the 6.5 inch hoverboard motors I came about. So we could give it a try with values I used.

@Etienne_GameSeed Maybe you can help me out with some questions about ffb. I have successfully got the vJoy to work with rfactor2 that uses periodic effect, by the way the missing part in the ESP_WHEEL_0.3. The funny thing though is that the force value comes in the offset, not in the magnitude variable. Anyway it's works perfect so far with rfactor2. What I not have figured out is the Constant effect. If I test with fedit.exe, I get the correct force value in magnitude going both positiv and negative, but if I test with Live For Speed that uses Constant effect, I get only positive values in magnitude. I figured out that I must use the direction in effect report to change direction on the force, but it still doesn't work good with low forces. I also tried with rfactor1, which made me very confused. It seems that rfactor1 sends the Acc/Brake forces on periodic effect?! I also got some values in Constant effect and direction values in the effect report, but couldn't see any logic in it. I suppose you have knowledge about this, but you may not want to share because you put a lot of work in it. I also tried to find some usable information from internet, but this seems to be one of the most kept secret on the internet of some reason... Maybe it is just vJoy that doesn't work as i should...

I did a test with fernandoigors fork of ESP_WHEEL with my BLDC code included. Almost identical result as my previous test with vJoy. rfactor2 worked perfect, LFS worked but behaved a little strange with low forces and rfactor1 didn't work. the wheel just turned to right as with my vJoy application.
I have my last round in the FSR league next weekend. After that I will try to finish my build and move away from the MY1020.
Currently I'm only using rFactor2, so support for other games isn't that important for me right now. I maybe buy Automobilista 2 when it comes out. What I understand it should be based on the same engine as project cars 2, anyone knows what ffb effect it uses?

I can't really help you because I mostly tested my FFB engine with my own game engine and with fedit.exe. The latter is a bit buggy but at least you can test all the effects without interference. Regarding rFactor 1/2, I'm not sure of how they deal with FFB, as of VJoy which I haven't tested since a long time (and when I tried, the FFB part was not working correctly). What I know is that FFB in rFactor was apparently not satisfying, so a lot of players installed RealFeel plugin. There's also the LeoFFB plugin from Leo Bodnar. They probably use FFB effects differently. The trick about putting the force in the offset of the periodic effect is that you get more precision (16 bits) instead of +/- 10000 values of the other gain/amplitude parameters of DirectX FFB effects.

Thanks for your reply. I thought maybe you had some idea because I experience the same issues with your early ESP_WHEEL as with vJoy. Anyway, I have now ported my code to a esp32. It's a very powerful cpu, so keeping the cycle time down is not an issue. The weakest part in the esp32 is the ADC, but it works ok for this application. I still haven't solved the issue when I turning the wheel very fast. My theory is that the wheel produces back EMF that is higher than my 12 VDC for a couple of milliseconds. I have an idea how to solve it with measure the speed and do some proportional braking with the half bridges over a certain speed.

The variation in speed is probably because of the noisy ACS712 and/or the bad ADC input of the ESP32.

Hello everyone. I would like to offer up my semi started DD Hoverboard project to someone with the time to get it finished.
I have a hoverboard motor which has been machined and set up with an encoder as well as the XNucleo board and IHM08M1 driver. I started a thread about the project here: If anyone is interested, make me a fair offer for the above stuff plus your preferred shipping. Hopefully once a few more people have mastered these motors, I will have the time to get back in and build one myself.

I found this a while back ago https://github.com/NiklasFauth/hoverboard-firmware-hack
What I didn't realize at that time, was that they have reversed engineered the hardware also http://vocke.tv/lib/exe/fetch.php?media=20150722_hoverboard_sch.pdf

I haven't look so deeply in their code, but it seems to be a trapezoidal commutation with no current regulation.
I don't know what STM32 model the nucleo board uses, but shouldn't it be possible to port the code to suite the hoverboard hardware?

Up and running!


Was quite satisfied with my esp32 + IBT2 solution, but then I burned one of the half bridges, and the only hardware that was left in house was the hoverboard control board. Still doing som testing. The STM32F1 is far that powerful like the esp32, so I was forced to do some optimizations to my code. All calculations are done with integer now. The biggest advantage with this hardware is the current measurement part. At the same time the resolution is not optimal, but it's ok for my needs. (20 mA/bit). I have limited the output to 10 A, which is roughly 10 Nm and gives a resolution of 0,02 Nm.

Some minor modifications to the hardware was needed:
- Lower resistor value in the startup circuit to make it startup with only 12 VDC.
- Removal of som filter caps on the unused sides hall inputs to handle the higher pulse frequency from the encoder.

That's great!!
Did you have a test drive yet? How does that compare to your previous solutions, MY1020 ...?