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

geofft said:

We look forward to this full feature version appearing sometime soon.... :wink:

Click to expand...

Throttle is activated always in offroad mode now! There's no feedback in the display, that you've activated the offroad mode actually.

regards
stancecoke

stancecoke said:

geofft said:

We look forward to this full feature version appearing sometime soon.... :wink:

Click to expand...

Throttle is activated always in offroad mode now! There's no feedback in the display, that you've activated the offroad mode actually.

regards
stanecoke

Click to expand...

That was quick...
Will give it a try tomorrow.

-dg said:

I finally got my controllers and downloaded and built the tool chain and the project sources (from github) so I can start contributing.
I'm working on Linux, specifically Ubuntu 18.04. My immediate goal is to get all the related projects to build and to document and possibly script the process. If I get this done, I'd like casainho and stancecoke to add or update the documentation to their repos so the next person has an easier time.

Click to expand...

I would like to give you write access - please tell me your github account.

I tried to build both the casainho projects and the stancecoke project.

-dg said:

The others: Kunteng_LCD3_firmware and TongSheng_TSDZ2_motor_controller_firmware fail to build because the StdPeriphlib/src directory is missing. It is included in the BMSBattery_S_controllers_firmware project. Once I added it I was able to build all the projects.

Click to expand...

Good to know. I will correct that later.

So, TSDZ2 and LCD3 are really different projects from BMSBattery_S_controllers_firmware. Which hardware/motor controller do you have and plan to develop for??

-dg said:

Reading source code I see that all these projects use printf(). printf is almost 2Kb. I'd be happy to submit a patch to avoid printf, or to supply printf_lite() which would have just %d and %s. How should I submit patches?

Click to expand...

Fork and than submit a pull request.

-dg said:

One idea that has come up several times in this thread is to have the configuration adjustable without reflashing. I am thinking we could use the serial interface that connects the LCD to set parameters in both the controller and in the LCD by connecting a serial line. I'm also thinking of building something like a headless Cycle Analyst that could handle things like cruise control or different types of throttle.

To make this useful we would need a protocol to communicate settings that would be more general than the current protocol between the LCD display and the controller. Looking around, I found Modbus https://www.lammertbies.nl/comm/info/modbus.html which is used to send state info and settings between different industrial controllers. It is very simple and would not require much code. The idea is that we could use any serial device like a bluetooth dongle or a USB serial and change settings, or read data back from eiher the controller and the LCD. Since it is addressable we could also use Modbus to handle the LCD to controller communication so if we wanted to provide new displays on the LCD it would be easy to do so in a structured way instead of just taking another byte onto the existing protocol.

Since Modbus has been around since 1979, there are lots of interoperable implementations for Linux and Windows in a variety of languages and for various micro controllers. There are at least a dozen AVR or Arduino packages on github and even a couple for STM8 that could be adapted.

Click to expand...

Well, I am developing LCD3 and TSDZ2 firmware and I am at a point that I feel the need of a more elaborated protocol between them, mostly like some specific communication to send data when we are on configuration menu and other data when we are at main menu/screen.

Here the list of features of our OpenSource LCD3 firmware: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/TSDZ2-and-KT-LCD3-advanced-features

-dg said:

Specifically I am interested in making a multi button throttle for drop bars that would support multiple hand positions and cruise control and power settings without requiring a display. This might be based on one of the $1 STM8S breakout boards connected via the LCD serial to the controller. It would read speed and cadence etc from the controller and the buttons state and then send throttle either via the throttle wire, or even better via Modbus over the serial line. Ideally this device could live on the bars with the brake lever sensors and the throttle buttons and only have the 4 wire serial+power interface to the controller so that it would be fly-by-wire and there would not be such a mess of cable all over the bike.

Is this of any interest? Do I need to explain it better?

Click to expand...

Currently, I am interested in using LCD3 and TSDZ2 motor and motor controller - not much using a very custom hardware.

casainho said:

So, TSDZ2 and LCD3 are really different projects from BMSBattery_S_controllers_firmware. Which hardware/motor controller do you have and plan to develop for??

Click to expand...

I have Q100H, Q128H and Bafang SWXH, but I'm not opposed to trying other things.

I will say that it seems to me better to have submodules of the same project than different projects as surely there is lot of common code and setup. For example, the board initialization, reading the ADC, the UART handling, the PAS/throttle/torque sensor input, brake levers, under voltage monitoring, etc and probably a lot more are similar or identical between the original KT controller project and the TSDZ2. LCD3 applies to both. I'm thinking an organization more like SDCC where most of the compiler is the same but stm8 and 8051 have specific sub modules.

