DD-Wheel with Hoverboard Motor

This thread is about building a direct drive wheel with a powerful but cheap hoverboard motor. The discussion started here and was moved to this thread.

If time permits I will edit this first post to summarise the current build options.
-----------------------------------------------

My first build is currently running smoothly at 8Nm. The motor should be capable of around 12Nm.

Back then the question in the odrive community was asked by me. I did not test the odrive with a hoverboard motor. So yes, there is currently no negative report on using a hoverboard motor. I am doing my best it will be a positive report.

My current setup to test if a hoverboard motor qualifies as a DD-Wheel has two STM evaluation boards. A
- NUCLEO-F303RE (CortexM4) as the control board for around 10€ and a
- X-NUCLEO-IHM08M1 as the inverter (10-48V and 30A max.) for around 40€
- a second hand 12V server power supply for 24€
- a Hoverboard motor 36v 250W from a hoverboard with a broken battery.

Both boards can be plugged together and are programmable with the free STM-Motor Control Workbench (You need some other free tools to compile and upload to the controller board). This combination can control BLDC motors in 6-step or FOC mode. You can attach hall sensors or quadrature encoders.

Currently I am able to run the motor in sensorless mode. Maximum speed with 12V is around 170 rpm. Minimum speed is around 50 rpm. Below that the motor stops. Probably BEMF to weak or inconsistent. Attaching an encoder should help to overcome this issue, I hope.

When attaching an Omron encoder (2000P) the motor moves a bit but does not rotate. The motor is stalled and it is hard to move it. The Workbench UI shows there are 7A going through the coils. No errors reported from the controller board and rpm is signaled as 0. When spinning the encoder shaft I can see the encoder is working both directions and the Workbench UI is showing the rpm.

Next steps will be to work my way through the motor control parameters and figure out what keeps the motor from spinning. When this is resolved I will probably use an
- AMS AS5306B and an
- AMS AS5000-MR12-72 magneting ring
attached to the back of the motor to replace the Omron encoder. The inner diameter of the magnetic ring is a bit larger than the hoverboard motor shaft. In my opinion there is no need to build this into the motor.

Here is an image of the current setup.


-Benu

Don't focus on getting the motor to spin as this is not equivalent of getting torque from the motor.

This might help you understand: https://www.switchcraft.org/learning/2017/3/15/space-vector-pwm-intro

You MUST know the rotor position to know which phases to activiate in order to produce stationary torque.
Free running mode will not work as it assumes constant rpm (pulses phases in sequence regardless of rotor position).

That's correct. The rotor position is crucial for this kind of motor control. Especially with low motor rpm or even stall.

STM Workbench should do a (manually triggered) encoder alignment to match the encoder ABI input with the rotor position. But that does not work out for me. The alignment lets the motor twitch once. No error is reported. But starting the motor after that results in another twitch and 7Amps going through the coils. The motor is stalled.

I guess I first have to check if the aligment is done correctly.

Thanks for the URL. A very nice and visual description.

is this motor a 3 phase brushless motor ? are you using a brushless motor controller ?

The Hoverboard motor (3 phase brushless) is spinning now with torque control.

Using torque control and beeing cautious with the settings it delivers 3Nm at 6A. Tested with a kitchen scale and a screw clamp as lever. The lever end was 18.5 cm off axle and the kitchen scale read 1650 g. That should calculate to: 0.185 m x 16.5 N = 3.05 Nm.

I wrote a PWM input routine for the Nucleo-F303RE and injected it into the motor control code. This captures PWM+Dir signals as I expect them to come from the AIWaveFFB-Leonardo. Testing with an arduino sketch, emulating PWM+Dir, sets the torque reference current in the motor control board and drives to motor correctly. You can feel the torque variing when you try to brake the wheel.

Connecting a AIWaveFFB-Leonardo to deliver the input gives me some issues. I get some PWM reading but only shortly when hitting "OK" in the "Advanced Settings" window of WheelConfig(v0.21).

Is there a way to tell the AIWaveFFB-Leonardo to output some test PWM?
How would the wheel behave/move when I hit "Calibrate" or "Center Wheel"?

