Board index FlightGear Development Aircraft Cockpit development

zkv1000 reborn

Discussion about creating 2d and 3d cockpits.

zkv1000 reborn

Postby zakharov » Mon Apr 17, 2017 7:38 pm

Hello world,

after the zkv500, went the time of the zkv1000 which has stopped because unmaintainable (only XML) and lack of time, nowadays after a long absence far from FG, the zkv1000 is borning again now using Canvas.

This instrument is intended to easily equip any kind of aircraft and cockpits, and to provide PFD and/or MFD displays (including ND). It should also be able to integrate an already designed cockpit with glasses ready (not tested yet, so not available). It is quite 100% inspired from the Garmin Primus 1000 by following its documentation as near as it is interesting.

The zkv1000 is usable, in heavy development, was previously announced on the French forum two weeks ago, and I'm now proud to enlarge its audience here, if anyone is interested by.

It is not yet published on git(hub|lab) but I surely can do a
Code: Select all
git remote add --mirror
if someone wants to participate. There are two branches, I work on a daily basis on the dev branch, and merge master branch with it once a week or so.

The new zkv1000 has only around two monthes of existence, and was never successful in its ND tries on the MFD display. I've followed the Canvas documentation as far as I was able to, first tried a the Canvas Map Structure but it wasn't that convincing because I couldn't make the navaids and other airports fill the displayed space correctly, following the backgrouded map, neither to make the airports look like they should be in documentation. So I decided to give a try to the ND provided in the Extra500/Avidyne Entegra 9. I'm aware this way is not the recommended one, and that including code from another aircraft is not recommended too, moreover the code styles are very different.

Anyway, be a bit foolish :) (this is what I said to myself). Here we go, the code is imported, slightly refactored, purged of unuseful parts in my case, and now it is working like a charm.

Like a charm ? :oops: Maybe I omit to say that no Navaid or Airport is displayed on the dedicated display... And I really don't understand why... canvas visibiliity stuff ? I've tried to set all of elements visible whatever they are in range or not, but no more luck on this ? setGeoPosition not correct then ? I'm very interested in that direction, but as positioned.findWithinRange finds the correct answers... but this is the way I try to continue searching.

If there are some Extra500/AvidyneEntegra9 code experts around they may have an envy to look at the code. They may find the reason(s) of the non-displaing items :).

Continuing to investigate...

Hope my English didn't make someone feel sick, and you'll like the zkv1000 :)

@+
zakh
Callsign: zakh Immat: F-ZAKH
System: Intel i3 2GHz (hyperthreaded), 4Go RAM, Nvidia GeForce GT 330M (256MB VRAM), Debian unstable
FG 2016.4 from Debian packages + next (compiled)
in dev: zkv1000 PFD/MFD
zakharov
 
Posts: 12
Joined: Sun Jul 13, 2008 10:31 am

Re: zkv1000 reborn

Postby D-ECHO » Mon Apr 17, 2017 7:41 pm

Very very good news to hear the ZKV1000 is coming again! I have always enjoyed the zkv1000 (XML version) in several aircraft, thank you for this and even more for the canvas update!!!
User avatar
D-ECHO
 
Posts: 1537
Joined: Sat May 09, 2015 12:31 pm

Re: zkv1000 reborn

Postby zakharov » Tue Apr 18, 2017 1:37 pm

Hello,

D-ECHO wrote:Very very good news to hear the ZKV1000 is coming again!

Nice to hear that the zkv1000 has supporters ;)

The ND display AvidyneEntegra9-style is now functionnal, even if the integration of the code is a real mess from my point of view. Anyway it seems to work, enough to push everything in master.

It is not yet possible to change the range/zoom-level, as the tiles and ND are linked but don't use the same zoom system. There is certainly a way to get the link computed, but for now it is quite an esoteric hack to get it works. Anyway there isn't any function to change the zoom/range from the interface.

Next steps: INSET map and MFD settings pages

@+
zakh
(edit: fix quote bbcode)
Callsign: zakh Immat: F-ZAKH
System: Intel i3 2GHz (hyperthreaded), 4Go RAM, Nvidia GeForce GT 330M (256MB VRAM), Debian unstable
FG 2016.4 from Debian packages + next (compiled)
in dev: zkv1000 PFD/MFD
zakharov
 
