DD-Wheel with Hoverboard Motor

Had som time this week to do some tests with the encoder instead of the builtin hall elements. Unfortunately the encoders 2000PR doesn't fit this motor well with it's 15 cycles/turn so I was forced to use floating point math instead of integer calculating the commutation. A 1800PR which is available from the same store on aliexpress had been great. Maybe I order a new one in the future... I might go back to using the hall elements for the commutation for now when the tests so far shows that the resolution I get with the encoder isn't needed for it. A benefit from using the builtin hall elements doesn't need any sync routine which I played with a bit yesterday that I'm not 100% satisfied with. (Probably easier to use the Z output from the encoder, but that didn't come to my mind yesterday...) Maybe anyone of you have some Idea of how to do that correctly. At least this motor is strong! I mounted a 500 mm arm on the wheel and it gave 2.8 kg on that distance, which is 2.8 * 0,5 * 2*9.81 = 13,734 Nm! The code is kind of a mess after lot's of tests so it need to be cleaned a bit before sharing it. When I did the torque test I also realized that the code my need some function to linear the force, at least in the lower output part. I also have some more parts to print out before I can fit the wheel, and right now I'm waiting for a new gear to my extruder so I cannot do any ingame tests yet...
https://photos.app.goo.gl/9aAeSzYU9SwcugKG9

Went back to using the Hall elements in the motor. No reason to use the encoder for the commutation, it works just fine with the hall elements. The motor seems to be stronger one way which I cannot explain right now... Did some more serious torque test just to check the linearity, and maybe that is not a big problem, but I think I must compensate for the uneven torque in the different direction.

https://photos.app.goo.gl/7zDNCYjDZDERoPWn9
https://photos.app.goo.gl/A3UY89epb7T9Ge8c6

@Benu Did you test the torque in both directions? My motor seems to have better torque in one direction. Have tested to tune the commutation in both direction to check if I have bad commutation, but I only loose torque no matter what direction I go. Seems like I end up with some function to correct this. I'm not sure if I can run a PID cycle fast enough in the Arduino to make a closed loop with current measuring.

Hey @danove_b spotting IBT twins in the pic.
How did you wire them?

Nothing special about the wiring. You use on half of the two half-bridges on each card for each phase. For example,
IBT no 1:
Phase A: PWM pin to LPWM, Motor cable to M-
Phase B: PWM pin to RPWM, Motor cable to M+

IBT no 2:
Phase C: PWM pin to LPWM, Motor cable to M-

Wire all the Enable (R_EN, L_EN) together. I guess you can put them directly to 5v, but so far I have an output for them on the controller. There may be some glitch during startup of the controller that can make the motor react a very short time.

All VCC:s to 5v
All GND to 0v

Some feedback on my progress with the Hoverboard motor:

Finally did some real tests with torque values coming from a race simulator. I must admit that this was a bit harder that I thought, and I must honestly say that I'm not fully satisfied with the outcome so far. The MY1020 is still a better/more realistic feeling. I'm not sure if it's my software or if it is the character of this motor that's the biggest problem.

First test was done by just converting the torque signal from rfactor2 to proportional voltage output just as in the code I posted before. The result was far from impressive and it come very clear what the problem was. If I compare it to my brushed solution with the MY1020 that will spin up to a higher speed during some short time if I put a fixed lower voltage on it, the Hoverboard motor do not. It goes directly to a slow fixed speed.

Second test was done with a closed loop to the motor current using a PID function. This was much better, but still not in level with the MY1020 solution. The speed of the motor is still missing. Again, is it my software or just the motor character?!?... I tried to tune the PID konstants, but that didn't make any big differens. The biggest change to the better was accomplished by going down as much as possible in the PID cycle time. About 250 micros is the lowest possible currently. Maybe I could clean up the code a little by going to my first idea with multiple tables instead of doing floating point math every cycle...

Also in both tests I must put som filter on the torque signal, because the motor just went to loudly otherwise.

If someone have any ideas, you're welcome...

Some final thoughts:
- I may try with a higher supply voltage to accomplish higher speed. I have a 24v 20A somewhere....
- Maybe the Leonardo is a bit slow in the end for the PID loop. I have lots of Esp8266, but there is no option for differential ADC for measuring the motor current. I need to build an external amplifier for that...

- Is there any magic in the commutation that I have missed? I'm quite sure it's enough to use the Hall elements, The only differens is there is a small glitch when you turn the wheel with applied force and you pass a hall element, but the current doesn't change that much. I realized that the whole sine curve wasn't needed, so I simplified it. That didn't make any differens, just to keep the code cleaner and more understandable.

//Forward
const byte sine6_ph0[] = { 0, 0, 127, 255, 255, 127 };
const byte sine6_ph1[] = { 127, 255, 255, 127, 0, 0 };
const byte sine6_ph2[] = { 255, 127, 0, 0, 127, 255 };

//reverse
const byte sine6_ph0_r[] = { 255, 255, 127, 0, 0, 127 };
const byte sine6_ph1_r[] = { 127, 0, 0, 127, 255, 255 };
const byte sine6_ph2_r[] = { 0, 127 255, 255, 127, 0 };

After looking at Benu:s video, i removed the filter function. Maybe I'm just use to the MY1020, and this wheel is better in the end. I had never had chance to drive this kind of car for real... But if you look at wheel, it reminds a lot of what drivers in Indycar have to deal with...

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

IndyCar:

