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

The BionX runs good and quiet at low rpms if I activate the 360° interpolation and switching to 360° at 30 erps. But when I try to run the motor faster, there are faults, perhaps I'll take a video next week.

regards
stancecoke
 
stancecoke said:
The BionX runs good and quiet at low rpms if I activate the 360° interpolation and switching to 360° at 30 erps. But when I try to run the motor faster, there are faults, perhaps I'll take a video next week.
Good to know it runs well at low speeds. Try to use only 60º interpolation for a start. Do the real time log of ui8_angle_correction and see if it decreases/increases to much in the same direction...
I would say the issue can be with the FOC, that may be looking at wrong place for the phase B current signal zero cross.
Take as reference this real time log: https://opensourceebikefirmware.bitbucket.io/Various--Endless-sphere.com_forum_messages--2017.10.23_-_FOC_and_no_FOC_comparison.html
 
I added watchdog time protection and it needs to be reset every PWM cycle.

Some notes:
- // PLEASE NOTE: while debuging using STLinkV2, watchdog seems to be disable and to test, you will need to run without the debugger
- // there is always a PWM cycle (BUG !??) that takes about 220us (case 3 on the TIM1_UPD_OVF_TRG_BRK_IRQHandler ()) and so watchdog is configure for 375us while I wanted to be for 125us
- // from the init of watchdog up to first reset on PWM cycle interrupt, it can take up to 250ms and so we need to init here inside the PWM cycle:
 
casainho said:
- // there is always a PWM cycle (BUG !??) that takes about 220us (case 3 on the TIM1_UPD_OVF_TRG_BRK_IRQHandler ()) and so watchdog is configure for 375us while I wanted to be for 125us
Got that!! -- a division that was taking 111us!! Maybe the compiler was doing a 32 bits division...
Code:
	// this division takes 4.4us and without the cast (uint16_t) PWM_CYCLES_SECOND, would take 111us!! Verified on 2017.11.20
	ui16_motor_speed_erps = ((uint16_t) PWM_CYCLES_SECOND) / ui16_PWM_cycles_counter_total;
And now the watchdog timer is configure for 187.5us, the lowest value I could get it working.
 
Today I finally installed the torque sensor on my ebike. And then I tested and documented on the project page, like this:
98-4.png


https://opensourceebikefirmware.bitbucket.io/Torque_sensors--BMSBattery_torque_sensor.html

I also found that the CRC for received packet for LCD3 is different from the LCD5, but I got both working now.

Also I corrected the current value that is sent to LCD, and it shows about 0.7 times the value we send so I guess it expects the phase B sinosoidal peak value but I am just sending motor current and multiply by a constant.

And finally I went to make a test ride -- and I liked a lot!! I don't want anymore throttle or PAS.

The signal from this torque sensor seems that is already filtered, low pass. I just used the same code as for throttle but used level assist value to amplify the output value of torque sensor.

[youtube]Gz-j7yiEHKM[/youtube]
 
Fine, that you like the torquesensor mode :). I think you have to test it to see, that that's much better than the torque-simulation mode.
But as i interprete you post, you have not used the cadence information for the calculation of the motor power, yet?! That's just half of the truth, then. :wink:

regards
stancecoke
 
Yes, it was quick today, no time for more.

But my feeling is that the torque signal already includes/fusion the cadence and force...

I am being thinking why the cadence signal...

Maybe:
- map cadence to motor speed
- map torque to motor current torque
This way, on a downhill, we can keep the ebike speed by pedaling even if we do low torque, the motor will not stop but consume lower energy. With a direct drive motor, we could brake/regen when reducing cadence/ebike speed. I don't know if all this makes sense.
 
casainho said:
I am being thinking why the cadence signal...

That's just physics:
mechanical power= torque * rpm
7ed5841025dacf1e1cb61982f802915e40d73360


See
https://en.wikipedia.org/wiki/Power_(physics)#Mechanical_power

So I want P electric = U*I = factor* P human= factor * torque * cadence

regards
stancecoke
 
See the minimal voltage when no force:
98-5.png


