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

casainho said:
lizardmech said:
I think you're having issues with this because the controller is not running any sort of FOC control scheme. I don't see how you can try and reference any sort of d,q point when there is no point where data from the controller is converted to a 2 axis coordinate.

Refer to this article discussing FOC vs sinusoidal commutation https://www.controleng.com/single-article/got-field-oriented-control-in-your-servosthis-article-includes-online-material/37ab28025a3dd3e9ab551567b510795a.html
lizardmech, I started this thread to discuss the developement of firmware for KT and BMSBattery motor controllers.

You are not welcome here. Please don't start again, leave and start a new thread to discuss that topic.

It is enough what you did on EUC forum. I will just ignore you.

Umm what exactly did I do on the EUC forum? Please elaborate. It's impossible for people to develop the firmware if they're operating under the incorrect impression that they're fixing an issue with FOC, transforming 3 phase current and voltage data into a 2 axis coordinate system for a FOC control loop is fundamentally different to this controller. It may in fact be possible to develop a sinusoidal controller with good performance but understanding the differences in how they operate is crucial. In addition to inductance and resistance you may need to contend with factors such as any rotor saliency or rise time and latency of hall sensors etc. While FOC is computationally expensive it's popular because as long as it's provided with motor values and the rotor position its quite robust. Prior to modern DSPs and MCUs adoption of 3 phase BLDC/PMAC motors was less common due to the difficulty of controlling them without the computational power to do FOC which had been around since the 1980s.

If you think anything I have posted is scientifically incorrect or somehow not relevant to maximizing torque per amp of a sinusoidal motor controller please point it out.
 
casainho said:
Stancecoke, I was looking at regen.

Hm, switching the direction from ++ to -- was my first idea, too, but it didn't work for me. The advance angle was not stable an ran away.
How much battery current can you achieve from regen? Have you ever logged the values for battery current and advance angle while riding?


lizardmech said:
While FOC is computationally expensive it's popular because as long as it's provided with motor values and the rotor position its quite robust.


This thread is about the Kunteng KT36/48/SxxS E-Bike controllers. It has only one phase current sensor. So we can't do "traditional" FOC with this hardware. So any discussion about Park/Clarke transformation is obsolete here....


Regards
stancecoke
 
stancecoke said:
casainho said:
Stancecoke, I was looking at regen.

Hm, switching the direction from ++ to -- was my first idea, too, but it didn't work for me. The advance angle was not stable an ran away.
How much battery current can you achieve from regen? Have you ever logged the values for battery current and advance angle while riding?
Good questions!! :)
No, I didn't validate other than feeling that the previous vibrations went away. Maybe I should to it but I am without time for that...

And yes, I was doing just this before but I think that could not be working because of all that "FOC angle" values before on firmware. Now the values are clear to me and follow the FOC documentation, FOC seems to work as expected. And you know, geofft did good tests and even figured out better than me with his results, that the angle values are working as expected per FOC documentation.
 
lizardmech said:
casainho said:
lizardmech said:
I think you're having issues with this because the controller is not running any sort of FOC control scheme. I don't see how you can try and reference any sort of d,q point when there is no point where data from the controller is converted to a 2 axis coordinate.

Refer to this article discussing FOC vs sinusoidal commutation https://www.controleng.com/single-article/got-field-oriented-control-in-your-servosthis-article-includes-online-material/37ab28025a3dd3e9ab551567b510795a.html
lizardmech, I started this thread to discuss the developement of firmware for KT and BMSBattery motor controllers.

You are not welcome here. Please don't start again, leave and start a new thread to discuss that topic.

It is enough what you did on EUC forum. I will just ignore you.

