Norman Vine writes:
Nice addition
Thanks.
No need for an 'expensive' derivation
of the rotation matrix though as you can
straight forwardly write it out all at once
Thanks! Your changes seem to make a big different -- I'm not seeing
any stuttering at the beginning, now. I've
On Tue 26. February 2002 14:52, you wrote:
Almost all of the major moving surfaces in the C172 are now animated:
It's wonderfull work.
There is a problem with propeller. With low frame rate I couldn't see
diferents between low and high RPMs. There is obvious to add instead of
rotating
Martin Dressler writes:
On Tue 26. February 2002 14:52, you wrote:
Almost all of the major moving surfaces in the C172 are now animated:
It's wonderfull work.
There is a problem with propeller. With low frame rate I couldn't see
diferents between low and high RPMs. There is obvious to
Tony Peden writes:
Is there a way to dump the entire tree to xml (whether or not the
archivable bit is set)?
Not currently, but I can modified writeProperties to take an extra,
optional argument, then make a dump-properties command.
All the best,
David
--
David Megginson
[EMAIL
David Megginson [EMAIL PROTECTED] said:
Martin Dressler writes:
There is a problem with propeller. With low frame rate I couldn't see
diferents between low and high RPMs.
Even with a fairly good framerate the prop doesn't look so good yet.
What we need to do is switch to a
Almost all of the major moving surfaces in the C172 are now animated:
- propeller
- ailerons
- flaps
- rudder
- elevators
The nosewheel still doesn't turn, but I'll add that when I get a
chance. I'll probably start on the DC-3 first, though.
Inevitably, I've got some of the movements
On Tue, 2002-02-26 at 05:58, Jon S. Berndt wrote:
Excellent. Is there an X-15 model? :-)
There's not much to see at Mach 5.
Jon
Almost all of the major moving surfaces in the C172 are now animated:
- propeller
- ailerons
- flaps
- rudder
- elevators
David
Jon S. Berndt writes:
Excellent. Is there an X-15 model? :-)
Seriously, there probably won't be one from me. My main interest is
civil propeller-driven planes, and after I've fixed up the DC-3 model,
I'll probably do a C-310 3D model, followed by a Twin Otter (if I can
manage a JSBSim or
David Megginson writes:
Almost all of the major moving surfaces in the C172 are now animated:
- propeller
- ailerons
- flaps
- rudder
- elevators
The nosewheel still doesn't turn, but I'll add that when I get a
chance. I'll probably start on the DC-3 first, though.
Inevitably,
Curtis L. Olson writes:
The elevator is backwards, but other than that it looks great. (The
flaps don't smoothly transition, but you probably are aware of that.)
Yes -- right now the surfaces are tied to /controls/*; I plan to
switch to values reported by the FDMs when a) they're all being
David Megginson writes:
Curtis L. Olson writes:
The elevator is backwards, but other than that it looks great. (The
flaps don't smoothly transition, but you probably are aware of that.)
Yes -- right now the surfaces are tied to /controls/*; I plan to
switch to values reported by the
Curtis L. Olson writes:
David Megginson writes:
Curtis L. Olson writes:
The elevator is backwards, but other than that it looks great. (The
flaps don't smoothly transition, but you probably are aware of that.)
Yes -- right now the surfaces are tied to /controls/*; I plan to
Curtis L. Olson writes:
David, I'm starting to get nit-picky here :-) but one more thing
... the elevator doesn't seem to be responding to elevator trim. In a
real life C172 the elevator trim is a little tab on the trailing edge
of the elevator that causes the elevator to actually
Curtis L. Olson [EMAIL PROTECTED] said:
David Megginson writes:
That said, it might be possible to animate the X-15 model that we
already have, assuming that the various objects in the model are
named.
I haven't looked at pretty-poly lately, but it might not be hard to
load up the
Curtis L. Olson writes:
David, I'm starting to get nit-picky here :-) but one more thing
... the elevator doesn't seem to be responding to elevator trim. In a
real life C172 the elevator trim is a little tab on the trailing edge
of the elevator that causes the elevator to actually
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Animated C172
Alex Perry writes:
(lots about trim)
For zero force yoke (aka centered joystick), motion of the trim
causes the tab to move one way and the elevator to move the other.
The ratio of the two angular rates is about equal to the ratio
On Tue, 26 Feb 2002 11:19:13 -0600 (CST),
Curtis L. Olson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
David Megginson writes:
I haven't added a tab object to the 3-D model yet, but I'd like to
understand more about how it actually works first (ditto for
elevator and rudder
* [EMAIL PROTECTED] (David Megginson) [2002.02.26 11:35]:
Alex Perry writes:
The position of the elevator is a force balance, consisting of the
aero force on the elevator, the aero force on the tab and the muscle
force on the yoke.
I'm still not entirely certain that I understand.
Alex Perry writes:
The position of the elevator is a force balance, consisting of the
aero force on the elevator, the aero force on the tab and the muscle
force on the yoke.
I'm still not entirely certain that I understand. I know that you
don't think in terms of absolute yoke
I've been wondering for a while - suppose I take a non-force
feedback yoke, and attach a wheel that actually moved the neutral
position by moving the end points of both springs backwards or
forwards, and use this instead of the software trim, would this be a
reasonably realistic
On Tue, 26 Feb 2002 12:29:35 -0500,
David Megginson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Alex Perry writes:
The position of the elevator is a force balance, consisting of the
aero force on the elevator, the aero force on the tab and the
muscle force on the yoke.
On Tue, 26 Feb 2002 18:51:05 +0100,
Arnt Karlsen [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
..the PA 28/Piper Cherokee family use an all moving elevator,
with an anti-servo tab, to _add_ stick forces for pilot feedback.
This tab also serve as a trim tab.
..the Piper Cubs use a
Alex Perry writes:
I'm still not entirely certain that I understand. I know that you
don't think in terms of absolute yoke position when you're flying, any
more than I think in terms of absolute steering-wheel or gas-pedal
position when I'm driving, but perhaps you can verify that
And just for fun, here's an elevator trim tab that's been ripped off at
the Reno air races (looks like a modified P-51D):
I read an article about this one: 3500 HP and Vmax of approx. mach 0.82
Not bad for a propeller driven plane,
Martin.
--
Unix _IS_ user friendly - it's just
Alex Perry wrote:
David Megginson wrote:
I've been wondering for a while - suppose I take a non-force
feedback yoke, and attach a wheel that actually moved the neutral
position by moving the end points of both springs backwards or
forwards, and use this instead of the software trim,
Andy Ross writes:
And on that subject, would you like to pick a property tree for the
FDM output properties? How about /control-positions? Adding this
support to YASim will be quick.
Currently, JSBSim uses an /fdm subtree to report some information, and
/engine subtree, and a /gear
At 2/26/02, you wrote:
Almost all of the major moving surfaces in the C172 are now animated:
snip...
Sounds really neat.
Does all this animation work w/ the LaRCsim and UIUC code? I have a
feeling 'yes', but we're still running 0.7.8.
Regards,
Michael
These are the output names you may find in the current MDL loader:
rudder, elevator, ailerons, flaps, gear, spoilers,
propeller
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Michael Selig writes:
Does all this animation work w/ the LaRCsim and UIUC code? I have a
feeling 'yes', but we're still running 0.7.8.
Yes, it should. Some of it might stop working, though, when we switch
to reading positions from the FDMs themselves rather than the control
inputs.
Wolfram Kuss writes:
These are the output names you may find in the current MDL loader:
rudder, elevator, ailerons, flaps, gear, spoilers,
propeller
Cool. It should not be hard for someone to write XML wrappers for the
current MDL models to animate them -- just a matter of getting the
David Megginson writes:
Michael Selig writes:
Does all this animation work w/ the LaRCsim and UIUC code? I have a
feeling 'yes', but we're still running 0.7.8.
Yes, it should. Some of it might stop working, though, when we switch
to reading positions from the FDMs themselves
On Tue, 2002-02-26 at 10:29, David Megginson wrote:
Andy Ross writes:
And on that subject, would you like to pick a property tree for the
FDM output properties? How about /control-positions? Adding this
support to YASim will be quick.
Currently, JSBSim uses an /fdm subtree to
Tony Peden writes:
Well, what are the chances that both the fdm and the 3D model will need
their own set of properties for these things? If there is little chance
of that then I think we should go with Andy's suggestion and either
eliminate the /fdm tree or save it for special purpose fdm
On Tue, 2002-02-26 at 10:30, Andy Ross wrote:
David Megginson wrote:
... if I hold the yoke in *exactly* the same position and move the
trim wheel, the elevator surface will not move; only the amount of
force required to hold the yoke in position will change. Is that
right?
Yes.
On Tue, 2002-02-26 at 11:27, Curtis L. Olson wrote:
Tony Peden writes:
Well, what are the chances that both the fdm and the 3D model will need
their own set of properties for these things? If there is little chance
of that then I think we should go with Andy's suggestion and either
Does all this animation work w/ the LaRCsim and UIUC code? I have a
feeling 'yes', but we're still running 0.7.8.
Your feeling's right,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Tony Peden writes:
What form would you need the surface positions in? Actual angles are
the easiest thing for JSBSim to output (would those be useful for 3D
models?), but I can see where normalized positions (-1..1) might be
easier to deal with.
I use angles (degrees) in the 3D
Curtis L. Olson writes:
For FDM's that don't do sophisticated control surface position
modeling (or fly-by-wire) we could simply echo back the flightgear
control position (possibly multiplied by a constant to get it into the
desired range.)
That sounds reasonable.
All the best,
On Tuesday 26 February 2002 08:52 am, you wrote:
Almost all of the major moving surfaces in the C172 are now animated:
- propeller
- ailerons
- flaps
- rudder
- elevators
The nosewheel still doesn't turn, but I'll add that when I get a
chance. I'll probably start on the DC-3 first,
On Tue, 26 Feb 2002 09:55:59 -0500, David Megginson
[EMAIL PROTECTED] wrote:
Jon S. Berndt writes:
Excellent. Is there an X-15 model? :-)
Seriously, there probably won't be one from me. My main interest is
civil propeller-driven planes, and after I've fixed up the DC-3 model,
I'll probably
On Tue, 2002-02-26 at 11:58, David Megginson wrote:
Tony Peden writes:
What form would you need the surface positions in? Actual angles are
the easiest thing for JSBSim to output (would those be useful for 3D
models?), but I can see where normalized positions (-1..1) might be
Rick Ansell writes:
Unfortunately I'm not running FGFS ATM as various hardware and
OS shufflings need to take place before it becomes worthwhile
again. When that's done I might even get PPE to generate a
non-zero frame rate!
PPE's an impressive piece of work so far, and is great for
John Check writes:
Awesome! Does gear retraction work?
It can -- I have it sort-of working on my local copy of the DC-3, but
(1) it's instantaneous (since it's using the /controls/gear-down
property), and (2) part of the strut pokes through the top of the
nacelle, so I'll have to split it
Tony Peden writes:
OK, JSBSim now reports control surface positions. I set up the
following properties:
/surface-positions/elevator-pos-deg
/surface-positions/left-aileron-pos-deg
/surface-positions/right-aileron-pos-deg
/surface-positions/rudder-pos-deg
Andy Ross writes:
Hrm... I'm not liking the idea of specifying explicit, absolute angles
as the interface here. First off is the problem of configuration --
what are the appropriate angles? If we put them in the property
interface, then both the FDMs and the model need to know. If we
How do I create new animated models?
[]'s
Marcio Shimoda
- Original Message -
From: David Megginson [EMAIL PROTECTED]
To: FlightGear Development [EMAIL PROTECTED]
Sent: Tuesday, February 26, 2002 10:52 AM
Subject: [Flightgear-devel] Animated C172
Almost all of the major moving
Nice addition
No need for an 'expensive' derivation
of the rotation matrix though as you can
straight forwardly write it out all at once
model.hxx
class FGAircraftModel : public FGSubsystem
{
.
struct Animation
{
enum Type {
None,
Spin,
Rotate
On Tue, 2002-02-26 at 19:08, David Megginson wrote:
Andy Ross writes:
Hrm... I'm not liking the idea of specifying explicit, absolute angles
as the interface here. First off is the problem of configuration --
what are the appropriate angles? If we put them in the property
48 matches
Mail list logo
