Re: [Flightgear-devel] Autopilot and violent roll
-Original Message- From: leee [mailto:l...@spatial.plus.com] Did you try scheduling your autoplilot´s height-error to pitch demand gain with 1/V (speed inverse) ? Alan Re-read the end of the paragraph after the one you quoted above ;-) LeeE Red Face (me that is) I can't help thinking that there must be another problem somewhere. It should only be necessary to up the frame rate above 20Hz if you need to simulate vibrations, not aircraft motion and autopilot control loops. A possible cause is if the simulation is not ordered correctly and some equations in the solution are receiving old inputs which relate to a previous time frame. Errors due to this effect would reduce as the frame rate is increased. Anything in the simulation which has a faster response that that provided by a 20Hz frame rate can safely be ignored for man-in-the-loop stuff as the man just won't be capable of seeing or reacting to it. Alan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Wednesday 14 Oct 2009, Alan Teeder wrote: -Original Message- From: leee [mailto:l...@spatial.plus.com] Did you try scheduling your autoplilot´s height-error to pitch demand gain with 1/V (speed inverse) ? Alan Re-read the end of the paragraph after the one you quoted above ;-) LeeE Red Face (me that is) Heh :-) I added the reciprocal filter type to specifically address this problem. It's still more of a work-around than a cure though. I can't help thinking that there must be another problem somewhere. It should only be necessary to up the frame rate above 20Hz if you need to simulate vibrations, not aircraft motion and autopilot control loops. A possible cause is if the simulation is not ordered correctly and some equations in the solution are receiving old inputs which relate to a previous time frame. Errors due to this effect would reduce as the frame rate is increased. Anything in the simulation which has a faster response that that provided by a 20Hz frame rate can safely be ignored for man-in-the-loop stuff as the man just won't be capable of seeing or reacting to it. Alan It really depends on what you're trying to do with the autopilot. As I said, for aircraft that only need relatively slow responses you can get away with a 20Hz rate, but even then there's little margin of safety insofar as the controller will be working near its minimum stable rate. Where you need faster responses though, you really need higher rates and it's not just an issue of having a person in the loop. For example, one of the things I was playing with on the SU-37 and YF-23 updates was to intercept stick inputs and have a stick-mode where the stick set a target pitch roll instead of controlling the elevator/elevons/ailerons directly. In this case I really needed to achieve a pitch/roll-change rate of 20-30 degrees/second, without overshoot, and you just can't do that with the controllers running at ~20Hz. There's also the added advantage that with a higher resource availability for the FDM and autopilot controllers you could make the controllers more predictive by using several samples to match a curve, instead of just reacting the the difference between consecutive samples. LeeE -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
leee wrote: On Saturday 10 Oct 2009, Pete Morgan wrote: Roy Vegard Ovesen wrote: On Saturday 10 October 2009 22:33:01 Curtis Olson wrote: Really, this is all in how the autopilot is tuned and configured. FlightGear doesn't model realistic control surface deflection rates so it's possible to command an instantaneous deflection of the control surfaces. Control surface deflection rate can be limited by inserting a low-pass filter between the output of the final PID-controller and the control surface. THis is done in the autopilot config file. I expected FlightGear to crete the realistic mdel.. and deflection rate.. So your response cofirmas a few facts... ie if u stick in a new value to the FDM then it will react.. That sucks in my oioiion.. I how have to create my own craqo to make the model. that sucks to me.. pete You really need to chill a bit. Just moaning about things isn't the best way to go about getting stuff fixed. LeeE I apoligise. am just a little frustrated.. kinds regards Pete -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Monday 12 Oct 2009, Alan Teeder wrote: -Original Message- For the faster and more maneuverable military jets though, I found that I really needed guaranteed higher rates to both ensure a crisp response and avoid instabilities. For example, I could tune an altitude-hold cascade that would work fine at speeds up to 400kt say, but which would become unstable above that. The reason was that the rate of deviation increases with aircraft speed as the control surfaces generate more force for a given deflection, so for a given deflection of the control surfaces by the controller, it sees a greater response result in its next sample. Eventually, it can't help but over-correct and go into oscillation. Running the controller at a higher rate though, would mean that it would see a smaller deviation because the aircraft would have moved less in the shorter time period. Did you try scheduling your autoplilot´s height-error to pitch demand gain with 1/V (speed inverse) ? Alan Re-read the end of the paragraph after the one you quoted above ;-) LeeE -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sunday 11 Oct 2009, Alan Teeder wrote: -Original Message- From: leee [mailto:l...@spatial.plus.com] ie if u stick in a new value to the FDM then it will react.. That sucks in my oioiion.. I how have to create my own craqo to make the model. that sucks to me.. pete You really need to chill a bit. Just moaning about things isn't the best way to go about getting stuff fixed. Anyway, in short, this 'problem' such as it is, is largely due to the rates at which the autopilots are run within FG. In real life, autopilot controllers, and the sensors that feed them the data they need to work with, run at much higher frequencies than are possible within the FG framework. Ideally, you want to be able to run the autopilots at several to many kHz but in FG, although you can specify very high rates in the autopilot config, you are effectively limited by the frame rate, so not only do they run much more slowly than is desirable but they also run at varying rates as the frame rate changes. Lee First, thanks for the quick into to Flightgear´s autopilot. I think that your premise that autopilots need to run at very high frame rates is not realistic. I guess it depends upon what you're trying to do. If you just need an autopilot for a light aircraft or an airliner, where you want fairly slow and gentle responses, you can get away with relatively low rates. Apart from frame-rate induced instabilities, I found the rates that I could get, on my relatively old kit, acceptable for the larger aircraft I did. For the faster and more maneuverable military jets though, I found that I really needed guaranteed higher rates to both ensure a crisp response and avoid instabilities. For example, I could tune an altitude-hold cascade that would work fine at speeds up to 400kt say, but which would become unstable above that. The reason was that the rate of deviation increases with aircraft speed as the control surfaces generate more force for a given deflection, so for a given deflection of the control surfaces by the controller, it sees a greater response result in its next sample. Eventually, it can't help but over-correct and go into oscillation. Running the controller at a higher rate though, would mean that it would see a smaller deviation because the aircraft would have moved less in the shorter time period. Now admittedly, I the autopilots I were working on were more like FBW/FMS systems. For example, I was using a three-stage cascade for elevator control and the final elevator driver stage had to be able to maintain pitch between take-off and landing speeds, up to top speed, a typically range of 130-1200 kts. To maintain control at take-of and landing speeds, the elevators need a lot of authority, and to be quite honest, pretty brutal, but you can't apply that brutefulness at top speed. One way to ameliorate this was to use reciprocal filters to reduce the controller gains as the speed increases, but once again, a higher guaranteed sample rate would be better. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. You can think of the different autopilot controllers and filters as analogue logic building blocks. You're pretty much building an analogue computer when you set up a complex autopilot. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. As I've mentioned, you can simulate the control surface actuators in the aircraft FDM config, both in JSBSim and YASim. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. Alan There's the rub really, as the response of the aircraft is quite slow. LeeE -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
-Original Message- For the faster and more maneuverable military jets though, I found that I really needed guaranteed higher rates to both ensure a crisp response and avoid instabilities. For example, I could tune an altitude-hold cascade that would work fine at speeds up to 400kt say, but which would become unstable above that. The reason was that the rate of deviation increases with aircraft speed as the control surfaces generate more force for a given deflection, so for a given deflection of the control surfaces by the controller, it sees a greater response result in its next sample. Eventually, it can't help but over-correct and go into oscillation. Running the controller at a higher rate though, would mean that it would see a smaller deviation because the aircraft would have moved less in the shorter time period. Did you try scheduling your autoplilot´s height-error to pitch demand gain with 1/V (speed inverse) ? Alan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Saturday 10 Oct 2009, Pete Morgan wrote: Roy Vegard Ovesen wrote: On Saturday 10 October 2009 22:33:01 Curtis Olson wrote: Really, this is all in how the autopilot is tuned and configured. FlightGear doesn't model realistic control surface deflection rates so it's possible to command an instantaneous deflection of the control surfaces. Control surface deflection rate can be limited by inserting a low-pass filter between the output of the final PID-controller and the control surface. THis is done in the autopilot config file. I expected FlightGear to crete the realistic mdel.. and deflection rate.. So your response cofirmas a few facts... ie if u stick in a new value to the FDM then it will react.. That sucks in my oioiion.. I how have to create my own craqo to make the model. that sucks to me.. pete You really need to chill a bit. Just moaning about things isn't the best way to go about getting stuff fixed. Anyway, in short, this 'problem' such as it is, is largely due to the rates at which the autopilots are run within FG. In real life, autopilot controllers, and the sensors that feed them the data they need to work with, run at much higher frequencies than are possible within the FG framework. Ideally, you want to be able to run the autopilots at several to many kHz but in FG, although you can specify very high rates in the autopilot config, you are effectively limited by the frame rate, so not only do they run much more slowly than is desirable but they also run at varying rates as the frame rate changes. This isn't ideal, of course, but running an entire flight simulator on a single PC is always going lead to compromises. Having said that though, there are a number ways of working around most of the problems. There isn't really a problem with the autopilot code or the FDMs in flight gear, but that doesn't mean that individual FDMs and autopilots are always optimally configured. As Jon said, JSBSim incorporates actuator simulation, and I know that YASim allows you to set control surface deflection rate limits. These should really be set up in the aircraft FDM config and it is down to the developer to do this. However, few of the people developing aircraft for FG could be described as professionals in this field so you shouldn't expect everything to be absolutely perfect. So first of all, have a look at the FDM configs for the aircraft you're using and, depending on which FDM is being used, find out whether the actuators or rate limits have been set up correctly. The next thing to do is to look at the autopilot config. When the 'new' PID/PI autopilot was introduced, Roy set up a basic 'example' autopilot configuration to show how the new controllers could be used and this has formed the basis for most of the autopilots since then. The basic autopilot that Roy set up used two-stage controller cascades, where the output from the first stage controller was fed into the second stage. For example, in the true-heading-hold mode, the first stage controller would look at the true-heading-error-deg property and generate a desired roll setting to turn the aircraft and reduce the true-heading-error-deg to zero. The second stage would then take the desired roll setting and generate an aileron deflection to achieve the required roll. As the aircraft turns and true-heading-error-deg starts to approach zero, the controller will detect this and command a reduced degree of roll. Similarly, the second stage controller will look at the current degree of roll and compare it with the required degree of roll and if the two are very different the second stage controller will command a large deflection (this is where the jerkiness come from). Then, as the difference between the current roll and required roll reduces, the controller will command less deflection. The jerkiness then, can occur when the first stage controller sees a large difference between its current state and the state required, and quite reasonably commands the maximum change it is allowed. For example, if you're flying level and then tell the autopilot that you want to fly in the opposite direction it will quickly decide that it needs to command maximum roll. Now the second stage controller, which controls the ailerons to achieve the desired rate of roll, has to be quite aggressive in the way that it works if it is to tightly control roll, both because it has to operate over a much shorter time span than the first stage controller (to turn an aircraft through 180 degrees may take several minutes but to achieve 40 deg of roll may only take a few seconds) and also to prevent the aircraft from 'over-rolling' and then see-sawing as it then corrects itself, but this means that when it is told to change the current roll from zero to, 40 degrees say, it sees a very large error, just as the first stage controller has seen, and command its maxmum
Re: [Flightgear-devel] Autopilot and violent roll
-Original Message- From: leee [mailto:l...@spatial.plus.com] ie if u stick in a new value to the FDM then it will react.. That sucks in my oioiion.. I how have to create my own craqo to make the model. that sucks to me.. pete You really need to chill a bit. Just moaning about things isn't the best way to go about getting stuff fixed. Anyway, in short, this 'problem' such as it is, is largely due to the rates at which the autopilots are run within FG. In real life, autopilot controllers, and the sensors that feed them the data they need to work with, run at much higher frequencies than are possible within the FG framework. Ideally, you want to be able to run the autopilots at several to many kHz but in FG, although you can specify very high rates in the autopilot config, you are effectively limited by the frame rate, so not only do they run much more slowly than is desirable but they also run at varying rates as the frame rate changes. Lee First, thanks for the quick into to Flightgear´s autopilot. I think that your premise that autopilots need to run at very high frame rates is not realistic. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. Alan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sun, Oct 11, 2009 at 3:39 AM, Alan Teeder wrote: First, thanks for the quick into to Flightgear´s autopilot. I think that your premise that autopilots need to run at very high frame rates is not realistic. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. I think what Lee(e) may be observing is that when you tune an autopilot to behave well when the update rate is 60hz, and then fly into an area of complex scenery + effects the frame rate in FlightGear can drop substantially. In this situation, the autopilot (which is running at the same update rate as the graphics) can go unstable, leading to wild oscillations. Presumably this is an entirely different issue than what Pete is dealing with, and neither of these contradict anything you have said. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sunday 11 Oct 2009 4:30:08 pm Curtis Olson wrote: I think that your premise that autopilots need to run at very high frame rates is not realistic. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. I think what Lee(e) may be observing is that when you tune an autopilot to behave well when the update rate is 60hz, and then fly into an area of complex scenery + effects the frame rate in FlightGear can drop substantially. In this situation, the autopilot (which is running at the same update rate as the graphics) can go unstable, leading to wild oscillations. Presumably this is an entirely different issue than what Pete is dealing with, and neither of these contradict anything you have said. Interesting. I would have imagined that the autopilot logic were synchronized with the FDM and hence slow downs should not cause an issue as they would both slow down together. But it seems that the autopilot logic is synchronized with GUI frame paining code. Is there any literature that lists out the sequence? I'm curious to know how the network IO is synchronized. Not having a common time base reference for the various subsystems can lead to varying performance based on the underlying hardware on which flightgear is run. The PID/Autopilot tuning for a given model should not vary based on the hardware on which flightgear is run. Should it? Or did I get this all wrong? -- Cheers! Kishore -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
I haven't looked at these autopilot configurations (at least not for a long time) but off the top of my head, I think this can all be fixed by tuning the autopilot. For instance, lowering the max aileron deflection from (-1 ... 1) down to maybe (-0.1 ... 0.1) might be an interesting thing to start with. These are normalized values so +/-1 represents full deflection and 0.1 represents 1/10th of full deflection. If the autopilot is hitting you with full instantaneous aileron deflection that might be part of the issue. The other thing to look at is tuning the actual PID gains. These are obscured a bit given that we are using a slightly different form of the PID algorithm compared to what you might see in a Control Theory-101 class. I believe there is an autopilot tuning README and it just takes some fiddling around to see what changing the different values will accomplish. There's an art (maybe part science) to tuning autopilots ... I've yet to meet an expert in that area, but they must exist ... they are probably locked in the basement of Airbus and Boeing and various UAV companies and not allowed to leave their cells. :-) Curt. On Sat, Oct 10, 2009 at 1:56 PM, Pete Morgan ac...@daffodil.uk.com wrote: I'm working on my motion sim for xmas. Its powered by a vacum cleaner atmo.. One BIG BIG problem - am basicng the cockpit on Bravo and 787 The autopilot heading bug is very violent and JERKS to direction.. How can we solve that problem please because on my motion platform, I cant keep up with the drastric movements. Actually I can, but this is where there is a problem.. the behaviour of bank is performing well with the Ardiono/pneumatics card firing off the valves, however the violent values from the autopilot when auto pilot is engaged is causing a problem.. I've damped it down in my arduino/python middle man code, But I think this problem is an actual flightgear problem.. Any one offer me some advice which area of code to look at please... eg I could damp it in nasal script ? pete -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
Actually my motion platform is at the momnet I am taking it one step at a time.. ie so far its banking left to right by around 10 degree's which kinda exagarrated the sim and is useful.. Anyone as a pilot at the moment can tip the aircfaft to lbank.. However this jerk needs solving.. SO what you are saying is .. stuff FlightGear and its your problem.. pete Curtis Olson wrote: I haven't looked at these autopilot configurations (at least not for a long time) but off the top of my head, I think this can all be fixed by tuning the autopilot. For instance, lowering the max aileron deflection from (-1 ... 1) down to maybe (-0.1 ... 0.1) might be an interesting thing to start with. These are normalized values so +/-1 represents full deflection and 0.1 represents 1/10th of full deflection. If the autopilot is hitting you with full instantaneous aileron deflection that might be part of the issue. The other thing to look at is tuning the actual PID gains. These are obscured a bit given that we are using a slightly different form of the PID algorithm compared to what you might see in a Control Theory-101 class. I believe there is an autopilot tuning README and it just takes some fiddling around to see what changing the different values will accomplish. There's an art (maybe part science) to tuning autopilots ... I've yet to meet an expert in that area, but they must exist ... they are probably locked in the basement of Airbus and Boeing and various UAV companies and not allowed to leave their cells. :-) Curt. On Sat, Oct 10, 2009 at 1:56 PM, Pete Morgan ac...@daffodil.uk.com mailto:ac...@daffodil.uk.com wrote: I'm working on my motion sim for xmas. Its powered by a vacum cleaner atmo.. One BIG BIG problem - am basicng the cockpit on Bravo and 787 The autopilot heading bug is very violent and JERKS to direction.. How can we solve that problem please because on my motion platform, I cant keep up with the drastric movements. Actually I can, but this is where there is a problem.. the behaviour of bank is performing well with the Ardiono/pneumatics card firing off the valves, however the violent values from the autopilot when auto pilot is engaged is causing a problem.. I've damped it down in my arduino/python middle man code, But I think this problem is an actual flightgear problem.. Any one offer me some advice which area of code to look at please... eg I could damp it in nasal script ? pete -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net mailto:Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
Do you really expect much help after that stuff you lot remark? As a former autopilot designer I would suggest that what is needed is a rate limit on roll angle demand within the autopilot. You could also try to add some roll damping within the autopilot. It is possible that the FDM for your aircraft is making the simulated aircraft over-sensitive to aileron. How this should be implemented within Flightgear I am not in a position to tell you as I am not familiar with the code, sorry. -Original Message- From: Pete Morgan [mailto:ac...@daffodil.uk.com] Sent: 10 October 2009 20:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autopilot and violent roll Actually my motion platform is at the momnet I am taking it one step at a time.. ie so far its banking left to right by around 10 degree's which kinda exagarrated the sim and is useful.. Anyone as a pilot at the moment can tip the aircfaft to lbank.. However this jerk needs solving.. SO what you are saying is .. stuff FlightGear and its your problem.. pete Curtis Olson wrote: I haven't looked at these autopilot configurations (at least not for a long time) but off the top of my head, I think this can all be fixed by tuning the autopilot. For instance, lowering the max aileron deflection from (-1 ... 1) down to maybe (-0.1 ... 0.1) might be an interesting thing to start with. These are normalized values so +/-1 represents full deflection and 0.1 represents 1/10th of full deflection. If the autopilot is hitting you with full instantaneous aileron deflection that might be part of the issue. The other thing to look at is tuning the actual PID gains. These are obscured a bit given that we are using a slightly different form of the PID algorithm compared to what you might see in a Control Theory-101 class. I believe there is an autopilot tuning README and it just takes some fiddling around to see what changing the different values will accomplish. There's an art (maybe part science) to tuning autopilots ... I've yet to meet an expert in that area, but they must exist ... they are probably locked in the basement of Airbus and Boeing and various UAV companies and not allowed to leave their cells. :-) Curt. On Sat, Oct 10, 2009 at 1:56 PM, Pete Morgan ac...@daffodil.uk.com mailto:ac...@daffodil.uk.com wrote: I'm working on my motion sim for xmas. Its powered by a vacum cleaner atmo.. One BIG BIG problem - am basicng the cockpit on Bravo and 787 The autopilot heading bug is very violent and JERKS to direction.. How can we solve that problem please because on my motion platform, I cant keep up with the drastric movements. Actually I can, but this is where there is a problem.. the behaviour of bank is performing well with the Ardiono/pneumatics card firing off the valves, however the violent values from the autopilot when auto pilot is engaged is causing a problem.. I've damped it down in my arduino/python middle man code, But I think this problem is an actual flightgear problem.. Any one offer me some advice which area of code to look at please... eg I could damp it in nasal script ? pete -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net mailto:Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend
Re: [Flightgear-devel] Autopilot and violent roll
Alan Teeder wrote: Do you really expect much help after that stuff you lot remark? Sorry.. guess it my frustration... As a former autopilot designer I would suggest that what is needed is a rate limit on roll angle demand within the autopilot. You could also try to add some roll damping within the autopilot. It is possible that the FDM for your aircraft is making the simulated aircraft over-sensitive to aileron. Precisely the problem,. I;m readinga property tree and aparently all aircraft with new heading can Immeseatley tip to that bank angle,, u can so that with live controls. dot period . How this should be implemented within Flightgear I am not in a position to tell you as I am not familiar with the code, sorry. Who I'd like to engage is someone who is familiar witht eh code, albeit c_++, py or indeed nasal.. This is a problem across the whole system and a mega fault. pete -Original Message- From: Pete Morgan [mailto:ac...@daffodil.uk.com] Sent: 10 October 2009 20:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autopilot and violent roll Actually my motion platform is at the momnet I am taking it one step at a time.. ie so far its banking left to right by around 10 degree's which kinda exagarrated the sim and is useful.. Anyone as a pilot at the moment can tip the aircfaft to lbank.. However this jerk needs solving.. SO what you are saying is .. stuff FlightGear and its your problem.. pete Curtis Olson wrote: I haven't looked at these autopilot configurations (at least not for a long time) but off the top of my head, I think this can all be fixed by tuning the autopilot. For instance, lowering the max aileron deflection from (-1 ... 1) down to maybe (-0.1 ... 0.1) might be an interesting thing to start with. These are normalized values so +/-1 represents full deflection and 0.1 represents 1/10th of full deflection. If the autopilot is hitting you with full instantaneous aileron deflection that might be part of the issue. The other thing to look at is tuning the actual PID gains. These are obscured a bit given that we are using a slightly different form of the PID algorithm compared to what you might see in a Control Theory-101 class. I believe there is an autopilot tuning README and it just takes some fiddling around to see what changing the different values will accomplish. There's an art (maybe part science) to tuning autopilots ... I've yet to meet an expert in that area, but they must exist ... they are probably locked in the basement of Airbus and Boeing and various UAV companies and not allowed to leave their cells. :-) Curt. On Sat, Oct 10, 2009 at 1:56 PM, Pete Morgan ac...@daffodil.uk.com mailto:ac...@daffodil.uk.com wrote: I'm working on my motion sim for xmas. Its powered by a vacum cleaner atmo.. One BIG BIG problem - am basicng the cockpit on Bravo and 787 The autopilot heading bug is very violent and JERKS to direction.. How can we solve that problem please because on my motion platform, I cant keep up with the drastric movements. Actually I can, but this is where there is a problem.. the behaviour of bank is performing well with the Ardiono/pneumatics card firing off the valves, however the violent values from the autopilot when auto pilot is engaged is causing a problem.. I've damped it down in my arduino/python middle man code, But I think this problem is an actual flightgear problem.. Any one offer me some advice which area of code to look at please... eg I could damp it in nasal script ? pete -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net mailto:Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu
Re: [Flightgear-devel] Autopilot and violent roll
This is a problem across the whole system and a mega fault. If you mean this sudden banking when after reaching a new wayoint: yes. It is known and is still on the bug-list on flightgear.org anywhere. There were some aircraft authors who had a workaround with nasal- to my knowledge the 787 Forums-version and so much as I know the 777 by Syd had this also. With the work by James Turner now on the GPS and Route-Manager it would be nice we could solve that. Bu Mega-fault is a bit hard said- the people here are working for free and in their spare-time beside Job, family and other hobbies -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sat, Oct 10, 2009 at 3:23 PM, Heiko Schulz aeitsch...@yahoo.de wrote: If you mean this sudden banking when after reaching a new wayoint: yes. It is known and is still on the bug-list on flightgear.org anywhere. There were some aircraft authors who had a workaround with nasal- to my knowledge the 787 Forums-version and so much as I know the 777 by Syd had this also. With the work by James Turner now on the GPS and Route-Manager it would be nice we could solve that. Bu Mega-fault is a bit hard said- the people here are working for free and in their spare-time beside Job, family and other hobbies Really, this is all in how the autopilot is tuned and configured. FlightGear doesn't model realistic control surface deflection rates so it's possible to command an instantaneous deflection of the control surfaces. FlightGear also doesn't model how much load the airframe can endure before pieces began to depart and go their own separate ways. Thus assuming infinite control surface deflection rates and perfectly rigid and robust airframe, and assuming the flight dynamics are configured correctly, what you see is a realistic response. You can tune the control surface movement rates and maximum deflection angles in the autopilot configuration for each aircraft. This would be an excellent place to start. This isn't a systemic FlightGear problem, it's an autopilot configuration problem that seems to be replicated across many aircraft. But tuning autopilots is hard for most people, and probably for most aircraft authors so this is an area that is not attended to very well. You might be imagining that FlightGear has a single universal autopilot that runs all airplanes the same way, and you'd be wrong. There is an individual config file that sets up the cascading stages and inputs and reference values and outputs for each stage. You can do a lot of neat stuff with it, but if it's not well tuned you'll get a lot of unstable behavior. For what it's worth I recently saw a very expensive UAV flying with a poorly tuned autopilot and the result was not smooth and graceful whereas the aircraft flew beautifully under manual control. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Saturday 10 October 2009 22:33:01 Curtis Olson wrote: Really, this is all in how the autopilot is tuned and configured. FlightGear doesn't model realistic control surface deflection rates so it's possible to command an instantaneous deflection of the control surfaces. Control surface deflection rate can be limited by inserting a low-pass filter between the output of the final PID-controller and the control surface. THis is done in the autopilot config file. FlightGear also doesn't model how much load the airframe can endure before pieces began to depart and go their own separate ways. Thus assuming infinite control surface deflection rates and perfectly rigid and robust airframe, and assuming the flight dynamics are configured correctly, what you see is a realistic response. You can tune the control surface movement rates and maximum deflection angles in the autopilot configuration for each aircraft. This would be an excellent place to start. This isn't a systemic FlightGear problem, it's an autopilot configuration problem that seems to be replicated across many aircraft. But tuning autopilots is hard for most people, and probably for most aircraft authors so this is an area that is not attended to very well. You might be imagining that FlightGear has a single universal autopilot that runs all airplanes the same way, and you'd be wrong. There is an individual config file that sets up the cascading stages and inputs and reference values and outputs for each stage. You can do a lot of neat stuff with it, but if it's not well tuned you'll get a lot of unstable behavior. For what it's worth I recently saw a very expensive UAV flying with a poorly tuned autopilot and the result was not smooth and graceful whereas the aircraft flew beautifully under manual control. Best regards, Curt. -- Roy Vegard Ovesen -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
Roy Vegard Ovesen wrote: On Saturday 10 October 2009 22:33:01 Curtis Olson wrote: Really, this is all in how the autopilot is tuned and configured. FlightGear doesn't model realistic control surface deflection rates so it's possible to command an instantaneous deflection of the control surfaces. Control surface deflection rate can be limited by inserting a low-pass filter between the output of the final PID-controller and the control surface. THis is done in the autopilot config file. I expected FlightGear to crete the realistic mdel.. and deflection rate.. So your response cofirmas a few facts... ie if u stick in a new value to the FDM then it will react.. That sucks in my oioiion.. I how have to create my own craqo to make the model. that sucks to me.. pete -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
From: Roy Vegard Ovesen [mailto:roy.v.ove...@haugnett.no] Control surface deflection rate can be limited by inserting a low-pass filter between the output of the final PID-controller and the control surface. THis is done in the autopilot config file. For JSBSim aircraft, you also have the actuator control system component, which supports modeling of just such a lag as Roy describes, but also rate and position limiting, drift, hysteresis, deadband, and bias. Jon -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
