LUA AUTO PID in-flight

I have an idea. Since my heli flight control cannot be adequately met with just one PID at higher airspeeds and different rotor speeds, I want to use a Lua script to help me change my heli PID settings in-flight based on airspeed and rotor speed switches.

I’ve seen in many places that it’s not recommended to change FC parameters in-flight through GCS. Would changing them through a Lua script cause FC instability? Just like AutoTune, but I might change the PID at a frequency of 5 or 10 Hz.

I think the recommendation to NOT make changes in flight is to avoid fat-finger mistakes and setting some unrealistic value that will cause a crash.
Scripted changes within some known/tested range should be fine.

1 Like

I have a question that has puzzled me for a long time. If I frequently change the parameters, will it quickly wear out the flash memory of the FC? I’m not very confident about testing this issue. Theoretically, changing the parameters will be directly saved in the flash, so frequent writing should cause a lifespan problem for the flash?

Typically the STM32 chips internal flash have a minimum lifetime of 10000 writes.
So if you change a parameter twice per day every day of the year, you have about 13 years of life for those bytes. People have aggressively tested Arduinos (essentially the same SOC and flash) to destruction and can get much more than 10000 writes before problems occur.
There’s some read-only parameters that are updated often, such as flight time and boot count.

I’m not totally sure about how Ramtron/FRAM devices are used in high end flight controllers (if at all??), but I suspect it’s in place of flash, and the advantages are increased write speed and practically unlimited writes and data retention - especially in our use case.

EDIT:
I’ll have to look up what is saved in EEPROM and what is saved in Flash - they have very different write lifetimes.

No. Consider that Flight Controllers w/o an Sd card write flight logs to flash and we don’t see those dropping out of the sky.

@Ben_bili asked for change rate of upto 10Hz if i understood correct. On a Flash with upto 100.000 write cycle on a single cell this are only 10.000 sec or 166 minutes or 2,77 hours.
@dkemxr writing logs is different as not each single cell is changed so often. A Param is allways on the same address or flash cell. So this is not directly comparable

Yes! I was just thinking about how to express my idea, and my thoughts are exactly as you said.
I am trying to use a script to directly edit the PID in flash memory, rather than in RAM. I don’t know if the script has the functionality to directly edit the PID that FC has already read into RAM while it is running. I took a quick look at the API, and it seems that it doesn’t have this functionality.
Maybe the best way to solve this is from the source code? Perhaps LUA scripts can’t do this for now?

@Ben_bili there is a Lua script that does quick tune for quadplanes. So there is definitely a way to change the gain parameters in flight using Lua scripting. Also gains can be changed without saving them to the eeprom. And I think that is what you would want to do you your case. You don’t want to permanently change the parameter values such that they are different the next time you power the flight controller. just change them while flying.

Also I am the helicopter code maintainer. I would be interested in your plans for changing PID gains with airspeed and rotor speed. Do you have physics based algorithms that you plan to do this? At some point, I think it would be a great benefit to have the code adjust PIDs with based on weight, rotor speed and potentially airspeed. Just haven’t gotten around to it yet.

1 Like

We have set vs set_and_save bindings for parameter manipulation in Lua. I haven’t specifically looked to verify, but given the behavior (with which I am very familiar), it’s reasonable to assume that the set binding results in a RAM-only change.

At any rate, focusing on flash writes is almost certainly the wrong hot topic here, especially if you’re intending to overwrite PID gains at anything measurable in Hz. One would wonder what you’re doing with a PID controller in the first place if the gains need to change at such a high rate.

Otherwise, I do think it’s a reasonable endeavor to examine the effects of various changes to airframe and provide custom, on-the-fly switchable tuning for expected scenarios.

Just curious, mavlink commands provides the option to set a parameter, which from what I understand, both writes it into permanent memory, but also to RAM so as to take immediate effect, is that correct? And LUA script provides more flexibility in this sense.

Thank you very much for the reminder! I will look at the examples later; I had forgotten about them.

Regarding the algorithm, I don’t have any good ideas at the moment. It might be possible to directly interpolate between the two PIDs using speed.

As speed increases, the efficiency of heli control decreases with increasing speed until one of the blades stalls. But to be honest, I think this feature might not be used by many people because we usually control the heli in Loiter mode or auto mode, and the flight controller will generally find a way to achieve the specified speed. I just thought of this; we might not need to spend too much effort on the attitude PID issue.

