[jdl]

High speed dives in Rate mode (100+ km/h) occasionally cause violent pitch/roll oscillations with my Wing Z-84. The same happens with MiniTalon at speeds 180+ km/h. Till now I've tried to reduce PIDs in StabilizationBank, fly slower of simply switch to Manual when necessary.

However, there is maybe a solution I was unaware of.

I was under impression that scaling PIDs (for a fixed wing) in relation to airspeed is not implemented / functional in LibrePilot. At least there was a topic more than an year ago relating this:

https://forum.librepilot.org/index.php?topic=2989.0

and f5soh noted there that "...Currently airspeed sensor cannot be used to reduce PID". He maybe said then that outer loop PIDs cannot be reduced, because the topic was about high speed oscillations in Attitude mode. But I personally got impression that no PID scaling , according airspeed, is possible at all.

Recently, while browsing through the flight code, I've noticed in the innerloop.c an implementation of PID scaling relative to CalibratedAirspeed. The code seems to be complete and fully functional. I also did a bench test and it proved that ActuatorDesired (and servos deflections) in Rate mode act accordingly and reflect the changes in the airspeed (me, blowing into the Pitot tube  ) while supplying constant RC sticks input.

The prerequisites to enable this Airspeed PID Scaling implementation are:
1. In the UAVO browser: set the System | StabilizationSettings | ScaleToAirspeed to a value that corresponds to the usual cruise speed of the plane, at which the current PID tuning is performed. For my Wing Z-84 this is near 13m/s, for the MiniTalon - 16.67m/s likely.

2. In the Configuration / Stabilization / Settings Bank X / Advanced: Enable TPS, then set all points in the curve to 0.0, if you do not want Thrust PID scaling relative to Thrust. The value in the Axis field has no influence on Airspeed PID scaling. It always scales actuators output for all three axis - pitch, roll and yaw.

I'll try to make a "real world" flight test this weekend with Z-84 and Airspeed PID Scaling endbled for Rate mode.

For safety, I plan to leave all other flight modes, incl. Attitude, RTB, PH, PP on the well tested, current  StabilizationBank settings with TPS disabled (I use to launch in Attitude) and just set Rate mode on a separate (copied from the original one) StablilizationBank with TPS Enabled, for tests during flight on higher altitude when I have time to react to any erratic behaviour. - useless, Airspeed PID Scaling is not related to TPS Enabled, my mistake!

I'd appreciate any comments from developers that are familiar with this feature, especially warnings, if any

[TheOtherCliff]

Just some thoughts.  I play with FixedWingPathFollower too.

Maybe Laurent was indicating that CC3D could not do scaling of FW PIDs with airspeed (but Revo could).

I don't see that you need to enable TPS (at least in 1609).  It does this (create_pid_scaler() in innerloop.c) whether TPS is enabled or not.  I guess you have tried it without TPS enabled?

Code: [Select]

  scaler.p = scaler.i = scaler.d = speedScaleFactor;

A related issue I found:  I was seeing stabilization go crazy on the ground sometimes and I was afraid to fly it.  I recall I tracked that down to pitot tube noise at zero actual airspeed causing negative airspeed sensor readings.

I initially wondered whether ScaleToAirspeedLimits might be speed, but it is actually square of reciprocal of ratio (to ScaleToAirspeed) so higher speed generates a smaller scale factor.     Good that average user doesn't need to set this. 

At such high speeds your oscillation may be related to servo speed being too slow since you indicate it is not just a mechanical flutter.

if this needs to be coded for performance (stateestimation.c)

Code: [Select]

    // EXPORT_STATE_TO_UAVOBJECT_IF_UPDATED_3_DIMENSIONS(GyroState, gyro, x, y, z) // replaced by performance shortcut
    if (IS_SET(states.updated, SENSORUPDATES_gyro)) {
        gyroDelta[0] = states.gyro[0] - gyroRaw[0];
        gyroDelta[1] = states.gyro[1] - gyroRaw[1];
        gyroDelta[2] = states.gyro[2] - gyroRaw[2];
    }

Then shouldn't this be coded the same way for performance?  (and does 9250 mag run at full rate too?)

Code: [Select]

    EXPORT_STATE_TO_UAVOBJECT_IF_UPDATED_3_DIMENSIONS(AccelState, accel, x, y, z);


[TheOtherCliff]

I got airspeed warnings ... too high, too low, SystemSettings airspeeds too high/low, and throttle going back and forth between zero and full in GPS modes.  I probably should have spent more time playing with velocity PID, but I got it working well enough by setting horizontal vel min and max both to 12 and setting thrust limits to something a bit below and above the throttle necessary for 12m/s.