I say this because I think the current multiple projects approach risks fragmenting what is already a very small user base. The number of people who:

- want an electric bike
- want to make their own bike
- want to have open source firmware
- know enough/are brave enough to open the controller and solder onto it.

That's not that many users. Then for contributors they have also to be able to program and debug. Very few people are left. But, I am hopeful that there might be still be enough to make this a real project if we can collect them all in one place. If we divide them up along the lines of hubmotor/central motor/display/no display/extra hardware/no extra hardware/windows/linux then it seems we will have 3 or 5 or 7 one person projects that die off soon instead of one multi person project that can survive and make a better more complete controller and display system.

Hello to you all..

[Finally the holidays are over :wink: and got my system running like a Cadillac! Must been a combination of wires I didn't come up with
Exept for one thing: If I stop pedaling the motor won't stop until I use my digital electric brake. Even so when I'm standig still and push my bike foreward without pedaling, it softly switches the motor on...until I brake again. Tried some changes in the configurator but nothing seemes to work....
What do I have to change in the code to overcome this?
Attached my config.h...

Greetz..


View attachment S06SConfig.h230718.txt

Mavabo said:

If I stop pedaling the motor won't stop until I use my digital electric brake. Even so when I'm standig still and push my bike foreward without pedaling, it softly switches the motor on...

Click to expand...

Nice to see that you've managed to install all things needed! 8)
Please try the older commit:
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/archive/cd4e9bc81e0f2611ff1b3cc216d6d49c49a40e4b.zip

I have to check it in THROTTLE_AND_PAS mode in the recent code.

geofft said:

That was quick...
Will give it a try tomorrow.

Click to expand...

I've added the feedback for activated offroad mode by showing high velocity for 3 seconds now. would be fine if you could check it.

-dg said:

I say this because I think the current multiple projects approach risks fragmenting what is already a very small user base.

Click to expand...

I agree totally, I'm looking forward to see your solutions!

regards
stancecoke

-dg said:

casainho said:

So, TSDZ2 and LCD3 are really different projects from BMSBattery_S_controllers_firmware. Which hardware/motor controller do you have and plan to develop for??

Click to expand...

I have Q100H, Q128H and Bafang SWXH, but I'm not opposed to trying other things.

I will say that it seems to me better to have submodules of the same project than different projects as surely there is lot of common code and setup. For example, the board initialization, reading the ADC, the UART handling, the PAS/throttle/torque sensor input, brake levers, under voltage monitoring, etc and probably a lot more are similar or identical between the original KT controller project and the TSDZ2. LCD3 applies to both. I'm thinking an organization more like SDCC where most of the compiler is the same but stm8 and 8051 have specific sub modules.

I say this because I think the current multiple projects approach risks fragmenting what is already a very small user base. The number of people who:

- want an electric bike
- want to make their own bike
- want to have open source firmware
- know enough/are brave enough to open the controller and solder onto it.

That's not that many users. Then for contributors they have also to be able to program and debug. Very few people are left. But, I am hopeful that there might be still be enough to make this a real project if we can collect them all in one place. If we divide them up along the lines of hubmotor/central motor/display/no display/extra hardware/no extra hardware/windows/linux then it seems we will have 3 or 5 or 7 one person projects that die off soon instead of one multi person project that can survive and make a better more complete controller and display system.

Click to expand...

I really like that idea of try using the submodules but I lack knowledge and experience to do that.
Also, I think the project like that will be big and harder to understand for developers, probably also hard to debug and a change for one project may break the other project -- that will be difficult because we are testing with real hardware and takes a lot of time for testing/validate new changes and every deveper will not have all the hardware to test.

For now, I think at least sharing knowledge between projects is already a big win. And even are different developers that will explore different paths and that can be good, if they share the results/knowledge.

There is one good thing: the flash memory is only 16kbytes so each project can't be big - more than enough for 1 only experienced developer to maintain. I feel the hard part is to have hardware and test on the hardware.

I wish you could help on the LCD / controller communication interface. TSDZ2 firmware is almost done, I would say it is at 80% and LCD3 firmware is very complete by now but lacks a good interface specific for sending configuration data. All the LCD menus are now implemented and well structured in the code so it is easy to expand.
Both TSDZ2 and LCD3 firmware take currently about 18kbytes flash memory while the limit is 32kbytes, so there is opportunity to improve much more, mainly on LCD side.

There is an installer for SDCC 3.7.1 for 64 bit Windows available. It's in a snapshot folder, so not a proven release ?!
https://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32-setup/

Compiling our project works, it even throws this warning no longer.


I'm not sure if I should refer to this installer in the tutorial, as it's much easier to install and doesn't need the cygwin files...

regards
stancecoke

stancecoke said:

geofft said:

That was quick...
Will give it a try tomorrow.

Click to expand...

I've added the feedback for activated offroad mode by showing high velocity for 3 seconds now. would be fine if you could check it.

Click to expand...

Just tried this but can't get offmode mode (cheat) to switch, no display indication or throttle enable.

I'm using the default 1sec timing, I could trigger this every time when it was added to casainho's branch (after you commented out the print commands...?), so I guess something's not quite right here..

You are right, there was a bug in the latest commit. now it works without display, Please check the display feedback again!

Thanks
stancecoke

Mavabo said:

Exept for one thing: If I stop pedaling the motor won't stop until I use my digital electric brake.

Click to expand...

I tried it with the most recent code in THROTTLE_and_PAS mode, it worked for me. I guess it's a problem of the auto-zero process for battery current at start up. Maybe your controller needs more time to get a constant ADC reading. Perhaps we should try a longer delay.

regards
stancecoke

....

stancecoke said:

You are right, there was a bug in the latest commit. now it works without display, Please check the display feedback again!

Thanks
stancecoke

Click to expand...

Strange, still can't get this to trigger, no display indication or throttle.
I'm in no rush for this fix, please take your time...

Can you please try again. The morse-phases are shorter than expected, I'm sure you will manage to activate the offroad mode! The throttle needs some tries before the motor starts the first time sometimes, I guess that's because of the phase current limitation...

regards
stancecoke

stancecoke said:

Can you please try again. The morse-phases are shorter than expected, I'm sure you will manage to activate the offroad mode! The throttle needs some tries before the motor starts the first time sometimes, I guess that's because of the phase current limitation...

regards
stancecoke

Click to expand...

Ok, but I did try many attempts with different timings (slow-medium-fast) without a single success.
Will try again tomorrow and get back to you.. :wink:

Thank you for your patience!
Here a video from the output in diagnostics mode. First time I failed, the second try is successful. In the fourth column is the "cheat state", in the fifth the time counter. So the sequence is pull - release - pull - release.
During state "4" (3seconds, the counter runs to 150) the display should show a high velocity. In state "5" the offroad mode is active.

[youtube]oYDeuu5XglU[/youtube]

I've updated the repo at github again, with a different timing for the auto zero process of battery current. I found no difference to the old solution, but perhaps it helps Mavabo with his problem.
Motor start is still not reliable from standstill with throttle, I have to improve the phase current limitation algorithm...

regards
stancecoke

casainho said:

I wish you could help on the LCD / controller communication interface. TSDZ2 firmware is almost done, I would say it is at 80% and LCD3 firmware is very complete by now but lacks a good interface specific for sending configuration data. All the LCD menus are now implemented and well structured in the code so it is easy to expand.
Both TSDZ2 and LCD3 firmware take currently about 18kbytes flash memory while the limit is 32kbytes, so there is opportunity to improve much more, mainly on LCD side.

Click to expand...

The concept here is to collect and move all the configuration and run time variables into a big structure and let it be managed entirely by Modbus. So all those magic constants like angle correction and limits and magnet numbers from config.h, and all the read outs from the ADC and the brake switches and PAS sensor and all the messages to the LCD would all be handled via Modbus.

Modbus is a master slave system, the master asks for values, the slave replies, The master commands new settings, the slave sets them. There can be one master, but many slaves. Inside a slave there are what they quaintly call "coils" and "registers". A coil is one bit corresponding to a switch or relay. A register is 16 bits, Some are inputs, ie data the slave collects from sensors fore example battery voltage, some are settings, ie commands or configuration value, for example low battery limit.

In operation when the controller comes up it is a Modbus slave. It initializes all the state with defaults and as it runs it updates the live values, ie adc readings. If there is another device, like an LCD display, or a PC serial, or a custom control unit (like I want for drop bars) then that is the Modbus master. It can read any information it wants via Modbus query. It can also set configuration via Modbus set commands.

As a Modbus master, the LCD or PC program would just loop using Modbus queries to ask for whatever information it wants and displaying it. Commands, eg LCD button presses, or settings updates from the PC are just Modbus set commands to the controller.

By putting all the configuration and all the data into theMmodbus accessible data area we can see any detail we like about the operation of the controller and make changes to any setting on the fly. For example, when bringing up a new motor there seem to be a few settings that have to be discovered by trial and error. With config under Modbus control, this could be done from a connected laptop or something while the motor is running and the resulting currents, rpm, and voltages, phase angles read back in real time. No need to edit files, recompile, or re-flash. We could even have a binary distribution and let people configure it to a new setup without having to build the firmware at all. Someone could even sell pre-flashed controllers should there be any interest in such a thing.

Since Modbus is very simple it would not take much code space. The configuration, (writable) Modbus registers could go in the EEPROM and the run time (read only) register would be in RAM. As I understand it, we are mostly short of flash, not RAM or EEPROM.

The other component is the Modbus Map. This is basically a text file or dictionary defining all the Modbus registers. The C language definition of how to access these in the controller, ie the replacement for config.h could be generated from the map file.

Here is a sample Modbus slave implementation for small systems. We could adapt this, or one of several similar projects: https://github.com/FxDev/PetitModbus. Take a look at the code just to get an idea of the size.

Here is a generic Modbus gui for Windows and Linux, pretty basic, but shows the idea: https://sourceforge.net/projects/qmodmaster/. I'm sure there are nicer ones available, but this should serve to test against.

And here is a giant PDF with the Modbus map documentation of a line of industrial standby power generation systems: https://www.ccontrols.com/support/dp/modbus2300.pdf Basically every configurable or observable about this equipment is in the Modbus map and so is by default remotely controllable and viewable. Just skip the first few pages to get an idea of the kinds of items it handles. Our system is much simpler but the same sort of meta-data driven approach will give us a well defined and extendable interface between the controller and displays other devices.

If we do this, I plan to make a fully fly by wire bike, all control going over two wires as Modbus messages from a MCU on the bars to the controller near the cranks. PAS/Torque and rear wheel speed would go to the controller. Throttle, display, brake levers, handlebar buttons would go to the handlebar MCU, just data tx+rx would connect the two. No wire rats nests, no wet shorted throttle connectors just one thin four conductor cable.

I have been trying to build the stancecoke flavor of the BMS Battery controller. I finally have it building, but if I enable debug symbols sddc still crashes. So there is still some sort of sdcc bug, but I can work around it. Stancecoke, how should I send you a patch for Makefile_linux to update it?

Anyway, once it built, I thought "how are we ever going to fit a new library for Modbus?" The answer turns out to be easy, with Modbus to send any data to the master there is no need for printf() even for debugging. Removing printf() saves over 2Kb:


I think the floats are the next area to prune. It think we could replace them with Q numbers (scaled binary ints) and save another 2Kb. See https://en.wikipedia.org/wiki/Q_(number_format). I'd even be up for writing stm8 assembler math routines for this even if we don't strictly need them, that kind of programming is fun fun fun although, truth be told I never get to write assembler any more.

Can anyone give me an idea of the range of values for the floats we have now? I see them starting out and being cast back to 16 bit ints mostly, but don't know what range and precision the intermediate calculation needs. Files to check:

update_setpoint.c
main.c
display.h
display.c

-dg said:

I have been trying to build the stancecoke flavor of the BMS Battery controller. I finally have it building, but if I enable debug symbols sddc still crashes. So there is still some sort of sdcc bug, but I can work around it. Stancecoke, how should I send you a patch for Makefile_linux to update it?

Anyway, once it built, I thought "how are we ever going to fit a new library for Modbus?" The answer turns out to be easy, with Modbus to send any data to the master there is no need for printf() even for debugging. Removing printf() saves over 2Kb:

Code:

stm8-size main.elf
   text    data     bss     dec     hex filename
  20353       0       0   20353    4f81 main.elf

as above, no printf
stm8-size main.elf
   text    data     bss     dec     hex filename
  18239       0       0   18239    473f main.elf

I think the floats are the next area to prune. It think we could replace them with Q numbers (scaled binary ints) and save another 2Kb. See https://en.wikipedia.org/wiki/Q_(number_format). I'd even be up for writing stm8 assembler math routines for this even if we don't strictly need them, that kind of programming is fun fun fun although, truth be told I never get to write assembler any more.

Can anyone give me an idea of the range of values for the floats we have now? I see them starting out and being cast back to 16 bit ints mostly, but don't know what range and precision the intermediate calculation needs. Files to check:

update_setpoint.c
main.c
display.h
display.c

Click to expand...

About modbus, thanks for the explanation. I did a quick look on the first github code but I am not sure I did understand everything. For what I can understand, the controller would need to send the full data/many bytes every time and I don't like it because we need processing time!! We even would like to run PWM at higher frequency and we need even more free processor time.

On TSDZ2, PWM interrupt runs the fast code for motor controller. On slow loop, I try to run at ever 4ms the FOC angle calculation and if UART sending of modbus is long, motor control will loose quality because of that delays...

I see that you can optimize the code for size but seems we are using about half of the size and firmwares and almost complete, so, no need for sizing optimizations. I think what we need is optimizations for speed, because of motor control needs speed!!

What do you think?

Looking at the thread about controller communication to implement special features here: https://endless-sphere.com/forums/viewtopic.php?f=2&t=94850#p1389267 and recalling several discussions on this thread about providing mode switches between restricted and unrestricted power or speed it seems that the Modbus proposal could help address this:

The speed and power limits would just be Modbus registers in the controller, enabling or disabling them could be done by setting/resetting a "coil" or by updating the registers. Since any Modbus master could do this there would be no need for any special handling in the controller at all. The master, LCD3, custom hardware or whatever could handle setting this. If the actual limits were set by a PC serial master then all the LCD would need is a button press to trigger the mode. The actual legal limits are different country to country, but that could be configured at installation time with no flashing or building needed.

Which would get the controller project out of the business of implementing secret handshakes for every different village

stancecoke said:

Can you please try again. The morse-phases are shorter than expected, I'm sure you will manage to activate the offroad mode! The throttle needs some tries before the motor starts the first time sometimes, I guess that's because of the phase current limitation...

regards
stancecoke

Click to expand...

Ok, glad to say I'm now managing to get offroad mode to trigger and the 'always on' throttle works really nicely...

I'm finding it difficult to hit the brake lever timing though. When the cheat mode was added to casainho's branch I could trigger it just about every time, but on this branch I'm only managing about 1 in 6. I think there was an adjustment for timing tolerance in casainho's branch - do we still have that?

Sounds like we have some exciting new ideas coming to the project..

Edit: Sorry, didn't see your last post about this - ignore my second paragraph for now.

geofft said:

Ok, glad to say I'm now managing to get offroad mode to trigger and the 'always on' throttle works really nicely...

I'm finding it difficult to hit the brake lever timing though. When the cheat mode was added to casainho's branch I could trigger it just about every time, but on this branch I'm only managing about 1 in 6. I think there was an adjustment for timing tolerance in casainho's branch - do we still have that?

Click to expand...

Nice to read that it workes for you finally. Did the display show the feedback also?
There are some differences in the "offroad" procedere. In my fork the procedure is reset, if you are too early with your action. I deleted this in casainhos fork (I didn't understand my own code at that moment ). So your input has to be more precise now. Another topic is the tolerance. The slow loop works a little faster than 50Hz, obviously. So the tolerance is less than half a second. We can set the tolerance to a slightly higher value, that makes it easier to hit the right timeframe.

-dg said:

Stancecoke, how should I send you a patch for Makefile_linux to update it?

Click to expand...

You can post it as a txt file here, or make your own fork and send a pull request at github.

regards
stancecoke

stancecoke said:

geofft said:

Ok, glad to say I'm now managing to get offroad mode to trigger and the 'always on' throttle works really nicely...

I'm finding it difficult to hit the brake lever timing though. When the cheat mode was added to casainho's branch I could trigger it just about every time, but on this branch I'm only managing about 1 in 6. I think there was an adjustment for timing tolerance in casainho's branch - do we still have that?

Click to expand...

Nice to read that it workes for you finally. Did the display show the feedback also?
There are some differences in the "offroad" procedere. In my fork the procedure is reset, if you are too early with your action. I deleted this in casainhos fork (I didn't understand my own code at that moment ). So your input has to be more precise now. Another topic is the tolerance. The slow loop works a little faster than 50Hz, obviously. So the tolerance is less than half a second. We can set the tolerance to a slightly higher value, that makes it easier to hit the right timeframe.

Click to expand...

Yes, the display does show the feedback..

Sorry, I hadn't seen your last post (yesterday evening) when I made the other comments, so they are probably not relevent. Will try the latest github download later.

stancecoke said:

-dg said:

Stancecoke, how should I send you a patch for Makefile_linux to update it?

Click to expand...

You can post it as a txt file here, or make your own fork and send a pull request at github.

Click to expand...

It seems a small change to make a fork for. I'm attaching the updated Makefile_linux, not a diff. Just replace the old one. It changes two things:

- update to add new files to build
- Turn off debug symbols to work around sdcc bug #2772 sdasstm8 seg faults on null pointer deref

I did not attempt to flash this or test it on hardware, just verified that it did produce a bin and ihex file. So it builds, no idea if it works. I'll look into some of the warnings when I get some time.