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

[geofft]

Casainho: I seem to have got the problem back with flashing empty battery signal and no motor functions (LVC triggered..?)
You fixed this a couple of days ago, could it have sneaked back into the github download?

Casainho, forget this, looks like my laptop software installation has got corrupted, I've cocked-up somewhere.
No more time now, will re-install it later, sorry to bother you.

[casainho]

And a question, 6fet has 1 shunt and 12fet has 2 of them, I wonder, isnt there a need to change something in firmware so they both measure correctly? (I want to use 4 of them in 18fet)

There isn't yet. On my S06S, I did measured each 8 bits ADC step (20mV) to be equal to 0.5A: 5V / 256 = 0.02V.
My S12S had 2 shunts but I cut one, so I can't now measure the real value for S12S.

Please measure for your controller and say the value, then I can put on the firmware as an option.

[casainho]

I am not really happy with riding experience with my direct drive motor.
The torque sensor outputs a value that is a peak signal every pedals rotation and I feel that peak on the motor, if I control directly the motor duty_cycle. Ideally, the torque signal would be stable continuous over a pedals rotaion and I think that would be veey good for the motor....

I need to think more about this...

I got no idea about the regen current. I can measure how much the stock firmware gives if you want but its strong only at high speed. Under 20km/h unusable.

The electric unicycles I did ride, had motors similar to Q11 and the same PWM control scheme our firmware uses, and they do break almost at to spto point -- it must, other Segways, hoverboards and electric unicycles could not exist.

[Buk___]

I got no idea about the regen current. I can measure how much the stock firmware gives if you want but its strong only at high speed. Under 20km/h unusable.

The electric unicycles I did ride, had motors similar to Q11 and the same PWM control scheme our firmware uses, and they do break almost at to spto point -- it must, other Segways, hoverboards and electric unicycles could not exist.

You might want to read this reply by AmberWolf to my question about regen.

In particular, I think this para may be relevant to you:

--complex and more common way is the controller repeatedly "shorts" the motor windings to create pulses of much higher voltage to be able to cause current flow even at motor speeds which would not otherwise be able to do it, so it can brake down to much lower speeds. Some are better at this than others, and some are more efficient at it (the less efficient ones make the motor and controller hotter from the waste heat than the more efficient ones).

On my KT S12SN controller, there is an option, C13, that is described in the manual as:

Code: Select all

 C13 ABS brakes of the controller and parameters of anti-charge control 

C13 parameter definition table: 
C13 Value      ABS braking strength           Energy recovery efficiency 
       0           None                                   None 
       1           Class 1 braking strength       Best energy recovery efficiency   
       2           Class 2 braking strength       General energy recovery efficiency 
       3           Class 3 braking strength       Weaker energy recovery efficiency 
       4           Class 4 braking strength       Poor energy recovery efficiency   
       5           Class 5 braking strength       Bad energy recovery efficiency 
       
The recommended value of C13 is 1; other values need to be chosen with caution for 
use.   
Be  sure  to  note:  the  higher  is  the  braking  intensity  level,  and  the  braking  strength 
will be greater, the greater damage to the motor shaft accordingly. 

Until I read AmberWolf's para above the weaker braking == better energy recovery & Stronger breaking == least energy recovery didn't make sense to me; now it seems clear that this controller can be configured to either feed whatever is generated by the motor on overrun back to the battery (C13=1) or actively feed reverse polarity power to the windings to slow the motor down (C13=5); or (somehow) a mixture of the two (C13=2..4).

Note:I have no real knowledge of this, I'm just passing along some info that seems it might be relevant to what you are doing, that you might otherwise miss.

I'm going to buy a wattmeter(or perhaps 2), and if I can work out how to put one in circuit with one of the phase windings, I will try to work out what the standard firmware does with that settings value.

[casainho]

I would say that parameter is just max regen current.

Now I remember to see many times on oscilloscope the motor PWM signals for the 3 phases and I just saw always the same, no short of windings.
The unicycle must brake as also quick change motor rotation direction and that is very smooth, the transition as also all the brake and also motor accelerating. Here an example of changing direction and that I never saw short of phases in oscilloscope:

[honya96]

