Re: [Flightgear-devel] Autopilot
[EMAIL PROTECTED] wrote: 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. The one described is one dimentional because all variables are scalars. In a multidimentional version the target, input and output would be vectors and gains matrices. With the matrices you should be able to express interaction between the components. e.g. as you said rudder and ailerons have overlapping effects. I'd say with two 1-dimenational controllers you ignore that fact and get imperfect results. 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. could you not take the heading as input and aileron controll as output directly, since the effect of the ailerons (roll) is directly connected to change of heading. Birger signature.asc Description: OpenPGP digital signature ___ 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: Maybe it is now easier for you to tell me, IF the desired functionality could be (easily) achieved using primarily nasal scripting and some smaller FlightGear source code modifications or whether it would be more feasible for me to really start writing directly into the FlightGear source. Even though I am more and more about to like the Nasal way, which seems to be pretty elegant by the way. I think (after reading the whole message) that FlightGear just needs a few modifications. Two come to mind: 1. load a new panel at runtime (refreshing the panel is already possible) 2. add XML I/O support to Nasal. The way I see it, a panel object could be used as a sheet containing the necessary information (animated instruments, text and static graphics). This would require FlightGear to load another sheet (panel) when requested to continue. I don't think that's too tough of a problem. Adding XML I/O to Nasal might be a bit harder to do. I guess the only thing that actually could be done by loading an XML document in Nasal would be to load a new set of pre-defined properties. While this is useful, it might be easier done using C++ instead. What could not be done using Nasal (and probably never will, although I really would like to see this added for the Radar object) is to load and manipulate 3d objects using Nasal *directly*. Andy (the author of Nasal) has clearly stated that this is probably really hard to do. Further more, I really think you shouldn't consider not loading subsystems because that's impossible right now. Instead it would be easier to disable subsystems after they have been loaded. As far as I can tell, all subsystems that allow disabled don't consume any CPU/GPU time. But as I mentioned previously: if I am shown HOW TO add Nasal bindings to FlightGear I wouldn't mind firing up my IDE and do some C++ stuff myself. There are some hints at the bottom of the document I mentioned earlier, but it's not very comprehensive. To go add some more detail: what I ultimately would like to be able to do with FliteTutor is to make FliteTutor a module for FlightGear that can create and play learning units within FlightGear. So, not FliteTutor itself is supposed to contain the actual contents for FlightGear, but rather dynamically loaded learning units will serve that purpose. So, these units could either be created based on a set of nasal-macros that are approriately adapted for each new unit - OR (more likely right now) it could rely on an individual (xml-based) file format that describes things like: [GENERAL] -position and alignment of GUI elements for navigational purposes -title of unit -introductory description (outline) -pages that exist for that unit This can all be done in the panel configuration file. So, each unit/lesson would then consist of different pages - (read panels here) whereas each page represents an empty FlightGear client area that is dynamically populated with those elements that are necessary for that particular unit - e.g.: the CBT navigation controls. The remainder of the screen could then be used for illustrative purposes. Hence, I would nasal need to be able to do mainly the following stuff: -draw abitrary (plib based) GUI elements within FlightGear's client area That can be done now. -register (nasal based) callbacks/handlers for controls such as buttons,textboxes etc. That is already present, but it might work a bit different than what you are hoping for. -register callbacks to act on certain mouse events within FlightGear This is done using the instrument configuration file. -load(enable)/unload(disable) individual FlightGear subsystems Enable/disable is present for most subsystems. -use subsystems (video,network,sound ...) to do certain things - e.g.: -draw images/animations within FlightGear's client area Except movies, animations and images can be displayed and positioned already. -play a certain sound Is present. -do file handling stuff (probably using FlightGear's XML-routines) This might need some attention. (I might have forgotten 2-3 things, though) That all done using XML (look in the FlightGear/data/gui subdirectory for the complete configuration of the menu layout). okay, thanks again - but is it then also possible to *dynamically* alter the menu, I mean not using XML definitions files ? Hmm, I'm not sure about that ATM ... OFFTOPIC In that regard it would be really useful to add another item to describe each property in the property-tree - that way you could even display a specific description for properties within the integrated property-browser and one would immediatley see, what's the purpose of a certain property and how it affects FlightGear. Caution has been taken to make each property self explanatory (including what values to expect).
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
Ampere K. Hardraade wrote: Would you mind posting the link to your site and forum again? http://flitetutor.sourceforge.net Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re:Compiling on win32
Hi, I solved the problem modifying the glut.h file. I've modified the string related to the exit function and now all works right. Now I've to update the XML files to match the version I've compiled; I think it's a long work Thanks, Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New scenery directories setup - joystick axis between win32 and unix
Hi, I've just downloaded the DATA directory in CVS; while in the old scenery configuration the elevation data and the objects were in the same directory, I've noticed that now they are splitten into Terrain and Objects. I've started a flight in KSFO, where there are some models, but they doesn't appear in the scene. How I can solve this? I've to merge the directories? However, this could be caused by the fact that I've removed the source files in the directory objects during the compilation? tanks, Luca PS1: If it's even important, I've tested the differences between win32 and unix axis (Mathias Fröhlich has hasked me about this some time ago) and I could confirm that this works right. PS2: There's a way to modify the FlightGear Wizard source files for windows? Some functionalities doesn't exists any more while others have to be added. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New scenery directories setup - joystick axis between win32 and unix
Luca Masera wrote: A : flightgear-devel I've just downloaded the DATA directory in CVS; while in the old scenery configuration the elevation data and the objects were in the same directory, I've noticed that now they are splitten into Terrain and Objects. I've started a flight in KSFO, where there are some models, but they doesn't appear in the scene. I don't have any problem with my MSVC build. Are you up to date ? Current FlightGear is looking for files in Scenery/Terrain and Scenery/Objects. Do you have --fg-scenery option set, either in fgrun, in system.fgfsrc or on the command line ? How I can solve this? I've to merge the directories? However, this could be caused by the fact that I've removed the source files in the directory objects during the compilation? What do mean ? what files ? tanks, Luca PS1: If it's even important, I've tested the differences between win32 and unix axis (Mathias Fröhlich has hasked me about this some time ago) and I could confirm that this works right. PS2: There's a way to modify the FlightGear Wizard source files for windows? Some functionalities doesn't exists any more while others have to be added. The source are there : http://sourceforge.net/projects/fgrun -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re:Scenery load
Erik Hofman wrote: Do you define the FG_SCENERY environment variable somewhere? If so, you might want to try to add both directories to your search path: FG_SCENERY=C:\FlightGear\data\Scenery\Terrain;C:\FlightGear\data\Scenery\Objects Doing so works right. Tank you very much. Frederic Bouvier wrote: How I can solve this? I've to merge the directories? However, this could be caused by the fact that I've removed the source files in the directory objects during the compilation? What do mean ? what files ? I've removed from the project I've compiled the files into the directory objects. Initially I suspected that the problem was determined by this but, adding the other directory to the FG_SCENERY environment, I've noticed that this doesn't affect the program (FlightGear now loads all the objects). Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Recording NMEA data playing back ?
Hi All, Related to my query re real flight playback, I thought I should start at the beginning. I found this mention here on the Avsim Flightgear forum re playback. http://forums.avsim.net/dcboard.php?az=show_mesgforum=198topic_id=62mesg_id=62page= I am already outputting NMEA data for use by Atlas. Can I record this to disk somehow ? and if so could someone point me in the direction of information on how to replay NMEA data in Flightgear. I'm also assuming that there is currently no way of inputing pitch, roll yaw data while playing back NMEA data ? if so would this be easy to implement ? I found this paper on the web regarding generating accurate pitch, roll, yaw, altitude, position velocity data. http://www.cmt-gmbh.de/crossbow_gpsdmu_german_gyrotech_paper.doc I think the end product derived from the above was this: http://www.xbow.com/Products/productsdetails.aspx?sid=104 There are other papers out there from people such as creators of robot football teams all tackling similar issues. I spent the weekend digging around on the web and made some calls on Monday and it appears the component cost could be as low as £300 - £400 to make a flight logger. One particular solid state gyro is mentioned as cheap but good by everyone from amateur rocket clubs to R/C helicopter builders. However if you read the above document the real deal breaker re making a homemade flight logger is not the component cost, but the processing of the signal from the gyros into accurate attitude / position data. Someone more than at home with extended kalman filter formulae amongst other things needs to write an algorithm to process the turn rate gps data into accurate attitude / position data. From what the paper says substantial testing would be required. This actually is rocket science ! and is way above my head ( at least 60 miles above my head ) I did think that at least with a flight logger rather than a real time device you could record raw turn rate / gps data in flight and do all the processing on your PC when you got home, not that that diminishes the complexity of maths that would need doing. From what I've observed on this list it would be no surprise if some of the readers do understand the principles of Kalman filters. Maybe some of the information is already being shared by amateur rocketry, R/C helicopter enthusiasts etc ? It will take a while, but I am building a simple GPS logger at the moment. If anyone is interested in taking part in getting the gyro part to work I could have it built here and post it out to others for testing. Mat ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Recording NMEA data playing back ?
Mat Churchill wrote: Hi All, Related to my query re real flight playback, I thought I should start at the beginning. I found this mention here on the Avsim Flightgear forum re playback. http://forums.avsim.net/dcboard.php?az=show_mesgforum=198topic_id=62mesg_id=62page= I am already outputting NMEA data for use by Atlas. Can I record this to disk somehow ? Look at the docs-mini/README.IO file. It should show how to export the nmea data to a file (or serial port) rather than a net connection. and if so could someone point me in the direction of information on how to replay NMEA data in Flightgear. Playback should also be mentioned in the README.IO file I think. I haven't played with file I/O in years though so I can't say for sure if it still works with no issues. I'm also assuming that there is currently no way of inputing pitch, roll yaw data while playing back NMEA data ? if so would this be easy to implement? The NMEA format doesn't account for pitch/roll/yaw. I'm not sure we'd want to start modifying the format either. Probably the nicest solution (but would involve some effort) would be to write some offline tool that would take the saved NMEA data (probably at 1hz?) and do all the roll/pitch/yaw calculations and interpolate for 30 or 60 hz. Then you could feed this back to FG as FGNativeFDM structures and get nice smooth playback. (You could even feed FGNativeCtrls structures back too and animate the control surfaces if you want to estimate their positions.) I found this paper on the web regarding generating accurate pitch, roll, yaw, altitude, position velocity data. http://www.cmt-gmbh.de/crossbow_gpsdmu_german_gyrotech_paper.doc I think the end product derived from the above was this: http://www.xbow.com/Products/productsdetails.aspx?sid=104 There are other papers out there from people such as creators of robot football teams all tackling similar issues. I spent the weekend digging around on the web and made some calls on Monday and it appears the component cost could be as low as £300 - £400 to make a flight logger. One particular solid state gyro is mentioned as cheap but good by everyone from amateur rocket clubs to R/C helicopter builders. However if you read the above document the real deal breaker re making a homemade flight logger is not the component cost, but the processing of the signal from the gyros into accurate attitude / position data. Yes that's hard ... I won't mention any names, but I've seen phd and master's level people struggle significantly with implimenting kalman filtering in a real world task. The theory itself is difficult enough, but getting a correct implimentation in your own code seems to be an order of magnitude harder. (Other's may disagree, I've never attempted to understand/impliment kahlman filtering myself, so I'm not speaking with much authority here ...) :-) Someone more than at home with extended kalman filter formulae amongst other things needs to write an algorithm to process the turn rate gps data into accurate attitude / position data. From what the paper says substantial testing would be required. This actually is rocket science ! and is way above my head ( at least 60 miles above my head ) I did think that at least with a flight logger rather than a real time device you could record raw turn rate / gps data in flight and do all the processing on your PC when you got home, not that that diminishes the complexity of maths that would need doing. If you want to just approximate roll/pitch/yaw based on gps data then you could always start simple, use a simple smoothing function, and at least get something working before you tackle more complex approaches. If you need to process raw gyro output (accelerations) and translate those into accurate positions and orientations, then you probably need to dig into Kahlman filtering. From what I've observed on this list it would be no surprise if some of the readers do understand the principles of Kalman filters. Maybe some of the information is already being shared by amateur rocketry, R/C helicopter enthusiasts etc ? Aaron Kahn (I don't know if that is quite the right name) was a guy on the autopilot.sf.net list. He is the only person I've ever seen personally who's produced a successful kahlman filter implimentation in real computer code to run in real time on a real embeded computer. I've seen a lot of people that can talk your ear off with the high level theory, or who know some of the basics of what Kahlman filtering does and what it's good for. But I've only seen one person who's managed to pull off a real world successful implimentation ... :-) It will take a while, but I am building a simple GPS logger at the moment. If anyone is interested in taking part in getting the gyro part to work I could have it built here and post it out to others for testing. I'm interested ... along with 100 million other things ... but please keep us up to date
Re: [Flightgear-devel] Autopilot
-- Original Message -- Date: Tue, 13 Jul 2004 18:57:13 +1200 From: Birger Brunswiek To: FlightGear developers discussions [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Autopilot Reply-To: FlightGear developers discussio s [EMAIL PROTECTED] rvovesen wrote: 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 ean by multidimentional PID c ntroller, but I believe that that it would be the same as multiple one dimentional PID controllers. The one described is one dimentional because all variables are scalars. In a multidimentional version the target, input and output would be vect rs and gains matrices. With the matrices you should be able to express interaction between the components. e.g. as you said rudder and ailerons have overlapping effects. You mean a state-space form?!: x' = x + Bu y = Cx + Du I think that would make the autopilot-configuration a bit more complicated. One of the things that was requested on this list when we redone the autopilot system was that it had to be simple to configure. For the state-sp ce form one would require a matematical model of the aircraft, the A matrix. With PID controllers you don't need matematical models. Since every aircraft have different matematical models, that would add to the complexity of configuring the autopilo . I'd say with two 1-dimenational controllers you ignore that fact and get imper ect results. Yes, since we don't have a matematical model to help us out, we ignore that fact. But we still know, in our head, that rudder and aileron interact and consequently we tune the two PID controllers in a slightly different way. So in theory we ignore it, but in pactice we consider it. could you not take the heading as input and aileron controll as output directly, since the effect of the ilerons (rol ) is directly connected to change of heading. Pleasy try it out! ;-) I guess that you will learn that as the controller demands full aileron deflection, the aircraft will roll, roll and roll until it's inverted, and it won't stop t ere, it will continue to roll. And the aircraft will return to almost the same heading as it had befor the roll started. :-( Back to the state-space form. There is nothing stopping you from implementing a state-space form to the existing autopi ot code. The source files to look for are xmlauto.* in the autopilot subdir. If you think that a multidimentional state-space model would give better performance than the PID controllers, go ahead! I also think that it would give better performa ce, and I would gladly help you in implementing. -- Roy Vegard Ovesen -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Recording NMEA data playing back ?
Correction last paragraph of last post was not clear. I am building a GPS NMEA recorder now. I will build the full flight logger as discussed in the bulk of my last mail if it looks possible to resolve the signal / data processing issues etc ( and all the as yet unforeseen problems ) Mat ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Laptop
On Tuesday 13 July 2004 03:04, Al West wrote: 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). Interesting possibility... I wonder if you can get a solar powered laptop. Should probably end this thread now, the topic is wondering from being in the slightest flightgear related. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Laptop
Chris Horler wrote: I think I'm going to look at the nvidia driver for acpi etc and then consider laptops again if the situation is any better. From the most recent release highlights: # Added support for ACPI I'm running the 1.0-6106 driver here and it seems fine. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Laptop
Chris Horler wrote: Interesting possibility... I wonder if you can get a solar powered laptop. I don't know about a solar powered laptop, but I just got email from a nice individual trying to sell me a solar powered cell phone charger that works anywhere, any time, and will charge my phone in 15 seconds. He wasn't a very good speller, but it's amazing what they come up with. And how did he know I had a cell phone? Well no matter, I thought this would be a great convenience so I called and ordered mine right away. 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] Recording NMEA data playing back ?
On Tue, 13 Jul 2004 09:49:19 -0500, Curtis wrote in message [EMAIL PROTECTED]: Mat Churchill wrote: I'm also assuming that there is currently no way of inputing pitch, roll yaw data while playing back NMEA data ? if so would this be easy to implement? ..do keep these _separately_ from the gps data, say off a gyro platform. Accellerometers are optional, accelleration can be both measured and calculated off the gyro platform. Also, consider recording total and static pressures, AoA, and a compass, these are fairly easy to read and process. You'll need to pool your data anyway. ;-) The NMEA format doesn't account for pitch/roll/yaw. I'm not sure we'd want to start modifying the format either. Probably the nicest solution (but would involve some effort) would be to write some offline tool that would take the saved NMEA data (probably at 1hz?) and do all the roll/pitch/yaw calculations and interpolate for 30 or 60 hz. Then you could feed this back to FG as FGNativeFDM structures and get nice smooth playback. (You could even feed FGNativeCtrls structures back too and animate the control surfaces if you want to estimate their positions.) ..by now we have gyro and IMU etc data format ideas? I found this paper on the web regarding generating accurate pitch, roll, yaw, altitude, position velocity data. http://www.cmt-gmbh.de/crossbow_gpsdmu_german_gyrotech_paper.doc I think the end product derived from the above was this: http://www.xbow.com/Products/productsdetails.aspx?sid=104 There are other papers out there from people such as creators of robot football teams all tackling similar issues. I spent the weekend digging around on the web and made some calls on Monday and it appears the component cost could be as low as £300 - £ 400 to make a flight logger. One particular solid state gyro is mentioned as cheap but good by everyone from amateur rocket clubs to R/C helicopter builders. ..how much can such ready-to-go flight loggers be sold for? ;-) However if you read the above document the real deal breaker re making a homemade flight logger is not the component cost, but the processing of the signal from the gyros into accurate attitude / position data. Yes that's hard ... I won't mention any names, but I've seen phd and master's level people struggle significantly with implimenting kalman filtering in a real world task. The theory itself is difficult enough, but getting a correct implimentation in your own code seems to be an order of magnitude harder. (Other's may disagree, I've never attempted to understand/impliment kahlman filtering myself, so I'm not speaking with much authority here ...) :-) Someone more than at home with extended kalman filter formulae amongst other things needs to write an algorithm to process the turn rate gps data into accurate attitude / position data. From what the paper says substantial testing would be required. This actually is rocket science ! and is way above my head ( at least 60 miles above my head ) I did think that at least with a flight logger rather than a real time device you could record raw turn rate / gps data in flight and do all the processing on your PC when you got home, not that that diminishes the complexity of maths that would need doing. If you want to just approximate roll/pitch/yaw based on gps data then you could always start simple, use a simple smoothing function, and at least get something working before you tackle more complex approaches. ..and all this will only be guesswork, as you _guess_ it from your gps data, rather than measure and record it. Adding heading data will help you get averaged wind, but not immediate stuff like turbulence jolts. If you need to process raw gyro output (accelerations) and translate those into accurate positions and orientations, then you probably need to dig into Kahlman filtering. ..doing both _can_ give you the wind around your plane, _if_ you get Kalman etc right. ;-) From what I've observed on this list it would be no surprise if some of the readers do understand the principles of Kalman filters. Maybe some of the information is already being shared by amateur rocketry, R/C helicopter enthusiasts etc ? Aaron Kahn (I don't know if that is quite the right name) was a guy on the autopilot.sf.net list. He is the only person I've ever seen personally who's produced a successful kahlman filter implimentation in real computer code to run in real time on a real embeded computer. I've seen a lot of people that can talk your ear off with the high level theory, or who know some of the basics of what Kahlman filtering does and what it's good for. But I've only seen one person who's managed to pull off a real world successful implimentation ... :-) It will take a while, but I am building a simple GPS logger at the moment. If anyone is interested in taking part in getting
[Flightgear-devel] no altitude in route waypoints
There does not seem to be altitudes in the new route structure. (Or, at least, they are not loaded into the autopilot.) In 0.9.2 you could set a waypoint to [EMAIL PROTECTED] and the aircraft would fly to the intended waypoint at the specified altitude. Has this feature been removed, or overlooked in the upgrade to the route_mgr + SimGear route/waypoint class method? If overlooked, what files should I look at to re-include this? Wendell --- Friends don't let friends squawk 1200 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
