DD-Wheel with Hoverboard Motor

@fzxj520

I suspect that you have some backlash between the motor and encoder, are you using spur gears to drive the encoder?

The way the motor is behaving it looks like the motor driver is outputing wrong phase sequence timing and that may be due to backlash between the motor and encoder.

The fact that you say that when you monitor the encoder and rotate the wheel and then return to the same position the encoder value isn't the same suggest that you are missing pulses or have backlash.

I'd suggest that if you can't get rid of the backlash would be to try using the hall sensors instead for the motor controller, you can still use the rotary encoder for MMOS as a small amount of backlash in the steering isn't going to make much difference.

All servo motors that I have experienced be it brushed or brushless have encoders directly mounted to the shaft.

PS. go get yourself a multimeter it will help so much in fault finding

I originally thought it was the connection between the encoder and the motor. I re-made the connection, and now the encoder and the motor are tightly connected, but the problem remains.
-------------
The encoder counting code I use has some bugs that can cause counting errors.
The extremely small forward and reverse rotation can also be called vibration, which causes the encoder count to increase continuously, although the final rotation position does not change.
https://www.xsimulator.net/communit...th-hoverboard-motor.13178/page-21#post-200022

I bought a multimeter for this.
I turned the steering wheel to the angle limit (at this time mmos has pwm output, I will also open the limit force to 100%). Turn the steering wheel slightly, and then test the ab phase voltage, the output voltage can jump to 4.5V. It seems that the encoder has no voltage fault.

Please do the measure on the ESC card (A/B). It should be 3.3 Voltage high and 0Voltage low. I guess you measure the voltage on the other side of the opto coupler. The ESC has 3.3 Logic level for the encoder inputs.

I directly measured the encoder signal line, the voltage can reach 4.2V
This is the model I use

What optocoupler are you using as it looks like there is ~7ms of turn on lag on trace A and ~3ms for trace B.
If you look at the vertical lines I drew on you pic it is far from 180deg out of phase.
This can be caused by not a constant speed and diferent turn on speeds for the optos.
Switch your scilloscope to the xy function, if your A & B channels are 180deg out of phase you should get a perfect square above 0v, if you see a trapezoidal trace it is not alligned or your optos are too different.
You can do a trace before and after the optos to find the culprit.
Slow optos could result in missing pulses at high rpm as they don't have enough time to turn on.
Best if you could get a constant speed to the encoder when viewing on the scope even if you take the encoder off the wheel and use a small motor to drive the encoder.
Try get atleast 3 complete cycles on the trace, 1 cycle isn't enough to be reliable.

Why do you have opto couplers? I don't need them, and I'm pretty sure you don't need them either...

I believe I now have the exact same problem as fzxj520 has. ESC was working as expected, smooth torque control in both directions through a test arduino sketch. After connecting to my FFB source my power supply reset when there was a reverse voltage as I didn't have the braking resistor connected. Pretty sure this burned something in the ESC as the wheel will no longer move under its own power, and when I move it by hand there is cogginess proportional to the pwm command. The higher the command, the more the cogginess is felt... Encoder still seems to operate as normal. Probably only one or two of the phases being energized. Not sure how to check this.

Not sure I am going to move forward with this little ESC, may be too fragile for this application. I am happy using the original hoverboard control board for now.

@OZHEAT
@danove_b
A. The encoder is directly connected to the ESC. The optocoupler is only between the mmos and the encoder, so should the optocoupler affect the ESC?

Benjamin suggested the safety recommendations of using USB isolation to ensure the absolute safety of the USB interface, and I chose to use optocoupler isolation.

I have done it without using optocoupler connection, and still have this problem.

-----------------------------------
B, this is a simple Arduino oscilloscope, no external circuit is connected, and the measurement should have errors.
This is the optocoupler module I use.

I think ESC must use braking resistor.
If you don't use a braking resistor, even if you use the minimum torque output, the ESC may enter the protection state (turn off the output) at any time. I use a 24V power supply.
Tip: Do not connect the braking resistor (or disconnect the Z connection of the ESC) before writing the firmware of Benu. This operation should also be used when running the Motor Profiler. Otherwise, the braking resistor will always heat up when the power is turned on, and the temperature is unacceptable.

I also doubt that ESC may have some potential problems. On the other hand, I think ESC is a good cheap solution with many advantages.
I used to test the game for more than 1 hour when the ESC was completely normal (past tense), and the FFB effect was very good, exceeding my G27. ESC uses a very small fan to dissipate heat. ESC only has a very low temperature. The temperature of the hub motor will be higher than that of ESC. (MMOS sets 30-50% force output during testing)
In addition, the wheel motor should be very suitable for FFB steering wheel. I also noticed that Fanatec DD also uses external rotor brushless