I had problems with waypoint flight because of the airspeed warnings.  It never would go far before returning to waypoint 1.  I examined the code and found that setting all waypoint ErrorDestinations to a negative number stops it from going to waypoint 1 for every airspeed warning.

I keep telling myself that I will go through FWPF one day, including safety margins and cutoff limits and ALtitudeHoldSettings.* and write up user instructions for successful and complete configuration of GPS flight.

I also would like to try a re-write that uses elevator for altitude, and throttle for speed which seems more natural, and would for example handle sonar altitude (quick changes) a lot better.  Pull up elevator and you get instant vertical velocity change with decreasing speed.  The decreasing speed gets detected and throttle gets added, possibly even add throttle from angle change to delta throttle table.  I also like the idea of circling in position hold, rather than randomly flying back and forth.  It would appear to be able to hold a tighter position (think between the trees).  Also a "tuning flight" that calculates and saves some settings.

[jdl]

@TheOtherCliff, thanks for comments, really helpful!

...I don't see that you need to enable TPS (at least in 1609).  It does this (create_pid_scaler() in innerloop.c) whether TPS is enabled or not.  I guess you have tried it without TPS enabled?

Code: [Select]

  scaler.p = scaler.i = scaler.d = speedScaleFactor;


Absolutely right, the same is in next.711. I must have been sleeping while reading this code section, scaler.x is assigned outside of "if..." section. Shame on me. This means Airspeed PID Scaling can not be switched on and off during flight by switching StabilizationBanks as I initially was planning!

I hadn't noticed negative values for CalibratedAirspeed. Still, when on the ground with no Airspeed, the scale factor should be sticked to ScaleToAirspeedLimits.Max that gives crazy servo reactions even ot small sticks inputs. When airborn, this should not be a problem, I guess. Anyway, I plan to set ScaleToAirspeedLimits.Max to 2 and ScaleToAirspeedLimits.Min to 0.25 for the first tests!

I prefer using a real Pitot tube airspeed sensor instead of software estimated airspeed. It allows using the full functionality of FWPF without the throttle jumps and airspeed warnings you mentioned.

Btw, I encountered idiotic airspeed warnings and throttle jumps even with the analog airspeed sensor in use and it took me some time to find that the issue is caused by the electrical noise from ESC and servos that messes with the ADC readings for the MPXV7002DP sensor. It could be observed watching AirspeedSensor.SensorValue in the scopes while on the ground. Servos in action (by sticks, for example) or full throttle jumps (prop installed on the motor - CAUTION!) SHOULD NOT change noticeably the AirspeedSensor readings.
I had both issues - operating servos was decreasing the AirspeedSensor readings by 15-20, while motor rushes caused jumping it up with 50-70!!

First issue - servos related, happens when servos are powered directly from Revo header pins. Thus, large currents when servos are in action pull up the ground potential at the Revo board and mess the ADC reference voltage. Workaround is simple: power and ground for the servos should be on a separate rail, with 0 and 5V directly connected to the BEC that powers them. Servo signal wires, ESC signal wire and ONLY one GROUND wire should go to the Revo pins header (to additionally avoid ground loops).

Second issue - ESC noise - I had it on the Wing Z-84 that uses 35A LittleBee multirotor ESC, even if the ActiveBraking was disabled. The issue does not persist on MiniTalon that has 45A ZTW Gecko Airplane ESC. I guess that Multirotor ESC is just noisier The solution there is a tiny LC filter on the power line between Revo and MPXV7002DP board.

With this little engineering workarounds the airspeed sensor gives perfectly clean output!

I've noticed a limitation when using MPXV7002DP analog airspeed sensor and Revo FC. The max output of the sensor (4.75V) exceeeds the 3.3V (max 3.6V permitted) input limit of the Revo ADCs. Although it will probably not damage the STM ADC input (max output current from the MPXV7002DP is only a tiny 0.1mA), it is not possible to use the full speed range of the Airspeed sensor. During tests, the max air speed I've seen on the OSD and in telemetry records later is around 125km/h and depends on the current ZeroPoint. Nevertheless, 0-120+km/h range is quite sufficient for an usual RC plane

...oscillation may be related to servo speed being too slow since you indicate it is not just a mechanical flutter.

Possible. Servos are quite fast though: KST DS213MG digital servos  (0.08sec/60°@4.8V,  [email protected]). The same oscillations happened with the little slower Emax ES3352 digitals (0.12sec/60°@4.8V,  [email protected]). No oscillations at all if I switch to manual in that very moment. I still hope that just PID scaling with the higher speed may help.

I keep telling myself that I will go through FWPF one day, including safety margins and cutoff limits and ALtitudeHoldSettings.* and write up user instructions for successful and complete configuration of GPS flight.

