I continued reading the documentation and decided to measure the motors KV, resistance and inductance to see if it helped but… same issue.
Measured:
0.75Ohm
38KV
1084uH 350khz // 1190uH 50khz
Changed from 12V to 24V,
I don’t know… I’m stumped as to what to check at this point…
I took a big step backwards and started testing the MKS controller with a small gimbal motor.
I want to find a working inlineCurrentSense setup that works without jumping from the workbench
@Candas1
Yeah, I was expecting a lot lower value too… hold on…
Yup, my bad, the online calculator uses the number of poles instead of pole pairs. The result is 19KV, still seems a bit high. Gonna try this value…
Works a tiny bit better hahahah
@o_lampe
I don’t think I have any other BLDC with hall sensors, maybe some 500W Dunkermotoren ones but they are again big motors. I have some quad-copter motors somewhere…
That’s a chonker of a motor hahahaha. Neat idea to get the hall sensors in place.
I’m looking at the price of motors with hall sensors and they are more expensive than I remembered…
Will empty out the motor closet tomorrow and see if I have anything I can test with…
If not I’ll continue with adding the AS5600 encoders to the hub motors.
Tomorrow because I can’t use the mill at these hours to drill out a centered hole at 2AM hahaha!
I saw you got a ¿DE-5000? looks really nice. I wish that one existed when I got mine, it’s missing ESR
369uH seems pretty high, but then if it works it works! What board and motor are you using? GD32F103 hoverboard driver?
Yeah, I thought it would be useful to measure the inductance and resistance of the many hoverboard motor types, maybe Lq and Ld. If we try to measure this by software it will help also.
I tried simplefoc on single boards with GD32F130 and dual boards with stm32f103(with only one motor) so far. Ideally it will work on all the boards.
What was the mode you wanted to use again?
If it’s torque mode (voltage or current based), be prepared for a wild ride…
You’d have to wrap the target-torque in a ramp-up/ramp-down (for-) loop to avoid excessive acceleration. As I’ve learned today, there isn’t much PID-tuning available for torque-mode.
I’ve written a bit of code to gradually change max_current and slow down the motor. It could be helpful for big motors in torque mode (current_sense required)
void loop() {
motor.loopFOC();
motor.move(accel2target);
if (accel2target == 0.0f && sq(motor.shaft_velocity) > 0.5f){
motor.PID_current_q.limit = motor.PID_current_q.limit /1.005f; // gradually reduce current
}
else if (motor.PID_current_q.limit < max_current){
motor.PID_current_q.limit += 0.005f ; // back to normal, waiting for new target
}
else if (motor.PID_current_q.limit > max_current){
motor.PID_current_q.limit -= 0.005f ; // back to normal, waiting for new target
};
// user communication SerialComm instead of Commander
if(Serial.available() > 0){
SerialComm();
};
}
Velocity/distance control in whatever mode works to be honest hahahah
Thanks for the chunk of code, I’m still struggling just to get the motor to spin hahaha
I found out that the I2C did NOT like being near the phase wires. Had to mill out flats on the shaft to get the wires out another way and the AS5600 reads properly when the motor is powered on!!!
Ah! Thanks, forgot to change that back to 1M xD (That improved the loop time from 1.6kHz to 6kHz! Still oscillating, but smoother hahaha)
I was using that from the Deng_FOC examples, but then found the other method in the ESP32 examples and saw absolutely no difference other than one just needs one line for setup on the ESP32
I tested the MKS FOC plus with the hub motor again. It seems, I still get shoot-through when the speed is too high. The FETs got very hot in no time when I increased the current-limit.
With the ESP32 they could have made a propper 6PWM layout, so we can adjust the dead-time via SW.
I guess, I stick with my splitboard controller and make the most of it without current_sensing.
Hmmm… have you checked it is shoot through with a scope? Mine don’t get hot at all and that’s with the constant current spikes xD
Sadly the Wemos Lite doesn’t have enought pins for 6PWM with the current sense and SPI/I2C stuff
Anyway, found the DEV branch, stole @o_lampe 's SmoothingSensor and PID values from here and the motor finally runs smooth… doesn’t want to stop but… it’s something.
Honestly I’m running out of motivation and Monday I’m starting a new job (farewell 21 months of fun holidays lol) so between work, training and chores my free time will provably be null. So yeah, if I don’t pop back in here on Saturday or Sunday this is most likely a farewell.
I hope not, because I have a third hoverboard of higher quality parts (the windings on the motor actually look nice and neat XD) and I’d like to see how that performs…
You can choose for me a small question: when using hall sensors, does your operating mechanism run well in closed loop mode? I am using velocity control but the chance is stuttering