1. Hundreds of coffees, endless nights of debugging and coding, and countless feedback by our beta testers led to this new major release. SimTools 2.4 is probably the version with the most upgrades and improvements in a single release ever. Look at everything Dustin has included:
    SimTools 2.4 all features.
    Dismiss Notice
  2. For downloading SimTools plugins you need a Download Package. Get it with virtual coins that you receive for forum activity or Buy Download Package - We have a zero Spam tolerance so read our forum rules first.

    Buy Download Package Now!
  3. Do not try to cheat our system and do not post an unnecessary amount of useless posts only to earn credits here. We have a zero spam tolerance policy and this will cause a ban of your user account. Otherwise we wish you a pleasant stay here! Read the forum rules
  4. We have a few rules which you need to read and accept before posting anything here! Following these rules will keep the forum clean and your stay pleasant here. Do not following these rules will lead to permanent exclusion from this website: Read the forum rules.

DD-Wheel with Hoverboard Motor

Discussion in 'Direct Drive Wheels' started by Benu, Jan 21, 2019.

  1. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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
    • Like Like x 2
  2. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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

    Attached Files:

    • Like Like x 2
  3. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    @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.
    Last edited: Aug 14, 2019
  4. BiT0

    BiT0 New Member

    Joined:
    Mar 13, 2019
    Messages:
    28
    Balance:
    166Coins
    Ratings:
    +3 / 0 / -0
    Hey @danove_b spotting IBT twins in the pic.
    How did you wire them?
  5. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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
    • Like Like x 2
  6. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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 };
    • Like Like x 1
  7. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -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:
    • Like Like x 2
  8. RSP

    RSP New Member

    Joined:
    Apr 26, 2019
    Messages:
    11
    Balance:
    94Coins
    Ratings:
    +4 / 0 / -0
    My Motion Simulator:
    DC motor
    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 ?
  9. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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.
  10. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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...
  11. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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.
  12. Benu

    Benu Member

    Joined:
    Mar 19, 2018
    Messages:
    78
    Location:
    Germany
    Balance:
    693Coins
    Ratings:
    +25 / 0 / -0
    @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.
  13. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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.
    Last edited: Aug 18, 2019 at 15:51
  14. Benu

    Benu Member

    Joined:
    Mar 19, 2018
    Messages:
    78
    Location:
    Germany
    Balance:
    693Coins
    Ratings:
    +25 / 0 / -0
    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:
    Hoverboard Motor Drive Settings.PNG
  15. danove_b

    danove_b Active Member

    Joined:
    Nov 11, 2017
    Messages:
    143
    Location:
    Sweden
    Balance:
    1,168Coins
    Ratings:
    +49 / 2 / -0
    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...
  16. siewcu

    siewcu New Member

    Joined:
    Yesterday
    Messages:
    1
    Location:
    Wroclaw, Poland
    Balance:
    17Coins
    Ratings:
    +0 / 0 / -0
    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.
  17. Benu

    Benu Member

    Joined:
    Mar 19, 2018
    Messages:
    78
    Location:
    Germany
    Balance:
    693Coins
    Ratings:
    +25 / 0 / -0
    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.
    upload_2019-8-20_19-7-2.png