Re: [Flightgear-devel] reality issues in MP

[Joacim Persson]

On Sat, 2 Jun 2007, Ron Jensen wrote:

> I was going to agree with real-world weather, but what if conditions in
> the area I want to fly in are IFR and I want/need to fly VFR?  Do I
> cancel my flightgear time and play sudoko instead?  or just forgo the
> pleasure of watching others fly as I fly, too?

Why do you want to watch other aircrafts take off from the other end of the
runway than yourself and crash into you? Would they want that too? Add
collision detection to the scenario of mixing uncontrolled VFR with
controlled IFR in the same airspace...  We simply can't implement an online
ATC, or any form or order, if the participating pilots disagree with the
ATC, and each other, about the flying conditions.  If you just want to
watch a lot of aircrafts moving around, AItraffic is the perfect tool. (And
that is, by the way, another feature that currently doesn't work well with
MP.) MP is not eye candy. It is a tool to interact with other traffic.

> Are you suggestion disappearing pilots would be better than "paused"
> pilots?

On MP, yes. Having (heavier-than-air) aircrafts hanging in the sky exactly
the way bricks don't kind of takes away the feeling of realism for those
who has to watch it as it wantonly violates the laws of gravity,
thermodynamics and probably a few others. A third option for fetching a mug
of coffee is using the autopilot.

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] reality issues in MP, Was: Flying at/for LinuxTag (fwd)

[Joacim Persson]

Looks like my sendmail was feeling ill today (DNS deficiency) and needed a 
cuddle and a restart. Second attempt:

On Sat, 2 Jun 2007, Torsten Dreyer wrote:

> http://www.t3r.de/fg/lt2007/dragonfly_an225.jpg

Was that me in the 225? ;) I did take off with it from EDDI/09L on Friday.
(Didn't notice an ultralight being sucked up by engine #5 though)

Anyway, look at the wind strut. It looks as if the 225 was lining up to
take off in a tail wind. And this brings up the issue of MP and reality:

The metar weather for EDDI on Friday was wind from 50 degrees, and the
default FG weather is 270 degrees. Some pilots where using runways 27L and
27R and others where using 09L and 09R, depending on if they had enabled
METAR weather or were using the default wind from the west. (Or perhaps
didn't care if they had headwind or tailwind?)

I've nagged about this on IRC from time to time: IMO, using
--enable-real-weather-fetch/METAR ought to be mandatory in combination with
MP. Or in the least to use the one and same weather. (There is perhaps the
possibility to consider that someone rigs up an MP server on an isolated
LAN, without having access to an online metar service, or don't want that
weather for some reason.)

So how about a default logic of enabling real-weather-fetch automatically if
--multiplay is used, unless an explicit --disable-real-weather-fetch is
set?

And as others may or may not have noticed, using
--enable-real-weather-fetch does not set the menu/dialogue option
"Weather->Weather Scenario->Weather source" to "METAR". There appears to be a
difference; not in wind but in cloud layers.

Maybe a few other reality options should be maintained in MP mode too,
like --timeofday=real, --time-match-real? ...disabling the "pause" and
"speedup" functions perhaps?

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] reality issues in MP, Was: Flying at/for LinuxTag

[Joacim Persson]

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] flash2a, inversed left right -- or pitch

[Joacim Persson]

On Mon, 28 May 2007, Stuart Buchanan wrote:

> FYI - the control is generally called the "control bar", or if including
> the attachment to the wing pivot "A-frame".

(AKA "speed bar".) I don't think of the speedbar as a control irl, but
rather as an extension of the wing. The control, "the stick", is my body.
That's how the Airwave hang glider in FG is operated too:
joystick forward==weight forward --> dive/increase speed,
joystick left==weight left --> bank/turn left. etc
So I would prefer to have the js work in the same old manner as for rudder
controlled aircrafts.

Is there any quick and simple way of inverting a js axis in jsbsim models?
(Short of holding the joystick upside down. ;)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] AN-225 patch

[Joacim Persson]

On Fri, 25 May 2007, leee wrote:

> http://www.air-and-space.com/Antonov%20An-225%20Mriya.htm
>
> it's the rear four sets.  This site also has some nice pics of the main gear,
> which show that the front three and rear four units are different, if anyone
> would like to make more detailed and accurate main gear units:)

(I can barely make a cube in Blender -- so don't look at me ;)

I suspect it can also kneel like the An-124. Looks like that on some of the
pictures too. But the 124 has a different setup with the main gear
steering, with the two forward axels steerable instead.

And rumor has it they are working on finishing the second 225 down in Kiev
now. The one they have in operation is booked up most of the time.

> The AN-225 also has a max taxiing weight but I couldn't find the doc which
> stated what it was:(  Basically, it means that the AN-225 cannot make ground
> turns above this weight and so for mtow takeoffs it has to be lined up on the
> runway and then loaded.  Unlike the AN-124, from which it was developed, it
> was never intended for short-field operation.

That information ought to be in the 2001 civil type certificate. (which may
have been published in Ukranian only though) I found the type certificate
number for it: (in latin-faked kyrillic) CTOK200-AH-225, but not the
document itself. (well, I can't google in non-latin alphabets)

We should add some more hard points to it. One can easily dip a wingtip or
engine in the ground now by turning too hard at too high taxi speed. Max
taxi speed is probably also specified in the type cert. And CG limits, and
other goodies...

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] transition-time, Was: AN-225 patch

[Joacim Persson]

On Thu, 24 May 2007, Andy Ross wrote:

> Joacim Persson wrote:
>> README.yasim says the "semi-deprecated" transition-time is "Time in
>> seconds to slew through input range." I'm not quite sure what it is,
>> but it's not that. ;)
>
> It's coded to assume that the "input range" is 0-1.

>From experimenting with it, I gathered it also assumes an /output/ range of
the same scale. To have a movement over one second with an input range of
0--1 and an output range of 0.0--0.1 (using src/dst tweaks), the
transition-time value have to be set 10 seconds. From the docs, however,
one would expect the value to stay at 1.0 seconds regardless of how the
output range is tweaked. So docs and code doesn't agree here and that may
cause some confusion for the users.

> It was really written for landing gear.  If you want to model hydraulic
> delays (which is what I think is happening here) you'd probably be
> happier with some Nasal anyway.  Thus the "semi-deprecated" note: this
> feature still works as intended, but there are far more robust ways to
> solve the same problem in the modern environment.

Yes synchronising multiple steering wheels accurately -- make all the 20
steerable wheel hubs point at exactly the same spot on the tarmac
throughout the full interval -- would take scripting anyway, involving
atan() and other evil trigonometric chants. ;)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] AN-225 patch

[Joacim Persson]

Patch attached.

Added steering to the four aftmost main gear axels -- with animations!

Found out just the other day that the AN-225 indeed steers on some of the
main gear wheels. The minimum turning radius is a wild guess however.
(Assumed a 45 deg average on the nose gears.) It now turns (quite
effortlessly) around a point straight out to the side from the second main
gear axel (nr 2 of the 3 non-steerable main gear axels), with a minimum
radius of 25.75 meters. (i.e. near engine nr 1 or 6) The option "squared"
was removed on steering. (Squaring radians messed up my calculations of the
turning angle of the respective wheels. Not that it's a perfect calculation
now either.) Ground wheel steering should, rather, not be connected to
directly the rudder pedals I think...

Also added transition-time(s) for the steering.

By the way:
README.yasim says the "semi-deprecated" transition-time is "Time in
seconds to slew through input range." I'm not quite sure what it is, but
it's not that. ;) (seconds for 2*1.0 on the output property? I.e. for a
rotation, that'd be 2.0 radians --? It doesn't operate on the input range
taking src/dst translations into account anyway.) Can't tell if this is a
code bug or a doc error.Index: data/Aircraft/AN-225/AN-225-yasim.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/AN-225/AN-225-yasim.xml,v
retrieving revision 1.5
diff -p -u -r1.5 AN-225-yasim.xml
--- data/Aircraft/AN-225/AN-225-yasim.xml   2 Mar 2006 22:40:56 -   
1.5
+++ data/Aircraft/AN-225/AN-225-yasim.xml   24 May 2007 18:01:25 -
@@ -164,7 +164,8 @@ them out of my 3d modeller.
 
 
  
-  
+  
   
 
  
-  
+  
   
 
@@ -295,43 +319,63 @@ them out of my 3d modeller.
  
 
  
+  
   
   
   
   
   
   
+  
   
+  
  
 
  
+  
   
   
   
   
   
   
+  
   
+  
  
 
  
+  
   
   
   
   
   
   
+  
   
+  
  
 
  
+  
   
   
   
   
   
   
+  
   
+  
  
 
 
Index: data/Aircraft/AN-225/Models/AN-225-model.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/AN-225/Models/AN-225-model.xml,v
retrieving revision 1.3
diff -p -u -r1.3 AN-225-model.xml
--- data/Aircraft/AN-225/Models/AN-225-model.xml2 Mar 2006 22:40:57 
-   1.3
+++ data/Aircraft/AN-225/Models/AN-225-model.xml24 May 2007 18:01:26 
-
@@ -1405,7 +1405,7 @@ AN225 model/animation config.
   L-NG-Strut
   gear/gear[0]/steering-norm
   0
-  -45
+  -57.30
   
-20.03
-0.93
@@ -1583,7 +1583,7 @@ AN225 model/animation config.
   R-NG-Strut
   gear/gear[1]/steering-norm
   0
-  -45
+  -57.30
   
-20.03
0.93
@@ -2292,6 +2292,28 @@ AN225 model/animation config.
   
  
 
+
+ 
+  rotate
+  L-MG-4-IS-Tyre
+  L-MG-4-OS-Tyre
+  L-MG-4-IS-Hub
+  L-MG-4-OS-Hub
+  L-MG-4-Strut
+  gear/gear[5]/steering-norm
+  0
+  -57.30
+  
+   9.05
+   -3.2
+   -2.0
+  
+  
+   0
+   0
+   1
+  
+ 
 
 
  
@@ -2472,6 +2494,28 @@ AN225 model/animation config.
   
  
 
+
+ 
+  rotate
+  L-MG-5-IS-Tyre
+  L-MG-5-OS-Tyre
+  L-MG-5-IS-Hub
+  L-MG-5-OS-Hub
+  L-MG-5-Strut
+  gear/gear[6]/steering-norm
+  0
+  -57.30
+  
+   10.72
+   -3.2
+   -2.0
+  
+  
+   0
+   0
+   1
+  
+ 
 
 
  
@@ -2652,6 +2696,28 @@ AN225 model/animation config.
   
  
 
+
+ 
+  rotate
+  L-MG-6-IS-Tyre
+  L-MG-6-OS-Tyre
+  L-MG-6-IS-Hub
+  L-MG-6-OS-Hub
+  L-MG-6-Strut
+  gear/gear[7]/steering-norm
+  0
+  -57.30
+  
+   12.42
+   -3.2
+   -2.0
+  
+  
+   0
+   0
+   1
+  
+ 
 
 
  
@@ -2832,6 +2898,28 @@ AN225 model/animation config.
   
  
 
+
+ 
+  rotate
+  L-MG-7-IS-Tyre
+  L-MG-7-OS-Tyre
+  L-MG-7-IS-Hub
+  L-MG-7-OS-Hub
+  L-MG-7-Strut
+  gear/gear[8]/steering-norm
+  0
+  -57.30
+  
+   14.10
+   -3.2
+   -2.0
+  
+  
+   0
+   0
+   1
+  
+ 
 
 
  
@@ -3552,6 +3640,28 @@ AN225 model/animation config.
   
  
 
+
+ 
+  rotate
+  R-MG-4-IS-Tyre
+  R-MG-4-OS-Tyre
+  R-MG-4-IS-Hub
+  R-MG-4-OS-Hub
+  R-MG-4-Strut
+  gear/gear[12]/steering-norm
+  0
+  -57.30
+  
+   9.05
+   3.2
+   -2.0
+  
+  
+   0
+   0
+   1
+  
+ 
 
 
  
@@ -3732,6 +3842,28 @@ AN225 model/animation config.
   
  
 
+
+ 
+  rotate
+  R-MG-5-IS-Tyre
+  R-MG-5-OS-Tyre
+  R-MG-5-IS-Hub
+  R-MG-5-OS-Hub
+  R-MG-5-Strut
+  gear/gear[13]/steering-norm
+  0
+  -57.30
+  
+   10.72
+   3.2
+   -2.0
+  
+  
+   0
+   0
+   1
+  
+ 
 
 
  
@@ -3912,6 +4044,28 @@ AN225 model/animation config.
   
  
 
+
+ 
+  rotate
+  R-MG-6-IS-Tyre
+  R-MG-6-OS-Tyre
+  R-MG-6-IS-Hub
+  R-MG-6-OS-Hub
+  R-MG-6-Strut
+  gear/gear[14]/steering-norm
+  0
+  -57.30
+  
+   12.72
+   3.2
+   -2.0
+  
+  
+   0
+   0
+   1
+  
+ 
 
 
  
@@ -4092,6 +4246,28 @@ AN225 model/animation config.
   
  
 
+
+ 
+  rotate
+  R-MG-7-IS-Tyre
+  R-MG-7-OS-Tyre
+  R-MG-7-IS-Hub
+  R-MG-7-OS-Hub
+  R-MG-7-Strut
+  gear/gear[15]/steering-norm
+  0
+  -57.30
+  
+   14.10
+   3.2
+   -2.0
+  
+  
+   0
+   0
+   1
+  
+ 
 
 
  
---

Re: [Flightgear-devel] An2 problems

[Joacim Persson]

On Wed, 7 Mar 2007, Ron Jensen wrote:

> I hand massaged the pitch to 17/32 as in the original file, and I
> lowered the diameter from 141.7 to 132 because it wouldn't start with
> 141.7 as a diameter.

That (132in) is the correct diameter for the AV-2 propeller. (132 inches or
3.35 meters) Source: http://www.vectorsite.net/avan2.html

But there's supposed to be a gearbox between the engine and propeller on
the AN-2 versions with AV-2 propeller. And the AV-2 is not a constant speed
propeller, but a plain variable-pitch design. (ibid.)

I sent this patchlet to Yuri (the author) in november last year:
   an2/Engines/AV-2.xml:

   - 400 
   - 2500 
   +   1.38 

   minrpm/maxrpm are for defining a constant speed propeller. (There is a bug
   in aeromatic.) For a manually variable pitch propeller, these should be
   left unset. And  isn't generated by aeromatic either.

(I dont' know if Aeromatic has been fixed sinced that. Haven't checked.)

Then there were also some problems with hard-coded idle rpm limits in
JSBsim. This was discussed on the list when the aircraft model was
introduced last year (in november).

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ATISs upgrade

[Joacim Persson]

On Fri, 2 Mar 2007, John Denker wrote:

> On 03/01/2007 02:19 PM, AJ MacLeod wrote:
>> Was the stuff at line 300 intended to be in there?
>
> Actually yes, I put the call-trace in there for a reason, and I left
> it in there for a reason.  I thought that in the future, some folks
> might find it helpful to see how/where this code was being called.

Anyone who needs that backtrace can do it himself. Those who don't even
know how to do set breakpoints and do a simple backtrace with a debugger,
won't understand sourcecode anyway.

Just like soucecode, saved backtraces would be documentation of
implementation, not design. The latter is something that could be improved
a lot for FG. :P  I'm not sure the sourcecode files is the right place for
that though, being limited to ascii plaintext; and by the risk of having the
documentation deleted by accident or misunderstandings; and in that it isn't
allways obvious that a design idea is connected to one particular position
in the code. Someone editing another source file may miss it together.
Maybe we should have a design documentation wiki? (Then just refer to
sections there from the source when necessary.)

