mxlemming
100 kW
- Joined
- Jul 17, 2020
- Messages
- 1,172
Copied from my original post on the flipsky 75100 thread... reposted in it's own thread at the request of a few people. FLIPSKY new 20s 100A tiny controller (vesc based)
I shall update occasionally, maybe...
I am not saying this is definitive, just to give you an insight into the way I tune and fiddle with VESC. I have based this on... let's say extreme fanaticism with discovering all the niches and oddities of controller behaviour and studying the Math of FOC and control loops. I am the author of one of the VESC sensorless observers and one of the HFI methods, as well as having generated more mundane things like the interpolation algorithm (an alternative for V0 and V7 control loop running for low side shunt hardware and persuaded the addition of full clarke transform..).
I try to condense this to a practical level and info that can be useful to those that do not actively enjoy math and physics. Hope it helps.
One day, I intend to make a video on tuning motors. Here I will outline my methodology in limited detail... I think it is kind of important because much of the common internet folklore about it is garbage/dangerous.
DO NOT:
1) use slow abs max, EVER
2) blindly increase limits to make errors go away
These are two commonly cited suggestions. This is akin to ignoring problems.
When I set up a new motor/controller, I roughly follow this order:
1) plug in controller (preferably to current limiting PSU, 18V or the lowest it will turn on at and 0.2A), check FOC offets on current sensors are sensible (typically 2048+/-150 counts).
2) Set the general current to like 10A and 20A abs max
Set the voltage limits to be sensible... I tend to use 10-15% above battery max voltage but always at least 5V off the FET rating. Under voltage I just put at a level where going lower would result in the controller turning off (typically 20V)
Take care that the battery current and voltage cut off limits are sensible to avoid power rollback and wondering why you have no power. Or blowing your battery.
3) press the bandbrake button, measure the phase voltage with scope or multimeter - scope = 50% duty (might recently have changed to all low FETs on...) multimeter = vbus/2 (might now be 0V).
Now connect a motor.
4) repeat 3), watch out for overcurrents. At this stage, if you get overcurrents, you probably have bad hardware or shorts somewhere.
5) Set currents to like half what your motor/ESC should be capable of, abs max like 50A over.
6) FOC page... run detection RL and lambda, with PSU set to half your battery voltage and maybe 5-10A... Many people have not got a PSU and so this becomes a lithium battery and YOLO. Check the results are sensible!
Flux linkages for EVs are usually:
10-20mWb region for in-runners,
20-40mWb for hubs.
2-10mWb for smaller outrunners can be down in the region...
higher kV implies lower flux linkage, more PP implies lower flux linkage.
R and L... quite variable.
big inrunners are in the 2-10mohm, 20-100uH region
outrunners can belike 5-100mohm, inductance is hugely variable,
hubs maybe 10-300mohm and 20-300uH
It is usually best to decrease the time constant to 400us. I have not seen a case where higher time constants helped except with broken hardware, where it can mask really bad current sensor readings.
If you get values much outside this, check it is really correct. Without correct values, there is little point proceding.
7) Run hall/encoder detection - remember if doing encoder you need to manually enter the encoder counts and pole pairs in the General Sensors tab before doing the setup in FOC Encoder... It can be really tricky to guess what the real counts are given motor datasheets since there are counts, transitions, steps... many factors of 2 and 4 between the naming.
Remember to apply and write the values using the Mdown button on the right...
At this point, your motor should spin and if you are lucky you are done and just need to set up a throttle.
However, if you are pushing a motor to the limit, or running a highly salient motor you usually need to go further.
8) Engage MTPA if your Ldq difference is more than maybe 20% of the L value. Use IQ measured, always, otherwise you can get extreme amounts of unintended field weakening.
At about this point you should consider jacking it up to the currents you actually want to run.
9) Now we get to the painful world of observers. If you have an encoder... and it works... just set the erpm limit in the FOC encoder tab to be higher than your max erpm and it should just be better that way without effort.
If you have not... then you just need to try various things. Different motors respond better to different observers.
Generally, highly salient motors run best with ortega original and a very low gain whereas a lot of problematic motors which have rapid saturation and high pole count (like Tmotor U15) run much better with mxlemming observer.
My findings with running Ortega back to back with an encoder has been that the lower the gain, the better it tracks... right up until it becomes unstable and stops working atall. If you run a higher gain, you can easily push more more more amps... btu the tracking angle is bad and the power output drops off so you create much more heat for not much benefit.
The flux linkage observer uses the same gain factor as the main observer, which means you cannot tune them independently - this causes trouble, and has led to some dislike of the flux linkage observer.
If running Mxlemming observer, you can use the gain factor independently for the flux linkage... if using Ortega... cannot. Frequent comment from scooters has been that Mxlemming observer gets more torque, but Ortega more amps. I have verified this, BUT if you sit and mess with gain and inductance tuning, eventually you get the best result with Ortega original in many cases.
Other tips for getting higher current under sensorless:
Use the FOC Sensorless Saturation Compensation Mode... use factor. Higher current = more saturation. Maybe start with like 30%. Maybe reduce the L or Ldq by 30%, this often improves stability but sometimes at the expense of efficiency.
I have never seen cross coupling help in an EV application. Turn it off, it is for things like servo drives with huge inductance and rapidly changing setpoints, not throttle twisting and accellerating.
The key thing is to identify the real source of your problem. This is done using the "trigger sampled at fault" option, and inducing the fault while connected (USB, BLE, wifi...) to a proper computer. Nothing else is much use. NOTHING.
This is a very nice looking trace, 500A, 60% duty cycle, 20s battery... But it was on low side shunts. Therefore, you start to get current sensing anomolies at high duty and current (dinks at the bottom of the sin). Perfectly useable though.
Same thing but 80% duty. This starts to be a problem, there is not much you can do about this, it is a hardware limitation this device still pushed like 20kW though so meh)
This is an example of unstable observer. The tracking goes off and therefore the currents go haywire. Need to fiddle the gain/inductance/saturation comp.
Here is an example of a small motor running field weakening on an ESC with 600A current meaurement range. It looks rough, but it is fine. The blue line is inverting because it cannot decide if it is breaking or accellerating - free spin. There is some evidence of low side shunt abbheration but it is minor.
The dinks in this are due to dead time abherration (ignore the first 0.02s, that is where it locks the rotor into synch). Not much you can do about it. Hardware limitation imposed by the maker. This is running on a phase current sensor board I had with very nice sensing but needed power stage tuning.
This looks horrid because of noise but is actually nice. Board was 1800A sensors, running 20A. Be aware of the noise floor.
Annoyingly, I cannot find an example of the typical unstable observer behaviour. That looks like a pulsating sin wave, with fault triggering when the pulsation goes above the abs max. If I find an example, or next time I experience it... I will post.
Edit: @thezenox sent me an example, thanks!
The reason this happens is that the observer struggles to accurately track the angle, and so the pwm output voltage phase angle changes faster than the PI current control loops can keep up. The motor will oscillate between leading and lagging power factors, and eventually even oscillate between motoring and regen. Observer gain and inductance (L and Lqd) are the tools to tune against this. Sometimes with very salient motors (or very saturated ones), it is hard to eliminate this. This is where Ortega observer can help; when applying the correction factor, the ortega observer applies it at an angle that results in a power factor reduction which is stable, but less efficient.
You can see in the above plot that the motor is motoring then regenerating in oscillation from the blue line (total current) going + then -.
Field weakening:
the only setting I ever use on VESC is 200ms, 80-85% start duty. Ramp up the amps to taste... bear in mind infinite speed is when L*id = lambda. Field weakening on VESC is somewhat crudely implemented but works for most cases. Where it is lacking is limited to applications where there are very rapidly changing setpoints at high speed, such as with a balance wheel pushed to the limit (EUC, VESC'd single wheel sk8board etc). In these cases, users have found that setting the FW to start at lower duty can be advantageous, since it suppresses the duty cycle (hit max duty = fall off on balancing machine). In an ideal world, the field weakening controller would apply field weakening very quickly with a feedforward term to avoid ever reaching this duty saturation while still allowing running at max duty, but this is actually surprisingly hard to implement mathematically and stably and would require extra loop tuning.
Offsets:
This is one of the most common issues causing poor performance, especially at low power. If there's any error during startup you might find the controller doesn't measure the current sensor offset correctly. This can result in buzzing for small error and clunking for larger errors. It will inject noise into the control loops.
Some hardware drifts after startup, usually not by much. This is especially true on hall sensor based current sensors. Using the full Clark transform (FOC advanced all sensors combined mode) helps this a lot. This mode can be worse on low side shunts.
I shall update occasionally, maybe...
I am not saying this is definitive, just to give you an insight into the way I tune and fiddle with VESC. I have based this on... let's say extreme fanaticism with discovering all the niches and oddities of controller behaviour and studying the Math of FOC and control loops. I am the author of one of the VESC sensorless observers and one of the HFI methods, as well as having generated more mundane things like the interpolation algorithm (an alternative for V0 and V7 control loop running for low side shunt hardware and persuaded the addition of full clarke transform..).
I try to condense this to a practical level and info that can be useful to those that do not actively enjoy math and physics. Hope it helps.
One day, I intend to make a video on tuning motors. Here I will outline my methodology in limited detail... I think it is kind of important because much of the common internet folklore about it is garbage/dangerous.
DO NOT:
1) use slow abs max, EVER
2) blindly increase limits to make errors go away
These are two commonly cited suggestions. This is akin to ignoring problems.
When I set up a new motor/controller, I roughly follow this order:
1) plug in controller (preferably to current limiting PSU, 18V or the lowest it will turn on at and 0.2A), check FOC offets on current sensors are sensible (typically 2048+/-150 counts).
2) Set the general current to like 10A and 20A abs max
Set the voltage limits to be sensible... I tend to use 10-15% above battery max voltage but always at least 5V off the FET rating. Under voltage I just put at a level where going lower would result in the controller turning off (typically 20V)
Take care that the battery current and voltage cut off limits are sensible to avoid power rollback and wondering why you have no power. Or blowing your battery.
3) press the bandbrake button, measure the phase voltage with scope or multimeter - scope = 50% duty (might recently have changed to all low FETs on...) multimeter = vbus/2 (might now be 0V).
Now connect a motor.
4) repeat 3), watch out for overcurrents. At this stage, if you get overcurrents, you probably have bad hardware or shorts somewhere.
5) Set currents to like half what your motor/ESC should be capable of, abs max like 50A over.
6) FOC page... run detection RL and lambda, with PSU set to half your battery voltage and maybe 5-10A... Many people have not got a PSU and so this becomes a lithium battery and YOLO. Check the results are sensible!
Flux linkages for EVs are usually:
10-20mWb region for in-runners,
20-40mWb for hubs.
2-10mWb for smaller outrunners can be down in the region...
higher kV implies lower flux linkage, more PP implies lower flux linkage.
R and L... quite variable.
big inrunners are in the 2-10mohm, 20-100uH region
outrunners can belike 5-100mohm, inductance is hugely variable,
hubs maybe 10-300mohm and 20-300uH
It is usually best to decrease the time constant to 400us. I have not seen a case where higher time constants helped except with broken hardware, where it can mask really bad current sensor readings.
If you get values much outside this, check it is really correct. Without correct values, there is little point proceding.
7) Run hall/encoder detection - remember if doing encoder you need to manually enter the encoder counts and pole pairs in the General Sensors tab before doing the setup in FOC Encoder... It can be really tricky to guess what the real counts are given motor datasheets since there are counts, transitions, steps... many factors of 2 and 4 between the naming.
Remember to apply and write the values using the Mdown button on the right...
At this point, your motor should spin and if you are lucky you are done and just need to set up a throttle.
However, if you are pushing a motor to the limit, or running a highly salient motor you usually need to go further.
8) Engage MTPA if your Ldq difference is more than maybe 20% of the L value. Use IQ measured, always, otherwise you can get extreme amounts of unintended field weakening.
At about this point you should consider jacking it up to the currents you actually want to run.
9) Now we get to the painful world of observers. If you have an encoder... and it works... just set the erpm limit in the FOC encoder tab to be higher than your max erpm and it should just be better that way without effort.
If you have not... then you just need to try various things. Different motors respond better to different observers.
Generally, highly salient motors run best with ortega original and a very low gain whereas a lot of problematic motors which have rapid saturation and high pole count (like Tmotor U15) run much better with mxlemming observer.
My findings with running Ortega back to back with an encoder has been that the lower the gain, the better it tracks... right up until it becomes unstable and stops working atall. If you run a higher gain, you can easily push more more more amps... btu the tracking angle is bad and the power output drops off so you create much more heat for not much benefit.
The flux linkage observer uses the same gain factor as the main observer, which means you cannot tune them independently - this causes trouble, and has led to some dislike of the flux linkage observer.
If running Mxlemming observer, you can use the gain factor independently for the flux linkage... if using Ortega... cannot. Frequent comment from scooters has been that Mxlemming observer gets more torque, but Ortega more amps. I have verified this, BUT if you sit and mess with gain and inductance tuning, eventually you get the best result with Ortega original in many cases.
Other tips for getting higher current under sensorless:
Use the FOC Sensorless Saturation Compensation Mode... use factor. Higher current = more saturation. Maybe start with like 30%. Maybe reduce the L or Ldq by 30%, this often improves stability but sometimes at the expense of efficiency.
I have never seen cross coupling help in an EV application. Turn it off, it is for things like servo drives with huge inductance and rapidly changing setpoints, not throttle twisting and accellerating.
The key thing is to identify the real source of your problem. This is done using the "trigger sampled at fault" option, and inducing the fault while connected (USB, BLE, wifi...) to a proper computer. Nothing else is much use. NOTHING.
This is a very nice looking trace, 500A, 60% duty cycle, 20s battery... But it was on low side shunts. Therefore, you start to get current sensing anomolies at high duty and current (dinks at the bottom of the sin). Perfectly useable though.
Same thing but 80% duty. This starts to be a problem, there is not much you can do about this, it is a hardware limitation this device still pushed like 20kW though so meh)
This is an example of unstable observer. The tracking goes off and therefore the currents go haywire. Need to fiddle the gain/inductance/saturation comp.
Here is an example of a small motor running field weakening on an ESC with 600A current meaurement range. It looks rough, but it is fine. The blue line is inverting because it cannot decide if it is breaking or accellerating - free spin. There is some evidence of low side shunt abbheration but it is minor.
The dinks in this are due to dead time abherration (ignore the first 0.02s, that is where it locks the rotor into synch). Not much you can do about it. Hardware limitation imposed by the maker. This is running on a phase current sensor board I had with very nice sensing but needed power stage tuning.
This looks horrid because of noise but is actually nice. Board was 1800A sensors, running 20A. Be aware of the noise floor.
Annoyingly, I cannot find an example of the typical unstable observer behaviour. That looks like a pulsating sin wave, with fault triggering when the pulsation goes above the abs max. If I find an example, or next time I experience it... I will post.
Edit: @thezenox sent me an example, thanks!
The reason this happens is that the observer struggles to accurately track the angle, and so the pwm output voltage phase angle changes faster than the PI current control loops can keep up. The motor will oscillate between leading and lagging power factors, and eventually even oscillate between motoring and regen. Observer gain and inductance (L and Lqd) are the tools to tune against this. Sometimes with very salient motors (or very saturated ones), it is hard to eliminate this. This is where Ortega observer can help; when applying the correction factor, the ortega observer applies it at an angle that results in a power factor reduction which is stable, but less efficient.
You can see in the above plot that the motor is motoring then regenerating in oscillation from the blue line (total current) going + then -.
Field weakening:
the only setting I ever use on VESC is 200ms, 80-85% start duty. Ramp up the amps to taste... bear in mind infinite speed is when L*id = lambda. Field weakening on VESC is somewhat crudely implemented but works for most cases. Where it is lacking is limited to applications where there are very rapidly changing setpoints at high speed, such as with a balance wheel pushed to the limit (EUC, VESC'd single wheel sk8board etc). In these cases, users have found that setting the FW to start at lower duty can be advantageous, since it suppresses the duty cycle (hit max duty = fall off on balancing machine). In an ideal world, the field weakening controller would apply field weakening very quickly with a feedforward term to avoid ever reaching this duty saturation while still allowing running at max duty, but this is actually surprisingly hard to implement mathematically and stably and would require extra loop tuning.
Offsets:
This is one of the most common issues causing poor performance, especially at low power. If there's any error during startup you might find the controller doesn't measure the current sensor offset correctly. This can result in buzzing for small error and clunking for larger errors. It will inject noise into the control loops.
Some hardware drifts after startup, usually not by much. This is especially true on hall sensor based current sensors. Using the full Clark transform (FOC advanced all sensors combined mode) helps this a lot. This mode can be worse on low side shunts.
Last edited:
