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

[Bersekz]

If you want to understand how to do the commutation of the BLDC you can find detailed information in the internet, but this is a real deep dive and not necessary for implenting the gearsensor.

I thought this firmware uses FOC sinusoidal commutation, not BLDC?
Anyway, besides implementing extra functions on your already working firmware, I'd like to better understand how to write a firmware from scratch, I think easiest is PID controller so I'm looking into that. Do you have any EVB brushless to advise, a developer board for brushless motors with a demo firmware already written and working?

Do you have a link to the gearsensor? I guess it just pulls the signal pin to gnd, when a gear shift is detected. So you can use the brake input of the controller to make the middrive motor stop to avoid shifting under full load.

Official site: http://gearsensor.com/

Originally, it was connected in series to a brake, on newer motors they started making a dedicated cable for it. The problem of having the gearsensor in series to the brake was that it had a higher activation time/latency for the cutoff.

Basically, what I'd like to do is implement 10 profiles for current and speed (https://i.imgur.com/1BY5MzA.jpg) + add an extra cutoff column and change the cutoff time for each assist level. In addition, I'd like to link this cutoff time also to my current speed and current gear.

The reason for this is, the gearsensor is amazing, but it has a big problem. If you go buy any motor that implements it (bafang, brose, etc.), you notice they use the same exact cutoff time for all assist levels and gears, and what happens is that at higher gears you can feel the motor tear off when you change gear. Thus I'd like to take this great tool, intercept the signal sent by it every time you change gear, but customise the cutoff time for every single assist level, for every single gear, and also based on what's my current speed.

Anyway, as a starting point, I'd be just happy to have 10 profiles with 10 different cutoff times tbh (something like this: https://i.imgur.com/Y0CVPYA.jpg). Then you can start adding more stuff.

 

[lizardmech]

I thought this firmware uses FOC sinusoidal commutation, not BLDC?
Anyway, besides implementing extra functions on your already working firmware, I'd like to better understand how to write a firmware from scratch, I think easiest is PID controller so I'm looking into that. Do you have any EVB brushless to advise, a developer board for brushless motors with a demo firmware already written and working?

Technically it's neither, its sinusoidal like FOC controllers are but it doesn't compare stator flux with rotor flux angle with complex math as FOC does. You get the smoother sinewave commutation of FOC with the lower CPU overhead of BLDC, the downside is you gain some of the headaches FOC has with having to reconfigure it for different motors. I'm not sure if it even has a specific name, it appears to have become popular largely due to electronic gimbals, BLDC is too rough at low speeds for them but they need to run 2 motors off one cheap MCU. The trade off is likely issues at higher ERPM when under load on more powerful motors, it should be possible to compensate but the amount of motor parameters needed is unknown.

 

[stancecoke]

Hmmm... how did you observe that??

The motor was noisy and drew much current without producing torque after a longer regen time.

Did you used "my" branch?

No, I just tested the HighSpeedMotor-Branch.

About that mod to torque sensor, so in the end we have an usual PAS signal

Yes

 

[stancecoke]

I thought this firmware uses FOC sinusoidal commutation, not BLDC?

The term "BLDC" only describes the design of the motor, not the way it is commutated.

Originally, it was connected in series to a brake, on newer motors they started making a dedicated cable for it. The problem of having the gearsensor in series to the brake was that it had a higher activation time/latency for the cutoff.

Basically, what I'd like to do is implement 10 profiles for current and speed (https://i.imgur.com/1BY5MzA.jpg) + add an extra cutoff column and change the cutoff time for each assist level. In addition, I'd like to link this cutoff time also to my current speed and current gear.

It's up to you how a signal at the brake input pin is processed. You can use a separate pin alternativly, as honya96 suggested, of course. But the additional input lines are not implemented in the code yet. (PA1 for the "learning"-wire, e.g.)





btw, it is much more intelligent to pimp your middrive with a torquesensor, then you can reduce the motor power for shifting in the same way, you do with a motorless (bio-) bike: with your legs. :wink:

regards
stancecoke

 

[Bersekz]