And Melchior is our source tree janitor whose job is act "troll on the
bridge" and keep the code nice and tidy. So just do as he says regarding
the cosmetics so we can get the stuff in already, OK. =)

Good work with cleaning up the ATIS mess.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Properties and weather

[Joacim Persson]

On Tue, 20 Feb 2007, Holger Wirtz wrote:


Is there something like a "smooth" factor for weather changes?


Alas, no. I worked a bit on a hack a while ago to smoothen out the "wall
of weather" somewhat, but got stuck on certain weather properties that
simply couldn't see how they were set. Some stuff is set via the property
tree, other data appear to be set in c++ objects and then copied to the
property tree.

Patch enclosed if you or anyone else want to play with it. (Beware: this
diff was hand edited to remove unrelated diffs and has not been tested at
all.)Index: source/src/Environment/environment_ctrl.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/environment_ctrl.cxx,v
retrieving revision 1.46
diff -p -u -r1.46 environment_ctrl.cxx
--- source/src/Environment/environment_ctrl.cxx 7 Mar 2006 10:26:25 -   
1.46
+++ source/src/Environment/environment_ctrl.cxx 13 Feb 2007 23:22:49 -
@@ -374,21 +374,21 @@ static void set_dewpoint_at_altitude( fl
 
 
 void
-FGMetarEnvironmentCtrl::update_env_config ()
+FGMetarEnvironmentCtrl::update_env_config (double dt_sec)
 {
 fgSetupWind( fgGetDouble("/environment/metar/base-wind-range-from"),
  fgGetDouble("/environment/metar/base-wind-range-to"),
  fgGetDouble("/environment/metar/base-wind-speed-kt"),
- fgGetDouble("/environment/metar/gust-wind-speed-kt") );
+ fgGetDouble("/environment/metar/gust-wind-speed-kt"), dt_sec 
);
 
 fgDefaultWeatherValue( "visibility-m",
-   fgGetDouble("/environment/metar/min-visibility-m") 
);
+   fgGetDouble("/environment/metar/min-visibility-m"), 
dt_sec );
 set_temp_at_altitude( fgGetDouble("/environment/metar/temperature-degc"),
   station_elevation_ft );
 set_dewpoint_at_altitude( fgGetDouble("/environment/metar/dewpoint-degc"),
   station_elevation_ft );
 fgDefaultWeatherValue( "pressure-sea-level-inhg",
-   fgGetDouble("/environment/metar/pressure-inhg") );
+   fgGetDouble("/environment/metar/pressure-inhg"), 
dt_sec );
 }
 
 void
@@ -414,14 +414,15 @@ FGMetarEnvironmentCtrl::init ()
 if ( a ) {  
 FGMetarResult result = fetch_data( a->getId() );
 if ( result.m != NULL ) {
+double dt_sec = 
fgGetDouble("/environment/metar/interpolation-time-sec", 0);
 SG_LOG( SG_GENERAL, SG_INFO, "closest station w/ metar = "
 << a->getId());
 last_apt = a;
 _icao = a->getId();
 search_elapsed = 0.0;
 fetch_elapsed = 0.0;
-update_metar_properties( result.m );
-update_env_config();
+update_metar_properties( result.m, dt_sec );
+update_env_config(dt_sec);
 env->init();
 found_metar = true;
 } else {
@@ -450,7 +451,7 @@ FGMetarEnvironmentCtrl::reinit ()
 }
 
 void
-FGMetarEnvironmentCtrl::update(double delta_time_sec)
+FGMetarEnvironmentCtrl::update(double delta_time_sec, double dt_sec)
 {
 
 _dt += delta_time_sec;
@@ -515,7 +516,7 @@ FGMetarEnvironmentCtrl::update(double de
 result = result_queue.front();
 result_queue.pop();
 if ( result.m != NULL ) {
-update_metar_properties( result.m );
+update_metar_properties( result.m, dt_sec );
 delete result.m;
 update_env_config();
 env->reinit();
@@ -603,7 +604,7 @@ FGMetarEnvironmentCtrl::fetch_data( cons
 
 
 void
-FGMetarEnvironmentCtrl::update_metar_properties( const FGMetar *m )
+FGMetarEnvironmentCtrl::update_metar_properties( const FGMetar *m, double 
dt_sec )
 {
 int i;
 double d;
@@ -617,9 +618,9 @@ FGMetarEnvironmentCtrl::update_metar_pro
 fgSetString("/environment/metar/last-metar", m->getData());
 fgSetString("/environment/metar/station-id", m->getId());
 fgSetDouble("/environment/metar/min-visibility-m",
-m->getMinVisibility().getVisibility_m() );
+m->getMinVisibility().getVisibility_m(), dt_sec );
 fgSetDouble("/environment/metar/max-visibility-m",
-m->getMaxVisibility().getVisibility_m() );
+m->getMaxVisibility().getVisibility_m(), dt_sec );
 
 const SGMetarVisibility *dirvis = m->getDirVisibility();
 for (i = 0; i < 8; i++, dirvis++) {
@@ -629,9 +630,9 @@ FGMetarEnvironmentCtrl::update_metar_pro
 d = dirvis->getVisibility_m();
 
 snprintf(s, 128, min, i);
-fgSetDouble(s, d);
+fgSetDouble(s, d, dt_sec);
 snprintf(s, 128, max, i);
-fgSetDouble(s, d);
+fgSetDouble(s, d, dt_sec);
 }
 
 fgSetInt("/environment/metar/base-wind-range-from",
@@ -639,17 +640,17 @@ FGMetarEnvironmentC

Re: [Flightgear-devel] The infamous invisible wall of weather

[Joacim Persson]

On Thu, 1 Feb 2007, Curtis Olson wrote:
> It's somewhat of a complex C++ inheritance maze to wade through,

Affirmative. ;) Looking at the code I can tell there's years of development
in layers on top of each other there, not entirely consistent with a one
and same philosophy.

> I'm not a big fan of interpolating between nearby stations because as those
> nearby station conditions are updated, you will still see discontinuous
> jumps in the local conditions ... plus it's complicated, time consuming,
> memory consuming, etc.
>
> What I would like to see is a mechanism that slowly (over the course of a
> couple minutes) migrates the "current" conditions towards the most recent
> data that is fetched via the metar subsystem.

Time interpolating over several minutes on a per plane basis will make
pilots on MP each flying in their own weather, even when they are all using
METAR weather (which IMO should be mandatory on MP). So they wouldn't even
agree on where the flighlevels are.  That would mess upp the IVAO stuff Pep
Ribal was talking about here recently. As I mentioned in my last message,
I'm more into using a combination of geometrical interpolation and time
interpolation using a small time delta (seconds) to filter out the
remaining transients. But again, we can't get enough data from METAR only.
(Think of intercontinental flight)

I can also imagine that different users with different needs for a flight
simulator would have different needs for weather model. Someone might want to
have a detailed simulation of microweather using software like MetPhoMod
(http://www.giub.unibe.ch/klimet/metphomod/, GPL'ed), for simulating flight
in a mountain area with difficult up- and downdrafts; soaring pilots want
realistic thermals that a motor pilot only thinks of as "turbulence".
Helicopter landings on offshore oil rigs etc etc. My feeling is that there
should first and foremost be a defined interface for weather vs the rest of
the sim system. Then people can hook up whatever they like to it using that
interface.

>
> We could do this a number of ways ... we could extend the interpolations
> scheme out to another enclosing layer to interpolate smoothly between "past"
> and "current" conditions.  We could simply move the data values in the
> "current" interpolation tables slowly towards the new values as they are
> updated.  This might be the simplest.  We could establish some sort of
> reasonable rate of change for each value type and just at that delta every
> iteration.
>
> This doesn't address clouds which are slightly more complex ... you could
> slowly move a layer to a new altitude and that should work ok, but how do
> you add a new layer or remove a layer smoothly and cleanly ... that get's
> tougher with our current scheme.

I am currently time interpolating everything weatherish typed as a double
using a modified fgSetDouble() with an extra optional argument. (But for some
bizarre reason, the sea-level air pressure -- what I particulary want to
smooth out -- refuses to be interpolated yet.  AAaargh!)

Horizontal cloud density is not a double though -- conceptually it's an
enumerate rather. Not much I can do about that. But the clouds doesn't
knock the aircraft over in a tunnel roll.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] The infamous invisible wall of weather

[Joacim Persson]

On Thu, 1 Feb 2007, George Patterson wrote:

> The interpolation should also take into account the distance between the
> METAR stations and the plane and weight the effect of the weather
> effects from there.
>
> Example: If I am flying right above a METAR station and there is another
> one 100km away, then ignore the distant station.

Well it is ignored already of course. ;) At the moment, only the nearest
METAR is used. The other idea (other than time interpolation) is to compute
some sort of weighed average between METAR stations around the aircraft
depending on the distance to them.

Time interpolation is necessary too anyway, to smoothen out a METAR update from
the one and same station, and also for transients emanating from switching the 
set of
stations being used as lined out above. I would expect these changes to be
fairly small under normal circumstances (although a front can pass a
station and shift the wind quite dramatically)-- but it's still transients
and can stir up autopilots.

But I think I have ran into a bug too:
Using --enable-real-weather-fetch does not set
/environment/weather-scenario to "METAR" automatically. The environment
code checks that property here and there, so I guess it matters.

METAR is not an optimal source for weather data, but perhaps the best
we can get for now (without paying big money for it). There are no METAR
stations out in the oceans for instance. And all METAR stations does not
provide the same set of information either. An alternative to using METAR
could be designing some sort of weather generator server that provides a
realistic (not real) weather which, contrary to METAR, has complete data for
the whole world.

I have something now which is a fair bit better than it was before:
notoriously barrel rolling the pa24-250 on a METAR switch has been replaced
by a mere shake. (I have yet to figure out what @$&*%! piece of code is
bypassing my nice and smooth interpolation of
/environment/pressure-sea-level-inhg all the time.)

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Trains?

[Joacim Persson]

On Thu, 1 Feb 2007, leee wrote:

> On Thursday 01 February 2007 00:35, Curtis Olson wrote:
>> For what it's worth, if someone wanted to adapt one of our existing fdm's
>> to do automotive vehicle dynamics, that would be a cool thing.

> It had occurred to me that YASim could be (ab)used to fake a car.

I have been using a setup for testing/measuring fuselage drag of the Chinook,
aka the "chinook bus".  I just added a thruster element down at the rear
wheels and a adjusted few other things. The original rotors were replaced
by a miniature rotor the size of a cpu fan, just to keep yasim in helicopter
mode. It actually autorotated sometimes. It was also during one of these
test runs I had an accident with a cow (the new greenhorn breed) and
crashed. ;)  That was before the recent ground bumpiness/friction patch so
I didn't always bother to stay on the runway.

But what cannot be simulated currently, in the above manner, is
powerskidding with the driving wheels.  There is also no gear box model.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] The infamous invisible wall of weather

[Joacim Persson]

I have an idea of how to at least partially fix the problem with the "wall
of weather" when flying with METAR updates, which when flying on autopilot
in a light aircraft often, not to say usually, results in advanced
airobatic manouvers, loss of control, altitude, and adjustment of the
horizontal gyro. It has been suggested that we should triangulate the
weather from several neighbouring metar data rather than one and that is by
all means an excellent idea but it may not solve everything (there could
still be transients due to varying/poor resolution of metar stations) and is
perhaps trickier to implement than what I have in mind. I think the two
methods should be combined for best result.

The /environment/metar/ properties are set in
FGClouds::update_metar_properties( const FGMetar *m )
[src/Environment/fgclouds.cxx: line 270]
where m is the new metar data. The properties are set with calls to the
fgSet...-functions from [src/Main/fg_props.hxx]

What I would like to do, is replace these instant Set-ing of the properties
to something similar to the interpolate-function in nasal, to smooth out
the change of weather over a certain time; a few seconds up to perhaps a
minute, whatever works best. At least I want to try it out.

Any ideas on how to implement this? I'm considering doing calls to the nasal
system for the interpolating. Any pitfalls with that? Better ways of doing it?
Useful functions I may have missed?

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear's restriction on sound hardware?

[Joacim Persson]

On Tue, 30 Jan 2007, Ampere K. Hardraade wrote:

> Just thought I should bring this to the list's attention:
>
> http://forums.avsim.net/dcboard.php?az=show_mesg&forum=198&topic_id=2326&mesg_id=2352&page=

Can this have something to do with the nforce (Intel 8x0?) audio chip's
inability to do 8-bit mono? (Lowest audio bandwidth supported by the chip
is 16-bit stereo if I remember it right from the top of my head here.)
Some sound files used in FG models are 8-bit mono.

The OSS driver for that chip is not actually OSS-compliant since 8-bit mono
is the specified default configuration at OSS initialisation. And I suspect
there are more "misfeatures" in the Linux OSS driver for that particular
chip. The OSS driver for it doesn't work at all with teamspeak (8-bit mono
again) for instance. Methink the driver whisper lies in user space about the
card, or at least not tell the whole truth...

The ALSA-driver does the job with teamspeak. Without having ivestigated it,
I would guess it recalculates an 8-bit mono stream to 16-bit stereo on the
fly. And the Windows-driver probably does the same. It's not a bad audio
chip really, but it doesn't support low bandwidth sound streams directly so
that has to be done in software somewhere, which may be error prone.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Trains?

[Joacim Persson]

On Tue, 30 Jan 2007, Tony Pelton wrote:

> and as a passing comment, i wonder if one of the train simulators
> might be a better train simulator that flightgear for your intended
> purpose ...

Or better still, a car simulator. (Assuming the mentioned train crossing
signs are to be viewed from the driving seats of moving cars.)

Perhaps the freeware racing simulator Torcs (www.torcs.org) could be
something for the psychology professor's experiment? Torcs uses plib, so it
can load the same 3d fileformats FlightGear can, and also has physic models
of road vehicles ready, and far better looking roads than FG.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] apt.dat et al.

[Joacim Persson]

I noticed that the versions of apt.dat, nav.dat etc we have in CVS are somewhat
outdated (~12 months old). Time for an update perhaps?

I understand we are using the 810 format for apt.dat -- are there work in
progress for switching to version 850? (Not a trivial task: v850 includes
improved drawing functions like Bezier curves.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] announcing star trek runabout shuttle and questions

[Joacim Persson]

On Fri, 26 Jan 2007, Stewart Andreason wrote:

> Hi Ampere,
>
> Actually creating a cloaking device isn't that difficult,

Ha! You can run but you can't hide from the PS-05/Blue Vixen radar. ;)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Terrasync

[Joacim Persson]

scenery.flightgear.org is down again

Since the scenery data is mirrored on a number of other ervers, would
it be possible to provide an rsync interface on some of these mirrors
aswell? I reckon it would both improve availability and spread the load
from the primary terrasync server. (And probably save some total bandwidth
too.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] segfaults in SGShaderAnimation::~SGShaderAnimation(), Patch

[Joacim Persson]

On Fri, 5 Jan 2007, Maik Justus wrote:

> Hello,
>
> sometimes I get a segfault in function 
> SGShaderAnimation::~SGShaderAnimation(), file 
> simgear/scene/model/shadanim.cxx.

I never get a SIGSEGV from there, but rather a SIGABORT due to a failed
assert. (This with plib, nota bene) And from the gang-debugging session we
had last night on IRC+MP we now know how to replicate it. (although I'm not
sure if there was a consesus on exactly how, but something like this: at least
two models using the chrome shader, one leaves mp and then fgfs crashes for
any miserable one watching them leave. Other's said it was provoked by a
join-leave-rejoin cycle)

