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
On Wed, 2002-02-27 at 06:52, David Megginson wrote:
> 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
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 different, blurry-disk object once
the RPM hits a certa
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 PROT
David Megginson <[EMAIL PROTECTED]> said:
> 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 -
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 obviou
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 propel
On Tue, 2002-02-26 at 18:53, David Megginson wrote:
> 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-po
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 comm
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
>
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
Marcio Shimoda writes:
> How do I create new animated models?
I'll try to post something useful soon, but in the meantime, take a
look at $FG_ROOT/Aircraft/c172/c172-dpm.xml for an example. The
object names come from the 3D file itself.
All the best,
David
--
David Megginson
[EMAIL PROTE
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] Anim
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
On Tue, 26 Feb 2002 21:50:46 -0500, David Megginson
<[EMAIL PROTECTED]> wrote:
>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
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
> /surface-positions/f
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 int
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
On Tue, 2002-02-26 at 14:54, Andy Ross wrote:
> Tony Peden wrote:
> > 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
Tony Peden wrote:
> 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
> /surface-positions/
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
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
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 f
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,
D
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 mo
> 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 !
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
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?
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: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 sub
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 themselv
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 matt
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.
A
Andy wrote:
>David Megginson wrote:
> > In JSBSim, we're just summing up the trim and elevator and clamping to
> > the elevator range -- I don't know if that's right, but it doesn't
> > seem to bother most people.
>
>That's exactly what YASim does, too.
Yes, Rowan's BoB and MA do the same.
By
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]
http://mail.flightgear.org/mailman/list
At 2/26/02, you wrote:
>Almost all of the major moving surfaces in the C172 are now animated:
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
**
On Tue, 2002-02-26 at 09:51, Arnt Karlsen wrote:
> 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 e
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 any aircraft that is not fly-by-wire*, the con
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
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 softwa
> 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 sel
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
David Megginson wrote:
> In JSBSim, we're just summing up the trim and elevator and clamping to
> the elevator range -- I don't know if that's right, but it doesn't
> seem to bother most people.
That's exactly what YASim does, too. In fact, this is provably OK.
The way pilots (real and auto-)
D Luff writes:
> 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
> reas
Curtis L. Olson writes:
>
> > David Megginson writes:
> >
> > > Yes -- right now the surfaces are tied to /controls/*
>
> 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
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 j
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 t
> 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 appr
> 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 yok
* [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 und
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 an
On Tue, 26 Feb 2002 10:06:59 -0700,
"Hoyt A. Fleming" <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Dave,
>
> The system that you describe is the exact type of system that I
> have in my(full-size) Lancair ES for rudder and aileron trim.
..Hoyt, do we have FG Lancair
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 position
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 trim).
>
> >From the pilot's point of view, I think, the elevator trim tab
> controls the amount of pressure required
: [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
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 of the
> two lengths of the movable pieces of metal. I
> 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 ac
"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
>
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 ch
Curtis L. Olson writes:
> The UIUC folks have a twin otter running so I bet you could grab quite
> a bit of info from their config file.
A little. The model uses linear data (like most UIUC models) and body
axes.
> I haven't looked at pretty-poly lately, but it might not be hard to
> load
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/*
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 reporte
David Megginson writes:
> 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 YASim aero model to go with it)
The
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 bein
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.
>
> Inev
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 YA
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
Excellent. Is there an X-15 model? :-)
Jon
> Almost all of the major moving surfaces in the C172 are now animated:
>
> - propeller
> - ailerons
> - flaps
> - rudder
> - elevators
>
>
> David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
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 backwards
69 matches
Mail list logo