And now, even if I quickly stop pedaling doing no force, the signal don't go to minimal voltage...
98-6.png


What I mean is that seems the output signal filters and delay, accounting for previous cadence -- makes sense?

You did refer before that you did implement the an average filter and I think the torque sensor already implements that internally. Or am I misunderstanding?
 
And I would like to clarify that the measures were done connecting the oscilloscope probes directly to the torque sensor wires. And the signal will be connected to the throttle input of S controller that add a low pass filter before the signal gets to the microcontroller and so the signal will be even flatter, with more delay, more filtered.



As we can see, there are 6 yellow signal transitions between each minimum because the "PAS" have 12 magnets.:
98-4.png
 
casainho said:
See the minimal voltage when no force...
And now, even if I quickly stop pedaling doing no force, the signal don't go to minimal voltage...
Or am I misunderstanding?

OK, that may be the same problem that I faced. I had to mount a stronger spring, to bring back the lever to it's home position reliably.
https://www.pedelecforum.de/forum/i...ensor-von-bmsbattery.31463/page-2#post-523198
plot with lever is not jamming:
index.php


plot with lever is jamming:
index.php


I don't remember exactly, but I think there's a RC-filter on the circuit board for the torque-signal, but there's no processing of the signal with the cadence, definitly.

The small µC on the board just processes the quadrature signal of the two hallsensors of PAS detection and generates the pulses when pedaling forewards and constant high level, if pedaling backwards.

Perhaps you can post a photo of the circuit board, to see if there are any changes in board design and perharps signal processing, as my photos are several years old, now.

Do you have a derrailure gear system or an internal hub gear in your bike?

Regards
stancecoke
 
stancecoke said:
OK, that may be the same problem that I faced. I had to mount a stronger spring, to bring back the lever to it's home position reliably.
Ok, I will wait to see If I get that issue.


stancecoke said:
I don't remember exactly, but I think there's a RC-filter on the circuit board for the torque-signal, but there's no processing of the signal with the cadence, definitly.
What you said before:
stancecoke said:
I take an ADC value of the torque at every PAS interrupt and save it in an array that has the same length as the number PAS interrupts (=magnets in the PAS disc) per crank revolution. For the calculation of the current target I sum up all array elements. So it's a mean value of the torque per crank revolution.
So I think they are doing the same mean value of torque, in hardware with that RC-filter on the circuit board (but maybe for more than one crank revolution...). Then we also have the another RC-filter on the S controller board... so I think we can skip the implementation of the mean value you did. Do you agree?

But let me see If I did understand:
Code:
uint32_current_target=((i16_assistlevel[ui8_assistlevel_global-1]*fummelfaktor*sumtorque))/(((uint32_t)PAS)<<6)-current_cal_b;
There you use the sumtorque that is the filtered value a divide for PAS (cadence), to follow the mechanical power= torque * rpm??


stancecoke said:
Perhaps you can post a photo of the circuit board, to see if there are any changes in board design and perharps signal processing, as my photos are several years old, now.

Do you have a derrailure gear system or an internal hub gear in your bike?
The 2 torque sensors I have are now installed on EBikes. Maybe when I buy the next unit or if I will need to open them for some reason, I will take pictures.

Only derrailure gear system but I live near the ocean on flat lands and so I always use a fixed gear on EBike, I mean, the same gear.
 
casainho said:
Ok, I will wait to see If I get that issue.
You wrote, that you already have that issue???
And now, even if I quickly stop pedaling doing no force, the signal don't go to minimal voltage...

casainho said:
So I think they are doing the same mean value of torque, in hardware with that RC-filter on the circuit board (but maybe for more than one crank revolution...). Then we also have the another RC-filter on the S controller board... so I think we can skip the implementation of the mean value you did. Do you agree?
The RC-filter filters much higher frequencies, only. If you look at the plots, you see every single force on the pedal, two peaks (right leg and left leg) per crank revolution. The hint that there has to be a filter is only that the torque signal does not return to the zero value completely between two pedal-treadles.
If you use a mean value or the difference of max and min value for calculating the current-target makes no difference I think. With averagaring you get less scatter of course.