And a question, 6fet has 1 shunt and 12fet has 2 of them, I wonder, isnt there a need to change something in firmware so they both measure correctly? (I want to use 4 of them in 18fet)

There isn't yet. On my S06S, I did measured each 8 bits ADC step (20mV) to be equal to 0.5A: 5V / 256 = 0.02V.
My S12S had 2 shunts but I cut one, so I can't now measure the real value for S12S.

Please measure for your controller and say the value, then I can put on the firmware as an option.

I do not understand this, I think you just need to know that there will be 4 of them. Or a mOhm value setting will be good also or just any value i can change by trial and error to get the amps I have set?

To the regen types. From my basic understanding I think there are 3 types. The real regen(charging battery), shorting phases, and powering them to slow down.

Best controllers can do all 3 types. Here we should be okay just with charging and shorting. (We get enough braking but no need to waste power)

Casainho, I wonder as you wrote its for moderate accelerations (not for my big bike) then how it can be used on unicycles which needs faster accelerations than I do (I mean in theory, to react that fast.)

On the testbike I am still having problems with the zero current. Once the motor starts it runs forever. I think some offset of the zero value will help here also but now for me its easier to do hardware repair of shunt and see if it helps. I will add brake lever and try a little ride tomorow

[stancecoke]

The torque sensor outputs a value that is a peak signal every pedals rotation and I feel that peak on the motor,

Therefore the torque is avaraged over one crank revolution in the torque simulation fork...
To have assistance by just putting force on the pedal at zero speed, in the "forumscontroller" code is checked, if the value of human power, or the direct torque value is higher. The bigger value is used for the motor control.

regards
stancecoke

[casainho]

I do not understand this, I think you just need to know that there will be 4 of them. Or a mOhm value setting will be good also or just any value i can change by trial and error to get the amps I have set?

Ok, how can you do it? Try to run the motor at a fixed battery current, like on a bike training roller, like 3 amps (measure with an amperimeter). At the same time, measure the voltage on the STM8 pin 23: PE7 (ADC_AIN8) | motor_total_current_filtered. Repeat for other current values, more samples of the measures, the better.
Also measure the STM8 pin 23 with motor stopped, that will be the voltage respective to zero battery("motor") current voltage.

On the testbike I am still having problems with the zero current. Once the motor starts it runs forever. I think some offset of the zero value will help here also but now for me its easier to do hardware repair of shunt and see if it helps. I will add brake lever and try a little ride tomorow

It runs forever when duty_cycle increases but never decreases again. I got that when this condition on motor.c code runs:

Code: Select all

  // verify if there is regen current > 0 (if there is happening regen) and
  // if battery voltage is over or equal to absolute battery max voltage, and if so
  // reduce regen current
  else if ((ui8_adc_motor_total_current < ui8_motor_total_current_offset) &&
      (UI8_ADC_BATTERY_VOLTAGE >= ((uint8_t) ADC_BATTERY_VOLTAGE_MAX)))
  {
    if (ui8_duty_cycle < 255)
    {
      ui8_duty_cycle++;
    }
  }

The thing was for me:
1. my mistake of cells voltage number and so was like if battery was charge to max value, so regen never happens and the only way is to keep the same duty_cycle or increase it
2. I was running the motor with a lab power supply, it does not receive back current and quickly increases the voltage at his terminals, will happen then the case 1.

[stancecoke]

On the testbike I am still having problems with the zero current. Once the motor starts it runs forever. I think some offset of the zero value will help here

I just added a small offset at github. You can try, with my testbench it works.

but now for me its easier to do hardware repair of shunt and see if it helps.

What do you mean with "repair"?

regards
stancecoke

[honya96]

On the testbike I am still having problems with the zero current. Once the motor starts it runs forever. I think some offset of the zero value will help here

I just added a small offset at github. You can try, with my testbench it works.

but now for me its easier to do hardware repair of shunt and see if it helps.

What do you mean with "repair"?

regards
stancecoke

Thank you, will try. With repair I mean get exactly to the original resistance, maybe just desolder and put new one. It was covered with solder to get from 20 to 25A on original firmware and then recovered back to like 20.5 maybe but as I see now here its a problem. But the offset will come in handy for more people I believe original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)

[honya96]

Casainho, thanks for you help, the 4 shunt controller testing is far.. but I gues then I will be ok with setting the zero and 15A at config tool will mean 60 for me.. easy.

