Refactor autopilot

[onox]

I'm planning to refactor the autopilot to be fully XML. Maybe use some XML state machines and new-navradio. Tuning the PID controllers so that it doesn't oscillate for half an hour on a VOR radial.

Also see https://github.com/c172p-team/c172p-detailed/issues/769#issuecomment-221107668

[gilbertohasnofb]

Talking of autopilot, can you see this report here, onox?: http://forum.flightgear.org/viewtopic.php?f=4&t=25157&sid=f687cbe7dd1ddfa53ba113f460d6754e&start=2490#p267580

[onox]

Yes, I saw that post. Seems I'm not the only one who thinks the AP is flaky.

[gilbertohasnofb]

Ok.

[onox]

239 is the issue about the altitude preselect beep. I'll make it persistent when I rewrite the AP.

@wlbragg FYI I'm working on it :wink:

@legoboyvdlp The AP has two knobs. The outer knob scrolls faster. You can also hold your mouse button and just drag the mouse. That's quicker than scrolling.

[wlbragg]

:+1:

[legoboyvdlp]

Thanks, @onox

[gilbertohasnofb]

stuart wrote in the forum:

Hi Guys,

Regarding the KAP-140 autopilot:

As some people have noted, some of the operations aren't exactly what you might expect if you're used to the standard FG manual.

There is lots of information on the internet about it's operation: http://www.bendixking.com/Products/Discontinued/KAP-140 includes the full Pilot's Guide.

I'd be very wary of trying to fix "bug" unless you've absolutely verified that you know from primary sources what the behaviour should be.

I'd also suggest not replacing it with another autopilot. One would need to go back over FG history, but the impression I had when I was maintaining the older c172p was the that autopilot was created by someone very familiar with the real thing.

-Stuart

[onox]

I had already downloaded the manual. Also, I know the KAP-140 is a bit odd compared to other other autopilots and I do not intent to change its behavior much.

Main thing I want to do is get rid of all that ugly Nasal code, require AP button to be pressed for at least 250 milliseconds in order to engage the AP, tune PID controllers to reduce the horizontal oscillations in NAV mode, reduce oscillations when accelerating time, and investigate using new-navradio.

[wkitty42]

On 12/12/2015 10:44 AM, onox wrote:

I had already downloaded the manual. Also, I know the KAP-140 is a bit odd compared to other other autopilots and I do not intent to change its behavior much.

Main thing I want to do is get rid of all that ugly Nasal code, require AP button to be pressed for at least 250 milliseconds in order to engage the AP, tune PID controllers to reduce the horizontal oscillations in NAV mode, reduce oscillations when accelerating time, and investigate using new-navradio.

will this refactoring also (finally) tie the panel AP to the F11 AP dialogue? i do hope so... right now the dialogue is only good for setting the heading bug and that is with the heading control box checked or not... the altitude hold and rate of climb/descent don't do anything, with the checkbox or not... speed control i don't use so have no thoughts on that... i just really want to see the F11 dialogue be more operational with the craft's AP so that i don't always have to switch to the cockpit view, zoom in, look down, try to find the buttons and then set them... F11 is just so much easier...

[onox]

@wkitty42 I know you like punching in numbers/keys, but the F11 window is really meant for (new) aircraft that don't have a native AP yet. Second, the F11 window suggests the AP can do more than it really can. Third, the KAP-140 AP has some unusual requirements like requiring to set the heading bug to the same as the CDI radial if you activate the NAV mode for example. And the F11 window doesn't show this.

We would basically have to recreate the KAP-140 AP as a PUI window. And why would we do that when we already have one in the cockpit? So I think we should actually hide the F11 window because currently it is useless anyway.

[onox]

In the future it would be nicer if you could click on the AP screen and then a new Canvas window pops up showing the same KAP-140 AP.

[wkitty42]

On 12/12/2015 01:43 PM, onox wrote:

@wkitty42 https://github.com/wkitty42 I know you like punching in numbers/keys,

