KT motor controllers -- Flexible OpenSource firmware for BMSBattery S/Kunteng KT motor controllers (0.25kW up to 5kW)

[KingQueenWong]

EUC1 controller(https://item.taobao.com/item.htm?spm=a1z09.2.0.0.2ed6e797zYFu2e&id=528731314428&_u=bm58rj4e4ba) and JinHui controller(https://world.taobao.com/item/544557726531.htm) both can do foc.

Are you kidding?? All this time and we didn't know EUC1 controller could do FOC????

I have some of that boards with me... they are great if they can do FOC and because of the 128kb flash memory. The only think missing is a way to printf, because the UART pins are used for PWM :-( -- once I were able to printf to SWIM but that was very slow... but maybe I should try again?? I wounder if it is still being produced...

I'm serious. EUC1 controller could do FOC,you can use Pin PB6 and Pin PB7 to printf somthing information(PB6 and PB7 is used for MPU6050,).The SHUNT is use the MOSFET internal resisitor.

 

[casainho]

I'm serious. EUC1 controller could do FOC,you can use Pin PB6 and Pin PB7 to printf somthing information(PB6 and PB7 is used for MPU6050,).The SHUNT is use the MOSFET internal resisitor.

Maybe implementing software UART using LED pins...

I would like to play and try implement the angle observer that Shane Colton did!!

 

[stancecoke]

I would like to play and try implement the angle observer that Shane Colton did!!

That sounds as you have finished S06S activities

Regards
stancecoke

 

[casainho]

I would like to play and try implement the angle observer that Shane Colton did!!

That sounds as you have finished S06S activities

Not yet. I am right now trying the 0.5º angle code... not perfect yet so I don't have results and see if it increases better behavior on my Q85 at the high eRPMs.

But I would like to know if I could do FOC with sensorless on the 32kbytes flash memory.....

 

[KingQueenWong]

I'm serious. EUC1 controller could do FOC,you can use Pin PB6 and Pin PB7 to printf somthing information(PB6 and PB7 is used for MPU6050,).The SHUNT is use the MOSFET internal resisitor.

Maybe implementing software UART using LED pins...

I would like to play and try implement the angle observer that Shane Colton did!!

I am very busy,but i will try my best to implement firmware to prove JinHui controller and ECU controller can do foc.

 

[casainho]

I am very busy,but i will try my best to implement firmware to prove JinHui controller and ECU controller can do foc.

You don't need to prove nothing.

I think JinHui may be the best option. Lishui don't seem to have high power controllers, contrary to JinHui controllers.
EUC1 controller may be good to play with and test, because of the 128kbytes flash memory and considering the microcontroller should be very similar.

But would be great to find a controller that could do PWM of 30KHz or more, for fast eRPM motors!!

 

[casainho]

I tried the 0.5 degrees resolution for the angle but didn't found any improvement. After tried to have 0.5 degrees + 10 bits PWM: the code did fail and I am pretty sure is a limitation of the SDCC compiler or on the code, like max RAM size...

 

[stancecoke]

The new controller arrived today. I've done some measurements on the test bench with the original firmware. The effiency is worse at higher mechanical loads in comparison to the 12 FET Lishui...
With your SVM_4 (8bit) algorithm we seem to do quite the same as the original firmware
The motor runs about 370 erps at max speed with no load, but the control loop is not stable at this point, the correction angle swings.
The start up and switch to angle interpolation is not as smooth as the old solution in the torquesensor branch.

Regards
stancecoke

 

[casainho]

The new controller arrived today. I've done some measurements on the test bench with the original firmware. The effiency is worse at higher mechanical loads in comparison to the 12 FET Lishui...
With your SVM_4 (8bit) algorithm we seem to do quite the same as the original firmware
The motor runs about 370 erps at max speed with no load, but the control loop is not stable at this point, the correction angle swings.
The start up and switch to angle interpolation is not as smooth as the old solution in the torquesensor branch.

Great work, it is really important to have this feedback/benchmark!!
But I must say I do not like much the results, because at least on my Q85 motor I do not see a good sinewave on the phase B current and it makes a lot of noise/vibrations at max speed. My Q85 motor max speed is more like 600 eRPM (Q85 of 328 RPM version). Your 370 eRPS is sinewave of 42 points...

I also tested Lishui and it really makes big different is the motor noise when compared to this FOC (SVM_4 8 bits) - on the EUC2 motor, slow eRPS. On Q85, Lishui always fails to work around a speed where sinewave is about 50 points!! Maybe this is the max eRPM for Lishui (this happen also to you??)?? Maybe we should not drive motors with FOC at less than 50 points for eRPS??

I am being reading about the sensorless angle estimator and I want learn about it... would be possible to run on S06S?? maybe a very low resolution version and if so would bring any advantage??

Also I found what seems to be the original values for the SVM and I want to try them!!

The start up and switch to angle interpolation is not as smooth as the old solution in the torquesensor branch.

Maybe you can try change the speed values for each transition and also you can disable MOTOR_STATE_RUNNING_INTERPOLATION_60_DEGREES or MOTOR_STATE_RUNNING_INTERPOLATION_360_DEGREES by commenting each respective line.

      if (ui16_motor_speed_erps > 50)
      {
	ui8_motor_state = MOTOR_STATE_RUNNING_INTERPOLATION_360_DEGREES;
      }
      else if (ui16_motor_speed_erps > 25)
      {
	ui8_motor_state = MOTOR_STATE_RUNNING_INTERPOLATION_60_DEGREES;
      }
      else
      {
	ui8_motor_state = MOTOR_STATE_RUNNING_NO_INTERPOLATION_60_DEGREES;
      }

Also the initial angle value is important, try change it: #define MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT 235

 

[KingQueenWong]

I implemented open loop foc firmware on the EUC2 controller board(Not be tested).
Finally,i will implement foc firmware on the Lishui and JinHui and etc.
https://github.com/KingQueenWong/BMC_FOC

 

[casainho]

I implemented open loop foc firmware on the EUC2 controller board(Not be tested).
Finally,i will implement foc firmware on the Lishui and JinHui and etc.
https://github.com/451506709/BMC_FOC

Nice TIM3_IRQHandler code!! And that SineCosine function seems great also, maybe I need to adopt it for Kuteng firmware

My suggestion is also for you to start thinking on the observer: Shane Colton have good documentation for his observer that works as a virtual hall sensors and so easy to integrate on code like yours that use hall sensors: https://eggelectricunicycle.bitbucket.io/EmbeddedFiles/19-sensorless_gen1_Rev1.pdf

I think JinHui have the most advantages and if you start develop to it, I may join with you.

 

[stancecoke]

I implemented open loop foc firmware on the EUC2 controller board(Not be tested)

That's great, I'm looking foreward to see your motor run with this firmware. You use DMA for ADC reading, that should be much faster. But I think that doesn't work with a STM8.
Wich toolchain do you use with the STM32?

@casainho: In the german forum there is a request to clean up the Github repo a little. Do you think it is the right time to update the master branch? He asks "what is the bottleneck" in the STM8 code, also. I don't no exactly at wich point we could improve the code to make it working faster....

regards
stancecoke

 

[casainho]

I implemented open loop foc firmware on the EUC2 controller board(Not be tested)

You use DMA for ADC reading, that should be much faster. But I think that doesn't work with a STM8.
Wich toolchain do you use with the STM32?

@casainho: In the german forum there is a request to clean up the Github repo a little. Do you think it is the right time to update the master branch? He asks "what is the bottleneck" in the STM8 code, also. I don't no exactly at wich point we could improve the code to make it working faster....

Yes, STM8 do not have DMA...
I bet that the toolchain is GCC (I don't see a Makefile on the sources...??)

Why do you think the users of that forum do not write in EN, why they don't prefer to write here on the official forum thread??

I am looking to run the motor with the same original sinewave. If I get good results, they I want to change to it. Then I think I will stop the experiments for now and focus on the max and over current control. But even before that, there is the need of PI controller for the FOC IQ current automatic adjustment, as also need to reed ID current...
I hope at the end of today to have the original sinewave tested.

 

[stancecoke]

I bet that the toolchain is GCC (I don't see a Makefile on the sources...??)

The makefile is located in the debug-folder

Why do you think the users of that forum do not write in EN, why they don't prefer to write here on the official forum thread??

Because it's much easier to write in your native language?! :wink:

Then I think I will stop the experiments for now and focus on the max and over current control. But even before that, there is the need of PI controller for the FOC IQ current automatic adjustment, as also need to reed ID current...

OK, can I help at any point? A first try to limit battery current is implemented in the torquesensor branch (update_setpoint) already.

regards
stancecoke

 

[casainho]

Why do you think the users of that forum do not write in EN, why they don't prefer to write here on the official forum thread??

Because it's much easier to write in your native language?! :wink:

Then I would be alone on this project, talking in portuguese on the portuguese forum "Nova Energia". I think we all understand that having devs from Portugal, China, German, etc, means we really need to write in EN.
Maybe you can persuade them to join us here?

OK, can I help at any point? A first try to limit battery current is implemented in the torquesensor branch (update_setpoint) already.

Maybe implement the PI controller (look as I did on the EUC firmware). We will need that kind of controller for ID current also (I think) and for sure we will need for speed control.
I think it should run on main and with higher priority (higher than throttle/PAS) and I don't know the frequency, but maybe 1/100 second?? We will have new read IQ values every 2 or 1ms max and they are low pass filtered so 10 or 20ms seems a good value for the PI controller frequency.

No floats, 8 bits would be great.

// Calculate phase/angle correction value to try keep id current = 0
//------------------------------------------------------------------------
static float correction_value = 0;

// I
correction_value = qfp_fsub(correction_value, qfp_fmul(K_POSITION_CORRECTION_VALUE, id));

// D
static float id_old = 0;
float delta = qfp_fsub(id, id_old);
id_old = id;
correction_value = qfp_fsub(correction_value, qfp_fmul(D_POSITION_CORRECTION_VALUE, delta));


if ((duty_cycle < 5 && duty_cycle > -5) || motor_speed_erps < 80) // avoid PI controller windup
{ // motor_speed_erps < 80 seems a good value to avoid motor stalling at start up, very low speed
correction_value = 0.0;
}
if (correction_value > 30.0) { correction_value = 30.0; }
if (correction_value < -30.0) { correction_value = -30.0; }
position_correction_value = (int) correction_value;
// ------------------------------------------------------------------------

https://github.com/EGG-electric-unicycle/firmware-gen2_boards/blob/modifiedFOC-motorMicroWorks30kmh/motor_foc.c

 

[KingQueenWong]

I implemented open loop foc firmware on the EUC2 controller board(Not be tested)

That's great, I'm looking foreward to see your motor run with this firmware. You use DMA for ADC reading, that should be much faster. But I think that doesn't work with a STM8.
Wich toolchain do you use with the STM32?

@casainho: In the german forum there is a request to clean up the Github repo a little. Do you think it is the right time to update the master branch? He asks "what is the bottleneck" in the STM8 code, also. I don't no exactly at wich point we could improve the code to make it working faster....

regards
stancecoke

PC:Windows7 X64
Toolchain：gcc-arm-none-eabi-4_9-2014q4-20141203-win32.exe
Development Tool:Eclipse oxygen

 

[casainho]

Ok I got the motors running with the original sinewave. Seems to me they are a bit more silent - stancecoke, can you please test??
And then I found on Q85 that FOC/motor starts to eat much current/failing before the max throttle... I went and saw that happens when the eRPM is lower than 3.4ms (about 50 point do draw the sinewave -- very similar result of Lishui controller!!).
Then I verified that I could increase PWM frequency, did that and changed from 16.6kHz to 22.857kHz and now the motor runs faster and as expected by the math, could run at up 2.5ms eRPM (about 50 point do draw the sinewave -- this time motor did run faster than with Lishui controller!!, about 35% faster).

stancecoke, can you please test?? you have on SVM_5, the last 2 commits with/without increased PWM frequency, as you can see on the commit log.

 

[casainho]

The motor runs about 370 erps at max speed with no load, but the control loop is not stable at this point, the correction angle swings.

370 eRPS is the nominal speed of that motor? or is higher than nominal?

The new controller arrived today. I've done some measurements on the test bench with the original firmware. The effiency is worse at higher mechanical loads in comparison to the 12 FET Lishui...

Looking at that graph, maybe we could change the angle with increasing load/motor current?? I would say that for that, the original firmware sinewave is the best to read motor current. Than I would adapt the "508 <->510" interval accordingly to motor speed. I think the issue may be with hall sensors not representing correctly the rotor position as motor current increases (advantage of the sensorless estimator). Would be great if we could get near the efficiency of the Lishui controller:

if (ui16_motor_speed_erps > 7)
{
if (ui16_ADC_iq_current_filtered > 510)
{
ui8_position_correction_value++;
}
else if (ui16_ADC_iq_current_filtered < 508)
{
ui8_position_correction_value--;
}
}

By the way, looking at motor current, we can perfectly detect when max eRPM is achieved... current increases a lot on that situation.

 

[stancecoke]

Ok I got the motors running with the original sinewave.

What do you mean with "original sinewave"? The saddle-form values from the pdf above?

this time motor did run faster than with Lishui controller!!

The sensorless 12 FET Lishui stops working at high speed suddenly, I have the same experience.

stancecoke, can you please test?? you have on SVM_5, the last 2 commits with/without increased PWM frequency, as you can see on the commit log.

OK, I'll test the latest commit. Perhaps I should try to run the motor with 48V to reach really high speed, as the shengyi middrive is a 48V system originally...

regards
stancecoke

 

[casainho]

Ok I got the motors running with the original sinewave.

What do you mean with "original sinewave"? The saddle-form values from the pdf above?

Yes.

The orignal is the bottom one and I was using the top one:

this time motor did run faster than with Lishui controller!!

The sensorless 12 FET Lishui stops working at high speed suddenly, I have the same experience.

I would like to test the other JinHui FOC controller to see if does the same behaviour. Maybe Sinewave can't work at higher speeds (unless using high speed PWM hardware) and this controllers are good only for direct drive motor. Geared motor would need block commutation/6 steps.

 

[stancecoke]

the latest commit of SVM_5 branch isn't working good with my Shengyi Motor. Motor speed is ~320erps @ 36V and ~420erps @ 48V
With the 8 bit SVM_4 code speed @48V is about 470erps.

Maybe implement the PI controller (look as I did on the EUC firmware).

Hmm, why do you think a PI controller would bring an improvement? If I look at the logged data, the IQ current jumps from quite big positive values to quite big negative values with just one digit change in correction angle. I think with this behavior, the PI control will improve nothing....


regards
stancecoke

 

[casainho]

the latest commit of SVM_5 branch isn't working good with my Shengyi Motor. Motor speed is ~320erps @ 36V and ~420erps @ 48V
With the 8 bit SVM_4 code speed @48V is about 470erps.

Maybe because max duty_cycle is now 700 but the table has max of 255, try to multiply the values for higher value -- I will update the table values later.

(700 - 1), // clock = 16MHz; counter period = 1024; PWM freq = 16MHz / 700 = 22.857kHz;

Maybe implement the PI controller (look as I did on the EUC firmware).

Hmm, why do you think a PI controller would bring an improvement? If I look at the logged data, the IQ current jumps from quite big positive values to quite big negative values with just one digit change in correction angle. I think with this behavior, the PI control will improve nothing....

Ok, on that situation will not help but will on accelerations or like when I blocked with my hand and saw a big delay the adjustment, a ramp while it should be faster when delta/error is big.

 

[stancecoke]

when I blocked with my hand and saw a big delay the adjustment, a ramp while it should be faster when delta/error is big.

OK, for that a simple P-controller will be sufficient, an integral part is not necessary....

Maybe because max duty_cycle is now 700 but the table has max of 255, try to multiply the values for higher value

??? I don't understand this.

I will now try to merge your SVM_4 to my torquesensor branch.
regards
stancecoke

 

[casainho]

Maybe because max duty_cycle is now 700 but the table has max of 255, try to multiply the values for higher value

??? I don't understand this.

Ok, you can checkout now SVM_5 that have full amplitude value (700) for the PWM.

I will now try to merge your SVM_4 to my torquesensor branch.

I am expecting to use instead SVM_5 with the original SVM because:
- motor current seems easier to read
- less commutations per eRPS should mean less heat (the other I was using should heat more the mosfets)
- less processing power on PWM cycle meaning I could increase PWM frequency 35% and so max eRPM speed is now 35% higher (but should increase the heat on the mosfets!!)

 

[casainho]

With original sinewave, it is possible to read the motor current while with the other is very difficult, seems to be needed some math to understand where the pulse current is in time -- impossible to do on the STM8.

I was testing SVM_4 but since max duty_cycle is 237, it seems to work best but after changing to 255, it works also bad as original sinewave.
ui8_temp = (uint8_t) map (ui16_adc_value, ADC_THROTTLE_MIN_VALUE, ADC_THROTTLE_MAX_VALUE, 0, 237);

For the motor to work well, I think we need to limit motor max current and also verify the max eRPS. My motor seems to start working incorrectly with eRPS < 3.4ms.