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

I've already updated the feature_torque_senor branch, you have to edit the config.h to #define THROTTLE instead of #define TORQUESENSOR.
I've tested just the switch from SVM 6 steps to SVM 127 steps. That worked with no problems.

Perhaps you can try to switch from SVM 6 steps to SVM 8 steps first.

Code: 
ui8_interpolation_angle = (uint8_t) ((ui16_PWM_cycles_counter << 3) / (ui16_PWM_cycles_counter_total>>5));

edit: just checked with excel, the formula doesn't work in the espected way. It is safer to use
Code: 
ui16_TEMP=ui16_PWM_cycles_counter >>3;
ui16_TEMP=ui16_TEMP<<3

ui8_interpolation_angle = (uint8_t) ((ui16_TEMP<<7) / (ui16_PWM_cycles_counter_total>>1));

If this works you can increase steps to 16,32 etc. slowly.

This shoud avoid, that the rotor accelerates too much in the first electric revolution with angle interpolation.

Regards
stancecoke
 
stancecoke said:
I've already updated the feature_torque_senor branch, you have to edit the config.h to #define THROTTLE instead of #define TORQUESENSOR.
I've tested just the switch from SVM 6 steps to SVM 127 steps. That worked with no problems.
Click to expand...
Well, just tested but had to change some parts like the Makefile and main.c because of throttle... it didn't work. Anyway, I did remember that this motor started well with SVM no interpolation and than run ok with interpolation, on the electric unicycle firmware. The firmware is very similar so I will redo the code and I should have it working. For sure that it starts well with SVM without interpolation, I tested it now and works very well. And for sure I can do the transition as I did on the electric unicycle.
 
Did you edit the config.h?! Then throtlle works.
In your makefile you should just add the
PAS.c \
SPEED.c \
update_setpoint.c \

and related .h files.

I'll continue to test in hardware to verify the issue with the overflow and 8-step approach.

But I don't know, if it helps with your motor.

Regards
stancecoke
 
stancecoke said:
I'll continue to test in hardware to varify the issue with the overflow and 8-step approach.

But I don't know, if it helps with your motor.
Click to expand...
By now you know how the motor control works and since you are testing/developing, that is really great to help. If there is an overflow, we need to take care of it, like using uint32_t if needed.
 
Just added the following warning to my main.c:

// Local VS global variables
// Sometimes I got the following error when compiling the firmware: motor.asm:750: Error: <r> relocation error
// and the solution was to avoid using local variables and define them as global instead
 
so, first conclusion to the overflow issue.

If you use
Code: 
ui8_interpolation_angle = (uint8_t) (((ui16_PWM_cycles_counter) << 8) / ui16_PWM_cycles_counter_total);
you get an overflow for ui16_PWM_cycles_counter_total>255 obviously.

If you use
Code: 
ui8_interpolation_angle = (uint8_t) ((((uint32_t) ui16_PWM_cycles_counter) << 8) / ui16_PWM_cycles_counter_total);
there is no overflow, but the division takes that long, that you get just very few points to form the sinus, so the motor runs not properly at high speeds.

That makes this solution favorite for me:

Code: 
if(ui16_PWM_cycles_counter_total>255){
	ui8_interpolation_angle = (uint8_t) ((ui16_PWM_cycles_counter << 7) / (ui16_PWM_cycles_counter_total>>1));}
    else {
	ui8_interpolation_angle = (uint8_t) ((ui16_PWM_cycles_counter << 8) / (ui16_PWM_cycles_counter_total));}

[youtube]kUscDlaMRgI[/youtube]

If switch from SVM 6 steps to SVM 127 / 255 steps doesn't work with your motor, please try to switch to 8 steps:

Code: 
    if(ui16_PWM_cycles_counter_total>255){
	ui8_interpolation_angle = (uint8_t) ((ui16_PWM_cycles_counter << 7) / (ui16_PWM_cycles_counter_total>>1));}
    else {
	ui8_interpolation_angle = (uint8_t) ((ui16_PWM_cycles_counter << 8) / (ui16_PWM_cycles_counter_total));}

    ui8_temp = (ui8_interpolation_angle>>5);
    ui8_temp = (ui8_temp<<5);
    ui8_motor_rotor_position = (uint8_t) (ui8_motor_rotor_absolute_position + ui8_position_correction_value + ui8_temp);

regards
stancecoke
 
Thank you for the video - I just saw it later on YouTube, after you edited your message.

I am having no luck and is good to see your video. I will keep trying and maybe I wil adopt your branch.
 
I'm still struggeling with theory of FOC vs. your "simple" implementation. There are tons of literature dealing with this topic, best i read was this.. But I haven' t found a source where the difference between the various control schemes are described for "dummies". Do you have at hint?!

