[jdl]

I've uploaded the new source code (v2.59) here:

https://github.com/jdlilov/MinOPOSD-JDL/tree/main/Sources/ArduCAM_OSD

Hope it works, I don't have time to test it right now. Any observations and comments on the new feature are welcome!

P.S. You might want to change the Flight Telemetry Update Period to something less than (default) 1000ms if faster updates of the OSD displayed thrust in autonomous modes are desired.

LibrePilot GCS: System Tab (UAVObjectBrowser) | Data Objects | ActuatorDesired | Metadata | Modes | Flight Telemetry Update Period

[trust]

jdl - thanks - I'll try it soon.
Meanwhile I ran more tests - after the first day of mostly reasonable tests, my attempts to improve it by narrowing the thrust window had the opposite effect. There was a tendency to speed up and turn in the right direction, but then the plane would pitch up, stall, and go into a spin.
After two days of trying adjusting the thrust and speed limits, I tried shifting the landing pitch from 0.5 to -5 degrees. This made a world of difference. Ran about 10 tests today and they all flew back to target. There is still a tendency to first speed up in the first turn, then throttle way back. At least now it doesn't stall. The pulsing tends to even out if the path back is far enough. You'll notice the pulsing in the 2nd RTB test - throttle peaks about every 10 seconds.
Any ideas on how to smooth it?

[TheOtherCliff]

First you need to make sure that your Airspeed UAVO is set up and working right.

Then the "correct" way would be do tweak the Altitude PID.  If a PID is oscillating, a quick fix is to reduce the numbers (say multiply P, I, (and D) all by 0.66).  The long way is to tune the PID however you know to do that.

The Altitude PID version is either in the pathfollower version you are using (I guess this auto-switches and re-inits correctly?) or is in an external Altitude* UAVO.  Generally, the *PF settings are used when the PF is being used, but IIRC there is one case where the *PF setting is completely ignored and not ever used?

IIRC you can disable the use of airspeed and it will try to fly with a fixed angle of attack, must be slightly up where adding power makes it climb.  Airplane probably needs to be a bit nose heavy...

Be aware that in the FWPF, the vertical/thrust algorithm is "if too low, increase thrust" and "if too slow, push elevator down".  It is done this way for safety on engine failure instead of needing special code to keep it from pulling up and stalling on engine failure.  I think the main FWPF altitude setting is VerticalPosP, but then there are several other settings such as PowerPI. SpeedPI, and *CrossFeed that I have not played with and probably all interact.  Finally, there are Safety* and if these are disobeyed, your waypoint flight will go to "error destination" rather than next waypoint.  Try to understand these and set the limits to good values.  The way to avoid this for waypoints is to to set error destination to -1.

It would be great if someone would write up a complete FWPF tuning guide, but I suspect that there are a lot of things there that you should just leave alone, like the EKF settings.

Be aware that there seem to be some issues with flying wings and FWPF.

Karla, JDL, and I discussed FWPF altitude tuning (some guessing and testing) and flying wings here IIRC:
https://forum.librepilot.org/index.php?topic=4769.0
https://forum.librepilot.org/index.php?topic=3518.0

[trust]

Thanks for the notes.
I don't have an airspeed sensor. UseAirspeedSensor is set to false, so it flies with parameter hasAirpeed false all the time.
There seems to be a way to use the GPS to simulate airspeed, do I just set UseAirspeedSensor to true?
How does it know if there is actually a sensor? If one was setup in the config?
BTW - if hasAirpeed is false, it always flies with fixed pitch - the one defined as landingpitch.

[TheOtherCliff]

There seems to be a way to use the GPS to simulate airspeed, do I just set UseAirspeedSensor to true?
How does it know if there is actually a sensor? If one was setup in the config?

As I recall, you set AirspeedSettings.AirspeedSensorType to GroundSpeedBasedWindEstimation

I have flown many autonomous flights using GSBWE and not really had problems with it, but IIRC @JDL has.  I have some hacks, like setting thrustlimits to a narrow range that could potentially be making my setup work better than stock?

I have 2 autonomous airplanes, one with GSBWE and the other with a pitot tube sensor.

I would compare airspeed sensor value to GPSPositionSensor.GroundSpeed over some long flights (live or recorded telemetry).  Of course if you do this on a calm day they should be very similar and if they differ, GSBWE is suspected.  Long periods of flight into the wind or downwind can be easily subtracted from your wind speed estimate.  Flying perpendicular to the wind (but a little downwind, just enough to drift down wind with the wind) can negate the wind speed.

BTW - if hasAirpeed is false, it always flies with fixed pitch - the one defined as landingpitch.

I would not have guessed "the one defined as landingpitch"
I would guess that is for landing mode and that it uses PitchLimit.Neutral for normal FWPF flight

[trust]

Thanks. Ill try GSBWE.
Looking online there seems to be a dearth of available pressure sensors to use for airspeed that are supported. Must be the chip shortage. The chips are all back ordered well into 2022.
Do you are does anyone have any extra sensors they're not using they'd be willing to sell?

