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

Alan B said:

Another is to drive the PWM'd switch's other half with inverse PWM. This way the throttle generates acceleration when above the back EMF and deceleration when you throttle back and drop below back EMF voltage out of the controller.

Click to expand...

We are doing that one!!

That's at the full PWM rate, should be smooth, but you might have to clamp the throttle request UP to keep from overvoltage/overcurrent on regen. So it is a bit strange compared to the usual clamping.

Alan B said:

That's at the full PWM rate, should be smooth, but you might have to clamp the throttle request UP to keep from overvoltage/overcurrent on regen. So it is a bit strange compared to the usual clamping.

Click to expand...

Sorry, didn't understand what you mean by clamp on this subject. What is the "usual clamping"? why do we need to do that clamp??

Control the regen overcurrent / overvoltage. Instead of reducing the PWM to reduce current the PWM must be increased to reduce current when regenerating.

Alan B said:

Control the regen overcurrent / overvoltage. Instead of reducing the PWM to reduce current the PWM must be increased to reduce current when regenerating.

Click to expand...

Ah ok, now I understand. Our firmware is already doing that, that is why it controls regen current well -- here the max current and max regen current control:


But there is a feature that I need to implement, I already tried but didn't worked as I expected:
- when motor is already rotating, freewheel, if I want to apply a duty_cycle value, let's say with current = 0, I need to apply a vbat*duty_cycle = BEMF. I can read vbat and I define the duty_cycle but I miss the BEMF value as I can't read it... so, how to start the motor while it is already running??

Read motor RPM and calculate Back EMF by multiplying with the motor constant.

casainho said:

Stancecoke, as you probably saw, there is a 4 pin header on the board, probably to program that microcontroller. Were you able to see which microcontroller is?

Click to expand...

It is a Renesas UPD78F9202MA. I had a discussion about it on mikrocontroller.net, as the µC is defective on my sensor. I now use the signal from the hallsensor pin directly.



There are two hallsensors on the ciruit board that generate a quadrature signal. There are many examples for encoding quadrature signals on the web.

regards
stancecoke

Alan B said:

Read motor RPM and calculate Back EMF by multiplying with the motor constant.

Click to expand...

Good idea and in fact I already tried that but there are some issues:
1. that is another motor parameter for user to know but original firmware never ask user to setup it, so, original firmware may be doing something different....
2. when I tried, it seems to work for the sinewave amplitude but the other thing needed is the sinewave phase to be the same as BEMF. And on my tests, there is a kind of short circuit and since I recall, the issue is the phase because our FOC algorithm adjust automatically the phase but only when there is phase B current and since motor is rotating with almost no phase B current... so I don't know.......

stancecoke said:

There are two hallsensors on the ciruit board that generate a quadrature signal. There are many examples for encoding quadrature signals on the web.

Click to expand...

So you are taking to outside the signal of each hall sensor??

I found that the PAS sensor only gives a 50% duty_cycle signal because the magnets are equally space as their size, unlike PAS magnets... and this way I can't detect rotation direction :-(
Let's see If I can get other options...

casainho said:

so I don't know.......

Click to expand...

to be honest, I don't understand your problem.
The control loop keeps the current at zero automatically if the throttle is closed, so the right duty cycle is applyed at every time with a direct drive. If you have a geared motor, you start at zero erps every time, that's no problem, too.

I've implemented the "regen-throttle" this afternoon. It was much easier than I thought, see the recent commit on the torque-simulation branch. I've soldered a wire to "X4" and connected it to a poti to set the regen amps.
In the video our controller with the open source firmware drives the Sanyo Dynamotor that works as a generator on my test bench. The Shengyi middrive motor is driven by my 12 FET Lishui and simulates a downhill ride.

[youtube]6sS2sDfgb10[/youtube]

In the plot you can see that the control loop keeps the current at zero at the first 12 seconds. So the wheel turns free with no resistance. (riding downhill with no braking). Then I applied the "regen-throttle" and you can see how the current is regulated to negative values (braking the wheel) ...



