Re: [Flightgear-devel] Autopilot and violent roll

[leee]

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 h

[Flightgear-devel] time.h (was Re: GPS / route-manager landing)

[James Turner]

On 10 Oct 2009, at 08:56, Olaf Flebbe wrote:

>> Also, if we have two consistent time_t, why not simply subtract one  
>> from
>> the other, ABS it, and voila you have the time difference ? Or am I
>> missing something regarding usage of difftime ?
>
> yes. there is no _standard_ mapping of the data type time_t to any
> standard C/C++ data type.
>
> i.e. time_t may be a struct (for instance for  compilers which cannot
> handle 128 bit time_t).
>
> One should not guard  with an HAVE_WINDOWS_H because time.h is
> the correct header. See
>
> man 2 time, man difftime

Fair points :)

As a general note, the time.h isn't doing what I need really (and  
neither do the current SG time classes). I'm leaving the current code  
as is, until I decide how I really want to handle time. It's quite  
likely it will be based on the boost classes, since they are portable,  
and explicitly handle time zones and many other complex issues. The  
only problem will be store the values in the property tree.

Regards,
James


--
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

[Jon S. Berndt]

> 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

Re: [Flightgear-devel] Autopilot and violent roll

[Pete Morgan]

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

[Roy Vegard Ovesen]

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

[Curtis Olson]

On Sat, Oct 10, 2009 at 3:23 PM, Heiko Schulz  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

[Heiko Schulz]

> 
> 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

[Pete Morgan]

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 > > 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. Jumps

[Flightgear-devel] Autopilot

[Pete Morgan]

We need to define the autopilot properly and define its behaviour.

At it's most basic I expect the autpoilot to fullfil the following 
functions.

1) maintain a heading - ie go that way direction - this "jerks" 
violently in the sim
2) Altitude hold - this works, and on the motion platform it works and cool
3) speed - this is working cool


My bone of contention is that I cant "jerks" the sim to a new bank 
angle, setting a new Flight Level works sweet.. So the sim is certainly 
to blame as it would be impossible to move that quickly in a physical thing.

Expected is for one to tip the joystick, mouse, bigStick to a turn angle 
and its real ie some drag time

Engaging the autopilot causes the actual aircraft to violently turn to 
bank angle..

The sim needs to damp down the autopilot inputs to being the same as 
real control.


pete
is going to bed ad think about it a bit more. os I think its a sim issue 
and NOT a motion issue. Ie I couldnt turn an airfraft that way if I 
wanted to..




--
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

[Alan Teeder]

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  > 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
>   



--
Come build with us! The BlackBerry(R) Devel

Re: [Flightgear-devel] Autopilot and violent roll

[Pete Morgan]

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  > 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
>   


--
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

[Curtis Olson]

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  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

[Flightgear-devel] Autopilot and violent roll

[Pete Morgan]

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

Re: [Flightgear-devel] SimGear compile error

[Anders Gidenstam]

On Sat, 10 Oct 2009, dave perry wrote:

> I have --build=i686 as a switch to configure.  Where do I supply "-march="?

You set CXXFLAGS and CFLAGS (but the latter might not be needed). My 
configure line starts with:

configure CFLAGS="-O2 -g -march=core2 -mfpmath=sse -Wall" CXXFLAGS="-O2 -g 
-pipe -march=core2 -mfpmath=sse -Wall"


Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
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] SimGear compile error

[dave perry]

Mathias Fröhlich wrote:
> Hi,
>
> A recent checkin into SGAtomic.cxx brakes that.
>
> Either provide a -march= option higher than i386 to your compile, or revert 
> to 
> rev 1.3 of SGAtomic.cxx.
>
> I am currently asking the author of that change what this patch should fix.
>
>
>   
I have --build=i686 as a switch to configure.  Where do I supply "-march="?

Dave P.


--
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] SimGear compile error

[Mathias Fröhlich]

Hi,

A recent checkin into SGAtomic.cxx brakes that.

Either provide a -march= option higher than i386 to your compile, or revert to 
rev 1.3 of SGAtomic.cxx.

I am currently asking the author of that change what this patch should fix.

Greetings

Mathias

--
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] SimGear compile error

[Anders Gidenstam]

On Sat, 10 Oct 2009, dave perry wrote:

