Board index FlightGear Development Aircraft

IDG A32X Development Archive - Closed

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

Re: IDG A32X Development

Postby Octal450 » Sun Dec 31, 2017 1:50 pm

I based my version off the latest version of the Canvas ND by artix in his A330-200, but I had to make major systems to get it to talk to my FMGS rather than his/omegas. This ND was already alot changed from the version in FGData, and much better working, but it was also specific for that FMGS. So, I had to rework it to mine, and I also improved the appearance, and functionality of many components. The MapStructure side has quite a few bugs, like flashing lines appearing, and some things are drawn wrong. Once I get a better understanding of MapStructure, I need to go back and fix that all. Plus, it is still inaccurate in many areas, and I want to fix that.

Are you now going to go through every component and suggest I look through generic versions? If so, please don't. You are wasting your time and yours.

In other news, the PFD now has Speed Trend arrows to the PFD (finally), and they work very similar to the real ones.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Hooray » Sun Dec 31, 2017 1:57 pm

it0uchpods wrote in Sun Dec 31, 2017 1:50 pm:Are you now going to go through every component and suggest I look through generic versions? If so, please don't. You are wasting your time and yours.


nope, far from that - I looked at your comments, wondering why you needed to touch code that was supposed to use delegates (aka callbacks that you pass to the back-end to customize all sorts of things, including not just styling/apperance but also the underlying logic itself. Next, I looked at the repository link in your signature to look at some of your code that I should be a little familiar with (let's say, the Nasal/Canvas bits), which is when I felt you might consider it helpful to see concrete advice posted, e.g. the suggestion to look at artix work, because he understhood how to use delegates, which is why I pointed out his work, to hopefully prevent you from wasting any of your time without realizing it)

No offense intended or taken though ...

Anyway, happy new year to you !
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

Re: IDG A32X Development

Postby Octal450 » Sun Dec 31, 2017 2:41 pm

Makes sense, I am definitely far from the best Canvas programmer, so I will try to improve it, (especially all those getprops), but I don't feel changing out the whole framework is needed.

Just wasn't sure the intention. Thanks, non taken or intended from me either, happy new year,

Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Octal450 » Mon Jan 01, 2018 1:42 am

Thanks everyone for your awesome support in this project thoughout 2017. There are alot of awesome things I am working on and I can't wait to get them into your hands during 2018. (hint hint, FMGS)

Happy new year, and hope 2018 will become the year of the Airbus V1.0 ;)

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby vaipe » Mon Jan 01, 2018 8:06 am

I got exited about Flightgear again for a while when I bumped into this IDG A32X project. Looks and feels awesome so thanks about this.

I configured a second PC to work as a slave on LAN and it works (PARK BRK handle in A32X is turning on/off on slave PC when it is turned on/off on master pc). I was thinking to make slave PC as an PFD/ND screen. So while studying protocols etc. in FG to send stuff over LAN if learned that I have to transfer more properties over LAN to slave.

So my question... Is it doable? Or how (insanely?) long protocol files will be?
vaipe
 
Posts: 12
Joined: Thu Dec 18, 2014 12:15 pm
Location: Finland
Version: 2017.3.1
OS: Ubuntu 17.10

Re: IDG A32X Development

Postby Octal450 » Mon Jan 01, 2018 2:20 pm

Hi @vaipe,
I am not sure. You may want to talk with merspieler who is working on the dual control using emesary. I do know the PFD and ND have each probably hundreds of properties, it will be a lot to transfer.

Glad you are enjoying!!!

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Hooray » Mon Jan 01, 2018 2:29 pm

I was thinking to make slave PC as an PFD/ND screen. So while studying protocols etc. in FG to send stuff over LAN if learned that I have to transfer more properties over LAN to slave.

it will involve not just properties, replicating MFD stuff like the ND involves also non-property state - thus, sooner or later you will have to use Nasal coding to get there.
That is by the way one of the reasons why I suggested to look at Richard's MFD framework, because it's designed with the IPC use-case in mind, i.e. using his Emesary framework.
Which is not to say that things will just "magically" work, but that it is much more straightforward to actually implement this.
Then again, at least the ND can be replicated and sync'ed to a separate fgfs instance with a bit of coding - alternatively, streaming the whole thing to another process may be simpler though, e.g. consider the FGQCanvas stuff - or just apply ThomasS' patches and render any Canvas MFD by streaming it a browser (which is what I'd recommend to use if you are not into coding, especially given that FGQCanvas is basically a re-implementation of the built-in Canvas system).
However, be aware that "streaming" a Canvas to another process obviously has potential round-trip/latency issues.

http://wiki.flightgear.org/Read_canvas_image_by_HTTP
Image
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

Re: IDG A32X Development

Postby legoboyvdlp » Mon Jan 01, 2018 3:16 pm

Considering there are latency issues with any dual control there shouldn't be too much bother about that.
User avatar
legoboyvdlp
 
Posts: 7789
Joined: Sat Jul 26, 2014 1:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: IDG A32X Development

Postby Octal450 » Mon Jan 01, 2018 3:20 pm

Well, we are not sure if that will be needed, IIRC, the plan would be to run the systems on both sides, but have them share data with each other, therefore, the NDs, would be driven by that users FG session, not the other one. @merspieler knows the most about this.

@jonititan was able to get my Canvas ECAM to inserted into an HTML, so probably the same concept would be applied for you cause. We do not plan to support this out-of-the-box, however. (The real best solution might be to do how FSX does, and allow the Canvas popups to leave the border of the FlightGear window.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Octal450 » Mon Jan 01, 2018 3:34 pm

Now only one AP will work at a time, unless you are in APPR armed, or active, then both APs will be allowed. In addition, I fixed a bug with the VS/FPA syncing and armed modes turning off whenever an AP or FD is turned on or off.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Hooray » Mon Jan 01, 2018 3:55 pm

legoboyvdlp wrote in Mon Jan 01, 2018 3:16 pm:Considering there are latency issues with any dual control there shouldn't be too much bother about that.

the streaming solution won't involve any coding - however, it will involve patching & rebuilding fgfs from source.
Other than that, it should work fine in any local (=LAN) setting, i.e. where latencies are not an issue.
Besides, this will work just fine for any Canvas based display - that is, assuming that the computer is sufficiently powerful to actually stream the created image to another process.
It's not exactly elegant from a technical standpoint, but there is not much needed in terms of deployment - i.e. as long as you through the right hardware at this, it will work just fine, even for people wanting to display the Canvas on a mobile phone or tablet computer.
With a bit of C++/OSG expertise, it should be also possible to optimize this a little more - and maybe integrate it better with the Canvas system, e.g. by coming up with a dedicated "streaming placement", i.e. a Canvas placement that would register any Canvas as a stream that is created and processed in a background thread - which is actually a long-standing idea: http://wiki.flightgear.org/Canvas_Devel ... ter_Vision

The real best solution might be to do how FSX does, and allow the Canvas popups to leave the border of the FlightGear window.

That, too, would be relatively straightforward - it will primary require someone familiar with the CameraGroup stuff to make this available as a distinct Canvas placement.
This isn't exactly rocket science either. Icecode GL was actually once contemplating to do this. And originally, TheTom and James were discussing this on the devel list back in 2012, too: http://wiki.flightgear.org/Canvas_Devel ... ve_Windows

If you are interested in any of this, please do file a corresponding feature request, so that we can gather feedback (and maybe even patches) there.

Also, if you know how to patch & rebuild fgfs from source (ideally familiar with git & C++/OSG), feel free to get in touch for additional pointers.

For CameraGroup pointers, see:

http://wiki.flightgear.org/The_FlightGe ... ameraGroup
http://wiki.flightgear.org/Howto:CameraGroup_talks
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

Re: IDG A32X Development

Postby Octal450 » Mon Jan 01, 2018 4:16 pm

HI Hooray,
While that does make sense, streaming will have latency, so I still think running the display on the FO's machine as well is the best option at the moment. (Especially, PFD) But the biggest concern for latency is the sending the FlyByWire inputs, so that is why I think both sides should run the simulation, and the pilot in command's version will sync position, parameters, and such to he pilot not flying's version.

I do have some C++ experience, but I haven't done much of it in 2 years. I also don't have the time to invest into learning the internals of FGFS and such, so I think it would be better to add a feature request and have people who have the time/experience implement it.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Hooray » Mon Jan 01, 2018 4:48 pm

as I said already, "the best" solution depends entirely on the circumstances - I specifically mentioned latencies as the most likely issue here.
sync'ing (replicating) a Canvas MFD to another fgfs instance would also be possible, I actually once did that in the early Canvas days, at the property-level.

These days, it would be better to use Richard's MFD/Emesary framework for this - because that would mean that only relevant state changes would need to be propagated (selectively), rather than full 1:1: Canvas primitives at the property level.

To some extend, the ND code is prepared for this use-case, by using the notion of "driver hashes", which is to say that these are the equivalent of "data providers" (think properties, but also Nasal APIs, e.g. to query terrain elevation) - thus, at the mere cost of replacing the driver hash, all higher-level code would automatically use a different "data provider", which means that even other fgfs instances could feed the corresponding data in a master/slave fashion - with each slaved fgfs client still running a local copy of the instrument/display logics (avionics), just not sync'ing low-level state with the main/master instance, but only relevant state changes are propagated.

However, that makes really only sense to explore once you understand the concepts involved here, and how there are overlapping requirements between the MP/dual-control mechanism and the fgtape/instant replay (flight recorder) system, and how this relates to sync'ing/replicating certain state to another process (fgfs instance, or 3rd party Canvas implementation in the form of FGQCanvas).

There's really no way to tackle this properly without having a strong coding background, particularly in the Nasal/Canvas department and the fgfs/networking component (MP).

Thus, if you aren't eager to duplicate work unnecessarily, Richard's MFD/Emesary approach is the most promising option for the time being - but that requires a different coding approach, too.

Feel free to file a feature request - but like I said, we do already have various bits for this in place (in the form of several patches), it's just that the response so far has been rather trepid, so we didn't exactly go out of our way to integrate any of this with upstream fgfs.

Anyway, for the time being, the streaming option provides the most bang for the buck for people able to patch/rebuild from source, without requiring any coding experience.
If you want to do this properly, without any of this being specific to any particular instrument/aircraft or effort, there's no way around using an IPC mechanism and formalizing the synchronization/replication requirements, analogous to how MP/dual-control and the flight recorder subsystems are already doing that.

Which is to say, I would not expend even just a single second thinking about it, let alone working on it, if this sounds like some fancy gibberish, because then you're really just wasting your time, and will find it hugely frustrating should someone come up with a more proper solution (say, using Richard's MFD/Emesary integration).

Originally, we were wanting to make this master/slave use-case a first class concept of the whole Canvas system, but then RL took over, and other things were more important, technical background (includinig suggested approach at the sc::Element level) at: http://wiki.flightgear.org/Canvas_Devel ... FlightGear

PS: In a "perfect world", FlightGear would have a working HLA/RTI or CIGI implementation ...
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

Re: IDG A32X Development

Postby Octal450 » Mon Jan 01, 2018 5:41 pm

In an ideal situation, yes, that would be a good option. But I think you and I are talking about different things, I am speaking about dual control. I do not want Emesary to act on the Canvas itself, as the lag in updates may cause the displays to display incorrect/strange information. Instead, the Systems on the Master side and Slave side would talk to each other, for example:

Slave user pushes HYD YELLOW ELEC ON on overhead
Slave sends button click to Master
Slave Hydraulic system powers up yellow electric pump
Master Hydraulic system powers up yellow electric pump
Slave Lower ECAM Hydraulic pages reads Slave Yellow PSI rising, and displays accordingly.
Master Lower ECAM Hydraulic pages reads Master Yellow PSI rising, and displays accordingly.
or something like that

That way, the systems just talk to each other via Emesary, and some modifacations, but the instruments will never know that dual control is active. I believe that is the best way to proceed.

Where is this feature request? Maybe I am blind, but I do not find it. Is it just the mailing list?

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby merspieler » Tue Jan 02, 2018 9:44 am

For the dual control... @it0uchpods and I agreed, that it makes more sense, to implement it near v1 when no major changes are expected anymore.
If everything is going against you, keep in mind that airplanes take off against the wind, not with it.
merspieler
 
Posts: 738
Joined: Thu Oct 26, 2017 10:43 am
Location: Wish to be in YBCS
Callsign: JST935. ORI1711
IRC name: merspieler
Version: next
OS: Debian Bullseye

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: AhrefsBot [Bot], Octal450 and 6 guests