Umm what exactly did I do on the EUC forum? Please elaborate. It's impossible for people to develop the firmware if they're operating under the incorrect impression that they're fixing an issue with FOC, transforming 3 phase current and voltage data into a 2 axis coordinate system for a FOC control loop is fundamentally different to this controller. It may in fact be possible to develop a sinusoidal controller with good performance but understanding the differences in how they operate is crucial. In addition to inductance and resistance you may need to contend with factors such as any rotor saliency or rise time and latency of hall sensors etc. While FOC is computationally expensive it's popular because as long as it's provided with motor values and the rotor position its quite robust. Prior to modern DSPs and MCUs adoption of 3 phase BLDC/PMAC motors was less common due to the difficulty of controlling them without the computational power to do FOC which had been around since the 1980s.

If you think anything I have posted is scientifically incorrect or somehow not relevant to maximizing torque per amp of a sinusoidal motor controller please point it out.
Please respect the thread owner.
I started this thread and it is about developing firmware for KT motor controllers.

This thread is not about and please don't discuss here:
1. custom hardware for motor controller
2. FOC

There aren't limitations for creating threads on this forum. If you want to discuss that topics, please create a new thread for that.
 
casainho said:
And yes, I was doing just this before but I think that could not be working because of all that "FOC angle" values before on firmware. Now the values are clear to me and follow the FOC documentation,

Yes, you have cleared up the angle definitions, so it's easier to understand what happens. But the working principle is just the same as before. So the control behaviour will be the same as before....

regards
stancecoke
 
stancecoke said:
casainho said:
And yes, I was doing just this before but I think that could not be working because of all that "FOC angle" values before on firmware. Now the values are clear to me and follow the FOC documentation,
Yes, you have cleared up the angle definitions, so it's easier to understand what happens. But the working principle is just the same as before. So the control behaviour will be the same as before....
I am optimist and I want to think that before the angle at were I was doing "FOC" was incorrect as geofft found with his tests. I was doing at 180 + 60 degrees thinking I was doing well and geofft found it was incorrect but at it is correct at 180 degrees. 60 degrees my be enough to "jump to the phase B current other side" and then the algorithm may work in the wrong direction - that is in what I can think.
Well, I think it is confuse. Anyway, I am optimist and I am happy the ebike brakes and don't vibrate anymore. But that's true it needs more testing.
 
Ah, OK. I never managed to get your master branch running with my controller/motor combination properly. All my testing is with my fork, where I've always done the FOC at 180°.
Printing out the phase current values like shown before is very helpful to understand what happens...

file.php


regards
stancecoke
 
stancecoke said:
Printing out the phase current values like shown before is very helpful to understand what happens...
I did that, looked at the phase current and having always the BEMF/ rotor 90 degrees as timing reference. But I did using my oscilloscope and with ebike accelerating and brake/regen. Although wheel was unload, at least I saw big current values for the quick accelerations and brake, as the wheel is kind of heavy anyway due to the weigh of this Q11 direct drive motor.

I did in the past that log for the mobile phone, I will do that also later but can't say when :)
 
casainho said:
I think that maybe or motor is at 10 of 15 degrees and you should adjust instead MOTOR_ROTOR_OFFSET_ANGLE, because FOC will then be at 180 degrees, while adjusting MOTOR_ROTOR_ANGLE_STARTUP only, means your FOC will not be at 180 degrees...
I want to delete from the firmware the MOTOR_ROTOR_ANGLE_STARTUP, as I think that just like FOC, it is always at a fixed angle value. What may differ is the motor MOTOR_ROTOR_OFFSET_ANGLE, that when well adjusted will make the best startup and best torque and efficiency with motor running.

Can you please verify??

I've now moved the '15' offset my motor seems to need from MOTOR_ROTOR_ANGLE_STARTUP to MOTOR_ROTOR_OFFSET_ANGLE. The result is good, i.e. clean startup with good torque, as before.

Just been for a very short test ride, for gearmotor/throttle-pas users this fw rides really sweetly now, keep up the good work guys..... :wink:
 
stancecoke said:
This thread is about the Kunteng KT36/48/SxxS E-Bike controllers. It has only one phase current sensor. So we can't do "traditional" FOC with this hardware. So any discussion about Park/Clarke transformation is obsolete here....


