Latest firmware, FOC, Hallsensors, 1600kV motor, PID Speed Control
At very low speeds the motor does not rotate smoothly, it more looks like there are ripples. Realtime Data shows those nicely. I wonder if you can do something about that. In fact I don't understand the root cause of that. Thanks to the Hall Sensor the Vesc knows which phase to use and based on the target speed, it can apply the amps in a sinus form of the proper wave length.
At the looks of it, seems like the FOC does not take the desired speed into account but simply tries to rotate the motor and then the PIC controller dials it down. Is that possible? Would my suggestion make sense or am I completely off?
I was asking about something similar here : http://vesc-project.com/node/212
From what I understand now, the hall sensors don't have the resolution to allow the VESC to know when exactly to pulse which field (if that's the right terminology) at low speeds.
If you want really accurate (and powerful) low speed an additional sensor is recommended.
Good luck!
I am not sure you got the proper answer. Or I should better say, an answer covering all directions.
Shot version: Rotational Position control works with Hall sensors also, even sensorless. It lets the motor jump to an initial position and from then onwards the movement is very slick. What we essentially ask for is a transition from PID loop at higher speeds to positional control at extremely low speeds in a seamless manner. Because you know the posiiton of the motor at minERP quite well, three would not even be that initial jump. But we trade torque for smoothness at speeds around zero.
And my statement is, no idea if it is correct, that this can be simple to implement when using the Speed Control mode.
The better solution is to implement the brake logic suggested in another thread, to truly enter the positional logic. That might be quite complex and I would like to tune the positional PID values as well (if they come in place even, not sure).
Do you concur with the "maximum torque at speeds around zero is not needed"?
A problem with FOC is that the switching frequency is fixed, for example 30kHz.
With a low speed you have a very low duty cycle, minimum about 1%.
In BLDC mode I think the frequency will be automatically lowered to the minimum value you have defined.
So in FOC, you can try lowering the switching frequency and tell us if it's good for your application, otherwise try BLDC mode.
Have a Nice Day.
Thierry
Not getting your argument.
The switching frequency is an equivalent for the energy put into the motor, the amps so to say. Hence 100% would be equivalent of full energy without any pauses, the lowest amount of energy is one pulse of length 1/30000 seconds.
So lowering the switching frequency would make it less smooth (and increase noise).
Anyway, FOC is a given. High switching frequency is a given to have the least amount of noise.
But the lowest duty cycle is limited by the deadtime.
If the frequency is lower, than the duty cycle and power can be lower too.
Of course you are right about the noise and smoothness.
Have a Nice Day.
Thierry
That part of my statement is nonsense obviously. The amps when braking at 1g and holding the position are totally different. It has to be a default value, either fixed or slowly increased until the hall sensor does not switch.
The hall sensor does not have enough resolution to let the FOC algorithm know the exact position. However, it DOES provide precisely enough information to know which "field" to pulse.
When in FOC mode, when going slowly, both the high and low side mosfets are on for about 50% of the time.
A simple P-controller should be able to keep approximate position. Just make the current proportional to the number of steps that you're away from the desired position. So IF you're on a hill with the system wanting to go forward, you might end up say 5 hall-sensor-transitions from the desired position, but at that point the current has become enough to counter the force of gravity.
One of the expected problems is that tuning this is difficult. the stability/instability of the system probably depends on the weight (ehh inertia) on the system. So with the system parked/braked, stepping off could mean it gets unstable and takes off.... :-)
Somehow it seems I can't get my point across or I don't understand you point.
All I am asking for is a hybrid between normal and forced commutation at low speeds. You don't need a high res sensor/encoder for that. You don't need a Speed PID for that. At high speeds or varying loads, then the FOC vector does not control the RPMs, it is the energy that controls the RPMs and the vector has to match that. Since the target is a RPM value, you need a RPM PID loop. All fine.
All you are saying is that "high speed" is as low as 5 RPMs, but for that the Hall sensor resolution is not high enough, hence you need an encoder. Correct but not the point.
What I am saying is, since you know the target is 5 RPMs, the FOC vector should rotate at the exact same speed while it has no input from the Hall sensor. And as soon as the Hall sensor did switch, use that information to update the FOC vector.
What is happening instead is the vector has an arbitrary RPM and the Speed PID does accelerate/decelerate it to get the target RPMs and since the latter has no information about the current position at all for 120° the result is obviously an uneven movement.
A Positional PID is not required either, because the goal is not to achieve a perfect shaft angle. Nobody cares is it is off by 5° as long as it is turning with 5 RPMs.It would work of course but has downsides on its own.
@benjamin: Do you have any input? Any idea if something can be done about that and how?
Maybe I can look into the code myself but would like to get your thoughts first.
Problem is simple: The Speed PID needs lots of readings per seconds to work smooth, but with Hall sensor and at low speeds, it does not get those. Hence the motor runs uneven.
Suggestion: At low RPMs (<PID min eRPM) the target speed does bypass the PID loop and gets fed directly into the FOC vector speed.
Played with that some more. Went into the VESC Tool Terminal, did turn on the send-alive-packets and entered the command foc_openloop 5 10.
At no load on the motor I would have expected a very smooth motor movement but it does not. Is that an indicator there is something wrong?? Something not noticed in normal operation?
OK, joining the conversation because low speed smoothness is all I want from the VESC.
We have fitted 1000P/R pulse encoders to our direct drive hub motors (think 'hover' board wheel motors) Though they worked very smoothly at low speed when on the Chinese hover board controller with only Hall feed back so I have been wondering exactly what you have been discussing above.