Posts: 12
Joined: Sun Jul 13, 2008 10:31 am

Re: zkv1000 reborn

Postby D-ECHO » Tue Apr 18, 2017 2:47 pm

Very nice!
Couldn't resist to install it into the P2010 for testing and it is really very good!
Only one thing I noticed during installing:
On my PC fg-aircraft was not set so I'd propose replacing (zkv1000.nas, line 175)
Code: Select all
    data.zkv1000_dir = getprop('/sim/fg-aircraft') ~ '/Instruments-3d/zkv1000/';

by
Code: Select all
if(getprop('/sim/fg-aircraft')!=nil) {
        data.zkv1000_dir =  getprop('/sim/fg-aircraft') ~ '/Instruments-3d/zkv1000/'
    }else{
        data.zkv1000_dir =  getprop('/sim/fg-root') ~ '/Aircraft/Instruments-3d/zkv1000/';
    }

Regards and thanks for this great instrument!
User avatar
D-ECHO
 
Posts: 1537
Joined: Sat May 09, 2015 12:31 pm

Re: zkv1000 reborn

Postby zakharov » Tue Apr 18, 2017 4:17 pm

Hello D-ECHO,

thanks to you for your testing and feedback ! Your suggest is commited.

Is P2010 the Tecnam-P2010 we can find in FGaddon ?

Best regards
zakh
Callsign: zakh Immat: F-ZAKH
System: Intel i3 2GHz (hyperthreaded), 4Go RAM, Nvidia GeForce GT 330M (256MB VRAM), Debian unstable
FG 2016.4 from Debian packages + next (compiled)
in dev: zkv1000 PFD/MFD
zakharov
 
Posts: 12
Joined: Sun Jul 13, 2008 10:31 am

Re: zkv1000 reborn

Postby zakharov » Tue Apr 18, 2017 4:31 pm

I reply to myself, yes this is the Tecnam-P2010, including a partial zkv1000 XML version in it :)

Very partial though, I've kept an old and complete version, but I guess buggy because of last changes abandonned. But I think it is good to completly left the old zkv1000 in the past.

@+
zakh
Callsign: zakh Immat: F-ZAKH
System: Intel i3 2GHz (hyperthreaded), 4Go RAM, Nvidia GeForce GT 330M (256MB VRAM), Debian unstable
FG 2016.4 from Debian packages + next (compiled)
in dev: zkv1000 PFD/MFD
zakharov
 
Posts: 12
Joined: Sun Jul 13, 2008 10:31 am

Re: zkv1000 reborn

Postby zakharov » Thu May 11, 2017 2:02 pm

Hello,

just a quick update about the progress. The dev was focused on the MFD part, especially the maps, and now, sitting with tiles background layer, there are layers for navaids (using Avidyne Entegra 9 icons and map-building process), and route layer integrated with the standard route-manager. OBS mode isn't done yet, but LEG is working fine.

Moreover maps are now zoomable and can rotate (on MFD, press MENU button to access MFD maps options, outer FMS knob to select the entry, inner FMS button to chosse the value, ENT button to apply the selected change, MENU or CLR button to closse the window).

Currently zoom level are related to tiles Z level, from 7 to 13, not by range but it covers from around 2nm to around 250nm, defaults to 10 (~30nm). Available rotations are north up, track up, heading up and if a route is loaded and activated, desired track up.

PFD Inset map is also available but without zooming or rotating for now as the associated menu isn't implemented.

Next steps are maps decluttering, topo maps and the availability to include zkv1000 inside the file tree of an aircraft (instead of actual Aircraft/Instruments-3d which I would like to be the recommended way), and off course I would like to progress in documentation.

Note: the route layer is only on dev git branch as it is not completly finished.

Enjoy :)

zakh
Callsign: zakh Immat: F-ZAKH
System: Intel i3 2GHz (hyperthreaded), 4Go RAM, Nvidia GeForce GT 330M (256MB VRAM), Debian unstable
FG 2016.4 from Debian packages + next (compiled)
in dev: zkv1000 PFD/MFD
zakharov
 
Posts: 12
Joined: Sun Jul 13, 2008 10:31 am

Re: zkv1000 reborn

Postby www2 » Tue May 23, 2017 2:02 am

zakh

