DD-Wheel with Hoverboard Motor

If anyone wants to mount the motor on 40mm alluminium extrusion, I found these:

Hoverboard Motor Axle Clamp for 40mm Aluminum Extrusion

and with retention

Hoverboard Motor to Aluminum Extrusion Clamp w/ Full Retention Wing

@Benu & @RSP any news?

This clamp is a very good solution when the project will end up I'll have it set up better. Benu sent to me the firmware that he needed to modify to use the encoder and we had a good result. At 200w the motor have a peak of 11,77 Nm and mantain for 20 seconds 11.2 Nm then the board goes in overheathing. Measurements are not precisely I use a balance and my wheel and make the measurements three times and I had the same result all the time.The equation is 10Kg(balance)x9.81(g)x0,12m(distance between the center of motor and the end of the wheel). Benu is working to finish the firmware for test with the PWM inputs to the STM32F4 or Arduino.

Cool! So maybe this may be the ultimate solution in the end.
Wish you both sort it out because I think the hoverboard wheel is absolutly a nice project if you consider the Nm/price ratio.

I am so sorry I didn't sort it out my way. I think FOC is the elegant solution. But I am still convinced it may be possible to drive it nicely with the scaled sinus wave and h-bridge approach.

What is your final solution for the encoder mounting? Magentic or optical?

Sorry fot the late reply, I didn't find a multipole ring. I contacted two resellers but they didn't response after 3 week. I will use my 10000 ppr encoder with two gear, one attached at rear of the motor and the other on the encoder with no reduction (1:1).

I've received magnetic ring, and now waiting to buy a sensor for it... Unfortunately I've found it only in Mouser, which means that I need to wait for someone to buy something with me to get a free shipping. It looks like this is only thing that I need to go for assembling everything together.

But now I'm wondering - is there any sense in attaching additional encoder? Maybe its readings will help in something? Just to read in which position wheel is at the moment, despite magnetic sensor readings. Maybe it will help with something...

Currently I do not see any reason for a second encoder. One encoder can feed both, the MMos Disco board and the IHM08M1.
But if you want to use AIWave Leonardo firmware, the 16834 ppr of the encoder may be a bit to much for the Leonardo.

Finally got some time to work with this project. I have optimized the code now so there are no float operation at all and I managed to take down the loop time to 50-70 us, which correspond good with the PWM frequency on 15Khz. This is with trapezoidal commutation using the inbuilt hall elements. With the encoder and sinusoidal commutation I managed to reach 250 us, which also worked, but to slow to have time to adjust the current fast enough to feel kerbs in high speed. The backside of the trapezoidal commutation is that I have some minor torque rippel, but it's far less than it is with the MY1020. I will get back with more detail later if someone is interested. I have plan to port the code to a ESP later, but it can take some time....

Will you port the FFB code too or just the motor control part?

Just the motor control part. The esp has no hid. Currently my Leonardo code only include the motor control. I'm sending the torque values by serial from rfactor2. Currently I'm not sure if it gonna work including the hid code. There is no room for additional analog readings, so you still need a additional Leonardo for gas, brake etc. It was my goal in the beginning, but I missjudge the capability of this chip or the performance needed for the task...

