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

[nieles]

actually it doesnt matter where the 'clean' word is. my command and your command yield the same outcome.

i found an ever better fix:

Code: Select all

clean:
	@echo "Cleaning files..."
	@clean.bat
	-rm -f *.asm 
	-rm -f *.rel
	-rm -f *.lk
	-rm -f *.lst
	-rm -f *.rst
	-rm -f *.sym
	-rm -f *.cdb
	-rm -f *.map
	-rm -f *.elf
	-rm -f *.adb 
	@echo "Done."

this works even if i put MinGW and WINAVR back in path.

[honya96]

@Casainho - Can you share your 48V battery specs?
I wonder if you are able to test at 40A with your direct motor, so you can tune the firmware for higher powers. I am still not confident to test it..

I believe the phase current controll at zero/near zero speed is not ok yet.

Edit: 48v13Ah? Probably 13s6p 2.2Ah 10A LG cells so its ok for quite long 60A bursts if you bypass the bms.

[stancecoke]

I believe the phase current controll at zero/near zero speed is not ok yet.

We are not controlling the max value of the phase current. The phase current is only used for doing the simplyfied FOC.
Even this control is not active at very low speed.

Code: Select all

 if (ui16_motor_speed_erps > MOTOR_ROTOR_ERPS_START_INTERPOLATION_60_DEGREES)
    {
      // read here the phase B current: FOC Id current
      ui8_adc_id_current = UI8_ADC_PHASE_B_CURRENT;

      if (ui8_adc_id_current > 127) { ui8_angle_correction++; }
      else if (ui8_adc_id_current < 125) { ui8_angle_correction--; }
}

regards
stancecoke

[casainho]

@Casainho - Can you share your 48V battery specs?
I wonder if you are able to test at 40A with your direct motor, so you can tune the firmware for higher powers. I am still not confident to test it..

I believe the phase current controll at zero/near zero speed is not ok yet.

Edit: 48v13Ah? Probably 13s6p 2.2Ah 10A LG cells so its ok for quite long 60A bursts if you bypass the bms.

Yes, I think my battery is that one 48v13Ah, that I bought from BMSBattery.

I am not motivated to test/develop for controllers I don't use... like that of 40A. Anyway, I would do like that: choose a "constant" current like 4A and measure the voltage at STM8 ADC input pin, repeat with other currents like 6A and 8A. I expect the behavior is the same for higher currents.
Look, STM8 measures 2 different currents:
1. battery/"motor" current that is measured with the power shunt and is amplified using an opamp, where the final voltage is an input to STM8 ADCx pin
2. phase B current that is measured with the hall current sensor power and outputs a voltage "directly"(no amplification) to an input to STM8 ADCx pin

I bet that a more powerful controller as different than S06S and S12S:
- related to 1. -- has a different gain on the shunt itself (different shunt value) or on the opamp so we just need to know the gain and we can measure with lower currents, no need to use near the max current
- related to 2. -- we just need to know the gain of hall current sensor and for that we need to read the datasheet of it

I can help to guide you doing 1. and 2. -- you would need a power supply that can holds like 10A or maybe less. Or a battery with a fast fuse. A multimeter for reading voltage on STM8 ADCx pins.

[stancecoke]

We've already exercised the procedure to get the right calibration factors for the battery current measurement successfully!
https://endless-sphere.com/forums/viewt ... 8#p1352618

This can be easily repeated for different shunt/OP-gain values of any controller...

regards
stancecoke

[honya96]

We are not controlling the max value of the phase current. The phase current is only used for doing the simplyfied FOC.

Well I think original firmware does limit it or atleast cuts when over limit. Will do some tests...

I think that it will be needed, or if not possible, a ramp-up of max battery current linear with erps up to like 20 should do the job.

Problem is even when casainho has 12fet with 1000w direct hub, it can ask for too much phase amps from standstill and blow the mosfets.

[casainho]

We are not controlling the max value of the phase current. The phase current is only used for doing the simplyfied FOC.

Well I think original firmware does limit it or atleast cuts when over limit. Will do some tests...

I think that it will be needed, or if not possible, a ramp-up of max battery current linear with erps up to like 20 should do the job.

Problem is even when casainho has 12fet with 1000w direct hub, it can ask for too much phase amps from standstill and blow the mosfets.

Master branch also cuts if you block the motor for some seconds. The current is ALWAYS being limited to max configured current!!

[honya96]