Is an idea to split the wigged of the EIS Display to separate file and combine with nasal?
Beside this there are two different layouts of the MFD one with the standard size EIS Display and an wider version of the EIS Display (looks like this one is only use with the GDU1500 display).
www2
 
Posts: 260
Joined: Thu Apr 16, 2009 1:58 pm

Re: zkv1000 reborn

Postby Hooray » Sun Jul 02, 2017 6:11 pm

I haven't yet looked at any of the code in question, so bear with me - but speaking in general, any such efforts would greatly benefit from looking at Richard's MFD framework, and possibly even at Emesary - especially when it comes to multi-instance use of MFDs in multiplayer and/or dual-control setups, or even just FSWeekend/LinuxTag-style setups.

Overall, we do meanwhile have quite a bit of MFD related experience when it comes to the Canvas system, and how using Nasal is problematic for a variety of reasons - thus, it would seem like a good idea to document your journey with others interested in modeling MFDs - for starters, posting some screenshots and code snippets/URLs to the relevant files would seem like a good idea.

I don't know if you have any experience with C++, but some of the core folks have repeatedly raised the issue that MFD logic purely residing in Nasal space is problematic when it comes to multi-instance setups or setups interfacing with real hardware (see the CDU/MCDU talks) - thus, conceptually it would actually make sense to at least encapsulate anything involving state management (buttons, switches, knobs) so that these are represented in the form of property tree hierarchies, which could then also be supported by Phi, Qt5 (or other UIs), but also by external hardware (see James' and Stuart's comments in the archives).

Note that these are lessons learnt from implementing the so called "MapStructure" framework by refactoring Gijs' original NavDisplay/ND code to become fully MVC-based, and the degree of code reuse we were able to accomplish that way (unlike other MFD efforts like the extra500/Avidyne Entegra R9).

No matter what you end up doing, it would seem like a good idea to share some of your screenshots and code snippets with people interested in your efforts.
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: 11349
Joined: Tue Mar 25, 2008 8:40 am

Re: zkv1000 reborn

Postby stuart » Tue Jul 04, 2017 8:04 pm

Hi,

As an FYI, there's an interesting discussion that was started by David Megginson regarding implementing G1000-type systems on the mailing list:

https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAKor_TGugT%2Be%3DQhdNBqWq3Pn%2BCEq6iLZsgaB7HmiU%2BBoDK0vxQ%40mail.gmail.com/#msg35924395

I think there would be a great deal of interest in developing the zkv1000 into a G1000.

Best regards,

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: zkv1000 reborn

Postby Hooray » Wed Jul 05, 2017 8:47 pm

Well, I only skimmed over the postings made on the devel list.

But overall, I strongly agree with Thorsten and Richard that from a Canvas standpoint there really isn't too much missing to pull that off.

However, David, Heiko and others concerned about the work ahead (and the resulting performance) are also correct - and that is backed up by a number of Canvas-related contributions that either "suck" from a performance standpoint or due to the way the code is structured, i.e. implementations that are insufficiently generic, and those introducing too much Nasal code for things that should be handled by core code.

With that being said, as long as there is core developer support (as suggested and offered by Stuart), none of this would be difficult to tackle. However, as things are standing, we've seen little support (or even just feedback) regarding Canvas related feature requests from core developers, even if those feature requests included C++ patches.

As has been said already on the devel list, the lowest hanging fruit would be using an external simulator/emulator and hooking that up to fgfs - and even in that scenario, the Canvas system would be able to serve as the integration mechanism, because we could fetch a texture from an external process and stream that "live" - we do have various snippets of code doing something along those lines. And that is in fact also how the Garmin GNS430/530 simulators are hooked to FSX/X-Plane - the "trainer" (freely available) is executed separately, the image transcoded and injected into the simulator, with relevant events dispatched to the trainer, and data structures exchanged between the sim and and the trainer executables - and that is actually extensively covered in the FG devel list archives, as well as in the forum archives.

Anyway, like Thorsten and Richard said, the MFD framework that Richard created could (and arguably should) probably be used as the foundation for modeling more complex avionics. However, based on refactoring the NavDisplay framework, we should really consider making this a first class concept at the Canvas level, e.g. by sub-classing Canvas::Element and Canvas::Group to directly implement elements for wrapping MFD related functionality for things like "screens", "pages", "page elements" but also "buttons", "switches" and "modes".

