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

[stancecoke]

I've tested the recent SVM_5 branch, it works now! I get 560 erps @36V and 780 eprs @ 48V max speed without load now. Effiency with Load Level 3 is exactly the same as with SVM_4.

But merged to the feature_torque_sensor branch, the motor runs just about 320 erps without load. It seems that the additional ADC reading and processing the update_setpoint functions take too much time, or something went wrong with merging...

regards
stancecoke

 

[casainho]

I've tested the recent SVM_5 branch, it works now! I get 560 erps @36V and 780 eprs @ 48V max speed without load now. Effiency with Load Level 3 is exactly the same as with SVM_4.

On my tests, max eRPS is ~400 on SVM_5 (higher freq. PWM). Higher speeds and starts to ask to much current and making much noise... how to you get the 560 and 780??

 

[stancecoke]

how to you get the 560 and 780??

I don't know, it's just fact

Do you need an evidence?

Regards
stancecoke

 

[casainho]

how to you get the 560 and 780??

I don't know, it's just fact

Do you need an evidence?

I would like to understand better. It is a direct drive or geared motor? at that speeds, it keeps silent and asking low current??

Because my Q85 also runs much faster but doing very noise and asking to much current and the power supply protects other way I don't know what would happen...

And a capacitor did "burn", made smoke, 2 times, when I used 60V on the power supply........... but the controller still works

 

[stancecoke]

It is a direct drive or geared motor?

It's a geared motor of course. I've fixed the bug in merging SVM_5 to torque_sensor now.
But it's a little mystery, the erps shown over UART increase in a ratio of 560/370 but the real speed of the wheelchain increases just in the ratio 13/11. (measured with a normal speedometer)

But that's enough experimenting for today

Regards
stancecoke

 

[casainho]

It is a direct drive or geared motor?

It's a geared motor of course. I've fixed the bug in merging SVM_5 to torque_sensor now.

And now, don't you want to put merge torque_Sensor branch on master?

But it's a little mystery, the erps shown over UART increase in a ratio of 560/370 but the real speed of the wheelchain increases just in the ratio 13/11. (measured with a normal speedometer)

That is because it is geared??

I did the tests to:

if (ui16_motor_speed_erps > 7)
{
if (ui16_ADC_iq_current_filtered > (413 + ui8_tune))
{
ui8_position_correction_value++;
}
else if (ui16_ADC_iq_current_filtered < (409 + ui8_tune))
{
ui8_position_correction_value--;
}
}

And found that value are ok and there is a good margin on that values. I could not found a value where my motor would be so silent as when be driven by the Lishui controller... and since I remember, Lihsui also uses the same sinewave shape as S06S and the same I tested.

 

[stancecoke]

And now, don't you want to put merge torque_Sensor branch on master?

Not yet, I want to recheck the Torque-Sensor function first, as I tested just the Throttle function after all that code updating during the last days. My new controller has two speed input lines, one with the Hallsensor connector and one extra connector. I have to check the pinning of the extra line.

That is because it is geared??

The ratio has to be the same all the time! 560/370 =1.51 while 13/11 = 1.18. Or the other way round 560/13 = 43 while 370/11= 33. I think the speed of the rotating field is higher than the refering rotor speed ("asynchronous" working mode with "slip" of the rotor). That's the reason why the motor is noisy and draws too much current. Perhaps you can check the ratio at your Q85 with a speedometer, too. I'll try to check the ratio at different speeds with my motor tonight.

regards
stancecoke

 

[casainho]

Trying to get rid of the if/else... When you have

Thank you NJay. For now we are using a different sinewave and that code is not used anymore, it is simple now and I was able to increase PWM frequency. Let's see if we can make a stable version and maybe then we can focus on optimizations.

 

[casainho]

And now, don't you want to put merge torque_Sensor branch on master?

Not yet, I want to recheck the Torque-Sensor function first, as I tested just the Throttle function after all that code updating during the last days. My new controller has two speed input lines, one with the Hallsensor connector and one extra connector. I have to check the pinning of the extra line.

Well, I just did it. But there is no problem. When you think you have a stable version you will just need to merge again to master.

That is because it is geared??

The ratio has to be the same all the time! 560/370 =1.51 while 13/11 = 1.18. Or the other way round 560/13 = 43 while 370/11= 33. I think the speed of the rotating field is higher than the refering rotor speed ("asynchronous" working mode with "slip" of the rotor). That's the reason why the motor is noisy and draws too much current. Perhaps you can check the ratio at your Q85 with a speedometer, too. I'll try to check the ratio at different speeds with my motor tonight.