[casainho]

But the offset will come in handy for more people I believe original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)

So If I understand, it will not be only an offset, maube an offset + diferent ADC step... -- and If so, I think will be hard for people, for instance, let's see how can you deal with that.
But, I would be happy if people can use the firmware on modded more powerful hardware!!
Would be great if you can resume how to do it, what changes are needed in firmware and let's write an howto.

[stancecoke]

original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)

Thats no problem, as the firmware reads in the zero current value at every start up of the system. The problem is, that the delta between setpoint and actual value of battery current has to be quite big to make the i16_output value bigger than 1 respectivly smaller than -1.

Code: Select all

i16_error = ((int16_t) ui16_target_current_10b) - i16_motor_current;
  i16_output = i16_error * MOTOR_CURRENT_CONTROLLER_KP;

  // limit max output value
  if (i16_output > MOTOR_CURRENT_CONTROLLER_OUTPUT_MAX) i16_output = MOTOR_CURRENT_CONTROLLER_OUTPUT_MAX;
  else if (i16_output < (-MOTOR_CURRENT_CONTROLLER_OUTPUT_MAX)) i16_output = -MOTOR_CURRENT_CONTROLLER_OUTPUT_MAX;
  i16_output >>= 5; // divide to 64, avoid using floats

  

As there is no "classical" integral part with floating point arithmetic in the control loop, the delta can't be controlled completely by summig up the error by the time.
Setting the zero current value to a slightly negative value is just a trick to make the delta bigger.
I don't know, if we can do a "real" PI-Control like in the torque-simulation fork in the fast loop, or if the floating point operation is to slow...

regards
stancecoke

[casainho]

original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)

Thats no problem, as the firmware reads in the zero current value at every start up of the system. The problem is, that the delta between setpoint and actual value of battery current has to be quite big to make the i16_output value bigger than 1 respectivly smaller than -1.

Code: Select all

i16_error = ((int16_t) ui16_target_current_10b) - i16_motor_current;
  i16_output = i16_error * MOTOR_CURRENT_CONTROLLER_KP;

  // limit max output value
  if (i16_output > MOTOR_CURRENT_CONTROLLER_OUTPUT_MAX) i16_output = MOTOR_CURRENT_CONTROLLER_OUTPUT_MAX;
  else if (i16_output < (-MOTOR_CURRENT_CONTROLLER_OUTPUT_MAX)) i16_output = -MOTOR_CURRENT_CONTROLLER_OUTPUT_MAX;
  i16_output >>= 5; // divide to 64, avoid using floats
  i16_output = ui8_duty_cycle + i16_output;
  

As there is no "classical" integral part with floating point arithmetic in the control loop, the delta can't be controlled completely by summig up the error by the time.
Setting the zero current value to a slightly negative value is just a trick to make the delta bigger.
I don't know, if we can do a "real" PI-Control like in the torque-simulation fork in the fast loop, or if the floating point operation is to slow...

stancecoke, I remember when I did that, I tried hard to do a code not using floats as it is very slow... but, maybe we need that code.

I remember to play with the integral but for some reason I didn't like the results. Anyway, we can try again, with floats and integral part. I wasn't motivated to do something complex, because if that will be a PI controller and will need user to tune the coefficients... more complexity while the original don't have that need for user tune!! I think we should simplify in a way to have no more options for user to tune, like the original firmware.

[stancecoke]

I wasn't motivated to do something complex, because if that will be a PI controller and will need user to tune the coefficients... more complexity while the original don't have that need for user tune!! I think we should simplify in a way to have no more options for user to tune, like the original firmware.

The user won't have to tune the PI coefficients. I think we will find a setting that works for most Motor/Battery/Controller combinations.
And we still don't need to do the mathematics in a fast loop, as I have already mentioned several times

regards
stancecoke

[casainho]

But I think both controllers can coexist, I don't see any problem of using both on current firmware.
The only issue is that the sloow loop controller doesn't work so well because was bad implemented.

I am busy and there are a lot of things to implement. I will not implement most of them as fast a did last months. Just so everyone can have the right expectations.

[geofft]

Found some time for a test ride and some playtime in the garage today, a couple of things you may like to know.

