opengc-devel Mailing List for Open-source Glass Cockpit (OpenGC) (Page 6)
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: John W. <ca...@mm...> - 2003-09-20 18:21:49
|
a quick addendum regards windows; check out http://www.beyondlogic.org/index.htm#DeviceDrivers might be helpful if your building your own boards JW |
From: John W. <ca...@mm...> - 2003-09-20 17:58:15
|
> Well remember, FlightGear does run in Windows. :) > Well, I don't want to get into a flame war, however FG runs on windows because a few dedicated souls (like Curtis Olson) strive to make the program cross-platform compliant, and it's not always easy or fun... If you want to build a world-class simulator you need access to the OS internals and the ability to control hardware other than through the application layer. And peek and poke just don't cut it. But from what I've seen, the market is for hardware and interfaces to work with and in the windows environment so one either goes with the flow, sets their own course, or does without. Enjoyed the stories and pics on your website. These projects have a way of consuming us, don't they? ;-) Regards John W. |
From: Gene B. <ge...@de...> - 2003-09-20 02:49:36
|
> > > Not all that familiar with EPIC. EPIC is a fairly high end solution due to the cost of the gear. It's not cheap. :) > Sounds like you are using Windows. And the software provided by phidget is > windows based. so you either roll your own for Linux or make do with the > stuff in sourceforge. > I'm using Windows for all my initial development work. Once I've got all the hardware done, I'll run both Windows & Linux. > I still like my board that drives 16 digits and runs in Linux kernel space > on an interrupt basis. I never liked windows as an OS for simulation. As an > engineer I like to know ALL the details and I don't think MS is going to > release source any time soon... > Well remember, FlightGear does run in Windows. :) > Is your Eagle a C or E model? Still living with steam gauges... ;-) > It's a C model. Everything with the exception of the MPCD, VSD and TEWS is steam. I got really lucky and nailed down a real HSI and a built-for-simulation-use ADI. All my hydraulic and engine guages are scratch built by a friend of mine and the others will be gutted and rebuilt, with the exception of the ADI and HSI. Those will eventually be driven "as designed". g. |
From: John W. <ca...@mm...> - 2003-09-19 23:21:07
|
Hi Manuel, > > Over the course of the last year I've been trying to find simulation hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support open source programs like FlightGear and OpenGC. All I could find was Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot of interest in developing stuff for open source software under Linux. > > Sadly, this is true. Maybe Flightgear will change this in the future. > In the home cockpit building community, Linux and flightgear don't seem > to be very well known and used. > I suspect if you surveyed the users you would find most are not deeply involved in software, but rather the hardware aspects of building something tangible so windows and windows-related hardware provide a nice comfort zone. > I think that flightgear is especially suited for that since its open > source so you can get information in and out easily and dont have to > rely on peek'ing and poke'ing the memory of the running simulator > program. > Right, you need to get to the kernel and leave the application alone. > I thing all other things except the analog inputs will not be driven by > a kernel driver, but rather by a user mode program that can connect to > flightgear. That way, I can specify mappings eg. for the switches > without having to unload/reload the kernel module over and over. > Running is kernel space is both risky and very effective. In my case, the driver works with the hardware and never bothers the application (FG and OpenGC) which simple poll the driver. Displays, LEDs, switch states are all updated based on hardware interrupts and the application never sees or hears about it. > Costwise, I estimate my currently "in-progress" circuit schematic would > cost around $50-70 in components, depending on the prices of your > suppliers. > There are some sites that provide circuit design, PCB layout software and prices vary also as well with quantities purchased. Looks like my component costs for the MCP are around $30 to $35 but then I've kept the interface simple by using the parallel port so after you buy a PCI board ($40) it turns out to be a wash... And the start-up costs for the PCB range from $50 to $80 for the first unit. Then throw in some sockets, connectors, and you're over the century mark.The panel, produced by AGT, is excellent and with all the lights and switches goes for $325. This can be an expensive hobby... > > I'm glad I'm not alone doing things like that under linux. > I don't think there are a lot of us ;-) > If you are interested, I can send you a png of the circuit I'm working > on right now. > I would appreciate that; Don't have a schematic of the my circuit, just a bunch of notes and scribbles which I need to turn into a finshed product with a circuit design tool to do a PCB layup. There are some boards at www.phdigit.com that you might take a look at, only drawback ( I think ) is software is for windows. Still researching it. BTW, if your not familiar with Rubini's book on linux device drivers, recommend it highly. Google on device drivers or go to the O'Reilly website. Text and source are online and GPL'd Thank you for your comments Regards John W. |
From: Manuel B. <li...@va...> - 2003-09-19 22:32:22
|
Hi John, On Thu, Sep 18, 2003 at 10:50:24AM -0700, John Wojnaroski wrote: > Hi, > > Over the course of the last year I've been trying to find simulation hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support open source programs like FlightGear and OpenGC. All I could find was Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot of interest in developing stuff for open source software under Linux. Sadly, this is true. Maybe Flightgear will change this in the future. In the home cockpit building community, Linux and flightgear don't seem to be very well known and used. I think that flightgear is especially suited for that since its open source so you can get information in and out easily and dont have to rely on peek'ing and poke'ing the memory of the running simulator program. > Well, I never followed the herd and was not about to move over to Windows or FSxxxx. That would be a step back, wouldn't it :-) > So I sat down and designed an interface board for the MCP and EFIS as starters. Turns out, the board is somewhat generic in that it takes rotary enconder data and key scan circuits and along with the Linux driver stuffs the data into a small file that the application can read/write. Using the board goes like this: > > The board has a standard parallel port interface (I wanted to use IEEE1284 EPP but opted for the most common, simplest for the moment). It will run either on your printer port or any additional parallel port board (ISA or PCI) you care to install or I've got a custom ISA board with three programmable ports I used for development and testing. I've done something very similar. I'm using the serial port, however. The whole thing is based on microchips PIC line of microcontrollers. (Like someone else pointed out in this thread, these are very good for our purposes) Right now I'm tying things together to build a board that can take up to 1024 inputs (switches/rotaries/..), 35 analog input channels, and 64 digital 8 bit channel outputs for things like 7segment displays, steppers, Digital to analog,... I've written a joystick kernel driver for linux for a earlier 16 channel analog to digital system. And its Flightgear tested :-) I've made Panels myself for a 747-400 MCP and EFIS. I thing all other things except the analog inputs will not be driven by a kernel driver, but rather by a user mode program that can connect to flightgear. That way, I can specify mappings eg. for the switches without having to unload/reload the kernel module over and over. > So if you were running a MCP panel the data would be airspeed, mach, heading, vvi, and altitude. Plus the state of the pushbutton switches on the panel which would go to the FMC for the appropriate action and control of the system autopilot(s) and such. Or you could configure it as a NAV/RADIO panel and process the data as frequencies. Or whatever..... > > The board and driver run in kernel space and use an interrupt to process changes in the state of the connected panel > > I'm still testing the board but getting close to a decision on moving from a breadboard to a PCB layout. Best guesstimate on cost is between $100 and $200. ( I have no idea on what the manufacturing costs beyond the production of the bare PCB look like, as always very dependent on size of the lot and quantity discounts for parts and amortization of start-up costs,etc,etc) Costwise, I estimate my currently "in-progress" circuit schematic would cost around $50-70 in components, depending on the prices of your suppliers. > Trying to gauge the interest in such an item and welcome any feedback, questions, etc. > > For a look at some of the hardware panels I plan to use check out http://www.a-g-t.com I'm glad I'm not alone doing things like that under linux. Some older circuits and pics of my MCP/EFIS panels can be found at my home cockpit site: http://cockpit.varxec.de/ If you are interested, I can send you a png of the circuit I'm working on right now. Oh, and - of course - everything is released under the GPL, including the PIC assembly language firmware programs. Regards, Manuel |
From: Damion S. <be...@cs...> - 2003-09-19 20:08:48
|
Hi, I apparently misunderstood the status of FSUIPC support within OpenGC. A new version of the FSUIPC library is _not_ needed to be compatible with FSUIPC 3.0+ (in fact, the library version in release 15 of the SDK dates back to 2000). Therefore: a) If you're using FSUIPC 2.97 or less with FS2002 or earlier, OpenGC will continue to work (for free). b) If you're using FSUIPC 3.0+ with FS2004, OpenGC will also work. Note that if you are using 3.0+, the registration information provided in the earlier emails is still accurate. OpenGC 0.55 is now available for Windows (in addition to the Mac version mentioned in the email yesterday). Linux users should be able to roll their own release from source without running into compile problems. Cheers, -Damion- --------- 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 hope that after I die, people will say of me: "That guy sure owed me a lot of money." |
From: Damion S. <be...@cs...> - 2003-09-19 19:56:29
|
I feel like I've been doing this a lot lately, but OpenGC 0.55 is out for Mac and should be available for Windows by tomorrow evening. It adds a few experimental features to the nav display (ground track information and zoom buttons), which will probably change dramatically by the time anything near the final release occurs. Also available is preliminary NMEA GPS string parsing for the EGyro folks. 0.55 will probably be the last release for a couple of weeks. I have a number of issues I'd like to address more completely before issuing another. The flurry of recent changes has primarily been to iron things out prior to the Avsim conference and take care of a few EGyro items I procrastinated on from earlier in the summer. For developers: 0.55 is in sync with the CVS, which should be stable for at minimum the next five days, most likely until the beginning of October. At this point in time everything _should_ be building smoothly on all platforms. Any questions or problems, don't hesitate to ask. Cheers, -Damion- --------- 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 hope that after I die, people will say of me: "That guy sure owed me a lot of money." |
From: John W. <ca...@mm...> - 2003-09-18 21:53:36
|
> > > I do like that 0/256/0 prototyping kit. Will it handle static switches and > > momentary switches? > > > It works just like the EPIC does. You can get it in a 16x16 matrix or an > EPIC wiring-compatible 8x32 matrix. You use diodes just like in EPIC to > isolate the switches. Both momentary and on/off switches can be used. > Not all that familiar with EPIC. Sounds like you are using Windows. And the software provided by phidget is windows based. so you either roll your own for Linux or make do with the stuff in sourceforge. I still like my board that drives 16 digits and runs in Linux kernel space on an interrupt basis. I never liked windows as an OS for simulation. As an engineer I like to know ALL the details and I don't think MS is going to release source any time soon... Is your Eagle a C or E model? Still living with steam gauges... ;-) Regards John W. |
From: Gene B. <ge...@de...> - 2003-09-18 20:39:47
|
> > There is a 7 segment controller that will drive 8 digits each. I'm using > > one of them to handle my VHF radio panel. They're very easy to use and > > since they're USB, you can use as many as you need. (up to the USB max of > > course) > > > Looked and looked; could not find the above mentioned item. Is there a part > number? > It's called the PhidgetLED. I didn't spot it either - Chester may have not begun to sell them yet. > I do like that 0/256/0 prototyping kit. Will it handle static switches and > momentary switches? > It works just like the EPIC does. You can get it in a 16x16 matrix or an EPIC wiring-compatible 8x32 matrix. You use diodes just like in EPIC to isolate the switches. Both momentary and on/off switches can be used. g. |
From: John W. <ca...@mm...> - 2003-09-18 20:20:37
|
Hi Gene, > There is a 7 segment controller that will drive 8 digits each. I'm using > one of them to handle my VHF radio panel. They're very easy to use and > since they're USB, you can use as many as you need. (up to the USB max of > course) > Looked and looked; could not find the above mentioned item. Is there a part number? I do like that 0/256/0 prototyping kit. Will it handle static switches and momentary switches? Thanks for the input. Regards John W. |
From: Gene B. <ge...@de...> - 2003-09-18 19:57:19
|
> I looked at that site a while back, but again not convinced it meets the > test. For example, how would you drive an array of 16 7-segment LEDs? OTH > there are some items there that are interesting, but again did not see > anything that would drive/interface to something like an MCP and EFIS panel > as a single package. > There is a 7 segment controller that will drive 8 digits each. I'm using one of them to handle my VHF radio panel. They're very easy to use and since they're USB, you can use as many as you need. (up to the USB max of course) > Have you used these products in your sim? > I currently use both EPIC and Phidgets in my sim. I'm using 1 of the 7 segment controllers as I mentioned as well as 3 of the 32/32 I/O boards and 1 of the 0/256/0 boards. I'm also using 2 of the 8 servo boards and 1 of the 4 servo boards for driving custom built gauges. The 7 segment controller can also be set up to drive 64 LEDs directly. You might want to check out http://www.737flightsim.com - David is using Phidgets exclusively with his project. If you have any questions about Phidgets, I'd be more than happy to help. g. |
From: John W. <ca...@mm...> - 2003-09-18 18:34:41
|
Hi Gene I looked at that site a while back, but again not convinced it meets the test. For example, how would you drive an array of 16 7-segment LEDs? OTH there are some items there that are interesting, but again did not see anything that would drive/interface to something like an MCP and EFIS panel as a single package. Have you used these products in your sim? Regards John W. ----- Original Message ----- From: "Gene Buckle" <ge...@de...> To: <ope...@li...> Sent: Thursday, September 18, 2003 11:16 AM Subject: Re: [Opengc-devel] Linux Hardware > > > On Thu, 18 Sep 2003, John Wojnaroski wrote: > > > Hi, > > > > Over the course of the last year I've been trying to find simulation > > hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support > > open source programs like FlightGear and OpenGC. All I could find was > > Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot > > of interest in developing stuff for open source software under Linux. > > > John, you missed out on the Phidget (httpd://www.phidgets.com). There is > a Linux driver available on SourceForge and someone has also done work on > a Mac OSX version. It works very similar to EPIC, but is _vastly_ cheaper > to use and more oriented to software developers. > > g. > > -- > Proud Owner of 80-0007 > http://www.f15sim.com > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel |
From: Gene B. <ge...@de...> - 2003-09-18 18:06:18
|
On Thu, 18 Sep 2003, John Wojnaroski wrote: > Hi, > > Over the course of the last year I've been trying to find simulation > hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support > open source programs like FlightGear and OpenGC. All I could find was > Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot > of interest in developing stuff for open source software under Linux. John, you missed out on the Phidget (httpd://www.phidgets.com). There is a Linux driver available on SourceForge and someone has also done work on a Mac OSX version. It works very similar to EPIC, but is _vastly_ cheaper to use and more oriented to software developers. g. -- Proud Owner of 80-0007 http://www.f15sim.com |
From: John W. <ca...@mm...> - 2003-09-18 17:52:07
|
Hi, Over the course of the last year I've been trying to find simulation = hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support = open source programs like FlightGear and OpenGC. All I could find was = Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot = of interest in developing stuff for open source software under Linux. Well, I never followed the herd and was not about to move over to = Windows or FSxxxx. So I sat down and designed an interface board for the MCP and EFIS as = starters. Turns out, the board is somewhat generic in that it takes = rotary enconder data and key scan circuits and along with the Linux = driver stuffs the data into a small file that the application can = read/write. Using the board goes like this: The board has a standard parallel port interface (I wanted to use = IEEE1284 EPP but opted for the most common, simplest for the moment). It = will run either on your printer port or any additional parallel port = board (ISA or PCI) you care to install or I've got a custom ISA board = with three programmable ports I used for development and testing. Installing/using the board is standard Linux. Compile the module driver -- source and makefiles will be provided Create the device -> mknod /dev/mcp u 254 0 Install the modules -> insmod mcp.o Create you application -> something like this /********************** main() { : fd =3D open( "/dev/mcp", O_RDWR); int result =3D read(fd, mesg, sizeof mcp_data); // Convert from char string to data types memcpy( char * &mcp_data, char * &mesg, sizeof mcp_data ); // Now do your application stuff whatever : : close(fd);=20 } *******************/ So if you were running a MCP panel the data would be airspeed, mach, = heading, vvi, and altitude. Plus the state of the pushbutton switches on = the panel which would go to the FMC for the appropriate action and = control of the system autopilot(s) and such. Or you could configure it = as a NAV/RADIO panel and process the data as frequencies. Or = whatever.....=20 The board and driver run in kernel space and use an interrupt to process = changes in the state of the connected panel I'm still testing the board but getting close to a decision on moving = from a breadboard to a PCB layout. Best guesstimate on cost is between = $100 and $200. ( I have no idea on what the manufacturing costs beyond = the production of the bare PCB look like, as always very dependent on = size of the lot and quantity discounts for parts and amortization of = start-up costs,etc,etc) Trying to gauge the interest in such an item and welcome any feedback, = questions, etc. For a look at some of the hardware panels I plan to use check out = http://www.a-g-t.com Regards John W. |
From: Damion S. <be...@cs...> - 2003-09-18 03:40:11
|
That's a great idea, thanks. It was bothering me a bit that people would have to pay money to use free software... As soon as it's released I'll give it a try. For maximum compatibility we may keep dual interfaces for a while (since it doesn't sound like that would be extra work), although if both FS2002 and 4 are supported there's probably not any reason to. Your project looks great by the way! Seems that not attempting to support everything under the sun has allowed you to progress quite a bit further in other areas. I'll be sure to give you a plug in the presentation I'm giving at the Avsim conference. Cheers, -Damion- On Wednesday, September 17, 2003, at 04:20 PM, Mic...@ai... wrote: > Hi Damion, > > This was an announcement made a few days ago on our new site > (www.flightdecksoftware.com) >> > FDS is proud to report that FDSConnect is now as good as ready and > will be > released within a few days. FDSConnect is a FSUIPC-like interface > towards > FS2004/2002. Much like FSUIPC, FDSConnect makes FS2004/2002 look like > FS98. > FS2004/2002 variables can be found at the same offsets they were in > FS98 > and currently are in FSUIPC. Unlike FSUIPC, FDSConnect is and WILL > REMAIN > freeware. For (freeware) developers who are, like us, very unpleased > with > the fact that FSUIPC/WideFS is now payware, switching to FDSConnect is > just > a matter replacing a few function calls. The first release of > FDSConnect > will be FS2004-only but as there are still numerous people flying > FS2002 > users we will work hard to get a FS2002 version ready within a few > Weeks. > Off course we are already working on FDSWideConnect, and FDSWideView > which > will both be released within a few weeks. > < > After reading your mail I thought this might interrest you. > Cheers, > Michael De Feyter --------- 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 remember how my great-uncle Jerry would sit on the porch and whittle all day long. Once he whittled me a toy boat out of a larger toy boat I had. It was almost as good as the first one, except now it had bumpy whittle marks all over it. And no paint, because he had whittled off the paint. |
From: <Mic...@ai...> - 2003-09-17 20:20:56
|
Hi Damion, This was an announcement made a few days ago on our new site (www.flightdecksoftware.com) > FDS is proud to report that FDSConnect is now as good as ready and will be released within a few days. FDSConnect is a FSUIPC-like interface towards FS2004/2002. Much like FSUIPC, FDSConnect makes FS2004/2002 look like FS98. FS2004/2002 variables can be found at the same offsets they were in FS98 and currently are in FSUIPC. Unlike FSUIPC, FDSConnect is and WILL REMAIN freeware. For (freeware) developers who are, like us, very unpleased with the fact that FSUIPC/WideFS is now payware, switching to FDSConnect is just a matter replacing a few function calls. The first release of FDSConnect will be FS2004-only but as there are still numerous people flying FS2002 users we will work hard to get a FS2002 version ready within a few Weeks. Off course we are already working on FDSWideConnect, and FDSWideView which will both be released within a few weeks. < After reading your mail I thought this might interrest you. Cheers, Michael De Feyter |
From: Damion S. <be...@cs...> - 2003-09-17 18:09:57
|
Hi, I talked to Pete Dowson, developer of FSUIPC, yesterday and verified where OpenGC stands in regards to working with the new payware version of FSUIPC. Basically, OpenGC will work fine without any special registration provided the user already has a registered copy of WideFS. A registered copy of FSUIPC is _not_ required, unless you want to run OpenGC on the same machine as the sim (which I discourage for performance reasons). This means that if you are using OpenGC with the FSUIPC data source, you should purchase your 3.0+ copy now to avoid problems when we make the switch (probably soon). I would like to have the switch accomplished before the Avsim conference next week, and will be out of town from Friday through the beginning of the conference, so this will likely happen tomorrow evening. Once the switch occurs, we will no longer support earlier (i.e. freeware) versions of FSUIPC. The payware version of FSUIPC will, however, work with older versions of Flight Simulator, so OpenGC will support those as well as the latest and greatest. 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-09-17 02:42:02
|
> IMO the FG side should do the flying (EOM), scenery, and systems > modeling. > The glass displays should act like the flightdeck receiving data from > the > aircraft systems. I agree with that setup. > So, yes one could allow the FG side to input VOR/Radio > frequencies by then you need to have some sort of signal/semaphore to > exchange to decide who has control. Actually, I don't think it's necessarily all that complicated. It depends on the data scheme, but as long as you assume that the sim is holding the "master copy" of things there's no problem. For each data cycle, OpenGC reads the state of the sim, displays the relevant stuff, and then writes whatever changes the user requests back to the sim (which I suppose would have the option of rejecting the input). > One advantage of using OpenGC is to reduce the CPU and GPU workload on > the > FG side. You can expect around a 15 to 20% inprovement in frame rate by > spreading out the work. Perhaps in regards to the cockpit displays, but I don't think the nav stuff requires all that much CPU. > Again, I've not kept pace with the lastest CVS, there may be some > legacy > code (circa 2001) that might still work with fgfs... Peraps Damion > could > address that better than I. Well, yes and no. I removed most of the bidirectional stuff when I converted to plib networking for flightgear. The old flightgear interface didn't work on Windows, whereas the new one does. I think the main issue now is exporting the nav needle positions correctly, which I don't think should be _that_ big of a deal. Cheers, -Damion- --------- 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 remember how my great-uncle Jerry would sit on the porch and whittle all day long. Once he whittled me a toy boat out of a larger toy boat I had. It was almost as good as the first one, except now it had bumpy whittle marks all over it. And no paint, because he had whittled off the paint. |
From: John W. <ca...@mm...> - 2003-09-16 22:19:52
|
Hi, The question is one of philosophy and division of labor... IMO the FG side should do the flying (EOM), scenery, and systems modeling. The glass displays should act like the flightdeck receiving data from the aircraft systems. So in that world the display code gets a lat and lon from the FG side and nav/radio data from the FG receivers. Given that setup, the display side needs a panel to tune radios and send the frequencies to the FG side receivers who search the nav world for in-range stations and return the appropriate data. There should be NO panel displayed on the FG side except perhaps for thr HUD Having said that I then turned around and violated my own reasoning and built a clone of the FG nav data base on the display side and modified the FG nav/radio code to support situations present in glass displays like multiple tuned in-range stations for MAP modes, auto-search/tuning when flying in LNAV mode, etc. The FG/OpenGC interface gets a bit complicated with all the hand-shaking required to do this and somewhat non-deterministic; i.e, the FMC auto-searches for in-range/tunable stations and may select several to perform a nav calculation or use an INS (lat/lon) as raw data or correlate with identified stations, especially when flying great circle routes. To mitigate the network traffic and the complexity inherent in a variable length data packet I again felt the clone approach was a reasonable compromise. So, yes one could allow the FG side to input VOR/Radio frequencies by then you need to have some sort of signal/semaphore to exchange to decide who has control. One advantage of using OpenGC is to reduce the CPU and GPU workload on the FG side. You can expect around a 15 to 20% inprovement in frame rate by spreading out the work. Again, I've not kept pace with the lastest CVS, there may be some legacy code (circa 2001) that might still work with fgfs... Peraps Damion could address that better than I. Regards John W. ----- Original Message ----- From: "Wendell Turner" <we...@ad...> To: <ope...@li...> Sent: Tuesday, September 16, 2003 2:02 PM Subject: [Opengc-devel] NavTestGauge > When using OpenGC with FlightGear, and displaying the > NavTestGauge, I can't get the vor or adf needles to > move. Is that porting working with fgfs? Are the > needles on OpenGC supposed to track/mimic the ones on > the fgfs panel? I've tuned the radios in fgfs, but > the needles on the NavTestGauge don't move. (Maybe > that is why it is called 'Test'?) > > Is there a better way to turn off the navaids > and smaller airports other than to edit apt.dat? > > Wendell > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel |
From: Damion S. <be...@cs...> - 2003-09-16 21:31:07
|
> When using OpenGC with FlightGear, and displaying the > NavTestGauge, I can't get the vor or adf needles to > move. Is that porting working with fgfs? There are actually two issues here. 1) Back when the FlightGear data source was designed, FlightGear did not support sending nav deflections to external software. OpenGC did all of these computations internally, based on its own model of the world. For simplicity (and to enforce conformance to the rest of the data sources) OpenGC no longer allows the data source to do that. So, no, I don't believe that FlightGear is currently capable of sending that data to OpenGC. This may/should be a fairly simple matter of updating the data output format in FlightGear, but to be honest I haven't done much work in that regards. Your best bet may be to get someone in FlightGear to volunteer to maintain the data source. The rewrite that I did a while back changed the networking behavior but did not update the data format in any way. 2) I didn't write the needle code on the nav display, so I can't guarantee that it would work even if FlightGear supported the appropriate data output. This issue is one I can handle pretty easily, and is on my list of things to do already (since it affects all of the data sources). > Is there a better way to turn off the navaids > and smaller airports other than to edit apt.dat? Not at this time, no. That's also on the short list of things to do. I added zoomin/zoomout buttons last night (which are in the CVS now) along with a ground track heading and speed indicator. Thresholding airports by runway length is one of the next things I'll be adding. For the time being, the nav display is not meant to mimic any particular aircraft model, merely to provide a platform for developing the core functionality (hence "test"). Any suggestions for nice things to have would be appreciated. Things which are already on my list include: 1) Verify needle and CDI functionality. 2) Range scale (to indicate approximate distances). 3) Better rendering of airports and navaids. 4) More complete data on airports and navaids (particularly runways and extended runway centerlines for airports). 5) More control over nav rendering (turn airports/navaids/etc. on/off) 6) Thresholding airports by max runway length Cheers, -Damion- --------- 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 remember how my great-uncle Jerry would sit on the porch and whittle all day long. Once he whittled me a toy boat out of a larger toy boat I had. It was almost as good as the first one, except now it had bumpy whittle marks all over it. And no paint, because he had whittled off the paint. |
From: Wendell T. <we...@ad...> - 2003-09-16 21:02:52
|
When using OpenGC with FlightGear, and displaying the NavTestGauge, I can't get the vor or adf needles to move. Is that porting working with fgfs? Are the needles on OpenGC supposed to track/mimic the ones on the fgfs panel? I've tuned the radios in fgfs, but the needles on the NavTestGauge don't move. (Maybe that is why it is called 'Test'?) Is there a better way to turn off the navaids and smaller airports other than to edit apt.dat? Wendell |
From: Damion S. <be...@cs...> - 2003-09-16 19:08:06
|
As you may be aware, the FSUIPC software that OpenGC uses to access the Microsoft Flight Simulator line has recently shifted to a payware model. I had explored getting OpenGC free access to FSUIPC through the author's freeware accreditation process, but it looks like the need to use the WideFS program will complicate this. Right now it appears that users will be required to register WideFS regardless of the status of OpenGC as accredited freeware or not. This means that going through the accreditation process, which would make the builds more complicated, is only worthwhile if we want to run on the same computer as FS2000x without WideFS. I have tended to discourage people from doing this because of the performance hit incurred, so it looks like the build process will be the same but users (and developers) will be required to register WideFS in order to use OpenGC with FS200x. This does NOT affect the use of OpenGC on Windows for data sources other than FSUIPC - it will still build and run the same, the only difference being that if you attempt to connect with an unregistered copy of WideFS it won't work. Because of library differences, we will no longer support versions of FSUIPC < 3.0. I'm still verifying with the author what exactly will need to be registered - just WideFS, or both WideFS and FSUIPC - in order to keep things running as they are, and will pass this info on once I know. For reference, current costs are $20 for either WideFS or FSUIPC, or $30 for both. Cheers, -Damion- --------- Damion Shelton The Open Source Glass Cockpit Project (OpenGC) Carnegie Mellon University, Robotics Institute http://www.opengc.org da...@op... |
From: Wendell T. <we...@ad...> - 2003-09-16 17:41:49
|
On Tue, Sep 16, 2003 at 01:23:51PM -0400, Damion Shelton wrote: > I would suggest that in general you try and stick with the versions of > the libraries that are included in the OpenGC repository Duh! I was just going off of the build web page, now I see that ExternalLibraries contains the 'right' versions of things. > So my understanding is that it's not even in alpha yet. I guess I should have read the fine print first! Thanks, Wendell |
From: Damion S. <be...@cs...> - 2003-09-16 17:23:47
|
Hi, I would suggest that in general you try and stick with the versions of the libraries that are included in the OpenGC repository (unless of course, I screw something up and those don't work either). I only switch to newer versions of the libraries if there's something new that they offer that's really compelling, because of problems like you encountered. > -- fltk-2.0.x bad; fltk-1.1.3-source.tar.gz good I think the FLTK problem deserves particular discussion - version 2.0 is _dramatically_ different than 1.x. The current CVS of 2.0 doesn't even build on the Mac, nor is it particularly stable on other platforms either. From the FLTK web page: "FLTK 1.1.x is the current stable release branch. FLTK 2.0 is currently in development and available via CVS. Please see the software page for details. The first 2.0 alpha releases will likely appear mid-2003, with a final release around the end of 2003." So my understanding is that it's not even in alpha yet. I'd really like to see 2.0 out and working, because we have some problems at work that are FLTK related and are unlikely to be resolved in the 1.x branch. Until then, I would suggest using a 1.1 release. Cheers, -Damion- --------- 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 hope that after I die, people will say of me: "That guy sure owed me a lot of money." |
From: Wendell T. <we...@ad...> - 2003-09-16 15:43:26
|
Thanks again for all of the work in OpenGC. A month or so ago I downloaded everything (onto RedHat Linux) and got it running. I tried it yesterday, getting the latest versions of everything, and things didn't go well. -- freetype-2.1.5 bad; freetype-2.1.4 good The latest FTGL references FT_Open_Flags, which is not in 2.1.5, but is in 2.1.4. -- fltk-2.0.x bad; fltk-1.1.3-source.tar.gz good In OpenGC, ogcRenderWindow.cpp includes FL/Fl.h, which isn't in 2.0.x. However, using earlier versions of those may have caused this error: Source/Base/main.o(.text+0x45): undefined reference to `fltk::repeat_timeout(float, void (*)(void*), void*)' I went back to the previous version from a month ago, and it works fine. Wendell |