I looked through my gdb logs frm last night again now and found this
interesting little piece of forensic evidence:
#
$30 = { = { = {_vptr.ssgBase = 0x861cd08, refc = 0, 
unique = 169256, type = 1,
   spare = 0, name = 0x0, user_data = 0x0}, static current_object = 0x0,
 static sim_time_sec = 370.013874, _branch = 0xe84da10, 
animation_type = 0}, _condition = 0x0,
   _condition_value = true, _shader_type = 3, _param_1 = 1, _param_color = 
{9.52882956e-44, 9.38869971e-44,
 9.52882956e-44, 8.82818033e-44}, _depth_test = true, _factor = 1, 
_factor_prop = {_ptr = 0x0},
   _speed = 1, _speed_prop = {_ptr = 0x0}, _effectTexture = 0xe822df8,
   _textureData = 0xe860b98 
"\216\211\214\210\203\207\203~\201{wzxtvwtvwtuwtuxuvyvwywwzwx~}{\200\200~\201\202\1
77\202\203\177\202\203\177\211\204\206\201\177|\205\205\204\206\206\206\206\206\206\206\206\206\223\224\222\23
0\231\226\232\234\231\234\236\232\235\237\233\235\237\233\236\237\234\236| 
\234\236| \234\236| \234\236| \234\
236| \234\236| 
\234\236\237\234\235\237\233\235\237\233\234\236\232\232\234\231\230\231\226\223\224\222\206\20
6\206\206\206\206\206\206\206\205\205\204\201\177|\211\204\206\202\203\177\202\203\177\201\202\177\200\200~~}{
zwxywwyvwxuvwtuwtuwtvxtv{wz\203~\201\210\204\207\203~\201{w"..., _texWidth = 
64, _texHeight = 64, _envColor =
{
 0.853901267, 0.865621746, 0.934002459, 1}}
(gdb) print * this._effectTexture
$31 = { = {_vptr.ssgBase = 0x862d428, refc = 1, unique = 169252, type 
= 17, spare = 0, name = 0x0,
 user_data = 0x0}, filename = 0x0, own_handle = 0, handle = 0, wrapu = 0, 
wrapv = 0, mipmap = 0,
   has_alpha = false}
###

Note the refc's are different for the parent and child.


Something like this perhaps?
  if (_effectTexture->getRef()==UNUSED) delete _effectTexture;
#define UNUSED 0 // ??





-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] spam ridden official FlightGear forum

[Joacim Persson]

On Fri, 19 Jan 2007, Curtis Olson wrote:

> I believe the captcha is randomly generated each time.  I'm pretty sure the
> problem is real people who take the time to sign on, answer the captcha,
> reply to the confirmation email, and then go to town with their spam.

Beware. Captchas can be breached automatically nowadays. (And Stefan: that
is not specific to phpBB.)

A couple of articles specifically on breaching captchas:
http://blog.phpbb.cc/articles/captcha/
http://sam.zoy.org/pwntcha/

Further reading:
http://www.w3.org/TR/turingtest/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Ki-84 Hayate

[Joacim Persson]

Some feedback:

* Nice plane to fly. (Perhaps a bit too forgiving in a stall?)

* Impossible to taxi. I noticed the friction coefficients for the main
   gear wheels are significantly lower (dfric="0.06" sfric="0.10") than for
   the tail wheel (dfric="0.3" sfric ="0.40").  So there's virtually no
   braking action, thus nothing to steer with. ...leaking engine oil soaking
   the tyres? ;)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] How to get Doc without PDF format ?

[Joacim Persson]

On Thu, 18 Jan 2007, gh.robin wrote:
> The problem with pdf on screen is that the page layout is FIXED like it is
> on paper. That is why it prints more consistantly , that page layout is
> cast in stone. If you have a smaller screen or need larger text you have
> to scroll _horizontally_ to read the document. To all intents and purposes
> it becomes unreadable.

I'm looking at getstart.pdf on a 14" monitor in 800x600 now, and at a zoom
level of 200% in kpdf, there is still margin on the sides to zoom more. In
that resolution and zoom, a capital letter in the running text is about
5--6mm tall. (Same size as the letters on my keyboard tops and more than
twice the size of common newspaper print) When the day comes when I cannot
even read that anymore, I better invest in a pair of reading glasses.


> Under the same conditions html reformats to fit.

Y
o
u

m
e
a
n

l
i
k
e

t
h
i
s
?

;
-
)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] How to get Doc without PDF format ?

[Joacim Persson]

On Thu, 18 Jan 2007, gh.robin wrote:

> Oh, yes you are right , with a 21 inches CRT, and 2048x1536  these PDF
> documents are readable.
>
> Have you tried it with 15 inches and 800x600


I fail to see how it could matter for the viewability wether there is a
pdf-viewer rendering fonts on the screen or if there is a web browser doing
exactly the same thing.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] How to get Doc without PDF format ?

[Joacim Persson]

On Thu, 18 Jan 2007, Stuart Buchanan wrote:

> However, as it is converted from the Latex source, it isn't as easy to
> read as a pure HTML document. There is certainly room for improvement in
> that area.

If you mean that the LaTeX source isn't easy to read (not to mention edit)
for people unfamiliar with LaTeX/TeX, let me recommend LyX:
http://www.lyx.org/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Help,questions about multiplayer

[Joacim Persson]

On Tue, 16 Jan 2007, tangyong wrote:

> Hi,everybody. My project need to drive many aircraft to fly autonomouslly
> using ATC radar data.My radar data contains many aircrafts' flight data.I
> set up a FlightGear server(fgms) in my local network and what I need to
> do is just inputing my radar data(each client has a unique callsign) to
> the fgms.Then the fgms and the FlightGear will do all the thing I need.Is
> that right?

That depends on what it is you need of course. ;)


> But my problem is that my radar data only contains position
> information(lat,lon and alt).

Then that's all you can display that aren't guessed values.

> What's the use of these variables in FG?
"orientation" is where the nose of the aircraft is pointing
"linearVel" is it's velocity vector (whereto it's flying)
"angularVel": angular velocity vector (how it is rotating)
and then the corresponging acceleration vectors

This data is used for displaying the orientation, velocity and
accelerations of the aircrafts in the simulation at the receiver of the
datagrams. Since the position is only updated at intervals (shortly after
the reception of each datagram), the velocity value is used for displaying
it in the meantime, between updates.  If velocity was zero but position
changes, then the aircraft would jump between positions at each new
datagram.

If the heading (included in "orientation") is zero, the nose of the
aircraft will always point north (I presume), regardless of where it's
flying. And so on. Of course, that may look funny in the simulation. But
that's as good as it can be without any data about orientation, velocity
and accelerations.

You could simply set the unknown data to zeros to begin with, to comply to
the protocol. (and live with aircrafts jumping around with their noses always
pointing north and never banking in turns)

Or you could try to design an algorithm to calculate/predict/guess them.
And then you have to find a compromise between correctness and time delay,
according to the sampling theorem. And live with strange flying aircraft
each time you guess wrong, depending on how much time delay you can
accept. (Aftermath is the only truly exact science.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] kap140 bug+fix

[Joacim Persson]

On Thu, 11 Jan 2007, Melchior FRANZ wrote:
>> (Why are there three copies of essentially the same file anyway?
>
> That's a bug. There should be only one global one.
> Which one is the best?

Hopefully, the best version would be the overhauled version Vegard Ovesen
mentioned he is sitting on but not yet has made it's way to cvs. (See his
message of jan 3rd ...was it?)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Idea: VOR/ILS/NDB "Emergency" Localizer

[Joacim Persson]

On Tue, 9 Jan 2007, Douglas Campos wrote:

> my reasons about this is that f* country that i live won't let you
> find nav info/ enroute/terminal charts easily
>
> You need to subscribe to cindacta's monthly crap for a lot of
> money $8/page of info.
>
> Imagine that is near impossible for a poor guy have some navigation charts...

I can relate to the cost issue, but that's no excuse for getting lost while
flying in the flight simulator. With emphasis: _plan_ the flight before you
take off. Learn how to navigate. Don't get lost, and then you won't need to
ask the flight simulator where you have flown(?!). That's _your_ job to
know. You're the pilot. (Well, in the l410 you can be a passenger, but
someone has to fly the thing too. ;)

There are several options to get the necessary information for planning the
flight.

* Use the FlightGear Flightplanner:
 http://sourceforge.net/projects/fgflightplanner/
 (which however doesn't list ILS beacons)

* If you want to use real charts and standard departures/approaches and
   can't retrieve any for one area, then fly in areas for which you /can/
   get information. (The US is a safe bet here, due to publicity laws. But
   it goes for most of the world.)
   ...What's this btw? (speaking of Cindacta):
   http://paginas.terra.com.br/servicos/marcotulio/index_arquivos/Page348.htm
   (Came there from www.vatsim.net)

* Make your own charts:
 - The MP server map page is an excellent source for locations and
   frequencies of navigation beacons (including ILS), airways etc.
 - Atlas (apart from the moving map RAM-eater, that package also contain
   tools for producing printable maps.)

To get back on the topic: The "emergency localiser" you ask for would be
contacting the ATC, admitting that you are lost and ask for instructions.
(And prepare for an interrogation and investigation after landing.) In
the initial phase of pilot training, the student is restricted to stay
within visible range of the home field.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Idea: VOR/ILS/NDB "Emergency" Localizer

[Joacim Persson]

On Tue, 9 Jan 2007, Douglas Campos wrote:

> I'm interested in implementing it.
>
> Case:
>
> I'm flying near some airport that i don't know, then  I use the GPS
> Instrument Setting dialog to find a near airport. How can I make a
> query about the navaids near this airport?

Hrrrm! ;)
(You just don't fly near an airport you don't know.)
IRL, you are obliged to at all times know where you are and where you are
going: pre-flight planning, navigation... Which incidently is one of the
things for which a flight simulator can be used as a training tool.

Highly recommended web site:
http://www.navfltsm.addr.com/index.htm

Note that there are differences in some details. That site is oriented
around MSFS, wich has some flaws FGFS doesn't have, and perhaps vice-versa.

Some things I've noticed that the author warns for which doesn't apply to
FG:
* FGFS directional gyros *are* drifting as real (affordable) gyros do. 
(model-dependant)
* FGFS metar weather is correct regarding wind directions.

(Cheat tip: use the MP server map.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Inertia tensor

[Joacim Persson]

On Fri, 5 Jan 2007, Ampere K. Hardraade wrote:

> This may be a little off topic, but:
>
> What is a tensor?

http://en.wikipedia.org/wiki/Tensor
(here it's the engineering meaning of the word)

And a pretty good handbook (well, scan quality is not the best) on the
topic of inertia calculations of aircrafts is available from:
http://stinet.dtic.mil/  Search for "AD0617354"
pdf, ~5MB

Title: AIRCRAFT MOTION ANALYSIS
AD Number: AD0617354
Corporate Author: DOUGLAS AIRCRAFT CO LONG BEACH CA
Personal Author: Thelander, J. A.
Report Date: March 01, 1965
Media: 107 Pages(s)
Distribution Code: 01 - APPROVED FOR PUBLIC RELEASE
Report Classification: (Not Available).
Source Code: 116400
From the collection: Technical Reports


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] patch for Yasim (printing out inertia tensor)

[Joacim Persson]

On Fri, 5 Jan 2007, Roy Vegard Ovesen wrote:


I'm pretty sure what you had in your patch and what I wrote in my last post is
correct.


Yup, apart from my confused comments in yasim-test.cpp

I hereby declare the enclosed patch as the last and final version.  ;)Index: source/src/FDM/YASim/RigidBody.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/RigidBody.cpp,v
retrieving revision 1.2
diff -p -u -r1.2 RigidBody.cpp
--- source/src/FDM/YASim/RigidBody.cpp  14 Aug 2006 21:59:44 -  1.2
+++ source/src/FDM/YASim/RigidBody.cpp  5 Jan 2007 17:13:43 -
@@ -204,4 +204,14 @@ void RigidBody::getAngularAccel(float* a
 Math::vmul33(_invI, v, v);   // v = invI*(tau + (omega X I*omega))
 }
 
+void RigidBody::getInertiaMatrix(float* inertiaOut)
+{
+// valid only after a call to RigidBody::recalc()
+// See comment at top of RigidBody.hpp on units.
+for(int i=0;i<9;i++)
+{
+   inertiaOut[i] = _tI[i];
+}
+}
+
 }; // namespace yasim
Index: source/src/FDM/YASim/RigidBody.hpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/RigidBody.hpp,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 RigidBody.hpp
--- source/src/FDM/YASim/RigidBody.hpp  10 Sep 2002 01:14:03 -  1.1.1.1
+++ source/src/FDM/YASim/RigidBody.hpp  5 Jan 2007 17:13:44 -
@@ -97,6 +97,9 @@ public:
 // Returns the instantaneous rate of change of the angular
 // velocity, as a vector in local coordinates.
 void getAngularAccel(float* accelOut);
+
+// Returns the intertia tensor in a float[9] allocated by caller.
+void getInertiaMatrix(float* inertiaOut);
 
 private:
 struct Mass { float m; float p[3]; };
Index: source/src/FDM/YASim/yasim-test.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/yasim-test.cpp,v
retrieving revision 1.9.2.1
diff -p -u -r1.9.2.1 yasim-test.cpp
--- source/src/FDM/YASim/yasim-test.cpp 18 Dec 2006 21:32:56 -  1.9.2.1
+++ source/src/FDM/YASim/yasim-test.cpp 5 Jan 2007 17:13:44 -
@@ -103,6 +103,20 @@ int main(int argc, char** argv)
 float drag = 1000 * a->getDragCoefficient();
 float cg[3];
 a->getModel()->getBody()->getCG(cg);
+a->getModel()->getBody()->recalc();
+
+   float platypus_inertia[9];
+a->getModel()->getBody()->getInertiaMatrix(platypus_inertia);
+   // Due to the mix of units in Yasim, we get inertia matrix values
+   // in the most peculiar unit of lbs*m². But to keep the model
+   // developers clear from the asylum, we display one matrix in kg*m²
+   // and one in lbs*ft² instead:
+   float SI_inertia[9], lbsft2inertia[9];
+   for(int i=0;i<9;i++)
+   {
+   SI_inertia[i] = platypus_inertia[i]*0.4536;
+   lbsft2inertia[i] = platypus_inertia[i]*10.763;
+   }
 
 printf("Solution results:");
 printf("   Iterations: %d\n", a->getSolutionIterations());
@@ -111,7 +125,13 @@ int main(int argc, char** argv)
 printf("   Cruise AoA: %f\n", aoa);
 printf("   Tail Incidence: %f\n", tail);
 printf("Approach Elevator: %f\n", a->getApproachElevator());
-printf("   CG: %.3f, %.3f, %.3f\n", cg[0], cg[1], cg[2]);
+printf("   CG: x:%.3f, y:%.3f, z:%.3f\n\n", cg[0], cg[1], 
cg[2]);
+   printf("  Inertia [kg/m²]: %.3f, %.3f, %.3f\n", SI_inertia[0], 
SI_inertia[1], SI_inertia[2]);
+   printf("   %.3f, %.3f, %.3f\n", SI_inertia[3], 
SI_inertia[4], SI_inertia[5]);
+   printf("   %.3f, %.3f, %.3f\n", SI_inertia[6], 
SI_inertia[7], SI_inertia[8]);
+   printf("   [lbs/sqft]: %.3f, %.3f, %.3f\n", lbsft2inertia[0], 
lbsft2inertia[1], lbsft2inertia[2]);
+   printf("   %.3f, %.3f, %.3f\n", lbsft2inertia[3], 
lbsft2inertia[4], lbsft2inertia[5]);
+   printf("   %.3f, %.3f, %.3f\n", lbsft2inertia[6], 
lbsft2inertia[7], lbsft2inertia[8]);
 }
 delete fdm;
 return 0;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] patch for Yasim (printing out inertia tensor)