The motor wattmeter is improved but still reads about 30% high (was 100%+ high previously). Damping is also improved, now takes maybe 5secs to reach zero after a motor cut, maybe should be slightly less, not a big deal.

The battery indicator is not quite right, with 'sensible' voltages entered in the main.h voltage lookup table (similar to default values) it was generally reading 1-2 bars too high. My battery was almost fully discharged, so whilst charging was able to enter lookup table values that gave a correct indication. The results were surprising, generally needing values around 0.25v higher than you might expect:-

// Considering the follow voltage values for each li-ion battery cell
// State of charge | voltage
#define LI_ION_CELL_VOLTS_MAX 4.46
#define LI_ION_CELL_VOLTS_100 4.23
#define LI_ION_CELL_VOLTS_80 4.07
#define LI_ION_CELL_VOLTS_60 3.94
#define LI_ION_CELL_VOLTS_40 3.89
#define LI_ION_CELL_VOLTS_20 3.85
#define LI_ION_CELL_VOLTS_0 3.75
#define LI_ION_CELL_VOLTS_MIN 3.0

...it seems the code that runs the battery indicator may not be operating exactly as you intended, or maybe I have a fault with my controller?

Another 'oddity', when reflashing these numbers and powering back up was that I was occasionally greeted with LVC indicated on the lcd3 (flashing battery icon, motor disabled). Couldn't really work out what was causing this, but the real problem was that I couldn't escape from it, whatever I changed in main.h or anywhere else in the firmware (and re-flashing) I still got LVC.
Eventually found that deleting the entire firmware folder on the laptop (BMSBattery_S.....) then re-installing a new copy restored normal operation. This worked every time, so it seems that when LVC was triggered something was being flagged in the firmware folder to lock it. Any ideas?

All just details really, have to say the bike rode really well....

[honya96]

Guys I think my testbike motor fails to switch to FOC, when motor start interpolatiom 60 degrees set to 200 it runs up to high speed and then starts coughing when set 40 it starts sooner. Is it related with only FOC ID angle or also rotor offset? This motor needed the C2 parameter set at 5 with stock fw.

Edit: Thanks stancecoke, motor stopping is improved.

[honya96]

Id angle at zero works best but far from usable, looks like it cant take negative.

[casainho]

Guys I think my testbike motor fails to switch to FOC, when motor start interpolatiom 60 degrees set to 200 it runs up to high speed and then starts coughing when set 40 it starts sooner. Is it related with only FOC ID angle or also rotor offset? This motor needed the C2 parameter set at 5 with stock fw.

Edit: Thanks stancecoke, motor stopping is improved.

I think you need mainly to play with MOTOR_ROTOR_OFFSET_ANGLE.
I would put fixed FOC_READ_ID_CURRENT_ANGLE_ADJUST = 127 and start play with MOTOR_ROTOR_OFFSET_ANGLE.

Out of curiosity, how did you find that C2 must be 5 for your motor, on stock firmware?

Id angle at zero works best but far from usable, looks like it cant take negative.

FOC_READ_ID_CURRENT_ANGLE_ADJUST can't take negative values, only from 0 up to 255. 127 is considered the "zero" value, and less than 127 are negative values...

See that you are adjusting this: https://opensourceebikefirmware.bitbuck ... DJUST.html

The thing is, FOC needs to keep motor current at a specific position, and that specific position is relative to hall sensor signal. A value o 127, means it will be at the same position at hall sensor. Please read that document.

[honya96]

Found no value working, maybe its 60° hall.. or I dont know.. some weird motor.

changed to newer one which worked at C2 - 0 (original fw) and now its ok.

First ride tomorow morning.

[casainho]

The motor wattmeter is improved but still reads about 30% high (was 100%+ high previously). Damping is also improved, now takes maybe 5secs to reach zero after a motor cut, maybe should be slightly less, not a big deal.

How did you measured to verify it is about 30% high? -- if we agree, I can just reduce that 25% or 30%, etc.

You can reduce and try by yourself the damping.

Code: Select all