Maybe it's a bit OT, but I went through lots of Evaluation Boards (since I'd like to understand how Brushless Motors work). I found eventually this one which seems good, with a proper software and firmware and all the source code, what do you think guys? Could it be a suitable platform for a beginner?

Control Board:
https://www.infineon.com/cms/en/product/evaluation-boards/eval-m1-1302_36-84a/
Power Board: (unfortunately, the best I found was 300W in DC)
https://www.infineon.com/cms/en/product/evaluation-boards/eval-m1-05f310/

 

[stancecoke]

Could it be a suitable platform for a beginner?

I think, you should stick at a STM32 processor, as the code will be quite similar to the one we use in this project... (except the strange interrupt declaration SDCC uses )
https://github.com/open-bldc

regards
stancecoke

 

[Bersekz]

Could you pl

Could it be a suitable platform for a beginner?

I think, you should stick at a STM32 processor, as the code will be quite similar to the one we use in this project... (except the strange interrupt declaration SDCC uses )
https://github.com/open-bldc

regards
stancecoke

Could you please advise me a developer board using STM32 processor? Maybe a board where you can attach physical controls like brakes and other stuff for testing. I can't believe there is no guide/tutorial video on YouTube or anything for learning how to control a bike or other vehicles and write a firmware, there must be something somewhere. I understand you find open source firmware written by somebody, but these guys must have started from somewhere, I doubt they started writing code from scratch without having the faintest idea what to do and figured out everything by theirselves. A step-by-step guide that explains every single part of code and how you debug/test to add new features to a firmware is really impossible to ask?

 

[lizardmech]

Could you please advise me a developer board using STM32 processor? Maybe a board where you can attach physical controls like brakes and other stuff for testing. I can't believe there is no guide/tutorial video on YouTube or anything for learning how to control a bike or other vehicles and write a firmware, there must be something somewhere. I understand you find open source firmware written by somebody, but these guys must have started from somewhere, I doubt they started writing code from scratch without having the faintest idea what to do and figured out everything by theirselves. A step-by-step guide that explains every single part of code and how you debug/test to add new features to a firmware is really impossible to ask?

If you want a commercial dev kit I would suggest the texas instruments motor control kits, they have the best low price mcu and motor control kits, those infineon ones have high voltage IGBTs and aren't well suited to ebikes. The downside is the commercial ones all keep some of the code hidden in encrypted libraries, generally they won't let you see the code for the sensorless FOC observer.

The most popular two options would be the STM32 kits and the Ti kits, the STM32 is slightly easier to use and has a GUI for configuration, you just have to watch out, only a few of their nucleo dev boards actually work with their motor control software. On the Ti one you have to manually write everything into the firmware and compile but overall the motor control software is more advanced than the STM one.

For full functionality and complete open source the VESC is the only one I know of at the moment they range from about $80 to $400 depending on the quality. You can easily configure throttle, brakes etc. via a gui. The only downside is it's an immensely complex project and not easy to modify if you want to play around with motor control code.

One interesting option is a stm32f407 dev board + a ti mcu board and motor board, it's possible to wire up the the STM32F407 board to the Ti motor control board and test both the STM motor software as well as VESC software using it. With only two $20 MCU boards and a $50 motor control board you can play around with 3 different sets of motor control software.

 

[Bersekz]

Could you please advise me a developer board using STM32 processor? Maybe a board where you can attach physical controls like brakes and other stuff for testing. I can't believe there is no guide/tutorial video on YouTube or anything for learning how to control a bike or other vehicles and write a firmware, there must be something somewhere. I understand you find open source firmware written by somebody, but these guys must have started from somewhere, I doubt they started writing code from scratch without having the faintest idea what to do and figured out everything by theirselves. A step-by-step guide that explains every single part of code and how you debug/test to add new features to a firmware is really impossible to ask?

If you want a commercial dev kit I would suggest the texas instruments motor control kits, they have the best low price mcu and motor control kits, those infineon ones have high voltage IGBTs and aren't well suited to ebikes. The downside is the commercial ones all keep some of the code hidden in encrypted libraries, generally they won't let you see the code for the sensorless FOC observer.

