David Culp [EMAIL PROTECTED] said:
We just need another calculation
in the update_helper for the /orientation/heading-magnetic-deg value.
Yes, I looked through update_helper, and the other error calculations are
compatable with inertial systems, so only the heading source need be
Roy Vegard Ovesen [EMAIL PROTECTED] said:
On Tue, 3 Feb 2004 17:10:07 -, Jim Wilson [EMAIL PROTECTED] wrote:
Roy Vegard Ovesen [EMAIL PROTECTED] said:
The obvious thing you missed is the fact that newauto.cxx is no longer
used, it has been removed from the makefile. So many of the
Jim Wilson wrote:
That sounds like it might be the right way to do it. Is it better to use a
general flag like that or to have one that is specific to indicated heading as
in the old autopilot code?
Does this work for the designers (Curt et al), using configuration properties
to manipulate the
Curtis L. Olson [EMAIL PROTECTED] said:
Jim Wilson wrote:
That sounds like it might be the right way to do it. Is it better to use a
general flag like that or to have one that is specific to indicated heading as
in the old autopilot code?
Does this work for the designers (Curt et
Jim Wilson wrote:
It is indeed! Is the altitude hold working for you? I'm finding that the
first stage is outputing values that ocilate from max to min and back in
probably 5 or 6 (not timed yet) cycles. Anyway, I haven't looked at the code
or adjusted any of the parameters yet. I just wanted
Jim Wilson wrote:
Curtis L. Olson [EMAIL PROTECTED] said:
Jim Wilson wrote:
That sounds like it might be the right way to do it. Is it better to use a
general flag like that or to have one that is specific to indicated heading as
in the old autopilot code?
Does this work for the designers
Yes, that leaves the options open. May I suggest this then? (I'm trying
to get the 747 a/p together :-))
Beat me to it :) Here are two other calculations you'll need, vertical speed
error and mach error.
// Calculate vertical speed error
static SGPropertyNode *target_vert_speed
On Wed, 4 Feb 2004 13:28:39 -0600, David Culp [EMAIL PROTECTED]
wrote:
Beat me to it :) Here are two other calculations you'll need, vertical
speed
error and mach error.
// Calculate vertical speed error
static SGPropertyNode *target_vert_speed
= fgGetNode(
I think this is taking it one step too far. We don't need to calculate
vertical speed error, that is done inside the controller (when you use
/velocities/vertical-speed-fps ans input and
/autopilot/settings/vert-speed-fps as reference).
I see. Thanks.
Dave
--
On Tuesday 03 February 2004 02:23, Jim Wilson wrote:
Curtis L. Olson [EMAIL PROTECTED] said:
For everyone: I've integrated this into a larger document which attempts
to explain the basic ideas behind control theory and then describes the
specific PID algorithm we have implimented for
Lee Elliott [EMAIL PROTECTED] said:
On Tuesday 03 February 2004 02:23, Jim Wilson wrote:
Curtis L. Olson [EMAIL PROTECTED] said:
For everyone: I've integrated this into a larger document which attempts
to explain the basic ideas behind control theory and then describes the
specific
On Wed, 4 Feb 2004 21:39:23 -
Jim Wilson [EMAIL PROTECTED] wrote:
Curt fixed that today. It even works pretty well with the 747. With
the one
he commited, the gain is higher than what you have (Kp=1.0), a little
longer
intergration period (Ti=25.0) and the derivator is way down to almost
On Wed, 4 Feb 2004 00:48:00 +, Lee Elliott
[EMAIL PROTECTED] wrote:
!-- Altitude hold. 2 stage cascade controller. --
!-- Stage #1 sets target rate of climb based on diff between current
alt
--
!-- and target altitude. --
pid-controller
nameAltitude Hold (Altimeter based)
Jon S Berndt [EMAIL PROTECTED] said:
On Wed, 4 Feb 2004 21:39:23 -
Jim Wilson [EMAIL PROTECTED] wrote:
Curt fixed that today. It even works pretty well with the 747. With
the one
he commited, the gain is higher than what you have (Kp=1.0), a little
longer
intergration period
Hello Curt,
I've been trying to customise the AP pitch hold controller so that I can use
it for take-offs - helps a lot with consistancy when I'm working on the fdms.
I've got something working for the TSR2 but it starts oscillating at around
210kias. I can also tune it so that it doesn't
On Wednesday 04 February 2004 21:39, Jim Wilson wrote:
Lee Elliott [EMAIL PROTECTED] said:
On Tuesday 03 February 2004 02:23, Jim Wilson wrote:
Curtis L. Olson [EMAIL PROTECTED] said:
For everyone: I've integrated this into a larger document which
attempts to explain the basic ideas
On Wednesday 04 February 2004 21:52, Roy Vegard Ovesen wrote:
On Wed, 4 Feb 2004 00:48:00 +, Lee Elliott
[EMAIL PROTECTED] wrote:
!-- Altitude hold. 2 stage cascade controller. --
!-- Stage #1 sets target rate of climb based on diff between current
alt
--
!-- and target
On Wednesday 04 February 2004 22:03, Roy Vegard Ovesen wrote:
On Wed, 04 Feb 2004 15:44:15 -0600, Jon S Berndt [EMAIL PROTECTED] wrote:
I'm wondering if a PID controller is only marginally better than a PI
controller. What if you remove the D control altogether?
That would crash the
Arguably, it
should be the FDM that provides vertical speed in fps but if that doesn't
happen in the near term, then I don't see a problem with the autopilot
doing a quick conversion for it's own use.
Regards,
Curt.
JSBSim has this:
velocities/v-down-fps
But, we also have this:
On Mon, 2 Feb 2004 18:39:23 -0600, David Culp [EMAIL PROTECTED]
wrote:
Thanks Curt, Jeff, Norman and Wendell for the slick new autopilot system.
I've been playing with it, trying to adapt the generic autopilot to the
737.
I see that I can set the autopilot to use actual mag heading, rather
So, it appears that newauto.cxx allows for the heading source to be
selected,
but FGXMLAutopilot::update_helper() has it hard-wired to the DG.
Or, very likely, I missed something obvious.
The obvious thing you missed is the fact that newauto.cxx is no longer
used, it has been removed
Roy Vegard Ovesen [EMAIL PROTECTED] said:
The obvious thing you missed is the fact that newauto.cxx is no longer
used, it has been removed from the makefile. So many of the properties
under /autopilot/config/ do no longer apply.
Yes, but that doesn't solve the problem. We just need
Jim Wilson wrote:
Roy Vegard Ovesen [EMAIL PROTECTED] said:
The obvious thing you missed is the fact that newauto.cxx is no longer
used, it has been removed from the makefile. So many of the properties
under /autopilot/config/ do no longer apply.
Yes, but that doesn't solve the problem. We
We just need another calculation
in the update_helper for the /orientation/heading-magnetic-deg value.
Yes, I looked through update_helper, and the other error calculations are
compatable with inertial systems, so only the heading source need be changed.
Perhaps all we need is to reinstate a
On Tue, 3 Feb 2004 17:10:07 -, Jim Wilson [EMAIL PROTECTED] wrote:
Roy Vegard Ovesen [EMAIL PROTECTED] said:
The obvious thing you missed is the fact that newauto.cxx is no longer
used, it has been removed from the makefile. So many of the properties
under /autopilot/config/ do no longer
A question. When defining a cascade controller, is it important that the early stages
of the controller go before the later stages in the config file?
Alternatively, do the individual PID controllers get processed in the order they
appear in the config file each frame, or are any dependencies
On Mon, 2 Feb 2004 10:55:05 -, Richard Bytheway
[EMAIL PROTECTED] wrote:
A question. When defining a cascade controller, is it important that the
early stages of the controller go before the later stages in the config
file?
The Primary controller (the one that sets the reference set-point
Richard Bytheway wrote:
A question. When defining a cascade controller, is it important that the
early stages of the controller go before the later stages in the config
file?
Yes, this is the optimal arrangement.
Alternatively, do the individual PID controllers get processed in
the order they
Thanks Curt, Jeff, Norman and Wendell for the slick new autopilot system.
I've been playing with it, trying to adapt the generic autopilot to the 737.
I see that I can set the autopilot to use actual mag heading, rather than DG
heading, by setting autopilot/config/indicated-heading-magnetic
Curtis L. Olson [EMAIL PROTECTED] said:
For everyone: I've integrated this into a larger document which attempts to
explain the basic ideas behind control theory and then describes the
specific PID algorithm we have implimented for FlightGear. This
information isn't strictly necessary for
Roy Vegard Ovesen wrote:
I've slapped together a short document on controller tuning.
[ snip ]
Thanks Roy!
For everyone: I've integrated this into a larger document which attempts to
explain the basic ideas behind control theory and then describes the
specific PID algorithm we have implimented
On Thu, 29 Jan 2004 01:45:18 -, Jim Wilson [EMAIL PROTECTED] wrote:
But to go back to the C172 example, does anyone actually understand how
this
issue is handled in a cessna autopilot or any of the others that might be
installed in a 172? Will it stall the aircraft? Or...hmmm...trying to
On Thu, 29 Jan 2004 11:40:38 +0100, Roy Vegard Ovesen
[EMAIL PROTECTED] wrote:
I just downloaded the Pilot's Guide from this link:
http://www.n612sp.com/KAP%20140%20AUTOPILOT.pdf
It seems that this pdf file does not contain the entire document. For the
complete document use this link:
Jim Wilson wrote:
But to go back to the C172 example, does anyone actually understand how this
issue is handled in a cessna autopilot or any of the others that might be
installed in a 172? Will it stall the aircraft? Or...hmmm...trying to
remember... does the 172 even have an AP for the pitch
William Earnest wrote:
I can't give an exact matching case, but here is some info on a
S-TEC System Twenty/System Thirty autopilot in a Piper Warrior II, a
plane in the C172 class.
The STEC is currently the AP of choice for any light aircraft, whether
shipped as a factory option or not.
Again, this is something that the JSBSim FCS components could handle - you
need building blocks.
Reading about the flight control system of the thrust vectoring fa-18 HARV in
http://techreports.larc.nasa.gov/ltrs/PDF/NASA-96-tm110216.pdf
and loooking at the released MATLAB code of a
Yikes! That's interesting. It's interesting that the file is called
roll_stick_limits. Judging by the title alone it would seem to be simply
a complicated way to calculate the limits of pilot stick roll inputs. In
fact, this is what the comment at the top of the file says:
this
On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED]
wrote:
Right now we have limits built into the altitude hold modules. For
instance, for the C172, I don't want to command a climb if the speed is
less that 70 kts. So I take the target climb rate and tail that off to
zero
Lee Elliott wrote:
I think I've heard of some of the stuff Curt's referring to - the next
gen US fighters are planned to be thrust vectoring only. Taking the
control surface stuff out of the wing removes channeling, making it
more simple but also stronger and more resiliant to damage - you
Roy Vegard Ovesen wrote:
I just started looking at Nasal, and I think that could be used for
summing, gaining, if...then, etc.
It certainly could. In the past I've warned (for performance reasons)
about getting into situations where a zillion Nasal scripts expect to
run every frame, but for
Roy Vegard Ovesen wrote:
I don't think this should be part of the PID algorithm. I think we
should use your hack and apply it to the setpoint to the v/s or pitch.
This means that we need some sort of if ... then functionality. I just
started looking at Nasal, and I think that could be used for
Roy Vegard Ovesen [EMAIL PROTECTED] said:
On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED]
wrote:
Right now we have limits built into the altitude hold modules. For
instance, for the C172, I don't want to command a climb if the speed is
less that 70 kts. So I
Hi All
As one of only a few people who have built an
autopilot for FG.I would ask what the perseved
problems are with the current system.
While I admit there are improvements to be made
What is there is pretty good.
At the risk also of seeming rude I would ask what
experence the people who are
Roy wrote:
What's inside the black box? That's what I want to configure.
Innis replied:
Why???.Thats why they are called a black box.
And unless you work for Bendix/King or one of the other black box
manufactures you will never know.After all what is in the black box
is there bread and
I agree with Jon. JSBSim (and possibly others) seems to be a notable
flightdynamics model even in research. It will be better not to restrict
posibilities in the area of modelling planes with their flightcontrol systems
including the autopilots behavour.
Greetings
Mathias
Roy
Hi Jon
Jon Berndt writes
Most people probably won't care to what level of detail the autopilot
functionality is mechanized in FlightGear. However, once a general purpose
heading A/P is crafted, or a wing leveler, etc., then those items as
specified in a configuration file could be reused. They
On 1/27/04 at 10:30 PM Innis Cunningham wrote:
Also how much more computing power will be required for what ever extra
detail may be involved.A 3D modeller would not even think of modeling the
insides of the engine or every rivit in the aircraft for the obvious
Almost certainly neglible
Innis Cunningham wrote:
This is what I dont understand what is wrong with the current system
which can do heading,V/S,wing leveler,vor/loc(nav),approach,and
autothrottle
are these not accurate enough?.
Also how much more computing power will be required for what ever extra
detail may be
Roy Vegard Ovesen wrote:
On Mon, 26 Jan 2004 13:13:44 -, Richard Bytheway
[EMAIL PROTECTED] wrote:
That would be the responsibility of the autopilot designer. If he/she
designed a control structure that used two separate
controllers that acted
on the ailerons, that would be his/her problem.
This is what I dont understand what is wrong with the current system
which can do heading,V/S,wing
leveler,vor/loc(nav),approach,and autothrottle
are these not accurate enough?.
Also how much more computing power will be required for what
ever extra
detail may be involved.A 3D modeller
On Tue, 27 Jan 2004 18:18:36 +0800, Innis Cunningham [EMAIL PROTECTED]
wrote:
Why???.Thats why they are called a black box.
And unless you work for Bendix/King or one of the other black box
manufactures you will never know.After all what is in the black box
is there bread and butter.
If nobody
On Tue, 27 Jan 2004 22:30:17 +0800, Innis Cunningham [EMAIL PROTECTED]
wrote:
This is what I dont understand what is wrong with the current system
which can do heading,V/S,wing leveler,vor/loc(nav),approach,and
autothrottle
are these not accurate enough?.
I'm sure the performance of the current
Just a bit more grist for the mill - as if it were needed:)
One of the type of up-coming generations of a/c are likely to be controlled by
thrust alone. No moving control surfaces and probably tailess.
What I haven't figured out yet is if the concept's relying upon a very simple
aerodynamic
My understanding is that they will be doing a lot of thrust
vectoring ... lots of research is/has been done in that area.
Curt.
No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion
only:
http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf
Differential thrust (per side)
No. This paper describes tests on a B-747, C-17, and MD-11 using
propulsion only:
I meant No thrust vectoring is necessary, nor used in the examples in the
referenced paper.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Jon Berndt wrote:
My understanding is that they will be doing a lot of thrust
vectoring ... lots of research is/has been done in that area.
Curt.
No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion
only:
http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf
Differential
I thought some were discussing this in the context of fighters of the
future. Just ignore me. :-)
Curt.
Oops. Yes, that has been done, most recently on an F-15 I believe. I must
have misinterpreted the context of the discussion.
Jon
___
On Wednesday 28 January 2004 02:26, Jon Berndt wrote:
My understanding is that they will be doing a lot of thrust
vectoring ... lots of research is/has been done in that area.
Curt.
No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion
only:
Lee wrote:
I think I've heard of some of the stuff Curt's referring to - the next gen
US
fighters are planned to be thrust vectoring only. Taking the control
surface
stuff out of the wing removes channeling, making it more simple but also
stronger and more resiliant to damage - you don't
Hi Curt
Curtis L. Olson writes
Also, we have several people here knowledgable in the field of control
theory and people that understand how autopilots are supposed to work. Add
that in with someone who (thinks he) understands the internals of FG and I
think we have an opportunity to really
On Sun, 25 Jan 2004 22:19:48 -, Jim Wilson [EMAIL PROTECTED] wrote:
These are all controllers for ailerons, elevators, rudders, etc. A
small and
easily definable set which is ideal for subclassing. Maybe we could
have a
subclass for each of these controls rather than trying to abstract a
That would be the responsibility of the autopilot designer. If he/she
designed a control structure that used two separate
controllers that acted
on the ailerons, that would be his/her problem. In fact it
might turn out
to be a good thing. ;-)
Does this imply that we also need a
On Mon, 26 Jan 2004 13:13:44 -, Richard Bytheway
[EMAIL PROTECTED] wrote:
That would be the responsibility of the autopilot designer. If he/she
designed a control structure that used two separate
controllers that acted
on the ailerons, that would be his/her problem. In fact it
might turn out
Roy Vegard Ovesen [EMAIL PROTECTED] said:
I disagree. I think we should have one generic controller class. Remember
that we don't want to control the ailerons, we want to control the roll
angle or the turn rate through the ailerons. We tell the controller that
we want 20 degrees left bank
On Mon, 26 Jan 2004 16:21:19 -
Jim Wilson [EMAIL PROTECTED] wrote:
That has nothing at all to do with what I said. We are controlling
individual
control surfaces. Period. I don't think we should have subclasses
for each
desired action/process. Only each control surface type. Roll
Jim Wilson wrote:
That has nothing at all to do with what I said. We are controlling
individual control surfaces. Period. I don't think we should have
subclasses for each desired action/process. Only each control
surface type. Roll control ends up being intrinsically part of
aileron
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
That has nothing at all to do with what I said. We are controlling
individual control surfaces. Period. I don't think we should have
subclasses for each desired action/process. Only each control
surface type. Roll control ends up
On Mon, 26 Jan 2004 17:42:02 -
Jim Wilson [EMAIL PROTECTED] wrote:
Good point (as is Jon's) but in all such design cases there are tradeoffs.
What I'm looking at is ease of configuration and that may be a
reasonable
tradeoff against the limitations of defining a standard set of
control
Hi,
That has nothing at all to do with what I said. We are controlling individual
control surfaces. Period. I don't think we should have subclasses for each
desired action/process. Only each control surface type. Roll control ends up
being intrinsically part of aileron control is it not?
On Mon, 26 Jan 2004 16:21:19 -, Jim Wilson [EMAIL PROTECTED] wrote:
That has nothing at all to do with what I said. We are controlling
individual
control surfaces. Period. I don't think we should have subclasses for
each
desired action/process. Only each control surface type.
Do you
On Mon, 26 Jan 2004 09:10:23 -0800, Andy Ross [EMAIL PROTECTED] wrote:
I'd strongly suggest an architecture where the autopilot specifies a
black box, with all input and output done via property nodes:
../roll-rate -++---+ /controls/elevator
../yaw-rate -+-- | Autopilot | --
On Mon, 26 Jan 2004 09:10:23 -0800, Andy Ross [EMAIL PROTECTED] wrote:
I'd strongly suggest an architecture where the autopilot specifies a
black box, with all input and output done via property nodes:
Elaborate?
../roll-rate -++---+ /controls/elevator
../yaw-rate
72 matches
Mail list logo