it isn't that i ""like to""... it is that i'm an old school touch typist... i use the keyboard for at least 90% of what i do... even when web browsing :wink:

but the F11 window is really meant for (new) aircraft that don't have a native AP yet. Second, the F11 window suggests the AP can do more than it really can. Third, the KAP-140 AP has some unusual requirements like requiring to set the heading bug to the same as the CDI radial if you activate the NAV mode for example. And the F11 window doesn't show this.

there are some craft that bring up a much different dialogue than the standard F11 AP dialogue... we could do our own or adapt one of the more simple ones to fit the KAP-140's functions...

We would basically have to recreate the KAP-140 AP as a PUI window.

why? i understand there's also canvas but i don't know which is better...

all we need is a dialogue box with the same fields that the KAP-140 shows so that we can see the same numbers which ever way we choose view them... so we can directly enter the numbers via the dialogue or use the more realistic clicky-slidey knobs and buttons and fraking about with the view point and zooming in and out... that's really only even been my complaint about the AP in this craft...

all the others that use F11 work just fine with the default dialogue... some provide their own replacement dialogue that's as complicated as the panel control but at least there's a dialogue that can be brought up while still being able to see out the windows or whatever the current point of view is... even if one is looking at the engineer's panel, they can see and adjust the AP settings when the engineer's panel can't do that :wink:

And why would we do that when we already have one in the cockpit? So I think we should actually hide the F11 window because currently it is useless anyway.

no, it is not useless! at least one can fly around using it with the GPS and setting the heading bug to match the purple line in the map window without having to muck around zooming in on the panel and moving the view point around while not being able to see anything going on outside the windows, make the adjustments, zoom back out and try to get the view centered properly again... that's especially a beeyotch when trying to get into the air or navigating valleys in the mountains...

i've also been considering that we implement the original AP as i noted in another post somewhere else... apparently this KAP-140 is a retrofit or maybe the craft was purchased new with it and cessna came out with their own later... i don't know but the POH on the c172 definitely talks about their various APs and how to work them... when the cessna AP(s) are implemented, then one can choose which AP they want in their craft...

some folks talk about having a "S-Tec 50" and adding a "S-Tec GPSS" allowing for interfacing with their GPS... a garmin "GNS 430W" GPS has been mentioned in some posts i've read... of course the GNS line is no longer available, but...

anyway, whatever...

