Problem Controlling E-BIke

[PedroCastro]

Hi,

I have a e-bike project that I am using kv31f and kms as the motor controller. Since I need a torque control, I have to use the current control mode of kms. As far as I understood, the torque control must first go through a speed control and after a threshold the torque control takes place. The problem is that in e-bikes the pedal is mechanically coupled with the motor, so when the user pedals the motors also spins. In this situation it seems to me that if the motor is already spinning or even above the rpm threshold, the controller is unable to enter the current control. The faults the system gives is kind of random to me, for example: peak current on phase (A/B/C) which is strange cause I am trying to use current control. Motor overspeed in low rpm and even under voltage using a DC power supply.

So, my question is: How can I use a current control for an e-bike with a motor mechanically coupled with the pedal?

Thanks in advance

[philip_drake]

We have had other customers solve this startup issue with a Hall-startup.  After startup the Torque control can be used.

Once a motor start is requested with the throttle then the hall-start will read the current motor angle and engage the motor.  Once startup mode is exited, sensorless FOC is commanded. 

During commissioning you might want to try setting the FOC crossover speed to be higher than the pedal assisted motor speed.

Other than hall startup, we have not developed alternative on-the-fly startup algorithms.

The other way to accomplish this is through a mechanical clutch which would leave the motor not-engaged until the motor RPM exceeded the pedal. 

For your e-bike operation you may want to work on the re-generative braking possibilities as well.

Best Regards,

Philip

[linestream-adam]

Pedro / Philip,

I wanted to see how hard it would be to modify the startup when using hall start into torque control so that you are always in torque control.  It was far simpler than I expected.  On my bench it works great.  Lets you go into and out of hall mode based on the hall derived speed.  I've attached the updated drv.c file that enables this feature.  Give it a shot.  Hopefully this will help with some of the issues you are seeing.  

[PedroCastro]

Hi Adam, many thanks for the code! I will test as fast as possible!

Do I have to change the FOCLowSpeed, accel, jerk or anty paramters regarding startup to use this drv.c?

[linestream-adam]

The FOCLowSpeed will still be used but now it looks at the speed reported by the halls to determine if it should make the transition to FOC.  So if running above that speed it will run FOC, below that speed it will run TRAP.

You can ignore accel & jerk with the startup.

Let me know if this helps resolve the issue in the other thread as well.

[PedroCastro]

Adam,

there is still a bug with the FOCLowSpeed transition. If the motor is above the threshold when the controller comes in, it cannot start the RUN_CURRENT mode. Besides when the transition happens, it seems it gets lost sometimes also. Do you have a solution for this?

[linestream-adam]

Pedro,

That is where the need for a "flying start" algorithm comes from.  When it attempts to start above the FOCLowSpeed, it will try to start controlling the motor using FOC.  But since the estimator hasn't synchronized with the rotor prior to starting to control it can get "lost".  

The solution to this problem is to add a flying start algorithm that will allow the estimator to lock onto the rotor before trying to control it.  It is possible to modify the drv.c file in order to do this, but I don't have an example I am able to provide.

[PedroCastro]

Would it be possible for you to send an updated file today or maybe tomorrow? We have an important event for customers to test the products.

One thing I have tried is to set a really low FOCLowSpeed and the controller always starts above, which gives some torque but it does not reach rated speed. Would it be possible to solve this instead?

[linestream-adam]

Pedro,

I won't be able to provide an update that resolves this issue.  It requires adding an algorithm and capabilities that are not currently present in KMS. 

If anything, I would recommend setting a higher FOCLowSpeed, this way your odds of starting in the FOC region are lower.

[PedroCastro]

linestream-adamreynolds‌

will be an update to add the flying start algorithm? We are depending on NXP to have a good product we are about to sell hundreds and even thousands

[linestream-adam]

Also, it could be useful to modify the transition point between TRAP and FOC.  You can do this in the GUI by changing the "Speed Threshold" on the Speed Control page.  The associated MCU variable is est.config.FOCLowSpeed.  If you get the bike started in TRAP mode with the crossover speed high you can lower the crossover speed once the motor is spinning to try and transition into FOC.

[PedroCastro]

Hi Adam,

I am not been able to set a FOCLowSpeed during run time, I am using the function above:

void setFOCLowSpeed(float speed)
{
flashSysParams.estCfg.FOCLowSpeed = _LQ24(speed / FULL_SCALE_SPEED_RPM);
}

Should I call DRV_Init(&flashSysParams) after setting the new valeu for it?

[linestream-adam]

Pedro,

Instead of setting flashSysParams.estCfg.FOCLowSpeed, set your new value to est.config.FOCLowSpeed

That will update the live value.

[PedroCastro]

Adam,

so even in speed control mode, if the motor is already spinning when I command a target speed, the FOCLowSpeed should always be above the current speed, right?

[linestream-adam]

Pedro,

Yes, you will want to run for a little bit in the startup region so that the estimator has a chance to stabilize.  One thing you will need to be cautious of when running in speed mode is that for startup it will always start from 0.  You may need to adjust the trajectory start point to be the current speed of the motor.

[PedroCastro]

Thanks Adam,

one more thing, what is the variable to set th trajectory start point? Should I ran in SPEED_RUN or SPEED_RUN_PLAN?

[linestream-adam]

Pedro,

The trajectory start point can be set using trajvel.config.startSpeed but it will only work if you are not generating a trajectory.

I would use SPEED_RUN.

[PedroCastro]

Hi Adam,

just one doubt I would like to discuss... Could it be possible to use the hall sensors for a sensored control? Since I am using velocities below 1500rpm the hall readings are still precise, right?

[linestream-adam]

You can modify the drv.c file to do that.  You would need to change the feedback for the speed control to use the hall-derived speed in all conditions instead of only during startup.  Not that this will still use the sensorless in order to determine the electrical angle of the motor.

[PedroCastro]

I thought about using the "sensored velocity" created by the KMS, but it asks for an encoder lines parameter, which I think is used with an external encoder. Is it possible to use with the hall sensors?

[linestream-adam]

Sensored Velocity is only available using an encoder.  It will not work with hall sensors.

By modifying the drv.c file with Sensorless Velocity - Hall Start, you could do sensored velocity control with sensorless motor control.