Andy Ross wrote:
safety lock; even a perfectly threadsafe property system is
susceptible to race conditions.
The point, again: *all* multithreaded code is susceptible to race
conditions and deadlocks. There is *no* way around this. The only
way to avoid them is to be very, very careful
Hoyt A. Fleming wrote:
I am attempting to compile (version 2.4.2-32) MetaKit, which is
included in (version 0.0.17) Simgear. (I am utilizing cygwin to create
binaries on a PC.) The ../unix/configure command appears to work fine.
However, the make command creates the following error
John Wojnaroski writes:
On Jan 19 the FGEngInterface and FGGearInterface were removed from
the flight.hxx source. It broke a lot of code in the opengc
interface as well as internal logic to modulate the display
symbols.
Is the OpenGC interface in the FlightGear code base, or separate?
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
Erik,
Thanks for the help! I configured MetaKit with the --without-tcl option
and received the following error:
Hoyt A. Fleming@HOYT'S_DESKTOP /usr/local/source/simgear/metakit/builds
$ ../unix/configure --without-tcl
checking for Python configuration... not enabled
checking for Tcl
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,
I've built
ftp://ftp.uni-duisburg.de/FlightGear/Aircraft/marchetti-uiuc-set.xml
Fortunately this is really simple. But it does not recognize the
position
altitude-ft1500/altitude-ft
/position
statement. Wht I start at KSFO i'm still sitting on the ground. Anything
wrong out there ?
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
Martin Spott writes:
Fortunately this is really simple. But it does not recognize the
position
altitude-ft1500/altitude-ft
/position
JSBSim has an on-ground trimming routine. Try also setting the
velocity to non-zero.
All the best,
David
--
David Megginson
[EMAIL
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
Compilation stops with: JSBSim.cpp file not found.
File is JSBSim.cxx
Rainer
begin:vcard
n:Emrich;Rainer
tel;fax:+49 6142 827249
tel;work:+49 6142 827212
x-mozilla-html:FALSE
org:TECOSIM GmbH
adr:;;Im Eichsfeld 3;Ruesselsheim;;65428;Germany
version:2.1
email;internet:[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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of D Luff
Sent: Tuesday, February 26, 2002 9:53 AM
To:
Compilation stops with: JSBSim.cpp file not found.
File is JSBSim.cxx
Rainer
No, there is a file called JSBSim.cxx that is used by FlightGear. The file
JSBSim.cpp is used only to test JSBSim in a standalone mode. This file has
recently been removed from the FlightGear tree. Try updating
JSBSim has an on-ground trimming routine. Try also setting the
velocity to non-zero.
The file I put on the ftp server is called marchetti-uiuc-set.xml and looks
like this:
?xml version=1.0?
!--
UIUC Marchetti S.211 init
Rainer Emrich writes:
Compilation stops with: JSBSim.cpp file not found.
File is JSBSim.cxx
There is some weird default make behavior getting triggered some how.
in src/FDM/JSBSim, remove the entire .deps subdirectory. Then do a
make clean down there, and that should help.
Regards,
Curt.
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
John Wojnaroski writes:
Excuse me, but if you go back you will see that I allowed to the
fact that I was unclear on the idea of the properties, but was
willing to give it a go.
I cannot find that message or my replies to it through Google, but it
may have missed indexing some archived
Rainer Emrich writes:
Compilation stops with: JSBSim.cpp file not found.
I had the same problem. You have to remove src/FDM/JSBSim/.deps then
recompile (yes, it took me an hour to figure that out).
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
I like the consept of multiple programs (communicating through sockets
or pipes) over threading anyhow, and that *forces* you to think about
it :-)
You are right about the example you gave, the pth packages only
removes the multiple r/w operations on the same value at the same
time (which might
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,
John Wojnaroski [EMAIL PROTECTED] said:
Excuse me, but if you go back you will see that I allowed to the fact that I
was unclear on the idea
of the properties, but was willing to give it a go. If this is truely an
open source project then other
ideas and opinions need to be honored, not
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]
What do you suggest that I do to the models on my homepage?
Is it somehow possible to create a model that works with the old and
the new FGFS version?
I fear you will tell me to use XML instead of Python?
Maybe use both and generate a XML on the fly by Python? Can I easily
find out what version
Hi,
I've just seen an article that mentioned Valgrind, a program that checks
for memory access and corruption:
http://devel-home.kde.org/~sewardj/
From the homepage it look easy enough to run. Can someone with Linux
give it a try?
CU,
Christian
--
The idea is to die young as late as
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 !
David wrote:
Wolfram Kuss writes:
What do you suggest that I do to the models on my homepage?
If I recall correctly, the models on your page are already oriented
correctly; if so, then they should continue to work fine. You don't
need to write any XML unless you need to reorient or animate
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,
Wolfram Kuss writes:
The Python script sets these parameters:
/sim/model/path
/sim/model/r-rotation
/sim/model/z-offset
The last two changed quite a few months ago, to z-offset-meters and
pitch|roll|heading-offset-deg. They will be that way in 0.7.9, at
least.
All the best,
David
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
I'm in a bit of a quandary here.
I know the preferred method of supplying data to properties is by
binding or tying the properties to C++ methods. In order to do this
with JSBSim, however, I need to do one of two things:
1) bind the properties in the JSBSim classes themselves. This is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 25, 2002 at 05:07:16PM -0800, Andy Ross wrote:
No, it's not. Imagine what happens when one thread is reading it
while another thread is writing to it. :-)
You missed my point. First, the Vector class *is* threadsafe; check
all
The new model animation is very cool so far.
One thing I did notice is that there seems to be significantly greater CPU
overhead when running these models as opposed to some of the msfs models I've
tried. When taking off in chase view there's a great deal of interuption in
the sound. Also and
Jim Wilson wrote:
Also noticed the rudder control seems to be broken on the dc3 at the
moment.
Blame David. :)
The DC-3 is a taildragger, and therefore doesn't have a steerable
wheel to turn with. Instead, real aircraft use differential braking
to do this.
The problem is, typical control
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
Tony Peden writes:
I know the preferred method of supplying data to properties is by
binding or tying the properties to C++ methods.
Actually, I've come to the conclusion that it's best just to leave
them in the property tree whenever possible, and to bind only where
necessary. A lot of
Go here:
http://sicuroengineering.com/
Click on Technology and Tools
Look for two familiar tools in their stable of simulation utilities.
Jon
--
Jon S. Berndt
Coordinator
JSBSim Project
http://jsbsim.sourceforge.net
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
Jim Wilson writes:
One thing I did notice is that there seems to be significantly
greater CPU overhead when running these models as opposed to some
of the msfs models I've tried. When taking off in chase view
there's a great deal of interuption in the sound.
I notice more interruptions
Andy Ross writes:
The problem is, typical control setups don't have toe brakes on the
rudder pedals. So I cheated in the initial configuration and mapped
the outer (+/- 0.5-1.0) range of the rudder pedals to the brakes. I
thought this was nifty and clever, but David (who spends a lot
On Tuesday 26 February 2002 10:14 pm, you wrote:
Jim Wilson writes:
One thing I did notice is that there seems to be significantly
greater CPU overhead when running these models as opposed to some
of the msfs models I've tried. When taking off in chase view
there's a great deal of
On Tuesday 26 February 2002 10:16 pm, you wrote:
Andy Ross writes:
The problem is, typical control setups don't have toe brakes on the
rudder pedals. So I cheated in the initial configuration and mapped
the outer (+/- 0.5-1.0) range of the rudder pedals to the brakes. I
thought
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
John Check [EMAIL PROTECTED] said:
I noticed that sometimes the dc3 will get into a rotation on the ground
sometimes, especially after a reset. Maybe this is what he is seeing.
TTYL
J
Yep. It does. Applying both brakes seems to stop it. The rudder to brakes
binding doesn't seem to work
Wow, good stuff. Skimming through to apply my own intuition:
6.99% ssgEntity::cull_test
5.28% ssgBranch::cull
4.85% ssgVtxTable::draw_geometry
3.42% FGHitList::IntersectLeaf
3.28% FGHitList::IntersectBranch
2.85% ssgVtxTable::getNumVertices
2.71% sgFrustum::contains
1.85% sgdPointInTriangle
I spent most of today working on a virtual cockpit interface for the
panel, and I'll be damned, it works!
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply
74 matches
Mail list logo