I think this thread will be better with everyone's efforts.

What arduino sketch do you use?
-----------------------------------------

I now have my wheel pretty much up and running.



It works great, but the brake circuit isn't doing its job. The PSU keeps tripping.
This is how I connected it. The mosfet is a IRF520 and the PSU is a Fractal Tesla 550 connected with 12V. My multimeter is too slow to measure the output signal of the b-g431b-esc1, so I can't tell if its trying or just being lazy.



Can somebody spot an error?

I am not an expert, but I suggest that you test the mos tube separately, you can connect a small power bulb or a DC brush motor to test whether it can work normally. (G level uses 4V-5V voltage)

In addition, whether the Z trigger voltage is less than the power protection voltage？

Yeah, I thought I’d connect some 12V led to see when/if the mosfet opens up.. What does G level mean?

Power protection should be up over 20V. I think z-trig is 14V or so.

Your problem may be, that the IRF520 is not a logic level MOSFET.

The ESC I/O output pins are 3.3V max.
The IRF520 datasheet shows, that Vgs (max) threshold is 4V and Vgs (min) threshold is 2V. So to be on the save side the IRF520 needs at least 4V to start opening up. But even then source-drain is not completely open. Higher gate voltage gives lower drain-source resistance which gives higher current capabilities.

Better use an IRLZ44 or IRL540n.

Sorry to hear that.
Did that happen the moment you switched on the ESC or the FFB source?
Or were you driving in a sim when that happened?

There is a software and hardware shutdown implemented on the ESC. In case voltage and/or current is to high. This should protect the ESC from all but the worst mistreatment, even without a braking resistor attached. Pushing the reset button on the ESC (or power off/on cycle) will restart and clear internal state.

So it would be good to understand the exact circumstances how this happened.

I was not driving in the sim, but adjusting settings for wheel stop in the EMC software utility. I moved the wheel to one stop, and it spun rapidly to the other stop. At that time it tripped the power supply. When I reset everything the ESC would no longer control the wheel, it would only apply "coggy" resistance.

Last night I used the motor profiler to see if that was behaving normally, and although it made it through the profiler routine, it could only get to 230 RPM, about half speed of the original profile. I believe this is another indicator that only 2 of the 3 phases are working properly out of the ESC. Just to check, i reconnected motor to the original hoverboard control board and it behaved normally, so that rules out a motor problem.

That's strange.
First it shouldn't spin to the other stop and second even then, over-current protection and over-voltage protection should prevent a burnout. What force level were you using?

Is the EMC software for an Arduino Leonardo? If so, could you send me the EMC firmware you are running? I would like to check what PWM signals are sent?

Yes, the EMC firmware runs on Leonardo. I run a custom version of firmware that the creator built for me that emulates standard RC PWM signal, since that is what the hacked hoverboard control board requires to control it. I use an arduino nano to capture that signal, and translate it to a 3KHz PWM signal to send to the ESC. I will send that code when I get home tonight. I could send you the EMC firmware, but I believe it will only work with EMC Utility which requires a license.

Thank you very much for your help! Finally normal
--------------------------
1. I use the new 1024ppr encoder and upload the corresponding newly compiled code. I exchange the connection between the AB phase line of the encoder and the ESC to obtain a normal FFB.
2 Then I reconnected the encoder of 2000ppr, uploaded the corresponding old code, and also exchanged the connection between the AB phase line of the encoder and the ESC, and actually got the normal FFB (I did not exchange the connection of the AB phase line before, I can also get the normal FFB), I was very pleasantly surprised.

I have also changed the connection between the AB phase line of the encoder and the ESC many times before, but I have not been able to get the normal FFB until I uploaded the firmware of the 1024ppr encoder. I think that the unreliable connection between the motor and the encoder caused the ESC to retain the wrong memory until I uploaded the new firmware to eliminate the error. Perhaps it was my negligence.
--------------------------

A. Since the mechanical connection between the motor and the code is not finely calibrated, there may be 2 connection methods:
a, encoder A phase <—connect—> ESC A phase, encoder B phase <—connect—> ESC B phase
b, encoder A phase <—connect—> ESC B phase, encoder B phase <—connect—> ESC A phase
B. If the output of the motor is reversed (after manually turning to the limit, the motor rotates independently and continuously), two output modes of pwm can be changed:
a, PWM 0.50.100
b, PWM 100.50.0
C, mmos encoder cpr setting has nothing to do with this fault (only affects the steering wheel rotation angle).

Glad you have your setup up and running again!