Regards
stancecoke

That's why I'm saying it's counter productive to approach it as FOC, without Park/Clarke transformations there is no FOC going on in the first place. If you take concepts and code from FOC controllers and try to apply them in a different control scheme it won't work as they rely on the underlying FOC scheme to function properly, you can try and add layers and layers of work arounds only to break other functions and cause cascading faults. There's possibly more effective ways to control a sinusoidal controller, if you focus on emulating FOC behavior you're likely to overlook them. There should be some decent code examples of this type of controller somewhere, they might be a little harder than usual as they became less common as FOC became the norm but I have seen similar solutions in some low cost BLDC drivers without a MCU, they're hardware based but some of the data sheets are pretty informative.

There's other things to consider, with a FOC controller it basically gets the phase lag compensation for free so no one would normally consider switching to 6 step BLDC commutation at higher ERPM. On a sinewave controller without FOC control becomes progressively harder as ERPM increases, switching modes above certain ERPM where torque ripple is not a concern may be more effective.
 
Perhaps we should not call our control strategy "FOC" or even "simplyfied FOC", as it is confusing.
We control the zero crossing of phase B current to a certain rotor position by adjusting the advance angle. It's easy and it works reliably.
So what's wrong with it, except the confusing naming?

regards
stancecoke
 
stancecoke said:
Perhaps we should not call our control strategy "FOC" or even "simplyfied FOC", as it is confusing.
We control the zero crossing of phase B current to a certain rotor position by adjusting the advance angle. It's easy and it works reliably.
So what's wrong with it, except the confusing naming?
It is not confusing, it is a way to implement field oriented control. And it is done like this: motor phases voltages are controlled so the phase currents are oriented to the magnetic field of the rotor magnets (D axis Id current = 0).

1. to get the magnetic field direction, we use as reference the hall sensor signals
2. we find the phase current vector angle by looking at phase B current signal
3. we orient the phase vector current to the magnetic field (keep Id current = 0)
4. we control motor torque (Iq current) using DC shunt
 
Of course you are right, but the naming is still confusing, as "FOC" is normally associated to the approach with Park/Clarke transformation.
Especially "Iq" and "Id" are refering to the rotating coordinate system.

regards
stancecoke
 
stancecoke said:
Of course you are right, but the naming is still confusing, as "FOC" is normally associated to the approach with Park/Clarke transformation.
I think the name would be even more confusing if we invent a new one from what market already know. I think we should not corner ourselves but rather use communication that is recognized by all.

For the tecnhical guys, I can later update the notes I wrote about the control strategy used and that follows field oriented control concept and we get the same good results as you did test some months ago.
 
stancecoke said:
Perhaps we should not call our control strategy "FOC" or even "simplyfied FOC", as it is confusing.
We control the zero crossing of phase B current to a certain rotor position by adjusting the advance angle. It's easy and it works reliably.
So what's wrong with it, except the confusing naming?

regards
stancecoke
There's nothing wrong with it, it's usually referred to as sinusoidal BLDC or just sinusoidal control it's been around for a long time. The problem is it differs greatly to field orientated control, despite using current sense FOC actually derives the stator phase voltages from the current sense data, a PID loop compares the result to the requested output from the current control loop then commands the voltage vector it believes is needed, often multiple iterations are performed. In between all this you have multiple conversions from a 3 axis coordinate to a 2 axis to reduce the computational requirements. There is no physical D or Q axis, you can't align anything to a theoretical coordinate that you did not derive the location of in the first place. Also there is the issue that the entire concept of field orientated control is based on viewing everything from a rotating reference frame, it's too complex to explain in a small post.

If you try and mix bits and pieces of the different control schemes it won't work properly, a sinusoidal BLDC controller can only try to compensate through what is typically referred to as phase advance it doesn't use the same D,Q reference frame as FOC. While you can have a FOC controller using hall sensors or encoders to determine the rotor position it still requires the three stator currents for the FOC calculations. While you can be reasonably sure the hall sensor location approximates the for peak torque in an ideal situation on an outrunner motor at modest speeds you can't assume it emulates the same function as an actual FOC controller. You have to work around things that aren't an issue in FOC while using a different set of calculations.