However, the RPM control PID will definitely be useful because the heli may use different RPMs depending on the mission. For example, it will increase RPM for high-speed flight or high maneuverability and decrease RPM for just hovering, thereby reducing power consumption.

I think direct interpolation might work. For example, set the highest and lowest RPM, and let the FC automatically switch to the corresponding PID.

I am sorry, it’s just an idea I haven’t tested yet. I spent too much time dealing with copter issues.

Considering the weight might be more complex. I think mot_exop might already serve a similar function? I’m not sure; we might need to focus more on the center of gravity issue. At the large cargo UAV (plane) development company I used to work for, they would input weight and center of gravity before takeoff, just like an airliner. However, for heli and copter, it’s more about hanging the payload for transport, so I think we might not need to spend too much time on this.

Actually, the main reason I want to only change the data in the RAM is because I’m concerned about the write-erase lifespan. The PID values are generally lower during heli takeoff and landing because there is no speed. Of course, resetting all parameters before the next flight is also what I hope for, just like setting MOT_HOVER_LEARN to 1; after a power-off, the FC always resets MOT_THST_HOVER.

Thank you for your answer! My main intention is to find a simple solution for the FC when the control model changes due to different speeds of the aircraft. I just thought of this; it might not be a problem that needs much attention. Of course, this issue might be more significant on high-speed planes, for example, divergence under different aoa.
It may not need such a high frequency of 5-10Hz to change. I just want to try it on a 450 heli first; maybe this is a more practical value? Anyway, I will try it when I have time.

I don’t really agree with this. Certainly once you get into retreating blade stall, then you will have controllability issues. From theory, pitch control sensitivity will get better with increases in speed and roll control sensitivity should not change much with speed. I think the tail may be sensitive to speed. These are things I will need to look into.

Yes I agree with this. I have done some research where I have shown that PIDs could be adjusted based on using coefficient of thrust. By maintaining the same coefficient of thrust after increasing the rotor speed with increase in aircraft weight, I showed that the aircraft response was nearly the same with the same PIDs. So some additional testing would need done to determine how the PIDs change with rotor speed while maintaining the same weight using the coefficient of thrust.

Never heard of the MOT_EXOP. I assume you mean MOT_EXPO? I would have to look at that. Not sure that it applies to heli’s. It is designed to correct the PWM request to the ESC to provide a linear change in thrust.

While a Lua script might prove useful for proof of concept testing, this kind of sounds like new control law territory. Might be worth a custom branch and firmware level changes.

Yes, the tail rotor of the heli is very important, and I think this is one of the reasons why Russia uses the Ka-29 as a shipborne aircraft. I think this might require adding two side pitot tubes? Theoretically, the tail rotor of the heli mainly suffers from the problem of lateral airspeed components, so adding pitot tubes facing the side along with some relatively simple interpolative PID might solve this problem? I’m not sure, I saw that the AH-64 has a gimbal pitot tube, but I think its structure might be a bit complicated.

The pitch problem I mentioned mainly stems from the retreating blade, because the stall problem on the retreating blade does not happen suddenly, but starts from the inner side of the blade and expands as the forward speed increases until it completely stalls. Then, due to gyroscopic effects, it ultimately acts on the pitch. But you reminded me, maybe this problem is mainly integral? Mainly because the speed of the heli can change quickly, I’m worried that a larger I might not react in time. I’m not sure, anyway, this nose-up moment exists, but I’m not sure of the specific situation.

Regarding MOT_EXPO, I’m very sorry I got the spelling wrong, and I thought you were talking about copters, which might not apply to helis, so please forget it. As for helis, I guess the PID and weight are not much related? Because the load is always under the rotor, the heli becomes more stable. If the PID is increased based on weight, suppose the heli is lifting cargo with a rope, when the heli releases the cargo, if the higher PID cannot recover quickly, it might cause some issues. I think there might not be a need to change the PID based on different weights, but this is just my thought because neither my copter nor heli have ever had attitude issues due to loads hanging directly below the CG.

Thank you for the reminder. I’ll first try the Lua script when I have some free time. If it doesn’t work, I’ll think of other ways.