Re: [Flightgear-devel] Re: type conversion problem for amd64
On Fri, 2005-09-23 at 21:27 -0700, Alex Perry wrote: From: Erik Hofman George Patterson wrote: Tonight I cvs checkout the simgear sources tonight from cvs to recompile FlightGear. I was getting the following error. (Also got the same error in swap_test.* but worked around that problem by remove the file and references to it. Could you test the latest version in CVS, there was some restructuring of this code and I think this is solved now. Erik, it works fine for me under Debian/Sarge AMD64. George, what toolchain are you using ? $ gcc --version gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) $ uname -a Linux host 2.6.13 #1 Sun Aug 28 19:57:26 PDT 2005 x86_64 GNU/Linux $ gcc --version gcc (GCC) 3.3.5 (Debian 1:3.3.5-8ubuntu2) $ uname -a Linux beast64 2.6.10-5-amd64-generic #1 Tue Apr 5 12:21:57 UTC 2005 x86_64 GNU/Linux However, I seem to have had a problem with syncing CVS but fixed it with some guidance from Oliver Schroeder (thanks). George ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Simgear and SGFile usage in FGFS
Alex Perry wrote: Unless I'm missing something, someone has committed bad code to CVS. The ch variable on line 377 is of class SGIOChannel, which doesn't support the eof() method, and not of class SGFILE, which does. ~/fs/source/utils/GPSsmooth$ make if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../../src -I/usr/X11R6/include -I/usr/local//include -g -O2 -D_REENTRANT -MT MIDG-II.o -MD -MP -MF .deps/MIDG-II.Tpo -c -o MIDG-II.o MIDG-II.cxx; \ then mv -f .deps/MIDG-II.Tpo .deps/MIDG-II.Po; else rm -f .deps/MIDG-II.Tpo; exit 1; fi MIDG-II.cxx: In member function `int MIDGTrack::next_message(SGIOChannel*, MIDGpos*, MIDGatt*)': MIDG-II.cxx:377: error: `eof' undeclared (first use this function) MIDG-II.cxx:377: error: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [MIDG-II.o] Error 1 Yup, missed a commit. Should be in cvs now. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Flightgear Documentation update: prefligh.tex
Hi all,
I have made some changes to the preflight: Installation section of the
Getting started guide.
While I am still learning latex, I did check my changes with lacheck
which didn't complain. Could someone (probably Erik or Martin) check the
patch file over and commit it into CVS?
CHANGES MADE
- Changed download link for Mac OS X binaries
- Amended Debian install instructions to be applicable for Ubuntu via
apt-get install.
- Formatting errors which lacheck reported.
Thanks
George Patterson
--- prefligh.tex2005-09-24 19:41:10.82636 +0930
+++ prefligh.gp.tex 2005-09-24 21:35:33.893210816 +0930
@@ -80,7 +80,7 @@
the simulator.
In case of doubt about the correct directory structure, see the summary at the
-end of chapter \ref{building}.
+end of chapter \~ref{building}.
%%%
\section{Installing the binary distribution on a Macintosh
system}\index{binaries!Macintosh}
@@ -90,7 +90,7 @@
Walisser)\index{Walisser, Darrell}. Download the file
\verb/FlightGear_Installer_0.X.X.sit/ from the corresponding subdirectory under
\medskip
-\web{http://icdweb.cc.purdue.edu/~walisser/fg/}.
+\web{http://macflightgear.sourceforge.net/}.
\medskip
\noindent
@@ -112,9 +112,10 @@
Note that there is no \texttt{runfgfs} script for Mac OS X yet.
%%%
-\section{Installing the binary distribution on a Debian Linux
system}\index{binaries!Debian}
+\section{Installing the binary distribution on a Debian based Linux
system}\index{binaries!Debian}
%%%
+
Download the file \verb/flightgear_0.7.6-6_i386.deb/ (being provided courtesy
Ove
Kaaven)\index{Kaaven, Ove} from any of the \Index{Debian} mirror sites listed
at
\medskip
@@ -129,9 +130,11 @@
\verb/dpkg --install flightgear_0.7.6-6_i386.deb/.
\medskip
+If you have a Debian, Ubuntu or other Debian package based linux distribution,
you might perfer using apt-get to install Flightgear \texttt{apt-get install
flightgear}.
+
\noindent
After installation, you will find the directory \texttt{/usr/local/Flightgear}
-containing the script \texttt{runfgfs} to start the program.
+containing the script \texttt{runfgfs} to start the program. If runfgfs has
not been included that you may run flightgear by running the binary
\texttt{runfgfs} directly.
%%%
@@ -161,7 +164,7 @@
\noindent
Moreover, Curt provides the complete set of US Scenery on \Index{CD-ROM} for
those who
-really would like to fly over all of the USA. For more detail, check the
remarks on the
+really would like to fly over all of the USA\. For more detail, check the
remarks on the
downloads page above.
An alternative data set was produced by William Riley\index{Riley, William}
and is available from
@@ -198,14 +201,14 @@
\medskip
\noindent
- with the directories w122n37 and w123n37, resp. containing numerous *.gz
+ with the directories w122n37 and w123n37, resp.\ containing numerous *.gz
files. Installation of the Grand Canyon scenery adds to this the directories
\medskip
\noindent
\texttt{/usr/local/FlightGear/Scenery/w120n30/w112n30}\\
\texttt{/usr/local/FlightGear/Scenery/w120n30/w112n31}\\
- \texttt{...}\\
+ \texttt{\.\.\.}\\
\texttt{/usr/local/FlightGear/Scenery/w120n30/w120n39}.
\medskip
@@ -216,7 +219,7 @@
%%%
Most of the packages named above include the complete \FlightGear{}
documentation
-including a .pdf version of this \textit{Installation and Getting Started}
Guide intended
+including a \.pdf version of this \textit{Installation and Getting Started}
Guide intended
for pretty printing using Adobe's Acrobat Reader being available from
\medskip
@@ -224,7 +227,7 @@
\medskip
\noindent
- Moreover, if properly installed, the .html version can be accessed via
+ Moreover, if properly installed, the \.html version can be accessed via
\FlightGear{}'s \texttt{help} menu entry.
Besides, the source code contains a directory \texttt{docs-mini} containing
numerous
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Crash carnage
This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out with. We have a backup plane and our expensive instrumentation survived intact, so this shouldn't be a severe setback to us. Very high on my todo list is to build some glue code that can take live IMU/INS/GPS data from the airplane (sent over radio modem) to the ground station and display a live synthetic view of the airplane using FlightGear. If I'm successful with building the link, then the next obvious thing to try is to fly the airplane looking only at the real time FlightGear view, not looking at the real airplane. Beyond just being a fun thing to try, you could imagine putting some representation of restricted airspace in the synthetic view, or other objects that are important to your mission ... whether that be monitoring traffic, wild fires, surveying damage after a storm, etc. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
On Saturday 24 Sep 2005 16:28, Curtis L. Olson wrote: This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out with. We have a backup plane and our expensive instrumentation survived intact, so this shouldn't be a severe setback to us. Very high on my todo list is to build some glue code that can take live IMU/INS/GPS data from the airplane (sent over radio modem) to the ground station and display a live synthetic view of the airplane using FlightGear. If I'm successful with building the link, then the next obvious thing to try is to fly the airplane looking only at the real time FlightGear view, not looking at the real airplane. Beyond just being a fun thing to try, you could imagine putting some representation of restricted airspace in the synthetic view, or other objects that are important to your mission ... whether that be monitoring traffic, wild fires, surveying damage after a storm, etc. Curt. Hmm... I'm getting a 504 - gateway time-out when I try to look at www.flightgear.org. (Hmm... wonders if this e-mail will get through...) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] TAT in Yasim
Hi, I'm currently working on the EICAS display for 747-400, and I would like to display TAT (Total Air Temperature) too. Is that property available somewhere in YASim? Thanx, Gabor P.S.: Screenshots: http://www.i-net.hu/fgfs/screenshots/747 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] macflightgear info
There are some other mac fgfs guys on this list. I figured I'd let everyone know exactly what the MacOSX port of FGFS is up to.http://artooro.blogspot.com/2005/09/mac-flightgear-project-report.html (NOTE:)The Flight starter (fgrun equiv) is referred to as MacFlightGear and the rest is obvious (I hope).We're not using fgrun because first, it won't compile at all on OSX without major changes, and second, even if it did work it would look ugly because it uses FLTK so a port isn't worthwhile. While I wouldn't care, a lot of mac users would care about how it looks. MacFlightGear uses the wxWidgets framework.Also a note to you mac developers, if you would be interested in helping make fgfs more user-friendly drop me a line. I would love to have more guys join. We're reaching 4 downloads in the next week or so by the way. Probably nothing compared to others but to me it means, get to work! http://macflightgear.sourceforge.net-- Arthur/- http://sourceforge.net/users/artooro/ - http://artooro.blogspot.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TAT in Yasim
Gabor Toth wrote: I'm currently working on the EICAS display for 747-400, and I would like to display TAT (Total Air Temperature) too. Is that property available somewhere in YASim? This is not part of the FDM, the outside air temperature comes out of the environment code and is available in the /environment/temperature-degc property. There is no code currently to compute the compression heating for the static air temperature, AFAIK. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
On Saturday 24 September 2005 16:28, Curtis L. Olson wrote: This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out with. We have a backup plane and our expensive instrumentation survived intact, so this shouldn't be a severe setback to us. Ouch! :( Just a thought, many years ago I watched a demo of a BRS for a model plane at Cosford in the UK. Apparently it was very lightweight but had clever triggering. In the event that the radio signal (controller to plane) was lost, the system cut the fuel off to the motor and released a spring loaded BRS which brought the model down for a vertical but gentle landing. Could you fit something like this on the UAV for loss of contact events? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
On Saturday 24 September 2005 20:07, Curtis L. Olson wrote: It's definitely an interesting thought. Anyone know what size parachute a person would need to gentle let down about 15 lbs (7kg)? Many R/C receivers have a failsafe mode so you can trigger the servos to go to preset locations in the event of a transmitter signal loss. The danger is probably similar to the danger the full size BRS units have ... if you deploy the chute at a high speed, you are going to tear your airplane to shreads. Not sure on weights for the chutes but from my school days I remember only needing a few grams of parachute to retard the fall of a 3kg rubber brick. The speed risk issue would probably have to be dealt with like the real BRS systems which cause a pitch-up when deployed to share the aerodynamic load between airframe and parachute. You could perhaps experiment with a 'slider' to hold the chute partly closed until the speed drops. Just on the subject of BRS; there was a Flight Designs CT on a test-flight which exceeded Vne in a dive causing the wing to fail; The BRS was opened at 195mph and worked! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
On Saturday 24 September 2005 16:28, Curtis L. Olson wrote: This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out with. We have a backup plane and our expensive instrumentation survived intact, so this shouldn't be a severe setback to us. Just done some more reading of your page and incident analysis; I was just thinking that a useful tool would be a couple of camcorders. (and a friend to operate one of them). If you set one up on a tripod looking at the transmitter, you could at least see what control positions you were *trying* to get at any given time. The second camera could be kept on the aircraft itself. Both cameras would need to be synced to keep the correct time (for comparison with your UAV data). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
Dave Martin wrote: Just done some more reading of your page and incident analysis; I was just thinking that a useful tool would be a couple of camcorders. (and a friend to operate one of them). If you set one up on a tripod looking at the transmitter, you could at least see what control positions you were *trying* to get at any given time. The second camera could be kept on the aircraft itself. Both cameras would need to be synced to keep the correct time (for comparison with your UAV data). We do have a camera on board looking forward and down, but our helpful video capture application decided that there was so much snow and bad signal in the video stream (primarily after the crash) that it helpfully deleted that entire segment of video for us. Ya gotta love windows! One thing we'd like to do that wouldn't be too technically difficult would be to get a 2nd receiver on the same channel as the aircraft but keep it on the ground. Pipe the servo outputs from the ground based receiver into a little PIC board and decode the PWM signals coming in on each channel and send them out the serial port to the ground station. This would be a way to record pilot inputs without needing extra equipment in the air. It doesn't tell you about loss of signal or interference issues with the airborn system, but it does tell you what the pilot is trying to do. I think we'll get there ... you learn as you go with this stuff and it takes time to assemble equipment and develop software and interfaces. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] missing libraries for MIDGsmooth
Hello, I'm happy to realize that almost everything in the Sim-/FlightGear source tree compiles cleanly on IRIX (thanks Erik !!). There's just a small utility left that doesn't build: make[2]: Entering directory `/usr/local/src/FlightGear/utils/GPSsmooth' CC [...] -c99 -I/opt/FlightGear/include/simgear/compatibility -D_REENTRANT -exceptions -L/opt/lib32 -L/usr/freeware/lib32 -Wl,-rpath -Wl,/usr/freeware/lib32 -s -L/opt/FlightGear/lib -L/usr/local//lib -o MIDGsmooth MIDG-II.o MIDG_main.o -lsgio -lsgtiming -lsgmath -lsgmisc -lsgdebug -lsgbucket -lplibnet -lplibul -lm -lz ld32: ERROR 33 : Unresolved text symbol SGPath::SGPath(const std::basic_stringchar,std::char_traitschar,std::allocatorchar ) -- 1st referenced by /opt/FlightGear/lib/libsgbucket.a(newbucket.o). ld32: ERROR 33 : Unresolved text symbol SGPath::~SGPath(void) -- 1st referenced by /opt/FlightGear/lib/libsgbucket.a(newbucket.o). In a first step I added -lsgbucket to the linker command in order to resolve another missing symbol but I can't tell which library this call from libsgbucket depends on, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] missing libraries for MIDGsmooth
Martin Spott wrote: Hello, I'm happy to realize that almost everything in the Sim-/FlightGear source tree compiles cleanly on IRIX (thanks Erik !!). There's just a small utility left that doesn't build: make[2]: Entering directory `/usr/local/src/FlightGear/utils/GPSsmooth' CC [...] -c99 -I/opt/FlightGear/include/simgear/compatibility -D_REENTRANT -exceptions -L/opt/lib32 -L/usr/freeware/lib32 -Wl,-rpath -Wl,/usr/freeware/lib32 -s -L/opt/FlightGear/lib -L/usr/local//lib -o MIDGsmooth MIDG-II.o MIDG_main.o -lsgio -lsgtiming -lsgmath -lsgmisc -lsgdebug -lsgbucket -lplibnet -lplibul -lm -lz ld32: ERROR 33 : Unresolved text symbol SGPath::SGPath(const std::basic_stringchar,std::char_traitschar,std::allocatorchar ) -- 1st referenced by /opt/FlightGear/lib/libsgbucket.a(newbucket.o). ld32: ERROR 33 : Unresolved text symbol SGPath::~SGPath(void) -- 1st referenced by /opt/FlightGear/lib/libsgbucket.a(newbucket.o). In a first step I added -lsgbucket to the linker command in order to resolve another missing symbol but I can't tell which library this call from libsgbucket depends on, Martin. Try adding -lsgmisc (I think that is where SGPath resides.) If that works we can add it for everyone. Most systems don't care about library dependencies for calls that aren't used, but irix seems to need to resolve all the dependencies in a library, even for functions that are never called or used. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] missing libraries for MIDGsmooth
Martin Spott wrote: Curtis L. Olson wrote: Try adding -lsgmisc (I think that is where SGPath resides.) It does. Thank you, Martin. I notice that -lsgmisc is already there. Did you have to move it to a differerent relative place in the link command? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] help: making SimGear CVS under Cygwin
Building SimGear CVS under Cygwin Hi, thanks to the help of AJ I solved the OpenAL problem and though the files of Norman do not work with older versions the problems are solved with the CVS version of SimGear and Normans precompiled files (thank you Norman, AJ) Now there is another problem I cannot solve myself at my present stage of knowledge (make files): I installed FlightGearCVS, OpenAL files and I installed the SimGear CVS files under /usr/local/source/SimGearCVS First I made zlib: /usr/local/source/SimGearCVS/src-libs/zlib-1.1.4 ./configure make make: Fur das Ziel all ist nichts zu tun. (make: for the target all is nothing to do make install .. runs through Then I went back to /usr/local/source/SimGearCVS ./autogen.sh Running aclocal /usr/share/aclocal/libsmi.m4:8: warning: underquoted definition of AM_PATH_LIBSMI run info '(automake)Extending aclocal' or see http://... /usr/share/aclocal/cppunit.m4:4: warning: underquoted definition of AM_PATH_CPPUNIT Running autoheader Running automake --add-missing Running autoconf Now you are ready to run './configure' next step: ./configure ... runs through many points without remarkable observations ... but then, at the end: configure: creating ./config.status config.status: creating \ .infig.status: error: cannot find input file: \ next step make make: *** Keine Targets angegeben und keine make-Steuerdatei gefunden. Schluss (make:*** No targets found and no makeconfig(???)file found. End) Please, can someone give a hint what to do, what did I do wrong? I would like to be able to build FlightGear CVS versions as there are some other Win32 users too who would like to do some user-development (texturing, aircraft-work) with an actual FG version. Thank you very much in advance Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] PID Controller Bug?
I have been playing around with the autopilot this evening, and
noticed something that seems to me to be broken.
I ran into a problem where I would see a really large change in output
(delta_u_n) but the output would not change (yes, this probably also
means my gains need some adjusting), e.g.:
- From debug output ---
Updating Yaw Stabilization
input = 119.876 ref = 0.000610361
ep_n = -119.875 ep_n_1 = -118.088 e_n = -119.875 ed_n = -119.876 delta_u_n =
-2.96522
P:-0.268029 I:-2.69719 D:0
min saturation
output = 0.982904
---
So I checked the code in xmlauto.cxx and found that yes, these lines
were responsible for zeroing delta_u_n:
- From xmlauto.cxx
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout min saturation endl;
}
-
Perhaps I am not understanding this correctly (this PID controller is
not like any I have seen before), but it seems to me that it should
read:
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = u_max - u_n_1; // --- CHANGED
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = u_min - u_n_1 // -- CHANGED
if ( debug ) cout min saturation endl;
}
-Jeff
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