void calc_motor_current_filtered (void)
{
  // low pass filter the current readed value, to avoid possible fast spikes/noise
  ui16_adc_motor_current_accumulated_10b -= ui16_adc_motor_current_accumulated_10b >> 2;
  ui16_adc_motor_current_accumulated_10b += ui16_adc_read_motor_total_current_10b ();
  ui16_adc_motor_current_filtered_10b = ui16_adc_motor_current_accumulated_10b >> 2;
  i8_motor_current_filtered_10b = ui16_adc_motor_current_filtered_10b - ui16_motor_total_current_offset_10b;
}

That 2 lines with >> 2, before was value 3. You can try reduce to 1 or 0, with 0, there will be no damping.
>> 2 is divide by 4; >> 1 is divide by 2. Maybe no damping will be ok, who knows if the LCD already damps that value??

...it seems the code that runs the battery indicator may not be operating exactly as you intended, or maybe I have a fault with my controller?

I just looked at the code and I found I could do some variable type optimizations -- can you please test?
I must say I tested by looking at my display and changing the lab power supply, and seems ti works well but I never verified in details.

Can you please write the SOC table, for what would be the correct values? And provide a link your references??

I took from here, from a 16S pack: https://github.com/EGG-electric-unicycl ... _and_power

Eventually found that deleting the entire firmware folder on the laptop (BMSBattery_S.....) then re-installing a new copy restored normal operation. This worked every time, so it seems that when LVC was triggered something was being flagged in the firmware folder to lock it. Any ideas?

All just details really, have to say the bike rode really well....

I have no idea.
Happy to know that the rode went really well

[geofft]

The motor wattmeter is improved but still reads about 30% high (was 100%+ high previously). Damping is also improved, now takes maybe 5secs to reach zero after a motor cut, maybe should be slightly less, not a big deal.

How did you measured to verify it is about 30% high? -- if we agree, I can just reduce that 25% or 30%, etc.

My estimate here is not scientific, the power maximum the motor draws (indicated on display) with the stock firmware is 800w, but the new firmware is showing 1150w. I can do some better tests with an ammeter in the battery supply if you prefer..?

Will play with wattmeter damping numbers and get back to you.

...it seems the code that runs the battery indicator may not be operating exactly as you intended, or maybe I have a fault with my controller?

I just looked at the code and I found I could do some variable type optimizations -- can you please test?
I must say I tested by looking at my display and changing the lab power supply, and seems ti works well but I never verified in details.

I'm beginning to think that the battery state-of-charge voltage figure (as reported from controller to display) is an imprecise number which varies with different controllers. This is maybe why the LCD3 provides for a large range of adjustment via the P5 parameter? So maybe we already have the solution by adjusting the voltage figures in the main.h lookup table. This works well enough for me, but will checkout your changes and let you know.

Can you please write the SOC table, for what would be the correct values? And provide a link your references??

I always use this table, seems to give a very accurate state-of-charge indication.

Lipoly Voltage vs_ State of Charge.jpg (32.17 KiB) Viewed 1200 times

[casainho]

My estimate here is not scientific, the power maximum the motor draws (indicated on display) with the stock firmware is 800w, but the new firmware is showing 1150w. I can do some better tests with an ammeter in the battery supply if you prefer..?

That would be great, if you can confirm with an external meter.

I always use this table, seems to give a very accurate state-of-charge indication.
Lipoly Voltage vs_ State of Charge.jpg

I just updated the table on main.h but I also had to update the code that calc the number of bars:

The BATTERY_PACK_VOLTS_100 is 4.20, that is the voltage when it leaves the charger and will be at that value almost no time when running the motor, so, we can't consider the 4 bars | full charge for that voltage. So, I consider the battery is full between 100% and 80%, this seems logic to me.

Code: Select all

  // calc battery pack state of charge (SOC)
  ui16_battery_volts = ((uint16_t) motor_get_ADC_battery_voltage_filtered ()) * ((uint16_t) ADC_BATTERY_VOLTAGE_K);
  if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_80)) { ui8_battery_soc = 16; } // 4 bars | full
  else if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_60)) { ui8_battery_soc = 12; } // 3 bars
  else if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_40)) { ui8_battery_soc = 8; } // 2 bars
  else if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_20)) { ui8_battery_soc = 4; } // 1 bar
  else { ui8_battery_soc = 3; } // empty

[honya96]

I am gonna confirm the wattage correction in few minutes, but I can say allready that it reads atleast 20% too high.