A brief search turned up some application notes for sinusoidal BLDC controllers but they're less common these days mainly relegated to small pumps and things that don't experience dynamic loads or high torque demands.

This freescale app note is reasonably good but sparse on information on how to address phase lag, the code might still be floating around on the NXP website somewhere.
https://www.nxp.com/docs/en/application-note/AN4869.pdf

Page 20 of this Ti BLDC controller describes a method much the same as used here but it's a completely integrated IC there's no way to know if anything more complex is going on inside and it's a low powered device more for appliances than a vehicle. There's a little about how potential low speed startup issues are solved but that's all.
http://www.ti.com/lit/ds/symlink/drv10970.pdf
 
That both approaches are completely different is obvious, but can you explain (perhaps in an extra thread), why "real" FOC leads to better efficiency than the simple way we do it in this projekt. I think, both approaches try to control the rotating magnetic field to be in 90° to the rotor magnets ...
Here is a nice explanaition "FOC for dummies"

regards
stancecoke
 
stancecoke said:
That both approaches are completely different is obvious, but can you explain (perhaps in an extra thread), why "real" FOC leads to better efficiency than the simple way we do it in this projekt. I think, both approaches try to control the rotating magnetic field to be in 90° to the rotor magnets ...
Here is a nice explanaition "FOC for dummies"

regards
stancecoke

I think the biggest issue is operating under the assumption that the hall sensor represents the position where maximum torque is produced. Like when you run it without any phase advance compensation you're treating it as if the motor is an ideal circuit with no resistance, it works at low speed but degrades as ERPM increases. The same applies to the hall sensor, if treated as an ideal circuit when you align the current sense with the hall sensor perfectly you get maximum torque. Like with the motor you have components that don't function ideally, the current sense, MCU ADC and hall sensor all have different rise times and delays. It should be possible to compensate for it all but then you face issues with any minor changes to controllers or hall sensors between motors. There's probably more issues I'm missing

On the difference between FOC vs sinusoidal BLDC using hall sensors, excluding above issues I imagine it would largely come down to bandwidth, on the FOC controllers I have the FOC loop runs at 15khz or 20khz, though it's not uncommon to see as low as 5khz. While sensor based BLDC can only run the loop at whatever speed the ERPM is while having to make do with less resolution, the FOC controller is only limited to sampling every PWM cycle or whenever it runs out of CPU power.

Considering these factor to optimize these controllers the main things to solve will be, since we can't perform FOC:
Can aligning the current reading and hall data reliably work across different speeds?
Does the single hall and current sensor combo offer enough bandwidth? Perhaps at lower ERPM where you have some phase lag but limited bandwidth some form of interpolation using ERPM values can be used on the phase advance result itself.
If the technique does not work reliably at certain speeds or conditions consider transition to other control methods. For example if performance is poor at higher ERPM, under light loads while moving quickly it might be practical run on an open loop with the halls just estimating ERPM. If there is any limitation the original firmware must have a work around in place.
 
We compared the effiency of our custom firmware with a Lishui controller (that does "real" FOC) and found that there's no big difference at the tested loads. I don't know, if we would see a difference at higher loads...

Effizienzvergleich_3LL.JPG

regards
stancecoke
 
stancecoke said:
We compared the effiency of our custom firmware with a Lishui controller (that does "real" FOC) and found that there's no big difference at the tested loads. I don't know, if we would see a difference at higher loads...

index.php


