DD-Wheel with Hoverboard Motor

The motor I use does not have any imprint or label. The specifications of the hoverboard I scraped the motor from were 500W. For me that is 250W per motor. The battery voltage was 36V. The diameter including rubber wheel is 6.5 inches.

Beny, what do you think about using ABS magnetic ring? Resolution is much worse than in your magnetic ring, but I can't find one that you've bought...

I am not sure if the material of the magnetic ring is relevant. My guess is, it is not.
But pole width and magnetization (field strength) have to match with the encoder chip you will be using. For the AS5311 you need 1mm pole width.
Make sure the magnet ring does not exceed 128 magnetic poles for the AS5311. Otherwise the FOC software will not be able process the >65536 pulses per rotation.

It'll be the as yours, so to be honest I don't bother. Now I need to find AS5311 with a reasonable price.

Torque vs motor current diagram is linear? I'm wondering about measuring torque, if it's possible to translate motor current with simple method, without calculation etc.

Yes, input current and output torque are linear. Clockwise and counter clockwise directions seem to be reasonably equal too.

Accuracy:
The data was aquired with an analog kitchen scale. 0g - 5000g and min scale interval of 50g.

Seems like differences are caused only by scale measurement reading So now there's only problem with finding proper current sensor. 30 A are common, but I think that's too close to the limit of the engine... IMO 35 A sensor is reasonable minimum.

Yeah, that will be the major part of (in)accuracy.

If you want to stick to 30A limit there is no need to change anything. Current sensing works upto ~31A and overcurrent protection kicks in at 30A. That should do to get about 12Nm out of a 250W hoverboard motor. Which is the sensible limit for my motor. In my opinion the main issue is not the current limit but dynamic forces induced by us, the sim racing driver.

Overcurrent protection (OCP) kicking in (and overvoltage OVP) in my opinion is caused by Back EMF induced by me counter acting the wheel when hitting bumps or curbs. I have set OVP to 20V and OCP to 30A and when I go beyond 16000 Iq very hard hits in the racing sim activate OVP.
This value may differ with each game/sim and in game settings.

In my opinion the safest way to cope with that would be a braking resistor circuit. Just cranking up the OCP limit will increase the potential of killing the power supply or parts of the board.

BTW did you try STM MC SDK already?

Nope, not yet. Lack of free time... I'll try next week, I'll also should have this motor but I still have a problem with magnetic ring... And have no idea how to solve it. Shipping arrangement from supplier isn't as easy as I thought it will be. Biggest problem without any idea how to find different solution for this.

Just realized that I can take use of the bipolar function of the AC712 and detect when the current goes reverse and make a software controlled braking resistor. One half-bridge on one of the IBT-2 is leftover but will suite this just perfect!

I'm still wondering why hall sensor is much easier way than encoder. Resolution should be much higher, but if it's software issue with this maybe using another arduino/esp8266 will be enough to translate its output signal to be the same as with a hall sensor? I don't have too much knowledge about electronics etc and I'm just trying to copy working project(at least at this time), but when I have some free time at work I'm trying to resolve this really serious problem with magnetic ring...

If you have troubles finding a magnetic ring you could try Erics solution. If you want to have buttons on your wheel rim you need a spiral cable from the (turning) steering wheel to the (fixed) controller board anyway. The encoder will occupy only 2 additional wires (3 if you want to use index signal).
Many use spiral HDMI cable for that purpose. 19 wires and all heavily schiedeld.

I went back to the hall elements mainly because when I ordered the encoder I didn't know how many poles the motor had. Unfortunately, the PPR value I had bought wasn't evenly dividable with the number of poles(15) of the motor. I should have bought a 1800 PPR but I bought a 2000 PPR.
I couldn't measure any differens in stall current moving inside the 60 ° sector and i also didn't need to solve some sync. function for the commutation. For now I'm using the hall elements. Maybe I order a new encoder in the future, but for now it doesn't seem to make any noticeable change.

I am really excited to see the interface options for hoverboard motors develop. In the spirit of moving things forward faster, I am willing to do the machining on a limited number of wheel/motor assemblies if it would help any of you existing members of this thread progress the interface faster.
I am currently deployed with the Guard but will be back in the states by the end of December. I would do the machine work for free if you guys are willing to ship to me and pay for return shipping. I am more of an integrator person vs. you software and electronics guys. So my goal is to wait in the shadows till one of you has a nice working solution I can simply integrate on to my motor.

Hi Erik,
nice to know you are still following this thread. Thanks for your generous offer. That will help people from the US getting their hoverboard motor encoder ready.
Can you think of a way to do the same modification without the professional tools you used? Using only tools you will find in DIY toolchest.
That would be very helpful for all the others.

Truly doubt it. The main problem is that the the shaft needs to be center drilled for the smaller output shaft that is installed to projects thru the cap and center of the encoder.

