Garmin 196 GPS option - Githubissues

gilbertohasnofb commented 9 years ago

We could add the Garmin 196 GPS to our dashboard as an option (default off, to be activated via the menu). This GPS model is already located in fgdata, so it's very easy to add it to our plane. For my tests, I add the following lines to Models/c172p.xml:

<model>
    <path>Aircraft/Instruments-3d/garmin196/garmin196.xml</path>
    <offsets>
            <x-m>-0.4</x-m>
            <y-m>0.16</y-m>
            <z-m>0.205</z-m>
            <heading-deg>-12.0</heading-deg>
    </offsets>
</model>

And the following to the c172p-set.xml inside the <nasal> block:

<garmin196>
    <file>Aircraft/Instruments-3d/garmin196/garmin196.nas</file>
</garmin196>

This is the result, which is quite nice IMO:

The good thing about directing to this GPS inside fgdata instead of copying it to our project is that any updates would also be automatically applied to our plane. For instance, I created a better texture for it but I couldn't make it work, and I reported it to the original creator.

onox commented 9 years ago

@gilbertohasnofb Could you perhaps upload those images directly to github? :open_mouth: (Via the link at the bottom of the text input box) Then they are directly visible in the issue.

Nice feature for 3.8 btw :smile:

gilbertohasnofb commented 9 years ago

Could you perhaps upload those images directly to github?

Well, I left them in the same server as before (postimage) but added them directly to the issue. Next time I add them directly, ok?

Nice feature for 3.8 btw

Yes, but there is lots to be fixed on this GPS. I already wrote the original author and I am seeing if he is interested in fixing a couple of bugs I found. I tried creating a more realistic dark texture but I can't add it to the model (his instructions are not working), but more importantly it seems the map is always slightly off position sometimes, but that changes according to the airport (e.g., when at SBRJ, the GPS displays the airport as being 0.15 nm south, when at SBSP it shows the airport some 0.3 nm North, and so on). Let's see how this goes, I will post an update here if I get any answers.

gilbertohasnofb commented 9 years ago

Hooray informed me that the original Garmin 196 project is apparently not being developed any longer, but someone was porting it to Canvas: http://wiki.flightgear.org/Garmin_GPSMap_196

I will keep this post updated if I receive any answers.

gilbertohasnofb commented 9 years ago

From Hooray:

The 196 isn't too complex - so as long as you have 1-2 guys familiar with basic coding concepts (maybe even Nasal/Canvas), completing the existing prototype shouldn't be too difficult or time-consuming. All the mapping stuff (as shown in the screen shot above) is already fully functional and working, because it was done by Gijs, Philosopher and others involved in unrelated MFD efforts, and because the MapStructure framework is sufficiently generic to still be useful. Making the other pages/features functional will mainly involve editing/creating Inkscape SVG files and animating those via Nasal functions (timers/listeners). For page handling, one of your coders should understand the concept of a state machine and the benefits of introducing one - which is where/why the GPSMap196 failed basically - even though I did provide corresponding patches, those were never committed by F-JJTH. You may still be able to find them by searching the forum/wiki though.

wkitty42 commented 9 years ago

i can hardly wait for a fully glass cockpit to be fitted... i know there are some out there in RL as i've seen photos of them... almost leads to wonder about possible weight changes... they probably won't be enough to worry about, though...

gilbertohasnofb commented 9 years ago

Yes, the glass cockpit will be nice, but it will involve so much work (we will have to remodel and re-texturize the whole panel I think). But regardless of that, I think having a realistic looking GPS (particularly an old-school one such as the 196) would be great for the regular panel :smile:

gilbertohasnofb commented 9 years ago

The Canvas version of the GPS does not turn on on my computer, and I also felt a drop in performance (but this has to be tested, this is merely an impression). Is anyone here familiar with Canvas? Maybe @onox, @Juanvvc or @wlbragg?

onox commented 9 years ago

I did some work on that OSM map on the wiki. Added zooming with scroll wheel and dragging. But the dragging is not consistent yet across zoom levels and there's no double buffering yet.

gilbertohasnofb commented 9 years ago

