opengc-devel Mailing List for Open-source Glass Cockpit (OpenGC) (Page 3)
Status: Pre-Alpha
Brought to you by:
madmartigan
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(22) |
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(12) |
Oct
(31) |
Nov
(6) |
Dec
(2) |
2003 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(18) |
Jun
|
Jul
|
Aug
(7) |
Sep
(56) |
Oct
(23) |
Nov
(7) |
Dec
(7) |
2004 |
Jan
(2) |
Feb
(2) |
Mar
(7) |
Apr
(26) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(6) |
Nov
(5) |
Dec
|
2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Damion S. <da...@op...> - 2004-03-23 16:06:56
|
Hi, Is your question about the OpenGC build process or about including the=20= OpenGC libraries in another visual studio project after they are built?=20= Please let me know and I'll try and help out. Cheers, -Damion- On Mar 18, 2004, at 8:01 AM, yoan.rousseau wrote: > >>> Hi! >>> I have a project! And i think that your OpenGC project can help me=20= >>> but=85 >>> >>> My project is: >>> -include some glass cockpit in a Visual c++ 6.0 App (Cdialog,Sdi or=20= >>> Mdi I don=92t no) >>> >>> After downloading the openGC, and windows dll... I clicked on=20 >>> OpenGC.EXE from >>> openGC main folder and it works! >>> >>> So I download the source,I use Cmake after Visual c++ 6.0 , add=20 >>> library directory in my project but it works but there =91s lot of=20= >>> =93unresolved external symbol=94 errors=85missing lib I think. >>> >>> But my question is: Is it possible to include some opengc code in=20 >>> Visual project (MFC) ? >>> Source I need etc=85 >>> >>> I don=92t Want a complete cockpit 3 or 5 main glass cockpit is = enough. >>> >>> PS:my English is bad?I=92m French! ;) >>> >>> Bye & thks!! >>> yoan |
From: Besters <be...@di...> - 2004-03-22 10:38:14
|
Hi I recently downloaded your Program and it is very helpfull. I just want = to know if you are planning to upgrade the X-plane support to later = versions or if there is a way that I can do it myself. I tried it in = X-plane 730 and it works but not all the info comes through (heading, = alt and that) I played around in X-plane's data box but I cannot seem to = get it going Thanks for the help Jaco Bester |
From: yoan.rousseau <yoa...@vo...> - 2004-03-18 13:01:36
|
> > Hi! > > I have a project! And i think that your OpenGC project can help me but= =85 > >=20 > > My project is: > > -include some glass cockpit in a Visual c++ 6.0 App (Cdialog,Sdi or Mdi= I don=92t no) > >=20 > > After downloading the openGC, and windows dll... I clicked on OpenGC.EX= E from=20 > > openGC main folder and it works! > >=20 > > So I download the source,I use Cmake after Visual c++ 6.0 , add library= directory in my project but it works but there =91s lot of =93unresolved e= xternal symbol=94 errors=85missing lib I think. > >=20 > > But my question is: Is it possible to include some opengc code in Visua= l project (MFC) ? > > Source I need etc=85 > >=20 > > I don=92t Want a complete cockpit 3 or 5 main glass cockpit is enough. > >=20 > > PS:my English is bad?I=92m French! ;) > >=20 > > Bye & thks!! > > yoan ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr=20 |
From: Wendell T. <we...@ad...> - 2004-03-05 19:44:25
|
On my system (Red Hat Linux release 8.0 (Psyche)), using opengcnew from cvs, in the file FindPlib.cmake, I needed to add to the "FIND_PATH(Plib_INCLUDE_DIR" section, the line /usr/include/plib (I think this is where stock plib wants to put itself). I also needed to change, in the "FIND_LIBRARY(Plib_SL_LIBRARY" line, sl plib sl to sl plibsl These changes allowed the OpenGC to compile. So, where do I look to find out how to use the gauges listed in the Source/Gauges/Examples/*.cpp area? Do I just copy one that I like up to the Gauges area and re-make? Thanks, Wendell |
From: Damion S. <da...@op...> - 2004-03-04 19:15:06
|
Hi everyone, A quick note that the OpenGC CVS server will be offline from approximately 5 pm Monday the 8th through noon Tuesday the 9th, as the building in which my lab is located is having major electrical work done. The web site and email dlists are hosted by sourceforge and will not be affected. Cheers, -Damion- |
From: Damion S. <da...@op...> - 2004-02-22 04:17:24
|
Hi folks, I've been a bit busy lately but I'm pleased to announce that after a great deal of headache setting up a new Linux machine at home, I've been able to build OpenGC successfully. I received several emails from people that I did not respond to because of not having a machine to test things on, so hopefully this will address those questions. There were two changes I had to make to the source (in the opengcnew repository) to allow compilation, and I also made the following notes: FLTK built fine (version 1.1.4). Freetype built fine (version 2.1.7). When building FTGL (version 2.07 I think) I had to create a symlink in the X11 libraries directory to libGL.la installed under /usr/lib. This may be a peculiarity of the NVidia graphics driver I installed, but it's something to keep in mind. When building Plib (version 1.6) I needed to install the libmesaglut and libmesaglut-devel libraries first - we do not need the glut dependent portion of plib but unfortunately there's no obvious way to turn it off. A few people have asked about CMake. Under Linux if you do a "make install" on Freetype, FTGL, and Plib CMake should find the relevant files _automatically_. You will need to manually specify "Plib_INCLUDE_DIR", which as the ccmake interface notes means "What is the path where the file ssgconf.h can be found". On my machine, which is probably typical of most linux boxes, this is /usr/include/plib. I also had to manually edit one of the plib library names, but I forget which offhand. You should _never_ need to edit a CMakelists.txt file in order to get OpenGC to build. If you need to, either you're doing something wrong or I've set things up incorrectly. Please let me know if you have trouble. As a final note, I have not tested any of the data sources under Linux, so I have not idea what is working and what isn't. Hopefully I'll be able to check on this in the next week or so. Cheers, -Damion- |
From: Caleb N. B. <cbonilla@Princeton.EDU> - 2004-02-03 13:04:00
|
I have edited CMakeLists.txt according to where my libs are. I have made the changes in the "UNIX" portion only (I'm RH 9), and cmake does create an executable. However, when I run ./OpenGC, the program crashes immeadiately with a segmentation fault. I'm assuming this is a path issue. Could someone who has built opengc from cvs please either look at my CMakeLists.txt or if I could look at a copy of yours? I'd really appreciate it, I think that is where the problem is. I've make sure all the libs are there, and hopefully my mistake is only an insignificant one... Caleb |
From: Damion S. <da...@op...> - 2004-01-12 18:30:09
|
Hi, there are several possibilities. Most likely there is an incorrect=20= entry in the OpenGC.ini file. You should make sure that the paths to=20 the font and navigation data are correct. If they are wrong, you would=20= receive an error like the one you did when trying to start OpenGC. Let=20= me know if the paths are correct and you still have problems. Cheers, -Damion- On Jan 6, 2004, at 6:51 PM, Pro...@ao... wrote: > After downloading the openGC, and windows dll... I clicked on=20 > OpenGC.EXE from openGC main folder and I recieved Program error: > =A0 > OpenGC.exe has generated error and will be closed by Windows you will=20= > need to restart the program An error log is being created. > =A0 > 1. Where is the error log? I couldnt find it on my folder > 2. What did I do wrong? > =A0 > In the folder it contains with file names and they are: > -OpenGC.EXE > -GPL. Txt > -MSVCP70.dll > -MSVCR70.dll > -OpenGC. ini > -OpenGC_install_Guide.PDF > -Vera true type text file > -Vera Copyright.Txt > =A0 > Can anyone help me out? FYI the computer I am using does not have=20 > FS2004 installed, So must I get it installed in this computer? > =A0 > Let me know, reply back at me atP...@ao... > =A0 > =A0 > Much Appriecated > -Arthur |
From: <Pro...@ao...> - 2004-01-06 23:52:17
|
After downloading the openGC, and windows dll... I clicked on OpenGC.EXE from openGC main folder and I recieved Program error: OpenGC.exe has generated error and will be closed by Windows you will need to restart the program An error log is being created. 1. Where is the error log? I couldnt find it on my folder 2. What did I do wrong? In the folder it contains with file names and they are: -OpenGC.EXE -GPL. Txt -MSVCP70.dll -MSVCR70.dll -OpenGC. ini -OpenGC_install_Guide.PDF -Vera true type text file -Vera Copyright.Txt Can anyone help me out? FYI the computer I am using does not have FS2004 installed, So must I get it installed in this computer? Let me know, reply back at me at Pro...@ao... Much Appriecated -Arthur |
From: Damion S. <da...@op...> - 2003-12-30 18:16:39
|
Hi folks, A quick update as to what I've been working on in the past month. I _finally_ solved the problem of how to maintain an authoritative list of objects within the OpenGC world for the purposes of passing messages around (for instance, between the zoom in/out buttons on the nav display and the nav map). My first thought was to try to adapt the Object class from the Insight Toolkit project, but after several days of experimentation this proved to be much harder than I had hoped and required a great deal of code which would have no real function in OpenGC. The solution I ended up implementing is to write a simple ogcObject class that handles all of the message passing tasks, and then derive the RenderObject (and therefore all gauges) from this. Eventually, data sources and render windows will also be ogcObjects. The new ogcObject contains a static linked list of pointers to ogcObjects. The constructor of an ogcObject adds the "this" pointer to this list and the destructor searches the list and removes it. The net result is that there is a statically accessible list of all ogcObjects; message passing occurs by iterating through this list and posting the message to each object. In retrospect this is a fairly obvious solution, and it seems to work as expected. The code that was "broken" in the new OpenGC repository (the map zoom, keypad demo, etc.) is now working again. I've updated the opengcnew CVS repository if you want to give this a try. The other model for message passing that I plan on adding is a transmitter/receiver model. Right now, messages are dispatched to _all_ OpenGC objects even if they're only appropriate for one. Ambiguity could result if there were two nav displays, for example, because the zoom controls for one should not affect the other (but would, at the moment). This should be easy to avoid by providing a means to set certain objects as receivers of the messages of a particular "transmitter", and providing a second dispatch function that iterates only over a given object's receivers rather than every OpenGC object. Issues with my current design MAY include: 1) Thread safety 2) The inconvenience of having to initialize a static member (the object list) from outside the class I have not done much programming with static members, so if anyone can comment on the initialization process I'd appreciate it. Cheers, -Damion- |
From: Damion S. <da...@op...> - 2003-12-02 17:37:41
|
Yes, this is a good opportunity to extend things. Basically, the way I've organized things now is under the "data-view" model. Because of the many possible map projections, it makes sense to separate apart the database and rendering components of navigation. Since Mercator is the only supported projection at the moment, and it does not vary based on aircraft location, it's possible to pre-compute the Northing and Easting coordinates of each nav object on the Mercator grid. This is what happens during the nav database initialization. It's then up to a particular nav display to decide how to draw the objects that are stored in the nav database. As we move towards more complicated projections, such as the conformal conic, or any other projection that varies based on aircraft lat/lon, the transformation of each geographic object will need to be computed in real time. To speed this up, I've experimented with hashing geographic objects based on 1 degree lat/lon squares (see ogcGeographicHash). The 1 degree hash is what's used with the nav test gauge (Mercator projection), and the speed is actually pretty decent. Unfortunately, this hash technique is subject to the different size of lat/lon squares depending on latitude. There are lots of other ways of doing this; some sort of distance based metric comes to mind, to avoid the problem of varying bin sizes with latitude. Under this scheme you'd compute a linked list of all geographic objects within 200 nm of a given lat/lon intersection (perhaps indexed by 1/2 or 1/4 degree increments), and then look up the nearest linked list based on aircraft location. This would increase obviously increase preprocessing time and memory consumption quite a bit, but may be necessary to achieve suitable rendering speed. The other possibility is to have a companion program to OpenGC that does this ahead of time and writes separate files that contain the above information, possibly in a binary format to save space and load time. I anticipate that something like this will be necessary for the sectional data, given it's large size. With the dynamic data you describe, I would assume we could get away with not preprocessing it since there will probably be much less of it around. Some things that would be good to think about: Is the "list of GeographicObjects" model sufficiently flexible to deal with navigation needs, insofar as representing discrete objects (airports, navaids, etc.) goes? Do graphical sectionals get stored in the nav database? Should we preprocess the nav data to disk, so that less needs to be stored in memory? -Damion- On Dec 2, 2003, at 11:32 AM, Wendell Turner wrote: > Is there an anticipated format or structure for data that the > nav display will use? I've hacked some data into the old one, > but with the re-write in progress, maybe here is an > 'opportunity' to work on this also. > > Certain data available for the nav display will be static, read > in at startup time, and possibly localized to the area (I will > not be needing waypoints around Kuala Lumpur if I'm flying in > Virginia, USA). Static data (from DAFIF, etc) would include: > Runway endpoints, VORs, waypoints, intersections, > restricted areas > > Also, dynamic data should be available during program operation. > This data would be received via datalink to the aircraft, or by > other means. This data would include > TIS/TCAS/ADSB targets, flight plan, active MOAs, and TFRs. > > Will this be an anticipated use for the nav display in > opengcnew? Or are these 'features' that we can program into the > display as desired? > > Wendell > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel > |
From: Damion S. <da...@op...> - 2003-12-02 17:12:21
|
I spent several hours last night looking at the data, and I think it will be pretty straightforward to use. Any TIFF library is capable of reading the images (I had no trouble opening them in Photoshop). The only marginally tricky bit is extracting the appropriate metadata for the projection tags, but there is quite a bit of documentation and sample code at http://remotesensing.org/geotiff/geotiff.html The thing that I'm not quite clear on is how to handle the boundaries of the sectionals. Although each sectional uses the Lambert Conformal Conic projection, the projection parameters vary for each chart. This could present a challenge when we go to overlay additional nav data on top of the sectional images, since we'd have to deal with two different conic projections on the same display. I laid a bunch of my paper sectionals out and they seem to match up pretty well, so it may not be a huge problem. -Damion- On Dec 2, 2003, at 10:35 AM, Wendell Turner wrote: >>> I found an unsupported program >>> http://www.hsge.de/geo-spatial/software/index.html >>> that will read & display the images, so that may be a starting >>> point. >> >> I'll take a look at it. Thanks for the info. > > I've tweaked the program to accept NMEA sentences from > flightgear, so this may help: > > Program > http://www.hsge.de/geo-spatial/software/hugo/hugo-1.2.tar.gz > > My notes/readme file > http://www.halcyon.com/wturner/hugo.readme > And the patches to make the program work > http://www.halcyon.com/wturner/hugo.patch > |
From: Wendell T. <we...@ad...> - 2003-12-02 16:32:45
|
Is there an anticipated format or structure for data that the nav display will use? I've hacked some data into the old one, but with the re-write in progress, maybe here is an 'opportunity' to work on this also. Certain data available for the nav display will be static, read in at startup time, and possibly localized to the area (I will not be needing waypoints around Kuala Lumpur if I'm flying in Virginia, USA). Static data (from DAFIF, etc) would include: Runway endpoints, VORs, waypoints, intersections, restricted areas Also, dynamic data should be available during program operation. This data would be received via datalink to the aircraft, or by other means. This data would include TIS/TCAS/ADSB targets, flight plan, active MOAs, and TFRs. Will this be an anticipated use for the nav display in opengcnew? Or are these 'features' that we can program into the display as desired? Wendell |
From: Wendell T. <we...@ad...> - 2003-12-02 15:36:11
|
> > I found an unsupported program > > http://www.hsge.de/geo-spatial/software/index.html > > that will read & display the images, so that may be a starting > > point. > > I'll take a look at it. Thanks for the info. I've tweaked the program to accept NMEA sentences from flightgear, so this may help: Program http://www.hsge.de/geo-spatial/software/hugo/hugo-1.2.tar.gz My notes/readme file http://www.halcyon.com/wturner/hugo.readme And the patches to make the program work http://www.halcyon.com/wturner/hugo.patch Wendell |
From: Damion S. <da...@op...> - 2003-12-02 03:26:34
|
Hi, > Has anyone considered making a moving map display with these > images? How difficult would it be to put these images onto the > nav display? I was unaware that this sort of data even existed. In looking for the headers provided for each sectional it appears that there is sufficient information to reconstruct the coordinate projection used on each map (specifically, Lambert Conformal Conic). See http://mathworld.wolfram.com/LambertConformalConicProjection.html Given the parameters of the projection, it should be relatively easy to implement that projection for OpenGC's internal nav data so that route information would be correctly overlaid on the graphical sectional. As far as the actual placement of the images on the nav display goes, OpenGL's texturing capability could do this pretty easily. The tricky bit would be aligning the sectional projection with the internal projection. > I found an unsupported program > http://www.hsge.de/geo-spatial/software/index.html > that will read & display the images, so that may be a starting > point. I'll take a look at it. Thanks for the info. -Damion- |
From: Wendell T. <we...@ad...> - 2003-12-01 15:45:19
|
There are sectionals available (for the US) at http://aviationtoolbox.org/raw_data/FAA_sectionals/ They are geo-tiff images, scanned directly from the published sectionals, with enough registration to plot lat/long coordinates on it. Has anyone considered making a moving map display with these images? How difficult would it be to put these images onto the nav display? I found an unsupported program http://www.hsge.de/geo-spatial/software/index.html that will read & display the images, so that may be a starting point. Wendell |
From: Damion S. <da...@op...> - 2003-11-23 23:16:57
|
Hi, here's a few notes about the build process for the experimental repository... --- Under all platforms: Download and install CMake version 1.8+ Download and build FLTK version 1.1.4 Download and build Freetype 2.1.4 Download and build FTGL 2.07 Download and build Plib 1.6 Other versions of these libraries may work, although I have tested only the above set. --- Under Unix (includes Linux and MacOS X): Do a "make install" on Freetype, Plib, and FTGL. "make install" for FTGL appears to miss some critical include files, so you will need to override the include directory for FTGL as described below --- Now that you have all of the libraries built, go ahead and run CMake on OpenGC. Options you will have to set are: FLTK_INCLUDE_DIR - the root directory for FLTK, for example /Users/beowulf/fltk-1.1.4 The various FLTK libraries will be found automatically if this is set correctly. FTGL_INCLUDE_DIR - for example, /Users/beowulf/opengc/FTGL-2.07/include - note that under Unix you should override the path if it's identified as /usr/local/include, since not all required headers are copied here. FTGL_LIBRARY - should be found automatically under Unix if you did a "make install", may need to be located manually under Windows or under Unix (without make install). Under Windows, I suggest that you pick ftgl_static_MT as the library. PLIB_INCLUDE_DIR - should be found automatically under Unix, under Windows it's the root plib directory (the Plib project is smart enough to lump the headers and libraries under the root Plib dir when building) Various PLIB libraries should be found automatically under both Windows and Unix Once CMake is happy, go ahead and run make or Visual Studio as appropriate. The results of building OpenGC will include 4 libraries (Base, DataSources, Gauges, and Nav) and one executable (OpenGC). The executable behaves approximately the same as it does in the main repository, with the exception of GPL licensed gauges which are not included yet. Please let me know if you encounter any problems. You _should not_ need to modify any CMakeLists.txt files in order to get a successful build. If you do, I made a mistake somewhere. As of 6:20 pm EST, the new repository is building correctly on both Windows and Mac OS 10.3. Cheers, -Damion- |
From: Damion S. <da...@op...> - 2003-11-23 04:22:10
|
I forgot to mention this in the previous email, but the build procedure has changed somewhat. You now need to set several path variables in CMake, and you should not need to hack the CMakeLists.txt file. I'll provide further details once I verify that this works under Unix. Cheers, -Damion- |
From: Damion S. <da...@op...> - 2003-11-23 04:01:20
|
Hi everyone, A new - and I caution _highly_ experimental - repository is open in addition to the more stable repository. Oddly enough, the new repository is "opengcnew", and the server path is: cvs.opengc.org:/opengcnew Please feel free to download this code and give it a try. It represents my first crack at refactoring the existing code into separate libraries, streamlining the build process, and generally giving the code a thorough once over. If you have Doxygen installed on your system, this repository can be used to generate a more or less complete set of documentation based on my overhaul of the headers. The detail of the Doxygen headers is far from complete, so bear in mind that things will improve in the future. Other rather dramatic changes in this repository: 1) The OpenGC application is built separately from the libraries. This helps to ensure that the bulk of OpenGC is standalone, and not dependent on the application structure. 2) The render window is now an abstract base class, with specific windowing interface dependent implementations derived from it. Right now this is just FLTK but I would like to have a native MFC class for Windows and a Cocoa class for Mac. 3) Gauges are now sorted by aircraft type. Things which will be happening in the near future: 1) I've decided that the distinction between gauges and components is rather arbitrary and unnecessary. Components will disappear, in favor of a more generalized gauge class that supports nesting of child gauges (which is essentially the only difference between gauges and components in the existing code). 2) Addition of a garbage collecting "smart pointer" base class derived from the ITK project. Among other things, this will allow us to wrap OpenGC for Java and Python programmers. Now, please keep in mind that this code is essentially a "straw man" proposal and is not the finished rewrite. However, I thought people would be interested in seeing it sooner rather than later. Comments on any aspect of the rewrite are welcome, it will be far easier to make changes now than 6 months down the road. Things that I'm positive are currently broken include message passing in regards to mouse events and most likely several other things I'm missing. Gauges for which I am not the original author do not appear in the repository yet. Rest assured that they will make their return _under the GPL_ once the rewrite is complete. The main "OpenGC" application is and will remain GPL. If anyone has issues with the relicensing of the "core" of OpenGC, again please let me know sooner rather than later. I have made my best effort to not relicense any code of which I am not the sole author, although it's very possible that I have made a mistake. Rest assured I will correct any problems of this kind immediately; the original GPL'd code remains available under the main repository for your inspection. Finally, a few warnings: 1) This code is not as thoroughly tested as the main repository. I can't guarantee it will build on your machine. 2) I STRONGLY encourage you NOT to use this code as the base for development, although you are of course free to do so. I make no guarantee that this code will not change substantially before the official release of the rewrite. Cheers, -Damion- |
From: Stein,Jeffrey L. <js...@mi...> - 2003-11-11 15:56:59
|
In response to the question about a radar display. In our work with openGC we've put together a rather extensive nav display using an in-house flight simulator. Our flight simulator sends out TCAS traffic. The nav display was built with an old build of openGC before it had support for a nav display and thus the entire gauge was written by us. The approach I used, which I'm not sure is the best appraoch, was to create a set of classes for various navData types: Waypoints, Stations, Airports etc. each of these instantiated from gaugeComponent and they all had their own render method. I also added TCAS data wrapped everything into STL Lists and threw it into a navData class. I added this class to the datasource and everything came together. Assuming you are talking about a radar display in terms of an airplanes navigation display OGC is fine for doing it as its been done. If you are refering to a stationary radar display I would also suggest that OGC is fine to use because it would more or less be the same implementation as the nav display except you would have a stationary point instead of a flying plane. As we have made substantial modifications to OGC I'm not sure how useful any of my code would be but if you have any questions feel free to ask. -jeff Damion Shelton wrote: > Hi, > > Developing a HUD would be very easy in the present system, given that > they are usually simpler than in-cockpit displays. You should be able > to use the basic 777 PFD as a starting point; I would imagine that by > removing the background color on the ADI for example, and switching > the foreground (lines, fonts, etc.) to be monochromatic you could get > a decent HUD pretty quickly. > > A radar display would be a bit more complicated; not in regards to > rendering, but rather data representation. OpenGC currently has no way > of storing information about other aircraft or radar contacts. This > would have to be an extension to the ogcDataSource object; not hard, > but definitely more time consuming than the HUD. This of course also > presumes that you have a source of radar contact data. The > FSUIPC/FS2004 interface provides this sort of data (in order to > simulate TCAS) but that functionality is not yet present in OpenGC. > > In regards to documentation, there is no definitive programming guide > available for OpenGC at this time. I'm working on set of code > revisions, and one of the new features will be a set of Doxygen > documentation generated automatically from the source code. I have a > preliminary version of this on my hard drive, but since it documents > the new version of OpenGC, not the current CVS version, I'm not sure > that this would be of much use (though I'd be happy to send it to you > if you'd like). I hope to have the new version of OpenGC posted to CVS > and the web site updated with the new documentation by the end of this > month. I've also been working on programmer's guide PDF, but as I'm > currently involved in source revisions, I can't predict when this will > be available. > > Incidentally, I'm hoping that the code revisions will make OpenGC > significantly easier to use... I guess we'll find out. > > Any other questions, feel free to ask. > > Cheers, > -Damion- > > On Nov 10, 2003, at 10:48 PM, Ed Peddycoart wrote: > >> I am interested in using OpenGC for some instrumentation >> development. I am >> interested in developing some RADAR panels, and HUDs. Is this something >> that OpenGC can currently handle, or would it be "simple enough" to >> extend >> the capabilities to handle these instruments? Also, where can I find >> some >> beginner level docs for OpenGC? >> Thanks, >> Ed >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: ApacheCon 2003, >> 16-19 November in Las Vegas. Learn firsthand the latest >> developments in Apache, PHP, Perl, XML, Java, MySQL, >> WebDAV, and more! http://www.apachecon.com/ >> _______________________________________________ >> Opengc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opengc-devel >> >> > > --------- > Damion Shelton > Carnegie Mellon University, Robotics Institute > A408-o Newell Simon Hall > 412.268.3866 (office) > 412.818.8829 (cell) > 412.268.6436 (fax) > http://www.cs.cmu.edu/~beowulf > --------- > I wish I would have a real tragic love affair and get so bummed out > that I'd just quit my job and become a bum for a few years, because I > was thinking about doing that anyway. > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel |
From: Wendell T. <we...@ad...> - 2003-11-11 15:38:11
|
> A radar display would be a bit more complicated; not in regards to > rendering, but rather data representation. OpenGC currently has no way > of storing information about other aircraft or radar contacts. I've managed to butcher ogcNavTestComponent.cpp and create a TGDataSource (very similar to other data sources) to get a TCAS-like display on the HSI. This also displays the flight plan path on the HSI. I'm waiting for the upgraded OpenGC before submitting it for cvs, but could change those plans if needed. > The > FSUIPC/FS2004 interface provides this sort of data (in order to > simulate TCAS) but that functionality is not yet present in OpenGC. Is that defined in a public document anywhere? Wendell |
From: Damion S. <da...@op...> - 2003-11-11 04:00:31
|
Hi, Developing a HUD would be very easy in the present system, given that they are usually simpler than in-cockpit displays. You should be able to use the basic 777 PFD as a starting point; I would imagine that by removing the background color on the ADI for example, and switching the foreground (lines, fonts, etc.) to be monochromatic you could get a decent HUD pretty quickly. A radar display would be a bit more complicated; not in regards to rendering, but rather data representation. OpenGC currently has no way of storing information about other aircraft or radar contacts. This would have to be an extension to the ogcDataSource object; not hard, but definitely more time consuming than the HUD. This of course also presumes that you have a source of radar contact data. The FSUIPC/FS2004 interface provides this sort of data (in order to simulate TCAS) but that functionality is not yet present in OpenGC. In regards to documentation, there is no definitive programming guide available for OpenGC at this time. I'm working on set of code revisions, and one of the new features will be a set of Doxygen documentation generated automatically from the source code. I have a preliminary version of this on my hard drive, but since it documents the new version of OpenGC, not the current CVS version, I'm not sure that this would be of much use (though I'd be happy to send it to you if you'd like). I hope to have the new version of OpenGC posted to CVS and the web site updated with the new documentation by the end of this month. I've also been working on programmer's guide PDF, but as I'm currently involved in source revisions, I can't predict when this will be available. Incidentally, I'm hoping that the code revisions will make OpenGC significantly easier to use... I guess we'll find out. Any other questions, feel free to ask. Cheers, -Damion- On Nov 10, 2003, at 10:48 PM, Ed Peddycoart wrote: > I am interested in using OpenGC for some instrumentation development. > I am > interested in developing some RADAR panels, and HUDs. Is this > something > that OpenGC can currently handle, or would it be "simple enough" to > extend > the capabilities to handle these instruments? Also, where can I find > some > beginner level docs for OpenGC? > Thanks, > Ed > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel > > --------- Damion Shelton Carnegie Mellon University, Robotics Institute A408-o Newell Simon Hall 412.268.3866 (office) 412.818.8829 (cell) 412.268.6436 (fax) http://www.cs.cmu.edu/~beowulf --------- I wish I would have a real tragic love affair and get so bummed out that I'd just quit my job and become a bum for a few years, because I was thinking about doing that anyway. |
From: Ed P. <epe...@ra...> - 2003-11-11 03:44:51
|
I am interested in using OpenGC for some instrumentation development. I am interested in developing some RADAR panels, and HUDs. Is this something that OpenGC can currently handle, or would it be "simple enough" to extend the capabilities to handle these instruments? Also, where can I find some beginner level docs for OpenGC? Thanks, Ed |
From: Damion S. <da...@op...> - 2003-10-30 16:54:56
|
Hi, A quick update as to where I am on the "rewrite", and how things are shaping up. 1) The CMake build process has been extensively overhauled. The paths to the various external libraries are now either determined automatically, or are prompted for in the GUI/TUI presented by CMake. This means that you no longer have to hack the CMakeLists.txt file to set library paths, making it easier to keep in sync with the CVS version. 2) OpenGC is now built as a series of libraries; at the moment, this includes OpenGCBase, OpenGCDataSources, and OpenGCNav. The data source and nav libraries are actually useful in their own right, so developers who want _just_ data collection (for creating motion platforms, steam gauges, etc.) can obtain that functionality without dragging the rest of OpenGC along for the ride. The gauges have been reorganized by aircraft type and will eventually be rolled into a library as well. 3) The OpenGC executable code has been moved to a separate "Applications" directory; in addition to still being the public face of OpenGC, it also serves as an example of how to write a standalone app that links against the libraries. I will probably GPL the current application and continue development of it as the "lite" version of OpenGC. My understanding is that it's ok to use non-GPL code in a GPL application, but the reverse is not true. Can anyone verify this? In other words, although the core of the toolkit will not be GPL after the rewrite is finished, it's perfectly fine to distribute add-on bits that work with it which _are_ GPL...(?) 4) Any code that was (a) in the GPL'd OpenGC and (b) the author/s wish to keep as GPL will be placed in an "unsupported" directory; there will be a build flag that will allow you to turn on/off the creation of the OpenGCUnsupported library. If you link against code in this library, your application may be subject to commercial restrictions per the GPL or other open source license. If you link against any of the other libraries you are free to develop commercial products subject only to the copyright notice restriction. Obviously, if you are only interested in developing open source code, this shouldn't really affect you. 5) New code contributions can fall into one of two categories: official or unsupported. Official code will be released under the new VTK (BSD-like) license, and will be supported with automated build testing, Doxygen documentation, and CVSweb browsing. Unsupported code can be released under any of the licenses permitted by Sourceforge.net will be included in the toolkit and built per (4). I would encourage potential developers to consider releasing their work "officially". Finally, none of these changes have been committed to the CVS repository. I will give plenty of advance notice prior to committing anything... If you have questions or comments please let me know. Cheers, -Damion- --------- Damion Shelton The Open Source Glass Cockpit Project (OpenGC) Carnegie Mellon University, Robotics Institute http://www.opengc.org da...@op... |
From: Damion S. <be...@cs...> - 2003-10-29 03:06:30
|
Hi, I've got a few suggestions. As I mentioned in a few earlier emails, I'm in the process of rewriting and relicensing the "core" part of OpenGC. Although the changes to existing gauges will be relatively minor, the affect of the "philosophy" of OpenGC will be larger. Right now, OpenGC is both a toolkit and an application. While nice from an organization standpoint, this causes the sorts of problems that you're running into; i.e., the difficulty of maintaining different private and public versions of code. The rewrite that I'm working on is primarily focused on shifting OpenGC more completely into the toolkit realm. Under the new philosophy, OpenGC is a bunch of components that you can use to write an application, but not an application itself. Therefore, main.cpp and the AppObject class will become examples in how to _use_ the forthcoming OpenGC libraries, and not form the basis of a complete application. As far as end users are concerned, the executable that is obtained from compiling this example will still be "OpenGC", but as far as developers are concerned, OpenGC is a set of libraries you can link against to add cockpit data acquisition and rendering to your application. A side effect of this is that I will be a little more concerned with making the various classes completely portable. Right now, for example, the RenderObject class (the base for both gauges and components) requires a pointer to an AppObject. This of course locks you into the application framework, and hence FLTK, and therefore complicates the lives of developers who might want to use something other than FLTK (e.g. embedding OpenGC into an existing applications). With the new "portable" philosophy, any code you'd like to contribute or maintain internally should not interfere with any other code in the repository. The data source base object needs considerable work on my part; in particular, it needs an easy way to identify which variables in the base class a particular sim supports, and whether or not those are read/write/both. If this facility existed, it seems like it would address your problem (the need to have variables not present in OpenGC). What I'd like is for the base DataSource class to become arbitrarily complex; i.e., add whatever you want. With proper initialization, gauges that require the specialized data would simply not function (by always receiving the default value) with a data source that did not implement a method for retrieving this data from the sim. Does this sound like it would meet your needs? Perhaps there could even be some sort of global warning that would pop up that says "The gauges you are trying to use require data not supported by the data source you have selected". Your comments would be appreciated. I'm trying to move to a design model more along the lines of VTK and ITK, two toolkits that have been extremely successful ( http://www.vtk.org and http://www.itk.org respectively). One of the reasons they work so well is that they are extremely compartmentalized and don't force design decisions on their users; I'm a bit concerned that the current OpenGC makes a number of assumptions that force users into a particular application model. Hopefully the "new" OpenGC will avoid this... Cheers, -Damion- On Tuesday, October 28, 2003, at 07:02 PM, Pollack,Matthew E. wrote: > We at MITRE have been using OpenGC for a few months now, and have > recently run into an issue that we are not sure how to tackle. We have > a custom, internally developed flight simulator that has both outputs > that MSFS, FG and X-plane do not have and requires inputs different > from > the aforementioned flight sims. Up until now, we have been adding > variables to the ogcDataSource class to support our needs. However, > this precludes us from making a smooth transition to newly released > versions of OpenGC. Does anyone have any ideas as to how we might be > able to both support our needs, while, at the same time not breaking > any > backward compatibility with the reference implementations of OpenGC? > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel > > --------- Damion Shelton Carnegie Mellon University, Robotics Institute A408-o Newell Simon Hall 412.268.3866 (office) 412.818.8829 (cell) 412.268.6436 (fax) http://www.cs.cmu.edu/~beowulf --------- I wish I would have a real tragic love affair and get so bummed out that I'd just quit my job and become a bum for a few years, because I was thinking about doing that anyway. |