[Flightgear-devel] Re: Laptop
From: Chris Horler <[EMAIL PROTECTED]> > Are the problems you're experiencing with > the drivers only experience on a 64 bit system? No. The driver is completely unusable in 64 bit mode. In 32 bit mode, it works fine providing you don't try to use the most recent kernel. The 2.4.x series is fine, as is 2.6.5, but the more recent ones aren't. > What are the power saving features like for this driver? Can you configure > anything worthwhile? I haven't tried. It doesn't appear to have any ACPI support, for example. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor => A FlightGear based interactive Training Concept
Would you mind posting the link to your site and forum again? Thanks in advance, Ampere On July 12, 2004 11:06 pm, Boris Koenig wrote: > I > would really like to ask you to *use* the forum ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor => A FlightGear based interactive Training Concept
Ampere K. Hardraade wrote: On July 12, 2004 08:44 pm, Oliver C. wrote: For example a voice of a pilot instructor could be played that explains what to do next, like turning to heading 230. May be we can also have dynamic responses during a lesson, where the instructor can tell you things like "too fast", "too slow", "too high", "too low", etc. This is -again- a request that has also been made by other users, I would really like to ask you to *use* the forum - that way everybody would be able to see what's been requested so far and we could even introduce polls in order to see what's important to the community. It will be a good idea if we can find a text-to-speech engine to do the voice instead of using recordings. Not only will this save us a lot of space, but it will also be more flexible. lol, that's weird: I just wrote exactly that 2 minuts ago :-) There are various speech-synthesis tools for unix, the mentioned "festival" being the most prominent one - though I am not sure if any of these could be easily used under windows, but it shouldn't be that much of a problem, because the Microsoft Speech SDK is fairly simple to use - and one could easily write an abstraction layer that could take care of the subtleties for each TTS-system - but also operating system. If I remember correctly the FreeTTS can also be used under windows- gonna have to check it out, though. Just checked google - looks pretty good: http://linux-sound.org/speech.html and festival can be found at: http://www.cstr.ed.ac.uk/projects/festival/download.html regards - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor => A FlightGear based interactive Training Concept
good morning ! Oliver C. wrote: On Tuesday 13 July 2004 00:25, Boris Koenig wrote: It wouldn't matter if FlightGear needs to be running directly or if only subsystems get called. I would like to have it integrated into FlightGear, so that the user can start the lessons from FlightGear in the Sim/Game menu. yes, that's also something I'd like to see ultimately, and I didn't mean to imply that FliteTutor should be run externally - just the way the actual interfacing takes place wouldn't be that important to me. But as I said already: IF Nasal can be used/extended for my purposes, I would love to use it. Using Nasal would really simplify many things- e.g. you wouldn't even need to compile yet another package to get FliteTutor to work - also, and even more important: I wouldn't have to mess around with the FlightGear code ;-) The lessons could then be picked up in a separate list menu or a menu where the lessons are organized by the required skill level or training tour (basic flying, VFR flight, instrument flight etc.). yes, it's good that you mention this here - you are the 4th user so far requesting some kind of categorization for FliteTutor units to take place. And we've made already some drafts for potential categories, some of which comprise: The two global categories: GROUNDSCHOOL or FLIGHT TRAINING (the difference MAINLY being the variying demands for subsystems to be loaded/running) Both gobal categories would then contain categories named "VFR" and "IFR" to separate lesson units. We could then add general categories such as "Instrument Interpretation" to the relevant sub-menus. This would be where the final learning units get stored - probably using a title and a short description to be displayed in some kind of "quick-browser" to get an impression of the outline of a specific unit. But regarding this categorization thing there were really plenty of ideas, some of which even suggesting a user rating for each unit, so that users can provide direct feedback to an author of a FliteTutor lesson-I really can't complain that there are too few ideas for FliteTutor ;-) It seems to be mainly a matter of getting the thing rollin'... Unfortunately, people keep contacting me privately be email in order to make such suggestions instead of directly using the forum or at least this mailing list ;-) - hence, it's likely that many suggestions are repeatedly being made, but so far I've written everything down that I received. But I would like to ask you to post your ideas and suggestions in the forum - that way we have them in a central place and everybody could see what's been suggested so far-there's no need to register in order to post anything in the forum. Also, as I mentioned already on the webpages, I am going to add those features most frequently requested to the "features" section on the webpage. if you want me to, I can go into even further detail :-) A webpage with example screenshot drawings with these step by step explanations would be nice. :) Well, what do you expect: the FliteTutor webpages are not even 4 days old... Actually, I meanwhile have indeed been contacted by some users who would be willing to help FliteTutor become a bit more than just a vague idea-a lot earlier than I had anticipated. So, we are currently about to collect all feature requests and connect them to our own ideas & imaginations - and try to get a working draft for a concept. But this may still take some time. I am also going to send a notification to this list as soon as the first detailed draft for a concept has been finished and when we've put it on the webpage. Particularly, in order to get some feedback about the overall feasibility of all this. But due to the various feature requests that I've received so far, we will have to concentrate mainly on those features that are realistic to be implemented easily into a first coding attempt - which does not mean that anybody should stop sending in "utopic" suggestions :-) (But please try to use the forum, it makes things easier) Anyway, I do intend to offer some graphical representation of the goals behind FliteTutor - actually, also in order to make the whole thing easier to grasp and to attract those people to keep on reading who don't like to read ;-) Well, I hope it's now easier to understand what I would like to achieve with FlightGear. Yes. Glad to see, but now tell me HONESTLY: how thorougly did you *really* _read_ the webpages ? :-) BTW, i like the idea very much. ;) yes, thanks - strange thing being though: people keep telling me how much they like the idea but fail to leave a vote on the webpage- well at least during the first 2 days, now the situation has already somewhat "improved" ;-) It would be also very nice, if FliteTutor could be used for in flight lessons. You are again requesting something that has already been requested, and I do wholeheartedly agree with you, but personally I consider it unlikely to be added to a todo list that soon,
Re: [Flightgear-devel] Re: Laptop
On Monday 12 July 2004 00:39, Arnt Karlsen wrote: > ..http://www.google.com/search?q=laptop+replacement+battery > returns 577,000 hits, FWIW, auxillary drops those hits to 17200: > http://www.google.com/search?q=laptop+auxiliary+battery > One thing to consider also is a 12V DC to 16-20V DC convertor (~20 UKP) and a sealed car/motorcycle battery (20+ UKP). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor => A FlightGear based interactive Training Concept
On July 12, 2004 08:44 pm, Oliver C. wrote: > For example a voice of a pilot instructor could be played > that explains what to do next, like turning to heading 230. May be we can also have dynamic responses during a lesson, where the instructor can tell you things like "too fast", "too slow", "too high", "too low", etc. It will be a good idea if we can find a text-to-speech engine to do the voice instead of using recordings. Not only will this save us a lot of space, but it will also be more flexible. > And for showing how to fly a special flight maneuver we could use > transparent squares with visible borders that are placed in the air and > describe the flight path that should be flown. For that, an invisible near-flat-cylinder will be more appropiate. For the border, we can have a bunch of trianglar prisms pointing toward the center of the cylinder. This will allow the border to resize independently from the target so that the user can see it no matter how far he is. Of course, if the user is too far from the target, the target itself will need to be bigger as well; otherwise the triangles will get cluttered together. Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor => A FlightGear based interactive Training Concept
On Tuesday 13 July 2004 00:25, Boris Koenig wrote: > > What exactly are you trying to do, create a separate program that runs > > portions of FlightGear in a (sub)window, or do you want to use > > FlightGear (the user would indeed start fgfs then) and add a menu > > structure that guides the user while flying? > > Actually, neither the former, nor the latter: > > What I want to do is actually be able to use FlightGear -and its > subsystems- as a backend for a basic presentation system for > (aviation related) - CBT / learning purposes. > Hence, I would need to have pretty much full access to most of the > subsystems - either using an API or the integrated scripting > language nasal. > > It wouldn't matter if FlightGear needs to be running directly or > if only subsystems get called. I would like to have it integrated into FlightGear, so that the user can start the lessons from FlightGear in the Sim/Game menu. The lessons could then be picked up in a separate list menu or a menu where the lessons are organized by the required skill level or training tour (basic flying, VFR flight, instrument flight etc.). > > Basically, the following would be an example scenario for a > beta - FliteTutor learning unit using nasal: > > 1)Run FlightGear - optionally providing a nasal script file as > parameter - OR load that script file from within fgfs as soon > as FlightGear has booted and is running. > > ==> This nasal file should then perform the following > actions: > > a) disable (or not even load during startup) all > those FlightGear sub-systems that aren't required > by that specific FliteTutor module - i.e. the > rendering of the outside view, and disable the > things like the panel view. > What we would then basically have is an "empty" > FlightGear window (so, not even a panel !) > > b) draw some basic GUI components such as > "previous/back"-buttons in the empty client area at > certain coordinates - these controls would serve the > purpose to allow basic CBT-like navigation within > FlightGear. Also it might be - depending on the lesson- > necessary to draw other GUI elements such as checkboxes > or dropdown menus at certain coordinates. > (Originally, I had hoped to be able to use the PLIB GUI > functions for that purpose, but if these possibilites > also exist through nasal bindings, all the better !) > > > c) register specific events for these controls to be > triggered for certain actions > (like "button [next] got clicked" => "do: next page") > > > d) load a specified gauge/instrument from the FlightGear > base directory (e.g. a standard VOR) > > e) display that gauge/instrument at a a certain position > on the screen, optionally also set custom dimensions (as > it would be useful to have a really large view of an > instrument in order to illustrate its workings) > > f) display certain text (explanations) at a certain > position - probably either close to the instrument, in > a specific "textbody" (GUI-element) or even rendered as > a separate layer above the displayed instrument in order > to explain the instrument itself. > > g) register a message handler loop, that waits for > specific events to be triggered - e.g. to allow > monitoring if a user follows the CBT instruction to > set the VOR OBS to radial 290 or not - based upon > this validation the script could give a warning or > even hint. > > => At this point we would be able to dynamically > illustrate the workings of a VOR indicator by > either automatically animating the instrument > and displaying explanations OR by displaying > instructions for the user to use/interpret the > instrument and actually have a readout of user > actions. > > h) depending on the triggered events, it should be > possible to go to the next section of a "lesson" > or replay a certain animation etc. > > if you want me to, I can go into even further detail :-) A webpage with example screenshot drawings with these step by step explanations would be nice. :) > > Well, I hope it's now easier to understand what I would like to achieve > with FlightGear. Yes. BTW, i like the idea very much. ;) > > I guess you just want to disable the out-of-the-window view. This is > > handled by setting "/sim/rendering/draw-otw" to false. >
[Flightgear-devel] Problem with game menu when switching to wireframe mode
Hello, today i played around with the wireframe mode which can be activated in-game by starting flightgear with the option "--enable-wireframe" or by setting in the property menu "/sim/rendering/wireframe" to true. But when i do this the in-game menu gets useless because the fonts used in the in game menu get scarcely visible. To solve that, the in-game menu and its fonts shouldn't be affected by setting the wireframe mode to true. Can someone fix this? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor => A FlightGear based interactive Training Concept
...if you need pen-pals subscribe to a mailing list ;-) Erik Hofman wrote: Boris Koenig wrote: So I hope to know now for example that nasal's lack of threadsafety is unlikely to become an issue, as not nasal itself would handle things like animations but rather a specific subsystem - that nasal would only access to provide the necessary parameters - correct ? Hmm, well yeah. Sort off ... I'm not quite sure why you still want code to be thread safe. I've got the feeling we're not exactly talking about the same issue. Probably you are right, I was just referring to this as an example because when I first read about nasal a couple of days ago I was under the impression that you would directly use nasal to *animate* an instrument.So, doing something like that in parallel with other actions, like processing a message loop to wait for user events might have been a problem. What exactly are you trying to do, create a separate program that runs portions of FlightGear in a (sub)window, or do you want to use FlightGear (the user would indeed start fgfs then) and add a menu structure that guides the user while flying? Actually, neither the former, nor the latter: What I want to do is actually be able to use FlightGear -and its subsystems- as a backend for a basic presentation system for (aviation related) - CBT / learning purposes. Hence, I would need to have pretty much full access to most of the subsystems - either using an API or the integrated scripting language nasal. It wouldn't matter if FlightGear needs to be running directly or if only subsystems get called. I want to be able to make use of a subsystem - either by calling it directly or using means like those that are provided via nasal. As the FliteTutor webpages don't seem to be precise enough on that yet, I am going to give a more in depth example, I would definitely appreciate getting your views about that. Basically, the following would be an example scenario for a beta - FliteTutor learning unit using nasal: 1) Run FlightGear - optionally providing a nasal script file as parameter - OR load that script file from within fgfs as soon as FlightGear has booted and is running. ==> This nasal file should then perform the following actions: a) disable (or not even load during startup) all those FlightGear sub-systems that aren't required by that specific FliteTutor module - i.e. the rendering of the outside view, and disable the things like the panel view. What we would then basically have is an "empty" FlightGear window (so, not even a panel !) b) draw some basic GUI components such as "previous/back"-buttons in the empty client area at certain coordinates - these controls would serve the purpose to allow basic CBT-like navigation within FlightGear. Also it might be - depending on the lesson- necessary to draw other GUI elements such as checkboxes or dropdown menus at certain coordinates. (Originally, I had hoped to be able to use the PLIB GUI functions for that purpose, but if these possibilites also exist through nasal bindings, all the better !) c) register specific events for these controls to be triggered for certain actions (like "button [next] got clicked" => "do: next page") d) load a specified gauge/instrument from the FlightGear base directory (e.g. a standard VOR) e) display that gauge/instrument at a a certain position on the screen, optionally also set custom dimensions (as it would be useful to have a really large view of an instrument in order to illustrate its workings) f) display certain text (explanations) at a certain position - probably either close to the instrument, in a specific "textbody" (GUI-element) or even rendered as a separate layer above the displayed instrument in order to explain the instrument itself. g) register a message handler loop, that waits for specific events to be triggered - e.g. to allow monitoring if a user follows the CBT instruction to set the VOR OBS to radial 290 or not - based upon this validation the script could give a warning or even hint. => At this point we would be able to dynamically illustrate the workings of a VOR indicator by either automatically animating the instrument and displaying explanations OR by displaying instructions for the user to us
[Flightgear-devel] autopilot properties
What is the difference in these properties?
/autopilot/route-manager/wp-last/id ='' (none)
/autopilot/route-manager/wp/id = 'KANP' (string)
/autopilot/settings/route-manager/wp/id ='KGAI' (string)
They seem to be overshadowing each other. Have some of these
been superceeded by the new route-manager code? Which one is
the official next waypoint? (Or is it some artifact of nasal
generating new branches of the property tree?)
Or yet, is mucking with the property tree via fgTie/xxSet/xxGet
the proper way to change these, or would a better method be via
a nasal script, for example, that calls something like:
autopilot.update("hdg-true")
If so, then how does an external program call a nasal script to
change things (like the telnet interface does)?
Wendell
-
Friends don't let friends squawk 1200.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor => A FlightGear based interactive Training Concept
Boris Koenig wrote:
So I hope to know now for example that nasal's lack of threadsafety
is unlikely to become an issue, as not nasal itself would handle things
like animations but rather a specific subsystem - that nasal would only
access to provide the necessary parameters - correct ?
Hmm, well yeah. Sort off ...
I'm not quite sure why you still want code to be thread safe. I've got
the feeling we're not exactly talking about the same issue.
What exactly are you trying to do, create a separate program that runs
portions of FlightGear in a (sub)window, or do you want to use
FlightGear (the user would indeed start fgfs then) and add a menu
structure that guides the user while flying?
The first one would be really hard to implement I'm afraid. The latter
doesn't require thread safety IMHO.
But to get back to that, Nasal doesn't run all the time. It gets
triggered by an event, does what is required and then waits for the next
trigger. A trigger could be a timer, and the code could be setting a
property that triggers the animation code to change something.
All subsystems are almost self containing. Most of the time they only
read the values of some properties, and sometimes they alter other
properties. This is FlightGear's way of communicating between subsystems.
As I don't know -yet- how to access FlightGear's subsystems from a
language like nasal, I am currently definitely likely to indeed
-reinvent the wheel- in order to resemble the beviours and functionality
that I need. I do want to prevent that as well !
Most of the time you really don't want to access the subsystems, but
instead you tell the subsystems what should happen. In most cases that's
setting or altering a small set of properties(*) and the particular
subsystem acts upon the changed properties.
For example,
If you want to animate the gear of an aircraft you would have to write
an XML based configuration file that performs an animation type on the
3d model object name, using the input of a property:
From FlightGear/data/Aircraft/c310/Models/c310-dpm.xml
rotate
NoseWheel
/gear/gear[0]/position-norm
120
-120
-90
0
-2.28
0.0
0.035
0
1
0
Here you tell the animation subsystem to rotate the 3d object named
"NoseWheel" based on the value of the property located at
gear/gear[0]/position-norm
This property is currently altered by the FDM (Yasim, JSBSim or
UIUC/LaRCsim), but for the AIModels it could be altered bu a Nasal
script like this:
based on the animation code of the bo105 located at
FlightGear/data/Aircraft/bo105/Models/bo105.nas
# gear
pos = props.globals.getNode("gear/gear[0]/position-norm", 1);
swingTime = 2.5;
target = 1;
toggleGear = func {
val = gear.getValue();
time = abs(val - target) * swingTime;
interpolate(gear, target, time);
target = !target;
}
You see, there are two configuration files (one for each subsystem) that
work together using the property tree.
That's usually the problem if you don't have the necessary information
available.
There is some information at:
FlightGear source in FlightGear/docs-mini
The base package in FlightGear/data/Docs
The webpage in:
SimGear:http://simgear.org/doxygen/
FlightGear: http://flightgear.org/docs.html
Nasal can also read and modify properties but it can also be
incorporated into the menu system.
There is a (comprehensive) example available in
FlightGear/data/gui/dialogs/autopilot.xml
Would you mind letting me know, which source files are responsible
for the menu-access (like adding/removing items) ?
So that I can look up the exact usage ?
That all done using XML (look in the FlightGear/data/gui subdirectory
for the complete configuration of the menu layout).
Because my current set of goals would then be to really drop the
C++/PLIB idea and try to give nasal a go:
This combination would allow one to design a menu system that:
1. pauses displays a dialog and pauses the simulator.
2. waits for the user to confirm the dialog.
3. alters one or more properties (change view for example)
4. starts the simulator again.
5. waits for a certain property to change
6. goto 1.
...for the nasal attempt to work, I would like to start by creating a
simple script file which, when loaded by FlightGear, would disable
subsystems like terragen (that aren't necessary at the current
stage for FliteTutor) and continue adding custom menus to the
FlightGear menu, in connection with the necessary hooks to be called
when selected.
TerraGen is actually a separate program to build the scenery data. I
guess you just want to disable the out-of-the-window view. This is
handled by setting "/sim/rendering/draw-otw" to false.
I think this is already most of what you are looking for.
You are probably right, but I would still need to know, what specific
subsystem/properties to access (and what parameters to provide) in order
for example to be able to do things such as:
- load/display an instrument at
Re: [Flightgear-devel] Re: Laptop
> You specifically need to decide whether weight is a factor for you: > (a) a desk top replacement, will weigh about 8 lb ... a luggable > (b) a lightweight powersaver, will weigh about 4 lb ... no gaming conversion 2.2lbs = 1kg, so I guess I'm talking a 'not quite desktop replacement at ~7lbs.' My personal computer at the moment is a 1GHz P3 with 512MB Ram and 32mb geforce 2mx graphics. For me a processor which has much more cache (4-8 times as I can't remember how much L2 cache a p3 100mhz fsb has). 4x the bus speed, and 1.7x the clock speed can't be that bad. I'm not convinced processing power is the be all and end all any longer... in my mind that sounds fast enough for a processor. I'm under the impression that the graphics is the most important thing, I would welcome critique as to where system limitations occur. > My laptop has the 9600, can't help you on the support level for 9700. > If you visit the ATI discussion boards, you'll find that ATI have been > playing marketing name games with the recently released chip designs. I have emailed ati, no response as yet. I will look at these discussion boards. What I don't understand is they have one document indicating that everything above radeon is supported and another saying only certain specific chipsets are supported. Are the problems you're experiencing with the drivers only experience on a 64 bit system? What are the power saving features like for this driver? Can you configure anything worthwhile? Thanks for the input... t- minus 3 days and counting... Regards, Chris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor => A FlightGear based interactive Training Concept
Erik Hofman wrote: Boris Koenig wrote: If anybody of you doesn't yet know what this is all about, please check: http://flitetutor.sourceforge.net (please leave feedback using the poll) Boris, Erik, ;-) First of all, the documentation for Nasal can be found here: http://www.plausible.org/nasal/flightgear.html ya, thanks for that - but this doesn't seem to be complete - even though it's better than having nothing ;-) I could now start to collect and write down all questions that I still have regarding nasal interfacing with FlightGear, but I think that wouldn't lead to anywhere, so please take a look at the offer I made at the end of this mail. Secondly, I really think you are making things too complex. To clarify that I will need to explain the basics of FlightGear some more. FlightGear way of doing things is breaking it up into small pieces. There is (for example) animation code that reacts on property changes. There is also a Flight Dynamics model (FDM) that (amongst other things) updates properties. There is a menu system that can display and alter properties. Then we have sound code that plays sound based on ... properties. Maybe you see a pattern evolve by now. Yes, thanks for that Erik, and you are probably right in saying that I am making things too complex. But this is because of my lack of familiarity with FlightGear and its subsystems. That's exactly why I am asking all these questions - and answers like the ones that you've given so far are really tremendously helpful. So I hope to know now for example that nasal's lack of threadsafety is unlikely to become an issue, as not nasal itself would handle things like animations but rather a specific subsystem - that nasal would only access to provide the necessary parameters - correct ? All subsystems are almost self containing. Most of the time they only read the values of some properties, and sometimes they alter other properties. This is FlightGear's way of communicating between subsystems. As I don't know -yet- how to access FlightGear's subsystems from a language like nasal, I am currently definitely likely to indeed -reinvent the wheel- in order to resemble the beviours and functionality that I need. I do want to prevent that as well ! That's usually the problem if you don't have the necessary information available. So, I do appreciate you taking the time to clarify things a bit more for me. Nasal can also read and modify properties but it can also be incorporated into the menu system. Would you mind letting me know, which source files are responsible for the menu-access (like adding/removing items) ? So that I can look up the exact usage ? Because my current set of goals would then be to really drop the C++/PLIB idea and try to give nasal a go: This combination would allow one to design a menu system that: 1. pauses displays a dialog and pauses the simulator. 2. waits for the user to confirm the dialog. 3. alters one or more properties (change view for example) 4. starts the simulator again. 5. waits for a certain property to change 6. goto 1. ...for the nasal attempt to work, I would like to start by creating a simple script file which, when loaded by FlightGear, would disable subsystems like terragen (that aren't necessary at the current stage for FliteTutor) and continue adding custom menus to the FlightGear menu, in connection with the necessary hooks to be called when selected. I would then like something like that to become the basis for my FliteTutor coding attempts in nasal. I think this is already most of what you are looking for. You are probably right, but I would still need to know, what specific subsystem/properties to access (and what parameters to provide) in order for example to be able to do things such as: - load/display an instrument at a certain screen position - alter that instrument's properties - set its properties in a way that allows animation Just to name a few things, I guess you know what I mean. Available for your needs without any code touched. thanks, that's exactly why I am asking all that stuff What might be necessary is to code some hooks into FlightGear to (for instance) disable out of the window view when a certain property is set to false. yes, that's what I meant by adding certain interfacing possibilities - I think I will get back to you, as soon as the basic functionality for FliteTutor has been put on the webpage, in order to see what might need to be added. I hope you start to see the potential possibilities already present in FlightGear *now*. Yes, thank you for that - but: Regarding the FlightGear subsystems, is there any documentation available OR would any of the developers mind to give me some insight ? (this might also be done privately, I really don't want to disturb this mailing list) In exchange I'd love to present the provided information in a graphical way, possibly using UML or any other means to create relational diagrams. We could even feed
Re: [Flightgear-devel] Real Flight PLayback ?
"Curtis L. Olson" wrote: > Martin Spott wrote: > Yes, I've heard that the lower end IMU stuff (i.e. < $100,000) is pretty > bad in terms of fine grained accuracy ... There are two steps between solid-state- and $100k IMU's. _Simple_ FOG's (Fibre Optic Gyros) ($6k at X-Bow) translate a "moving picture" (convergent or divergent circles, see Michelson Interferometer, http://www.physics.uq.edu.au/people/mcintyre/applets/optics/michelsc.html) into modulated frequency and from threre to an analogue signal, sometimes with a calibrated A/D added to the output. Despite the translation errors the result is pretty usuable, even for manned aircraft. The "real thing" (TM) employs a digital counter to interpret the interferometer picture which makes this method nearly error-free. I assume these devices are in the $100k pice range. > >[ co-pilot ] > > To me, this device doesn't sound like it would be very useful for your > needs, but perhaps if you hacked it up and interfaced to the sensors > directly, you could get something out of it? It works on the IR > temperature differential between sky and ground and (as I understand) Yes, but for some circumstances the co-pilot is simply too error-prone. I need for a system that doesn't lets the heli go over the top when it faces the infraread CO2 spectrum near a tree or a wall ;-) Cheerio, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARINC 429 protocol
> Has anybody had success using ARINC 429 protocol? Yes, I have. How can I help you? -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Real Flight PLayback ?
Warning: this is all written with not enough sleep and not enough caffiene, read and respond at your own risk. :-) Mat Churchill wrote: I can see several business ideas related to this along the lines of something that could be fun to develop but which also has a variety of commercial possibilities. Does anyone have any examples of how commercial collaborations with open source projects actually work in practical terms ? I see it kind of like a marriage, every relationship is a bit different and you have to work hard to find a happy balance and keep it there. There are certain things people have found to be helpful and work well, but in the end it's up to the happy couple to find each other, figure out how to do life together, and continue to work hard to stay ahead of issues that come up, or resurface, etc. I think it's a similar challenge to figure out how to marry an open source project with some sort of commercial venture. But I think if you look around, there are a ton of examples ... from companies effectively using open source software in their day to day lives (Linux, X11, apache, emacs, gcc, python, etc.) to companies collaborating with open source projects for some mutual benefit to companies who derive their life blood from open source. For instance if you were developing a hardware product specifically for use with Flightgear, how would you develop the software side without competitors being able to find out exactly what you are up to? Yes, unfortunately there are a lot of sleazy bastards out there who are all to happy to rip off your work as soon as they see you making a sale or two. We can try to pretend to live in a happy world where these people don't exist, but it can be hard for a business to survive this sort of thing. Unfortunately, hardware and software vendors aren't just paranoid black helicopter types ... I'm not much of an expert in this area, but you can use things like closed source drivers to hide your hardware specifics. But, that won't stop people from disassembling your compiled objects, downloading your microcode, etc. etc. The best thing you can do to combat this is never develop an interesting or useful product, because if you do, you will have someone trying to copy it before long. As an example, I'd love to see open source drivers for nvidia cards, but I certainly can't fault them for their approach. I'm no big fan of Microsoft, but I can understand why they are like they are and why they do what they do. When you are at the top of the heap you have to fight off challengers from all areas ... open source is only one of *many* challenges. But in the end, let the best company or best approach win. :-) Hopefully we can trust gov't and law enforcement to keep the playing field from getting too unlevel ... it will never be perfectly level ... and we could never all agree on exactly what is level anyway ... I guess you'd set up a software company that privately develops the software. Are there scenarios where the community helps write software and gets cash back from related profits. Could you set up a "Flightgear Foundation" that developed commercially useable add ons away from the gaze of potential competitors and got cash back from profits towards things that the community wanted to do ? Or can open source software be developed privately and then shared at a later date ? To be clear on this I do understand the point of open source and am a firm believer in it. I hope this is not seen as a dangerous question. You are a danger. :-) To be honest, mixing profit motives with a hobby is a dangerous thing. There are many obvious (and many very subtle) ways we could shoot ourselves in the foot. Anything we would do would need to be approached very cautiously and with *much* thought. And we need to be realistic, money has to come from somewhere. That implies that we would need to do or promise something of enough value that people would be willing to part with their money and willingly give it to us. If we have a commercial product then we need to compete with products like MSFS and X-Plane and try to match them fluff-4-fluff. Research money is an option, but that is an entirely different ball game and has it's own large set of head aches. I think the question to ask (if we are interested in finding some sort of money source) is what kind of value can we offer to individuals, companies, research institutions? Courting any of these can require up front cash, long term risk, lots of sales work, etc. I tend to think that FlightGear in and of itself is too loose of an organization to effectively go after money sources like this. We will have better luck if individuals (who are part of some company, or part of some research group) work to get FlightGear used as part of their projects and do whatever they can to contribute the results back to the project. These companies or research institutions might d
RE: [Flightgear-devel] Autopilot
I have found this to be an excellent reference most of which is directly applicable to aircraft. MANEUVERING AND CONTROL OF MARINE VEHICLES by Michael S. Triantafyllou and Franz S. Hover Department of Ocean Engineering Massachusetts Institute of Technology Cambridge, Massachusetts USA http://ocw.mit.edu/OcwWeb/Ocean-Engineering/13-49Maneuvering-and-Control-of-Surface-and-Underwater-VehiclesFall2000/LectureNotes/ Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot
>-- Original Message -- >Date: Mon, 12 Jul 2004 12:09:04 +1200 >From: Birger Brunswiek >To: FlightGear developers discussions <[EMAIL PROTECTED]> >Subject: Re: [Flightgear-devel] Autopilot >Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]> > >ver these books which I'm going to get from the library: (name and ISBN) PID controllers / by Karl J. ?str?m and Tore H?gglund. 1556175167 Adaptive Control (2nd Edition) 0201558661 Control Theory : Multivaria le & Nonlinear Methods 0748408789 The >Control Handbook 0849385709 Handbook of PI and PID controller tuning rules / Aidan O'Dwyer. 1860943500 Digital Control of Dynamic Systems (3rd Edition) 0201820544 Advanced Control Unleashed: Plant Performance Management for Optimum Benefit 1556178 >58 Control Systems Engineering 0471445770 I'll add one of the textbooks that I used in my education: Process dynamics and control 0471863890 Isn't it more apropriate to have a multidimentional PID c ntroller rather than multipl > 1 dimentional PID controllers? Or is that just the same? I'm not sure what you mean by multidimentional PID controller, but I believe that that it would be the same as multiple one dimentional PID controllers. If we look at multivariable control, where we have multiple inputs and multiple outputs, we still use one PID controller for for each input-output pair. Consider an autopilot that is supposed to control the ailerons and the rudder. We know from experie ce (and probably from theory) that an aileron deflection will result in a roll, and that a rudder deflection result in a yaw, but also in a roll. Aileron deflection also result in a yaw, but I guess not as much as rudder deflection. So we have tw inputs: aileron and rudder, and two outputs: roll and yaw. Theese variables are not independent, the aileron does not only control roll, and the rudder does not only control yaw. They both interact. Of course the aileron controls roll much more tha it controls yaw and the rudder controls yaw more than it controls roll. So our two PID controllers would be: one with roll as input and aileron as output, and one with yaw as input and rudder as output. This might seem obvious, but still one should know the theory behind and note that it also makes sense in theory. When it comes to tuning the two PID controllers, one has to keep in mind that they interact. In general more conservative controller settings must be used, but I guess you'll fin more on multivariable controller tuning in one of the books :-) >What is the benefit of cascading PID controllers? Lets look at an autopilot that is supposed to steer the aircraft towards the heading bug. Suppose that the only thing we can man pulate is the aileron. Obviously we need a PID controller with aileron as its output. We choose roll angle as input. Now we can set the reference to say 20 degrees, and a properly tuned PID controller will hold a 20 degree roll angle. But how do e get it to steer towards the heading but? One solution is for the pilot to set the reference roll angle apropriately so that the aircraft steers toward the heading bug. Another is to let another PID controller set the reference roll angle. The outp t of this controller is then connected to the reference of the first controller. This is what we call a cascade configuration. For this example the benefit is that, well without cascading we wouldn't be able to do what we wanted (steer towards the h ading bug). For situations where cascading is not required, it can still be used and might give a more robust or smoother control loop. -- Roy Vegard Ovesen -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Real Flight PLayback ?
Martin Spott wrote: [ autopilot.sf.net ] Yes, they've hovered a heli. Even though this is already a difficult task not only for a 'manual' pilot but also for a computer, this is by far not sufficient for my needs. I need the computer to stabilize the heli in situations where the demands go beyond the pilots skills As long as the heli hovers more or less parallel to the surface, things are quite 'easy' because you move within "well defined" limits. When you start employing significant tilt angles and accelerations and go over tens of minutes of flight, then you get to the point where the 'repeat accuracy' of affordable solid-state gyros and accelerometers makes the whole thing unusuable. Yes, I've heard that the lower end IMU stuff (i.e. < $100,000) is pretty bad in terms of fine grained accuracy ... probably fine for stabalizing an aircraft and doing navigation, but pretty poor if you need degree-level accuracy. I am [currently] interested in simple level flight of a fixed wing aircraft and simple point to point navigation. I the the FMA direct copilot will work well for me, but it sounds like your interests/needs are in a totally different league. [ co-pilot ] To be honest: I don't trust this device enough to make the 'life' of my experimental heli project depend on it - but probably I simply should give it a try ;-) People are using it to stabalize helis. I've read that it is scary how well it works. I haven't tried it myself. Also, in the case of a helicopter, "stabalized flight" and "hover" are two entirely different things. As I understand it, helicopter pilots are using this device as a way to save their butts when they get crossed up on the controls. Center the controls, add power, and the helicopter should level out ... enough to give the pilot time to get reoriented and take back active control. To me, this device doesn't sound like it would be very useful for your needs, but perhaps if you hacked it up and interfaced to the sensors directly, you could get something out of it? It works on the IR temperature differential between sky and ground and (as I understand) the sensor has a fairly wide swath, so for small deviations for horizontal, you may be able to get some accurate data if you look directly at the sensor output ... but then if you are doing this with a helicopter and are near the ground, I have to wonder if trees and buildings or terrain would contribute enough error in the sensor differential to mess you up. But what do I know ... It's 5am here and I haven't had nearly enough sleep. :-) 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Real Flight PLayback ?
"Curtis L. Olson" wrote: > Martin Spott wrote: > >If you spend $6k at X-Bow you already get a FOG-based IMU. This is the > >sort of things I was looking at for my partially autonomous heli (see > >below), but this sort of equipment out of the price range I can pay. > > Yeah, that's pretty tough for most people's home budget. I imagine > you've looked at the autopilot.sf.net project. They claim to have > hovered a heli, but they don't seem to have had much activity in the > last year or two. I assume I'm the guy who made you aware of the 'autopilot' project ;-) Yes, they've hovered a heli. Even though this is already a difficult task not only for a 'manual' pilot but also for a computer, this is by far not sufficient for my needs. I need the computer to stabilize the heli in situations where the demands go beyond the pilots skills As long as the heli hovers more or less parallel to the surface, things are quite 'easy' because you move within "well defined" limits. When you start employing significant tilt angles and accelerations and go over tens of minutes of flight, then you get to the point where the 'repeat accuracy' of affordable solid-state gyros and accelerometers makes the whole thing unusuable. I must admit that I don't have a real proof for this theory, but this is the conclusion after several different mathematical approaches to this subject over the past ten years or so > The FMA Direct Co-Pilot Norman mentioned has been used with some success > for stabalizing R/C helicopters. When you start to get in trouble, just > center the controls and give it throttle. To be honest: I don't trust this device enough to make the 'life' of my experimental heli project depend on it - but probably I simply should give it a try ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 Model
"Ampere K. Hardraade" wrote: > Well, their method of rendering is capable of rendering that 350 millions > triangle monster in under 10 seconds. If using that method means that the > framerates of FlightGear goes up plus more detail scenery, then it certainly > worths look into in my opinion. Please keep in mind that the Boeing apparently doesn't contain textures but siple shadowing instead, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