[Joacim Persson]

On Fri, 5 Jan 2007, Roy Vegard Ovesen wrote:


On Friday 05 January 2007 18:25, Joacim Persson wrote:

I screwed up again, didn't I?

How *do* I convert "metres per square feet" to "pounds per square feet"
really?


m/ft² -> lb/ft² ?
That does not make sense, or do you still mean  m² -> ft²?


Er, no mixed it up (again! ;):
Yasim usess a mix of unit systems: pounds for mass, but metres for lengths

So moment of inertia becomes "pounds per square metre", which doesn't make
anyone happy.

I'm quite sure my conversion to kg/m² is correct (the values I get looks
sane), but numbers in pounds, slugs, gallons, feet etc are about as
meaningful to me as if they were given in "yellow striped hedgehogs per
square prostethnic waterfalls".

...think it should be divided by about ten rather than multiplied. ...?-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] patch for Yasim (printing out inertia tensor)

[Joacim Persson]

I screwed up again, didn't I?

How *do* I convert "metres per square feet" to "pounds per square feet"
really?

Perhaps someone who is used to those weird bushel/pounds/gills units could
be kind enough to do a sanity-check and set it right if it's wrong. ;)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] patch for Yasim (printing out inertia tensor)

[Joacim Persson]

On Fri, 5 Jan 2007, Joacim Persson wrote:


The enclosed patch is for printing out the inertia matrix from the "yasim"
command line utility (yasim-test.cpp).


...except that I used the wrong conversion constant for m² -> ft². :P
(forgot to square it too)

New replacement patch enclosed.Index: source/src/FDM/YASim/RigidBody.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/RigidBody.cpp,v
retrieving revision 1.2
diff -p -u -r1.2 RigidBody.cpp
--- source/src/FDM/YASim/RigidBody.cpp  14 Aug 2006 21:59:44 -  1.2
+++ source/src/FDM/YASim/RigidBody.cpp  5 Jan 2007 17:13:43 -
@@ -204,4 +204,14 @@ void RigidBody::getAngularAccel(float* a
 Math::vmul33(_invI, v, v);   // v = invI*(tau + (omega X I*omega))
 }
 
+void RigidBody::getInertiaMatrix(float* inertiaOut)
+{
+// valid only after a call to RigidBody::recalc()
+// See comment at top of RigidBody.hpp on units.
+for(int i=0;i<9;i++)
+{
+   inertiaOut[i] = _tI[i];
+}
+}
+
 }; // namespace yasim
Index: source/src/FDM/YASim/RigidBody.hpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/RigidBody.hpp,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 RigidBody.hpp
--- source/src/FDM/YASim/RigidBody.hpp  10 Sep 2002 01:14:03 -  1.1.1.1
+++ source/src/FDM/YASim/RigidBody.hpp  5 Jan 2007 17:13:44 -
@@ -97,6 +97,9 @@ public:
 // Returns the instantaneous rate of change of the angular
 // velocity, as a vector in local coordinates.
 void getAngularAccel(float* accelOut);
+
+// Returns the intertia tensor in a float[9] allocated by caller.
+void getInertiaMatrix(float* inertiaOut);
 
 private:
 struct Mass { float m; float p[3]; };
Index: source/src/FDM/YASim/yasim-test.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/yasim-test.cpp,v
retrieving revision 1.9.2.1
diff -p -u -r1.9.2.1 yasim-test.cpp
--- source/src/FDM/YASim/yasim-test.cpp 18 Dec 2006 21:32:56 -  1.9.2.1
+++ source/src/FDM/YASim/yasim-test.cpp 5 Jan 2007 17:13:44 -
@@ -103,6 +103,20 @@ int main(int argc, char** argv)
 float drag = 1000 * a->getDragCoefficient();
 float cg[3];
 a->getModel()->getBody()->getCG(cg);
+a->getModel()->getBody()->recalc();
+
+   float platypus_inertia[9];
+a->getModel()->getBody()->getInertiaMatrix(platypus_inertia);
+   // Due to the mix of units in Yasim, we get inertia matrix values
+   // in the most peculiar unit of lbs/m². But to keep the model
+   // developers clear from the asylum, we display one matrix in kg/m²
+   // and one in lbs/ft² instead:
+   float SI_inertia[9], lbsft2inertia[9];
+   for(int i=0;i<9;i++)
+   {
+   SI_inertia[i] = platypus_inertia[i]*0.4536;
+   lbsft2inertia[i] = platypus_inertia[i]*10.763;
+   }
 
 printf("Solution results:");
 printf("   Iterations: %d\n", a->getSolutionIterations());
@@ -111,7 +125,13 @@ int main(int argc, char** argv)
 printf("   Cruise AoA: %f\n", aoa);
 printf("   Tail Incidence: %f\n", tail);
 printf("Approach Elevator: %f\n", a->getApproachElevator());
-printf("   CG: %.3f, %.3f, %.3f\n", cg[0], cg[1], cg[2]);
+printf("   CG: x:%.3f, y:%.3f, z:%.3f\n\n", cg[0], cg[1], 
cg[2]);
+   printf("  Inertia [kg/m²]: %.3f, %.3f, %.3f\n", SI_inertia[0], 
SI_inertia[1], SI_inertia[2]);
+   printf("   %.3f, %.3f, %.3f\n", SI_inertia[3], 
SI_inertia[4], SI_inertia[5]);
+   printf("   %.3f, %.3f, %.3f\n", SI_inertia[6], 
SI_inertia[7], SI_inertia[8]);
+   printf("   [lbs/sqft]: %.3f, %.3f, %.3f\n", lbsft2inertia[0], 
lbsft2inertia[1], lbsft2inertia[2]);
+   printf("   %.3f, %.3f, %.3f\n", lbsft2inertia[3], 
lbsft2inertia[4], lbsft2inertia[5]);
+   printf("   %.3f, %.3f, %.3f\n", lbsft2inertia[6], 
lbsft2inertia[7], lbsft2inertia[8]);
 }
 delete fdm;
 return 0;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] patch for Yasim (printing out inertia tensor)

[Joacim Persson]

The enclosed patch is for printing out the inertia matrix from the "yasim"
command line utility (yasim-test.cpp).Index: source/src/FDM/YASim/RigidBody.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/RigidBody.cpp,v
retrieving revision 1.2
diff -u -r1.2 RigidBody.cpp
--- source/src/FDM/YASim/RigidBody.cpp  14 Aug 2006 21:59:44 -  1.2
+++ source/src/FDM/YASim/RigidBody.cpp  5 Jan 2007 16:52:24 -
@@ -204,4 +204,14 @@
 Math::vmul33(_invI, v, v);   // v = invI*(tau + (omega X I*omega))
 }
 
+void RigidBody::getInertiaMatrix(float* inertiaOut)
+{
+// valid only after a call to RigidBody::recalc()
+// See comment at top of RigidBody.hpp on units.
+for(int i=0;i<9;i++)
+{
+   inertiaOut[i] = _tI[i];
+}
+}
+
 }; // namespace yasim
Index: source/src/FDM/YASim/RigidBody.hpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/RigidBody.hpp,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 RigidBody.hpp
--- source/src/FDM/YASim/RigidBody.hpp  10 Sep 2002 01:14:03 -  1.1.1.1
+++ source/src/FDM/YASim/RigidBody.hpp  5 Jan 2007 16:52:24 -
@@ -97,6 +97,9 @@
 // Returns the instantaneous rate of change of the angular
 // velocity, as a vector in local coordinates.
 void getAngularAccel(float* accelOut);
+
+// Returns the intertia tensor in a float[9] allocated by caller.
+void getInertiaMatrix(float* inertiaOut);
 
 private:
 struct Mass { float m; float p[3]; };
Index: source/src/FDM/YASim/yasim-test.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/yasim-test.cpp,v
retrieving revision 1.9.2.1
diff -u -r1.9.2.1 yasim-test.cpp
--- source/src/FDM/YASim/yasim-test.cpp 18 Dec 2006 21:32:56 -  1.9.2.1
+++ source/src/FDM/YASim/yasim-test.cpp 5 Jan 2007 16:52:24 -
@@ -103,6 +103,20 @@
 float drag = 1000 * a->getDragCoefficient();
 float cg[3];
 a->getModel()->getBody()->getCG(cg);
+a->getModel()->getBody()->recalc();
+
+   float platypus_inertia[9];
+a->getModel()->getBody()->getInertiaMatrix(platypus_inertia);
+   // Due to the mix of units in Yasim, we get inertia matrix values
+   // in the most peculiar unit of lbs/m². But to keep the model
+   // developers clear from the asylum, we display one matrix in kg/m²
+   // and one in lbs/ft² instead:
+   float SI_inertia[9], lbsft2inertia[9];
+   for(int i=0;i<9;i++)
+   {
+   SI_inertia[i] = platypus_inertia[i]*0.4536;
+   lbsft2inertia[i] = platypus_inertia[i]/0.3048;
+   }
 
 printf("Solution results:");
 printf("   Iterations: %d\n", a->getSolutionIterations());
@@ -111,7 +125,13 @@
 printf("   Cruise AoA: %f\n", aoa);
 printf("   Tail Incidence: %f\n", tail);
 printf("Approach Elevator: %f\n", a->getApproachElevator());
-printf("   CG: %.3f, %.3f, %.3f\n", cg[0], cg[1], cg[2]);
+printf("   CG: x:%.3f, y:%.3f, z:%.3f\n\n", cg[0], cg[1], 
cg[2]);
+   printf("  Inertia [kg/m²]: %.3f, %.3f, %.3f\n", SI_inertia[0], 
SI_inertia[1], SI_inertia[2]);
+   printf("   %.3f, %.3f, %.3f\n", SI_inertia[3], 
SI_inertia[4], SI_inertia[5]);
+   printf("   %.3f, %.3f, %.3f\n", SI_inertia[6], 
SI_inertia[7], SI_inertia[8]);
+   printf("   [lbs/sqft]: %.3f, %.3f, %.3f\n", lbsft2inertia[0], 
lbsft2inertia[1], lbsft2inertia[2]);
+   printf("   %.3f, %.3f, %.3f\n", lbsft2inertia[3], 
lbsft2inertia[4], lbsft2inertia[5]);
+   printf("   %.3f, %.3f, %.3f\n", lbsft2inertia[6], 
lbsft2inertia[7], lbsft2inertia[8]);
 }
 delete fdm;
 return 0;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference

[Joacim Persson]

On Wed, 3 Jan 2007, John Denker wrote:

 *) I spelled out "deg".  I tried putting the ° symbol in the
   xml file, but it complained of a parse error.  Using °
   didn't work, either. Any suggestions on how to encode symbols?


Not directly an answer to you question but here's a tip that may be useful
to you or others: I've recently switched to generating the xml config file
(for the ch47d project) (ab)using the C preprocessor and a Makefile.  So I
put comments in the source file I feed to cpp instead, using regular c/c++
comments or #if -- #endif's. I find that very convenient. But most of my
notes go, as plain prose, into a separate textfile.

(The main reason for that setup, however, is to avoid doing a mistake I've
done too many times before: adjusting common airfoil/rotorhead parameters
for only one rotor with something completely unflyable as a result. Now I
just #include the common parameters from one single file instead of
changing two identical instances everytime. I didn't investigate the matter
at depth, but I got the impression that there is no general include
function in the xml standard. Many xml parser implementations add that
functionality on top of xml though.)-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Gold mine of helicopter airfoil data

[Joacim Persson]

On Wed, 3 Jan 2007, Heiko Schulz wrote:

> Hi,
>
> Real nice. But from 1976 - newer one would be good
> too!

If there is a volume 2 somewhere...

Leo Dadone is a Boeing guy btw, so I suspect the 40-some listed airfoils
should at least cover the Boeing rotorcrafts up to 1977. Many of the
airfoils listed are regular NACA airfoils that probably are documented
elsewhere too. Nice to have them in one file though, even if it is a bit
big.

Now excuse me, I have to drool over the VR-7 and VR-8 data for a while. =)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Gold mine of helicopter airfoil data

[Joacim Persson]

Thought I'd share this find -- discovered it just now:
http://ntrs.nasa.gov/
Document-ID: 19770018207
Title: US Army helicopter design datcom. Volume 1 Airfoils
Author: Leo Dadone
Abstract:
This report contains airfoil data of interest for rotor
applications. The data is presented in the form of lift, drag, and
pitching moment coefficients and, in most cases, it covers the
complete Mach number range from low subsonic to supercritical flow
conditions. An introductory section presents airfoil data trends
and information pertaining to the source and usefulness of such
data.

The pdf is >19MB

No traces of a volume 2 at NTRS. Maybe there never was one.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Improved c172p autopilot

[Joacim Persson]

On Wed, 3 Jan 2007, Ralf Gerlich wrote:

> I'm confused. Does the KAP140 use the trim or not?

It does not use trims (i.e. trim tabs, usually) for controlling the
aircraft. The AP servos drive the control surfaces directly so the pitch
servo operates pitch, not pitch trim (tabs); just as the roll servo
operates on the ailerons, not the aileron trim tabs. (And there is no servo
operating the rudder or rudder trim tab for the kap140)

There is however an optional electric elevator trim function which is not
implemented in the FG kap140 model and that can (IRL) be manually operated
or automatic. See pp 3 -- 7 in the KAP140 Pilot Guide.  The figure on p. 7
in particular. There is a roll servo and a pitch servo.  The optional pitch
_trim_ servo shown in the figure would move the elevator trim tabs rather
than the whole elevator. (depending on aircraft design of course)

I suppose the pitch trim servo would actuate the same mechanisms as the
pilot uses for trim pitch, so even if the aircraft has some other physical
means for pitch trimming than tabs on the trailing edge of the elevator, it
would still be two different input points.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Improved c172p autopilot

[Joacim Persson]

On Wed, 3 Jan 2007, Ralf Gerlich wrote:

> Disabling joystick inputs alltogether should not be an option, except -
> perhaps - if you only disable a single axis. Assume that your AP is in
> ALT hold mode and you want to do turns.

You are right about that of course. And using a separate channel is also a
better idea. (And in some AP implementations, not the kap140, the AP is
disengaged if the controls are moved a certain amount or with a certain
force. But that's beside the kap140 issue.) Noice from the js should be
handled elsewhere: deadzone or filtering ...or simply bin old worn-out
joysticks with dodgy sensors. ;)

> OTOH if we're not that much after exact internal modelling, we might as
> well use the trim channel ;-)

The piloting of the aircraft, including AP, should be realistic. In this
case that involves adjusting the pitch trim (manually) -- why there are
warning lights for it on the kap140 panel (irl and in the sim) to inform
him/her that the pitch trim needs to be adjusted to avoid unpleasent
surprises when the AP is disengaged. So it isn't about internal modelling,
but rather external such. ;)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Improved c172p autopilot

[Joacim Persson]

On Wed, 3 Jan 2007, woodyst wrote:

> For the moment using trim for autopilot makes the fly more acurate because
> it does not interfere with input devices.

...kap140 controlling the aircraft via trim is not accurate regarding how the
kap140 works. :P  But you do point out a problem there: input device vs AP 
interference.  How about disabling joystick inputs altogether when the AP
is in control?

Speaking of kap140, has anyone applied the onliner-bugfix I posted a week
ago?  (dec 26th: ROL -> APR/GS mode broken; unless I've misunderstood the
function of the kap140 of course ;)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Yasim glider

[Joacim Persson]

On Tue, 2 Jan 2007, Maik Justus wrote:

>> So what's your plan here? Add optional /external/ control of a thruster?
>>
> Adding a hinch objects to YASim, which can be connected to a tow. The
> other end of the tow can be connected to a fixed position or an
> AI/MP-Object. The length of the tow can be modified (-> winch).