/me stumbles back to the workbench for more recovery work on a dead server :(

[wlbragg]

So I think we should actually hide the F11 window because currently it is useless anyway.

That make a lot of sense.

In the future it would be nicer if you could click on the AP screen and then a new Canvas window pops up showing the same KAP-140 AP.

That makes even more sense.

will this refactoring also (finally) tie the panel AP to the F11 AP dialogue?

I kind of look at it like this, you could add virtually every other common instrument to the dialog (GUI), but for some reason it was decided to only add autopilot as a stand alone menu entry, and then you have an instruments menu entry with a couple items (radio) why? What else can you access on the GUI? I think it should be all or nothing. Make everything available in GUI. However, I'm not interested in doing this myself, not when the real thing is sitting in front of me. If the framework was setup as such that it polled the aircraft code for what instruments to add to the GUI and all aircraft followed the same format, well then that would be cool too.

To me it was a bad implementation of a potential good thing which left it in the state it is. I'm sure there were good intentions but it needs consistency.

[wkitty42]

On 12/12/2015 01:45 PM, onox wrote:

In the future it would be nicer if you could click on the AP screen and then a new Canvas window pops up showing the same KAP-140 AP.

that might be alright, too... and link it to F11, too :wink:

aside: my apologies if i sounded grumpy earlier... i lost a server yesterday and have been working on it all night... that's why my posts stopped in the other issues when they did... it normally sits right next to me... when it blew, it was really loud, very bright and let an awful lot of that majik smoke out :cry:

[onox]

that might be alright, too... and link it to F11, too

If we manage to replicate the AP in a Canvas window I don't have any problems with binding it to F11.

but for some reason it was decided to only add autopilot as a stand alone menu entry, and then you have an instruments menu entry with a couple items (radio) why?

Would you prefer to disable the "Radio Settings" window as well? I would not be opposed to that. Everything can be done with the instruments in the radio stack.

[wlbragg]

Would you prefer to disable the "Radio Settings" window as well?

I guess not in light of @legoboyvdlp reply.

This hodgepodge scattering of extraneous GUI items, added with good intention, is now being relied on and expected by some. I don't know what the politically correct thing to do is, ask 10 different users and you'll get 10 different answers.

In the long run, I think there needs to be a well thought out strategy of what to include in the GUI, not an assortment of whatever sounded good at the time.

[dany93]

Is there a drawback at letting the generic AP and radio stack (F11, F12)? They can be convenient for some users, quick to set for some tasks (I've often used the generic AP on aircraft when it works well for the FDM development). For those who would complain that they are not satisfied with the generics, the response is obvious.

[wlbragg]

I don't think there is any harm in leaving them available. I'm just venting about the GUI in general. In a perfect world, I think they could have been organized better.

[Octal450]

Hi, @onox I wrote my KAP140 ITAF module to replace the FGData autopilot, which was working poorly, I did not get REV mode finished, but that can be done rather easily.

This aircraft is really good, but the autopilot is quite lacking, hence why I recommended this to @legoboyvdlp. If you'd like, I can fork this and make a prototype and you can decide whether you want to use it or not.

Kind Regards, Josh

PS: I also have a F11 dialog for the KAP140 ready.

[onox]

but the autopilot is quite lacking

Can you elaborate?

[Octal450]

Hi @onox, I find to often be unstable, and does not work reliably. I experienced many oscillations, mostly in the pitch axis, and while navigating VORs and ILSs.

Kind Regards, Josh

[onox]

Isn't it then just sufficient to tune the PID controllers? That's what I wanted to do when I wanted to refactor (https://github.com/c172p-team/c172p-detailed/issues/603#issuecomment-164162176) the code and clean it up a bit.

The KAP 140 AP generally behaves a bit odd if you're used to other AP's in FG.

[Octal450]

I attempted to do so in my PA28-Warrior, however, the changes became so extreme, I just decided to rewrite the entire XML file, all controllers.

I also ended up changing the nasal, as the nasal also has some faults, and during doing so, I used the Pilot manual to do so.

I already have 90% of the code, so it wouldn't too much work to finish it.

Kind Regards, Josh

[onox]

Tuning the PID controllers just requires changing some numbers, it shouldn't require extensive changes, should it?

[onox]

@it0uchpods How much code are we talking about? Does it reproduce the KAP140 oddities like requiring the pilot to set the HDG bug when switching to NAV for example? Is the F11 GUI a canvas window?

[Octal450]

@onox That is the problem. Just retuning everything won't fix it fully. I've rewritten the entire XML in a much more advanced way.

I didn't do that yet, but those things can be added rather quickly.

I don't know exactly, but many hundreds of lines.

Kind Regards, Josh

[legoboyvdlp]

@onox I am sure that it0uchpods could guarantee that whatever is in the Bendix KAP 140 manual will be in the ITAF KAP140?

[wlbragg]

I'm impressed with the stability of @it0uchpods autopilots. I'm using the ga in the j3cub with no complaints, "other than he won't make me one for the yasim Aircrane" :smile:

I don't know if anyone else has ever experienced this issue I have with our autopilot. But I have verified this to myself more than once. If I set the autopilot to fly a direction and sit back and relax, after a certain amount of time it suddenly decides to break and starts a violent bank that I can't control without shutting down the autopilot. This is a consistent behavior on my system. Or at least it used to be. I haven't used it since I verified this bug. Either it is a bug or by design that it changes course after a certain amount of elapsed time.

[Octal450]

@wlbragg thank you. :) [offtopic] Ultimately it could be done, but I don't have enough time to fully design a full new system for helis right now [/offtopic]

I suggest anyone to try the PA28-Warrior in my repo, you can try the KAP140 I developed there, which works about 80-90% correctly. The remaining functionality I could probably get in there rather quickly.

Kind Regards, Josh

[HHS81]

@it0uchpods Please tell us what you mean with "correctly"! Does it relay on the same systems like the real KAP140?

Looking at your implementation I can say: No!

As you know, FlightGears motto is, to make it work like the real one. That means simulating it, emulating it where possible. Please have a look on the pages of the manual of the KAP140 where the underlying systems and inputs are described....

[HHS81]

Btw: some older autopilots (60s/70s/80s) has some oscillations, Thorsten Dreyer reported that his owned real SenecaII does the same shaking over a VOR like it does in FlightGear.

[Octal450]

@HHS81 The behavior is the same. The ultimate issue I had was that alot of readings could not be found properly, such as air pressure. I had tremendous problems with this property and decided instead to base it off a more stable property, vertical speed.

By correctly, I am describing the behavior. Button presses, etc. However, when I designed this AP, the aircraft was still yasim. perhaps JSB makes this property more correct, and I can base it off air pressure again. Its been a while now and I don't remember much else.

My main issues with the current AP in the 172 are:

• Logic seems full of bugs, I've had it stop working completely a few times
• AP is very unstable, especially in bad weather

I am aware of that, and it can be modelled, but I am talking about is instabilities. There is a difference.

Kind Regards, Josh

[HHS81]

@it0uchpods

I had tremendous problems with this property and decided instead to base it off a more stable property, vertical speed.

That's not how the real KAP140 is working.

Property: /systems/static[0]/pressure-inhg[0] ? Nothing to do with JSBSim.....

Logic seems full of bugs, I've had it stop working completely a few times

Which bugs? What's wrong?

AP is very unstable, especially in bad weather

Framerates? Turbulences? (especially the later is often much stronger in FGFS than in real life)

FlightGear is about making things right- that means simulating/ emulating it like the real ones. I think @onox described the issues of the KAP140 quite well above:

ugly Nasal code, require AP button to be pressed for at least 250 milliseconds in order to engage the AP, tune PID controllers to reduce the horizontal oscillations in NAV mode,

[Octal450]

Hmm, then I'm not sure. I saw the original was using pressure, so that is what I tried to do at first, but it proved very irritating.

I won't bother then, seems you don't need me.

Kind Regards, Josh

[wkitty42]

On 02/21/2018 01:56 PM, wlbragg wrote:

I don't know if anyone else has ever experienced this issue I have with our autopilot. But I have verified this to myself more than once. If I set the autopilot to fly a direction and sit back and relax, after a certain amount of time it suddenly decides to break and starts a violent bank that I can't control without shutting down the autopilot. This is a consistent behavior on my system. Or at least it used to be. I haven't used it since I verified this bug. Either it is a bug or by design that it changes course after a certain amount of elapsed time.

i've never seen anything like that and i'm one to fly the c172p across country from KSFO to KJFK (for example) non-stop (using fuel freeze)...

as soon as i get off the ground, i've got the AP on for wing leveling, heading control and especially maintaining the climb rate which i generally run ~700 or less depending on altitude... i forget when i set my desired altitude but it gets there and holds it for me...

i use the heading bug to direct my course... yeah, i'm an extremely basic user on long max ceiling level flights... the only thing i ever really ran into was wind drift and that took me a little while to figure out with prodigious use of the CTRL-M map... i know i can (could?) take off from KSFO and be at max ceiling on a heading of 90 before i get to the mountains and cross over Mammoth's airport...

could you maybe be having some sort of damage (ice?) causing the AP to respond badly?

[HHS81]

@it0uchpods

I won't bother then, seems you don't need me.

I wouldn't say that. The KAP140 needs some tuning, some up-to-date nasal code....

[Octal450]

@HHS81 -, ok then. I'll probably end up rewriting the XML portion again then, to keep it neat, and up to date. When I get some spare time I'll look into it.

Kind Regards, Josh

[onox]

To me replacing the AP with ITAF feels like adding a full blown professional Airbus AP to a little cessna. Not sure that is what we want.

[Octal450]

There is a huge difference between ITAF and ITAF:GA. Furthermore, I have a KAP140 module which sits on top of ITAF:GA and makes the logic behave like a KAP140.

J

[gilbertohasnofb]

I am copying relevant comments from the duplicate issue #769 'Autopilot seems buggy' which we closed.

@wlbragg wrote:

Also for the autopilot, I'm unclear on its behavior. It appears to be 'off" by default until you hit the AP button, but then you can't turn off the digital display by hitting it again, how does that work?

I wrote:

About the AP, it indeed looks buggy... sometimes by clicking several times on the main arm/disarm button, I manage to get the display dark again, but not always.

@wlbragg then wrote:

One issue is

hit AP, hit it again, pull autopilot breaker, push autopilot breaker

pull autopilot breaker, wait till all AP digital display go black, push autopilot breaker

hit AP, pull autopilot breaker

In other words, the breaker is very strange either by design or not.

Another issue I have had "every time I use it" after flying for x-time it suddenly re-configures itself and put's me into a spin that is usually catastrophic.

[Octal450]

Update: Roll Axis completely refactored:

• New PID tuning
• Much more stable heading control
• NAV, APR, and REV new tuning, much more stable.
• Still using same inputs like @HHS81 said to preserve realism.

It has passed my autopilot torture test.

Working on the Pitch Axis now.

Kind Regards, Josh

[onox]

Does the NAV mode depend on the heading bug? In the AP when you click on NAV, "HDG" starts blinking and you need to set the heading bug for correct operation of NAV mode.

[Octal450]

Yes it does @onox

Kind Regards, Josh

[onox]

@wlbragg Could you ask (Torsten I think) on the mailing list what the purpose/state of new-navradio is? Should we switch from navradio to it?

[Octal450]

Update: Having some trouble with Pitch Axis, especially since elevator does not directly influence pressure rate (as it is calculated currently), therefore, the feedback loop has a rather long delay, making the pitch control not very good in bad weather and in my torture tests. Further, the derivative filter calculating pressure rate now is noisy, and rather unreliable.

I'm going through the Bendex-King manual to try and find some info on exactly what input it uses, maybe I can find a better way to get pressure rate, or something. If not, I'll just have to be careful and figure out something clever. (some anti-noise filters or something, and a carefully tuned control loop)

Kind Regards, Josh

[dany93]

Hi Joshua,

Are you meaning that it can it be due to the time filter? (lines 674 - 689)

    <flight_control name="FCS: c172">
        <channel name="Pitch">
            <kinematic name="fcs/elevator-cmd-norm-filtered">
                <input>fcs/elevator-cmd-norm</input>
                <traverse>
                    <setting>
                        <position>-1</position>
                        <time>0</time>
                    </setting>
                    <setting>
                        <position>1</position>
                        <time>0.15</time>
                    </setting>
                </traverse>
                <output>/sim/model/c172p/cockpit/yoke-elevator</output>
            </kinematic>

[Octal450]

Hi @dany93, Nope, that is all fine.

When you pull up on the yoke, it does not influence pressure rate (or vertical speed) directly. It influences pitch degree and pitch rate. Since pressure rate is not directly a result of pulling on the yoke (especially in poor weather), the control loop is very difficult to get right.

I have gotten it stable now, and after some testing, I will make the first prototype in my fork. Further, I added a filter to try and anti-noise the derivative filter.

Kind Regards, Josh

[onox]

If you have a noisy signal, you could try to route the signal through a low pass filter.

[Octal450]

I have a second order low pass filter on it currently, this seemed to get most of them gone.

Kind Regards, Josh

[HHS81]

https://www.pprune.org/archive/index.php/t-295247.html

According to this our KAP140 behaved like the real one. So now?