Airbus A320neo (A319,A320,A321)

[Figaro]

Well I know that, BUT if it's the reason stopping me from getting the neo FDMs to work for the -family, and I won't to fly the -family ASAP...

Cheers,
Sam.

[omega95]

Progress on FMGC and mCDU

• Basic DATA Section complete (POS MONITOR, GPS MONITOR, IRS MONITOR MENU (only MENU atm), A/C STATUS (shows aircraft, engine, active and second nav databases).
• INIT A Section in progress (by default, you have a choice of 4 european routes (merlion routes, but it works for anyone flying those routes ) atm, where you enter a company route id, or enter the departure and arrival and the mcdu searches for available routes in the database. If you don't have a company route for the flight, you can add the wps yourself. The Company waypoints include Waypoint IDs, Altitudes and Speeds, yep... the FMGC controls speeds automatically too Then, you can enter the cost index (doesn't do anything till I finish INIT B), cruise FL (replaces crz alts in company route) and temperature at that alt. Then the WINDS page in INIT A lets you either manually enter wind data or send a WIND REQUEST which gives you winds for different altitudes)
• INIT B Section Started (atm, it just lets you enter ZFWCG, ZFW, and TAXI TIME... I have to make it let you enter fuel blocks and predict fuel, time etc using cost index and the route. NOTE - Use this only if you're flying a company route available in the DB. But it's pretty easy to add your own routes to the database. Btw, INIT B is also called FUEL PRED)
• F-PLN page in progress (You can view the waypoints, speeds, time you'll be there at (min) and altitude. You can also scroll through pages and it shows F-PLN DISCONTINUITY where you're supposed to have terminal procedures and END OF F-PLN at the end and also you can change spd and alt values atm. What's left here is the most important part - Lateral Revision, where you insert/delete/add waypoints, and where you select DEPARTURE (LSK1 on departure airport), ARRIVAL and APPROACH (LSK6))

That's all for now. I still have to make the SEC F-PLN, MCDU MENU, ATC COMM, NAV RAD, DIR, PROG, PERF and ARPT sections. This might take a while... Basically, there's only 1 loop this time which is run only every 10 seconds are for simple stuff like reseting to start page if the cdu is turned off for longer than 10 seconds etc. Then the rest of the nasal are in functions activated on button presses on the mCDU.

EDIT : As for Terminal Procedures, It doesn't show that it's supposed to get on the main route, so we'll have a separate ap function for those.

[polly]

" needs commenting" in the sense that text comments in the .nas code must be preceded with a 'comment' symbol.
I can't find an 'fbw-stable' branch but the changes above seem to have been made to fbw-devel on Saturday causing segfaults in that branch.
The logic behind having the trimmable stabilizer continually resetting to zero is completely beyond me, if the THS is to stay at zero then why have it movable ? In normal flight, if the THS is always hunting to zero, what trims the craft ? I posted the relevant parts from pprune earlier, the story I've picked up from the many threads there dealing with the subject make sense to me.

[omega95]

" needs commenting" in the sense that text comments in the .nas code must be preceded with a 'comment' symbol.
I can't find an 'fbw-stable' branch but the changes above seem to have been made to fbw-devel on Saturday causing segfaults in that branch.
The logic behind having the trimmable stabilizer continually resetting to zero is completely beyond me, if the THS is to stay at zero then why have it movable ? In normal flight, if the THS is always hunting to zero, what trims the craft ? I posted the relevant parts from pprune earlier, the story I've picked up from the many threads there dealing with the subject make sense to me.

Umm, it doesn't ALWAYS reset to 0, it only resets to 0 when you're in flight mode and your stab control is turned off. You probably didn't see that cuz Jon scaped that right off the fbw.

And btw, the fbw is in the fbw-stable branch... (it's still not really stable cuz after the "re-organization", it's really messed up when you do a touch and go) And I'm working on the mCDU, FCU and FMGC on the flight branch... Now, I want the new flightdeck AND the fbw in this branch as the FMGC controls the plane by sending inputs to the FBW so all rules are always maintained. How do I get the fbw into this branch?

[omega95]

So, I got the basic Flightdeck into FlightGear, completed a basic FMGC and the FCU. The 2 APs do basically the same thing, but anyway, here're the modes in each : A-THR > SPD > (IAS/MACH) | LAT > HDG, LNAV, LOC | VER > GS, VNAV, ALT > (LVL-CH > VS/FPA) - Atm, everything on the FCU except METRIC ALT works

Here's a screenshot of the flightdeck so far...



Now, to the Flight Control Unit (FCU)



In this screenshot, the APs and A-THR are turned off but the autopilot is set to FMGC for all modes (SPD, LAT and VER) This means the FMGC gives in pre-set flight plan values into the ap. This is sorta like LNAV, VNAV and AUTO SPD CTRL. To toggle b/w FMGC and Manual Select, simply click on the respective knobs. To change the values, use the scroll bar on the mouse or the side/2-finger scroll on laptop track pads. (Btw, clicking on the VS Knob levels the plane off at the current alt, and clicking on EXPED makes your climb/descent rate to maximum possible value)



In this image, the speed is set (not engaged though) to 250 KIAS, and ALT to 10000 with 1800 VS climb rate. The Lateral Control is set to FMGC Mode though. Note that when the aircraft is climbing or descending, a 'LVLCH' Icon appears between ALT and VS/FPA.

Oh, and the black part of the ALT knob lets you select if 1 click increments/decrements the alt by 100 or 1000 ft.



In this image, all modes are set to manual select, and FPA is used instead of VS (toggle b/w VS and FPS using the round button in the center.



And here, AP1, A-THR, LOC and APPR are engaged. When LOC and APPR are NOT engaged, the AP follows the values you have on the FCU.


And I also modeled a new PFD using http://www.smartcockpit.com/data/pdfs/plane/airbus/A320/misc/A320_Flight_Deck_and_Systems_Briefing_For_Pilots.pdf



The SPD tape (right side of the SPD tape), includes stall tape and Vfe tapes which shows max flap extension speeds for the current config.

The ALT markings are in 1000s... like 0 , 5 , 10 etc. for 0, 5000, 10000 etc. You don't see any markings atm as 0 is hidden and 5 is above.

Dotted lines on the Artificial Horizon indicates limits which the fbw won't let you pass

Cheers, now to animate the PFD.

[Trez]

This is amazing..

Omega your recent works are brilliant. i have tested bicyus' FDM and it's amazing aswell i can't wait to finaly test this out i hope this will be included to 2.8. i like the 787 but i would like to work with a smaller aircraft i did research on the fbm though.

kind regards trez

[zakalawe]

omega, can you explain a bit about how the FMGC and CDU are structured internally? Scott and I are doing a ton of work to extend the core C++ data classes into Nasal, so that the internal view of the world is available to Nasal and can be manipulated. Especially things like loading / saving routes, setting speeds and altitudes on waypoints, and assigning procedures / runways during POS-INIT and flight.

I guess you're working on something that is pure Nasal at this point, does it interact with the route-manager at all, or simply ignore it?

Oh, and the Bravo now contains a lovely (non-Airbus) example of using the NavDisplay texture to show traffic, the route-path, and nearby data.

[Hooray]

Oh, and the Bravo now contains a lovely (non-Airbus) example of using the NavDisplay texture to show traffic, the route-path, and nearby data.

A while aog, I talked to Scott, our idea was to document the required steps and add a write-up to the wiki, so that others may have a look and use this for reference.

Scott and I are doing a ton of work to extend the core C++ data classes into Nasal, so that the internal view of the world is available to Nasal and can be manipulated.

Referring to Nasal API, deprecating features:

Looking through the Nasal work that you and Scott have done recently, I was planning to add the specifics of exposing objects via Nasal ghosts to the Nasal docs: http://wiki.flightgear.org/Howto:Extending_Nasal

That's something which isn't currently too well documented - apparently, most people aren't really aware of this option, or they don't know how to do this properly. And even Stuart's cloud interface was not implemented as a Nasal extension function (or even a ghost), but as an fgcommand().

Obviously, there are pros&cons here - but on the other hand, people are fairly unlikely to add clouds via command bindings via joystick or mouse clicks.

So there's a fairly clear line where certain approaches should be favored. Especially keeping in mind the marshaling overhead involved in repeatedly running fgcommands, which require their arguments to be provided in the form of SGPropertyNode data structures.

Also, looking at the NasalPositioned code, it's getting obvious that there are some things that could be further generalized and become a part of the "official" FG APIs, so that data structures and classes can be exposed to Nasal more easily. You have already done tons of work related to this, it just isn't currently accessible to other Nasal "users".

For instance, you already created a bunch of nifty helpers (such as stringToNasal() and a handful of others) which could probably be moved to SimGear or at least to the NasalSys class as a static method, so that these are available to all C++ code dealing with Nasal?

Also, you managed to come up with a pretty elegant scheme to make SGReferenced instances available to Nasal. It is my feeling that there's lots to be gained, just by moving this stuff to the NasalSys.cxx file and exposing such routines as generic helpers.

I mean it's obvious that you yourself probably don't need to take a look at those docs or the helpers anymore, but overall, I think it's a good idea to document such things better and add useful routines as generic helpers, rather than purpose-specific tools.

In addition to that, you brought up computing certain results lazily, that's another thing that could probably be useful in other contexts?

The bottom line being, most of your recent work on improving the Nasal interface happened to include a sizable number of useful general purpose helpers, which could easily (and probably should) be used by others.

Regarding the fgcommands() you are planning to phase out: It's probably worth keeping in mind that those are trivially accessible from XML space (command bindings), but also as telnet commands.

In the past, Curt has repeatedly opposed to removing such things for these reasons.

[omega95]

omega, can you explain a bit about how the FMGC and CDU are structured internally? Scott and I are doing a ton of work to extend the core C++ data classes into Nasal, so that the internal view of the world is available to Nasal and can be manipulated. Especially things like loading / saving routes, setting speeds and altitudes on waypoints, and assigning procedures / runways during POS-INIT and flight.

I guess you're working on something that is pure Nasal at this point, does it interact with the route-manager at all, or simply ignore it?

Oh, and the Bravo now contains a lovely (non-Airbus) example of using the NavDisplay texture to show traffic, the route-path, and nearby data.

Well, I am using the route manager to hold the active route.... (switches between F-PLN and SEC F-PLN) but then stuff like speed management etc. are done separately. It'd be pretty cool if the route manager lets you input and keep altitudes and speeds separate from the WP id, as whenever I change the altitude-ft prop for a wp and open the route manager, it resets to -9999. Atm, to use the FMGC properly without glitches, I can't open the route manager dialog. To fix these, I'd probably have to create a separate route manager sorta thing with nasal or the current Hard Coded RM could be improved to manage the routes. As for terminal procedures, I DON'T use the route manager. You have an F-PLN Discontinuity where you're using TPs (which you can select from respective LATeral REVision pages on the mCDU) and these wps, alts and speeds are managed separate from the RM.

And for the route manager, another idea would be to be able to choose how many different routes you can have in it. (For eg. here, you have the primary and secondary flight-plans. Atm, the FMGC copies the active flight-plan (managed separately) into the active route where you can edit it and then when you change to the other plan, it saves your changes into the plan.) It'd be better to be able to have the Route Manager to manage all of them instead of using nasal for it, wouldn't it?

[zakalawe]

Well, I am using the route manager to hold the active route.... (switches between F-PLN and SEC F-PLN) but then stuff like speed management etc. are done separately. It'd be pretty cool if the route manager lets you input and keep altitudes and speeds separate from the WP id, as whenever I change the altitude-ft prop for a wp and open the route manager, it resets to -9999. Atm, to use the FMGC properly without glitches, I can't open the route manager dialog. To fix these, I'd probably have to create a separate route manager sorta thing with nasal or the current Hard Coded RM could be improved to manage the routes. As for terminal procedures, I DON'T use the route manager. You have an F-PLN Discontinuity where you're using TPs (which you can select from respective LATeral REVision pages on the mCDU) and these wps, alts and speeds are managed separate from the RM.

And for the route manager, another idea would be to be able to choose how many different routes you can have in it. (For eg. here, you have the primary and secondary flight-plans. Atm, the FMGC copies the active flight-plan (managed separately) into the active route where you can edit it and then when you change to the other plan, it saves your changes into the plan.) It'd be better to be able to have the Route Manager to manage all of them instead of using nasal for it, wouldn't it?

Okay the good news is nearly all of this is being actively worked on and discussed with Scott. Especially the storing of speeds / altitudes, and handling terminal procedures sanely. And handling of multiple routes (flight plans) is coming too, so you can have active, secondary and save and load these. What I'm working out is how much to do in C++, and how much to leave for Nasal to help with. If you message me your email address, I'll CC you on any discussions with Scott about the API.

The only issue is if it reaches a 'good enough' state in time for 2.8 - I hope so.

[zakalawe]

A while aog, I talked to Scott, our idea was to document the required steps and add a write-up to the wiki, so that others may have a look and use this for reference.

Right - the Bravo is definitely the best example in FGDATA right now. There's some docs on the Wiki about using the NavDisplay, I'm happy to extend them, but since I already know how it works it's tricky. I would be delighted to work with someone as they attempt at integration - or do I need to create a skeleton first?

Looking through the Nasal work that you and Scott have done recently, I was planning to add the specifics of exposing objects via Nasal ghosts to the Nasal docs: http://wiki.flightgear.org/Howto:Extending_Nasal

That's something which isn't currently too well documented - apparently, most people aren't really aware of this option, or they don't know how to do this properly. And even Stuart's cloud interface was not implemented as a Nasal extension function (or even a ghost), but as an fgcommand().

The bottom line being, most of your recent work on improving the Nasal interface happened to include a sizable number of useful general purpose helpers, which could easily (and probably should) be used by others.

In general you are correct, but I'm still learning all this myself, especially what works best for Nasal authors. So while ultimately things can be generalised, I want to make small steps (and keep things self-contained), for now. Generalising is much easier with several examples to work with.

Regarding the fgcommands() you are planning to phase out: It's probably worth keeping in mind that those are trivially accessible from XML space (command bindings), but also as telnet commands.

I'm not planning to remove any FGcommands at all - only the legacy route-manager commands, which are a different thing entirely to FGcommands. Anyway, this discussion is much easier to have on the devel list

[omega95]

Just did 2 test flights with the A320neo... (MIA761 and MIA775, using CO_DB Routes MIALGWDUB1 and MIADUBLGW1) and found a couple of problems.

1. The elevator control PIDs (mainly AP (the one in the flight branch) and FBW) are REALLY unstable over 280 KIAS. Those need some major tweaking.. Polly?
2. For some reason, after we reach a waypoint, the Route Manager seems to de-activate. I could fix that by making my own route-manager (WP Transitions like the holding pattern on hte 787) but then this problem shouldn't be happening, so I think we should rather try to fix this.
3. FG SegFaulted THRICE! and I had to restart the flight. It shouldn't have anything to do with nasal, should it?

All files have been pushed to the flight branch.

[zakalawe]

2. For some reason, after we reach a waypoint, the Route Manager seems to de-activate. I could fix that by making my own route-manager (WP Transitions like the holding pattern on hte 787) but then this problem shouldn't be happening, so I think we should rather try to fix this.

Please don't make your own route-manager. The route-manager deactivates when the last waypoint is reached. Can you point me at the code you have which touches the route-manager? Though the API is going to improve really soon

3. FG SegFaulted THRICE! and I had to restart the flight. It shouldn't have anything to do with nasal, should it?

Depends when you last updated from Git - I introduced some crashes some days ago, and then in the last two days there were fixed.

[omega95]

Please don't make your own route-manager. The route-manager deactivates when the last waypoint is reached. Can you point me at the code you have which touches the route-manager? Though the API is going to improve really soon

Well, I haven't directly changed props from the RM, just added stuff like speed to each wp node. The only other communication with hte RM is with commands, like @JUMP:x, @INSERT5:WP@ALT etc.

And I thought of a method (TEMPORARY) to keep the RM going if it stops by keeping track of the current WP separately and making sure the RM is activated. I'll try this and get back.

Depends when you last updated from Git - I introduced some crashes some days ago, and then in the last two days there were fixed.

Hmm, right... I need to try those. I use git normally but checked out release/2.6.0 as I didn't want the whole fgdata. When I checked out sg and fg git, 2.6 fgdata gives me box clouds and untextured vegetation. Is there a way I can pull only certain directories from a git repo? Say, everything in FGData except aircraft?

[polly]

What to say: Bicyus reported excellent results with the configurations we worked on, those in the branch mentioned seem to be not those but some default configurations.
There is a dead band set up in the fbw nasal which tests for controls/flight/elevator less than some arbitrary number. The deadband is properly handled in joystick configuration ( it will differ with joystick hardware); the number chosen is far higher than the control input that, from the keyboard, can be seen to make an appreciable difference to pitch or vertical speed. In the fly by wire nasal that deadband is used to switch from the pitch rate elevator PID to pitch hold by elevator trim PID. The pitch rate elevator PID is capable of holding pitch within parts per million over hours when given a zero reference input; as long as it's reference signal is zero it's identical to a 'Hold' PID. Elevator trim is not correctly used for primary pitch control, it's movement rate would be much too slow.
The autopilot PID's feed their PID outputs back into the FBW PIDs by driving controls/flight. This tandem PID arrangement alone makes for difficult tuning, it's also not clear which fbw PID would be active: Pitch G-Load, Pitch Rate, Pitch Hold or Pitch Stable. In any case, it's easy to see that, with the deaband in fbw nasal together with the fact that autopilot drives back into flight/control inputs, PID control is continually flapping between the 'Stable' PID and one of the other fbw pitch controls as autopilot PID demands adjustments around that deadband threhold. At present I can see both Pitch Stable and Pitch V/S active during each autopilot frame.
Get rid of the deadband sensing and Pitch/Roll Stable PIDS, use the rate PIDs for all control including zero rate demands ( Roll / Pitch Hold). Have a single driver PID for each of elevator and ailerons, driving the /fdm/jsbsim/fcs/elevator-fbw-output and /fdm/jsbsim/fcs/aileron-fbw-output. Have both autopilot and fbw PIDs drive the reference signals to these two and let the autopilot and FBW controls be enabled / disabled via the properties already set up in nasal. That makes tuning much easier by optimising response to step demands to Pitch and Roll drivers, then, knowing output drivers are fast and stable, moving up the chain and adjusting Rate, Load, Heading, Alt, Nav stages individually in both fbw and autopilot chain.
Finally, all that's needed for the Horizontal Stabilizer is have it follow slowly in tandem with the elevator allowing the elevator to slowly ( about 30sec time constant) return to center in any trim condition. The documentation from BusDrivers doesn't say thats not how it works, it simply doesn't properly explain how it works. There's extensive explanation on the pprune links, alternatively consider how quickly pitch is controlled at cruise in turbulence, a massive slow moving THS just doesn't cut it.