There may be problems with sampling interference here:

In an equilibrium, the force is the same at both ends of the wire.
(we will never reach an equilibrium)

If one aircraft accelrates/turns (which they will, of course) there will be
a change in force which (irl) will travel along the wire with a certain
speed (speed of sound for the material, I'd guess, for pure longitudinal
forces along the wire anyway), and so on back and forth.

The wire must have a property analoguos to the concept of "impedance" in
electronic engineering. Then there will be an eternal recalculating of
force at each end, which travels over the wire to the other, added to the
fdm calculation there and the new force vector value is sent back out on
the wire and added to the wire's own force calculations before it reaches
the other aircraft/cargo model, etc etc

Now, the time it takes for a wave to traverse along the wire to the other
end may be shorter than can be modelled even with the 120Hz default fdm
frame rate and, quite likely, shorter than the sampling rate in the current
MP-server system (10Hz?). We may run into a "jitter" similar to the
notorious gear jitter... Or forced to use wires that are unrealistically
"rubbery".


...
> Yes, but we need a cargo-fdm.

Any fdm engine that can take an external force into account can be used for
modelling cargo. (Could even use existing models: a ch53 can easily
airlift a bo105 or a light winged aircraft) A standard box-shaped shipping
container, a big log, or a section of a power line tower etc are all just
"aircrafts" with really lousy L/D ratios and no engines (on).

> Yes. But if it is released by one aircraft, the tow will be ignored by
> the other aircraft.

Anyway, my point was that the towing wire shouldn't be viewed as a simple
submodel of either the towed or the towing model since the towing wire can
be released at either end first, and then produce drag/weight force on only
the remaining aircraft, whichever model ends up with the wire. (The drag
from the line can be substantial. The woing lines they use for aerotowing
hang gliders with trikes, are even fit with a drag parachute to prevent the
line from snapping into the trike's propeller on release, or if the rear
weak link snaps.)

> Do you know, if this is already possible in Flightgear?

Well what do I know? ;)  But it seems to me this is really an issue of
architecture of all FG, perhaps more so more than fdm engine design.

> Yes, you can add a thruster and YASim can simulate glieders as it is.
> But with a very small patch (adding a glide angle to approach and
> cruise) you don't need the thruster fake any longer.

Alright, same thing but more convenient. ;)
(That's what we have computers for: computing tedious calculations that
we'd rather not be doing ourselves.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Yasim glider

[Joacim Persson]

On Tue, 2 Jan 2007, Maik Justus wrote:

> I thought the next sentence in my mail is the explanation:
>
> "But his is not the real aim. I want to add the ability to use ropes. To
> be used for winch as well as for aerotow."

The real challenge is to make it work over MP with a human piloting the
tow aircraft. (A winch or a towing ground vehicle could by all means
also be human controlled.)


So what's your plan here? Add optional /external/ control of a thruster?

Then it wouldn't matter if it's a towing aircraft being subject to a force
pulling backwards or a towed aircraft being subject to a force forward.
Same implementation. It would also work the same for helicopter sling
loads. Or towing with mobile ground vehicles.

But where would the simulation of the towing line go?  (Stretch, drag, bend,
weight, inertia... weak links? A winch wire or a pay-out line doesn't have
a constant lenght.) It's not a "dead" object. A towing line can be released
at either end, by the pilot at each end or by a snapping weak link at each
end. So it's not really a submodel of any of the objects at the ends of it.

I think the tow/airlift wire/line object should be it's own simulation
instance. -- ?

And of course, designing gliders per se doesn't require any patching of any
fdm backend. The yasim solver needs a thruster element for determining
drag, but the force from that would be the same fwd thrust produced from
sink rate + mass and the L/D ratio at best glide or min sink. (easily
calculated) L/D ratio and airspeed for best glide performance, and sink
rate /airpseed for minimum sink (at a respective weight) are normally
published data for gliders. Just pretend gravity is not perfectly vertical
when defining  and ...

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] kap140 bug+fix

[Joacim Persson]

Bug:
AP won't do GS arm (and GS lock) when switching to APR mode from ROL mode.

Fix:
In the last lines of function "apr_arm_from_rol" change:
-setprop(Locks, "roll-arm", "gs-arm");
+setprop(Locks, "pitch-arm", "gs-arm");

In Aircraft/c172p/kap140.nas and the identical Aircraft/c182/kap140.nas,
this is line 799. In Aircraft/pa-24-250/kap140.nas, it's line 840.
Assigning roll-arm with "gs-arm" doesn't seem to make any sense, so I guess
it's just a typo there.

(Why are there three copies of essentially the same file anyway? The pa24
version is extended with checks for power supply voltage.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Small problem with 787 ...

[Joacim Persson]

On Fri, 22 Dec 2006, Curtis Olson wrote:

> I experienced a small technical glitch in the 787 on climbout from KSFO ...
> picture at the following link:
>
> http://baron.flightgear.org/~curt/tmp/problem.jpg

=8-o

...terrorists placed a bomb onboard perhaps?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] chinook data (was ch53 ditto)

[Joacim Persson]

On Thu, 21 Dec 2006, Arnt Karlsen wrote:

> running iceweasel.  A pdf would be better here, vector format
> and no lossy compression.

Yes it would. Vectorise it, please.

NASA has a neat (linux) set of apps for viewing very large (ridiculously
large) bitmaps. It is available free for download from:
http://opensource.arc.nasa.gov/project.jsp?id=11

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] chinook data (was ch53 ditto)

[Joacim Persson]

Wim,
The "ch47" in cvs is only a concept demonstrator of a tandem helicopter.
Hardly any numbers there represent a real Chinook. I'm fiddling with
another configuration.

On Wed, 20 Dec 2006, wim van hoydonck wrote:


blade mass -> 111.6 [kg]


This is different from the blade mass I am using: 357 lbs ~= 162 kg
An upgraded blade perhaps? Composite material technology hasn't exactly stood
still in the last 20 years.



blade twist -> -9.14 [deg]


This is also different from the data I've got: -12° twist.
But from the B or C model and on, Boeing has been using assymetric airfoils
on the ch-47's. I'm not sure the -12° remains that under load...

My sources:
"CH-47 Theory of Operation" which can be downloaded (beware: >50MB!)
from: http://www.chinook-helicopter.com/Publications/Publications.html
(page "5-9", p. 232 in the pdf)
And a Boeing drawing of a somewhat inconventient size (6.6M):
http://www.chinook-helicopter.com/Drawings/Structure/Images/CH-47D_Drawing.jpg


and some mass & moment of inertia values:
mass -> 14968.6 [kg]
ixx -> 50386.3 [kg*m^2]
iyy -> 273536 [kg*m^2]
izz -> 257685 [kg*m^2]
ixz -> 19838.3 [kg*m^2]


Ah, thank you!
Now I only have to figure out how make use of inertia data in Yasim. ;)-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] chinook data (was ch53 ditto)

[Joacim Persson]

On Tue, 19 Dec 2006, Maik Justus wrote:
> Important info for the ch47d flight model. I had expected a large delta3
> effect.

Forgot to mention that the chinooks do however have lead-lag hinges which
may have a blade pitch coupling to it, I don't know (yet). We don't have
lead-lag hinges in the rotor calculations anyway. (yet -- nudge-nudge
wink-wink ;)

Speaking of delta-3, I saw a litterature reference giving a hint that
Boeing did perform experiments in the mid 60' with a delta-3 rotorhead, but
for some reason only on the forward rotor. I've found no evidence that this
ever was introduced in production models, not up to the D model anyway.

PS. I've finally figured out the LCT algorithm, from studying explicit data
on the B model. Flying perfectly level at 60kts now. (Also using wind
tunnel data for the fuselage drag at alpha=beta=0.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CH53e data

[Joacim Persson]

On Tue, 19 Dec 2006, Maik Justus wrote:


Important info for the ch47d flight model. I had expected a large delta3
effect. Can you point me to the point in the report, where you found
this info?



From the British ministry of defence:

http://www.mod.uk/NR/rdonlyres/DB72A687-551F-498C-A402-A015E9C1CDDB/0/chinook_boeing1c.pdf
(~2.5MB A report regarding the simulation of the accident. They mention
several times that although the software used for the simulation is capable
of taking delta3 into account, this is not used for the reason that there
is no delta3 on the chinook helicopter.)

Another little gem in the same collection (haven't seen this one before
myself):
http://www.mod.uk/NR/rdonlyres/8BF9CD63-D369-47AD-88A1-0117FEE32C01/0/chinook_boeing1b.pdf
(a few diagrams of output from the simulation which gives away some data about 
the
LCT algorithm -- it was 4°+4° after all. And Rotor thrust/torque in real
units.) Now I'm confused about the LCT again. 4° relative what? "their
respective masts"?? :P-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CH53e data

[Joacim Persson]

On Tue, 19 Dec 2006, Maik Justus wrote:
> One important point for the simulation: most rotors have a delta3 effect
> (this means: reducing the pitch with increased flapping angle). Do you
> know this parameter for the ch53e (or for other helicopter?)

I can only add that the CH-47D has no delta3 mechanism.

(Or at least not the RAF HC Mk2 version which is very similar to the D
version Chinook. Found that out just now from reading the RAF
Mull-of-Kintyre accident report more thoroughly. But presumably this goes
for all Chinook production models.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Periodic 'stutter' in FG

[Joacim Persson]

On Fri, 15 Dec 2006, leee wrote:
> Could a few other people give the SU-37 a bit of a run and see if they notice
> any SU-37 specific problems?

I've been buzzing the KSFO tower and downtown SF now back and forth at mach
1.5 for 15 minutes or so, until I had a little accident at too low altitude
-- couldn't notice anything peculiar with it. Sound and video runs fine.
This was with a plib cvs fg (a day or two old) and a likewise
recent data cvs.

(And the DR mode feels much more flyable now than last time I took the
Su-37 for a spin.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Periodic 'stutter' in FG

[Joacim Persson]

On Fri, 15 Dec 2006, leee wrote:

> Hmm... hadn't thought about trying different video drivers...  that wouldn't
> explain why some other aircraft don't display this problem though, or do you
> get it with all aircraft?

I fixed the problem here this evening the $$ way. Bought myself a new
(but cheap) card. I had finally dug out an old hard drive with the popular
game loader "windows" on from the growing pile of computer junk and tried
the gfs card with that: bluescreened on me on first attempt of running
anything 3D. (worked when the card was new) So it was a hardware fault in
my case. (Two electrolyte capacitors on the card looks suspicious)

>
> CONFIG_PREEMPT in kernels is optional.  This may be a different level of
> premption to the one that Koffman (who he?) refers to.

"Koffman's conditions" is an operating system theory concept.

If I remember them right now, a deadlock occur if and
only if we have:
1. "No preemption" (a resource cannot be taken from a process by force)
2. "mutual exclusion" (there is at least one resource that cannot be shared)
3. "Hold and wait" (a process can hold one resource while waiting for
another it also need to complete the task)
and the fourth iser...hmmm... oh yes (the most obvious condition):
4. "circular wait" (there is a chain of processe waiting for a recource
held by another process, formed in a loop of forever waiting processes:
deadlock)

Who Koffman was? That has slipped my mind completely. Some
operating system theorist obviously.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Periodic 'stutter' in FG

[Joacim Persson]

On Fri, 15 Dec 2006, leee wrote:

> Well, I've tried removing references to AI aircraft, including removing
> references to it from preferences.xml, ensuring that the VBlank nVidia
> settings are checked and also re-compiling my kernel without pre-emption but
> none of it seemed to make any difference - I still get the periodical pause
> despite reasonable frame rates.

I am (and many others are) experiencing the same phenomenon (and much worse),
but not just with your Sukhoi and not only in FG. Something's wrong with
the nvidia drivers or GL libs for linux (also reported for FreeBSD, don't
know about Solaris).

It may of course be different causes for the same symptom. There is not
infinite cpu or gpu power available, nor bus bandwidth (pci bus latency
timers?) nor memory (video or system such).

...a kernel without preemption? =8-o ("non-preemption" is one of Koffman's
four necessary and sufficient conditions for deadlock)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Modeling a Flexwing Microlight

[Joacim Persson]

On Fri, 8 Dec 2006, Stuart Buchanan wrote:

> - There is no trimming for different flight phases. Vertical speed is
> purely controlled by power.

Many trikes has a trim function, just like all non-trainer hang glider has
nowadays. (I know the Airborne trike we use for aerotowing has it.) This
trim is usually operated by a line, the trim line, which is drawn to the
speedbar (on a HG) or on a sidebar (on a trike) and most noticeably it
adjusts the tension of the cross beam (which is divided in two parts
connected with a hinge at the centerline).  (Compare with the "kick" or
sheet on a sailboat mainsail.) There are however more functions coupled
with the trim than cross beam tension. On kingpost HG's (like your trike),
there is something called "luff lines" connected to the trailing edge via
the kingpost, on the newer topless hg's there are "sprogs" at the wing tips
filling the same function. Luff lines and sprogs act like an elevator trim
under certain circumstances, and is primary a safety detail to prevent an
uncontrollable dive. The setting of those are also altered along with the
trim setting.

So the trim on a HG or trikes changes:

1. The camber of the whole wing. (cross beam tension) This affects L/D ratio,
stall speed.
2. Apex (follows from sail tension) and dihedral (not much).
3. The elevator trim function of sprogs or luff lines.

Your trike may have the cross beam fixed to the keel (can't tell by the
photo) and would then be a bit stiffer in handling (but more course stable)
than a hang glider with the trim fully loose, but with a floating cross
beam (i.e. not connected to the keel) as all hang gliders have today, the
first effect of moving the weight to one side (shifting the keel sideways
with respect to the cross-beam and wing tubes) is that the wing you move
away from gets less camber and the other gets more camber. This in turn
makes the outer wing tip fly a bit faster than the inner wing tip,
generating some rudder and aileron effect. A hang glider with a
non-floating cross beam is rather slow in turns.

This difference in camber between the wing halves is less the more the
pilot tighten the trim.  So we can add a fourth function of the HG trim:

4. Sets the amount of rudder and aileron effect from shifting weight
sideways -- indirectly by adjusting the cross beam tension and thus the
difference in tension of the trailing edge on each wing half.

In short: when circling thermals or coming in for landing, you release the
trim, when flying straight between thermals you tighten the trim (fully or
to a wanted trim speed).

But that is perhaps a bit beside the point -- a trike pilot doesn't have to
worry much about L/D ratio, and there is plenty of weight for steering with
pure CG shift on a trike.

> So, should I use YASim or JSBSim for this project?

Or larcsim? The only hang glider model in FG (airwaveXtreme150, a larcsim
model) has an invisible motor+propeller attached to it, so we could call it
"a trike". It doesn't have a trim function anyway. (I'm quite sure the
original has.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FW: JSBsim and low rpm engines (AN-2)

[Joacim Persson]

On Thu, 9 Nov 2006, Jon S. Berndt wrote:

> The engine stuff can't (at least for now) be removed from JSBSim, in theory
> or in principle. JSBSim is a drop-in dynamic library for flight dynamics,
> which includes all normally available subsystems that provide forces and/or
> moments on the aircraft. It can be run on its own without flightgear, or in
> other simulations/frameworks. Even if we wanted to remove the propulsion
> subsystem (which we don't), it would break other peoples' applications.

I'm not suggesting it should be thrown away. (It probably covers 99% of the
cases as it is.) I'm suggesting an optional external engine model: an
interface. (With a proper object-oriented design that should be trivial
to provide: wrapping it in an interface class)

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Antonov AN-2 ready for download

[Joacim Persson]

On Thu, 9 Nov 2006, Yurik V. Nikiforoff wrote:
> After start sim, aircraft have full load of fuel and cargo, so plane have
> weight about 5000 kg (11000lbs).

Ah! That explains. ;)

(I wondered why I couldn't get a 3.5 m/s climb)

This may cause problems in high altitude settings or low pressure weather
situations with --real-weather-fetch. I assume it can't take off with 5
tons under all circumstances?

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] JSBsim and low rpm engines (AN-2)

[Joacim Persson]

On Wed, 8 Nov 2006, Jon S. Berndt wrote:

> Actually, yes, it is. Dave Culp submitted a change to *JSBSim* CVS on
> October 16 that had this change in it, among others:
>
> StarterHP = sqrt(MaxHP) * 0.2;

Yes I saw that on the CVS, but the engine idle rpm parameters are also
still hard-coded.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Antonov AN-2 ready for download

[Joacim Persson]

me wrote:
> There is something funny with the propeller pitch control.

The cause of that is the lines defining minrpm and maxrpm in the propeller
definition file for An-2. Only fixed-speed propellers should have a minrpm
and maxrpm setting. See the test for fixed pitch/fixed speed/variable pitch
propellers in src/FDM/JSBSim/models/propulsion/FGPropeller.cpp,
FGPropeller::GetPowerRequired(void)
The test is basically "if minrpm == maxrpm (i.e. zero, not set), then it's a
variable pitch prop". The default value for either is 0 in the constructor.
(Not sure how one would go about to define a fixed speed prop where the rpm
cannot be varied the slightest.)

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] JSBsim and low rpm engines (AN-2)

[Joacim Persson]

On Wed, 8 Nov 2006, Berndt, Jon S wrote:

> Regarding low RPM engines: I'm not sure, but I think this has been
> addressed in the version of JSBSim that is in JSBSim CVS.

Nope, it isn't. :P

There is a similar hard-coded value in FGPropeller.cpp, 
FGPropeller::GetPowerRequired()
Line 240, regarding operation of the pitch mechanism. (Can't assume that
every variable pitch mechanism works the one and same way.)

My feeling is that all that logic should be up to the model designer to
implement, for FG that would be done in nasal scripts. In every model with
an rpm meter, the rpm is monitored constantly anyway, for displaying the
value on the meter and so forth, so the logic about at which rpm the engine
stalls (or the propeller pitch mechanism fails) could just as well be
handled there.

Perhaps engine simulation should be separated from the flight dynamic
calculations altogether? (the propellers must stay though) People may
introduce all sorts of weird engines in aircrafts: stirling or wankel
engines, rubber bands, electric motors and batteries, pigeons of burden...
...coal fired steam engines? (ok, maybe not). And you end up supporting a
plethora of engine principles, when all you need to know is mass, shaft
power for the propeller and torque/gyroscopic effects from the engine.
(anything else?)

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Antonov AN-2 ready for download

[Joacim Persson]

On Wed, 8 Nov 2006, Chris Metzler wrote:

> Heh.  Was getting my speed from the property browser.

I was a bit worried that you were stalling it around. =)