> With today's SimGear CVS, I am getting the following compile error
> Making all in props
> make[3]: Entering directory `/home/dad/source-osg/SimGear/simgear/props'
> g++  -g -O2 -D_REENTRANT -lOpenThreads  -o props_test props_test.o
> libsgprops.a ../../simgear/xml/libsgxml.a ../../simgear/misc/libsgmisc.a
> ../../simgear/debug/libsgdebug.a ../../simgear/structure/libsgstructure.a
> props_test.o: In function `SGAtomic::operator--()':
> /home/dad/source-osg/SimGear/simgear/props/../../simgear/structure/SGAtomic.hxx:60:
> undefined reference to `__sync_sub_and_fetch_4'

Hi,

This problem has been discussed on IRC but as far as I recall we didn't 
reach a certain solution. Can you try setting the target machine 
architecture? I use -march=core2 (appropriate for my box) and have not 
had this problem (but I have gcc 4.3.4).

It seems possible that these intrinsic functions are only available when 
the target hardware can support them in a reasonable way. IIRC some of the 
basic atomic read-write operations were first introduced in the i486 while 
the default target for gcc is probably i386.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
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

[Flightgear-devel] SimGear compile error

[dave perry]

With today's SimGear CVS, I am getting the following compile error
Making all in props
make[3]: Entering directory `/home/dad/source-osg/SimGear/simgear/props'
g++  -g -O2 -D_REENTRANT -lOpenThreads  -o props_test props_test.o 
libsgprops.a ../../simgear/xml/libsgxml.a ../../simgear/misc/libsgmisc.a 
../../simgear/debug/libsgdebug.a ../../simgear/structure/libsgstructure.a
props_test.o: In function `SGAtomic::operator--()':
/home/dad/source-osg/SimGear/simgear/props/../../simgear/structure/SGAtomic.hxx:60:
 
undefined reference to `__sync_sub_and_fetch_4'


I am running Fedora 10 with gcc-4.3.2-7.i386.

Regards,
Dave P.


--
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] Exposing a property over MP

[Mathias Fröhlich]

Hi,

On Thursday 08 October 2009 22:09:40 Martin Spott wrote:
> If bandwidth is not a matter, then you'd probably want to jump on the
> HLA train and join the CERTI/VirtualAir effort. They're offering
> everything like subscribing to attributes and the such   yet I have
> to state that reduced bandwidth footprint, compared to the current
> state, would be beneficial to have in CERTI  ;-)
... currently working on fixing usability stuff in certi. So stay tuned :)
Anyway, I also consider an RTI a possible multiplayer replacement.
Even if we would handle local RTI federations different than internet wide 
stuff. But yes, an RTI provides almost all we would need to get that right.

Greetings

Mathias

--
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] Exposing a property over MP

[Mathias Fröhlich]

Hi,

On Thursday 08 October 2009 17:29:21 James Turner wrote:
> Related to the new route-manager: I could very easily define a string
> property which contains a plain text summary of the filed flight-plan.
> What is the magic required to expose that string (which be 200 or 400
> bytes, I guess, depending on how many waypoints are in the route) over
> MP, so that the ATC 'aircraft' could see them?
> 
> Is there an 'event' channel in MP, to deal with properties which
> change infrequently? (Compared to position/velocity/surface positions/
> etc)

No, the current implementation just dumps all.
If you want to do that in a reliable way with a minimum of transferred data 
you will need a bunch of changes to the protocol and the server.

The easiest way would be to have some fields not updated on each cycle but just 
update only about every few seconds. Make sure that you add some randomness to 
the count that we avoid bursts to the communication of those values.

Greetings

Mathias

--
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] GPS / route-manager landing

[Olaf Flebbe]

Hi,

> 
> Also, if we have two consistent time_t, why not simply subtract one from 
> the other, ABS it, and voila you have the time difference ? Or am I 
> missing something regarding usage of difftime ?

yes. there is no _standard_ mapping of the data type time_t to any 
standard C/C++ data type.

i.e. time_t may be a struct (for instance for  compilers which cannot 
handle 128 bit time_t).

One should not guard  with an HAVE_WINDOWS_H because time.h is 
the correct header. See

man 2 time, man difftime


Cheers
Olaf

--
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