Thanks for your offer Erik. The backside with you solution though is that you need wiring that can handle the rotation. My 3d printed gear that use the pattern on the wheel works perfect. That seems to be the easiest part for me in this project. I have done some more testing with the AC712 current sensor, and I'm very close to be 100% satisfied now. I'm down to 200 us loop time, but I'm lost in the PI tuning. I don't have any oscilloscope at the moment, so I'm kind of working in the dark. I haven't yet implemented the brake resistor function, I just connected a 50 w lamp in parallel for now that keep me away from power supply trips. The part that isn't perfect yet is when the wheel moves very quickly like when you get a snappy oversteer and do a fast correction. It reminds a bit of a hydraulic power steering that isn't fast enough. There is also a terrible noise probably because the current is turning direction very quickly, like oscillating. This also trips the power supply if I don't have the lamp in parallel.

A couple of thoughts...

Is the 200 us loop time to much for this application?

Is 8 bit resolution on the AD not enough?
The ACS712 has a range of -20 to 20 Amps which gives 0 - 5 Volts.
My working range is set to 0 - 10 Amps, so that's only 1/4 of the 10 bits range...

Tried with 10 bit PWM, but didn't make any noticeable differens....

I cut away the rubber ring from the motor. That took off 400g from the outer rim and reduced inertia. Had to build some kind of harness to attach the wheel. But overall the wheel base is lighter that way. I was not sure if the front of the motor could handle some holes and screws for the wheel. I think RSP used the latter approach. @RSP - Any hints on how to do that?

I see the same behaviour. Quick wheel movements under heavy load generate voltage spikes on the DC bus.
To test that I use iRacing WheelCheck selecting "Spring Force -> Simple Spring".
Moving the wheel against the spring force with normal steering speed works well even under highest loads.
Moving the wheel quickly under light to medium load works well too.
Moving the wheel quickly under heavy load raises DC bus voltage beyond my currently set Over Voltage Protection (OVP) limit of 20V DC bus.
The quick movement has to be against the spring force to create the voltage spike. A quick movement with the spring force has no negative effect.

I set the limit to 20V because I am not sure how much DC voltage my HP server power supply can handle. The IHM08M1 is not the problem, is rated 50V.
To mitigate the voltage spike I reduce motor current dramatically at a voltage level below OVP limit. This all does not matter while driving as only a direct hit into a wall or a very hard bump on a high curb trips OVP. With the implemented current reduction you only feel a "light wheel" for a fraction of a second. I think a brake resistor would make the wheel feel heavy or stiff in that situation which would feel probably more "realistic".

The IHM08M1 has no circuit for a brake resistor on board. @danove_b - Is it possible to attach a brake resistor circuit without big board modifications? I could programm the F303RE to signal OVP situations on one of the GPIO pins.

The F303RE PID loop runs at 30 kHz. That is a loop time of 33.3 us. Maybe the 5 kHz are to slow. And the frequency is in the audible range. That maybe the reason for the terrible noise. Shifted above 20 kHz the noise will be inaudible.

With 8bit your resolution is approximately 0.04 A = 10 A / 255. I would say that is ok.

Did you consider to use some other hardware than the Arduino. There are plenty of boards for around 10€ that can be programmed with the Arduino IDE. Maybe the FFB software can be ported to one of those boards and you can still build an all-in-one solution.

I have seen some analog examples of braking resistor circuit using a zenerdiode, but at least with you cycle time it should be no problem to control it from software. As I understand you already have the voltage connected to a ADC? You can control a N-FET directly with a I/O so a power resistor between 0.5 and 1 ohm connected from +12v to the Drain of the N-FET and the Source to GND and finally Gate to your I/O with a 10k resistor. Activate at 18v and deactivate at 15v.

I have some alternative hardware laying around, but because we have access to the source of a working version on the AIWave, I saw a chance that we could make a "one card only" solution even if I don't need it myself. I'm sending the torque values directly from rFactor2 to the serial interface with the help of a plugin that i have written. I have done lot of projects with the ESP8266 which is very powerful. I also have a couple of ESP32 that are even more powerful. The problem with these are the missing HID ability. The STF32 has, but I haven't found any working FFB HID examples yet...

I had 300 km in the car this morning and had some time to come up with some new ideas. Before I went over to a current loop I had plan to use a linear function I found on the internet called multimap. My plan is to make a table with torque values to PWM values in stall, and the just a Integrator function working with integer to fine adjust the PWM value which is needed when the motor is turning . This will help me cut the cycle time in half I think. This is kind of halfway back to my initial idea that with a motor in stall, the current is proportional to the voltage, but I didn't realize the amount of back EMF this motor produce already at very low rpm.

Maybe it'll be better to try with different PSU or make a variable voltage power supply of the one that you have? I'm still wondering what will be better to deliver power to this, with dedicated power supply OVP may not be needed, but OCP is more than neccessary. Destroying motor controller isn't something that I want to do, it wasn't cheap and my supplier had 3 pcs left some time ago...