Board index FlightGear Development Aircraft

Airbus A320neo (A319,A320,A321)

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: Airbus A320neo (A319,A320,A321)

Postby omega95 » Tue Apr 10, 2012 10:35 am

Finished (I think :wink: ) the Flight Control Unit Model. :D

Image

Now, I need to create switches and labels for the main panel.

As for the fly-by-wire, I found that the active PIDs should control the actual control surfaces (elevators/ailerons), that's where you take the stick input, convert to target g-force/roll-rate and then control the surface servos. But for the stablizer, we need to use the trimmers. You won't be able to control the trimmers manually during flight mode in NORMAL LAW. Anyway, yea... we could do this- when absolute value the stick input (pitch/roll) is less than say 0.05 (can't use something as small as 0.01 as some joysticks like mine don't exactly come that close to the center when you leave it), we can use the stabilize pids to maintain pitch and bank angle, while we disconnect load factor control pids. :)

have two different branches for different implementations of a FBW, you can then see the different approaches each developer takes


Well, that's what we did but then Jon thought that wasn't right as I was re-doing the FBW which he's already completed (?)

Ahh and what about the ALTERNATE, ABNORMAL ALTERNATE and MECHANICAL BACKUP LAWS? I don't see those implemented in the Airbus-fbw branch. :| But anyway, I'll leave the fbw to you now, I'll focus on the cockpit and required new instruments (mCDU, FCU etc.)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Airbus A320neo (A319,A320,A321)

Postby bicyus » Tue Apr 10, 2012 11:17 am

Omega95, is that Photo from a real Airbus? ;-) i think is Fucking amazing model.

On FBW, my branch is not even remotely completed, even your branch has gone further, so we could start working on your branch, once uptaded the FDM. just wanted to work together, not in different ways. ;-)

So Stability pid to the trimmer, and active pids to normal surfaces. what if we just clip, the active pid to 0 values in neutral joystick condition, and instead of deactivating, keep it active and help it with the stable PID on the trimmer, to maintain attitude. Does this make sense?

by the way, i would prefer to work together on the FBW if you like to.

So, going to your branch, or mine? but i think we need to focus on one.
User avatar
bicyus
 
Posts: 116
Joined: Fri Nov 25, 2011 3:11 pm
Location: Bilbao
Callsign: Bicyus
Version: 2.6
OS: Ubuntu Linux

Re: Airbus A320neo (A319,A320,A321)

Postby awexome » Tue Apr 10, 2012 12:01 pm

Hi,
omega95 wrote in Tue Apr 10, 2012 6:05 am:In this and many other pictures, the cockpit base color is sorta blue-grey (more to the grey end) rather than the blue used in hte current A320 cockpits...

I second to 'pick' the colors from the original cockpit. However, one can avoid a 'double-take' by being careful about 'light-bounce' and low-lighting in the images, and cross-checking with similar image.It will be interesting to see comparative pixes of the 'real' and the model :idea:

awexome
When one thinks, one looks up to the skies.
I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>
awexome
 
Posts: 111
Joined: Sat Jan 21, 2012 11:24 am
Location: GMT
Callsign: SHA7
Version: GIT
OS: GNU

Re: Airbus A320neo (A319,A320,A321)

Postby zakalawe » Tue Apr 10, 2012 12:16 pm

Just to add something to your mix - ScottH is doing great work on the A380 NavDisplay, using my NavDisplay code which was included in 2.6. If you speak to him, you should be able to get the ND showing TCAS, waypoints, the route path, VORs and airports. I would hope the symbol definitions and textures you need can be borrowed from the A380 and converted, otherwise I have the 777 versions (which are definitely different!) or they're in the main 777 repo.

Of course, since you will be among the first people to use the NavDisplay instrument, expect some bugs - but you can also request more features. I know the Boeing ND best, but Scott has been trying to keep me aware of the Airbus side.

And, great work guys.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Airbus A320neo (A319,A320,A321)

Postby awexome » Tue Apr 10, 2012 12:40 pm

Hi,

