Re: [Flightgear-devel] OT: Mojave, CA
Curtis L. Olson wrote: The other issue to consider is we could create the worlds most super whiz bang remote FDM interface, [...] I don't feel it's so much about whiz bang. To make those people happy (to whom I've been talking) I expect it would be sufficient to write down a bit pattern of the current version on your most preferred platform, declare this document as the 'official' FlightGear network FDM interface description and, this is actually the point, make sure that this doesn't change with the next version of FG or on another CPU. These people don't want to risk adjusting their FDM to a moving target. They'd like to see an interface that they can rely on - at least for a predictable amount of time instead of starting reverse-engineering with every new version. These people don't write their FDM in C, the way they generate FDM output probably differs significantly from the way the data is generated by FG itself (if used as a standalone FDM). That's all. This doesn't mean the interface has to be changeless for the next ten years. If the need arises to apply changes to the interface then you could simply update the interface description and point at the changes. 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] OT: Mojave, CA
Curtis L. Olson wrote: [...] However, it has only very basic out the window graphics. I'm doing a (hopefully quick little) project to build an interface from their software to FlightGear in order to use FlightGear as the visuals. Indeed this sounds interesting. Does it mean that FG will get a modern, full-featured and stable interface for external FDM's ? 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] OT: Mojave, CA
Martin Spott wrote: Curtis L. Olson wrote: [...] However, it has only very basic out the window graphics. I'm doing a (hopefully quick little) project to build an interface from their software to FlightGear in order to use FlightGear as the visuals. Indeed this sounds interesting. Does it mean that FG will get a modern, full-featured and stable interface for external FDM's ? Sounds like you probably have something more specific in mind than can be expressed in a single sentence. The particular adjectives you've chosen could be loaded with additional meaning (or not.) :-) I'm not aware of any industry standards that coule be targeted, even if we wanted to target something. From what I've seen, this stuff is very project (and aircraft) specific. As with any feature request, you are welcome to code something up yourself if the collective group isn't moving fast enough for you. :-) 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] OT: Mojave, CA
Hi Curt, Curtis L. Olson wrote: Martin Spott wrote: Indeed this sounds interesting. Does it mean that FG will get a modern, full-featured and stable interface for external FDM's ? Sounds like you probably have something more specific in mind than can be expressed in a single sentence. The particular adjectives you've chosen could be loaded with additional meaning (or not.) :-) Well, I prefer you to understand it as well-meant lobbying, driven by the strong feeling that FG needs this - not for me but for others who could do much more by connecting an external FDM to FG than I ever could. Just have a look at the CIGI Interface Control Document, they do care very much about defining the low-level protocol. Although CIGI isn't adequate for being used as FDM interface for FlightGear I find it very interesting to see how they approach the goal to offer a reliable interface to the developer. When I became aware of FG I first started looking for something like a remote FDM interface definition, but I was put off by the simply copy the struct way that I would have had to go. As I was quite uneducated in mangling other people's C++ code I grounded my project after a while. As you know I'm not the only one who felt offended by the mentioned 'interface'. Other people who actually _did_ interface to FG decided not to follow the ongoing changes and stick to old FG versions as long as there is no 'official' interface definition that they can expect to be stable and platform independent. Now as you aim to interface to a quite unrelated FDM I had the hope an interface definition that matches the forementioned attributes might evolve as a side effect. As with any feature request, you are welcome to code something up yourself if the collective group isn't moving fast enough for you. :-) I'll see, after never having coded in C from scratch before I now started this weekend to investigate how things would do - don't expect me to meet the speed of the moving group very soon ;-) 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] OT: Mojave, CA
Martin Spott wrote: Well, I prefer you to understand it as well-meant lobbying, driven by the strong feeling that FG needs this - not for me but for others who could do much more by connecting an external FDM to FG than I ever could. Just have a look at the CIGI Interface Control Document, they do care very much about defining the low-level protocol. Although CIGI isn't adequate for being used as FDM interface for FlightGear I find it very interesting to see how they approach the goal to offer a reliable interface to the developer. When I became aware of FG I first started looking for something like a remote FDM interface definition, but I was put off by the simply copy the struct way that I would have had to go. As I was quite uneducated in mangling other people's C++ code I grounded my project after a while. As you know I'm not the only one who felt offended by the mentioned 'interface'. Other people who actually _did_ interface to FG decided not to follow the ongoing changes and stick to old FG versions as long as there is no 'official' interface definition that they can expect to be stable and platform independent. Now as you aim to interface to a quite unrelated FDM I had the hope an interface definition that matches the forementioned attributes might evolve as a side effect. Well there is always a struggle between designing the perfect module or interface and getting things done. Too much designing and you can design something that can't be built in a finite/human time frame. With no design effort or advance thought, you end up with a big mess. So there needs to be a balance between the two ... obviously we want to get things done, but obviously we want to avoid big messes. There is a proposal on the table for a flexible binary structure similar to the generic protocol, but binary. But as far as I know, no one has started any coding. But, an FDM interface needs to do more than shove a datastructure back and forth. There needs to be some higher level communication to tell the remote FDM when it should reset it self or when it should trim for in air or on the ground, and what trim conditions are requested (i.e. start in air at 4500' MSL, 98 kts, 10 degree flaps, gear up, in a 20 degree right banking turn.) There are also very important and difficult timing issues to consider with a remote FDM. How those are handled can have a *huge* impact on the latency and smoothness of flightgear rendering. The other issue to consider is we could create the worlds most super whiz bang remote FDM interface, but you must remember that 99% of the time, people are trying to interface to remote FDM code that already exists. These people typically aren't going to want to spend months implimenting the other end of our super feature rich protocol, and the more complicated we get, the less they'll want to write the other end of it. As you suggest, passing a C struct over the net has some disadvantages, but it is simple, it is easy to code, it is efficient, and can be made to work very well. Most people doing this stuff are doing it on the same machine, or between similar machines. If endianness does pose a problem, these people are usually smart enough to quickly discover that and the fix is pretty easy (maybe a bit tedious but easy.) There are always a lot of factors that influence people's design decisions, and don't be too quick to rule out simple, easy, robust, quick to code As I'm sure you know there is room for many different interfaces within the FlightGear umbrella, so if anyone wants to do something better (or maybe I should say something with a different feature set and different strengths and weaknesses) we all would welcome it. In open-source, good ideas tend to succeed and grow, bad ideas tend to die on the vine ... but no one wants to stand in the way of anyone trying out a new idea ... that is one of FlightGear's core values. 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] OT: Mojave, CA
But, an FDM interface needs to do more than shove a datastructure back and forth. There needs to be some higher level communication to tell the remote FDM when it should reset it self or when it should trim for in air or on the ground, and what trim conditions are requested (i.e. start in air at 4500' MSL, 98 kts, 10 degree flaps, gear up, in a 20 degree right banking turn.) Also, it should be able to handle any number of engines (0 ... n), various arbitrary control surface arrangements, any number of landing gear or ground contacts, arbitrary flight control system, etc. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Mojave, CA
Jim Wilson wrote: BTW great pictures Curt. Sharp looking crew as well :-) And a very exciting flight story. The scariest jet airline flight I've been on was one that landed on Corfu and it was 100% routine. I have serious doubts that this jet could have stopped on the runway if an engine was out and beyond one end of the runway is water and buildings (houses, etc) on the other end. No room for overruns. When the aircraft finally braked to a stop, I actually thought we were a little off the end of the runway from the poor viewing angle I had in the cabin. The takeoff later was equally interesting, although by then I had convinced myself that they did this every day and we would make it, which we did. I had a flight out of Cuzco, Peru (we were up to see Macchu Pichu) that was interesting. The Cuzco airport is up about 11,500' MSL and we were flying out of there in an old beater Boeing 727. I had a stop watch so I started it when we began our take off roll. We got airborn and everything was normal, but because of the geography of the area, 5 full minutes into flight we were still seeing terrain straight out our window and still very close. That's not something I'm used to seeing around here in Minnesota. Anyway after all the exciting stories, is there anything more you are able to say about the simulator project mentioned top of the page? Let's see. The NTPS has some simulator software that is their own proprietary product. The strength of their software is that it is really well suited and tuned towards developing and evaluating the performance of a modern fly-by-wire aircraft (and is well proven in action.) However, it has only very basic out the window graphics. I'm doing a (hopefully quick little) project to build an interface from their software to FlightGear in order to use FlightGear as the visuals. 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] OT: Mojave, CA
On Fri, 05 Aug 2005 16:10:54 -0500, Curtis wrote in message [EMAIL PROTECTED]: The Draken is a really impressive bird, especially considering the era in which it was designed. The US is pretty cocky about stuff invented over here, but the Draken had some really impressive specs for it's day. ..me, I'm just wondering how their J22 would have done at altitude with turbos off interned B-17F|G's. http://anycities.com/user/j22/j22/ ;o) -- ..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] OT: Mojave, CA
Lee Elliott wrote: Liked the 3 engine 747 :) The Draken is an interesting a/c - I saw the one at Duxford, here in the UK, and was surprised at how close to the ground the wing trailing edge was. When looked at from the back I rather thought it looked like a huge moth. I don't know how much more work I'll do with the National Test Pilot School (pending the results of the current small project) :-) but if things go well, there may be some modeling work that needs to get done at some point. Any interest in that sort of thing, or do you keep busy enough with your day job and hobbies? The Draken is a really impressive bird, especially considering the era in which it was designed. The US is pretty cocky about stuff invented over here, but the Draken had some really impressive specs for it's day. To be honest, I stared and squinted at the real scene for the longest time trying to figure out if my eyes were playing tricks on me or what. It wasn't until I got to see the full digital picture that I figured out the 747 hump was behind the DC-10/MD-11. :-) 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] OT: Mojave, CA
From: Curtis L. Olson To be honest, I stared and squinted at the real scene for the longest time trying to figure out if my eyes were playing tricks on me or what. It wasn't until I got to see the full digital picture that I figured out the 747 hump was behind the DC-10/MD-11. How about 5 engines? http://photos.airliners.net/photos/9/6/7/635769.jpg This standard way to distribute emergency replacements. In fact I read somewhere that all 747's are built with the mount to transport replacement engines. Not sure if it is true, but it makes sense. BTW great pictures Curt. Sharp looking crew as well :-) And a very exciting flight story. The scariest jet airline flight I've been on was one that landed on Corfu and it was 100% routine. I have serious doubts that this jet could have stopped on the runway if an engine was out and beyond one end of the runway is water and buildings (houses, etc) on the other end. No room for overruns. When the aircraft finally braked to a stop, I actually thought we were a little off the end of the runway from the poor viewing angle I had in the cabin. The takeoff later was equally interesting, although by then I had convinced myself that they did this every day and we would make it, which we did. The fake snow in Mohave story reminds me of the time my father came back from a base in Florida where he conducted environmental testing on some electonic equipment. From what I understand they had a huge hanger (large enough to hold 2 C-5 aircraft with room to spare) down to -25F while it was over 90F outside. Now that's virtual reality. Anyway after all the exciting stories, is there anything more you are able to say about the simulator project mentioned top of the page? Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Mojave, CA
On Tuesday 02 Aug 2005 17:09, Curtis L. Olson wrote: In case anyone is interested in looking at airplane pictures, I just returned from a trip to Mojave, CA (KMHV) where I got to see a bunch of neat aviation stuff. I took some pictures and posted them here: http://www.flightgear.org/~curt/Photos/KMHV/ Mojave is home to a lot of wind mills on the ridge overlooking town, home to Scaled Composites (Burt Rutan/Space Ship One), Orbital Dynamics, the Rotary Rocket (tm), an aircraft boneyard, and the National Test Pilot School ... lots of neat toys, aircraft restoration, research, development, and other projects going on out there. There's also a lot of heat, desert, tumbleweeds, and a whole lot of nothing once you get off the airport property. Curt. Liked the 3 engine 747 :) The Draken is an interesting a/c - I saw the one at Duxford, here in the UK, and was surprised at how close to the ground the wing trailing edge was. When looked at from the back I rather thought it looked like a huge moth. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