I took a ride with my "tinkering-bike" in torque-simulation mode today, it went pretty good. The max current was set to 6A and I found 6.07A peak in my Turnigy after the ride in assist-level 5




regards
stancecoke

stancecoke said:

to be honest, I don't understand your problem.
The control loop keeps the current at zero automatically if the throttle is closed, so the right duty cycle is applyed at every time with a direct drive. If you have a geared motor, you start at zero erps every time, that's no problem, too.

Click to expand...

I wish it would be so simple
So, what happens when you break? the motor coast and the duty_cycle goes to 0, we loose track of both duty_cycle as also FOC angle.

On the original firmware of S06ST, we can use the throttle + torqe sensor. If you use throttle, when you release it, you will see the motor coasting -- the same not happens when using only the torque sensor, as it regens...

Can you think in a solution for this problem?

And thank you for all your information and feedback. Very happy to see that you could ride -- and the tests and documentation you shared!!

casainho said:

So, what happens when you break? the motor coast and the duty_cycle goes to 0, we loose track of both duty_cycle as also FOC angle.

Click to expand...

Why do you let the motor coast at braking? Just set the current target to zero and let the control loop do it's job!!!

casainho said:

So you are taking to outside the signal of each hall sensor??

Click to expand...

No, I just use one hall sensor and have no direction detection implemented, as in torquesensor-mode it is not necessary. In torque-simulation mode the motor starts turning forewards when pushing the bike backwards and the pedals are turning backwards. That is not good and has to be improved. (or a PAS with internal direction detection has to be used)

I have never looked at the pure hallsensor signal, but I don't believe that it's exactly symmetrical. The duty cycle of exactly 0.5 is generated by the µC

regards
stancecoke

stancecoke said:

Why do you let the motor coast at braking? Just set the current target to zero and let the control loop do it's job!!!

Click to expand...

Did you ride like that? Do you think it will work? the test ride you did today was like that?
The regen, do you think is smooth or make vibrations on the motor?

casainho said:

Do you think it will work?

Click to expand...

Of course this works, as you can see in the video and in the plot. There's no difference in sound between accelerating (positive current) and regenerating (negative current).

The ride was without regen but with current control active all the time, the brake switch was not connected...

regards
stancecoke

Today I updated the firmware to verify if battery voltage is equal or higher than absolute max battery voltage and reduce regen current on that situation. Seems to work well, on the lab power supply, the firmware simple didn't regen/break as the power supply were using even higher voltage that the 7S (24V) battery packs and that way it also protects then I lab power supply and battery pack.



Also now when I hit the brakes, the target duty_cycle value is set to zero value and that way the ebike will regen/brake, until I release the brakes and the throttle/PAS/torque sensor set a new target duty_cycle value:



Then I went to test on the bicycle and the regen/brake seem to be soft, as It should be. It was also very slow break as the regen current were configured to 3A only. After I talked with my friend that owns the ebike workshop and told me that for regen/braking a few seconds, I can use the same regen current as the one I use for accelerate the motor, on this case is 15A.

But the test on the bicycle was not good because I think most part of time the motor didn't work well because of FOC algorithm was failing... I need to verify the FOC configuration/motor angle for this direct drive slow ERPM motor, which I didn't yet.

Hm, that's not the way I've solved the regen. Your current-controller only controls positive current, you've underlined that in the comment:


to regen with the break lever, you just set the duty cycle to zero and then let the regen-current-limitation-function increase it again? I don't understand that. Why don't you let the current-control-loop do this job?

You've not committed your last changes to github?

Regards
stancecoke

stancecoke said:

Hm, that's not the way I've solved the regen. Your current-controller only controls positive current, you've underlined that in the comment:

Code:

 // make sure current is not negative, we are here not to control negative/regen current

Click to expand...

I have 2 current controllers, one that is fast on PWM cycle code and other slow with PI controller.
For this tests I am being using the fast controller.

stancecoke said:

to regen with the break lever, you just set the duty cycle to zero and then let the regen-current-limitation-function increase it again? I don't understand that. Why don't you let the current-control-loop do this job?

Click to expand...