zakalawe wrote in Tue Apr 10, 2012 12:16 pm:... ScottH is doing great work on the A380 NavDisplay, using my NavDisplay code which was included in 2.6. If you speak to him, you should be able to get the ND showing TCAS, waypoints, the route path, VORs and airports. I would hope the symbol definitions and textures you need can be borrowed from the A380...


Absotively ;) The A380 and 777 series projects have so much resources that are well coded, modern and easily re-usable for the Airbus A3xx. In particular, the ND is likely the most functional in FGFS (my opinion), and the 'managed' and 'selected' flight control systems offer competitive functionality. I iterate Zakalawe' words and add that some potential problems being encountered now, and likely so later, already have a solution; in the A380 and 777 projects for example.

awexome.
When one thinks, one looks up to the skies.
I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>
awexome
 
Posts: 111
Joined: Sat Jan 21, 2012 11:24 am
Location: GMT
Callsign: SHA7
Version: GIT
OS: GNU

Re: Airbus A320neo (A319,A320,A321)

Postby Hooray » Tue Apr 10, 2012 1:04 pm

Yes, the A380 contains tons of well-written Nasal code, which is also written in a "true OOP"-style, many other OOP snippets around here (including most 3rd party repositories, but also the base package) are unfortunately not yet properly coded, so that it wouldn't be possible to instantiate multiple objects using the same class/hash template (think multiple FMCs, CDUs, FBWs), due to weird/misunderstood coding patterns.

Scott's code is written such that it's already pretty generic, also most functions are really pretty compact, too. There are tons of helper functions in Scott's code that should be moved to the Nasal library directory eventually, such as all the math/geo helpers - those will be useful for all related project, and it should help make Scott's code more compact, by moving certain stuff to the Nasal directory (math.nas, geo.nas).
The only thing that needs fixing in my opinion is ensuring that function definitions make use of the var keyword, because a bunch of them, don't.

Overall, it would be a very promising route to generalize and "librarify" the various Nasal FMS approaches and make them available to all airliners/jets, while leveraging zakalawe's ND system for the low level work.

But that would obviously require that the C++ code becomes even more configurable, so that no manufacturer-specific assumptions are hard-coded anymore, i.e. ideally in a "CSS" fashion, so that appearance and behavior can be largely customized by parametrizing the ND subsystem using XML and properties, not just for static resources like textures or strings, but also for dynamic features, by registering Nasal callbacks to be called by the ND code to implement certain behavior.

Unfortunately, Scott's apparently still waiting for his merge request to be reviewed and committed: http://gitorious.org/fg/flightgear/merge_requests/14
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: Airbus A320neo (A319,A320,A321)

Postby awexome » Tue Apr 10, 2012 1:14 pm

Hi,

Nicely spotted ... but it seems like I am ahead fo you ;)
Hooray wrote in Tue Apr 10, 2012 1:04 pm:There are tons of helper functions in Scott's code that should be moved to the Nasal library directory eventually, such as all the math/geo helpers - those will be useful for all related project, and it should help make Scott's code more compact, by moving certain stuff to the Nasal directory (math.nas, geo.nas).
The only thing that needs fixing in my opinion is ensuring that function definitions make use of the var keyword, because a bunch of them, don't.


I have been compiling the said library of generic functions which I have already included the WCA. I shall be posting a 'poster' ;) of the library shortly. It will be very helpful if scottH will review/'double-check' the library for consistency (re-checks may be trouble some, but they save me headaches later on).

By the way, the 'AlgoScore' has loads of generic functions (maths , etc) that are likely useful to Nasal developers, and learners lime me ;)

Update -- generic functions
I am extending my thoughts on the library of generic functions. I could port these sub-modules to C++ code and shove em in the flightgear base somewhere -- now thats the question, where and which folder. Initially, I am considering using the tree for incoming and outgoing data processing. Any takers ...

awexome.
Last edited by awexome on Tue Apr 10, 2012 2:16 pm, edited 1 time in total.
When one thinks, one looks up to the skies.
I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>
awexome
 
Posts: 111
Joined: Sat Jan 21, 2012 11:24 am
Location: GMT
Callsign: SHA7
Version: GIT
OS: GNU

Re: Airbus A320neo (A319,A320,A321)

Postby omega95 » Tue Apr 10, 2012 1:23 pm

