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

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:

[youtube]BsCGRwtaQO0[/youtube]
 
casainho said:
honya96 said:
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 8)
 
casainho said:
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
 
honya96 said:
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.

honya96 said:
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 8)
It runs forever when duty_cycle increases but never decreases again. I got that when this condition on motor.c code runs:
Code:
  // 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.
 
honya96 said:
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.

honya96 said:
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
 
stancecoke said:
honya96 said:
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.

honya96 said:
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 :wink: original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)
 
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.
 
honya96 said:
But the offset will come in handy for more people I believe :wink: 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.
 
honya96 said:
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:
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
 
stancecoke said:
honya96 said:
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:
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.
 
casainho said:
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 :wink:

regards
stancecoke
 
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.
 
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.... :wink:
 
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 said:
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?

honya96 said:
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.bitbucket.io/development/Datasheets_and_application_notes--Endless-sphere.com_forum_messages--2018.01.10_-_How_to_measure_FOC_READ_ID_CURRENT_ANGLE_ADJUST.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.
 
Found no value working, maybe its 60° hall.. :roll: 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.
 
geofft said:
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:
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??

geofft said:
...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-unicycle/documentation/wiki/MicroWorks-30B4-30kmh-controller-board-with-bluetooth#Battery_voltage_and_power

geofft said:
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.... :wink:
I have no idea.
Happy to know that the rode went really well :)
 
casainho said:
geofft said:
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.

geofft said:
...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. :wink:
Lipoly Voltage vs_ State of Charge.jpg
 
geofft said:
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.

geofft said:
I always use this table, seems to give a very accurate state-of-charge indication. :wink:
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:
  // 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 said:
I am gonna confirm the wattage correction in few minutes, but I can say allready that it reads atleast 20% too high.
Great! And then, please tell us how did you measure.
 
So its much higher.
Standby 6.9-7w - 20-21 on lcd. No load 46-48w - 120-138 on lcd. 400w real - 840-860lcd .

Motor current 40A at tool gives 10-11 real. :shock: 15A at tool gives 3.5-3.8 real.

Measured by 8$ AE wattmeter (checked to work well)
 

Attachments

  • 20180114_131103-1024x576.jpg
    20180114_131103-1024x576.jpg
    68.9 KB · Views: 2,264
honya96 said:
So its much higher.
Standby 6.9-7w - 20-21 on lcd. No load 46-48w - 120-138 on lcd. 400w real - 840-860lcd .

Motor current 40A at tool gives 10-11 real. :shock: 15A at tool gives 3.5-3.8 real.

Measured by 8$ AE wattmeter (checked to work well)
That is really crazy values!! I think we should not consider low values like under 3amps. On your measures, I would only consider the "400w real - 840-860lcd" and that would mean LCD is showing double of wattage.

1. What controller did you use? it is an unchanged controller?
2. how many shunts does it have?
3. Did you use latest firmware? (because I already halved the wattage on LCD on last days....)

Also, let's compare with geofft measures.
 
6fet as the 2 on photos I sent. Its back to original as much as I was able to get. 1 original shunt.

It should be latest firmware from yesterday flashed by your tool.

50A set at tool blew my 8A fuse so I replaced with 20A and It drives already better than original I would say. Great work. I am done testing gearmotor at 10s

Next is 6fet with 14s battery and direct motor on the bigger bike. If it runs, then flashing the 18fet.

Bug report: PAS at 0 runs motor when pedal rotating backwards.
slow reaction to throttle and PAS while running and standstill also.
Does not start the motor with a bit of throttle while icon is showing it should run.
 
Back
Top