casainho said:
There you use the sumtorque that is the filtered value a divide for PAS (cadence), to follow the mechanical power= torque * rpm??
You are right! :) Remember that the PAS value in the code represents a time value and is reciprocal to the cadence.

Regards
stancecoke
 
stancecoke said:
casainho said:
Ok, I will wait to see If I get that issue.
You wrote, that you already have that issue???
And now, even if I quickly stop pedaling doing no force, the signal don't go to minimal voltage...
And now, even if I quickly stop pedaling doing no force, the signal don't go to minimal voltage...
98-6.png
The issues of being communicating by writing messages and on a different language :)
I don't think I have the issue you had. I wanted to say that looking at that image, when I did very quickly stop to pedal, the signal never went to min value, probably because the capacitor got charged -- just to point out the effect of RC filter.

stancecoke said:
If you use a mean value or the difference of max and min value for calculating the current-target makes no difference I think. With averagaring you get less scatter of course.
I will skip that filter, because even if the throttle/torque sensor signals scatter, there are after other delays like the PWM duty_cycle ramps that I think act as another low pass filters on the system. But I will need more tests to understand the final result :)

stancecoke said:
casainho said:
There you use the sumtorque that is the filtered value a divide for PAS (cadence), to follow the mechanical power= torque * rpm??
You are right! :) Remember that the PAS value in the code represents a time value and is reciprocal to the cadence.
My intuition says that the torque signal is already the mechanical power and so no need to calc mechanical power= torque * rpm.
Not that I am experienced but, on a climb when cyclists reduces gears and increase the cadence, they also reduce the instantaneous torque done on each stroke. So they reduce the instantaneous torque of each stroke but they increase the number of strokes, meaning the average value of the torque may keep constant (sure, depends if they want to keep the same torque or increase. I don't know why do this balance but maybe to have less torque ripple, as on a climb the wheel speed will be reduced and so the cadence also, which would result in less strokes but stronger, so more ripple).

So, back to mechanical power= torque * rpm, I think the torque sensor with the RC-filter, do filter the higher cadence and does the torque * rpm. It like if on an electric signal, let's say on our motor control we increase the PWM frequency (the cadence) but maintain the same energy 50% duty_cycle, an RC filter will filter and the increased frequency should not change the output signal.
What do you think?
 
casainho said:
The issues of being communicating by writing messages and on a different language :)
I don't think I have the issue you had. I wanted to say that looking at that image, when I did very quickly stop to pedal, the signal never went to min value, probably because the capacitor got charged -- just to point out the effect of RC filter.
OK, then we meant the same thing with different words :)

casainho said:
My intuition says that the torque signal is already the mechanical power
So your intuition has never read a physics book :)

casainho said:
What do you think?
Just try both path and then decide, what's your favourite way....

Regards
stancecoke
 
Fixed gear control mode
I live near the ocean with flat lands. I don't like to change gears on my EBike and since I have the help of the motor, I (almost) always run with the same gear -- this makes me remember the way my Smart electric car works, it does not have gears and so I don't need to change gears, it is much more simple and zen to drive.

Assuming I use the same gear, I am thinking in implement the fixed gear control mode:
- CADENCE: The cadence will setup in real time, the wheel target speed. User define the max pedal cadence on the firmware, like 90. The max speed is also defined by the user on the LCD.
- TORQUE: the torque signal will define the real time motor target current. The torque signal will be amplified by the LCD 5 levels of assist level. The max current is the value for the controller max current and can be reduced using the LCD C5 Controller Maximum Current Adjustment.

The algorithm will use the max value from either the CADENCE or TORQUE. So if cadence defines constant speed, the user can increase the torque that will increase the motor current/assistance, that will after increase the cadence and increase the wheel speed as also the target value for the speed controller.
If user want to reduce the speed, will reduce the applied torque that will reduce the wheel speed and mechanically force to reduce the cadence and so will decrease the target value for the speed controller.