The most popular two options would be the STM32 kits and the Ti kits, the STM32 is slightly easier to use and has a GUI for configuration, you just have to watch out, only a few of their nucleo dev boards actually work with their motor control software. On the Ti one you have to manually write everything into the firmware and compile but overall the motor control software is more advanced than the STM one.

For full functionality and complete open source the VESC is the only one I know of at the moment they range from about $80 to $400 depending on the quality. You can easily configure throttle, brakes etc. via a gui. The only downside is it's an immensely complex project and not easy to modify if you want to play around with motor control code.

One interesting option is a stm32f407 dev board + a ti mcu board and motor board, it's possible to wire up the the STM32F407 board to the Ti motor control board and test both the STM motor software as well as VESC software using it. With only two $20 MCU boards and a $50 motor control board you can play around with 3 different sets of motor control software.

Hello, since you seem to know a lot about this, could you please provide me directly with the links of what would you buy if you were to learn/teach how to start up from scratch on how to control a brushless motor? (products links on manufacturer official site or electronic shop are both fine). Also, in the very remote case somebody has ever made a guide/asked for something similar on any other existing forum on the internet, I'd be glad if I could have the link to that also.

 

[casainho]

Ok I mean from no interpolatiom to 60.. I tried values from 5 to 300 (300-never switch)

So "FOC" starting and 60° interpolation are 2 different things?

I am almost sure your issue happens because FOC starts and not the interpolation. So, start by disable FOC:
Origonal code:

// minimum speed to do FOC
    if (ui16_motor_speed_erps > MOTOR_ROTOR_ERPS_START_INTERPOLATION_60_DEGREES)

Change to:

// minimum speed to do FOC
    if (ui16_motor_speed_erps > 1000)
    {

So, let's see if that issue happens without FOC running.

If so, probably you have a very different start angle from the one FOC setup, hence that big change in speed and current.

 

[honya96]

So, let's see if that issue happens without FOC running.

I dont see that jump on road..

But after a lot testing I hope I got good feedback for you, and hope the bugs I found are not all only my case.

1. After few second stanby the fw freezes, no reaction to anything, if brake symbol is active when freezed it stays active..
2. Releasing regen brake at around the interpolation switch point +? Adding throttle brakes really strong for a while
3. Throttle reaction is still too slow for acceleration and waaaay too slow after releasing.
4.Throttle stays full sometimes, I dont know for how long (testing at 3kw+, so I had to brake :lol: ) luckily brake sensor overwrites that.
5. (Only my case) At 3kw+ even just a little throttle gives 500w minimum



as it feels, before we was limiting phase current combined only

and now - calculating battery current from it, right?

It gives me better acceleration with the same max. real battery amp draw.

Edit: + Regen phase current at 66 is extremely low.

 

[casainho]

So, let's see if that issue happens without FOC running.

I dont see that jump on road..

But after a lot testing I hope I got good feedback for you, and hope the bugs I found are not all only my case.

1. After few second stanby the fw freezes, no reaction to anything, if brake symbol is active when freezed it stays active..
2. Releasing regen brake at around the interpolation switch point +? Adding throttle brakes really strong for a while
3. Throttle reaction is still too slow for acceleration and waaaay too slow after releasing.
4.Throttle stays full sometimes, I dont know for how long (testing at 3kw+, so I had to brake :lol: ) luckily brake sensor overwrites that.
5. (Only my case) At 3kw+ even just a little throttle gives 500w minimum



as it feels, before we was limiting phase current combined only

and now - calculating battery current from it, right?

It gives me better acceleration with the same max. real battery amp draw.

Edit: + Regen phase current at 66 is extremely low.

1. strange but I can't say it does not happen to me sometimes...
2. I also have that issue but does not happens always while riding. May be wrong FOC implementation during brake/regen, as Stancecoke did discover. I think I know a way to do proper implementation.
3. Even with direct PWM control using throttle?
4. I would say that is because of I term of PI controller... braking will execute:

void pi_controller_reset (struct_pi_controller_state *pi_controller)
{
  pi_controller->i16_i_term = 0;
}

I really think the I term accumulation is the issue... maybe you should increase the PI terms..

5. Please tell me what is the voltage at ADC pin for your throttle at zero. I am thinking of this:

#define ADC_THROTTLE_MIN_VALUE 51
#define ADC_THROTTLE_MAX_VALUE 183

Yes, I also get low regen with 66... I need to revise this.........

 

[honya96]

3. Yes, last time I tested direct pwm it felt also slower than expected..
4. Will try.
5. Now I remember, lowering the min value helped when trying Stancecoke's fw on table. I dont understand why it should, but think it will help.

 

[casainho]

5. Now I remember, lowering the min value helped when trying Stancecoke's fw on table. I dont understand why it should, but think it will help.

ADC_MIN value is the voltage value that will be considered after which throttle is enable/starts and will scale/map throttle value starting at that value.

Let's say you measure 1.1V on your controller circuit STM8 pin (not valid to measure throttle pin only, must be connected to controller and measure STM8 ADC pin!!).
5V is equal to 255 ADC value. You should use an ADC MIN value a bit higher than 1.1V, let's define 1.25V.
(1.25 x 255) / 5 = 64. ADC_THROTTLE_MIN_VALUE should be 64.

 

[geofft]

I haven't contributed much feedback just lately, just thought I'd let you guys know where I'm at with the firmware just now.

I've been using a build of the Master branch that I downloaded way back on 12-1-18 with a few configuration changes to suit my setup. I'll list the pros/cons (compared to the stock f/w) below:-

Cons:-
1) Still a little slow to build up pas from a standing start compared with stock which is fairly aggressive. Easily cured by simply adding some throttle however, so no big problem for me.