bicyus wrote in Tue Apr 10, 2012 11:17 am:So Stability pid to the trimmer, and active pids to normal surfaces. what if we just clip, the active pid to 0 values in neutral joystick condition, and instead of deactivating, keep it active and help it with the stable PID on the trimmer, to maintain attitude. Does this make sense?


Pretty much ok, but during the transition, if we set active surface positions to 0 then won't there be a sudden jerk? I was thinking we could let the active pid surface positions be the same (unchanged) from transition time till you move the side stick again. AirbusDriver.net didn't have any mention of this, do you have any idea of what really happens? I would think if the positions are somewhere near the center (say -0.2 to 0.2), then we can leave them unchanged and then use the trimmers to stabilize them.. and then when you move the stick again, the trimmers go back to the center and active stuff could play around again.

Alright, so what exactly's the progress of the Airbus-fbw branch? :wink:
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Airbus A320neo (A319,A320,A321)

Postby scotth1 » Tue Apr 10, 2012 1:59 pm

It's getting a bit late in the evening here, but a quick note, yes I think a library is an excellent idea, I've been collecting bits and pieces, but to put them in a nice little library would be great, I'd be very happy to review and help build such a beasty...

Secondly; Nara that modelling is looking pretty darn spiffy (which is a colloquialism for very good) these aircraft are going to look very nice, and I think the skill of everyone here should bring them up to a very high level.

I just had a quick look at some of my Nasal code, I'm thinking CabinPressureSystem.xml, afs_cp.nas, AirbusFMS.nas, fmsDB.nas, fmsWP.nas, fmsTP.nas and fmsTransition.nas should all be reusable with some work. The bit that was written first and is quite messy is airbus_fg.nas and system.nas and the bit that is specific to the A380 is mcdu.nas. So there should be an opportunity to enhance the code to work on more airbus models.


S.
scotth1
 
Posts: 231
Joined: Thu Jan 01, 2009 3:27 am
Location: Australia
Callsign: VH-SHA
Version: Git next
OS: Linux 3.4.11

Re: Airbus A320neo (A319,A320,A321)

Postby awexome » Tue Apr 10, 2012 2:23 pm

Hi,

you seem to be ahead of me on this one :)

scotth1 wrote in Tue Apr 10, 2012 1:59 pm:I just had a quick look at some of my Nasal code, I'm thinking CabinPressureSystem.xml, afs_cp.nas, AirbusFMS.nas, fmsDB.nas, fmsWP.nas, fmsTP.nas and fmsTransition.nas should all be reusable with some work. The bit that was written first and is quite messy is airbus_fg.nas and system.nas and the bit that is specific to the A380 is mcdu.nas. So there should be an opportunity to enhance the code to work on more airbus models.


However, I have been doing minor cleaning, so to say, to the 'system.nas', and continue to investigate the following [copilot.nas, tertain-map.nas, v-speeds.nas, systems.nas].

May I ask this: is the team happy with more use of 'hash' boxes for common data objects? E.g., doors, vspeeds, etc.

awexome
When one thinks, one looks up to the skies.
I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>
awexome
 
Posts: 111
Joined: Sat Jan 21, 2012 11:24 am
Location: GMT
Callsign: SHA7
Version: GIT
OS: GNU

Re: Airbus A320neo (A319,A320,A321)

Postby zakalawe » Tue Apr 10, 2012 2:24 pm

Hooray wrote in Tue Apr 10, 2012 1:04 pm:while leveraging zakalawe's ND system for the low level work.

But that would obviously require that the C++ code becomes even more configurable, so that no manufacturer-specific assumptions are hard-coded anymore, i.e. ideally in a "CSS" fashion, so that appearance and behavior can be largely customized by parametrizing the ND subsystem using XML and properties, not just for static resources like textures or strings, but also for dynamic features, by registering Nasal callbacks to be called by the ND code to implement certain behavior.


There's two issues being combined here - FMSs can and should be done in Nasal, with low-level help from the GPS/route-manager code - which I'm happy to extend. The 'NavDisplay' code in 2.6 is already fully generic - using XML and some clever PNGs, it should be able to approximate most moving-map type displays - Honeywell/Boeing, Airbus, a basic Garmin (maybe not a G1000), or various military displays. Right now.