Let's see if I can make this working on the firmware and if the result is interesting. It is easy to be missing a few things but I will just find while implementing and testing.

This algorithm is the same as my electric car, that I can almost drive with only one pedal. I control the speed of the car with that pedal, the car have no gears and the electric motor is able to accelerate the car as also decelerate/brake it and so is possible to drive the car with only one pedal. With EBikes, I hope we can get the same, using a fixed gear and a direct drive motor and accelerating and decelerating/braking the bike only with the pedals.
The same on electric unicycles, where the motor accelerates and also brakes and we use only one input, the accelerometer.
 
stancecoke said:
So your intuition has never read a physics book :)
Need to think more about it...
 
casainho said:
Assuming I use the same gear, I am thinking in implement the fixed gear control mode:
- CADENCE: The cadence will setup in real time, the wheel target speed. User define the max pedal cadence on the firmware, like 90. The max speed is also defined by the user on the LCD.
- TORQUE: the torque signal will define the real time motor target current. The torque signal will be amplified by the LCD 5 levels of assist level. The max current is the value for the controller max current and can be reduced using the LCD C5 Controller Maximum Current Adjustment.
Why that complicated??? Keep it simple!
Of course, you can try what ever you want, but I can't see an advantage in you plan.

casainho said:
This algorithm is the same as my electric car, that I can almost drive with only one pedal.
I want to ride my (e-) bicycle with the most bicycle-like feeling that is possible... If I want to let the motor do all the work to move my 80kg, I'll use my motorcycle or my car... But again, this is my personal preference :wink:

regards
stancecoke
 
stancecoke said:
I want to ride my (e-) bicycle with the most bicycle-like feeling that is possible... If I want to let the motor do all the work to move my 80kg, I'll use my motorcycle or my car... But again, this is my personal preference :wink:
Yes. And I would like to explore other possibilities. I can't forget my experience with fixed bikes with the mainly difference on the way we brake because they have no mechanical brakes. Also the electric unicycles, with no the mechanical brakes, where the motor can (almost) full stop the device.

I would like to explore the ebrake and I see it near the fixed bikes. Doing like what emotorcycles does with throttle, but doing on ebikes using the torque sensor:
a Vectrix-style twist-grip control. Namely, go forward by twisting backward with your right hand, release the grip and it rotates to neutral, and apply regen braking by twisting forward.
 
Hmmm, but this won't work with the BMSBattery-Sensor. This sensor can't detect "negative" torque, as you can't push a chain.... :shock: :?

regards
stancecoke
 
stancecoke said:
Hmmm, but this won't work with the BMSBattery-Sensor. This sensor can't detect "negative" torque, as you can't push a chain.... :shock: :?
Yes, can't with BMSBattery torque sensor. So the idea is to map cadence (when using a fixed gear) to motor speed, and when we reduce cadence, for motor speed to reduce it will need to brake -- yes, would be great if could be with negative torque. And there are that bikes that have a coast brakes, that we need to do that "negative torque" to brake the bicycle.

Do you know a torque sensor that can detect "negative torque"? do you think would be possible to hack BMSBattery torque sensor to get "negative torque"?
 
casainho said:
Do you know a torque sensor that can detect "negative torque"? do you think would be possible to hack BMSBattery torque sensor to get "negative torque"?
The 2nd generation of the sempu-sensor should do it, but I never tried it. And I've just selled my Sempu, as a want to test our firmware on my "tinker-bike" now.
https://www.pedelecforum.de/forum/i...aus-sempu-sensor-und-lishui-controller.50186/
The BMSBattery-Sensor can't measure negative torques due to it's working principle. There has to be a force acting towards the front of the bike to get a negative signal. With a chain, you can't produce a force in that direction...

regards
stancecoke
 
Again I burned my controller with trying to get the BionX run. Even with the lab power supply set to 3A max :-(...
Perhaps it was uncontrolled regen.
Yet I don't know if there are just some Mosfets burned, or if it's another fault.

edit: the controller is OK, it's the J-LCD display, that causes the short circuit :(

regards
stancecoke
 
Back
Top