Fixedwing porpoising effect in altitude hold modes

[rts18]

I ran tests using 8.0 from the master. And encountered a porpoising or dolphin effect in all modes that hold altitude. I proceeded to run auto level trim and altered pitch2throttle related settings, showing no difference. I did not expect anything to change, as this aircraft was already tuned with 7.1.2. I later reduced nav_fw_pos_z_p = 29 and increased nav_fw_pos_z_i = 8. This appears to have removed the effect. However it does not appear to track altitude as well as the previous release. It reaches the target altitude and slows down correctly with the adjustment of an apparent new setting nav_fw_alt_control_response. However there is more drift either side of the setpoint altitude, than while using 7.1.2.

[breadoven]

What wing was this and do you have a log and diff file ?

[rts18]

It's an Orca V2. Sometimes INAV records the logs and sometimes they're corrupted. This was the latter.

Here is the Diff. Orca 8.0.txt

[P-I-Engineer]

i also had really bad pitch oscillations in alt hold modes. turning i gain down helped then it flew sloppy

[breadoven]

It would be useful to have a 7.0 Diff and an 8.0 Diff so the PIDS for the altitude control changes in 8.0 can be better tuned. And as mentioned above a log would be most useful to better understand what's happening.

[b14ckyy]

It's an Orca V2. Sometimes INAV records the logs and sometimes they're corrupted. This was the latter.

Here is the Diff. Orca 8.0.txt

set your Logging rate to 3% only. Thats sufficient for most things to analyze. Everything above 250Hz (or 25%) can be problematic on some SD cards. btw your loop time is not in the diff. That means it is on firmware default and that should be 2khz. This is too much fur a wing and means that with your 25% log rate right now it logs at 500Hz. Definitely problematic with SD logging.

[breadoven]

Have you noticed these same problems @b14ckyy ? The PIDS for https://github.com/iNavFlight/inav/pull/9471 were never fully optimised other than basic tweaking to avoid an instability with the original settings. They work fine for me for a conventional plane, certainly not obviously worse than the previous position based altitude control method. I'm guessing it's more likely to cause problems with flying wings which tend to be sluggish in pitch response.

I imagine it would be beneficial to add in PID FF, should improve responsiveness, so I'll do that and see if it improves things.

[rts18]

@breadoven Besides nav_fw_pos_z_p = 35 etc. All other setting alterations between 7.1.2 and 8.0 are based on the software improvements. Like the removal of UBLOX7, control_profile renaming and things of that nature. With all other new features using default settings. And I don't have any of the new filtering enabled.

@b14ckyy Thanks for the heads up. I'm aware that lower speed logging often works better. But I still experience log corruption on most of my flight controllers. Not always, but regular enough to say its frustrating. If it was just about replacing a SD card that would be fine. But I've been seeing this issue all to often. I have logging problems with most flight controllers, with dozens of SD cards of all different brands and speeds. And to cap it off. When reformatted, these cards work fine with the same flight controllers, using other flight software.

[b14ckyy]

I have had altitude hold problems in different ways indeed but no constant dolphining. On my Altus during my test flights the FF tune for pitch was off and I eyeballed it manually. After that the altitude hold was kind of sluggish. I have not investigated further so far due to lack of flight time.

The worst issues I have is with HITL actually as in waypoint missions the plane really struggles to climb to the target altitude and sometimes even loses altitude despite being already below. This only then recovers when getting closer to the target WP. But my HITL plane tune is a mess in general and I wanted to redo that from scratch before going into that further.