regards
stancecoke
There shouldn't be much difference in efficiency, motor and controller hardware should impact that more. Even 6 step BLDC can get within 1% or so much of the time. The primary issue is maintaining control under dynamic loads and dealing with different motors. That's why you still find BLDC controllers both 6 step and sinusoidal in many applications, with something like a quadcopter torque ripple and rough throttle response isn't as much of an issue as it is for a direct drive electric vehicle. If it does stay out of sync for extended periods when under a difficult load like climbing a hill efficiency will plummet and will likely burn either a controller or motor. Under light loads with gentle throttle changes even open loop control modes with no feedback at all will generally work.
 
@casainho: I've done a test ride with your suggested advance angle adjustion at regen:
Code:
if(ui16_motor_speed_erps > 3){
	if (ui16_BatteryCurrent > ui16_current_cal_b)
	      {
		if (ui16_ADC_iq_current>>2 > 127 && ui8_position_correction_value < 135)
		{
		  ui8_position_correction_value++;
		}
		else if (ui16_ADC_iq_current>>2 < 125 && ui8_position_correction_value >90)
		{
		  ui8_position_correction_value--;
		}
	      }

	if (ui16_BatteryCurrent < ui16_current_cal_b) //regen, current negative
		      {
			if (ui16_ADC_iq_current>>2 > 127 && ui8_position_correction_value > 90)
			{
			  ui8_position_correction_value--;
			}
			else if (ui16_ADC_iq_current>>2 < 125 && ui8_position_correction_value < 135)
			{
			  ui8_position_correction_value++;
			}
		      }
	}
	else ui8_position_correction_value=127; //reset advance angle at very low speed)

But confirming my former experience, the advance angle runs away :-(

Log with regen.PNG

regards
stancecoke
 
Thank you for testing.

Lately I am being using my 2nd ebike with TSDZ2 motor and that is taking me time away from using oir firmware for KT controllers. I am more enjoying the nice weather of this months.

On last code of FOC, I removed the angle pos and neg limits and so I expected to feel the angle / vibrations.

I need to do more testing with my ebike nr 1.

Luckily seems that a new developer is joining: nieles. Because there are a lot if things that we can do and bring imediatily bring value to us.
 
here is another log with the code of the recent master branch of my fork.
Angle adjust is not perfect, but it produces much more regen current...
It is obvious, that we need a PI-Controller for the angle adjust, as the simple increase/decrease with ++/-- is too slow.

Log with regen_stancecoke_code.PNG

regards
stancecoke
 
Maybe can be of interest of some developers of KT:

I got the firmware for KT LCD3 up to a point were it receives a packet data from motor controller and and prints a number value to the odometer field on the LCD (the sources are on github). The function to print to LCD is this one: lcd_print(number, ODOMETER)
The firmware is structured to be easy to add support for the other fields.

Example of printing a variable:
[youtube]aEfVNVFy9kA[/youtube]
 
I got finally the TSDZ2 motor controler firmware disassembled - here is the file on google docs so anyone can put comments on sections that understand.

The tecnhology should be near from KT motor controllers firmware so we can learn. For instance, I spotted a big array of values that seems like the same we use on KT, for the phase voltages SVM, but seems they are using a bigger array...

https://drive.google.com/file/d/10TKBj_eeEpHKlMHcyRwxi2huQ99P7OBt/view?usp=drivesdk

Original firmware file, etc is here: https://opensourceebikefirmware.bitbucket.io/development_tsdz2/Various--2018.04.18_-_original_firmware_and_debug_session_using_OpenOCD.html
 
after i received my 12Fet 48V controller from risunmotors a few weeks ago i had some time today to test a little bit.

At first i made sure hall sensors and phase connections are correct by using the original firmware. I have connected the controller to an old bafang 250w geared motor on my bench

After that i set up WSL bash on windows 10 and built the SDCC from source. It worked!. So no need to use any cygwin crap or VM at all.

Then i built https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware. I had to change battery count in config.h, rest is still on default.

Motor runs but takes a lot of current. No load current is about 10A while it was 1A before. Startup is very rough and fast, low speed is not possible. I changed phase cables a few times but did not find a better combination. So this must be a software issue ...

any idea what i can do?
 
Back
Top