By the way, is there any dead time considered in your code as shown in the picture?

regards
stancecoke
file.php

Dead Time.JPG
 
stancecoke said:
I'm still struggeling with theory of FOC vs. your "simple" implementation. There are tons of literature dealing with this topic, best i read was this.. But I haven' t found a source where the difference between the various control schemes are described for "dummies". Do you have at hint?!
Click to expand...
- Texas Instruments videos: https://eggelectricunicycle.bitbucket.io/FOC--Texas_Instruments_videos.html
- Shane Colton documentation: https://eggelectricunicycle.bitbucket.io/FOC--Shane_Colton_documentation_and_firmware.html

stancecoke said:
By the way, is there any dead time considered in your code as shown in the picture?
file.php

Click to expand...
Dead time of original S06S: https://opensourceebikefirmware.bitbucket.io/Motor_controllers--BMSBattery_S06x--S06S--PWM_signals.html#h1-5
Dead time of 1us on pwm_init ():
Code: 
void pwm_init (void)
{
(...)
  // break, dead time and lock configuration
  TIM1_BDTRConfig(TIM1_OSSISTATE_ENABLE,
		  TIM1_LOCKLEVEL_OFF,
		  // hardware nees a dead time of 1us
		  16, // DTG = 0; dead time in 62.5 ns steps; 1us/62.5ns = 16
		  TIM1_BREAK_DISABLE,
		  TIM1_BREAKPOLARITY_LOW,
		  TIM1_AUTOMATICOUTPUT_DISABLE);
 
I am being pushing some commits to feature_torque_sensor -- will help later to merge to master branch. Since it is working for you and have the latest code, we can merge it. I am trying to make my motor working also and If I get it, I will probably add a few #ifdefs before merge to master.

Don't forget to git pull feature_torque_sensor branch before commit any new code.
 
OK, so we worked in parallel, I updated the update_setpoint.c yesterday, as i recognized that I had not updated all edited files from my local working directory.... ;)
I don't know how to "git pull", I'll have to download your changes manually :? .

Regards
stancecoke
 
stancecoke said:
OK, so we worked in parallel, I updated the update_setpoint.c yesterday, as i recognized that I had not updated all edited files from my local working directory.... ;)
I don't know how to "git pull", I'll have to download your changes manually :? .
Click to expand...
You really should read quick tutorials about using git. After that, you can use the visual apps, like gitg that I use on Linux: https://wiki.gnome.org/Apps/Gitg/

Gitg


You can also install git for windows that should give you a terminal where you can run git command line.

I did a few short commits to be easy for you to follow the changes and apply to your branch in the case of conflits.
 
I got my motor working BUT was luck... I found that it transition ok at a specific speed and angle... like the best angle value to start will not work on the transition and I need to use a worst value angle for start that will work on the transition...

On my EUC code I have:

Code: 
  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;
  }

At startup (motor_speed_erps < 80) the angle correction_value is set to 0 but at correct value when speed increases...