> Well, 70 knots is about 130 km/h, so I guess that's right.  It seems
> *so* slow though; I was in constant fear of stalling if I did anything
> interesting . . .although I just read the Wikipedia page, and it
> appears that's a needless fear.

You must mean this (from http://en.wikipedia.org/wiki/Antonov_An-2):
If the engine quits in instrument conditions (blind flying when you
can't see the ground) or at night, the pilot should pull the
control column full aft (it won't stall) and keep the wings level.
The leading-edge slats will snap out at about 40 mph (64 km/h), and
when the airplane slows to a forward speed of about 25 mph [40
km/h], the airplane will sink at about a parachute descent rate
until the aircraft hits the ground.
(That actually works in the sim)

Yurik:
There is something funny with the propeller pitch control. I can't get it
to the minimun 17" pitch except with idling engine. (looking at
/engines/engine/thruster/pitch) And at start-up, the propeller is set to
max pitch. (Pitch control may go backwards and depends on engine rpm)
Perhaps that explains the start-up problems with a 136" prop? It acts like
some kind of constant-rpm propeller. But the AV-2 is a plain variable pitch
propeller -- I mean the pilot sets the pitch directly? No fancy stuff there?

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] JSBsim and low rpm engines (AN-2)

[Joacim Persson]

On Wed, 8 Nov 2006, Yurik V. Nikiforoff wrote:

> Yes, It works, but I can't set diameter of propeller by data sheat from flight
> manual. Engine can't start, if I set propeller greater then 110'. But real
> AV-2 propeller have 136' diameter.

Found this kludge in JSBsim:
FGPiston::doEngineStartup()
in src/FDM/JSBSim/models/propulsion/FGPiston.cpp,
line 351 and on:
if (!Running && spark && fuel) {  // start the engine if revs high 
enough
if (Cranking) {
  if ((RPM > 450) && (crank_counter > 175)) // Add a little delay 
to startup
Running = true; // on the starter
} else {
  if (RPM > 450)// This allows us to 
in-air start
Running = true; // when windmilling
}
  }
and further down:
} else if ((RPM <= 480) && (Cranking)) {
   Running = false;
 }


So engine parameters are hard-coded in JSBsim...
But there is a min rpm setting in the engine definitions -- that ought to be
used here.

Isn't there another aircraft model that can't idle properly? I think it is
either the Spitfire or the Mustang. It stalls if it's left on idle too
long.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Antonov AN-2 ready for download

[Joacim Persson]

On Wed, 8 Nov 2006, Chris Metzler wrote:

>
> It's a pretty A/C.  I started and took off with no problem, but was never
> able to get the plane above a speed of about 70 knots while holding
> my altitude.  Does that seem right?

The instrumentation is metric in Russian aircrafts -- sure you weren't doing
just 70 km/h? ;)
(no flaps, 900 mmHg --> takeoff at 110 km/h, climbout at 140 km/h, works
for me anyway.)

I suspect the scaled down propeller (to make the starter working) may have a
price in thrust...

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Antonov AN-2 ready for download

[Joacim Persson]

On Wed, 8 Nov 2006, Yurik V. Nikiforoff wrote:

> There is one problem around it. Power of starter not enough for spin engine
> shaft with big propeller - as I understand, this is JSBsim limitation. I read
> about it in devel list, but fix not ready yet. Cause this limitation,
> inertial starter may work unstable.

Works for me anyway. I just followed the instructions on the screen.

A friend of mine showed me a film clip he took himself of the starting
up procedures of an AN-2. The owner of the aircraft, who was starting it
up, is a guy who is blind since birth and whose passion in life is loud
noices and engines, preferably in combination. Apart from the AN-2 he
has a small collection of old aircraft engines and a big ship engine in the
yard which he on occasions starts up and make loud noices with just for the
fun of it. So even a blind man can start up an AN-2.

But I noticed that there is a 3D cockpit (without instruments) in the
model, viewable from the outside. This however doesn't appear in the
cockpit view for me. Is that switched off intentionally, by mistake, or has
it something to do with my rendering setup?

And regarding manuals for the aircraft: Since this is the most manufactured
aircraft in the world, there ought to be manuals for it in plenty of other
languages than Russian. (or Ukrainian -- The Antonov factory is located at
UKKM near Kiev in Ukraina. Zoom in on the satellite image on the flightgear
MP server map or google earth, and you can spot another famous Antonov
aircraft standing on the apron: the AN-225)

I found one translation to English (from Polish, they say) of the AN-2
manual here:
http://www.tailwheel.nl/airplanesal/antonov2/manuals/index.html
But before you all download the 36M pdf file: unfortunately it is passworded
-- no mentioning of that on the web page. (not that pdf encryption is very
strong...)

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] FGAIManager::getModel()

[Joacim Persson]

I've got the following messages (from within plib) recently:
fgfs: ssgBase.cxx:78: virtual ssgBase::~ssgBase(): Assertion `refc == 0' failed.

Spurious bug; hard to trigger at will. You have to swing a fresh dead mouse
from the mousetrap under the sink over your head whilst chanting "Oh Bug of
Darkness! Reveal thyself!" (and that only works on haloween)

Something is being deleted while still referenced. (Doesn't seem to be
plib's fault. I haven't even tried to build an osg version yet.)

But tonight I managed to catch it in gdb (as well as the notorious sink
mouse). Backtrace follows below.

While investigating this I noticed these lines in src/AIModel/AIManager.cxx
in method ssgBranch * FGAIManager::getModel(const string& path) (line 262)

...(while iterating over all loaded models):
   if (i->getNumRefs() == 1)
 {
   i = loadedModels.erase(i);
   //cerr << "[ Deleted ]" << endl;
 }
   else
 {
   i++;
   //cerr << endl;
 }


Does this mean what I think it does?: "if referenced by just one -- then
what the heck, let's erase it!" Looking at the backtrace it seems the task
was to add a new aircraft in the MP scene. Why erase anything.

But the call to ::getModel() looks funny too: the argument is NULL


The backtrace:

Chat [Platon] Syd is now online, using

Chat [Platon] Aircraft/Aerostar-700/Models/aerostar.xml

fgfs: ssgBase.cxx:78: virtual ssgBase::~ssgBase(): Assertion `refc == 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 28136)]
0x404ccd81 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x404ccd81 in kill () from /lib/libc.so.6
#1  0x40039681 in pthread_kill () from /lib/libpthread.so.0
#2  0x400399fb in raise () from /lib/libpthread.so.0
#3  0x404ccb14 in raise () from /lib/libc.so.6
#4  0x404ce05d in abort () from /lib/libc.so.6
#5  0x404c600f in __assert_fail () from /lib/libc.so.6
#6  0x086591c4 in ~ssgBase (this=0xc603ce0) at ssgBase.cxx:88
#7  0x0866e2dd in ~ssgTexture (this=0xc603ce0) at ssgTexture.cxx:148
#8  0x085d553d in ~SGShaderAnimation (this=0xc66da28) at shadanim.cxx:621
#9  0x08656999 in ssgDeRefDelete (s=0x4003eff4) at ssg.cxx:92
#10 0x08659169 in ~ssgBase (this=0xc90ce58) at ssgBase.cxx:75
#11 0x0865d5a2 in ~ssgEntity (this=0xc90ce58) at ssgEntity.cxx:52
#12 0x08659e5a in ~ssgBranch (this=0xc90ce58) at ssgBranch.cxx:59
#13 0x08656999 in ssgDeRefDelete (s=0x4003eff4) at ssg.cxx:92
#14 0x0865a076 in ssgBranch::removeKid (this=0xcaf1b70, n=0) at ssgBranch.cxx:97
#15 0x0865a10a in ssgBranch::removeAllKids (this=0xcaf1b70) at ssgBranch.cxx:112
#16 0x08659e47 in ~ssgBranch (this=0xcaf1b70) at ssgBranch.cxx:59
#17 0x08656999 in ssgDeRefDelete (s=0x4003eff4) at ssg.cxx:92
#18 0x0865a076 in ssgBranch::removeKid (this=0xc889d60, n=0) at ssgBranch.cxx:97
#19 0x0865a10a in ssgBranch::removeAllKids (this=0xc889d60) at ssgBranch.cxx:112
#20 0x08659d47 in ~ssgBranch (this=0xc889d60) at ssgBranch.cxx:59
#21 0x0866627e in ~ssgSelector (this=0xc889d60) at ssgSelector.cxx:56
#22 0x08670856 in ~ssgRangeSelector (this=0xc889d60) at ssgRangeSelector.cxx:57
#23 0x08656999 in ssgDeRefDelete (s=0x4003eff4) at ssg.cxx:92
#24 0x0865a076 in ssgBranch::removeKid (this=0xecaaa48, n=10) at 
ssgBranch.cxx:97
#25 0x0865a10a in ssgBranch::removeAllKids (this=0xecaaa48) at ssgBranch.cxx:112
#26 0x08659e47 in ~ssgBranch (this=0xecaaa48) at ssgBranch.cxx:59
#27 0x08656999 in ssgDeRefDelete (s=0x4003eff4) at ssg.cxx:92
#28 0x0865a076 in ssgBranch::removeKid (this=0xde78a58, n=0) at ssgBranch.cxx:97
#29 0x0865a10a in ssgBranch::removeAllKids (this=0xde78a58) at ssgBranch.cxx:112
#30 0x08659d47 in ~ssgBranch (this=0xde78a58) at ssgBranch.cxx:59
#31 0x08659985 in ~ssgBaseTransform (this=0x0) at ssgBaseTransform.cxx:49
#32 0x0866e836 in ~ssgTransform (this=0xde78a58) at ssgTransform.cxx:52
#33 0x08656999 in ssgDeRefDelete (s=0x4003eff4) at ssg.cxx:92
#34 0x0865a076 in ssgBranch::removeKid (this=0xc70de40, n=0) at ssgBranch.cxx:97
#35 0x0865a10a in ssgBranch::removeAllKids (this=0xc70de40) at ssgBranch.cxx:112
---Type  to continue, or q  to quit---
#36 0x08659e47 in ~ssgBranch (this=0xc70de40) at ssgBranch.cxx:59
#37 0x08656999 in ssgDeRefDelete (s=0x4003eff4) at ssg.cxx:92
#38 0x0865a076 in ssgBranch::removeKid (this=0xc5d2548, n=0) at ssgBranch.cxx:97
#39 0x0865a10a in ssgBranch::removeAllKids (this=0xc5d2548) at ssgBranch.cxx:112
#40 0x08659d47 in ~ssgBranch (this=0xc5d2548) at ssgBranch.cxx:59
#41 0x08659985 in ~ssgBaseTransform (this=0x0) at ssgBaseTransform.cxx:49
#42 0x0866e836 in ~ssgTransform (this=0xc5d2548) at ssgTransform.cxx:52
#43 0x080b3269 in ssgSharedPtr::put (this=0x4d19e7c8) at 
ssgSharedPtr.hxx:85
#44 0x085187a8 in std::vector >::erase 
(this=0xb1350cc)
 at ssgSharedPtr.hxx:43
#45 0x085178fc in FGAIManager::getModel (this=0xb1350c0, [EMAIL PROTECTED]) at 
AIManager.cxx:273
#46 0x08519b64 in FGAIBase::load3DModel (this=0xefb7668, [EMAIL PROTECTED], 
[EMAIL PROTECTED],
 prop_root=0xc61d538, si

Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft

[Joacim Persson]

On Tue, 8 Aug 2006, Lee Elliott wrote:

> I think there's now a patch in for the engine problem - don't
> know if it fixes everything though.

Well it changed the behaviour somewhat. No more negative FF et al values.
It still accelerates like mad in extreme turns but now we get a SIGSEGV
clue. I got this SIGSEGV three times in a row in the same manner as for the
negative FF effect, so it seems to be reproducable.

#1 (below) is a call to localWind for the thruster calculations, only the 
thruster
altitude is NAN. The altitude comes from the lines just
before the for-loop. (yasim::Model::initIteration, Model.cpp line 100 and on)
   // Need a local altitude for the wind calculation
   float lground[4];
   _s->planeGlobalToLocal(_global_ground, lground);
   float alt = Math::abs(lground[3]);

"_global_ground" are all NAN:s too. But I think by then, my insane turns had
become insane loopings. (Hard to tell with the view flipping around like
that.) I can't see where the NAN value of _global_ground came from, from a
stack backtrace, so the lead ends there.

On the other hand it's perfectly reasonable that altitude becomes a NAN
under those circumstances -- the aircraft bloody should disintegrate under
that kind of stress. So maybe it isn't a bug after all, rather a realistic
simulation of a massive structural failure due to severe overspeed and
exceeded G limit. ;)  ("Altitude?" ...of debris and fumes you mean?)


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9871)]
0x0825a3b8 in yasim::Turbulence::getTurbulence (this=0xa806678, loc=0x0, 
alt=nan(0x40),
 up=0xbfffed60, turbOut=0xbfffedb0) at Turbulence.cpp:100