As I have to rebuild the Altus anyway after my recent crash I will set it up with 8.0 from scratch and see how it behaves. It was well behaving in 7.1 with just the basic tuning (Autotune, Angle trim, P2T and bank angles.

@rts18 can you please open another issue ticket for the corrupted logs with the same info. Also please post a dump (and not a diff) from the affected craft, some of the corrupt logs and the SD card models you tested? Its something that should be tracked and noted.

[breadoven]

After testing on HITL I get the impression altitude control is possibly best with lower P, higher I and turn up nav_fw_alt_control_responseas much as possible before porpoising becomes a problem, certainly at least 30. Higher nav_fw_alt_control_responseshould sharper up the response. Also keep D term low, no higher than the default of 10.

However, this is just based on HITL testing which I'm not convinced is great when it comes to accurately simulating dynamic stability so take the above as a rough guide.

[Jetrell]

I agree. the sim is useful. But its flight dynamics leave a bit to be desired, when comparing to many real models.

I found that increasing nav_fw_alt_control_response wasn't a good idea if nav_fw_auto_climb_rate is increased to suit individual requirements.. This often caused my elevon controlled aircraft to oscillate around the altitude target when its windy.. This is more noticeable in a loiter circuit, when the aircraft looses lift on the down wind side of the loiter circuit, and gains it on the head wind side. When I tested back and forth between the pos and vel controllers. I found this condition was more exaggerated.

It reaches the target altitude and slows down correctly with the adjustment of an apparent new setting nav_fw_alt_control_response. However there is more drift either side of the setpoint altitude, than while using 7.1.2.

The Velocity controller certainly appears to react more responsively to a call to change altitude, and to halt at the target. But it seems to have issues maintaining the target window under certain conditions.

[breadoven]

There isn't really that much difference between using velocity and using position as far as the PID controller is concerned. It effectively just looked at the error between desired and actual position before and now looks at desired and actual velocity. However, the desired velocity is just based on:

position error * nav_fw_alt_control_response/ 100

Or ... 0.2 * position error if nav_fw_alt_control_responseis set to the default of 20.

So it is using a smaller error to work with. However, checking the previous position based code again I'd forgotten that the inputs used by the PID controller, desired and actual energies, were effectively just the positions factored down by around 10. This 10 figure is gravity / 100, gravity in m/s2 and the 100 to convert centimetres to metres, to give you potential energy (ignoring the mass). I compensated for this by reducing the PID setting factors for P, I and D by 10 (they were previously factored down by 10 so are now factored down by 100).

So the working error is smaller around the control point with the velocity based control which could explain the poorer response in some cases (possibly made worse by estimated velocity being less accurate than estimated position ?). However, I'm also thinking that factoring down the PID settings probably isn't the same as factoring down the actual error inputs to the PID controller so maybe this should be changed to make it the same as the previous position based control. I also changed the D term calculation from using measurement to error which is a significant difference given measurement tracking appears to link D term to whether or not you're climbing or descending rather than the altitude error itself increasing or decreasing (which seems more relevant ?). However, this could be changed back to see if it improves things.

[b14ckyy]

I will this time set up a plane from scratch and see how it behaves. Probably testing tomorrow after my Altus is repaired

[Jetrell]

However, checking the previous position based code again I'd forgotten that the inputs used by the PID controller, desired and actual energies,

That is interesting. Because I'd noticed with the Pos controller, that elevator up was applied in the crosswind quarter of the loiter circuit, before it would turn to the downwind quarter. Which seemed to help it hold altitude with the tail wind. While the Vel controller mostly doesn't try to correct for loss of altitude in the downwind leg of the loiter circuit until it had already lost a few meters.. But by that time, it makes it harder and takes longer to regain what its lost.

However, I'm also thinking that factoring down the PID settings probably isn't the same as factoring down the actual error inputs to the PID controller so maybe this should be changed to make it the same as the previous position based control.

I would agree with that line of thought.

I also changed the D term calculation from using measurement to error which is a significant difference given measurement tracking appears to link D term to whether or not you're climbing or descending rather than the altitude error itself increasing or decreasing (which seems more relevant ?).

From looking over the logs again. The times altitude oscillations are most noticed, when comparing the Vel with the Pos controller. Is after the airplane makes a turn, and looses altitude. And that especially if the turn takes it on a downwind heading. There was always a slight drop in altitude with Pos controller.. But the Vel controller has much more difficulty trying to recover that lost altitude.. It gets it back. But it can take a considerable amount more time with some airframes under windy conditions.. And that apart from the reduction in PI gains required to lessen the porpoising effect in althold, in straight line flight.