Alternatively, we could also get the non-Canvas 196 and try to develop it ourselves. It's quite functional so far, besides the texture problem and the major bug of the position being sightly off.

onox commented 9 years ago

I haven't looked at the instrument yet, currently fixing bugs for 3.6 :smile:

gilbertohasnofb commented 9 years ago

I understand that, I am simply brainstorming here, as well as taking notes so I don't forget anything. Right now I have very few things to do in our project (I am basically only testing your PRs and trying to contribute with one or two discussions), so I have plenty of time to mess around with this type of things :wink:

tigert commented 9 years ago

The 196 is very fitting option to an older 172 like ours. There are also panel-mounts available that have a clip for easy attachment and removal of the unit.

http://www.airportpilotshop.com/Air-Gizmo-Panel-Mount-for-Garmin-196-296-396-496-p/airgizmo-496.htm http://www.vicdrive.co.uk/JOHNB1.JPG

It would be nice to do an avionics upgrade option for the Cessna at some point, with maybe a Garmin GNS or GTN set, but developing those moving map gps'es and color display navigators is quite time consuming if you want to model them completely, and I think it is also important to have a complete "steam gauges" and dials & needles set as well, since part of the fun in radio navigation is to learn to model the airspace inside your head, while following a VOR needle and DME readout. The moving map does add a lot of safety and situational awareness, but there is something very different in plain "raw data" radio navigation.

This old website seems to be online still: http://www.navfltsm.addr.com/ - very nicely written tutorial into that world.

I do agree we should try to create shared units, instruments and systems because all small GA planes would benefit from this kind of development and these units, and all of them share the same kind of units in the real life as well.

gilbertohasnofb commented 9 years ago

@tigert

The 196 is very fitting option to an older 172 like ours

Yes, I also love the look of them together with the model P :smile:

There are also panel-mounts available

I would rather have the GPS in some sort of mount like this:

http://www.gpscity.com/gallery_pics/pic01220-1.jpg https://www.rammount.com/images/ipadminimount4.jpg

This way, we don't need to modify the cockpit for it and the GPS would be an option for the default model, to be activated via the menu. So people who don't want to use it or don't want to lose performance can simply ignore it, and their panel won't have a hole where the GPS would be.

developing those moving map gps'es and color display navigators is quite time consuming

Indeed. The good thing about these 196 is that they were at least basically developed, so they can be at least a basic simulation of how these work. Right now I am using them only to orient myself, for instance to see where are the airports, high peaks, VOR and NDBs, etc., and for that the 196 looks pretty good.

tigert commented 9 years ago

Yeah, the dash mount is just fine too.

http://www.finnairflyingclub.com/flk/asp/images/CAY_panel_1024.jpg

This is a fellow club's 172 with the smaller garmin handheld. The 196 is also very nice, it can have a flight plan with waypoints etc. I need to look into it again :)

This is a good way to revive the project!

gilbertohasnofb commented 9 years ago

@tigert That mount in the centre of the dashboard looks great too!

Great to see that a lot of you are interested on this idea, so after the release of FG 3.6 we can really work on it! It would be so much nicer to have an implementation of a RL GPS instead of using FG's map and route manager :)

legoboyvdlp commented 9 years ago

One question here,does the GPS affect the autopilot IRL that is will it be able to do nav mode with gps instead of vor? Would it be possible to see this if yes?

tigert commented 9 years ago

Not the gpsmap196.

For autopilot guidance you need a certified gps and an approved installation.

It might be "accidentally" controlling the autopilot in flightgear, depending on how it is implemented, but in reality there are restrictions on what you can connect to the autopilot system (flight controls) or to the primary instruments.

gilbertohasnofb commented 9 years ago

Hooray on the performance hit I felt when using the Canvas version of this GPS:

yeah, the original code written by F-JJTH is using a few inefficient techniques, such as the settimer(0) call to constantly update things (unnecessarily), I did actually post patches addressing/fixing this, but F-JJTH never committed those, so you will have to check the corresponding thread.

gilbertohasnofb commented 9 years ago

So guys, is anyone really up to develop this GPS or how do you feel about it? The thing is Hooray is offering some help but first we need someone with Nasal and Canvas knowledge and also he would like some help with the wiki for this work. Please see his message at: http://forum.flightgear.org/viewtopic.php?f=14&t=15433&p=253470#p253455