Of course there may be bugs, but all the C++ is there - what's needed is some better examples of the XML and PNGs required, which I'm trying to put together.

Now, for FMS / CDU behaviour, that's a much bigger, and harder question, and the area where Scott has done a ton of work - and there does need to be a sane discussion (on the mailing list) about how all those pieces get fitted together to avoid too much duplication.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Airbus A320neo (A319,A320,A321)

Postby polly » Tue Apr 10, 2012 2:42 pm

User avatar
polly
 
Posts: 455
Joined: Thu Nov 04, 2010 2:45 pm

Re: Airbus A320neo (A319,A320,A321)

Postby Hooray » Tue Apr 10, 2012 2:44 pm

I am extending my thoughts on the library of generic functions. I could port these sub-modules to C++ code and shove em in the flightgear base somewhere -- now thats the question, where and which folder. Initially, I am considering using the tree for incoming and outgoing data processing. Any takers ...


I am not sure what exactly you mean here "port sub modules to C++" is most likely referring to porting Nasal helpers to core C/C++ code that can be called from Nasal, right?

If that's the case, this is documented here: http://wiki.flightgear.org/Howto:Extending_Nasal

As you can see, there's a well-defined API to implement new scripting hooks, no need for unnecessary property tree uses.

Such "fat bindings" are usually added to $FG_SRC/Scripting, i.e. see: http://gitorious.org/fg/flightgear/blob ... xx#line785

This is where FG-specific extension functions are added and made available to Nasal scripts.

The "really low level" Nasal library calls (non FG specific) are part of SimGear, in simgear/nasal/lib.c: http://gitorious.org/fg/simgear/blobs/n ... .c#line563

Note, regarding all those math/geo helpers: The SimGear code base already has tons of C++ code available for this, often heavily optimized already - so I wouldn't bother porting the Nasal code to C++ in such cases, but merely expose the SimGear helpers to Nasal via wrappers (i.e. Nasal extension functions).

However, for the time being, I wouldn't even look at C++ actually: C++ patches, especially Nasal-related ones, have a tendency of not getting committed or even reviewed for months (or even years). Thus, I would suggest to focus on generalizing and factoring out components from aircraft-specific scripting folders to the shared Nasal directory in $FG_ROOT/Nasal.

Historically, such patches have a much better probability of getting reviewed and committed, because there are more people able to review, discuss, improve and commit stuff to the base package (including Nasal code), than to the core source code repository.

Basically, by keeping stuff in the base package ($FG_ROOT), there's less of a bottleneck, because you'd not necessarily depend on core developers reviewing and committing your code.
Last edited by Hooray on Tue Apr 10, 2012 6:50 pm, edited 1 time in total.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11377
Joined: Tue Mar 25, 2008 8:40 am

Request For Review of Generic Nasal code [RFR - Nasal]

Postby awexome » Tue Apr 10, 2012 3:21 pm

Splendid.
Hooray wrote in Tue Apr 10, 2012 2:44 pm:
... added to $FG_SRC/Scripting ... This is where FG-specific extension functions are added and made available to Nasal scripts. ... focus on generalizing and factoring out components from aircraft-specific scripting folders to the shared Nasal directory in $FG_ROOT/Nasal. ... there are more people able to review, discuss, improve and commit stuff to the base package (including Nasal code).

This saves me a whole load of time and effort. Now, I need to take a dump -- of code ;)

UPDATE:
Please extend your 'clickery' to the RFR - Nasal code review 'Hot Spot' @ http://www.flightgear.org/forums/viewtopic.php?f=6&t=15952&p=155046#p155046

awexome.
When one thinks, one looks up to the skies.
I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>
awexome
 
Posts: 111
Joined: Sat Jan 21, 2012 11:24 am
Location: GMT
Callsign: SHA7
Version: GIT
OS: GNU

Re: Airbus A320neo (A319,A320,A321)

Postby omega95 » Tue Apr 10, 2012 4:51 pm

Image

Some more labeling... Now, I'd better get started on the pedestal and the mCDU models. :)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: YandexBot [Bot] and 5 guests