That in and of itself would help make things much more intuitive for people less experienced with Nasal/Canvas internals - while Thorsten and Richard are correct in saying that it's feasible to create such avionics using the Canvas system, it really does require tons of expertise/experience doing this sort of coding - otherwise, Heiko and others are absolutely correct in saying that we do have too many examples of Canvas-based avionics that may look super nice, but that are using naive approaches to implement the corresponding functonality - just like Thorsten suggested previously, and obviously naive implementations written in Nasal are obviously slower than naive C++ code.

Thus, my suggestion would be not to argue with folks are basically saying the same thing by pointing out how many examples of poorly-structured Nasal/Canvas code we already have that really eat up performance, but instead look at what people are really saying, and find a way to "have our cake and eat it".

Like Stuart said, it would seem best to identify what is missing in terms of building blocks that would allow people to come up with sophisticated avionics, ideally using C++ hooks instead of scripting space workarounds.

Apart from that, it also seems that many participants in that discussion are unaware of all the functionality we've got already - such as the WXR/wxradar MapStructure layer that Thorsten briefly mentioned - and it using the MapStructure MVC layer, it is also available to any avoinics using that backend, such as any of the Boeing/Airbus airliners using Gijs' ND - in fact, once you disable "Advanced Weather", you will see that in action:

Image

Besides, there's also other experimental work to implement a WXR controller for other data sources, such as omega95's work shown below:

Image

Overall, I am not convinced that there's too much missing to implement arbitrarily complex avionics on top of the Canvas system and the route manager - however, I am also not convinced that this should be "just done" using tons of Nasal hacks - what is really needed is a team of folks to determine missing functionality, i.e. anything requiring custom Nasal code, that would be best provided as an API - or in the case of performance-critical code, re-implemented at the Canvas::Element level. Otherwise, we're just going to see more and more problematic Canvas/Nasal based contributions that will complicate the lives of people wanting to see better fgfs performance, and less Nasal running in the main loop.

Like I said previously, we can certainly accomplish that, but that would require a willingness among core developers and Canvas contributors to actually work out the details to make that happen, rather than continue working in different camps, without much/any concern for the other camp (school of thought).

What's been happening since TheTom stopped maintaining the Canvas system is that we've grown a backlog of feature requests, and C++ patches, that never got reviewed or integrated - and most Canvas developers simply go on doing their things without much concern for what core developers consider "best practices" obviously, so that -depending on whom you're asking- Canvas and Nasal are definitely causing more problems than they're solving right now ... which is unfortunate.

For the time being however, Thorsten is right - one of the lowest hanging fruits is optimizing property tree access, as in 1) avoiding it whenever possible and 2) making it much faster. The former can be accomplished by encoding update semantics at the Canvas::Element level, so that the element knows when to update an element (per frame, on write, on update, on change, per timer etc) - that alone, would help us get rid of tons of Nasal code. And the latter (making property I/O faster) would basically entail reviewing api.nas to get rid of calls ending up in props.nas, which is to say that we should probably consider porting props.nas to use native C++ code (using cppbind), or at least provide an alternate/faster scheme to avoid props.nas optionally.

These two changes would be fairly self-contained, and they would not involve much in terms of OSG/rendering expertise - it's mainly about understanding the property tree and making sure that update semantics are exposed at the property level, while reducing unnecessary Nasal use. And obviously, providing an alternative to props.nas would also benefit other non-Canvas use-cases where the property tree could be the bottleneck (I think Thorsten mentioned a few AW related instances ?).

Looking at the way we have come to use the Canvas system, and how it adds to the problems that Nasal is known to contribute to, it is kinda unfortunate to see how many useful C++ data structures and helpers are available in SimGear, that the Canvas system cannot use currently - as in having to use various more or less complex Nasal callbacks to implement support for animating Canvas elements using listeners and timers, instead of being able to use Torsten's property rules and/or James's state machine code (both implemented in C++) to do these things.

As far as I am concerned I don't think there's much/anything missing to implement fairly sophisticated avionics using the Canvas and the route manager, but I really doubt that we want to proceed "as is", without having endorsement from the core developer community to actually review opportunities to get rid of some of the more common, and more problematic, instances where Nasal scripting must currently be used to actually add functionality to a MFD - there really is tons of performance sacrificed that way currently, because people are unaware of what's going on behind the scenes (e.g. props.nas being used as the back-end by api.nas), which goes to show why people like Thorsten and Richard are able to come up with sophisticated Canvas based contributions, whereas most other contributors (including a few core developers) tend to use inefficient coding patterns.