So do any of you feel like embracing this? Maybe @onox or @wlbragg feel like and have the knowledge? As much as I would like to have a GPS I don't have any Nasal or Canvas skills myself, but as always I am willing to help with whatever I can.

onox commented 9 years ago

Any existing Nasal code that I can use?

gilbertohasnofb commented 9 years ago

I think you'd have to ask Hooray. Since I know you are not in the forum, I'd happily forward any messages to him.

onox commented 9 years ago

I'll create bug-392 with the non-Canvas variant.

gilbertohasnofb commented 9 years ago

Okay. Let me know if I can help with this. I personally had crashes all the time with the Canvas version, but the non-Canvas was awfully unreliable and the maps weren't precise enough. Hooray argued against developing the non-Canvas GPS for some reasons in that thread, but I have no horse in this race and no idea if that would be a good decision or not. I'm clueless as always :stuck_out_tongue:

wlbragg commented 9 years ago

Is this a GPS addon?

https://upload.wikimedia.org/wikipedia/commons/6/67/Cockpit_of_cessna_172e_g-asss_of_1964_arp.jpg

onox commented 9 years ago

Nasal runtime error: undefined symbol: ligne
  at Aircraft/Instruments-3d/garmin196/garmin196.nas, line 2872

onox commented 9 years ago

I can get a nice list of nearby VOR's, NDB's, and fixes :smiley:. Entering airport codes in the route tab is slow though. It affects the autopilot.

gilbertohasnofb commented 9 years ago

I don't get that error, @onox. Did you install the gps with the same snippets I posted in the first post here or are you doing something different?

onox commented 9 years ago

GPS instruments appears to be working mostly. Just slow sometimes.

gilbertohasnofb commented 9 years ago

I created a new branch called simply gps to play around with this issue, okay?

gilbertohasnofb commented 9 years ago

I wrote ages ago:

it seems the map is always slightly off position sometimes, but that changes according to the airport (e.g., when at SBRJ, the GPS displays the airport as being 0.15 nm south, when at SBSP it shows the airport some 0.3 nm North, and so on).

I found the cause of that bug: the reason behind it is that I am a complete idiot! Obviously we are always 0.x nm from the airport when starting at a runway, since the airport GPS position will never coincide with every single end of every single runway! :blush: Though I feel the initial value of the zoom being always at 0.125 nm is really strange, which is what caused my confusion. I don't know how it works in RL, but something like 1nm of zoom looks more realistic to me.

Also, I don't feel the GPS is slow at all. Where did you felt that, @onox? I remember that in the past it used to be slow, but today it is working super well and it's very responsive!

I made some modifications on the branch gps and I also want to report a couple of bugs:

the north arrow does NOT point to the North, it's always stuck in the top left corner:
sometimes the elements in the screen rotated 180 degrees for a brief time, like few hundreds of a second only (so an airport in the NW would show at SE), but I still didn't have the chance to try to narrow this down and see if it's reproducible or not. Let's just keep the eyes opened for it though.
some of the GPS screens are displayed slightly offset (one pixel or so) but the effect is very bad: try zooming in the GPS, click MENU then use the arrows up and down. Notice how the screen moves around.
in the already mentioned branch I moved this garmin to /Models/Interior/Panel/garmin196 so it's now local, and so we can freely modify it
I added a better texture for it (replacing the original coque.png)
I created a GUI check box for adding the GPS and made it's state savable (default = off)
the antenna now starts in the upper position

Question: does the GPS affect performance if it's not visible? Is its Nasal code loaded regardless of the model, for instance?

gilbertohasnofb commented 9 years ago

Question no. 2: when turning on the GPS, the default zoom range is always 0.125 nm, which seems awfully zoomed in. Does anyone know if the real model have a default value (and if so, what is it) or does save the last used value? I found its manual online but I can't find this answer there, and I also can't find any video of someone turning on a Garmin 196 or equivalent...

onox commented 9 years ago

@gilbertohasnofb Is that the Canvas variant? I had already created a non-Canvas variant in branch bug-392.