100 static inline float c2fu(unsigned char c) { return (c+0.5)*(1.0/256); }
(gdb) bt
#0  0x0825a3b8 in yasim::Turbulence::getTurbulence (this=0xa806678, loc=0x0, 
alt=nan(0x40),
 up=0xbfffed60, turbOut=0xbfffedb0) at Turbulence.cpp:100
#1  0x0824fcb5 in yasim::Model::localWind (this=0x9c1222c, pos=0xbfffee40, 
s=0x9c1223c,
 out=0xbfffee30, alt=nan(0x40)) at Model.cpp:544
#2  0x0824e923 in yasim::Model::initIteration (this=0x9c1222c) at Model.cpp:111
#3  0x0824eb00 in yasim::Model::iterate (this=0x9c1222c) at Model.cpp:163
#4  0x08244baa in yasim::FGFDM::iterate (this=0x9c12228, dt=0.0083377) at 
FGFDM.cpp:92
#5  0x0823dab7 in YASim::update (this=0xa92fae0, dt=0.01524188350679) at 
YASim.cxx:217
#6  0x080520bd in fgUpdateTimeDepCalcs () at main.cxx:163
#7  0x08052cb6 in fgMainLoop () at main.cxx:488
#8  0x08087492 in GLUTidle () at fg_os.cxx:124
#9  0x400a5929 in __glutRegisterEventParser () from /usr/X11R6/lib/libglut.so.3
#10 0x400a60ad in glutMainLoop () from /usr/X11R6/lib/libglut.so.3
#11 0x0805582b in fgMainInit (argc=2, argv=0xb464) at main.cxx:1021
#12 0x08051a86 in main (argc=2, argv=0xb464) at bootstrap.cxx:203


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft

[Joacim Persson]

On Tue, 8 Aug 2006, Lee Elliott wrote:


Thanks for posting this observation - this is clearly a bit wacky
(not that accelerating w/o +energy wasn't) - can you reproduce
it?


Now that I tested it again, I saw however that the FF number didn't fall
over from a high number to a negative, but decreased to zero first. Same
goes for N1. But it happens quite suddenly.

KSFO "Fair weather", Noon. 2D mini-panel on. Full throttle (no AB, no flaps
or slats). Take-off. Gear up and climb to 1000'. Bank 90° and pull the
stick all the way back. After a while the engine sound suddenly changes to
a low thunder and not only FF goes negative, but so does N1 and EGT.  (I
don't think N2 did though) Tank fills up and overfills quickly. FF is
*very* negative. The number runs off-screeen. If you get too much altitude
the phenomenon stops. Stay low; below 5000', at 1000'
or so ...without crashing into anything -- which isn't that easy to avoid in
70G mach 3 turns. If you ease off throttle, you get the reported phenomenon
with insane speed instead. (mach 8 and 300G). AoA seems to stay at about
16°.

Apparently the "magical energy" doesn't come from increased mass -- FF is
near zero (and positive) with zero throttle and mass doesn't increase. My
guess is that this is a bug in the yasim jet engine code somewhere. One of
these one-liners that are so hard to find. ;) But at least it's easy to
reproduce.-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft

[Joacim Persson]

On Fri, 4 Aug 2006, Curtis L. Olson wrote:
> Based on my understanding of YASim, this has to be some sort of bug in
> the core yasim code since it's getting energy from nowhere.  Might be
> some sort of numerical/roundoff issue, perhaps some of the code in YAsim
> makes assumptions/simplifications that start to break down at extremely
> high alpha angles?

I've seen the fuel flow meter (2D panel on) go *negative* at supersonic
speed and extremely high G turns (like 50G and beyond) at low altitude.  It
actually fills up the tank. ;) So it do seem to be some sort of
type/typecast mixup.  (Magically add mass at speed and you increase kinetic
energy.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Flightgear's best kept secret?

[Joacim Persson]

Maybe I missed it, but I didn't get any hits (except from a few messages on
fg-user's list) on a site search on the FG homepage for "kelpie", "fgfp"
nor "fgflightplaner", here's the link:

https://sourceforge.net/projects/fgflightplanner/

This is IMHO a pretty impressive app for IFR flight planning (aimed for
Flightgear) which certainly deserves to be mentioned on the FG link page -- ?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ASI: YASim & Systems/pitot bug ?

[Joacim Persson]

On Mon, 17 Jul 2006, Melchior FRANZ wrote:


/orientation/side-slip-*


So, as you didn't bother to write a whole sentence and leave the
interpretation to the reader, which I find quite annoying, is it
the following what you are trying to say: YASim is right, (airspeed-kt)
is *not* meant to be forward-speed and has to be interpreted together
with the side-slip angle, and it's really a bug in Systems/pitot.cxx
only, because it isn't doing that?

Or was it just an accident with your email program?


I'm trying to help you solve a problem and you're biting my head off. But
hey, it's Monday so knock yourself out. ;) (I assumed you were proficent in
basic trigonometry -- why I didn't bother to go into further details on how
to tell the difference from forward and backwards flight using a sideslip
angle value.)

Think about this way: Why should "airspeed" (true, not indicated by a pitot
or other device) be visavi a particular direction of the aircraft in the
sim (in /general/)?

What shows up on the instrument depends on the design and placement of the
probe. Obviously, there is no general formula there which will fit
every possible simulated aircraft model, so it's a job for the model
designer to create a realistic instrument for the aircraft in question.

Sideslip is of course not the only factor affecting the indicated value
from the pitot, but it's a start.

What I wonder now is how airspeed is measured, techincally, on aircrafts
like the Harrier -- or the Chinook. Do they have extra pitot tubes pointing
360° around? Since the Chinook has a speed limit of 50kts when flying
backwards, it better show up on some instrument on the dashboard so the
pilot can respect the backward flight speed limit. (According to the pilots
it's even possible to do an ILS departure on autopilot flying backwards with
it.)
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ASI: YASim & Systems/pitot bug ?

[Joacim Persson]

On Mon, 17 Jul 2006, Melchior FRANZ wrote:

> Seems that there are two bugs that make the bo105 ASI show
> positive speeds when flying backwards:
>
> 1. YASim delivers a positive "/velocities/airspeed-kt" on backward
>   flight.

> The second is easy to fix, but I have no idea about the first.

/orientation/side-slip-*


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CH53 main rotor not producing any torque.

[Joacim Persson]

On Tue, 4 Jul 2006, Josh Babcock wrote:

>
> This helo def does not seem to be producing any main rotor torque.

Adjust the poweratpitch_0 parameter. (on tail rotor too)

Those seven 11m long blades probably cost a bit more than 53kW to turn at
185 rpms even at zero pitch. =)

But where do one find real data for that? :P  Checklists perhaps?  -- torque
readouts on the panel during start up procedures?

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] yasim heli solver, CG for Z-axis

[Joacim Persson]

On Mon, 3 Jul 2006, Maik Justus wrote:


All effects I have only tested with the bo. But I will check everything
with the ch47 after finishing the coding. Please send me your ch47
config (or is it in cvs?). Probably there are some wrong signs for
clockwise rotating rotors. But the sign of the torque seems to be
correct; if not the ch47 would not be flyable.


Attached the yasim config file here (in case anyone else wish to try it too),
plus a readme.txt with some data I gathered about the aircraft so
far.

This configuration is not tested /without/ the patch to
::solveHelicopter(). It will most likely behave very differenly (and
possibly severly instable) with an unpatched fgfs. It can't reach cruise
speed with the modified solver (too much drag).

Longitudal cyclic pitch trim is set manually for both rotors via the
/engiges/engine[0]/propeller-pitch property. (simple 0--4° fwd on both
rotors. Doesn't seem to have much effect though.)


Oh and I use an inner payload set by a property from the menu.

Internal cargo
0
27000
  

...could use more of them to trim the CG during test flights.



  




  



  
  
  
  
  
  
  



  
  
  
  
  
  
  




























 
  
  


 
  
  



 
  
  
  


 
  
  
  




 
  



 
 
 






 
 
 

 




Datum used: x=0 at tip of pitot tube in the nose. (See Boeing drawing)

CG limits and calculations, see chapter 6 in TM 1-1520-240-10 (Operator's
manual) "station 328" at x=-8.33m is a good aim for CG
(for max speed and gross wgt)

Boeing drawing (dated year 1977) states:
(with reference to datum line between rotors at station 331")
Empty: 9.9 in aft, i.e. 331+9.9=340.9" (or x=-8.66 m)
Most fwd (33000lbs gross weight): 23.1" fwd, 331-23.1=307.9", (x=-7.82m)
Most aft (33000lbs gross weight): 12.0" aft, 331+12=343" (x=-8.71 m)
Gross wgt has been increased since 1977, to 5lbs. (engine upgrade etc)

Values for Z axis CG not yet found. Measured from drawing, for empty is
about 20" above datum, i.e. z=0.51m
Tanks are located with centre about 0.5m below datum. (Exact numbers in
Operator's manual)

NB! "Empty" is very empty. Not including various standard equipment.

Data from Boeing drawing for CH-47D model:
Blade pitch range for fwd rotor: -19.3 to 39.3
Blade pitch range for aft rotor: -22.5 to 36.2
(not sure how to use this information)

Blade twist: 12°
(not yet implemented in the FDM engine)

Flap hinge at radius: 8"
Lead-lag hinge at radius: 29.5"
(both with dampers)

Coning stop angle: 30°
Droop stop fwd rotor: -4.75°, aft: -5.75° "in flight" (-1.5° "static"?)
(there are more numbers on the drawing, not sure what they mean. The
droop stops are retracted somewhat when rotors are operating.)

Collective pitch (thrust): 1 to 18°
(i.e. /both/ rotors -- ?)
Ground detent for thrust lever: 3° (to avoid droop stop pounding)
Normal rotor rpm: 225
Autorotation max rpm: 244 
Forward rotor shaft leans forward 9° (tan(9°) yields ~0.1584 for nx
Aft rotor shaft leans forward 4° (tan(4°)= 0.0699


The Chinook is equipped with dual "Advanced Flight Control System", AFCS.
The AFCS controls, amongst other things, "longitudal cyclic trim", LCT.
(Which in Yasim means adjusting CYCLICELE on each rotor. Elevator on a tandem
helicopter is set by using differential "collective" between fwd and aft
rotor.)

CH47 Theory of Operations, page 11-5:
19. Longitudinal Cyclic Trim
Reduces flap-back to relieve bending stresses particularly on
rear rotor shaft.  In its automatic mode of operation, airspeed
and altitude signals are processed by the AFCS units and used
to position the two LCP actuators; the forward is controlled by
the No. 1 AFCS unit, the aft by the No. 2 AFCS. When the
aircraft clears the ground, the actuators retract from their
ground position. At sea level, beyond 60 knots, the forward and
aft actuators remain retracted, positioning the rotor disc
planes relative to their masts by 1.2° and 3.25° respectively.
From 60 knots to 150 knots, the actuators increase cyclic pitch
linearly to 4° forward on both rotors. With increasing
altitude, the LCT program is advanced. Provided that the AFCS
units are receiving electrical power, LCT automatic operation
continues. Driving signals are routed through the AUTO/MAN
switch on the AFCS panel.  Setting the switch to MAN
disconnects signals from both AFCS units and permits manual
operation of the LCT.

AFCS to be implemented. Meanwhile, manual LCT can be set using the
propeller pitch control. Not clear if the disc plane positions below 60kts
means they are leaning fwd or aft or one of each, nor what their positions
are on the ground. But from 150kts and above (and above some unknown
altitude, according to one pilot: in a hover at atmospheric altitude of
15000 feet, or less) both LCP actuators are fully extended:

Re: [Flightgear-devel] YASim vstab question

[Joacim Persson]

On Mon, 3 Jul 2006, Josh Babcock wrote:

> Joacim Persson wrote:
>
>> Or translate the rotor equations to jsbsim -- ?
>
> It always seemed odd that YASim should be the one to have rotary
> support. The whole solver idea just doesn't seem to fit at all. Lookup
> tables however work great for helos, you just have to calculate each
> blade separately and add it all up.

..how about Fourier first? (have phase shifts in the tables rather than
angular position of each blade)

But it would take a separate app to get the data from rotor specifications,
or maybe that could be calculated at start-up. Something like Datcom for
rotors.

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] yasim heli solver, CG for Z-axis

[Joacim Persson]

On Mon, 3 Jul 2006, Maik Justus wrote:

> If you put the stick forward or backward there should be a yaw effect.
> With the bugfix you have to cancel the  torque generated by fuselage and
> airspeed by putting the stick backward. This could be the cause for the
> yaw. (Or dou you get the yaw moment with torque off?)

No not with notorque="1" on the rotors.
But from time to time I've experienced the following:
*start fgfs
*start the rotors
*when rotor rpm is stable and I try to take off, the aircraft starts
spinning left, impossible to control.
*quit
*restart and (sometimes, sometimes not) the problem is gone, without
modifying the config file.

I've noticed that sometimes both rotors has yaw=-0.3 or so, when
parked on the ground, as if the sign on the torque is wrong on one rotor.
(probably the aft) But I'm sure there are many mysteries with helicopters
which yet haven't been revealed to me. =)

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] YASim vstab question

[Joacim Persson]

On Mon, 3 Jul 2006, Maik Justus wrote:

>> We could on the other hand let the model designer set and tweak the
>> fuselage Cd manually in the config file.
>>
> That would be the easier way. Maybe it make sense to look, which results
> the solver get for different airplanes.

...faking a wing from rotor data and let ::solver() chew on it perhaps?

(I have a rough idea of what drag the chinook fuselage has; this can be
derived from cruise pitch and the algorithm for the LCT. But that's not
the general solution.)

Or translate the rotor equations to jsbsim -- ?

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] YASim vstab question

[Joacim Persson]

On Sun, 2 Jul 2006, Maik Justus wrote:
> src/FDM/YASim/airplane.cpp in function void Airplane::solveHelicopter()
> from
>applyDragFactor(Math::pow(15.7/1000, 1/SOLVE_TWEAK));
>applyLiftRatio(Math::pow(104, 1/SOLVE_TWEAK));
> to
>applyDragFactor(Math::pow(1, 1/SOLVE_TWEAK));
>applyLiftRatio(Math::pow(1, 1/SOLVE_TWEAK));

Actually, that won't work. :P

The idea is that the solver shall determine Cd (and other parameters)
for surfaces by /iteration/. We can't set the value directly like
that because we simply don't know it, and neither does the fuselage or even
the surface compiler. There is a start value, but it can be up to 1
iterations (or more! ;) from a sane value.

To do it "the yasim way" we would need a similar iterative solver
for helicopters like for winged aircrafts, based on cruise&approach data or
whatever can be available. (possibly incorporated in ::solver())

We could on the other hand let the model designer set and tweak the
fuselage Cd manually in the config file.

(and one raised to the power of any real number is still one ;)

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] yasim heli solver, CG for Z-axis

[Joacim Persson]

On Sun, 2 Jul 2006, Maik Justus wrote:

> the helicopter simulation as it is in cvs has the bug, that any kind of
> surfaces, stabs, fuselages have no aerodynamical effect.

That bugfix had a huge impact on the chinook. I still get a negative yaw
moment from the both rotors (most of the time), but I guess you have more
stuff coming in due time. (I simply turned off torque calculations.
Doesn't matter on that model anyway.)

But I noticed something else now. Maybe it's been there all the time and I
just never saw it:

Solution results:   Iterations: 0
  Drag Coefficient: 15.70
Lift Ratio: 104.00
Cruise AoA: 0.00
Tail Incidence: -0.00
Approach Elevator: 0.00
CG: -8.331, -0.003, 3.088
   ^
(Datum used has the Z- and Y-axii along the mid of the fuselage.)

The solver places the CG 3 meters up! (I've only been using a small
ballast-statement at the stern to trim the longitudal CG right, plus the
two engines.) This lands somewhere at the height of the rotors (fwd Z: 2.6,
aft: 3.99). (They're not THAT heavy ;) This of course creates some
interesting stability problems when not flying perfectly coordinated...
Imagine a sailboat with the whole ballast at the top of the mast. =)

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fwd: FlightGear network protocol

[Joacim Persson]

On Fri, 30 Jun 2006, Robin van Steenbergen wrote:

>> Main thing is that I can't find the documentation for the protocol used
>> by FlightGear for data I/O.

There are several protocols. In fact, infinitely many. ;)
You can define your own protocols with --generic (binary or text strings)

(And thus saving bandwidth by sending only the data you need for your
application.)

Docs/README.IO  and (for the generic interface) Protocols/ where there is a
README and some examples.

>> Note that everything is connected through a LAN and the ideal case
>> would be to use a multicast to connect some systems together, but
>> I'm still unsure whether that's possible. The packet format used by
>> FlightGear is the main concern right now.

...you don't actally need to complexityficationalise things with multicast
if the hosts are on the same network segment. A simple UDP-broadcast should
do the same thing there, unless you have fancy multicast-aware switches in
the lab and need to really push the network to its limits. But it seems
noone has added (nudge-nudge wink-wink, Robin ;) an option for setting the
broadcast option on sockets.  (except for --multiplay) This ought to be an
option for all udp protocols in FG imho. Well, at least for the --generic.
(set via a simple plib call in the right spot)

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Chinook Was: Re: Helicopter: First Impressions

[Joacim Persson]

On Wed, 28 Jun 2006, chris wrote:


That is backward.


Indeed so. ;) (already sorted out)