The slow loop controller just sets duty_cycle_target while the fast one controls duty_cycle. duty_cycle have the higher priority and so I am actuating on it for the regen controller.

Hmmm, and on my code, I just commented/disabled the slow loop controller, so it should not interfere -- thanks for pointing that out!!

I can use motor_controller_state_is_set (MOTOR_CONTROLLER_STATE_BRAKE); to know if user is braking and if so, disable that slow loop controller...

stancecoke said:

You've not committed your last changes to github?

Click to expand...

Yes, I was in a hurry -- just did now

And corrected regen controller to (untested):

OK. In the torque-simulation fork, the (perhaps useful) redundant control of the duty cycle in the fast loop is disabled. All tuning of the duty cycle value happens in the update_setpoint.c, following the motto "keep it simple"

regards
stancecoke

stancecoke said:

OK. In the torque-simulation fork, the (perhaps useful) redundant control of the duty cycle in the fast loop is disabled. All tuning of the duty cycle value happens in the update_setpoint.c, following the motto "keep it simple"

Click to expand...

I really don't like that idea because:
- reading and controlling max motor current is needed to protect the motor controller/mosfets from burning
- reading and controlling max regen current is needed to protect the battery cells from overcharge and the controller/mosfets from burning
- ramp up/down of duty_cycle at fixed frequency is important to guarantee the motor will not accelerate to much fast and avoid FOC fail

On slow loop, we will be developing/adding features that are yet to be implemented and need heavy code with floats operations, that will slow more and more that very important motor control tasks. Also, it is easy to have a bug on the new features on the slow loop code and that will impede to run that motor tasks.

On the fast loop, we have guarantee that code will run every time at fixed frequency, fast. I added the protection of watch dog timer to that code, the system will reset if for some reason PWM cycle code don't run -- on the slow loop, I think will be to much difficult as the time will be varying as we will adding/changing new features.

And I think the motor control tasks should be near to be finished. We just need to have a robust FOC, motor max current controller, motor regen current controller and the duty_cyle ramp up/down. I think that only FOC may no be so robust and need rework for fine adjustment in angle values for each motor so we can get the best efficiency possible for each motor.

For my new Q11 direct drive motor, I need to see if FOC is work well - for what I could understand, what fails sometimes is the transition from no interpolation to interpolation. I wish there was a way to detect that fail and stop the motor...

casainho said:

For my new Q11 direct drive motor, I need to see if FOC is work well - for what I could understand, what fails sometimes is the transition from no interpolation to interpolation. I wish there was a way to detect that fail and stop the motor...

Click to expand...

I remember to see a case that when failing, the angle would run off to a max or min value, like getting out of sync. Since I remember, the FOC can adjust the angle of +-30º or something like that, other higher/lower values don't make sense. So maybe I need to check if the angle of FOC is withing that range... if not, stop the motor and consider a "motor in short circuit".

casainho said:

I added the protection of watch dog timer to that code, the system will reset if for some reason PWM cycle code don't run

Click to expand...

The watchdog in the fast loop is important of course. Having one central PI-controller that makes sure, that there are no sudden jumps in the dutycycle value is much more reliable, I think. The fast loop should concentrate on keeping track of the rotor position/sine table index and FOC control, that's the really time critical task...

But we can keep our little contest, who burnes more mosfets My score is still two 8)

regards
stancecoke

Hi all, I'm new here.
I'm trying to compile your code on windows 10 but I get the following error:
make: *** No rule to make target `StdPeriphLib / src / stm8s_itc.rel ', needed by` main'. Stop.
I have already read the pdf made by stancecoke, but...
Are there any problems with the .rel extension?

Which branch have you tried? The working windows version is in my fork.
But it's no problem to make the other branches work, I can update the makefile_windows, if you tell me which branch you want to try.

regards
stancecoke

master branch
Uh, i'm sorry ...the url branch present in pdf gives me 404 error.

the pdf is quite old and the links are partly dead. But the document still describes the "how to" in principle.
I've just updated the makefile_windows in the master branch, it should work now.

regards
stancecoke