gilbertohasnofb commented 9 years ago

@onox no, that's the non-Canvas variant. Sorry but I missed the message where you mentioned the branch bug-392. As far as I can see, the only thing you did in that branch was to add the 3D model to the plane (using the FGDATA path). Given that I made it local and already did some few improvements (texture, GUI check button, antenna position), do you think we could simply delete bug-392 and use the branch gps for this work? Alternatively, I can of course add these modifications to the branch you created and delete the newest one. What do you think?

gilbertohasnofb commented 9 years ago

Sorry for the mess by the way :confounded:

onox commented 9 years ago

Alternatively, I can of course add these modifications to the branch you created and delete the newest one.

@gilbertohasnofb I think it's better to do that. In the bug-392 we simply (re-)use the stuff in FGDATA instead of duplicating it. So I suggest to add your fixes to that branch and delete your gps branch. In case there are any bugs in the Aircraft/Instruments-3d/garmin196/ code, then you simply need to patch it and send the patches to the mailing list. That way other people who use the garmin196 can benefit from it as well.

gilbertohasnofb commented 9 years ago

@onox

In case there are any bugs in the Aircraft/Instruments-3d/garmin196/ code, then you simply need to patch it and send the patches to the mailing list. That way other people who use the garmin196 can benefit from it as well.

But that will give us much less room to improve things! Why can't we work on improving the GPS here and after the work is done we send a patch to FGDATA, just like we did with the environment sounds? It would be a nightmare to have to send a patch to FGDATA and wait for it to be tested and committed every time we changed that wind.wav sound, let alone something as complex as a GPS...

And then in case we will make the GPS local while working on it, are you sure you don't want me to simply delete branch bug-392 and keepgps as it's much less work? Else I will have to merge them and the result will be identical to the current gps, just with a different name.

gilbertohasnofb commented 9 years ago

For instance, the garmin196 in FGDATA can't use different textures for some reason, so if I am experimenting with them I'd need to first fix that, then send a patch of my texture every time I want to see it in the sim. Kind of a nightmarish scenario, isn't it?

onox commented 9 years ago

If you really want to work on improving the GPS, we should go with the Canvas variant.

gilbertohasnofb commented 9 years ago

Well, I don't think I am the person for that as I know nothing about Canvas (and even the non-Canvas is way beyond my programming capacities). But I am trying the best I can to work on it, started with textures, plan to have a look on that buggy North indication. But I'd hope that anyone else would jump in the boat for this as I don't think I can go far by myself :smile:

onox commented 9 years ago

We might be able to use Nasal/canvas/MFD_Generic.nas.

onox commented 9 years ago

Btw, what do you mean with "different textures"?

onox commented 9 years ago

Are you talking about the hardware itself (the device) or the screen?

gilbertohasnofb commented 9 years ago

I created a darker texture (for the device) that is much closer to the RL model. The one in FGDATA is grey, the real life is plastic black. So what I am saying is that it's easier to have a local copy to play around with it to improve, and then send a patch afterwards when we have something stable or that we are satisfied with. Makes sense?

gilbertohasnofb commented 9 years ago

And I also plan to take a look on the screens that move slightly when going up and down in the menu, I have to see if that's a texture, 3D model or programming problem.

onox commented 9 years ago

Let's do the following:

onox commented 9 years ago

Use bug-392. Move the old non-canvas device a bit to the right so I can compare it.

Then add a new .ac file containing just your patched device. Make sure to remove all non-visible objects in that .ac file. Make sure that the screen itself is just a flat rectangle.

I'll add the canvas stuff then.

onox commented 9 years ago

Is that ok with you?

gilbertohasnofb commented 9 years ago

Sure it is! I will try to modify the .ac file myself, but please know that I am useless on Blender... If I don't manage myself I will shout for help, ok?

(so this means that we will use only the 3D model of the garmin196 and that we plan to program the GPS itself from scratch?)

gilbertohasnofb commented 9 years ago

I will try to do this still tonight

onox commented 9 years ago

Yes. That's why you should move the old non-canvas to the right so I can reproduce the behavior in the new canvas variant.

c172p-team / c172p

Garmin 196 GPS option #392