Connections:
I connected AIWaveFFB-Leonardo (pin 10: PWM, pin 11: Dir and GND) to the motor control board (the same inputs I used for the test with my leonardo sketch).
The encoder output pins (A, B and Z) to AIWaveFFB-Leonardo digital pins 1, 2, 6. I use the same encoder outputs that are connected to the motor control board. When I connect AIWaveFFB-Leonardo pin 6 to GND I get encoder readings in WheelConfig(v0.21)

Sorted out the encoder issues. The right sequence of "Advanced Settings" and Arduino pin 6 -> GND did the trick.

The Hoverboard motor is up and running.

Anybody interested in WheelCheck log files? What are the best settings for WheelConfig (gain, damper, spring, etc.) to have a reasonable log output from WheelCheck?

This is the RFRWheelTest output.
Reduced maxium current to 4A for the time beeing. Just to be on the safe side.

Is this test program available for download?

I think I got it from here:
http://www.racingfr.com/forum/index...&showtopic=48669&st=0&p=1531001&#entry1531001
It's from a french racing forum. You'll find outputs for commercial and custom wheels in the thread.

Are you using sinusoidal or trapezoidal signal in your control?

The controller board uses Field Oriented Control method. FOC generates a sinusoidal wave form to maximise torque. You find a good write up in @Alexey's link in post #513 in this thread.

Yesterday the off axis encoder worked for about a minute. Then the AS5306 smoked its way into uselessness. But for that minute I was able to get position information from the magnetic ring/hall array combination. For the next try I will get new flux.

I bought a second hand hoverboard last week, and have plan to do some test when I got time... I found this Arduino code https://github.com/cmasenas/3-Phase-Sine-Arduino/blob/Release/DDS_Generator.ino that I plan to run on a Leonardo. I realize that it will be to time consuming for that cpu to do 3 torque multiplications with floats every interrupt so my idea is to make several tables, one for every torque level. I will start with maybe 100 just to test my idea. If it work ok there should be enough flash memory to make 500 tables so I get 0.2% torque step. Processing the encoder to get the angle and receive torque command by the serial interface shouldn't be that consuming I think.

I am not sure how you achieve a smooth wheel feeling with that code. As far as I understand this sketch, you only get a single waveform (frequency and intensity) for all 3 phases. That might make the wheel rotate when you connect the Arduino outputs to some driver stage. But I don't see how you will be able to modulate the strength of the output.

If the circuit boards of the Hoverboard are still ok you may try reprogramming them. You could re-use micro controller, driverstage and battery.

https://hackaday.io/project/158256-hoverbot/log/146067-reprogramming-hoverboards-for-robots

Although I did not check what kind of motor control is used in this alternate firmware. The micro controller should be capable of using FOC.

I looked in to that first, but from what I have read it's using trapezoidal. Tried to find the source of that statement now, but could not find it. Was some month ago. Also to use FOC I assume you need current feedback, and if the board isn't designed for that I think that's not an option....

My first idea was just to multiple the values in the array with the torque constant, but as I wrote it will be too time consuming for this cpu. So my idea is to make a lot of tables, one for every torque step I want. It will take a lot of flash memory, but will be very effective code.

Yes, you will need current sensing. Have you checked the main hoverboard circuit board for shunt resistor(s)? That is a cost effective way to get current sensing.

You could also go with the evaluation boards I selected. The combination is about 50€ +shipping.

BTW the AS5306 off-axis encoder is working now. So no need for an optical encoder anymore. The resolution is 1440 ppr (equals 5760 cpr). You still can get the AS5311, which has 65335 cpr, as an evaluation board for about 15€. The multi-pole magnetic rings are a bit harder to get. Today I asked two Chinese suppliers to give me a quote. Let's see what they come up with.

You will then feed the 3-phase PWM output of the arduino to three half H-Bridges I guess.

Exactly! I like to keep it as simple as possible, and there is a good chance that this could work quite well. Hope you can share some more details of your builds later, especially the AS5306. I have no time to work with this now, but I had plan to just use a omron encoder with a wheel attached and positioned against the back of the hoverboard wheel in 90° position.