OMG, I just discovered this thread. This is awesome guys (I'm the guy who did the FFB Firmware for Leonardo and Ai-Wave Wheel Config software).
I'm currently working on boards and software for motion simulators, but I'll be back to work on an evolution of my FW for Leonardo, for sure, I'll be back

Did some back to back testing between the hoverboard motor and the MY1020 today, and I must honestly say that I still prefer the MY1020.

One thing is that I still feel some clearance when I'm turning the wheel very fast back and forth. Maybe the motor produce so much back EMF, so the 12 V isn't enough to work against it. @Benu, do you also have this? I have tried to send the scaled torque values directly to the the PWM bypassing all my code but still the same issue.

The other thing is that the MY1020 gives a little more detail. Maybe this motor has a bit more inertia that the MY1020....

Turning the wheel back and forth very fast has two different outcomes:
1. If the FFB controler sends low to medium force request to the wheel, you feel the counter force while steering and everything is as expected. E.g. using WheelCheck in simple spring mode. Turning the wheel fast +/- 30 degree to the left and right, is ok.
2. If there is high force request from the FFB controler, over current protection from the IHM08M1 driver board kicks in. E.g. WheelCheck in simple spring mode, turning the wheel beyond 30 degree and moving it fast back and forth.

I guess this is the motor working as a generator and inducing too much voltage/current in the driver circuit. To protect the power supply (12V) and the rest of the electronics, I cut PWM to the motor at 16V and resume PWM when voltage drops below 16V.
The result is, in a very tight corner (e.g. Monza T1), sometimes there is no force feedback for a fraction of a second. The 16V limit is choosen from gut feeling and not scientifically.

Hi Etienne,

thanks for your firmware!! Great work!

Do you consider using some other hardware for the evolution or will you stick to the Leonardo? Would that be to much work?
The reason I am asking is, that it might be an option to integrate FFB firmware and driver firmware/hardware on a single board. That would be a nice DIY DD-Wheel project.

Benu

Hi, Thanks.

No I'm not considering using the Leonardo anymore. There are many other cheap MCU/boards capable of USB and that are much more powerful, and that include hardware quadrature decoders. I've already ported all the HID/FFB side on Teensys, Due (but a long time ago, and it was not stable), and on STM32. Now I need some time to test on different configurations (drives/motors), and to work on the interface to tweak all parameters.

What may happen is that indeed the motors behaves like a generator, which raises the main voltage. In this case you need a Mosfet and a braking resistor to absorb that energy and drop the voltage.

I have thought about that too, hopefully that's what is missing. I currently have a 18 volt OVP diode in parallel with the PS. I have already ordered 13 and 15 volts also. I suppose you have been working on a BLDC solution also? This is the third time we communicate on the same subject (DIY FFB)...

The OVP diode should be in serial with the PS, not in parallel, as on this schematics :



I haven't been working on a BLDC solution yet. I've tested VESC and could make it work with a MIGE 130ST-M10010, but there was a bit of torque ripple (I wanted to try to change the current sensing shunts to gain precision, but didn't find the time). I've also tried ODrive but could not make it work with this motor (but it seems possible). Both drives are overkill and not designed to do precise torque control, but I think that with minor adjustments they could be good choices (except ODrive is awful to configure, no GUI, and is for 2 motors which is useless for wheels).
I wanted to try with the X-NUCLEO-IHM08M1 some time ago, but it was not produced anymore, since then I've seen that it's produced again, but not in large quantities, and the next batch is in 2 month
Other boards have appeard since then, like the shield based on infineon IFX007T which seems to be a very interesting alternative (limited to 40V, but that should not be a problem if choosing the correct motor).
I'm focusing on the software, as designing a BLDC controller would be a bit time consuming and I'm quite sure that there is a cheap (<100 €) drive that will do the job, and because the software is the weakest aspect of commercial products at the moment.

That Diode is a "standard diode" just to protect the PS from overvoltage I assume. It doesn't "kill" the back EMF from the motor. That's why I use OVP diodes (it's like double zenerdiodes) mounted in parallel. When I receive the ones with lower voltage, I will try to put some directly over the motor windings. Do you know if the braking resistor in those drives are activated on rotation speed or just back EMF voltage?

Yes that diode prevents applying higher voltage to the PS when the motor is behaving like a generator. I think the braking resistor is activated from the back EMF voltage, when is goes beyond a threshold.

Yes, as Etienne said, the braking resistor would be activated beyond a backEMF threshold. The odrive has MOS FETS to switch braking resistors on/off. Unfortunately the IHM08M1 does not have them on board.