It all looks pretty clear to me, even as someone with limited autopilot knowledge, and is well laid out.
I've not tested it yet, but I've got some comments from a code-read of the autopilot itself:
Bank Angle Max - /autopilot/config/bank-limit will be over-ridden by the table.
FPA FPM Filter - can you simplify this by reversing the logic order on max-rate-of-change ?
IT-CONTROLLER: Speed By Pitch - looks like you convert the target speed to an fpm controller. That seems odd to my untutored eyes. Is this how real APs work?
Can I ask what aircraft you've tested this with?
Thanks,
-Stuart
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A few other random YAsim aircraft from FGdata
These tests were performed by pulling out all other autopilots the aircraft had integrated, and inserting this generic instead
If there is any specific aircraft (perhaps with unconventional characteristics?) let me know and I’ll test it.
Bank Angle Max: here’s how it works
The bank angle limit will never exceed the user set value.
The speed is an approximation of appropriate turn rate at max bank angle vs airspeed, exceed the table value and the rate of turn in banks is too fast, this allows the system to work properly in lighter/slower aircraft where appropriate turn rate is achieved at lesser bank angles. Otherwise, the system would bank too far and the “user” would feel the autopilot is trying to tip the aircraft over!
FPA FPM Filter:
Sorry I didn’t totally understand what you meant by reversing the logic order.
This component has 2 functions: to smooth the demanded VS when the target FPA is updated (as doing so causes a rough jump in the channel demand), and to sync the property when the FPA mode is not active so that when engaged, the filter starts smoothing from the current value (smoother engagement).
Speed By Pitch:
It’s a cascade controller setup, this is commonly used for more complex channels like speed on pitch.
In this case, speed error -> demanded speed rate -> speed rate error -> speed rate controller -> target vertical speed -> regular FPM control law used for pitch modes except basic pitch
My speed on pitch law is rate based, because this gives realistic acceleration/deceleration behavior when the target speed is changed.
Most aircraft I’ve worked with use FPM as a master channel, so that 0 = level flight. Unlike roll, there is no 0 = level flight with pitch angle as “level flight” pitch can be anything depending on alpha. Some places use FPA, but more often I see V/S used so my autopilots are V/S based (except the basic pitch hold mode). This makes implementation of many modes possible with far simpler controllers using absolute values. ONLY speed on pitch uses a PID here! The rest use an absolute calculation which is far better and more stably working.
Hope this answer your questions, looking forward to hear back from you.
Kind Regards,
Josh
PS: Sorry for the late reply. I did not realize the mail was because you sent it here, I thought it was the mailing list so I replied there. Only realized now!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Stuart,
Sorry for the late response, Outlook threw the email into my Junk!!!
The commit I wrote about before your reply was I pretty much did that but also added syncing logic that was accidently omitted from the filter. Please see commit 805877d.
Thank you!
Kind Regards,
Josh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm seeing really bad oscillations in heading using this on the ufo. Basically, if I engage heading mode about 10 degrees off course, it oscillates +/- 60 degrees and never settles down. This is just at 350kts.
Could you take a look please.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Stuart,
I must admit I completely neglected the ufo.
The design is designed to compensate for various classes of plausible FDMs, and since the ufo doesn't behave like a plausible FDM, it would require some changes.
I believe the old system has the same issue with the ufo also.
Regardless, I will check this out.
Kind Regards,
josh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Stuart,
Neither the old nor new autopilot will ever work properly on the UFO properly due to the fact that the UFO is not a (fixed wing) airplane. It defy all law of physics. I tested both old and new and found it does not works!
If you want, I can create a basic "autopilot" type thing for the UFO to fix the problem. UFO FDM is not a real FDM, it reacts predictably.
Please tell me what you want. :D
Kind Regards,
Josh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm crazy busy so have asked @stuartbuchanan @scttgs0 to take a look and give feedback.
Heads Up: I've added commit 9ab0a8 to fix a minor issue.
Kind Regards,
Josh
Hi Josh,
Apologies for the delay on this.
It all looks pretty clear to me, even as someone with limited autopilot knowledge, and is well laid out.
I've not tested it yet, but I've got some comments from a code-read of the autopilot itself:
Bank Angle Max - /autopilot/config/bank-limit will be over-ridden by the table.
FPA FPM Filter - can you simplify this by reversing the logic order on max-rate-of-change ?
IT-CONTROLLER: Speed By Pitch - looks like you convert the target speed to an fpm controller. That seems odd to my untutored eyes. Is this how real APs work?
Can I ask what aircraft you've tested this with?
Thanks,
-Stuart
Hi Stuart,
Thanks for the comments.
I have tested this with:
These tests were performed by pulling out all other autopilots the aircraft had integrated, and inserting this generic instead
If there is any specific aircraft (perhaps with unconventional characteristics?) let me know and I’ll test it.
Bank Angle Max: here’s how it works
FPA FPM Filter:
Speed By Pitch:
Hope this answer your questions, looking forward to hear back from you.
Kind Regards,
Josh
PS: Sorry for the late reply. I did not realize the mail was because you sent it here, I thought it was the mailing list so I replied there. Only realized now!
Pushed improvement to V/S and FPA filtering logic.
Patiently awaiting your reply :D
Kind Regards,
Josh
Hi Josh,
Thanks for the explanations and sorry for the delay.
I think you've tested a good set of aircraft, and your latest change.
On the FPA FPM Filter, you have the following:
<filter>
<name>FPA FPM Filter</name>
<type>noise-spike</type>
<input>/autopilot/internal/target-fpm-fpa-raw
<output>/autopilot/internal/target-fpm-fpa</output>
<max-rate-of-change>
<condition>
<not-equals>
<property>/autopilot/locks/altitude</property>
<value>fpa-hold</value>
</not-equals>
</condition>
<value>10000</value>
</max-rate-of-change>
<max-rate-of-change>300</max-rate-of-change>
</filter>
Can you change it to this:
<filter>
<name>FPA FPM Filter</name>
<type>noise-spike</type>
<input>/autopilot/internal/target-fpm-fpa-raw
<output>/autopilot/internal/target-fpm-fpa</output>
<max-rate-of-change>
<condition>
<equals>
<property>/autopilot/locks/altitude</property>
<value>fpa-hold</value>
</equals>
</condition>
<value>300</value>
</max-rate-of-change>
<max-rate-of-change>10000</max-rate-of-change>
</filter>
Other than that, I think this should be committed.
Hi Stuart,
Sorry for the late response, Outlook threw the email into my Junk!!!
The commit I wrote about before your reply was I pretty much did that but also added syncing logic that was accidently omitted from the filter. Please see commit 805877d.
Thank you!
Kind Regards,
Josh
Will do.
Hi Josh,
I'm seeing really bad oscillations in heading using this on the ufo. Basically, if I engage heading mode about 10 degrees off course, it oscillates +/- 60 degrees and never settles down. This is just at 350kts.
Could you take a look please.
Hi Stuart,
I must admit I completely neglected the ufo.
The design is designed to compensate for various classes of plausible FDMs, and since the ufo doesn't behave like a plausible FDM, it would require some changes.
I believe the old system has the same issue with the ufo also.
Regardless, I will check this out.
Kind Regards,
josh
I was just thinking the same thing. Perhaps the solution is to use the "old" autopilot just for the ufo? What do you think?
It doesn't work either from what I recall. But I doubt its a hard solution.
Kind Regards,
Josh
Hi Stuart,
Neither the old nor new autopilot will ever work properly on the UFO properly due to the fact that the UFO is not a (fixed wing) airplane. It defy all law of physics. I tested both old and new and found it does not works!
If you want, I can create a basic "autopilot" type thing for the UFO to fix the problem. UFO FDM is not a real FDM, it reacts predictably.
Please tell me what you want. :D
Kind Regards,
Josh
Ah, must me by memory - I thought that the WL and HDG modes at least worked using the old AP.
I've pushed your changes.
If you have the time to create a basic autopilot like function for the UFO, that would be nice.
Thanks for your patience, and sorry it took so long. I've been a bit busy recently with non-FG stuff.
-Stuart
Hi Stuart,
Thanks!
I do not see a reason it can't be done, I will write about it if news is available.
No problem, and thanks again for your input!
Kind Regards,
Josh
Stuart, please see: https://sourceforge.net/p/flightgear/fgdata/merge-requests/288/
I have done as you requested.
Kind Regards,
Josh