Re: [Flightgear-devel] Driving real instruments.
John Wojnaroski wrote: Dave Martin wrote: Unfortunately my total lack of software development skills and apparent numerical dyslexia would preclude this. That is, unless now or in the future enough people might become interested in doing this (I may not code but I'm quite the engineer when it comes to physical stuff ;) ) I think I could drive an ASI, AI, TC, VSI and engine guages using Phidgets just by writing FG values to a phidgets device in the correct sense but anything more is rocket-science to me due to the code involved. http://www.f15sim.com/index.html is a website you might try. He is using Phidgets to drive some of his gauges. Don't have the details. Phidgets are insanely easy to drive. Right now the only gauges I'm driving are 1" custom built steam gauges for the oil & hyd pressure. They use ultra-micro Futaba servos with a 2:1 gear ratio to drive the pointer. You might want to head over to http://www.mikesflightdeck.com if you want to see how to scratch build your own gear. g. -- "I'm not crazy, I'm plausibly off-nominal!" Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tue, October 25, 2005 5:18 pm, John Wojnaroski said: > The boards Curt refers to were specifically designed for a 747 > simulator. They will read analog, discrete inputs, rotary encoders but > are not designed to drive anything other than digital signals. Would > need a bit more design and rework to handle the current loads of DC > motors or servos, control, etc. (See earlier post) How about the analogue output boards on http://cockpit.varxec.net/ -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Curtis L. Olson wrote: Dave Martin wrote: Well, I think I could get the adjusters in place (experimentation time) My next question would have to be (bear with me) Does FreeGLUT support multiple mice yet? Alternatively, does FreeGLUT rely on X11 for it's mouse definitions. I think I may have found a method in X.org which will allow multiple USB mice to behave as a single 'logical' mouse - albeit with loads of scroll-wheels etc. ;) The idea being that a mouse is possibly the cheapest off-the-shelf 'encoder' on the market (not strictly an encoder but good for the purpose). Not sure about x.org's limitations but the USB interface will support 127 devices per channel; more than enough for a light-aircraft cockpit interface. It's cheap and you get what you pay for. Not enough bits and resolution and you still face the problem of now writing some sort of driver that handles the USB connections and converts the GLUT mouse inputs to something meaningful to drive your gauges. And you still have to handle the physical design problem. Thinking it's better to start with a clean piece of paper. Again, phidgets are worth a look. The software problem is also cleaner than a X-11/GLUT hack and can be worked. John Wojnaroski is developing some interesting switch, button, light interfacing hardware that plugs into your computer via usb. I don't know if it has any A2D or D2A capabilities. It sounds really promising though. Hopefully he will jump in here with details as his time permits. Curt. The boards Curt refers to were specifically designed for a 747 simulator. They will read analog, discrete inputs, rotary encoders but are not designed to drive anything other than digital signals. Would need a bit more design and rework to handle the current loads of DC motors or servos, control, etc. (See earlier post) Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tue, 25 Oct 2005 13:59:31 +0100, Dave wrote in message <[EMAIL PROTECTED]>: > Just wondering if anyone (pos historically) has driven physical > instruments using FlightGear on Linux. > > I'm thinking the analog variety (ASI AI ALT etc) from the likes of > SimKits. Obviously the SimKits stuff couldn't work directly because > their proprietary software to drive the CCU is for Windows and MSFS > only. > > So are there, or have there been any examples of someone succesfully > driving analog instruments using FlightGear on Linux? ..the closest thing I'm aware of this far, would be the Discovery TV show on Red Baron's (Richthofen) final dog fight, they used FG and a commercial FS (MSFS?) hooked up together. I think Michael Selig at UIUC was involved, Michael, Curt? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Unfortunately my total lack of software development skills and apparent numerical dyslexia would preclude this. That is, unless now or in the future enough people might become interested in doing this (I may not code but I'm quite the engineer when it comes to physical stuff ;) ) I think I could drive an ASI, AI, TC, VSI and engine guages using Phidgets just by writing FG values to a phidgets device in the correct sense but anything more is rocket-science to me due to the code involved. http://www.f15sim.com/index.html is a website you might try. He is using Phidgets to drive some of his gauges. Don't have the details. I think most of the Phidget software is MS Windows based although some of it is being ported to Linux ( how much and when I don't know ) I might be wrong and have not examined any of the software or interfaces closely but I think you'll need to do more a bit more than just write FG values to a device. If Phidgets aren't the answer, might consider breadboarding up a circuit via a USB I/O port along with the software. I've been working on some electronics for a slightly different application, but this might be an interesting derivative. If you want to handle the physical stuff, I could find some time to help with the electronics and software. You can contact me off-list at [EMAIL PROTECTED] Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 16:45, Curtis L. Olson wrote: > We are using multiple machines, one for each display. My feeling is > that if it is a bit excessive, it is only a small bit excessive and I > can put up with it. :-) You are welcome to try running a multiheaded > machine (with support for opengl on all your displays.) I'd be > interested in hearing your results. > I had a go at this a while back using the nvidia proprietary driver's TwinView option. TwinView can be configured to stretch the X display across 2 screens and provide acceleration on both. The nvidia driver hides the fact that the display spans two screens. So 2x 1024x768 displays are presented to the X server as a single 2048x768 wide screen. Using FlightGear across both of the displays is as simple as launching with --geometry=2048x768 and the performance is the same as you'd expect displaying the same size window on a single display. You can adjust the FOV to say 90deg to give a realistic panorama and I'd love to try it with two projectors :) Note that I tried --enable-game-mode but didn't get it working, however I'm sure this was down to my setup at the time and not the TwinView config. For displaying a panel (and avoiding the performance hit of two instances) perhaps you could configure the TwinView as 'top and bottom' monitors, the top one providing the out-the-window view and the bottom one showing the panel. The panel would probably have to be specifically designed to only fill 1/2 your display area - the 610x panel seems to scale to the longest edge in all circumstances. Personally, I'd favour the aforementioned 2 systems, one for panel, FDM, input and sound and one (or more) for the out-the-window view. (Hopefully thereby boosting the 3d display's performance a bit?) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: What is the reason for using a dual-core machine for each 'out the window' view? It allows you to load the scenery without seeing glitches or hick-ups in the rendering thread. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Well, I think I could get the adjusters in place (experimentation time) My next question would have to be (bear with me) Does FreeGLUT support multiple mice yet? Alternatively, does FreeGLUT rely on X11 for it's mouse definitions. I think I may have found a method in X.org which will allow multiple USB mice to behave as a single 'logical' mouse - albeit with loads of scroll-wheels etc. ;) The idea being that a mouse is possibly the cheapest off-the-shelf 'encoder' on the market (not strictly an encoder but good for the purpose). Not sure about x.org's limitations but the USB interface will support 127 devices per channel; more than enough for a light-aircraft cockpit interface. John Wojnarowski is developing some interesting switch, button, light interfacing hardware that plugs into your computer via usb. I don't know if it has any A2D or D2A capabilities. It sounds really promising though. Hopefully he will jump in here with details as his time permits. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Buchanan, Stuart wrote: How are you driving the panel? From the same box as the cockpit view (multiple FG instances?)or by using multiple machines? I'm quite interested in the possibilities of multi-display setups, but it feels a bit excessive to have a box just dedicated to displaying a panel. We are using multiple machines, one for each display. My feeling is that if it is a bit excessive, it is only a small bit excessive and I can put up with it. :-) You are welcome to try running a multiheaded machine (with support for opengl on all your displays.) I'd be interested in hearing your results. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 15:34, Curtis L. Olson wrote: > There are adjustments in the proper place on the panel. I'm just a > software guy, so I don't know all the hardware tricks that are being > done. But I do know the end result has a nice solid feel and is very > convincing. > > Curt. Well, I think I could get the adjusters in place (experimentation time) My next question would have to be (bear with me) Does FreeGLUT support multiple mice yet? Alternatively, does FreeGLUT rely on X11 for it's mouse definitions. I think I may have found a method in X.org which will allow multiple USB mice to behave as a single 'logical' mouse - albeit with loads of scroll-wheels etc. ;) The idea being that a mouse is possibly the cheapest off-the-shelf 'encoder' on the market (not strictly an encoder but good for the purpose). Not sure about x.org's limitations but the USB interface will support 127 devices per channel; more than enough for a light-aircraft cockpit interface. Cheers. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
> > A really good setup requires the following: > > * The server, displaying the panel and running the FDM. > * A dual core machine for every display as a slave to the main server. > > Erik What is the reason for using a dual-core machine for each 'out the window' view? (Asking out of ignorance) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Buchanan, Stuart wrote: How are you driving the panel? From the same box as the cockpit view (multiple FG instances?)or by using multiple machines? I'm quite interested in the possibilities of multi-display setups, but it feels a bit excessive to have a box just dedicated to displaying a panel. A really good setup requires the following: * The server, displaying the panel and running the FDM. * A dual core machine for every display as a slave to the main server. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
> For the FAA Level 3 FTD certified sims I work with, > we draw the > instruments on an LCD screen, then place a panel > cutout with bezels on top of that. How are you driving the panel? From the same box as the cockpit view (multiple FG instances?)or by using multiple machines? I'm quite interested in the possibilities of multi-display setups, but it feels a bit excessive to have a box just dedicated to displaying a panel. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Just another quick thought on this idea. (I'd like to try it) If I've got my facts right, a standard gauge is about 3 1/8inch (approx 80mm) diameter mount. So does that suggest a 19inch or 20inch LCD screen for the c172-610x panel? I don't recall the exact dimensions but I'm sure it's somewhere in that neighborhood. I've also had a couple of bright ideas for providing gauge adjustment controls infront of the LCD, do you have a trick to do this or do you set them separately (via a normal key/mouse interface)? There are adjustments in the proper place on the panel. I'm just a software guy, so I don't know all the hardware tricks that are being done. But I do know the end result has a nice solid feel and is very convincing. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 14:07, Curtis L. Olson wrote: > For the FAA Level 3 FTD certified sims I work with, we draw the > instruments on an LCD screen, then place a panel cutout with bezels on > top of that. Fools a *lot* of people into thinking they are real, even > though they aren't. Just another quick thought on this idea. (I'd like to try it) If I've got my facts right, a standard gauge is about 3 1/8inch (approx 80mm) diameter mount. So does that suggest a 19inch or 20inch LCD screen for the c172-610x panel? I've also had a couple of bright ideas for providing gauge adjustment controls infront of the LCD, do you have a trick to do this or do you set them separately (via a normal key/mouse interface)? Thanks -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
"Curtis L. Olson" wrote: > [...] The simkits stuff are driven by standard servos, > right? So you could get a little PIC board to run your servos and take > position commands in from the serial port ... then you just need to send > the data out the serial port from FG (with perhaps a small amount of > interface coding.) I could be easier than that. You can buy ready-to-run serial interface boards with several PWM outputs - you just need the ability to define an output bit mask in FlightGear in which you compile the desired output values. For the other direction there are simple analogue to serial converters, some even directly attached to a potentiometer that you can use to set the altimeter QNH. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 14:07, Curtis L. Olson wrote: > For the FAA Level 3 FTD certified sims I work with, we draw the > instruments on an LCD screen, then place a panel cutout with bezels on > top of that. Fools a *lot* of people into thinking they are real, even > though they aren't. I did think of this trick too :) Although it also threw up a problem.. > The simkits stuff are driven by standard servos, > right? So you could get a little PIC board to run your servos and take > position commands in from the serial port ... then you just need to send > the data out the serial port from FG (with perhaps a small amount of > interface coding.) It might be a little time consuming to get all the > pieces in place and working, but once you figure out how to generate the > PWM servo signal, there's nothing technically difficult there. > > Curt. The problem being the 'setting' of an instrument. If you wanted to directly set an instrument you'd need some sort of encoder (eg: to rotate a VOR direction wheel). This could be done easily enough, of course, in the case of the LCD behind the panel, the major hurdle being the depth of the control in the panel. When it comes to physical gauges, the system itself would need to know the precise position of a direction wheel so it would have to be read from a sensor in the instrument (SimKits do this). The only way forward I spotted was using 'Phidgets' interface cards to run the servos and also read from analog sensors in the instruments. Unfortunately my total lack of software development skills and apparent numerical dyslexia would preclude this. That is, unless now or in the future enough people might become interested in doing this (I may not code but I'm quite the engineer when it comes to physical stuff ;) ) I think I could drive an ASI, AI, TC, VSI and engine guages using Phidgets just by writing FG values to a phidgets device in the correct sense but anything more is rocket-science to me due to the code involved. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Just wondering if anyone (pos historically) has driven physical instruments using FlightGear on Linux. I'm thinking the analog variety (ASI AI ALT etc) from the likes of SimKits. Obviously the SimKits stuff couldn't work directly because their proprietary software to drive the CCU is for Windows and MSFS only. So are there, or have there been any examples of someone succesfully driving analog instruments using FlightGear on Linux? For the FAA Level 3 FTD certified sims I work with, we draw the instruments on an LCD screen, then place a panel cutout with bezels on top of that. Fools a *lot* of people into thinking they are real, even though they aren't. The simkits stuff are driven by standard servos, right? So you could get a little PIC board to run your servos and take position commands in from the serial port ... then you just need to send the data out the serial port from FG (with perhaps a small amount of interface coding.) It might be a little time consuming to get all the pieces in place and working, but once you figure out how to generate the PWM servo signal, there's nothing technically difficult there. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Driving real instruments.
Just wondering if anyone (pos historically) has driven physical instruments using FlightGear on Linux. I'm thinking the analog variety (ASI AI ALT etc) from the likes of SimKits. Obviously the SimKits stuff couldn't work directly because their proprietary software to drive the CCU is for Windows and MSFS only. So are there, or have there been any examples of someone succesfully driving analog instruments using FlightGear on Linux? Cheers -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