The chinook used to have just an  "Stability Augmentation System" the SAS for
short.  You still did not want to take your hands off the cyclic but it made
it somewhat smoother.


Yea I read a little about it. The AFCS with underlying systems is perhaps
more like something between an SAS and an autopilot.

From CH47 Theory of operations:


The advanced flight control system provides the following
modification and additions to the stability augmentation system
(SAS) installed in earlier model CH-47 helicopters.
1. Continuous pitch attitude and, in the long term, airspeed hold
referenced to the longitudinal control position throughout the
flight envelope.
2. Long term bank angle and heading hold in level flight and bank
angle hold about any stabilized bank angle in turning flight.
3. A stable longitudinal positive control gradient from maximum
rearward to maximum forward flight speeds.
4. Vernier beep trim of bank angle and airspeed.
5. Radar and barometric altitude hold.
6. Coupled heading selected through the HSI bug error.
7. Cockpit control position transducers (control switch pick-offs)
in the longitudinal, lateral, and directional control system to
improve maneuverability.
8. The mechanical detent switches on the lateral and directional
controls have been replaced by electronic signals derived from
control position signals supplied to the AFCS.
9. Automatic longitudinal cyclic trim positioning to the ground
mode when either aft wheels are on the ground.

Point (1) ought to make the aircraft appear rather differently to the pilot
than the older models with only SAS did. (3) I trim manually for now.
(hopeless to fly it straight if this is not trimmed correctly to speed and
thrust) I suspect (4) together with (5) is used a lot during normal free
flight cruise. (when not flying AP alltogether)

Apparently the SAS also included the LCT (automatic? -- just not auto
ground mode?).



I got it significantly more stable now. (without cheating with faked hstabs
and vstabs) At one point, when I used a silly power configuration, it even
flew fairly straight up to 470 kias. ;) (never mind the G meter)

But I still can't figure out how to make it cruise with the right pitch. No
matter how I adjust the parameters, it flies nose-up about 7° at cruise
(constant speed, heading and altitude). Mystery...Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Chinook Was: Re: Helicopter: First Impressions

[Joacim Persson]

On Tue, 27 Jun 2006, Josh Babcock wrote:

> But you don't *want* the rotor to be straight. Assuming a constant
> airfoil section along the length of the blade, you would want a constant
> aoa so that you can get the maximum lift out of the blade.

I'm glad you didn't read what I had typed, because I was full of shit. =)
(I said the tips have *higher* incidence)

Late last night I was looking at a picture of a parked chinook and saw,
erroneously, that the blade tips had higher incidence than the root, not
lower. In the process of trying to grasp this mind-bogging concept with my
little mind I assumed the blade must flex back, or most of it would be
stalled during flight.

After a good night sleep and investigating the matter more thoroughly it is
now my great privilige and honour to report that the chinook and the
bumble-bee are both well and flying. The blades are twisted the right way,
i.e angle of incidence are lower at the tips than at the root. (and the aft
rotor rotates clockwise)

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Chinook Was: Re: Helicopter: First Impressions

[Joacim Persson]

On Tue, 27 Jun 2006, Maik Justus wrote:


I'm working now on simulating the rotor on several points along the
rotor blades (with twist).


I suspect that twist to vary with load. It's the tips that has a 12° higher
incidence (sic!) than the root, when the rotor is stopped that is. I guess
that's a pre-tensioning of the blade; that the lift moment on the blade (it
has some naca profile if I remember it right) will twist it back to a more
straight shape under load or perhaps even twist it the other way.

I have begun to develop some doubts if this reductionistic approach is the
way to go for simulating an aircraft that under normal operation is flown
with an electronic flight control system which does it best at making the
aircraft behave like a much smoother thing to fly than it is with the FCS
broken. What we want to simulate in the end is certain movements of the
aircraft following a certain input, not necessarily all the gory details in
between that the pilot (normally) never have to worry about.

But then again -- where's the fun in simplicity? ;)Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Using FG and autopilot separatelly

[Joacim Persson]

On Mon, 26 Jun 2006, emanoel bernardo wrote:

> Hey everyone,
> I'd like to use FG (Flight Gear) and autopilot separetelly but i don't know
> how do they communicate to each other. Let me explain better...What I wanna
> do is:
> Run FG on a PC and run the autopilot on another PC and communicate them.

The AP's (there are several different implementations) are part of the
models. (Rationale is that autopilot devices normally are mounted *in* the
aircrafts in the real world =). If you are developing your own stand-alone
autopilot and want it on another host, there are several ways to interface
to the simulator to control the aircraft remotely.

Everything you need to read and set to control an aircraft is in the
aircraft's property tree. (This is how the aircraft is controlled
internally too) This property tree can be read and modified (if the
property is not a read-only one) across the network.

The simplest way to /set/ a property is perhaps via the telnet interface.
fgfs --telnet= then do "telnet  " and type "help" to see
the syntax. You can read properties aswell, that way, but perhaps you
rather prefer to get data synchronously. This can be achieved through the
general i/o-interface. (Can one /set/ properties aswell with this, anyone?
No mentioning on how in the docs. :P)

Stuff to read:
man fgfs
Docs/README.IO
Protocol/* (examples and another README-file)

There is also a remote joystick interface whose protocol could come in
handy: Docs/README.jsclient You have to mimic the jsserver with your remote
AP.

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Chinook Was: Re: Helicopter: First Impressions

[Joacim Persson]

On Sat, 24 Jun 2006, Maik Justus wrote:

> Hi Joacim,
>
> I am surprised how many helicopter types are (more or less) in process.
> The ch47 simulation is only a proof of concept. It shows, that the rotor
> simulation is able to simulate this rotor configuration (It has 4-blade
> rotors, it is much to small, no parameter of the rotor is form the ch47,
> etc.) Due to the missing drag of stabs and fuselage it is absolutely
> unrealistic. But this bug is solved and now it feels much better, but it
> is easy to get into very critical states.

Aha! So that's why I couldn't make it fly with the fuselage in level. It
has always flown a bit nose-up at speed, no matter what insane drag values
I set for the fuselage. Very confusing. ;)
(talking about my 3-blade rotors >5lbs version here)

There is (was?) also an odd bug occuring from time to time, where some
kind of torque was wrong or missing and the chinook started spinning like
mad at takeoff; as if the torque on one rotor was missing or the cyclic
aileron was differing between the rotors. Restarting fgfs usually "fixed"
the problem.  (I *can* get the same interesting effect by changing certain
values on one rotor only, so they produce different torque. But this
happens when they numbers are correct too.)
Seems like uninitialised memory somewhere perhaps.


> I have no information about
> the flight control systems; the control in the simulation is as it is in
> the rc models of chinook like helicopters.

CH47 Theory of Operation, chapter 11. Can be downloaded from:
http://www.chinook-helicopter.com/Publications/Publications.html
(beware: 47 meg pdf, 500 pages)
There is also a bitmapped drawing from Boeing there, containing fuselage
measures, CG limits, pylon and rotorblade data etc.

For now, I've added a manual longitudal cyclic trim (LCT) on it via the
"propeller pitch" control through CYCLICELE on the rotors, but the numbers
are guesswork so far. (I have tilt angles numbers for each rotor at various
speeds, but I can't set that directly in the fdm.) The AFCS's do more than
adjusting LCT. (yaw and pitch stabilisation for instance, which definitely
takes a PID-regulator or two. ...or fifty-seven. =)

> Maybe it is possible to add the flight control system to the simulation.

It can be designed in nasal + a number of PID-regulators.  All the
necessary tools are already there in FG, so it doesn't affect the heli code
in yasim. (Just a lot of work trimming the regulator values. :P)

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Chinook Was: Re: Helicopter: First Impressions

[Joacim Persson]

On Fri, 23 Jun 2006, Maik Justus wrote:


Is there any other helicopter (3D-model) in preparation?


Hello Maik,

I was fiddling with mainly the FDM for the Chinook last winter, and have a
simple 3D for it. (only an untextured exterior fuselage with two non-rotating 
rotors
and the four wheels) There is quite extensive documentation on the various
ch47 models on the net, D-model in particular. Pilot manuals, tech
manuals... thousands of pdf-pages.  I also downloaded a few film clips of
it flying, including a British crew performing some impressive aerobatic
manouvres, to get an idea of how it ought to feel in the simulator too.
(The ch-47 fdm in the cvs is apparently a mock-up with 4-blade(!) rotors
etc.)

Most of the info came from here: http://www.chinook-helicopter.com/
(and yes, the web design of those pages may make you go epileptic,
but there's /piles/ of information on the Chinook there)

Regarding the stabiliser on the ch47, that's not all there is to it: The
real thing has two flight control systems, one for each rotor. If any of
them are failed the heli can still be flown, but with a speed limit and
according to what chinook pilots have said on the net, only with full
concentration. (impossible to fly it and navigate at the
same time with both FCS's out of operation.)

This is also my experience with the FDM (my version) for it in FG, so
perhaps the FDM is correct. ;) Speeding with it is terrifying...

It really *do* need an FCS, even in the sim... The FCS varies the lift and
tilt on the rotors according to speed. This, I noticed, has a great impact
on stability. But I haven't found the details on the algorithms yet. There
is *some* info on it in the tech manuals but I recall missing some data.

AFAIK, the yasim fdm-engine does not simulate rotor blades with twist.
Chinook blades are twisted as much as 12°. ("for stability reasons")


I don't remember in what state I left my ch47 fdm last winter. (was
experimenting quite a bit with it) I'll have a look at it later and see if
I can resurrect something fairly flyable and post the config file here. I'm
too busy with other things right now to do any serious work on it.Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] simgear cvs compile errors with gcc 3.3.6

[Joacim Persson]

On Sat, 17 Jun 2006, Mathias Fröhlich wrote:


Given the error message, I could imagine a that the attached patch helps.
Can you please tell me if that patch helps?


Compiled without a warning on mat.cxx now.

(Was that all? Couldn't handle that method as inline?)


... I tested with gcc-4.1.1 and gcc-3.2.3 which are both happy with the actual
code. Can you help me testing with gcc-3.3.6?
:-/


Too lazy to upgrade gcc, so I guess that's unavoidable. ;)
(3.3.6 is the gcc version on slackware 10.2)___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] simgear cvs compile errors with gcc 3.3.6

[Joacim Persson]

>From talking to others on IRC I understand the cvs version of simgear builds
fine with gcc 4, but with gcc 3.3.6 I get these compile errors added below. Is
there a simple workaround for this?

In file included from mat.cxx:44:
../../../simgear/structure/SGSharedPtr.hxx: In member function `void
SGSharedPtr::get(const T*) const [with T = SGMaterialGlyph]':
../../../simgear/structure/SGSharedPtr.hxx:51:   instantiated from 
`SGSharedPtr::SGSharedPtr(T*) [with T = SGMaterialGlyph]'
mat.hxx:212:   instantiated from here
../../../simgear/structure/SGSharedPtr.hxx:91: error: no matching function for
call to `SGReferenced::get(const SGMaterialGlyph*&)'
../../../simgear/structure/SGReferenced.hxx:41: error: candidates are: static
unsigned int SGReferenced::get(const SGReferenced*)
../../../simgear/structure/SGSharedPtr.hxx: In member function `void
SGSharedPtr::put() [with T = SGMaterialGlyph]':
../../../simgear/structure/SGSharedPtr.hxx:58:   instantiated from 
`SGSharedPtr::~SGSharedPtr() [with T = SGMaterialGlyph]'
mat.hxx:212:   instantiated from here
../../../simgear/structure/SGSharedPtr.hxx:93: error: no matching function for
call to `SGReferenced::put(SGMaterialGlyph*&)'
../../../simgear/structure/SGReferenced.hxx:43: error: candidates are: static
unsigned int SGReferenced::put(const SGReferenced*)
../../../simgear/structure/SGSharedPtr.hxx:93: warning: possible problem
detected in invocation of delete operator: 
../../../simgear/structure/SGSharedPtr.hxx:93: warning: invalid use of
undefined type `struct SGMaterialGlyph'
mat.hxx:55: warning: forward declaration of `struct SGMaterialGlyph'
../../../simgear/structure/SGSharedPtr.hxx:93: note: neither the destructor nor
the class-specific operator delete will be called, even if they are declared
when the class is defined.
make[4]: *** [mat.o] Error 1



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Re: XF-23 has strange shadow

[Joacim Persson]

On Wed, 21 Dec 2005, Martin Spott wrote:


The square shadow is the fake. To my knowledge there were only two
aircraft that came with a fake shadow: the BO-105 and the YF-23.


The DC-3 also.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] importing x-plane models!

[Joacim Persson]

Just today I discovered this marvellous little tool for converting x-plane
.acf-files to ac3d .ac-files, and since I couldn't find it mentioned on FG
mailing list archives or on the web pages, I'd thought I better tip
others about it:

http://sysd.org/xplane/acftools/index.php

The perl-version has a bug in it: a test for big/small endian fails on my
machine, resulting in .ac-files which are looking more than a little
bizarre, but after a Q&D disabling of the test at
ACFTools_0.62a/lib/XPlane/Convert/ACFparse.pm, around line 52 and on, it
worked like charm.

As many of you probably know, there are quite a few free models for
x-plane available for download, models which thus can be imported to FG.

Well, at least the major part of the 3D model can be imported. Wings are
apparently handled differently in x-plane, but the aerodynamic data for the
wing sections are in cleartext in the airfoil files (simple tables of
alpha, Cl, Cd, Cm for each section), and since it doesn't matter for the
FDM's in FG if the 3D doesn't have exactly the right profile, profiles for
which acftools doesn't have uiuc geometry data files for can be shamelessly
faked with some similar one which looks good.

Oh, and I also found a free xplane model of Hawker Harrier:
http://www.x-plane.org/registry/5010.shtml

...a model which in FG already has a flight model, but no 3D.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel