Re: [Flightgear-devel] Sopwith Camel model added
You've been busy this weekend, it's always nice to see the range of aircraft increasing. I'm still on my way to making the CVS work (I'm very busy here), when I do it'll be great to have a go with all these aircraft. If I'm lucky I might get something done on the spitfire model today... Chris On Sun, 2002-11-10 at 04:42, Michael Selig wrote: I have just added a Sopwith Camel to the CVS. Not only does it include the flight dynamics model, but also there's an external model from A.F. Scrub! He has granted permission for us to use and release these with FlightGear under the GNU GPL. There's a readme file on the external model from A.F. Scrub in: ~/fgfsbase/Aircraft/sopwithCamel/Models/uiuc/sopwithCamel/ The flight model readme from ~/fgfsbase/Aircraft/UIUC/ is included below. I've included a blurb about the initial motivation for this model as it relates some work for the Discovery Channel. Regards, Michael == = Sopwith Camel F.1 = = WWI Fighter= = for FlightGear with LaRCsim and the UIUC Aeromodel = == = Flight model by: = = Michael Selig, et al. ([EMAIL PROTECTED]) = = http://www.aae.uiuc.edu/m-selig/apasim.html= == = External model by: = = A.F.Scrub Scrubby PC ([EMAIL PROTECTED]) = == To run, try: fgfs --aircraft=sopwithCamel-v1-nl-uiuc Files and directory structure required in $FG_ROOT/Aircraft/ to fly the model: sopwithCamel-v1-nl-uiuc-set.xml sopwithCamel/Models/uiuc/sopwithCamel/cambelg0.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg1.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg2.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg3.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg4.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg5.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg6.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg7.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg8.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg9.bmp sopwithCamel/Models/uiuc/sopwithCamel/Sop-panel.bmp sopwithCamel/Models/uiuc/sopwithCamel/camel.txt sopwithCamel/Models/uiuc/sopwithCamel/cambelg.mdl sopwithCamel/Models/uiuc/sopwithCamel/sopwithCamel-model.xml sopwithCamel/Sounds/uiuc/sopwithCamel-sound.xml UIUC/sopwithCamel-v1-nl/aircraft.dat UIUC/sopwithCamel-v1-nl/CDfa-06.dat UIUC/sopwithCamel-v1-nl/CLfa-06.dat UIUC/sopwithCamel-v1-nl/Cmfa-06.dat UIUC/sopwithCamel-v1-nl/Cmfade-03.dat UIUC/sopwithCamel-v1-nl/README.sopwithCamel.html These files above come with the FlightGear base package. ~~ Model description and updates: 11/9/2002 - First release: v1-nl * Motivation: FGFS and the UIUC aero model were used to develop the flight model of both the Sopwith Camel and Fokker Dr.1 Triplane. These models were then used in another simulation with a collaborator, Brian Fuesz. In that simulation, guns, terrain, villages, multiple planes, etc were added to simulate the last flight of the Red Baron. This work was filmed for the Discovery Channel show Unsolved History: The Death of the Red Baron scheduled to first air Dec 18, 2002. * A.F. Scrub ([EMAIL PROTECTED]) has granted FlightGear permission to use and release the external model files with FlightGear under the GNU GPL. * A weights and balance was performed to arrive at an allowable c.g. location and from that data, mass moments of inertia were calculated. * Lift, drag and pitching moment data is modeled from -180 to +180 deg. In general, the aerodynamics are modeled using various sources. * Apparent mass effects are modeled. * Gyroscopic forces caused by engine rotation and aircraft rotations are modeled. For an animation of how a WWI-type rotary engine works, go here: http://www.keveney.com/gnome.html An example of gyroscopic forces, are those forces produced when one tries to rotate by hand a spinning bicycle wheel. * Spin aerodynamics are not yet modeled. * The simulation starts on the ground. Throttle up to take off or alternatively, use Ctrl-U to jump up in 1000-ft increments. * Interesting flight characteristics to note: - The Sopwith Camel was considered a beast to fly. It killed 385 pilots while they were in training (non-combat). In combat, 415 of the surviving pilots were killed while flying the Sopwith Camel. Approximately 5000 Sopwith Camels were built, and it is believed that collectively 1294 enemy aircraft were destroyed. - In large part, the challenges to flying the Sopwith Camel involve the
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
Julian Foad writes: Well, I suppose it needs someone to show how the two aims can be compatible. But it's not easy; it would require becoming familiar with both implementations and re-arranging the interfaces a bit. While that's the sort of thing I do at work, I'm not yet in a position to do it here. We can already override parts of JSBSim's internal implementation (such as its weather model). There's no reason we couldn't rig up JSBSim and YASim to take engine parameters from properties as well. The engine model needs basic information like fuel available, outside air temperature and humidity, static and dynamic pressure, etc., all of which are accessible from outside the FDMs. It would have to feed back fuel and oil consumption, location and direction of thrust, amount of thrust, and information about gyroscopic effects. 3. The engine revs up and slows down very slowly. For example, when I cut the magnetos from 2000 RPM it takes over a minute to run down and stop. At a certain point, friction should take over. I added a kludge in JSBSim to make that happen. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Sopwith Camel model added
Michael Selig writes: I have just added a Sopwith Camel to the CVS. Not only does it include the flight dynamics model, but also there's an external model from A.F. Scrub! He has granted permission for us to use and release these with FlightGear under the GNU GPL. There's a readme file on the external model from A.F. Scrub in: ~/fgfsbase/Aircraft/sopwithCamel/Models/uiuc/sopwithCamel/ Thank you very much. It might be a good idea in the future to put 3D models directly into Aircraft/*/Models/ rather than Aircraft/*/Models/uiuc/, since 3D models are usable by all FDMs (all four major ones use the same C172 model, for example). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
Andy Ross writes: I'd *love* to see good numbers for propeller acceleration, however. If one of the Real Pilots out there could go out with a stopwatch and get us graphs of RPM vs. time for full throttle acceleration and cut-power deceleration I'd be eternally grateful. :) I don't want to get banned from the flying club (or demonstrate my limited forced-landing skills), so I'm not going to abuse the engines by jamming the throttle in hard to full from idle and timing it. Here are some unofficial observations, however, from various 172's: 1. The prop accelerates and decelerates very quickly. You're supposed to move the throttle smoothly so that the changes don't happen too quickly. 2. During runup, I push the throttle in from 1000RPM to 1700RPM -- the lag between throttle movement and tach indication is barely perceptable (under 0.25 sec). 3. Next, I pull the throttle from 1700RPM to idle. The drop on the tach from 1700RPM to about 600RPM is nearly instantaneous (again, under 0.25sec). 4. At shutdown, I set the engine to 1000RPM, then pull the mixture to shut it down. The engine continues to fire for a couple of seconds until it burns off all its fuel, but once it stops firing, the propeller stops in well under a second. During takeoff, I have other things to worry about, but I'll guess that the lag between 1000RPM and max static (2200-2400RPM) takes less than 0.5sec, possibly again less than 0.25sec. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
Hi Michael, What a great addition to the fleet! Beautiful 3D model too. Would you or A.F. Scrub mind if I converted that to ac3d? The purpose would be to convert the textures to rgb, alpha the prop disk, animate, and add 3D instrumentation similar to the j3cub (which would involve a few cockpit geometry adjustments). This might be a few weeks away, but thought I'd ask. Best, Jim Michael Selig [EMAIL PROTECTED] said: I have just added a Sopwith Camel to the CVS. Not only does it include the flight dynamics model, but also there's an external model from A.F. Scrub! He has granted permission for us to use and release these with FlightGear under the GNU GPL. There's a readme file on the external model from A.F. Scrub in: ~/fgfsbase/Aircraft/sopwithCamel/Models/uiuc/sopwithCamel/ The flight model readme from ~/fgfsbase/Aircraft/UIUC/ is included below. I've included a blurb about the initial motivation for this model as it relates some work for the Discovery Channel. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Sopwith Camel model added
David Megginson [EMAIL PROTECTED] said: Thank you very much. It might be a good idea in the future to put 3D models directly into Aircraft/*/Models/ rather than Aircraft/*/Models/uiuc/, since 3D models are usable by all FDMs (all four major ones use the same C172 model, for example). Agreed, there need not be a one to one relationship between fdm models and 3D models and the path implies there is. If there are differences in fdm data output that require multiple 3Dmodel xml files for animation, they can still be named according to the fdm they work with and still live in the same directory as a single mdl or ac file and texture set. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim origin and model offsets
Andy Ross wrote:
Jim Wilson wrote:
Anyway, what I now remember is this: the camera position as configured
for the chase view is always in relation to the FDM location. And in
the case of Yasim that location is always the nose.
Oh, good point. This will create problems for view direction too --
the viewer will expect to rotate around the center of the aircraft
instead of the nose.
But there are other places in the code that make assumptions about the
location of the aircraft, too, and they have different requirements.
...
Or consider an ILS receiver, which really wants to use the location of
the antenna on the 747, not the cockpit, c.g., or center. (I have no
idea where this is, but I suspect it's closer to the tail, so that the
main gear are what travel down the exact glidepath). Maybe we need
separate origin offsets for all of these applications?
For some of them, definitely. The viewer (eye, camera) position for
internal view must be quite precisely positioned, not just at the centre
of the airframe. Also the altitude (AGL) of the wings for modeling
ground effect. Many other things (measuring altitude for display,
position relative to radio beacons, etc.) would be fine using any origin
that is within the airframe.
Actually, wouldn't a sane default for the view code be to *always*
pick a center point for the offset? That is, just pick the center of
a bounding box computed from the model (or the FDM). This will match
more closely to what the user expects in all cases I can think of.
That would be suitable for the external views. The centre of gravity
would also be fine. Use whichever is more conveniently available; there
are already enough origins to choose from so don't calculate another
unless it is necessary.
It seems clear what ought to be done. Whenever a point on the aircraft
is used for some calculation, it should specify exactly what point is
required. The apparent obstacles to doing this are:
+ the required information is not available
+ concern about the run-time cost of additional calculation
+ the effort of thinking about what is required and implementing it
These can be tackled separately. For the first point, write stubs for
the missing information so that it can be easily added later. Instead
of this:
// Calc additional lift due to ground effect.
// Not sure exactly what FDM-getLocation() is supposed to return but it
// is about 1.2m below the C172's wings.
// Need to generalise this for other aircraft.
lift += calcGroundEffect(getTAS(), FDM-getLocation().height + 1.2);
write this:
// Calc additional lift due to ground effect.
lift += calcGroundEffect(getTAS(), getCentreOfLift().height);
Search for other bits of code that might already need the same
information. If there are none, make a stub function at the top of the
file (or somewhere more appropriate if you can):
// Stubs for missing information
vec3 getCentreOfLift() { return FDM-getLocationEmptyCofG() + 1.2 /*
this is for C172 */; }
If there are already one or more uses, share the function.
For the second point, consider the run-time cost it in context. If it
is expensive and the exact position is unimportant, make the stub do
nothing, with a comment saying why.
Surely each aircraft geometry definition should be obliged to specify
the position of the things we are interested in:
+ eye position of an average pilot (for internal view)
+ centre of lift (for ground effect)
+ nose, tail, wing tips (for crash detection, and for placing the model
not overhanging the end of a runway)
+ landing gear when fully extended, and its compression behaviour (for
ground handling)
+ centre of gravity when empty, and location of variable masses (fuel,
people, baggage)
The definition file would specify these things relative to its own
origin. If we cannot or do not wish to require all of these to be
specified, the Flight Gear class that reads the model definitions could
be made to guess reasonable values for the ones that are missing.
These statically specified offsets are all constant relative to the
rigid airframe. At run time, we can provide variable ones as well:
class AircraftGeometry {
// Get location of various points as an offset relative to some
arbitrary origin.
// User doesn't need to know what the arbitrary origin is; only
differences between
// these offsets are meaningful.
vec3 getOffsetPilotEye(); // constant
vec3 getOffsetCentreOfLift(); // constant in simple models; may be
variable
vec3 getOffsetNoseTip(); // constant
vec3 getOffsetLeft/RightWing/Tail/etc.();
vec3 getOffsetNoseGearExtended(); // constant
vec3 getOffsetNoseGearCurrent(); // variable
vec3 getOffsetEmptyCentreOfGravity(); // constant
vec3 getOffsetCurrentCentreOfGravity(); // variable
// and/or
vec3 getOffsetContactPoint(int n);
vec3 getOffsetVariableLoad(int n);
float getMassOfVariableLoad(int n);
// etc. as required.
}
Actually,
re: [Flightgear-devel] Sopwith Camel model added
At 11/10/02, Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: Thank you very much. It might be a good idea in the future to put 3D models directly into Aircraft/*/Models/ rather than Aircraft/*/Models/uiuc/, since 3D models are usable by all FDMs (all four major ones use the same C172 model, for example). Agreed, there need not be a one to one relationship between fdm models and 3D models and the path implies there is. If there are differences in fdm data output that require multiple 3Dmodel xml files for animation, they can still be named according to the fdm they work with and still live in the same directory as a single mdl or ac file and texture set. Best, Jim Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. We don't keep on the cvs legacy code as we develop it, but it might make sense to keep working legacy models when they are native to MSFS with their associated credits. If this does make sense, I am not attached to the uiuc dir name. We could call it OEM, orig, the author's name or something like that. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
At 11/10/02, Jim Wilson wrote: Hi Michael, What a great addition to the fleet! Beautiful 3D model too. Would you or A.F. Scrub mind if I converted that to ac3d? The purpose would be to convert the textures to rgb, alpha the prop disk, animate, and add 3D instrumentation similar to the j3cub (which would involve a few cockpit geometry adjustments). This might be a few weeks away, but thought I'd ask. Best, Jim I'd be thrilled to see what you could do to improve the 3D model. I'll check w/ AF Scrub. Regards, Michael Michael Selig [EMAIL PROTECTED] said: I have just added a Sopwith Camel to the CVS. Not only does it include the flight dynamics model, but also there's an external model from A.F. Scrub! He has granted permission for us to use and release these with FlightGear under the GNU GPL. There's a readme file on the external model from A.F. Scrub in: ~/fgfsbase/Aircraft/sopwithCamel/Models/uiuc/sopwithCamel/ The flight model readme from ~/fgfsbase/Aircraft/UIUC/ is included below. I've included a blurb about the initial motivation for this model as it relates some work for the Discovery Channel. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Sopwith Camel model added
Michael Selig writes: Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. I would think that the author already would provide an original reference version, i.e. the one that works with MSFS. If we have to make slight modications to get the model to work with FGFS then why not go whole hog and spruce it up a little while we are at it... assuming we have the author's permission to do so. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Sopwith Camel model added
At 11/10/02, Curt Olson wrote: Michael Selig writes: Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. I would think that the author already would provide an original reference version, i.e. the one that works with MSFS. If we have to make slight modications to get the model to work with FGFS then why not go whole hog and spruce it up a little while we are at it... assuming we have the author's permission to do so. Ok, this makes sense. The OEM resides w/ the working package for MSFS and people can always get that from, say, http://www.flightsim.com. We will only keep those parts (original or otherwise) that are currently working w/ the latest version of FGFS. In the future for the new aircraft that I add, I'll just put the models in the ~/Aircraft/*/Models. Regards, Michael Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SimGear patches for GCC 3.2: memrchr and typename
I had to remove a declaration of memrchr from simgear/metar/Local.h to
compile under gcc 3.2 (SuSE Linux 8.1). There are lots of semi-standard
functions declared there that probably shouldn't be.
To fix some warnings I added typename into some typedef lines. I am
not sure about the correctness or the portability of these - especially
the typename additions. Can anyone evaluate these?
These were the errors:
c++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../..
-I/usr/X11R6/include -O1 -finline-limit-256 -finline-functions -Wall
-pedantic -Wpointer-arith -D_REENTRANT -c -o Charcmp.o `test -f
'Charcmp.cpp' || echo './'`Charcmp.cpp
In file included from Charcmp.cpp:1:
Local.h:1118: declaration of `void* memrchr(const void*, int, unsigned
int)' throws different exceptions
/usr/include/string.h:72: than previous declaration `void* memrchr(const
void*, int, unsigned int) throw ()'
and warnings:
SkyBVTree.hpp:217: warning: `typename SkyBaseBVTreeObject,
BoundingVolume::BV' is implicitly a typename
SkyBVTree.hpp:217: warning: implicit typename is deprecated, please see
the documentation for details
(etc.)
- Julian
Index: simgear/metar/Local.h
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/metar/Local.h,v
retrieving revision 1.1.1.1
diff -u -3 -p -d -r1.1.1.1 Local.h
--- simgear/metar/Local.h 7 Sep 2002 02:58:19 - 1.1.1.1
+++ simgear/metar/Local.h 10 Nov 2002 19:28:47 -
-1115,7 +1115,7 int stregion(int);
int ccregion(char *);
char *rgnname(int);
-void *memrchr(const void *, int, size_t);
+//void *memrchr(const void *, int, size_t);
bool sysmonms(char *, char *, ...);
bool sysmoncl(char *);
Index: simgear/sky/clouds3d/SkyBVTree.hpp
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/sky/clouds3d/SkyBVTree.hpp,v
retrieving revision 1.2
diff -u -3 -p -d -r1.2 SkyBVTree.hpp
--- simgear/sky/clouds3d/SkyBVTree.hpp 14 Sep 2002 16:03:39 - 1.2
+++ simgear/sky/clouds3d/SkyBVTree.hpp 10 Nov 2002 19:28:49 -
-214,9 +214,9 class SkyBVTree : public SkyBaseBVTreeO
{
public:
typedef SkyBaseBVTreeObject, BoundingVolume BaseTree;
- typedef BaseTree::BV BV;
- typedef BaseTree::NodeObject NodeObject;
- typedef BaseTree::Node Node;
+ typedef typename BaseTree::BV BV;
+ typedef typename BaseTree::NodeObject NodeObject;
+ typedef typename BaseTree::Node Node;
void Clear()
{
Index: simgear/sky/clouds3d/SkyBVTreeSplitter.hpp
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/sky/clouds3d/SkyBVTreeSplitter.hpp,v
retrieving revision 1.2
diff -u -3 -p -d -r1.2 SkyBVTreeSplitter.hpp
--- simgear/sky/clouds3d/SkyBVTreeSplitter.hpp 14 Sep 2002 16:03:39 - 1.2
+++ simgear/sky/clouds3d/SkyBVTreeSplitter.hpp 10 Nov 2002 19:28:50 -
-52,7 +52,7 templateclass Object
class SkyBoundingBoxSplitter
{
public:
- typedef SkyBaseBVTreeObject, SkyMinMaxBox::NodeObject NodeObjectBox;
+ typedef typename SkyBaseBVTreeObject, SkyMinMaxBox::NodeObject NodeObjectBox;
//typedef SkyBaseBVTreeObject, SkyBoundingSphere::NodeObject
NodeObjectSphere;
#if _MSC_VER == 1200
-183,7 +183,7 class SkyAABBTreeSplitter
{
public:
typedef SkyMinMaxBox BV;
- typedef SkyBaseBVTreeObject, BV::NodeObject NodeObject;
+ typedef typename SkyBaseBVTreeObject, BV::NodeObject NodeObject;
SkyAABBTreeSplitter(const NodeObject* pObjs, unsigned int iNumObjs) :
_splitter(pObjs, iNumObjs) {}
Re: [Flightgear-devel] Sopwith Camel model added
On Sunday 10 November 2002 2:21 pm, Michael Selig wrote: At 11/10/02, Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: Thank you very much. It might be a good idea in the future to put 3D models directly into Aircraft/*/Models/ rather than Aircraft/*/Models/uiuc/, since 3D models are usable by all FDMs (all four major ones use the same C172 model, for example). Agreed, there need not be a one to one relationship between fdm models and 3D models and the path implies there is. If there are differences in fdm data output that require multiple 3Dmodel xml files for animation, they can still be named according to the fdm they work with and still live in the same directory as a single mdl or ac file and texture set. Best, Jim Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their I vote no. We can archive 'em someplace, but why should we use the extra bandwidth distributing something thats not used? original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. We don't keep on the cvs legacy code as we develop it, but it might make sense to keep working legacy models when they are native to MSFS with their associated credits. If this does make sense, I am not attached to the uiuc dir name. We could call it OEM, orig, the author's name or something like that. I understand where you are coming from, wanting to keep all uiuc enchancements segregated, but graphic and cosmetic stuff really should be consistently stored project wide. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
On Sunday 10 November 2002 2:37 pm, Michael Selig wrote: At 11/10/02, Curt Olson wrote: Michael Selig writes: Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. I would think that the author already would provide an original reference version, i.e. the one that works with MSFS. If we have to make slight modications to get the model to work with FGFS then why not go whole hog and spruce it up a little while we are at it... assuming we have the author's permission to do so. Ok, this makes sense. The OEM resides w/ the working package for MSFS and people can always get that from, say, http://www.flightsim.com. We will only keep those parts (original or otherwise) that are currently working w/ the latest version of FGFS. Right. I'd put a download URL for the original in the README. In the future for the new aircraft that I add, I'll just put the models in the ~/Aircraft/*/Models. Sweet. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
On Sunday 10 November 2002 2:24 pm, Curtis L. Olson wrote: Michael Selig writes: Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. I would think that the author already would provide an original reference version, i.e. the one that works with MSFS. If we have to make slight modications to get the model to work with FGFS then why not go whole hog and spruce it up a little while we are at it... assuming we have the author's permission to do so. Curt, How about putting something on the main site about the situation regarding MSFS models? This way anybody from that community will be aware if/when they check out the FGFS pages. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
At 11/10/02, John Check wrote: On Sunday 10 November 2002 2:21 pm, Michael Selig wrote: At 11/10/02, Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: Thank you very much. It might be a good idea in the future to put 3D models directly into Aircraft/*/Models/ rather than Aircraft/*/Models/uiuc/, since 3D models are usable by all FDMs (all four major ones use the same C172 model, for example). Agreed, there need not be a one to one relationship between fdm models and 3D models and the path implies there is. If there are differences in fdm data output that require multiple 3Dmodel xml files for animation, they can still be named according to the fdm they work with and still live in the same directory as a single mdl or ac file and texture set. Best, Jim Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their I vote no. We can archive 'em someplace, but why should we use the extra bandwidth distributing something thats not used? original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. We don't keep on the cvs legacy code as we develop it, but it might make sense to keep working legacy models when they are native to MSFS with their associated credits. If this does make sense, I am not attached to the uiuc dir name. We could call it OEM, orig, the author's name or something like that. I understand where you are coming from, wanting to keep all uiuc enchancements segregated, but graphic and cosmetic stuff really should be consistently stored project wide. All sounds good to me: no legacy dir, and no uiuc model dir. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
At 11/10/02, you wrote: On Sunday 10 November 2002 2:37 pm, Michael Selig wrote: At 11/10/02, Curt Olson wrote: Michael Selig writes: Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. I would think that the author already would provide an original reference version, i.e. the one that works with MSFS. If we have to make slight modications to get the model to work with FGFS then why not go whole hog and spruce it up a little while we are at it... assuming we have the author's permission to do so. Ok, this makes sense. The OEM resides w/ the working package for MSFS and people can always get that from, say, http://www.flightsim.com. We will only keep those parts (original or otherwise) that are currently working w/ the latest version of FGFS. Right. I'd put a download URL for the original in the README. That's been done (using a URL and/or email address). These model README files are in the ~/Aircraft/*/Model/uiuc dir. Regards, Michael In the future for the new aircraft that I add, I'll just put the models in the ~/Aircraft/*/Models. Sweet. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
At 11/10/02, John Check wrote: On Sunday 10 November 2002 2:24 pm, Curtis L. Olson wrote: Michael Selig writes: Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. I would think that the author already would provide an original reference version, i.e. the one that works with MSFS. If we have to make slight modications to get the model to work with FGFS then why not go whole hog and spruce it up a little while we are at it... assuming we have the author's permission to do so. If we -don't- have permission, then it's an incompatible license. It should be made clear when getting permission that modifications are likely to be made. We have a compatible license. I was very careful to explain that my request was to get permission to use their models under the GNU GPL. The related email correspondence on this is in the ~/Aircraft/*/Models/uiuc dir (uiuc to be obsolete). While I cannot speak for Curt, my interpretation assuming we have the author's permission to do so is out of courtesy to the creator. So these are GNU GPL models plain and simple. (Unfortunately, I was not able to secure a GPL model for the Fokker triplane model, which I hope to post sometime today.) Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Keyboard braking power
It seems silly to have the brake key slam on full braking power, if it is to be used on the runway. No wonder the aircraft tend to tip over or burst their tyres. Can I recommend this patch which sets the all brakes strength to 0.5 and the individual left/right to 0.7? Personally I do the same for my joystick configuration, but since we've got so many joystick config files, we really need to separate the joystick configurations from the commands that they control in order to be able to change things like this consistently. - Julian Index: keyboard.xml === RCS file: /home/cvsroot/FlightGear/FlightGear/keyboard.xml,v retrieving revision 1.37 diff -u -3 -p -d -r1.37 keyboard.xml --- keyboard.xml2002/11/07 16:30:39 1.37 +++ keyboard.xml2002/11/10 04:29:52 -276,7 +276,7 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[0]/property - value type=double1.0/value + value type=double0.7/value /binding mod-up binding -303,7 +303,7 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[1]/property - value type=double1.0/value + value type=double0.7/value /binding mod-up binding -678,17 +678,17 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[0]/property - value type=double1.0/value + value type=double0.5/value /binding binding commandproperty-assign/command property/controls/brakes[1]/property - value type=double1.0/value + value type=double0.5/value /binding binding commandproperty-assign/command property/controls/brakes[2]/property - value type=double1.0/value + value type=double0.5/value /binding mod-up descRelease all brakes./desc
Re: [Flightgear-devel] Sopwith Camel model added
At 11/10/02, John Check wrote: On Sunday 10 November 2002 2:24 pm, Curtis L. Olson wrote: Michael Selig writes: Since these are imports courtesy of developers working with MSFS, would it be a good idea to keep a copy of their models in original form in a separate directory? That way they could always come to FGFS and fly their original models as well as any enhancements to them? In each case, the original model developers have expressed some interest in FGFS. I would think that the author already would provide an original reference version, i.e. the one that works with MSFS. If we have to make slight modications to get the model to work with FGFS then why not go whole hog and spruce it up a little while we are at it... assuming we have the author's permission to do so. Curt, How about putting something on the main site about the situation regarding MSFS models? This way anybody from that community will be aware if/when they check out the FGFS pages. At least, these people should be mentioned on the contributor's page: A.F. Scrub (first Camel external model) Roland Stuck (first ASW 20 external model) Regards, Michael TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard braking power
Julian Foad wrote: It seems silly to have the brake key slam on full braking power, if it is to be used on the runway. No wonder the aircraft tend to tip over or burst their tyres. Can I recommend this patch which sets the all brakes strength to 0.5 and the individual left/right to 0.7? This issue came up about a year ago. There really isn't any good resolution. Sometimes you really do want full brakes (short runway landings in the A-4, for example), and sometimes you want to brake gently. And IMHO asymmetric braking is more likely to be gentle, as it's used for steering. The only control input that makes sense for those requirements is an analog axis from a brake pedal. Anything else is basically a hack. My favorite hack, FWIW, was to have the on/off input affect the braking power slowly -- over a second or two. That way you could modulate the brakes yourself by changing the frequency with which you toggled the button. You can try this out right now with YASim, by adding a control-speed tag for the braking inputs. But it's still a hack -- sometimes you want to release the brakes right now, as with short takeoffs. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard braking power
Andy Ross wrote: Julian Foad wrote: It seems silly to have the brake key slam on full braking power, if ... This issue came up about a year ago. There really isn't any good resolution. ... My favorite hack, FWIW, was to have the on/off input affect the braking power slowly -- over a second or two. That way you could ... Yes, you're right. That's quite a nice hack - but I see your point. I'm going through my differences from CVS trying to get rid of them by seeing how many would be wanted in CVS. It looks like this is one local modification that I'll just have to keep or delete. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Radio frequency range: min/max/wrap
I noticed that the radios had nav. freq. range 108.00 to 117.95 but com. freq. 0 to 140; this should be 118 to 140. But while playing with that I noticed that the wrapping is a bit unpredictable. With (min=118, max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips 118 and sometimes skips 140. For the nav. frequencies, my 1991 UK Pooley's Flight Guide confirms that the range is 108.00 to 117.95 inclusive. But the current implementation that specifies (min=108.00, max=117.95, step=0.05, wrap=true) tends to cycle (117.85, 117.90, 108.00, 108.05) skipping 117.95. There is a problem with the way min and max work when wrap is on and discrete steps are being used. Wrap is designed for analogue values to go round in a circle where min and max are regarded as equivalent. On things like our radio frequency controls, it is down to luck (due to floating-point precision) whether (min=118, max=140, step=1) cycles through (139, 140, 119) or (139, 118, 119). Some of the directional instrument controls are specified as (min=0, max=359, wrap=true). These should, I think, all be specified as (min=0, max=360, wrap=true), so that it doesn't skip 359, because in this case the min/max are the end points of an analogue range (not a set of discrete valid values). It doesn't matter whether it reads 360 or 0 for North. So: - Can anyone confirm the min. and max. settable com. frequencies on radios of this general type? I'm fairly convinced now that it must be 118.00 to 139.975 inclusive (or 139.95 on old models with 50 kHz spacing). - Do they wrap from one end of the range to the other? If not, it is easy to model properly. If they do, we need to look more carefully at the way the wrapping handles discrete steps. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality between FDMs
On 11/10/02 at 4:02 AM Julian Foad wrote: As for the guts of how the engines are modelled ... I first worked on the starting and stopping behaviour of the JSBsim engine. The thermodynamic model of the engine is probably very good Parts of it are, parts of it aren't and are overdue a re-visit. but there's lots of yucky stuff there to do with starting etc. I've done some stuff there, and in the sound configuration, but not finished. I'll go into that later. Ah yes, starting, I seem to recall a lot of hacking and kludging to get everything to work :-) There's a number of problems currently: 1/ My assumption of cranking speed at the time (480rpm!!!) was *way* too high. 2/ There's currently no friction modelled, which means there's not enough resistance to a proper starter motor torque at very low rpm when there's no prop resistance (I put a friction model into the LaRCsim IO360.[ch]xx to resist the prop when the engine was switched off in flight but I haven't brought it over to the JSBSim one yet). 3/ Need a proper starter motor torque curve. I did dig one out at one point but never put it in and now I've lost it. I'll have another look. Part of the problem is that I have to make sure that I'm working from publically available data and not anything internal. Have fun :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] C172 Taxiing speed
On 11/7/02 at 4:33 PM David Megginson wrote: lots Thanks. Are major taxiways such as the one parallel to the rwy that normally seems to be called Alpha 2-way or is the traffic normally directed one-way on them by ATC depending on the rwy in use? That would be very airport specific, but note that almost every case ends up being a special case. People are always requesting a different runway, a different taxiway, a different intersection takeoff, etc., and ATC is usually pretty obliging. When I taxi on taxiway alpha at CYOW, there is sometimes a big 767 or Airbus heading straight towards me -- I have an instruction to hold short at delta and the big plane will turn onto the main apron before there, so there's not conflict, but it would look quite frightening to a new passenger. So basically they're 2-way, but sequentially, with planes never passing wing-tip to wing-tip in opposite directions each side of the yellow line? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] brakes
It seems silly to have the brake key slam on full braking power, if it is to be used on the runway. No wonder the aircraft tend to tip over or burst their tyres. Can I recommend this patch which sets the all brakes strength to 0.5 and the individual left/right to 0.7? One option might be to make the braking force a function of speed. This is how we usually use brakes anyway, especially just before stopping. To make a smooth stop in an airplane, or a car for that matter, you have to let up on the brakes as you get slower or the vehicle will lurch to a stop. The braking force could be a constant value above say 10 knots, and taper down to a low value at zero knots. This should get rid of the nose dive. Another option is to have the brake control select a deceleration rate rather than a force. This is how the autobrakes work on a modern airliner. The problem with this is that it ignores the physical model of the airplane and might feel artificial. However, stopping an airplane with a keyboard key is itself artificial so it might not be so bad. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Keyboard braking power
Julian Foad writes: It seems silly to have the brake key slam on full braking power, if it is to be used on the runway. No wonder the aircraft tend to tip over or burst their tyres. Can I recommend this patch which sets the all brakes strength to 0.5 and the individual left/right to 0.7? I used to use a different approach -- instead of slamming the brakes right to 1.0, pressing my joystick buttons (works for keys as well) would repeatedly increase the brakes by a small amount like 0.05, while releasing would immediately reset to 0. You could get a sort of anti-lock brake by pumping the buttons. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] C172 Taxiing speed
David Luff writes: So basically they're 2-way, but sequentially, with planes never passing wing-tip to wing-tip in opposite directions each side of the yellow line? The yellow line is where your nosewheel is supposed to be. That said, little planes pass each other all the time on taxiways -- it's just like a country road, where one plane pulls far over to the side (even onto the gravel) to let the other by. During daylight with good visibility, ground control basically clears us to taxi to a runway and leaves us alone to work out the details. Big planes, of course, have to be more organized and wouldn't have room to pass on the same taxiway (there are also issues with jet blast -- taxiing too close behind an idling 737 could flip your Cessna upside down). Even runways are two-way in the real world -- in light winds, one plane might land on 32 as soon as the previous one turns off from a landing on 14 and just before another takes off on 25 right through the intersection with 14/32. In good VMC during the day, everyone (especially the big transports) takes straight-in if they can get it. In fact, the other night my instructor and I took a (long) runway with a 5kt tailwind to save ten minutes getting home. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
* [EMAIL PROTECTED] (Michael Selig) [2002.11.10 13:21]: At 11/10/02, Jim Wilson wrote: What a great addition to the fleet! Beautiful 3D model too. Would you or A.F. Scrub mind if I converted that to ac3d? The purpose would be to convert the textures to rgb, alpha the prop disk, animate, and add 3D instrumentation similar to the j3cub (which would involve a few cockpit geometry adjustments). This might be a few weeks away, but thought I'd ask. I'd be thrilled to see what you could do to improve the 3D model. I'll check w/ AF Scrub. Interesting. I'm probably blowing this way out of proportion, but I like legal brain teasers. :-) Do we need to get a clarification from AF Scrub what source means? The GPL requires that the source be treated a certain way. In the case of GPLing 3D models, it should be established what source form is. Do any changes we make have to be made available in MSFS format? It would be nice if we had an open model format that we could say, Format XYZ is considered 'source form' for all 3D models. MSFS, 3dsMax, etc are considered 'compiled forms.' And then follow the GPL accordingly, just like we do with the source package. -- Cameron Moore / If a tree falls in the forest and no one is around \ \to see it, do the other trees make fun of it? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fokker Dr.1 model added
I have just added the Fokker Dr.1 triplane to the CVS. There are notes in the readme below about how to get a 3D model file. Unfortunately, I could not acquire one under the GNU GPL. If I were going to be in a dog fight and had my pick of the Camel or Dr.1, the Dr.1 would be the weapon of choice. The Red Baron once said it It climbed like a monkey and maneuvered like the devil. I concur. Regards, Michael pre == = Fokker Dr.1= = WWI Fighter= = for FlightGear with LaRCsim and the UIUC Aeromodel = == = Flight model by: = = Michael Selig, et al. ([EMAIL PROTECTED]) = = http://www.aae.uiuc.edu/m-selig/apasim.html= == To run, try: fgfs --aircraft=fkdr1-v1-nl-uiuc Files and directory structure required in $FG_ROOT/Aircraft/ to fly the model: fkdr1-v1-nl-uiuc-set.xml fkdr1/Sounds/uiuc/fkdr1-sound.xml UIUC/fkdr1-v1-nl/aircraft.dat UIUC/fkdr1-v1-nl/CDfa-03.dat UIUC/fkdr1-v1-nl/CLfa-03.dat UIUC/fkdr1-v1-nl/Cmfa-03.dat UIUC/fkdr1-v1-nl/Cmfade-01.dat These files above come with the FlightGear base package. To add a 3D external model, read the file: ~/Aircraft/UIUC/beech99/README.beech99.html as an example to follow. A Fokker Dr.1 model file that does work is fokdr1m2.zip from http://www.flightsim.com. (The fuselage for this model is too wide in the cockpit region.) There are several variants of this which can also be used, namely these files: dr-1cfs.zip dr1mp98.zip dr1mpcfs.zip fkdr1blk.zip fokdr-15.zip ~~ Model description and updates: 11/10/2002 - First release: v1-nl * Motivation: FGFS and the UIUC aero model were used to develop flight models for both the Sopwith Camel and Fokker Dr.1 Triplane. These models were then used in another simulation with a collaborator, Brian Fuesz. In that simulation, guns, terrain, villages, multiple planes, etc were added to simulate the last flight of the Red Baron. This work was filmed for the Discovery Channel show Unsolved History: The Death of the Red Baron scheduled to first air Dec 18, 2002. * A weights and balance was performed to arrive at an allowable c.g. location and from that data, mass moments of inertia were calculated. * Lift, drag and pitching moment data is modeled from -90 to +90 deg. Because the aerodynamics are not modeled from -180 to +180 deg, the aircraft will sometimes twitch when coming out of a tail slide as it passed through 90 deg. * In general, the aerodynamics are modeled using various sources. * Apparent mass effects are modeled. * Gyroscopic forces caused by engine rotation and aircraft rotations are modeled. For an animation of how a WWI-type rotary engine works, go here:http://www.keveney.com/gnome.html An example of gyroscopic forces, are those forces produced when one tries to rotate by hand a spinning bicycle wheel. * Spin aerodynamics are not yet modeled. * The simulation starts on the ground. Throttle up to take off or alternatively, use Ctrl-U to jump up in 1000-ft increments. * The Fokker Dr.1 did not have brakes. Application of brakes in FGFS will cause the aircraft to promptly nose over. (I have added a fake contact point ahead of the aircraft to avoid completely tipping over.) The c.g. of the aircraft sits almost directly above the wheel contact point. There is a reason for this. The aft fuselage and tail were designed to be very light. Thus, the tail could not support much load, so the weight of the aircraft largely rests on the main wheels, which again requires the c.g. to be almost directly above the wheels. * WWI aircraft engines did not have a conventional throttle (at least most did not). The engines were either on or off/idle using a blip-throttle. So it is not realistic to fly with a variable throttle, which the current model allows. * To modelers, I can provide a graphic showing the c.g. location. * Something I have not yet modeled is rudder ineffectiveness on roll out and touch down. When the aircraft is sitting on the wheels and tail skid, the angle of attack of the wing is so high that it is mostly stalled and the flow off the aft fuselage is also not well behaved. The result is that there is not much dynamic pressure (flow speed) on the vertical stabilizer, so there is little rudder authority in this condition. As a point of interest, why would the designers settle for this result? It's because of the rotary engine. The max speed is limited to 1200 rpm because of the otherwise higher stresses on the rotary engine parts. To obtain the necessary thrust at such a low rpm, a large diameter ~8.5 ft propeller was required. With such a
RE: [Flightgear-devel] Fokker Dr.1 model added
Michael: What are your design references for the two WWI aircraft? Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Fokker Dr.1 model added
At 11/10/02, Jon Berndt wrote: Michael: What are your design references for the two WWI aircraft? Do you mean how did I get the aero data? Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
