snip
So that's what I've come up with so far. Am I completely nuts? Any
suggestions? I have no formal education in control theory,
so what I know
has been gleaned from here and there so I probably don't know
much of the
correct terminology and there are certainly tricks and things
Hi Guys
Curtis L. Olson writes
This is my general plan. Right now I have the autopilot config in a
separate .xml file
* The autopilot should get input from other instruments (airspeed
indicator, altimeter, attitude indicator, etc.), and not from
/position/altitude-ft, /velocities/..., etc.
Bohnert Paul [EMAIL PROTECTED] wrote:
Consider it done. Robin said he will add them as soon
as he can.
The meanings of these two sentences are 'diametrically opposed' ;-)
No, I don't want to accuse Robin, I fully understand that there are
times where the first priority is not occupated by his
On Thu, 22 Jan 2004 17:28:51 +0800, Innis Cunningham [EMAIL PROTECTED]
wrote:
As far as I am aware on any autopilot I ever worked on the
autopilot/autothrottle took
no information from the instruments.It provides information to the
instruments so the
pilot can see what the autopilot is
On Wed, 21 Jan 2004 22:28:22 -0600, Curtis L. Olson [EMAIL PROTECTED]
wrote:
Roy Vegard Ovesen wrote:
Let me share my thoughts about the autopilot:
* I would like to see the autopilot move from c++ code into the
instrument configuration xml-files.
This is my general plan. Right now I have the
After reading through "fg_props.hxx", I found
that the most efficient was to get a property value is to use fgGetNode instead
of the "fgGet" functions.
Is there a more efficient way to set properties, or is that best way to
use the "fgSet" functions
Thanks.
Adam
Hi,
I was formerly using flightgear-devel but someone suggested to adress
technical problems here. ;-)
Since Slackware will use Alsa sound from version 9.1 and onwards I would
like to mention a sound problem with some planes. Running
--aircraft=c310-yasim I'll get no plane sound, just the OM
Hello,
I have a Logitech joystick on the loose. It's a silvery/black, four-legged
USB wired Logitech.
js_demo says:
Joystick 0: Logitech Logitech Extreme 3D Pro
and I think the wireless 'brother' says the same. USB don't know what's
outside the transmitter...
The buttons are a bit funny.
Roy Vegard Ovesen wrote:
And I firmly believe that we _should_ use the instrument values because
in my mind using /position/... and /velocities/... would be cheating,
theese perfect values are _not_ available in the real world.
I definitely agree. We should have instrument values well modeled
Snyder Adam D Civ AFRL/VACD wrote:
After reading through fg_props.hxx, I found that the most efficient
was to get a property value is to use fgGetNode instead of the fgGet
functions. Is there a more efficient way to set properties, or is that
best way to use the fgSet functions
You could
* Curtis L. Olson -- Thursday 22 January 2004 18:46:
I'm half tempted to commit what I have to CVS. But that leaves a lot of
autopilot stuff temporarily broken.
You could make a cvs branch for that, and later merge it into head, if
it's done and tested.
m.
Adam D. Snyder wrote:
After reading through fg_props.hxx, I found that the most efficient
was to get a property value is to use fgGetNode instead of the fgGet
functions. Is there a more efficient way to set properties, or is
that best way to use the fgSet functions
The node objects you
And I firmly believe that we _should_ use the instrument values because
in my mind using /position/... and /velocities/... would be cheating,
theese perfect values are _not_ available in the real world.
I definitely agree. We should have instrument values well modeled for the
sorts of
This thread is scaring me. I hope we aren't deciding to hard-wire
the autoflight inputs from panel instrument output?
Why hardwire anything? Why not write it to take property nodes as the
input and output entities, and let the glue layers (XML, Nasal,
etc...) handle the configuration.
David Culp wrote:
This thread is scaring me. I hope we aren't deciding to hard-wire
the autoflight inputs from panel instrument output?
Why hardwire anything? Why not write it to take property nodes as the
input and output entities, and let the glue layers (XML, Nasal,
etc...) handle the
David Culp wrote:
This thread is scaring me. I hope we aren't deciding to hard-wire the
autoflight inputs from panel instrument output?
The input choice will be strictly optional, right?
Figures, I just finished screwing the cowl back on ...
The whole point of defining the autopilot via xml is
Hello everybody,
After doing a complete build of the flightgear-0.9.3 source under Cygwin,
the simulation runs near perfect. However on two machines (one AMD XP, one
P4 XP) with a Radeon 9700 card, fog is incorrectly rendered. Only cloud and
ground polygons change gradualy to a white color when
Avi Levy wrote:
Hello everybody,
After doing a complete build of the flightgear-0.9.3 source under Cygwin,
the simulation runs near perfect. However on two machines (one AMD XP, one
P4 XP) with a Radeon 9700 card, fog is incorrectly rendered. Only cloud and
ground polygons change gradualy to a
I'm new to this group, and would like to add that if there is any
information needed on MD11 and B767 flight characteristics or systems, feel
free to ask through this mailing list, I have a lot of flying hours on
these types.
Are you planning on making models of these yourself? It doesn't
-- Original Message --
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Proposed change to Terrain Following control
Date: Thu, 22 Jan 2004 14:09:30 -0600
Reply-To: FlightGear developers discussions [EMAIL PROTECTED]
Snyder Adam D Civ AFRL/VACD wrote:
After reading through fg_props.hxx, I found that the most efficient
was to get a property value is to use fgGetNode instead of the fgGet
functions. Is there a more efficient way to set properties, or is that
best way to use the fgSet functions
Yes,
Hi,
This is a heads up for all 3d model designers.
In order to be able the use your model as an AIModel (and later on ATC
controlled model) it is important that the properties used in the
animation configuration file are *not* absolute, but instead are defined
relative.
This is done quite
Curtis L. Olson wrote:
And I firmly believe that we _should_ use the instrument values
because in my mind using /position/... and /velocities/... would be
cheating, theese perfect values are _not_ available in the real world.
I definitely agree. We should have instrument values well modeled
Any chanceof doing a look-ahead on the scenery polygons to get an altitude
eg 2mi in front (for TSR2?)
- Original Message -
From: Andy Ross [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, January 22, 2004 8:12 PM
Subject: Re: [Flightgear-devel]
Richard Hornby wrote:
Any chanceof doing a look-ahead on the scenery polygons to get an
altitude eg 2mi in front (for TSR2?)
Yes, so long as the tile is loaded. But that's not the way that real
autopilots work. The real world doesn't have a scenery elevation
API. :)
Doing this right would
On Thu, 22 Jan 2004 16:15:41 -0500
David Megginson [EMAIL PROTECTED] wrote:
I agree as well. An autopilot driven by the gyro compass should
reflect all of the compass's error's, such as drift; ditto for an AP
driven by a VOR receiver. If we want to model an AP driven by a GPS,
INS, and/or
-- Original Message --
Date: Thu, 22 Jan 2004 11:46:00 -0600
From: Curtis L. Olson [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Proposed change to Terrain Following control
Reply-To: FlightGear developers discussions [EMAIL PROTECTED]
-- Original Message --
From: Jon S Berndt [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Proposed change to Terrain Following
control
To: FlightGear developers discussions [EMAIL PROTECTED]
Date: Thu, 22 Jan 2004 15:40:55 -0600
Reply-To: FlightGear developers discussions [EMAIL PROTECTED]
I
Any chanceof doing a look-ahead on the scenery polygons to get an
altitude eg 2mi in front (for TSR2?)
Yes, so long as the tile is loaded. But that's not the way that real
autopilots work. The real world doesn't have a scenery elevation
API. :)
Doing this right would presumably require
On Thursday 22 January 2004 22:12, David Culp wrote:
Any chanceof doing a look-ahead on the scenery polygons to get an
altitude eg 2mi in front (for TSR2?)
Yes, so long as the tile is loaded. But that's not the way that real
autopilots work. The real world doesn't have a scenery
Lee Elliott wrote:
I've been giving quite a bit of thought to look-ahead algorithms for terrain
following. The most straight forward way would be to take a number of
look-ahead samples each frame, and simply take the highest point as the
target alt.
Taking a lot of samples each frame can't be
Now if you do one terrain intersection lookup each frame and do it 2400
meters ahead of you. But, also keep the last 10 sec * 60 fps lookups in a
buffer, then assuming you are flying in a straight line, once your buffer
fills up, that gives you a set of elevation points in your path at 4
On Thursday 22 January 2004 22:54, Curtis L. Olson wrote:
Lee Elliott wrote:
I've been giving quite a bit of thought to look-ahead algorithms for
terrain following. The most straight forward way would be to take a
number of look-ahead samples each frame, and simply take the highest
point
Lee Elliott writes:
On Thursday 22 January 2004 22:54, Curtis L. Olson wrote:
Lee Elliott wrote:
I've been giving quite a bit of thought to look-ahead algorithms for
terrain following. The most straight forward way would be to take a
number of look-ahead samples each frame, and
On Thu, Jan 22, 2004 at 09:35:23PM +0100, Avi Levy wrote:
I'm new to this group, and would like to add that if there is any
information needed on MD11 and B767 flight characteristics or systems, feel
free to ask through this mailing list, I have a lot of flying hours on these
types.
A MD11
Here's an interesting MD-11 that NASA has modified:
http://www.nasatech.com/Briefs/May02/DRC9655.html
Controling the airplane with engines only is interesting, but controling it
with engines on one side only is amazing. This could probably be modeled in
JSBSim, and perhaps with Curt's new
36 matches
Mail list logo