A tricky question is whether the pitot tube should be mounted on the rotating wing, or to the main body. I would think the latter, but there may be cases where that isn't correct, such as steep climbs in vertical wing mode. IF the motors are at high power, the lift tends to be so great that the body stays mostly level but the wings tilt more in the vertical direction.

[TheOtherCliff]

Here are some sensors/pitots from posts I remember.
https://forum.librepilot.org/index.php?topic=4819.msg32303;topicseen#msg32303
http://e-hely.com/index.php?route=product/product&path=73&product_id=7141
https://www.xt-xinte.com/h-product-detail.html?goods_id=138778
https://www.ebay.com/itm/333924554403
https://www.ebay.com/sch/i.html?_nkw=(mpxv7002%2C+mpxv5004%2C+4525DO)
https://www.google.com/search?q=Ardupilot+Arduplane+Airspeed+Meter+Sensor

https://forum.librepilot.org/index.php?topic=4819.msg32389;topicseen#msg32389
https://www.aliexpress.com/item/32560997823.html?spm=a2g0o.cart.0.0.21f93c00C3V7HQ&mp=1

A tricky question is whether the pitot tube should be mounted on the rotating wing, or to the main body. I would think the latter, but there may be cases where that isn't correct, such as steep climbs in vertical wing mode. IF the motors are at high power, the lift tends to be so great that the body stays mostly level but the wings tilt more in the vertical direction.

In the code, the airspeed is used for fixed wing, to maintain airspeed in a range and avoid stall or flutter.  I don't see a need for pitot to rotate with the wing.  If hovering upward is positive speed, what would hovering downward be?

[trust]

Thanks for all the links. Many are back ordered, but Aliexpress has one I think I'll order.
Today before the rains hit again I tested the GPS ground based wind estimator.
It seems to act slightly different, though there is still the throttle up after initiating. The updating process seems to happen faster, and there is more pitch oscillating at times, but it always got back to base. On the second test with it pointed directly away, it had a bit of problem deciding which way to turn - changing direction several times - but it did finally pick one and go with it. Winds lite 5 SE but seemed stronger up higher.

The sound is slightly delayed in the audio.

[TheOtherCliff]

I recall a fixed wing in an autonomous mode that ran the motor up to full and down to off with a period of many (10?) seconds.  For a quick fix that I never changed, I adjusted the thrustlimits.  I recall @JDL had a similar issue that he fixed in a more correct fashion by adjusting some period1 / period2 stuff.  Pretty sure that thread is linked in my previous post.

Ah, search found it:
https://forum.librepilot.org/index.php?topic=3518.msg24240;topicseen#msg24240

(RTB)

it had a bit of problem deciding which way to turn - changing direction several times

As you know, it simply picks the shortest one of the two turns to home.  Changing (or seeming to change) the turn to go the other way says something funny is going on.  Adverse yaw when you roll or other control problems, bad compass readings (doubtful), strong wind blowing you sideways as you fly straight away from Base and thus changing an 89 to a 91, etc.

[trust]

The two IMUbasedxxx periods 1 and 2 are at 0.5 and 10 respectively. I can try upping them to 0.75 and 20 and see what happens.
I had tried in earlier tests to tighten the thrust limits to 0.4,0.5,0.6 - but it did not seem to have any helpful affect - it still ramped up and down a lot (much more than that range), but that was before I changed the pitch neutral to -5, which made the biggest difference. I also tried changing the Horzvelmax/min to a narrower range and Vertvelmax to 3 - those too did not seem to help any, though in checking the code they still SHOULD have had an affect even with hasAirspeed false.
At one point it did ramp up to 20m/s but that was a downwind leg.
I may try changing them back again to the tighter limits anyway.

It's too bad the algorithm can't be tailored to using yaw to change direction - with wing mounted motors it does very tight yaw turns at low speed, with very little or no loss in altitude. A little bank reduces the slip losses, but it doesn't need much. It will stall if you go TOO tight, but it's still impressive how tight you can get it.

I think I may try some waypoints now too - with some altitude changes to see how it works there.
Fun!

[TheOtherCliff]

I had tried in earlier tests to tighten the thrust limits to 0.4,0.5,0.6 - but it did not seem to have any helpful affect - it still ramped up and down a lot (much more than that range),

That makes me wonder if it is using the VTOLPF (or even AltitudeHold.ThrustLimits?) there...  or if more stuff needs to be done during the switch from VTOL to FW.

Telemetry ActuatorDesired.Thrust should stay within 0.4 to 0.6 or it could be tracked down as to why it isn't...

It's too bad the algorithm can't be tailored to using yaw to change direction - with wing mounted motors it does very tight yaw turns at low speed, with very little or no loss in altitude.

I am currently running a version where I hacked that code to immediately apply some up elevator to allow configured bank tighter / turn tighter.  It will give some up immediately rather than wait for the nose to drop before applying up.  I imagine you could add maybe some yaw ratedesired in there?