Re: [Flightgear-devel] PID Controller =?iso-8859-1?q?Bug??=
På 29.09.2005 00:47 CEST skrev Hans-Georg Wunder Behaviour with delta_u_n = 0 and an input jump function of 0.6 Saturation at the beginning o Time, reference,input,output 21:56:54,0,0,0 21:56:55,0,0,0 21:56:56,0,0,0 21:56:57,0,0,0 21:56:58,0,0,0 21:56:59,0,0.6,0.02549 Here the P-part is missing There has to be a jump to u_max You should not set the input to 0.6. You should set the reference to 0.6. The input is the process value, and the reference is the set point. You can not set the process value directly. If you could then you would not need a controller at all ;-). In your example here it does not matter, results would have been similar if you set the reference to 0.6. But you have to remember this when you use live values with your controllers. The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=FlightGear-0.9 should fix this. This is what would happen when you set delta_u_n = u_max - u_n_1 : delta_u_n (u_max - u_n_1) 0.6 (0.5 - 0.0) : true delta_u_n = u_max - u_n_1 = 0.5 - 0.0 = 0.5 u_n = u_n_1 + delta_u_n = 0.0 + 0.5 = 0.5 and at the next time step let's assume that delta_u_n is still 0.6: 0.6 (0.5 - 0.5) : true delta_u_n = 0.5 - 0.5 = 0.0 u_n = 0.5 + 0.0 = 0.5 u_n jumps to u_max and stays there as long as delta_u_n is positive. P.S.: The test result for delta_u_n = u_max - U What? Where are the results for delta_u_n = u_max - u_n_1? Am I right in assuming that the results you presented her were for version 1.19 of xmlauto.cxx and _not_ version 1.20 of xmlauto.cxx? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] macflightgear info
A Linux version is possible in theory but currently there is some Mac-only C++ code in MacFlightGear and also the source would have to be built manually.Apple is switching to Intel from PowerPC processors and universal binary simply allows apps to run native on both arcs. This apps are optimized for both and the only downside is that the file sizes are about twice the size. On 9/28/05, Jim Wilson [EMAIL PROTECTED] wrote: From: Arthur Wiebe 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.netThe wxWidgets/gtk apps I've used seem to work pretty well,so it might actually be possible to have a version easily portable to linux.I'm not able to do any development at the moment,but if you need a tester before releasing,I'm willing to mess around with it for a while on the little ibook.I wonder what kind of performance hit you are talking about using the universal binary mode?Anyway, thanks for the update. Best,Jim___Flightgear-devel mailing listFlightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel2f585eeea02e2c79d7b1d8c4963bae2d-- 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] PID Controller =?iso-8859-1?q?Bug??=
Roy Vegard Ovesen wrote: På 29.09.2005 00:47 CEST skrev Hans-Georg Wunder Behaviour with delta_u_n = 0 and an input jump function of 0.6 Saturation at the beginning o Time, reference,input,output 21:56:54,0,0,0 21:56:55,0,0,0 21:56:56,0,0,0 21:56:57,0,0,0 21:56:58,0,0,0 21:56:59,0,0.6,0.02549 Here the P-part is missing There has to be a jump to u_max You should not set the input to 0.6. You should set the reference to 0.6. The input is the process value, and the reference is the set point. You can not set the process value directly. If you could then you would not need a controller at all ;-). The test is done in an open loop configuration. The only difference between the input value and the reference value is the sign. Here the test results with the step response of the reference Same test with change of the reference value. Time, reference,input,output 08:51:03,0,0,0 08:51:04,0,0,0 08:51:05,0,0,0 08:51:06,0,0,0 08:51:07,0.6,0,-0.0195 Jump to 0.6 into saturation, output is negative due to Kp=-1 08:51:08,0.6,0,-0.08006P-Part ist missing 08:51:09,0.6,0,-0.14050001 08:51:10,0.6,0,-0.2011 08:51:11,0.6,0,-0.26150002 08:51:12,0.6,0,-0.32250002 08:51:13,0.6,0,-0.3833 08:51:14,0.6,0,-0.44350003 08:51:15,0.6,0,-0.4994 08:51:16,0.6,0,-0.4994 In your example here it does not matter, results would have been similar if you set the reference to 0.6. But you have to remember this when you use live values with your controllers. The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=FlightGear-0.9 should fix this. This is what would happen when you set delta_u_n = u_max - u_n_1 : delta_u_n (u_max - u_n_1) 0.6 (0.5 - 0.0) : true delta_u_n = u_max - u_n_1 = 0.5 - 0.0 = 0.5 u_n = u_n_1 + delta_u_n = 0.0 + 0.5 = 0.5 and at the next time step let's assume that delta_u_n is still 0.6: 0.6 (0.5 - 0.5) : true delta_u_n = 0.5 - 0.5 = 0.0 u_n = 0.5 + 0.0 = 0.5 u_n jumps to u_max and stays there as long as delta_u_n is positive. With this patch, the controller gets out of sync. Here the test results. But only, when the windup is used. Sorry, that it is so long. Behaviour with delta_u_n =u_max - u_n_1 (Patch fromj Erik) and an input jump function on the reference input of 0.2. Not Saturation at the beginning Time, reference,input,output 08:50:46,0,0,0 08:50:47,0,0,0 08:50:48,0,0,0 08:50:49,0,0,0 08:50:50,0,0,0 08:50:51,0.2,0,-0.2088 P-Part 08:50:52,0.2,0,-0.2291667 Integrator-Part 08:50:53,0.2,0,-0.24983339 08:50:54,0.2,0,-0.27016668 08:50:55,0.2,0,-0.2904 08:50:56,0.2,0,-0.31116659 08:50:57,0.2,0,-0.33133323 08:50:58,0.2,0,-0.35149986 08:50:59,0.2,0,-0.37216648 08:51:00,0.2,0,-0.39266644 Here the reference value changed from 0.2 to 0 08:51:01,0,0,-0.21149975 There the P-Part = 0 ond we only the the I-Part 08:51:02,0,0,-0.21149975 08:51:03,0,0,-0.21149975 08:51:04,0,0,-0.21149975 08:51:05,0,0,-0.21149975 08:51:06,0,0,-0.21149975 08:51:07,0,0,-0.21149975 08:51:08,0,0,-0.21149975 08:51:10,0,0,-0.21149975 08:51:11,0,0,-0.21149975 08:51:12,0,0,-0.21149975 08:51:13,0,0,-0.21149975 08:51:14,0,0,-0.21149975 08:51:15,0,0,-0.21149975 08:51:16,0,0,-0.21149975 08:51:17,0,0,-0.21149975 08:51:18,0,0,-0.21149975 08:51:19,0,0,-0.21149975 08:51:20,0,0,-0.21149975 08:51:21,-0.2,0,-0.0061664115 Here the reference value change from 0 to 0.2 08:51:22,-0.2,0,0.014166921The P-Part is added to the output value 08:51:23,-0.2,0,0.034500255The I-Part is added to the output value 08:51:24,-0.2,0,0.054833595 08:51:25,-0.2,0,0.075333593 08:51:26,-0.2,0,0.095666916 08:51:27,-0.2,0,0.11616691 08:51:28,-0.2,0,0.13683358 08:51:29,-0.2,0,0.15716694 08:51:30,-0.2,0,0.17766697 08:51:31,-0.2,0,0.19833365 08:51:32,-0.2,0,0.21866701 08:51:33,-0.2,0,0.23900037 08:51:34,-0.2,0,0.25966703 08:51:35,-0.2,0,0.2832 08:51:36,-0.2,0,0.30016693 08:51:37,-0.2,0,0.32083356 08:51:38,-0.2,0,0.34100019 08:51:39,-0.2,0,0.36150015 08:51:40,-0.2,0,0.38200011 08:51:41,-0.2,0,0.40266674 08:51:42,-0.2,0,0.4231667 08:51:43,0,0,0.2318Here the reference value change from -0.2 to 0 08:51:44,0,0,0.2318The P-Part is subtracted and we have only the I-Part 08:51:45,0,0,0.2318
[Flightgear-devel] RE: Feedback: Building SimGear CVS under Cygwin
Hi all, further help is needed, please! /1. I have experienced exactly the same problem using WinCVS. The solution is /drastic - you have to delete the source directory created by WinCVS and /start over with a clean checkout using the command line cvs provided as part /of Cygwin. Then ./autogen, ./configure etc. /.. /Vivian Thank you Vivian, this helped me to solve the problem but I got another one :-( Might be anyone had the same problem already solved? What I did until now: 1. installed plib-1.8.4 without problems (./configure; make; make install) 2. built SimGear CVS with Cygwin cvs command after deleting all old stuff 3. unpacked and built zlib-1.1.4 (tar xvfz ..; ./configure; make; make install) 4. SimGear/source ./autogen.sh ./configure make - ERROR! ... ... swap_test.cpp: In function 'int main()': swap_test.cpp:12: Fehler: Ungueltige Umformung von unsigned int* in uint32_t* (swap_test.cpp:12: error: not valid conversion of unsigned int* to uint32_t* swap_test.cpp:12: Fehler: Argument 1 von void sgEndianSwap(uint32_t*) wird initialisiert (swap_test.cpp:12: error: argument 1 of void sgEndianSwap(uint32_t*) gets initialised) make[3]: *** [swap_test.o] Fehler 1 (... error 1) make[2]: *** [all-recursive] Fehler 1 (... error 1) make[1]: *** [all] Fehler 2 (... error 2) make: *** [all-recursive] Fehler 1 (... error 1) ANY IDEAS? 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
Re: [Flightgear-devel] RE: Feedback: Building SimGear CVS under Cygwin
Georg Vollnhals wrote: swap_test.cpp: In function 'int main()': swap_test.cpp:12: Fehler: Ungueltige Umformung von unsigned int* in uint32_t* Good heavens what a pile of crap is this stdint stuff. Does no-one have a clue on how to define the *int*_t properly? Anyhow, I have fixed this in CVS now Georg, thanks for reporting this. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Transfer function elevator/climb for root locus analyse for JSBSIM
Hello all, is it possible to derive the transfer function from jsbsim fdm coefficients. I know the way to calculate the parameters like Clalpha for a operation point. But for a root locus analyse I need the transfer function (Root locus is used to calculate the PID-Controller parameter) I would like to start with a function, which descripe the dependency of climb to elevator deflection climb = f(elevator-deflection) I want to use SCILAB (free matlab ;)) to analyse the close-loop behaviour. Any help will be appreciated Kind regards Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] RE: Feedback: Building SimGear CVS under Cygwin
Georg Vollnhals Hi all, further help is needed, please! /1. I have experienced exactly the same problem using WinCVS. The solution is /drastic - you have to delete the source directory created by WinCVS and /start over with a clean checkout using the command line cvs provided as part /of Cygwin. Then ./autogen, ./configure etc. /.. /Vivian Thank you Vivian, this helped me to solve the problem but I got another one :-( Might be anyone had the same problem already solved? What I did until now: 1. installed plib-1.8.4 without problems (./configure; make; make install) 2. built SimGear CVS with Cygwin cvs command after deleting all old stuff 3. unpacked and built zlib-1.1.4 (tar xvfz ..; ./configure; make; make install) 4. SimGear/source ./autogen.sh ./configure make - ERROR! Yup - you were too soon - there were problems with SimGear/FlightGear-cvs under Cygwin. These were corrected yesterday. Try again :-). You don't need to do anything with zlib-1.1.4. If you are using Norman Vines pre-prepared OpenAL stuff there is a further problem, I think, you will need an earlier version of FlightGear configure.ac ver 1.3 will do. DO NOT DOWNLOAD THIS WITH WINCVS OR YOU WILL BE STARTING OVER. Guess who forgot ... duh. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Microsoft artwork (!) in the 707 panel
On Wed, 28 Sep 2005 17:06:40 -0400, Jim wrote in message [EMAIL PROTECTED]: From: Andy Ross Hans-Georg Wunder wrote: In the package there is a GPL-license. If this is enough, then everything is OK regarding the panel. Unfortunately, due to clear evidence of (minor, admittedly) copyright violation, this is not enough. The issue isn't license compatibility, it is copyright ownership. John Carty cannot legally grant a license to artwork he does not own. We need to be 100% sure that the people granting the license (GPL or otherwise) own the copyright. I wrote John a mail and told him, what Iam going to do, but I got no answer. At this point, I think a statement from Mr. Carty is really the only thing that will be acceptable. It's possible he didn't understand the rules, and generated some of the artwork via screenshots of other aircraft in MSFS. That's a showstopper for us. Obviously Innis's model and FDM configuration are fine. But my strong suggestion is not to commit the panel until we can trace the history of every image in it. Andy's view on this is the same as my own. If OSS developers learned a lesson from SCO it is this. Although it is hard to see now, some day FGFS or a derivative is likely to be a real threat to whatever is left of the future MSFS desktop market and the last thing we want to do is give some bunch of copyright lawyers a toehold. ..aye. http://groklaw.net/ We're not too worried about tSCOG anymore, ;o) but we do peel off layer by layer onion peel style who's done what etc and who's next and why and how etc. ;o) So, John Carty, your statement, please. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug
The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=FlightGear-0.9 should fix this. This is what would happen when you set delta_u_n = u_max - u_n_1 : delta_u_n (u_max - u_n_1) 0.6 (0.5 - 0.0) : true delta_u_n = u_max - u_n_1 = 0.5 - 0.0 = 0.5 u_n = u_n_1 + delta_u_n = 0.0 + 0.5 = 0.5 and at the next time step let's assume that delta_u_n But consider this scenario for next step: Assume Kp = 1. This means that the previous error e_n_1 = 0.6. Say the new error e_n = 0.5. delta_u_n = Kp(e_n - e_n_1) = -0.1 Now, this new delta when aplied to the saturated output will be: u_n = 0.5 - 0.1 = 0.4 ; The correct proportional component of the output should be 0.5 In the ideal scenario, the delta_u_n = -0.1 would be applied to u_n=0.6 to yield 0.5, but because of the saturation, the P component becomes offset. This offset will be compensated for by the I component after some time, but it shouldn't have to be. As I said before, I think the best solution is to track the true PID output (in this case 0.6) while outputing the saturated value and disable the integral component (with either a hard or soft limit) when the controller is saturated. Hans-Georg's suggested scaling of ep_n essentially fixes the problem. The one technical problem I have come to see with this approach is that it assumes that the entire output movement into saturation is due to the P part: ep_n = ep_n*u_max/(delta_u_n+u_n) This says that, for example, if the output only moved by half of the calculated increase because of saturation, we should change the current proportional position (saved in ep_n_1)to half its calculated value. This basically works because any large movements in one step are likely to be dominated by P, and in most (if not all) cases the error generated when the output moves back out of saturation is small and quickly compensated by the I part. I believe this is why the output of his latest test run using his fix returns to 0.0019 or 0.00175 after the reference is returned to 0, rather than returning to exactly u_n=0. Clearly this error is small and will not represent a proplem in this case. -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re: [Flightgear-devel] 2 Questions: Terrain data? Flight Sim
Gosh I don't know, a Piper Cub UAV would be pretty impressive. :-) Michael Selig has a screenshot of one on his web page, so he might know where you can get yourself a UAV 3D model. Google uiuc selig flightgear Best, Jim Jim, I did as you suggested, and it appears he has a UAV on there, but all of the aircraft are for a VERY old version of FG (0.7.2) and examination of the files shows that they're not even close to the same sort of format that the 0.9.8 codebase uses. Bummer! Anyone else have any ideas or could they tell me how to get the predator model from flightsim.com 's file library converted over to work on FG. Heck, at this point, if somebody could do the conversion for me I might even be able to get my company to kick some $$$ your way (although we'd really prefer an even smaller UAV model, like a Raven or a Silverfox or Hunter or something like that.) --Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Another error: Building SimGear CVS under Cygwin
Hi Erik and Vivian, thank you for your quick replies. I am sorry to show up here again with another error message .. but one solved, the next came :-/ Erik: /Anyhow, I have fixed this in CVS now Georg, thanks for reporting this. /Erik This is solved, thank you! but this is the (very long, sorry) error output of make: (BTW: getting this errors is very educational. I had to read nearly an hour until I found out how to redirect the *error* messages under Cygwin bash with 2. But the bash and me get more and more friends :-) ) (not translated, I only changed the German expressions Zeichen = char Fehler = error) In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/vector:72, from ../../simgear/math/sg_types.hxx:40, from ../../simgear/misc/sg_path.hxx:36, from ../../simgear/ephemeris/stardata.hxx:31, from ephemeris.hxx:45, from ephemeris.cxx:28: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:522: error: expected unqualified-id vor (-char /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_fill_insert(std::_Bit_iterator, size_t, bool)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:823: error: expected unqualified-id vor (-char In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/vector:75, from ../../simgear/math/sg_types.hxx:40, from ../../simgear/misc/sg_path.hxx:36, from ../../simgear/ephemeris/stardata.hxx:31, from ephemeris.hxx:45, from ephemeris.cxx:28: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In member function `void std::vector_Tp, _Alloc::_M_fill_insert(__gnu_cxx::__normal_iteratortypename _Alloc::pointer, std::vector_Tp, _Alloc , size_t, const _Tp)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:307: error: expected unqualified-id vor (-char /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In member function `void std::vector_Tp, _Alloc::_M_range_insert(__gnu_cxx::__normal_iteratortypename _Alloc::pointer, std::vector_Tp, _Alloc , _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:384: error: expected unqualified-id vor (-char make[3]: *** [ephemeris.o] error 1 make[2]: *** [all-recursive] error 1 make[1]: *** [all] error 2 make: *** [all-recursive] error 1 Is this a gcc-error or error in ephemeris.* ??? Vivian: /If you are using Norman Vines pre-prepared OpenAL stuff there is a further /.. /Vivian If I *only* get to the FlightGear stuff then I'll remember your hint. Erik and Vivian, thank you once again! Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Another error: Building SimGear CVS under Cygwin
Georg Vollnhals wrote: But the bash and me get more and more friends :-) ) (not translated, I only changed the German expressions Zeichen = char Fehler = error) No need, I can read German (and understand it as well). In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/vector:72, from ../../simgear/math/sg_types.hxx:40, from ../../simgear/misc/sg_path.hxx:36, from ../../simgear/ephemeris/stardata.hxx:31, from ephemeris.hxx:45, from ephemeris.cxx:28: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:522: error: expected unqualified-id vor (-char /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_fill_insert(std::_Bit_iterator, size_t, bool)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:823: error: expected unqualified-id vor (-char In file included from Ouch, this is a tough one. I've searched all over the place, but g++ 3.4.x seems not to accept one or more of the declarations in math/sg_types.h which is accepted by almost all other compilers. I have no clue which one it doesn't accept :-( Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Another error: Building SimGear CVS under Cygwin
Quoting Erik Hofman: Georg Vollnhals wrote: But the bash and me get more and more friends :-) ) (not translated, I only changed the German expressions Zeichen = char Fehler = error) No need, I can read German (and understand it as well). In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/vector:72, from ../../simgear/math/sg_types.hxx:40, from ../../simgear/misc/sg_path.hxx:36, from ../../simgear/ephemeris/stardata.hxx:31, from ephemeris.hxx:45, from ephemeris.cxx:28: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:522: error: expected unqualified-id vor (-char /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_fill_insert(std::_Bit_iterator, size_t, bool)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:823: error: expected unqualified-id vor (-char In file included from Ouch, this is a tough one. I've searched all over the place, but g++ 3.4.x seems not to accept one or more of the declarations in math/sg_types.h which is accepted by almost all other compilers. I have no clue which one it doesn't accept :-( Does it help to put #include vector *before* #include simgear/compiler.h in math/sg_types.hxx -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problem with HUD
I am having a problem porting a hud display that I wrote for use in FG8.0 up to 9.8. It hangs at the instruction in drawHUD() : for_each(HUD_deque.being(), HUD_deque.end(), HUDdraw()); with a segfault. The problems seems to be that there are 18 labels in hudlabel.xml, all 18 of which pass the instruction, but the program carries HUD_deque.size() as 20! Looks like it is looking for superfluous information. Where does it set the deque size, and how could it be going wrong? Thank you, Rex du Pont [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Flight plan and startup in air
[cc'd to flightgear-devel b/c of the internals explanation] Jeff McBride wrote: Andy Ross wrote: The current helicopter FDM does not support variable rotor speed. The spin up is entirely animation. You are flying just fine. I don't know what FDM you are using, but when I fly the bo105 (using 0.9.8), there is definitely a spin up time where I have only partial lift. Or else it's a very good animation:). OK, I had to go look this one up. It turns out that there is a *boolean* property controling engine-on for the helicopter FDM, which is wired to the engine[0] magnetos property by the FDM configuration. This in turn is driven via a timer by Melchior's Nasal code in bo105.nas. This inspects the /sim/model/bo105/state property to determine what the current state is, and to watch for changes. The default startup state defined in bo105-set.xml is 0, indicating off. You should be able to change /sim/model/bo105/state to 2 to start with the engine on, either in bo105-set.xml or (I think, if I understand the precedence correctly) your preferences.xml file, or the rc file, or the command line. But again note: this is a boolean property. There is no actual suppot for engine starup or shutdown in the helicopter FDM (which, now that I think about it, serves as good evidence that an ugly eye-candy hack is in fact an acceptable implementation of startup/shutdown for YASim. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Another error: Building SimGear CVS under Cygwin
Georg Vollnhals thank you for your quick replies. I am sorry to show up here again with another error message .. but one solved, the next came :-/ Erik: /Anyhow, I have fixed this in CVS now Georg, thanks for reporting this. /Erik This is solved, thank you! but this is the (very long, sorry) error output of make: (BTW: getting this errors is very educational. I had to read nearly an hour until I found out how to redirect the *error* messages under Cygwin bash with 2. But the bash and me get more and more friends :-) ) not really necessary - just copy/paste from the Cygwin window. (not translated, I only changed the German expressions Zeichen = char Fehler = error) In file included from /usr/lib/gcc/i686-pc- cygwin/3.4.4/include/c++/vector:72, from ../../simgear/math/sg_types.hxx:40, from ../../simgear/misc/sg_path.hxx:36, from ../../simgear/ephemeris/stardata.hxx:31, from ephemeris.hxx:45, from ephemeris.cxx:28: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:522: error: expected unqualified-id vor (-char /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_fill_insert(std::_Bit_iterator, size_t, bool)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:823: error: expected unqualified-id vor (-char In file included from /usr/lib/gcc/i686-pc- cygwin/3.4.4/include/c++/vector:75, from ../../simgear/math/sg_types.hxx:40, from ../../simgear/misc/sg_path.hxx:36, from ../../simgear/ephemeris/stardata.hxx:31, from ephemeris.hxx:45, from ephemeris.cxx:28: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In member function `void std::vector_Tp, _Alloc::_M_fill_insert(__gnu_cxx::__normal_iteratortypename _Alloc::pointer, std::vector_Tp, _Alloc , size_t, const _Tp)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:307: error: expected unqualified-id vor (-char /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In member function `void std::vector_Tp, _Alloc::_M_range_insert(__gnu_cxx::__normal_iteratortypename _Alloc::pointer, std::vector_Tp, _Alloc , _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:384: error: expected unqualified-id vor (-char make[3]: *** [ephemeris.o] error 1 make[2]: *** [all-recursive] error 1 make[1]: *** [all] error 2 make: *** [all-recursive] error 1 Is this a gcc-error or error in ephemeris.* ??? Well, all I can say is that it compiles here, using gcc 3.4.4 I have found it necessary to add the following to my bash_profile: LDFLAGS=-L/usr/local/lib CXXFLAGS=-pipe -O2 -Wall -DWIN32 -DNOMINMAX -DHAVE_WINDOWS_H CFLAGS=$CXXFLAGS export LDFLAGS export CXXFLAGS export CFLAGS Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Another error: Building SimGear CVS under Cygwin
Hi Fred, /Does it help to put #include vector *before* #include simgear/compiler.h in /math/sg_types.hxx /-Fred I CHANGED THE POSITION OF #include vector: ... #include vector #include simgear/compiler.h #include STL_STRING //#include vector (original position) #include simgear/math/point3d.hxx ... but the result was the same (error as described) Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2 Questions: Terrain data? Flight Sim
On Thursday 29 Sep 2005 15:05, Mike Kopack wrote: Gosh I don't know, a Piper Cub UAV would be pretty impressive. :-) Michael Selig has a screenshot of one on his web page, so he might know where you can get yourself a UAV 3D model. Google uiuc selig flightgear Best, Jim Jim, I did as you suggested, and it appears he has a UAV on there, but all of the aircraft are for a VERY old version of FG (0.7.2) and examination of the files shows that they're not even close to the same sort of format that the 0.9.8 codebase uses. Bummer! Anyone else have any ideas or could they tell me how to get the predator model from flightsim.com 's file library converted over to work on FG. Heck, at this point, if somebody could do the conversion for me I might even be able to get my company to kick some $$$ your way (although we'd really prefer an even smaller UAV model, like a Raven or a Silverfox or Hunter or something like that.) --Mike How soon do you need a model? I found a small basic 3-view of a Raven and it doesn't look as though it would be too difficult to knock a simple model up. A lot depends on how much detail you need. There's not a lot of detail in the 3-view I found and there wasn't many detail photos on Google either. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re: [Flightgear-devel] 2 Questions: Terrain data? Flight Sim
From: Mike Kopack Gosh I don't know, a Piper Cub UAV would be pretty impressive. Michael Selig has a screenshot of one on his web page, so he might know where you can get yourself a UAV 3D model. Google uiuc selig flightgear Best, Jim Jim, I did as you suggested, and it appears he has a UAV on there, but all of the aircraft are for a VERY old version of FG (0.7.2) and examination of the files shows that they're not even close to the same sort of format that the 0.9.8 codebase uses. Bummer! Anyone else have any ideas or could they tell me how to get the predator model from flightsim.com 's file library converted over to work on FG. Heck, at this point, if somebody could do the conversion for me I might even be able to get my company to kick some $$$ your way (although we'd really prefer an even smaller UAV model, like a Raven or a Silverfox or Hunter or something like that.) Hi Mike, The FS2000 model converted fine. You can find at the following links the converted model and texture file: http://www.spiderbark.com/fgfs/predator.ac http://www.spiderbark.com/fgfs/tblades.rgb By the time I recalled how to do the conversion I was done: There is a 3dconvert utility included with FlightGear that will read in the .mdl file and produce a .ac file (based on the extensions of the files named in the parameters e.g. 3dconvert filein.mdl fileout.ac). Then the indexed bmp file was loaded into gimp and converted to rgb (sgi) format. Finally I loaded the predator.ac into a text editor and did a global replace of the text tblades.bmp to tblades.rgb. BTW, the only textured portion of the model is the propellor disk, but since the aircraft are all white anyway...it looks fine. You could always add numbers. The only information in the flightsim.com archive is that the author is K.Furuya, with no copyright notice included in the package. Let me know when you have downloaded the files as I do not wish to leave them on the server for general distribution (i.e. outside the context of this discussion). Best regards, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