2) Controller runs a little warmer than with stock f/w, on rides of approx 5km distance stock f/w measures around 38degC, 'new' f/w around 44degC (Controller inside saddlebag in both rides).

3) Very occasional f/w lock-ups, with around 250w showing on wattmeter and no response to either throttle or pas input, usually seemed to happen when adding throttle in addition to pas. Haven't seen this for the last two or three rides however, maybe was some hardware issue peculiar to my setup.

Pros:-
1) Motor seems to run slightly quieter and smoother with 'new' f/w.

2) Blending in throttle in addition to pas works smoothly and progressively, unlike stock which does this in a rather jerky on/off manner.

3) Battery indicator now gives useful info on battery SOC, unlike stock which seems impossible to configure for a 12s battery.

.....so probably enough advantage with 'new' f/w over stock to now become my preferred choice. Note again that the above comments relate to f/w downloaded on 12th Jan 2018.

Just out of interest yesterday (9-3-18) I downloaded the current Master branch build and gave it a try but had issues with both throttle and pas only working intermittently (very strongly) for a couple of seconds, then cutting out. This is not a problem for me, as stated above the earlier f/w download works well for my setup. However, if you need anything tested with a geared motor setup in the future I'll be happy to help.....

 

[honya96]

but had issues with both throttle and pas only working intermittently (very strongly) for a couple of seconds, then cutting out.

I think you have not changed from torque sensor to THROTTLE_PAS in config.h

 

[casainho]

I haven't contributed much feedback just lately, just thought I'd let you guys know where I'm at with the firmware just now.

3) Battery indicator now gives useful info on battery SOC, unlike stock which seems impossible to configure for a 12s battery.

This is not a problem for me, as stated above the earlier f/w download works well for my setup. However, if you need anything tested with a geared motor setup in the future I'll be happy to help.....

Thank you for the feedback. Great that you could find a version that works ok for you.

Good to know that battery indicator works for you. I remember you telling that there was some issues and after that I really found an issue and corrected - it should work now as expected. Also, the battery undervoltage protection now works really great, as honya96 suggested: power is reduced to motor as soon battery undervoltage is hit and so you will feel less assist from motor as soon your battery is near to be discharged but will never cut suddenly the power, so you need to pedal harder in the end as you be getting less assist from the motor.

Last code had some big changes and you need to config.h using as reference config-example.h file and not the Java tool. Later, with a stable firmware, Java tool should be updated to include the latest changes on firmware.

 

[geofft]

but had issues with both throttle and pas only working intermittently (very strongly) for a couple of seconds, then cutting out.

I think you have not changed from torque sensor to THROTTLE_PAS in config.h