Really good work it's a good solution I thing that the problem are the IBT_2 some people are complaining that it's not precise especially in the current output. If you try to use the simulator with your custom board that I see in another video in this thread ?

The board I used before has the same half-bridges, so there is no difference. The only thing with the IBT-2 is that you can't go that high in frequency on the PWM, but 8 khz seems to work just fine.

I have done som more testing with my hoverboard wheel and I'm afraid that it is the duty cycle for the PID that is to high. For "normal" driving without to much oversteer it work quite well, but if you got some snappy oversteer when the wheel want to move very fast to the right and to the left, then it cannot control the current correctly. I can feel in the wheel that it probably start to oscillate and also hear the "unsmooth" sound, and the power supply trips... I tried to find some information about this kind of PID loops but no luck yet. The torque information from rfactor2 has an update cycle of 400 Hz, so my guess is that the PID loop needs to be at least 50 times faster (20 khz or 50 us). I also noticed that my current cycle time goes up to 350 us when the input torque is higher. I guess that the float operation time varies depending on the numbers.

Update:
To use the differential ADC function I found some code from Internet that I supposed was correct seems like it give some nonlinear values. May be some hardware issue also. Anyway, this is positive...

Stupid of me, kind of... A differential input is not a galvanic separated input...
ACS712 module ordered! First time I'm gonna test a hall effect current sensor. Will be interesting...
https://www.electrokit.com/en/product/current-sensor-acs712-20a/

With this sensor I can switch to the ESP8266 if I need to shorten the cycle time.

@danove_b Well, sort of. During testing I used both directions for torque tests but never made a test series to compare input current and output torque for both directions.
If you are interested I can do a test sometimes next week.

Thank you for offering your help, but since I realized that I need to solve it with a closed loop it's not a important matter anymore. I also realized that I never gonna have use of the max torque this motor can offer. Maybe if I put a full size steering wheel, but as long as I keep my old 250 mm Momo wheel I don't need it...

Do you have any idea of what cycle time the motor control library you use have? I think I can optimize my code down to maybe 0.1 ms with integer math in the PID control by up scaling the parameters, and then use one float operation to normalize the output value. An alternative to normalize is to go back to my initial idea to use look up tables for the PWM values.

I agree, you will not use the full strength of the motor unless you are using it to build your muscles.
The wheel rim I use is a 30 cm DIY wheel. Max torque in motor driver board is set to 8 Nm. In-game gain is set to 75%. That is enough for me. I like the quick response more than the available torque.

The PWM loop is running at 30 kHz and the torque/flux regulator runs every PWM period. That should be 0.033 ms period length. These are the drive settings from ST Motor Control Workbench:

That's was very valuable information, thank you. My first thought is that the BTS7960 my be a bottleneck. They doesn't work that well going above 15 khz. My current PWM frequency is 8 khz. The fast PWM in the 32u4 doesn't give you so many option, either 7812 Hz or 62500 Hz according to what I found in the code I found on the net. Didn't think of that earlier, but with the current PWM frequency I'm not helped by a faster cycle time than 128 us...

But what if you'll use 62,5kHz and execution set to 2 PWM periods? If I understand it correctly it should give you something like 31,25kHz resolution which is 3us... Of course if BTS7960 could handle it.

You are welcome.
The Leonardo has some more PWM modes for timer 1. This is a nice blogpost on capabilities and how to unleash them. You could use 15625 Hz or 31250 Hz and would be out of the audible range.

Hello there folks, sorry for my terrible in nowadays I get my 10-inch best hoverboard for kids wheel with a 350w engine and I attempt to utilize the IBT_2 for control the engine like proposing @danove_b . I have a STM32 and use Mmos set to PWM(H-BRIDGE) as interface to the board and associate the stick like the venture with MY1020 (Brush-engine). The issue is that the engine is in slow down mode constantly and it's produce a little power when I turn the encoder to 900 degrees the engine lock quickly like a genuine sterring haggle on the off chance that I pivot the encoder in the other sense the engine return in his slow down mode. First I utilize the corridor sensor like an encoder however don't work the guiding lock with my encoder works and I utilize two IBT_2 then I attempt with three IBT_2 one for stages and it's a similar issue of slow down mode all the time. I attempt diverse recurrence in Mmos yet the engine has a similar issue. When I use RFRwheeltest and put the base power in Mmos to 3% the engine moves and afterward it return in slow down mode. I connected a connection with my work: https://drive.google.com/drive/folders/1mpiiB-54IC0ox19TH7jdAYaqu4d7rlcN?usp=sharing .

Nowadays mostly people selling their simulator through paid search campaign like PPC

Sorry saboor,

but I cannot follow your explanations. So my answer is based on guessing what you meant to say.

If you try to drive a brushless motor with the H-Bridge output of the MMOS firmware: that will not work. Brushless DC motors need 3 PWM signals as input.

If you have a brushed DC motor you better ask your question in this thread. The creator built a DD-Wheel with a brushed DC motor.

Generally you may use an online translator like google translate to improve the readbility of your question.
You can also include the native language version to your post. Maybe someone speaks your language.
Shorter sentences would be helpful too.

Cheers

Benu

I've recently bought almost everything to build it, without a motor at the moment. Now there's one problem - do I need specific hoverboard or just anything with 36 V engine? I want to buy complete board with 2 working motors and try to modify one of these, increasing resolution of sensor could be good idea. Some printing, car parts and maybe it'll work... Now I need to figure out how to connect BMW gas pedal with arduino, because I don't have pedals