c172p

c172p copied to clipboard

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

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

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

Ok.

#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.

:+1:

Thanks, @onox

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

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.

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...

@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.

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.

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 :(

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.

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:

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.

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.

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.

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.

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.

but the autopilot is quite lacking

Can you elaborate?

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

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.

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

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

@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?

@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

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

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.

@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

@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....