I also would like to try a re-write that uses elevator for altitude, and throttle for speed which seems more natural, and would for example handle sonar altitude (quick changes) a lot better.  Pull up elevator and you get instant vertical velocity change with decreasing speed.  The decreasing speed gets detected and throttle gets added, possibly even add throttle from angle change to delta throttle table.  I also like the idea of circling in position hold, rather than randomly flying back and forth.  It would appear to be able to hold a tighter position (think between the trees).  Also a "tuning flight" that calculates and saves some settings.

+1.
I really miss "Autotune" like mode for the FixedWings and it would be useful to have AltitudeHold in Attitude mode (FBWB mode) one day.

[f5soh]

https://forum.librepilot.org/index.php?topic=2989.0
and f5soh noted there that "...Currently airspeed sensor cannot be used to reduce PID". He maybe said then that outer loop PIDs cannot be reduced, because the topic was about high speed oscillations in Attitude mode. But I personally got impression that no PID scaling , according airspeed, is possible at all.

This previous thread was related to a CC3D.

[jdl]

Test completed. EXCELLENT results with Airspeed PID Scaling enabled! This was one of the smoothest Z-84 flights I have ever had.

Left the ScaleToAirspeedLimits.Min to its default value (0.05).
Lowered ScaleToAirspeedLimits.Max a little to 2.5 but will raise it again to the default 3.

No oscillations at any tested speed (up to 152km/h!). Although the effective scaling stopped at 125km/h (this is the max value the analog airspeed sensor can detect with the Revo FC in this setup), PIDs were scaled low enough ( x0.14 approx.) to prevent oscillations.

Also had nice and smooth handling at lower speeds, close to stall speed of the Z-84. In fact, ScaleToAirspeedLimits.Max = 2.5 is reached at 29.7km/h and I've set the stall alarm limit to 28km/h for that particular Z-84. Actually, the stall happens at 22-23km/h (AUW is 675g)

DVR record from the successful test flight (lot of external RF noise in video feed in this area, sorry...):


And one more, from the previous flight, with no PID Scaling. Windy (20-35km/h) and gusts. Terrible oscillations at higher airspeeds (80+km/h).

[TheOtherCliff]

Excellent!

Running it one frame at a time, oscillations look maybe like pitch oscillation with some roll, or is one servo faster than the other?

In my Bixler foamies, pitch oscillation happens first.  I think that is because it is in resonance with wing flex, wing flex like a big guitar string. 

Edit:
I see that you blur out your GPS coordinates.  I always password protect my posted videos.  I daydream that a simple offset built into the OSD would fix a lot of snooping problems.  Shift it into a different country with similar landscape/weather (or over the ocean), but with nice numbers you can subtract in your head.

Edit:
I thought I saw something new on your OSD and it made me think it would be nice to have a "distance to empty" indicator, of course it would vary wildly with wind, throttle, climb/dive.  It could also tell you whether your current angle of descent hits the ground before making it back to base.

[jdl]

Yes, there were pitch oscillations mostly. Z-84 is much more sensitive on pitch than on roll controls / commands.

Have to admit that I've also decreased Pitch PIDs by 15% together with enabling Airspeed PID Scaling, so the comparison between two flights may not be considered completely fair.

Still, I recall I had test flights some months ago with even lower PIDs. So low that they made stabilization and control less effective. But still suffered from high speed oscillations. Tried to counter them with an aggressive TPS curve but this could not help when diving with low throttle at high speeds. Now, PID scaling relative to airspeed seems to be the right way.

Great idea about having some kind of simple encipherment of GPS coordinates! Worths implementing it

About OSD, I've made some modifications on the MinOPOSD code and implemented new features, like safety radius, efficiency estimation (mWh/km), glide distance estimation, etc.

I think "distance to empty" is not so useful, compared to what I named Long Term Safety Radius. It takes consumed energy (mAh) since takeoff, declared battery capacity (mA), odometer (m) and current distance (m) from home to estimate how much further from home the UAV can go before having to return-to-home in a straight line and still have 20% energy left in the battery after landing. Of course, such estimation makes more sense for MultiRotors as they run "on muscles" all the time, but I've found it useful for planes too. Energy saving while gliding is not included in equation and comes as an extra "bonus"

Edit: In "Multirotor Mode" the OSD also shows Short Term Safety Radius, similar to LTSR. It uses energy consumption/efficiency for the last few seconds only as it reflects current flight conditions. Both LTSR and STSR help me judge quite well how long and far I can fly safely.

The efficiency indicator (mWh/km) is self-explanatory. When throttle is off, it switches to a glide distance estimation that does just what you said: using current angle of descent and current altitude calculates how long the plane will travel before touching the ground.