Ok I understand now that the ratio needs to e the same.

The eRPM measured is using the hall sensors signal, that measures the rotor magnets. I don't think is possible to measure hall sensor signal a different value from the real rotor speed.

    switch (hall_sensors)
    {
      case 3:
      ui16_PWM_cycles_counter_total = ui16_PWM_cycles_counter;
      ui16_motor_speed_erps = PWM_CYCLES_SECOND / ui16_PWM_cycles_counter_total; // this division takes ~4.2us

Maybe the issue is with ui16_PWM_cycles_counter_total, that depends on the measure of ui16_PWM_cycles_counter. Maybe with the vibration, that code of hall_sensor case 3 happens more than one time... ????

 

[casainho]

I took some oscilloscope screenshots for motor current measurement... and clearly my Q85 motor is really different from the EUC2 motor direct drive -- I think should be something about different inductance and resistance of the motors... does anyone knows looking at the current shape??

https://opensourceebikefirmware.bitbucket.io/Various--Endless-sphere.com_forum_messages--2017.09.14_-_measuring_motor_current.html

 

[stancecoke]

    switch (hall_sensors)
    {
      case 3:
      ui16_PWM_cycles_counter_total = ui16_PWM_cycles_counter;
      ui16_motor_speed_erps = PWM_CYCLES_SECOND / ui16_PWM_cycles_counter_total; // this division takes ~4.2us

We didn't change PWM_CYCLES_SECOND in the main.h to 22857 ?! But with this, the calculated erps values should be even higher, not lower....

I think should be something about different inductance and resistance of the motors

The mass inertia of the geared motor rotor is much smaller that the one of the direct drive. Perhaps this is a problem with resonance frequencies. Have you tried to put a little load on the Q85?

regards
stancecoke

 

[casainho]

    switch (hall_sensors)
    {
      case 3:
      ui16_PWM_cycles_counter_total = ui16_PWM_cycles_counter;
      ui16_motor_speed_erps = PWM_CYCLES_SECOND / ui16_PWM_cycles_counter_total; // this division takes ~4.2us

We didn't change PWM_CYCLES_SECOND in the main.h to 22857 ?! But with this, the calculated erps values should be even higher, not lower....

Ok.

I think should be something about different inductance and resistance of the motors

The mass inertia of the geared motor rotor is much smaller that the one of the direct drive. Perhaps this is a problem with resonance frequencies. Have you tried to put a little load on the Q85?

Makes sense. And even the motor is placed horizontally. I took from garage the bicycle I bough 4 years ago for this project -- and I will use the installed motor that is also a Q85 and have the mass of the wheel and I will be bale to brake to simulate a load. Let's see if my girlfriend will not have a problem with it on our living room

[youtube]wrrfMGUwaAM[/youtube]

 

[stancecoke]

OK, I hope you don't get in trouble

I've tested a speed-dependend angle adjustment. I get less spikes in the current signal at max speed/no load with this. With load it has the same effiency as usual.

if (ui16_motor_speed_erps > 7)
         {

   	if (ui16_ADC_iq_current_filtered  > 510-(ui16_motor_speed_erps>>5))
   	{
   	  ui8_position_correction_value++;
   	}
   	else if (ui16_ADC_iq_current_filtered < 506-(ui16_motor_speed_erps>>5))
   	{
   	  ui8_position_correction_value--;
   	}
         }

Was it your plan, that in the master branch autotunig is not active?!

edit: I switched the torque sensor branch back to the SVM_4 8 bit stage, this works smoother with my Shengyi Middrive

regards
stancecoke

 

[casainho]

So, I am being testing the other Q85 24V 328RPM motor on my bicycle. The motor does less noise (maybe because of the mass of the wheel) but the speed limit is there at the same value!!

I've tested a speed-dependend angle adjustment. I get less spikes in the current signal at max speed/no load with this. With load it has the same effiency as usual.

Was it your plan, that in the master branch autotunig is not active?!

edit: I switched the torque sensor branch back to the SVM_4 8 bit stage, this works smoother with my Shengyi Middrive

Seems something went wrong with the merge I did to master... I will rectify later.

I want to go with the original sinewave because seems ok to measure correctly the motor current. I am trying to implement the motor over current protection, reading the motor current. I am trying to read ADC in continuous mode, buffered (it is not working, I want to see if is possible).
Motor over current protection will reduced PWM duty_cycle value every time the current value passes the limit, meaning that would protect the motor and I am thinking that unlike Lishui, I should not disable the motor but instead just reduce the duty_cycle and that way the motor will run at permitted max speed -- this is what I do manually, when I see the current going much higher and lab power supply indicating current short-circuit, I simple reduce the throttle.

With SVM_4 seems I get higher running speed with my Q85 than with the original sinewave...

 

[stancecoke]

OK, perhaps it's not a good idea to run a geared motor completly without load...

I've done some more measurements on the test bench. I have to revise my old results, I was not able to reproduce the "good" efficiency of the Lishui at high load. I've crosschecked everything three times now. It seems, that we are on the same level as the Lishui now, perhaps even a little better

Regards
stancecoke

 

[casainho]

OK, perhaps it's not a good idea to run a geared motor completly without load...

I've done some more measurements on the test bench. I have to revise my old results, I was not able to reproduce the "good" efficiency of the Lishui at high load. I've crosschecked everything three times now. It seems, that we are on the same level as the Lishui now, perhaps even a little better

Great, really important work!!!

We can run it without load because we can do it manually, we just need to control max overcurrent. I will implement it on next days, probably next monday.
I would like that graph could have the motor speed...
For instance, my Q85 motor should be able to run at 328RPM at 24v but can't do it with this firmware, probably only in 6 steps.

 

[stancecoke]

I would like that graph could have the motor speed...

I've done a few new measurements and logged the speed of the motor (erps), Here you are:

I can upload the excel-sheet to github, if you are interested in the data.

regards
stancecoke

 

[casainho]

I would like that graph could have the motor speed...

I've done a few new measurements and logged the speed of the motor (erps), Here you are:

I can upload the excel-sheet to github, if you are interested in the data.

Thanks. I would like to know why do you stop on that values, why don't you go higher?

github have a lot of space. I value a lot documentation and that tests validations. Is up to you to put there the information you think is relevant -- I would like to have that files and images there. Maybe even like what I am doing: https://opensourceebikefirmware.bitbucket.io/Various--Endless-sphere.com_forum_messages--2017.09.14_-_measuring_motor_current.html
A document with the notes from that date, so in feature we can understand all of that data. You can for instance put on a PDF file or on that notes file. Would be great if you could put there also the source files for the documentation.

I don't think it is really needed that we write on the same documents, we can have our own space for writing (I remember projects like RepRap were developers wrote theirs development finding on blog messages) and a wiki for a final documentation of a specific version.

If you want, I can give you access to git on bitbucket, that I use for the documentation files because their repos can hold much more data.

 

[casainho]

My plan for next week: OSEC firmware v0.1
- develop the firmware part for the motor over current:
--using this information: https://opensourceebikefirmware.bitbucket.io/Various--Endless-sphere.com_forum_messages--2017.09.14_-_measuring_motor_current.html

- develop the firmware part to read motor current (Id current)
-- read the phase B current value at 90º:when ui16_PWM_cycles_counter == (ui16_PWM_cycles_counter_total >> 2)

- decide for a sinewave form
-- original is ok for read motor current but the other "advanced" shape seems better to give motor more speed and more silent. I will need to see I can read ok the motor current and if so, stick with this sinewave form

- close the motor controller firmware, this time will not have Regen

- try to put throttle controlling the motor torque/Id current instead of current PWM duty_cycle
-----

After having OSEC firmware v0.1, maybe some developers could focus on support the LCD whiles others (like me) could focus on motor control/throttle "torque-speed" and regen. Or maybe LCD could be a priority, because new users will prefer to have a full working system instead of an optimized system. Full working system would be motor working ok, with throttle or/and PAS and LCD.
Stancecoke, what do you think?

 

[stancecoke]

Thanks. I would like to know why do you stop on that values, why don't you go higher?

As you already wrote, the power supply cuts the voltage in short current spikes. As I have the undervoltage protection set active in my code, the motor stops in this case. This happes if the motor draws more than around 4A. Therefore 144 W (4A@36V) is the highest power I can put on the motor actually.

I would like to have that files and images there

I've uploaded an .ods file to github.

maybe some developers could focus on support the LCD

I think DuckAmuc at the german forum has tasted blood already :wink: , as the code for the common LCDs already exists and just has to be ported to our project. He also has proofed, that he can write in english language

Full working system would be motor working ok, with throttle or/and PAS and LCD

I totally agree. But I think we will get the most "customers" if we offer a hidden function to disable the legal restrictions in Germany with an automatic reactivation after a stop (in case a policeman stopps you, everything will be legal if he takes a test ride) That's absolutly not my motivation for this project (it's the implementation of the torquesensor) but there is very much interest in this "tunig" option and some companies earn a lot of money with selling "tuning dongles" for insane prices....

Regards
stancecoke

 

[daffy99]

new users will prefer to have a full working system instead of an optimized system. Full working system would be motor working ok, with throttle or/and PAS and LCD.

As a potential new user, I would add "safe to run" to the requirements - i.e. the system should work very, very hard on not destroying any of its components (self-protection).

Personally, I could probably live with alpha or beta code when it comes to features and non-functionals (e.g. efficiency) - but the hardware should be protected to the fullest extent possible.

 

[casainho]

Thanks. I would like to know why do you stop on that values, why don't you go higher?

As you already wrote, the power supply cuts the voltage in short current spikes. As I have the undervoltage protection set active in my code, the motor stops in this case. This happes if the motor draws more than around 4A. Therefore 144 W (4A@36V) is the highest power I can put on the motor actually.

Good to know. 4A and undervolt, I hope that value of amps will be much higher with batteries so we can put more power to the motor.

maybe some developers could focus on support the LCD

I think DuckAmuc at the german forum has tasted blood already :wink: , as the code for the common LCDs already exists and just has to be ported to our project. He also has proofed, that he can write in english language

Would be great if he could joint here. I can also give git access.
Arduino is C++ code, I am afraid it can take a lot of space. I think we need to go very frugal on this project. The LCD communications seems very simple anyway and I would say that is also the reason to take less space as possible.

Full working system would be motor working ok, with throttle or/and PAS and LCD

I totally agree. But I think we will get the most "customers" if we offer a hidden function to disable the legal restrictions in Germany with an automatic reactivation after a stop (in case a policeman stopps you, everything will be legal if he takes a test ride) That's absolutly not my motivation for this project (it's the implementation of the torquesensor) but there is very much interest in this "tunig" option and some companies earn a lot of money with selling "tuning dongles" for insane prices....

Didn't know about all that. I will look at youtube to see If I can look how the policeman do that procedure.
Here in Portugal limit is 25km/h and with pedalec. But the chinese scooter combo bicycle, run just with throttle and users use them like if they are scooters. I run my electric bicycle at 45km/h in the flat and free places, with throttle but I would prefer to have the torque sensor (that I never tried!!).

 

[casainho]

new users will prefer to have a full working system instead of an optimized system. Full working system would be motor working ok, with throttle or/and PAS and LCD.

As a potential new user, I would add "safe to run" to the requirements - i.e. the system should work very, very hard on not destroying any of its components (self-protection).

Personally, I could probably live with alpha or beta code when it comes to features and non-functionals (e.g. efficiency) - but the hardware should be protected to the fullest extent possible.

I can tell you the system have already focus on self-protection. But maybe you know about something missing, maybe you can suggest any protection that is not yet on the firmware??

One thing I would like to have on the hardware was a temperature sensor on the mosfets, so we could decrease power output with rise of mosfets limit temperature.

 

[daffy99]

I can tell you the system have already focus on self-protection. But maybe you know about something missing, maybe you can suggest any protection that is not yet on the firmware??

It is reassuring to learn that there is already built-in protection! My level of competence in all matters electricity / knowledge of the current implementation is unfortunately so low, that I cannot make any useful contribution here at the moment.

Funny enough, stancecoke writing "144 W (4A@36V) is the highest power I can put on the motor actually." is something where I'd immediately stop tinkering. I'd want to push at least 10A@ (nominal) 36V, and the battery that I might be getting delivered soon should be able to provide at least 20A peak (which would fry the cheap 350W motor, which I eventually be getting for starters, I guess). I really would want to run this on the road, not in the lab, and I do have hills here. Ah, and I do know about the rules, yes, yes, I do, Sir!

Anyway, once I have all the parts, I'll have to assemble and gather some experience with the baseline kit.

One thing I would like to have on the hardware was a temperature sensor on the mosfets, so we could decrease power output with rise of mosfets limit temperature.

Indeed, that would be very helpful, but would require tweaking the controller hardware?

 

[casainho]

One thing I would like to have on the hardware was a temperature sensor on the mosfets, so we could decrease power output with rise of mosfets limit temperature.

Indeed, that would be very helpful, but would require tweaking the controller hardware?

Yes, that hardware do not support temperature sensor.
I think everyone will be free to do whatever. I think I will just use the bare hardware myself. Also it is dirty cheap hardware, very easy to replace in the case of need.

But with all the knowledge we have now, the full schematic of the controller and the firmware, everyone will be able to mod it to add additional features