In summary, I am not sure if many Canvas developers are even aware of the currently ongoing discussion - because there seems to be a certain disparity between those using the forum and those using the devel list - but maybe, for the sake of the effort, it would be a good idea to come up with a wiki page to actually document what we know, add open questions and volunteers interested in helping with some of the work that lies ahead ?

Like I said, there's at least a handful of Canvas related C++ patches floating around here, including work like Gijs' C++ patch that got added to the hard-coded map dialog, but that never got integrated with the Canvas::Map projection handling code, so that certain performance issues persist, despite the fact that they've been solved years ago - this is obviously unfortunate and unnecessary.


Equally, the route manager/autopilot subsystems are increasingly ignored by aircraft developers, because feature requests were not honored, so that aircraft developers tend to re-implement such systems in Nasal space - which also adds a bunch of problems to the work that lies ahead.

Therefore, if anybody around here is serious about all this, it would seem like an excellent idea to interface between the forum and the devel list, so that we can come up with a wiki page covering what we can do right now, what may be missing, and what may need to be optimized.

Personally, based on my own familiarity with the Nasal and Canvas subsystems, as well as the MFD framework, I am not convinced that we should simply proceed, without providing encapsulated building blocks that can be easily wrapped/re-implemented using C++ level helpers, so that we can easily get rid of bottlenecks, without having to review/rewrite tons of Nasal/Canvas code.
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: 11349
Joined: Tue Mar 25, 2008 8:40 am

Re: zkv1000 reborn

Postby stuart » Thu Jul 06, 2017 8:05 am

Hi Hooray,

That's really useful analysis, and I very much appreciate it. Thanks.

At this point my familiarity with the Canvas code and where the bottlenecks are is very limited.

I'm about to go on holiday for the rest of July, but when I return it sounds like a very useful starting point would be to optimize the property access and become more familiar with the Canvas C++ code so that I can help bridge the cap between core and Canvas client developers. I think James has some thoughts on the Canvas C++, so I'll want to coordinate with him as well.

Best regards,

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: zkv1000 reborn

Postby Hooray » Thu Jul 06, 2017 2:47 pm

I agree that it would be a good idea to coordinate any of your efforts with James, especially because he's the last person (apart from TheTom) to make significant changes to the Canvas system, but also because he mentioned on various ocassions that he had plans to improve the Canvas APIs, especially path handling.

Anyway, to understand what Thorsten was referring to in the context of property I/O being generally the bottleneck when it comes to updating many Canvas elements, I suggest to check out the following wiki page: http://wiki.flightgear.org/Howto:Canvas ... nchmarking

Regarding the idea to re-implement a subset of props.nas in C++ space and expose that to Nasal/Canvas, it would seem like a good idea to use TheTom's cppbind framework (James also used the same framework to expose his work to Canvas space): http://wiki.flightgear.org/Nasal/CppBind

Concerning the structure of the Canvas system itself, I suggest to check out the following wiki article, which provides a rough overview,and which also includes working C++ snippets to extend the system: http://wiki.flightgear.org/Canvas_Development

The details of creating/adding and integrating support for new elements are covered at: http://wiki.flightgear.org/Canvas_Devel ... ew_Element

There also is another article with C++ patches adding experimental new elements, including one to load/display PDF documents using existing OSG machinery - which is to say that charts or PDFs could be shown inside fgfs, as part of an MFD/EFB: http://wiki.flightgear.org/Canvas_Sandbox#CanvasPDF


However, no matter what you end up doing, please don't add new functionality in a "breaking" way, but make it strictly opt-in, so that aircraft developers have to explicitly enable new code paths, otherwise tons of folks will be yelling at us ...
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: 11349
Joined: Tue Mar 25, 2008 8:40 am

Re: zkv1000 reborn

Postby iamzac » Wed Nov 29, 2017 12:53 pm

Thank you for the new zkv1000!

Here it is on the updated Diamond-DA42:

Image

Image
iamzac
 
Posts: 96
Joined: Fri Nov 07, 2014 7:52 am
OS: Windows / Kubuntu


Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 1 guest