Thanks Honya, looks like you're correct. Stupid mistake by me, didn't notice the defaults in config.h had changed.

On the subject of torque sensors, I'd like to give one of these a try but have to admit I know very little about them. My first issue is the method of connection to the controller - do you use the existing pas and throttle connectors or some other way?

Maybe there's some info on this somewhere in the f/w documentation, if so a pointer to it would be good... :wink:

 

[casainho]

On the subject of torque sensors, I'd like to give one of these a try but have to admit I know very little about them. My first issue is the method of connection to the controller - do you use the existing pas and throttle connectors or some other way?

Maybe there's some info on this somewhere in the f/w documentation, if so a pointer to it would be good... :wink:

I am using torque sensor only on my 3 ebikes and I love it, because I want a ebike experience and not motorcycle.

Yes, our page with a lot of technical details about the torque sensor including wiring: https://opensourceebikefirmware.bitbucket.io/development/Torque_sensors--BMSBattery_torque_sensor.html

Yes, wire to PAS and throttle pins!! And LCD assist level works to multiply the torque sensor computed signal, so you can make it work with very little torque on the pedals.

And the torque sensor code was fine developed and tested. For instance, the sensor detects torque even if pedals are not rotating but the code filters that situation well. But you get signal when the wheel is stopped. If wheel is running, you get signal only if you have cadence on pedals

 

[geofft]

And the torque sensor code was fine developed and tested. For instance, the sensor detects torque even if pedals are not rotating but the code filters that situation well. But you get signal when the wheel is stopped. If wheel is running, you get signal only if you have cadence on pedals

Sounds interesting, I was wondering about these situations. Will probably order one soon and have a play.....

 

[honya96]

http://s.aliexpress.com/AryyqeER?fromSns=Copy
http://s.aliexpress.com/zINzeMzi?fromSns=Copy

I would like to try, if these work. I don't like the big bulky ones you have.

 

[honya96]

@casainho - I have an idea.

For legal purposes in EU, on pedal bike, Throttle can work only to 6km/h

What about something like the "cheat" as it is on stancecokes branch. Like - you press and release brake few times in specific intervals and it limits the throttle to 6km/h/250w (+ remembers even after turned of and on) +only can switch when at standstill.

I know you don't use throttle but I think this will be good future function for a lot of people so just sharing the idea

 

[casainho]

@casainho - I have an idea.

I know you don't use throttle but I think this will be good future function for a lot of people so just sharing the idea

That is not a priority for me, at least, I want first having direct drive motor working well. I created a new issue with that idea, so we not forget it over the time: https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/issues/29

 

[geofft]

@casainho - I have an idea.

For legal purposes in EU, on pedal bike, Throttle can work only to 6km/h

What about something like the "cheat" as it is on stancecokes branch. Like - you press and release brake few times in specific intervals and it limits the throttle to 6km/h/250w (+ remembers even after turned of and on) +only can switch when at standstill.

I know you don't use throttle but I think this will be good future function for a lot of people so just sharing the idea

Would it maybe be better to always power up in 'legal' mode (6kph thr/25kph/250w) and need to be switched to 'full on' - that way if the bike becomes the subject of a legality test it will always power up legal. Rather than 'cheat' maybe we should call it something like 'off-road mode' - doesn't sound so much like you're trying to...er....cheat... :wink:

 

[casainho]

@casainho - I have an idea.

For legal purposes in EU, on pedal bike, Throttle can work only to 6km/h

What about something like the "cheat" as it is on stancecokes branch. Like - you press and release brake few times in specific intervals and it limits the throttle to 6km/h/250w (+ remembers even after turned of and on) +only can switch when at standstill.

I know you don't use throttle but I think this will be good future function for a lot of people so just sharing the idea

Would it maybe be better to always power up in 'legal' mode (6kmh/250w) and need to be switched to 'full on' - that way if the bike becomes the subject of a legality test it will always power up legal. Rather than 'cheat' maybe we should call it something like 'off-road mode' - doesn't sound so much like you're trying to...er....cheat... :wink:

I like that idea of booting always in street mode and thinking that mode changing will happens rarely. But, for users living in places without limitations, a flag on java tool would boot firmware always in offroad mode (no limitations).