Code: 
  // calculate the interpolation angle
  // interpolation seems a problem when motor starts, so avoid to do it at very low speed
  if ( !(duty_cycle < 5 && duty_cycle > -5) || motor_speed_erps >= 80)
  {

And when interpolation starts, the correct angle correction_value is used may be the BIG DIFFERENCE for this firmware........
 
stancecoke said:
As I work with eclipse, I could use the git plugin, but I never tried it :oops:
Click to expand...
Using the command line here may be much more simple for you to start!! at least that happened with me -- because git have very few key commands to get you started -- I just use gitg because with that visual tree I can quick see the diffs of any commit -- can you see your name/commits on the log (click on the image to see full image)??

 
stancecoke said:
I tried your SVM-Table from the current SVM branch. The MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT is nearly zero in this setting. But the start up is very poor. At higher speeds I calculate the correction value like shown in the diagramm.
Can the start up be improved somehow? (This is the thing, you are working on?!)

Click to expand...
So, after I found that the transition to using interpolation only works for a narrow values of angles, I think we need to calc the angle almost from start and apply it -- is like if the angle to start will not be the same at the transition and that is why it fails - I will focus tomorrow on this.
 
casainho said:
I got my motor working BUT was luck... I found that it transition ok at a specific speed and angle...
Click to expand...

Great, but it seems that this is very specific to your motor.... Have you tried the approach to switch to 8 steps first? I think this should be the more universal way....

Regards
stancecoke
 
I had to undo some of your changes in the main.c, all modes should run now. With your commit there was a warning from the compiler and the update_setpoint function was not called in TORQUESENSOR mode.
I modified the windows-batch and the readme too, so everthing's running with windows now again.

I hope these changes are OK for you!

regards
stancecoke
 
stancecoke said:
I had to undo some of your changes in the main.c, all modes should run now. With your commit there was a warning from the compiler and the update_setpoint function was not called in TORQUESENSOR mode.
I modified the windows-batch and the readme too, so everthing's running with windows now again.

I hope these changes are OK for you!
Click to expand...
Let's keep your branch with the most recent code - later we can merge to master.

I found the equation for my motor and the transition happens ok BUT as before, when going from interpolation to no interpolation (decreasing throttle), the motor almost brakes on the transition!!
Code: 
if (ui16_motor_speed_erps < 6)
{
  ui8_position_correction_value = 0;
}
else
{
  // Equation found with experimental values:
  // ui8_position_correction_value = ui16_motor_speed_erps * 0.784
  // 100 ~= 0.784 << 127
  ui8_position_correction_value = (uint8_t) ((ui16_motor_speed_erps * 100) >> 7);
}

Since I remember, the FOC algorithm did output angles in the opposite direction when accelerating or decelerating and amplitude/rate of that values depended on the speed and/or current. I am afraid the idea of looking to the sinewave on phase B current will not work as most of the times it is not a perfect sinewave -- it is perfect sinewave only when in correct angle value but with strange shapes when out of the angle value that is when we will need to find if we should increase or decrease the angle. I can't see an algorithm but I will take sometime to think and try find also something on web. This will be my focus, I can't advance on firmware while not having the correct motor control -- the motor I am using is direct drive motor and slow eRPM as all direct drive motors may be, contrary to geared motors like Q100/Q8/Q75 that are fast eRPM motors. So we could understand the issues I am having seems to not apply to fast eRPM motors however they pose other issues and they also need "FOC control" so seems imperative to me to implement "FOC control".
 
I tested and recorded phase B current wave with correct and incorrect value of the angle and I put that information here: https://opensourceebikefirmware.bitbucket.io/Various--Endless-sphere.com_forum_messages--2017.09.01_-_Trying_to_figure_out_an_algorithm_to_automatically_adjust_ui8_position_correction_value.html



Seems that is possible an algorithm and maybe will not be difficult... any suggestions??
 
I've built a test bench for the comparison of the different working modes, to see how important the correction angle is in real life :)
Of course still quite provisional, but it's working in principle...

[youtube]dJCLpZxp4fs[/youtube]

regards
stancecoke
 
stancecoke said:
I've built a test bench for the comparison of the different working modes, to see how important the correction angle is in real life :)
Click to expand...
Great!! I can't measure with load in the motor, but now you can :)

Maybe you can try to setup the motor running at the same speed and different duty_cycle angle values and see the difference in the current value -- same speed, different angle and different power needed. You need to adjust duty and angle by UART.

I tried an algorithm based on zero crossing and it always fails, going always in one direction -- have to take more time to verify/debug this algorithm.
 
And because I should not forget my main motivation and I am really happy to see others like Pope Francis working for a better environment. This also helps me explain to my little son with 7 years old (and the rest of my family) why I take so much time working on this project and why I have a lot of bicycles, electric motors, etc on the garage.

Christians make (next) month of mobilizations in defense of the environment
http://www.correio24horas.com.br/noticia/nid/cristaos-fazem-mes-de-mobilizacoes-em-defesa-do-meio-ambiente/

image-kcn1bc42b.jpg


VATICAN CITY (Reuters) - Pope Francis and Orthodox Christian leader Patriarch Bartholomew called on Friday for a collective response from world leaders to climate change, saying the planet was deteriorating and vulnerable people were the first to be affected.

The appeal comes three months after U.S. President Donald Trump withdrew from a global agreement, struck in Paris, to limit greenhouse gas emissions.
Click to expand...
https://www.swissinfo.ch/eng/pope--orthodox-leader-make-climate-change-appeal-to--heal-wounded-creation-/43485700
 
You must log in or register to reply here.

Similar threads

badboy1999
    • Like
Looking for a ~350w controller
Replies
7
Views
1,189
slaphappygamer
S
E-HP
    • Like
DIY Newb FAQ?
2
Replies
30
Views
9,929
Low-and-Slow
L
casainho
Bafang BBSHD BBS02 mid drive -- Flexible OpenSource firmware
2 3 4 5 6
Replies
129
Views
45,768
stts
S
casainho
Unlock the max power of your scooter: Flexible OpenSource firmware for Kunteng KT motor controllers (0.25kW up to 5kW)
Replies
2
Views
3,553
ElectricGod
ElectricGod
casainho
TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)
265 266 267 268 269
Replies
6,711
Views
823,306
Zambam
Z
Back
Top