I am not motivated to test/develop for controllers I don't use... like that of 40A.

I dont understand how can you not be motivated to run 2kw ~65kph when your bike can handle it maybe just my mind set... your s12s is not 40A? Or you have it and dont use?

Is 2. Needed to run the FOC correctly?
S12S phase current sensor is 50A and 18fet is 100A

I believe stock 2 shunt 18fet will work the same as 2 shunt 12fet..

To your last post: stock fw cuts when you floor it too fast from dead stop, (when asking for too high phase current)

[casainho]

I am not motivated to test/develop for controllers I don't use... like that of 40A.

I dont understand how can you not be motivated to run 2kw ~65kph when your bike can handle it maybe just my mind set... your s12s is not 40A? Or you have it and dont use?

Unfortunately I am not riding bicycle lately and just using car.
Also I don't have the firmware ready to run my ebike: direct drive motor and torque sensor. I am currently working on torque sensor.

Is 2. Needed to run the FOC correctly?
S12S phase current sensor is 50A and 18fet is 100A

I believe stock 2 shunt 18fet will work the same as 2 shunt 12fet..

On our firmware, currently, it is used only for FOC (as Stancecoke told before and did show the only piece of code that uses phase B current sensor signal, that only looks for 2.5V (127 value) and increase or decrease ui8_angle_correction:

Code: Select all

      // read here the phase B current: FOC Id current
      ui8_adc_id_current = UI8_ADC_PHASE_B_CURRENT;

      if (ui8_adc_id_current > 127) { ui8_angle_correction++; }
      else if (ui8_adc_id_current < 125) { ui8_angle_correction--; }

The ui8_angle_correction variable is the green line on this image -- read more here: https://opensourceebikefirmware.bitbuck ... rison.html

To your last post: stock fw cuts when you floor it too fast from dead stop, (when asking for too high phase current)

No point in talk about phase current to protect the motor as the hardware only has 1 phase current sensor, while we would need to have the 3 phase currents -- so we are using instead the motor current(the current that flows from the battery).

I want to understand what you mean by: "you floor it too fast from dead stop".

[casainho]

Read the throttle value, the direct torque-signal and the human power (human power averaged over one, or at least a half crank revolution) and give the highest value to the motor. With this, the support will start from zero speed, it will oszillate at startup, but it will be smooth from the point, where the human power value is higher than the simple torque value, the thumb throttle as highest priority and overrides the other values...

I think I got it, more or less as you suggested:


- the direct torque sensor value always has the oscillation, as expected and we can see on second line
- the processing algorithm:
-- when cadence is lower than 15RPM, the direct torque sensor value is used, as can be seen at left side of graph, the third line has the same oscilation when cadence (first line) is bellow 15 RPM
-- the filtered/processed signal is almost flat while the input signal has oscilation
-- this torque sensor, outputs a signal value when I am resting my feet on the pedals - as can be seen when there is an output value and cadence = 0 (this can be problematic, let's see how it goes in real testing ride)
-- I used 1 cadence RPM and output the max value

Now I need to test this on a real ride and see if I like it. Also I can test processing over 1/2 * 1 cadence RPM.

[casainho]

I am now happy with torque sensor, I tested on direct drive motor Q85, 24V battery, S06S controller.
The answer from torque sensor is reasonably fast and I don't feel any oscillation on the motor. Next I want to test with the direct drive motor as last time I was very unhappy with the oscillations...

The torque sensor is very sensitive but the value is after divided by 4 and multiplied by assist levels, so at assist level 5, the final torque sensor signal is multiplied by 1.25 and at assist level 1, the final torque sensor signal is multiplied by 0.25:

Code: Select all

void ebike_throttle_type_torque_sensor (void)
{
...
  // divide the torque sensor throttle value by 4 as it is very sensitive and multiply by assist level
  f_temp = (float) ((ui8_throttle_value_filtered >> 2) * lcd_configuration_variables.ui8_assist_level);
}

Also found 2 bugs that were solved by resetting PI controllers I term while we break, so when we release brakes, motor will not suddenly start:

Code: Select all

  // set PWM duty_cycle target value only if we are not braking
  if (!motor_controller_state_is_set (MOTOR_CONTROLLER_STATE_BRAKE))
  {
    // now use the lowest value from the PI controllers outputs
    motor_set_pwm_duty_cycle_target (ui8_min (
      motor_current_pi_controller_state.ui8_controller_output_value,
      wheel_speed_pi_controller_state.ui8_controller_output_value));
  }
  else
  {
    // keep reseting PI controllers so the I term will not increase while we are braking!
    pi_controller_reset (&motor_current_pi_controller_state);
    pi_controller_reset (&wheel_speed_pi_controller_state);
  }

[stancecoke]

Hmm, I don't understand your latest code in detail...
I can't see the typical sinusoidal shape in the torque-curve?!
Why don't you average the torque signal over a crank revolution? This would avoid the scatter.

I think you are doing many things much more complicated than necessary, e.g. a reset of the integral part of the controller should not be done to avoid sudden changes in the setpoint which could cause the motor to stutter. The control loop will decrease the integral part fast enough automatically, if you choose proper parameters ...



Regards
stancecoke

[casainho]

Hmm, I don't understand your latest code in detail...
I can't see the typical sinusoidal shape in the torque-curve?!

It is inline what I measured some time ago: https://opensourceebikefirmware.bitbuck ... ensor.html
Maybe that is the effect of the low pass filter on the motor controller??

If you need some clarification, please ask.

Why don't you average the torque signal over a crank revolution? This would avoid the scatter.

I can't imagine being less scatter using the average. Do you have a link were I can read more about it for a similar situation?

I think you are doing many things much more complicated than necessary, e.g. a reset of the integral part of the controller should not be done to avoid sudden changes in the setpoint which could cause the motor to stutter. The control loop will decrease the integral part fast enough automatically, if you choose proper parameters ...

I am sure others ways can work. For instance, keep resetting the target value instead of resetting the I term.
It works for now, in future can be rewritten if needed or such.
I am now more worried about direct drive motor.

[stancecoke]

I can't imagine being less scatter using the average. Do you have a link were I can read more about it for a similar situation?

I had a closer look to you code now. As far as I understand, you are averaging the torque-signal over four AD-conversions, in the fixed frequency of the slow loop. So you have no reference to the pedal position.

Code: Select all

 // low pass filter the torque sensor to smooth the signal
  ui16_throttle_value_accumulated -= ui16_throttle_value_accumulated >> 2;
  ui16_throttle_value_accumulated += ((uint16_t) ui8_throttle_value);
  ui8_throttle_value_filtered = ui16_throttle_value_accumulated >> 2;

The slow loop frequency seems to be very slow (only 10 Hz ?!)

Code: Select all

ui16_TIM2_counter = TIM2_GetCounter ();
    if ((ui16_TIM2_counter - ui16_motor_controller_counter) > 781) // every 100ms
    {
      ui16_motor_controller_counter = ui16_TIM2_counter;
      motor_controller ();
      ebike_app_controller ();
      continue;
}

So as an example: if you are pedaling with a cadence of 60/min you will get 10 AD-conversions per crank revolution, if you are averaging over four points, you will get an low-resolution sine-curve for the ui8_throttle_value_filtered values. I marked four red dots on the sine-curve to make it more transparent.

Torque-Signals whithin one crank revolution.png (146.67 KiB) Viewed 838 times

In the "forumscontroller"-code and in my fork, we are reading the torque-value at every PAS-interrupt, and average the torque over one crank revolution. In this way you get a stable torque-value with no oszillation.

Code: Select all

#if defined(TORQUESENSOR) || defined(TORQUE_SIMULATION)
    //	Update cadence, torque and battery current after PAS interrupt occurrence
    if (ui8_PAS_Flag == 1)
    {
      ui16_PAS=ui16_PAS_Counter; 		//save recent cadence
      ui16_PAS_High=ui16_PAS_High_Counter;
      
      ...

      ui8_PAS_Flag =0; 			//reset interrupt flag

      ui8_temp = ui8_adc_read_throttle (); //read in recent torque value
      ui16_torque[ui8_torque_index]= (uint8_t) map (ui8_temp , ADC_THROTTLE_MIN_VALUE, ADC_THROTTLE_MAX_VALUE, 0, SETPOINT_MAX_VALUE); //map throttle to limits
      ui16_sum_torque = 0;
      for(a = 0; a < NUMBER_OF_PAS_MAGS; a++) {			// sum up array content
	   ui16_sum_torque+= ui16_torque[a];
	   }
      ui8_torque_index++;
      if (ui8_torque_index>NUMBER_OF_PAS_MAGS-1){ui8_torque_index=0;} //reset index counter
}

This may be a bit sluggish at low cadence, but therefore the "forumscontroller" overwrites the target value from human power with the direct read torque if this value is higher. Then you get direct response to the pedal force...

regards
stancecoke

[casainho]

I had a closer look to you code now. As far as I understand, you are averaging the torque-signal over four AD-conversions, in the fixed frequency of the slow loop. So you have no reference to the pedal position.

Seems you missed my new code -- you can see on the commits diffs:
- https://github.com/OpenSource-EBike-fir ... 90a6b4db90
- https://github.com/OpenSource-EBike-fir ... 42905c8609

The new code I added to PAS code, at every signal change:

Code: Select all

  if (ui8_pas_state != ui8_pas_state_old) // PAS signal did change
  {
    ui8_pas_state_old = ui8_pas_state;

    (...)
	
    ui8_torque_sensor_throttle_value = UI8_ADC_THROTTLE;
    ui8_torque_sensor_pas_signal_change_counter++;
    if (ui8_torque_sensor_pas_signal_change_counter > (PAS_NUMBER_MAGNETS << 1)) // ui8_pas_signal_change_counter = (PAS_NUMBER_MAGNETS*2) means 1 pedal rotation
    {
      ui8_torque_sensor_pas_signal_change_counter = 1; // this is the first cycle
      ui8_torque_sensor_throttle_processed_value = ui8_torque_sensor_throttle_max_value; // store the max value on the output variable of this algorithm
      ui8_torque_sensor_throttle_max_value = 0; // reset the max value
    }
    else
    {
      // store the max value
      if (ui8_torque_sensor_throttle_value > ui8_torque_sensor_throttle_max_value)
      {
	ui8_torque_sensor_throttle_max_value = ui8_torque_sensor_throttle_value;
      }
    }
  }

As you can see, it reads the max value of the signal every 1 pedal rotation and outputs that value to the global variable ui8_torque_sensor_throttle_processed_value.

Then on ebike_app.c, running at 10Hz:

Code: Select all

void read_torque_sensor_throttle (void)
{
  read_throttle (); // so we get regular processing of throttle signal

  // if cadence is over 15 RPM, use the processed torque sensor value, otherwise, use ui8_throttle_value_filtered
  if (ui8_pas_cadence_rpm <= 15)
  {
    ui8_throttle_value_filtered = ui8_throttle_value;
  }
  else
  {
    ui8_throttle_value_filtered = (uint8_t) (map (
	  ui8_torque_sensor_throttle_processed_value,
	  (uint8_t) ADC_THROTTLE_MIN_VALUE,
	  (uint8_t) ADC_THROTTLE_MAX_VALUE,
	  (uint8_t) THROTTLE_MIN_VALUE,
	  (uint8_t) THROTTLE_MAX_VALUE));
  }
}

ui8_throttle_value (unfiltered value!!) is used when cadence <= 15 and when over, ui8_torque_sensor_throttle_processed_value is used instead, as I did show before with real values on the graph.

Note that

Code: Select all

ui8_throttle_value_filtered

is the same variable with output value from either:
- read_throttle (); (used for thumb throttle and PAS)
- read_torque_sensor_throttle (); (used for torque sensor)
I am using the S06S Bluetooth version and I think I will stick with that version, for later use with our mobile app. This means I connected the torque sensor signals to the thumb throttle connector and PAS and so I can't use in parallel a thumb throttle with this controller.

[stancecoke]

Seems you missed my new code -- you can see on the commits diffs:

Ah, yes, I didn't recognize the changes in the motor.c
You will get less scatter with the averaged values, but of course it will work with the single maximum value of one crank revolution also. But you get a new torque value only once per revolution and not at every PAS event...

I am using the S06S Bluetooth version and I think I will stick with that version, for later use with our mobile app. This means I connected the torque sensor signals to the thumb throttle connector and PAS and so I can't use in parallel a thumb throttle with this controller.

Is the X4 pad used for somethings else with the BT-version?

regards
stancecoke

[casainho]

Ah, yes, I didn't recognize the changes in the motor.c
You will get less scatter with the averaged values, but of course it will work with the single maximum value of one crank revolution also. But you get a new torque value only once per revolution and not at every PAS event...

Go ahead an show the results on a similar graph as I don't believe will be a big difference.

Is the X4 pad used for somethings else with the BT-version?

I don't know, I wish someone could see the hardware differencies...

[stancecoke]

Go ahead an show the results on a similar graph as I don't believe will be a big difference.

OK, I'll do some logging of the raw ADC-values on a real ride, but this will take at least two weeks to prepare. I can try the "thumb-brake" with the BionX in "real life" then, too

regards
stancecoke

[casainho]

OK, I'll do some logging of the raw ADC-values on a real ride, but this will take at least two weeks to prepare. I can try the "thumb-brake" with the BionX in "real life" then, too

About 1 month up to start spring season, so right on time (at least for me) to have the bicycles ready for family fun
I have 2 ebikes using S06S, geared Q85 motors and 24V batteries (for young son of 8 years old + girlfriend). My other ebike, that I use, has the S12S, direct drive Q11 motor and 48V battery - on this one I need to work the firmware for this direct drive motor, as I was not happy last time I tested. All this ebikes has torque sensor only.
So, that is my plan up to spring and summer.
Who knows if on next year we can prepare the Mobile bluetooth app??

[honya96]

I want to understand what you mean by: "you floor it too fast from dead stop".

I mean turning throttle to full position at standstill.
As it is now, Iam sure it will blow s12s mosfets with fast direct motor at 40A.

Pwm rise value may help but it will affect reaction at higher rpm.

As I understand, there is a current going through phase sensor 2/3 of time? So limiting it, in combination with pwm rise value should be ok?

Or the other way as I mentioned before, limiting battery current up to set erps should also do the job, maybe better.

Having "startup Amps" and "Max current eprs" values in java app will limit phase current and allow users to get higher battery amps without blowing the controller at startup.

[casainho]

I went for a real test drive with the geared Q85 motor, 24V battery, S06S controller, LCD5 and torque sensor only. I am very happy with the result and I don't feel the need to change anything on the firmware. I really like the feeling of pedaling stronger and felling higher support from the motor. Also adapting the motor support from LCD, using the assist level, works well and is very useful.
Some notes:
1. I wasn't using an external wheel speed sensor so on LCD5 I was seeing the motor speed. On situations like small downhills (here, all is almost flat, no real downhills), I wanted to rest my feet and verified that torque sensor outputs some throttle value, keeping the motor rotating at a lower speed than bicycle wheel thanks to motor internal clutch.
2. I wounder what should be the correct algorithm for a direct drive motor, as when downhill and resting my feet, I don't want that motor stops/brakes...

[casainho]

I mean turning throttle to full position at standstill.
As it is now, Iam sure it will blow s12s mosfets with fast direct motor at 40A.

So you mean the S12S can't withstand his max current of 40A for a period of 2.5 seconds?

As I understand, there is a current going through phase sensor 2/3 of time? So limiting it, in combination with pwm rise value should be ok?

We can measure only twice per ERPs (at Id and -Id points on the image), but even like that didn't worked well when I tested:

https://opensourceebikefirmware.bitbuck ... llers.html

Also that would work with motor rotating at least medium speed, not at startup. So we just can use current value from the shunt(motor total current).

Or the other way as I mentioned before, limiting battery current up to set erps should also do the job, maybe better.

Having "startup Amps" and "Max current eprs" values in java app will limit phase current and allow users to get higher battery amps without blowing the controller at startup.

Can you please make a graph with example values? (you can draw on paper and take a photo).
Maybe you mean a current ramp, so the max controller current is not available at startup?

[honya96]

So you mean the S12S can't withstand his max current of 40A for a period of 2.5 seconds?

Yes, actually not even 0.5 second with really fast motor, because 40A from battery can be 200A to motor. (=at mofets)

Maybe you mean a current ramp, so the max controller current is not available at startup?

Not exactly, it has to be available when the wheel is spinning allready, and has to be limited when at speed and terrain slows your motor under the set speed, or something blocks your wheel.

[casainho]

Yes, actually not even 0.5 second with really fast motor, because 40A from battery can be 200A to motor. (=at mofets)

Didn't know about that!! Now I recall Stancecoke and others telling that "motor current" on firmware is instead battery current but I always thought they were equal.
I need to read more about it and I found this one shunt used on this controllers, is referred as "DC-Link Current Sensor".

Not exactly, it has to be available when the wheel is spinning allready, and has to be limited when at speed and terrain slows your motor under the set speed, or something blocks your wheel.

I think I got it. I hope to get back to this later.

[honya96]

I think I got it. I hope to get back to this later.

Thank you, I really need this.

I know I am the only one (for now) trying higher powers but It will be important function for anyone who wants fast motor response from standstill without risking mosfets..