[Flightgear-devel] KR-87
I found a bug in the KR-87 adf code. The ANT and ADF annunciators are wrong. After fixing this, how do I proceed to update the CVS repository? I've also modified the KR-87 instrument XML-file to make it behave acording to the Pilot's Guide from the Bendix/King website. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot in jsbsim
I played around with the wing-leveler example from Automatic flight in jsbsim. I noticed that the solution had the problem of intergator-windup. I tried to limit and/or clip the intergator component, but that didn't do what I thought it would. Does anyone have a solution to this problem? Note that cliping the summer (as the example does) does not solve the windup problem. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 9 Jan 2004 06:31:23 -0600, Jon Berndt [EMAIL PROTECTED] wrote: First of all, let me know how you played with the JSBSim wing-leveler example - I mean, did you use JSBSim in its standalone mode, or did you somehow integrate this with JSBSim within FlightGear. I ask, because I have never tried it within FlightGear, as I have not looked at how to make sure the FlightGear autopilot and the JSBSim flight control/autopilot features could be made to work independently - i.e. how to make a choice on which capability to use. I'd be concerned that they might end up fighting each other. Yes, I used FlightGear. I did a cut and paste into the c172p.xml file from the example code in the manual. I had to modify it a bit: I rederected the output into the fcs/roll-trim-cmd-norm property (the example uses some property under ap/) I figured that the autopilot should use the trim to control the aircraft, is this correct/reasonable? I'm pretty sure that the jsbsim autopilot and FlightGear's autopilot are not fighting each other. I haven't activated the FlightGear autopilot at all! And it works great (the jsbsim one), exept for the integrator windup. Also, can you explain what you mean by integrator windup? Integrator windup is a problem with all PID controllers. When the actuator, in our case the roll trim, goes into saturation (uses all available trim deflection), and still is unable to bring the wings level, the integrator keeps on integratin the error. Problems arise when the actuator (roll trim) goes out of saturation. By then the integrator has been winding up it's contribution to the PI controller output signal. The integrator then has to unwind, the time it takes to unwind ofcourse depends on how long it has been winding-up. While the integrator is unwinding the controller isn't working as it is supposed to. I provoked this actuator saturation by pushing the stick to the right, the autopilot tried to counter this with the roll trim. As I pushed the stick further to the right eventually the roll trim was unable to keep the wings level. The roll trim goes into saturation (full deflection), but is still not able to keep the wings level. This is when the intergator begins winding up. Hope this explains a bit! I've run tests in JSBSim with that component and it holds steady for quite a while until I stopped the test. I am guessing you mean that the aircraft grows a bias over time. When the wings are level and the actuator (roll trim) stays out of saturation, this PI controller works great. It does not grow a bias as long as the actuator is able to do it's job, it only grows a bias when the actuator does not have enough power (deflection angle) to do it's job. The solution to this is to stop the intergation when the actuator goes into saturation. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 9 Jan 2004 13:58:11 -, Richard Bytheway [EMAIL PROTECTED] wrote: Knowing nothing about the jsbsim structure, and only a little about PID control, could you arrange the control loop so that the Integral term is only updated when the output is between 2% and 98%? This is the solution I'm looking to implement, but sadly my knowlege about the jsbsim structure is so limited that I could not think of a way to do it. Maybe the SWITCH component could be used as an if structure? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 09:15:53 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: On Fri, 09 Jan 2004 15:24:15 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: This is the solution I'm looking to implement, but sadly my knowlege about the jsbsim structure is so limited that I could not think of a way to do it. Maybe the SWITCH component could be used as an if structure? Yes, I think this is exactly a possibility. Have you seen this paper: http://jsbsim.sourceforge.net/AutomaticFlightInJSBSim.pdf ?? Yes, that's where I cut and pasted the wing leveler example from :-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 09:13:33 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: On Fri, 09 Jan 2004 14:52:28 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: The solution to this is to stop the intergation when the actuator goes into saturation. Aha! Good explanation. Yes, I think this should not be too hard to fix, but I don't have time to play with that myself at this time. I've found more problems caused by the integrator: When our jsbsim autopilot is deactivated (ap/wingslevel_hold = false) the integrator is still integrating the difference between actual roll angle and desired roll angle (zero). So if the pilot makes a bank to one direction, and then brings the wings level, the integrator has been winding up during the bank. If the pilot then activates the autopilot the contribution from the integrator will be much more than it should be. If we had the ability to reset the integrator to an arbitrary value, we could reset it to zero whenever the autopilot was deactive. To fix the windup when it was active, we could reset it to the walue it had when saturation occured. I think this should be implemented in the jsbsim source code, not in the fdm_config xml file. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 15:51:40 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: Yes. And it is true there probably should be an initialization capability for filters, integrators, etc. I'll try and look into this very soon. How about adding a new flight control component: PID controller?! I've been searching my textbooks on control systems and found a few PID controller algorithms. I could begin to implement one that takes care of the integrator windup problem and has some other usefull features. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Tue, 20 Jan 2004 15:09:02 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Sounds reasonable. Is the current height above terrain in the property tree someplace? FWIW (and hopefully this doesn't mean major breakage) I've been considering some changes to the autopilot infrastructure to make it more flexible. For instance, we (or at least I) could really use a mode to hold speed with pitch, or hold pitch with elevator. And it would be nice to be able to support some of the more advanced FCS concepts that right now are only accessible to JSBSim models (things like yaw dampers, and other fly-by-wire type stuff.) Regards, Curt. Let me share my thoughts about the autopilot: * I would like to see the autopilot move from c++ code into the instrument configuration xml-files. * The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was broken. Failures in the underlying instruments and systems would affect the autopilot. * A PID-controller that can be accessed from the instrument configuration files. This could be used to build the autopilot controller structure as an instrument. This means that one could build different autopilot instruments for different aircraft. The Cub for example might have a simple autopilot with only heading hold and altitude hold. And because the Cub does not have an attitude indicator instrument, a wing-leveler would not be available. And in addition the heading hold would not be allowed to use roll information. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Thu, 22 Jan 2004 17:28:51 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: As far as I am aware on any autopilot I ever worked on the autopilot/autothrottle took no information from the instruments.It provides information to the instruments so the pilot can see what the autopilot is doing.But to fly the A/C the autopilot could not careless what the instruments are doing. After studying the Bendix KFC 225 Pilot's Guide (available on the Bendix/King website), I am under the impression that this particular autopilot reads information from the instruments: Attitude Gyro Altimeter Compass System Optionally a GPS and Optionally a Radar Altimeter This was the autopilot that I had in mind. The autopilot takes its information from CADS Corrected Air Data System INS or U Inertial Navigation System or Unit or GPS Radio Navigation Unit Radio Altimeter Auto Pilot Control panel Compass Controler I don't think all theese units are available in a light aircraft like the C172 ;-) All these units except for the control panel are blackbox's down in the bowels.Also the autopilot unit is down there to. So to simulate the Autopilot you would need to simulate all these box's outputs. Yes! Alternativly you could just add there outputs to the property tree,quite a few already are,and make the autopilot/autothrottle that way. This is all I used to do the 737 autopilot.And while there are a few things that need to be done the property tree I found to be very good. Hope this helps Cheers Innis _ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Wed, 21 Jan 2004 22:28:22 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Roy Vegard Ovesen wrote: Let me share my thoughts about the autopilot: * I would like to see the autopilot move from c++ code into the instrument configuration xml-files. This is my general plan. Right now I have the autopilot config in a separate .xml file * The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was broken. Failures in the underlying instruments and systems would affect the autopilot. Yup, each autopilot component will be able to take input from any property, and output to any other property. As long as we have the instrument values modeled and placed in the property tree, we can use them. And I firmly believe that we _should_ use the instrument values because in my mind using /position/... and /velocities/... would be cheating, theese perfect values are _not_ available in the real world. The trick will be for someone who knows a little about autopilots to be able to tell us what inputs drive what functions. I have a masters-degree in control theory, and I think that an autopilot is just like any other plant that has to be controlled. The most important thing is to have a good knowledge about the process that is to be controlled. So maybe the best consultant for an autopilot would be a good pilot. He/She _is_ the autopilot (think about it!). I've been hacking things out here a bit this evening and here's what I've come up with for a simple proportional wing leveler. All of this is in a state of flux, is subject to change, and only exists on my local HD. I'll intersperse some explanatory comments ... autopilot.xml: proportional nameWing Leveler (Turn Coordinator based)/name I implemented (in jsbsim) a wing leveler or I should say a roll-angle holder that was roll-angle based. It's all a matter of preference, I think (turn coordinator based or roll-angle based or ...) enable !-- enable this component when the defined property equals the specified value -- prop/autopilot/locks/heading/prop valuewing-leveler/value /enable input !-- the input source -- prop/instrumentation/turn-indicator/indicated-turn-rate/prop /input target !-- what we want to drive the input value to, this can also be a property name -- value0.0/value /target output !-- the output property name -- prop/controls/flight/aileron/prop /output config !-- output = (target - input) * factor + offset -- factor0.5/factor !-- I don't know if it makes sense to offer an offset here, but it's easy to add and I've seen similar things other places in the code so I stuck it in. -- offset0.0/offset In PID controllers an offset is often to set the working-point. The point where: offset = output = target - input = 0. The aileron deflection that results in zero turn rate. This aileron deflection doesn't have to be zero, as we all have experienced :-) Another application for the offset is to attatch it to the manual actuator, in our case the stick. This means that the pilot can still control the airplane when the autopilot is engaged ;-) , and when the autopilot is disengaged, the output = offset = stick = pilot is flying. post !-- I might be better off moving this to the output section, but this lets us clamp the output result -- clamp min-1.0/min max1.0/max /clamp /post /config /proportional So if you set /autopilot/locks/heading = wing-leveler, this component will become active and start driving the turn rate to zero using the ailerons. A proportional only controller will _not_ be able to drive the turn rate to zero. If the working-point were zero aileron deflection, then this controller would work but, as stated earlier, the working point is moving around. In general you need at least proportional and intgral components, in a controller, to avoid this static-error. Here's a more complicated two stage heading bug follower (still using simple proportional control): This is called cascade control. !-- this first stage calculates a target roll degree based on the difference between our current heading and the heading bug heading. It writes the result to a temporary property name. This temp property is the input to the second stage. Both stages use the same enable property and value. -- proportional nameHeading Bug Hold (DG based) Calc Target Roll/name enable prop/autopilot/locks/heading/prop valuedg-heading-hold/value /enable input prop/instrumentation/heading-indicator
[Flightgear-devel] Autopilot PID algorithm
On Thu, 22 Jan 2004 11:46:00 -0600, Curtis L. Olson [EMAIL PROTECTED]
wrote:
I have a PID controller algorithm from one of my textbooks, I could
send it to you with lots of comments.
If it's not too much typing for you, it would be worth taking a look at.
Ok! Here is the PID controller algorithm that I would like to see
implemented:
delta_u_n = Kp * [ (ep_n - ep_n-1) + ((Ts/Ti)*e_n)
+ (Td/Ts)*(edf_n - 2*edf_n-1 + edf_n-2) ]
u_n = u_n-1 + delta_u_n
where:
delta_u : The incremental output
Kp : Proportional gain
ep : Proportional error with reference weighing
ep = beta * r - y
where:
beta : Weighing factor
r: Reference (setpoint)
y: Process value, measured
e : Error
e = r - y
Ts : Sampling interval
Ti : Integrator time
Td : Derivator time
edf : Derivate error with reference weighing and filtering
edf_n = edf_n-1 / ((Ts/Tf) + 1) + ed_n * (Ts/Tf) / ((Ts/Tf) + 1)
where:
Tf : Filter time
Tf = alpha * Td , where alpha usually is set to 0.1
ed : Unfiltered derivate error with reference weighing
ed = gamma * r - y
where:
gamma : Weighing factor
u : absolute output
Index n means the n'th value.
Inputs:
enabled ,
y_n , r_n , beta=1 , gamma=0 , alpha=0.1 ,
Kp , Ti , Td , Ts (is the sampling time available?)
u_min , u_max
Output:
u_n
if (enabled)
{
// Calculates proportional error:
ep_n = beta * r_n - y_n;
// Calculates error:
e_n = r_n - y_n;
// Calculates derivate error:
ed_n = gamma * r_n - y_n;
// Calculates filter time:
Tf = alpha * Td;
// Filters the derivate error:
edf_n = edf_n_1 / (Ts/Tf + 1)
+ (ed_n * (Ts/Tf) / (Ts/Tf + 1);
// Calculates the incremental output:
delta_u_n = Kp * ( (ep_n - ep_n_1)
+ ((Ts/Ti) * e_n)
+ ((Td/Ts) * (edf_n - 2*edf_n_1 + edf_n_2)) );
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) )
delta_u_n = 0;
else if ( delta_u_n (u_min - u_n_1) )
delta_u_n = 0;
// Calculates absolute output:
u_n = u_n_1 + delta_u_n;
// Updates indexed values;
u_n_1 = u_n;
ep_n_1 = ep_n;
edf_n_2 = edf_n_1;
edf_n_1 = edf_n;
}
else if (!enabled)
{
u_n = 0;
ep_n = 0;
edf_n = 0;
// Updates indexed values;
u_n_1 = u_n;
ep_n_1 = ep_n;
edf_n_2 = edf_n_1;
edf_n_1 = edf_n;
}
Comments?
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalization of Live-CD
On Mon, 26 Jan 2004 09:06:16 +0100, Ronny Standtke [EMAIL PROTECTED] wrote: Hi, I am in the process of i18n of the Live-CD. I need your assistance here. I only speek German and my own version of English. I need the sentence For starting in insert your language here please type: In norwegian: For å starte på norsk skriv: -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New autopilot
On Sun, 25 Jan 2004 22:19:48 -, Jim Wilson [EMAIL PROTECTED] wrote: These are all controllers for ailerons, elevators, rudders, etc. A small and easily definable set which is ideal for subclassing. Maybe we could have a subclass for each of these controls rather than trying to abstract a generic controller class. I disagree. I think we should have one generic controller class. Remember that we don't want to control the ailerons, we want to control the roll angle or the turn rate through the ailerons. We tell the controller that we want 20 degrees left bank angle and then the controller figures out what aileron deflection is required. We don't tell the controller that we want 7 degrees aileron deflection, that we can (easily) do with the stick. In the same way we want to control the pitch or the vertical speed through the elevator, we don't want to control the elevator. My point is that there are usually more than one thing that can be controlled through the various control-surfaces. And it would then be limiting the flexibility if there were a specific controller for the ailerons that used roll angle as it's set-point/reference/desired value. Then these could have both generic and unique properties that are somewhat easier to configure. The xml for the AP configuration would include a controller-type property that would imply certain characteristics (such as integrating roll limits in the aileron controller). Every controller would need limits in its output because when you think about it every actuator, be it ailerons, elevator, rudder, thrust, etc. has a limit. It will also be important not to have more than one controller for a given type active at any one time. That would be the responsibility of the autopilot designer. If he/she designed a control structure that used two separate controllers that acted on the ailerons, that would be his/her problem. In fact it might turn out to be a good thing. ;-) Let me propose an altitude-hold control structure using generic PID controllers: First off I would control the vertical speed through the elevator control-surface: Desired Vertical Speed--PID Controller--Elevator ^ | Sensed Vertical Speed The output of the PID-Controller would have to be limited to the elevator-deflection angle limitations of the particular aircraft. Actually I would set the limits a bit below the limitations of the aircraft. Now I can set the Desired Vertical Speed to what I want. It is my responsibility to set it to a value that I know/think the aircraft is capable of. Now, in order to climb to my desired altitude I would need a positive Vertical Speed. So I design a structure that controls altitude through Vertical Speed. If I want higher altitude I demand positive Vertical Speed etc. This leads to the final control structure: Desired Altitude--PID--Desired Vertical Speed--PID--Elevator ^ ^ | | Sensed AltitudeSensed Vertical Speed The output from the first PID controller offcourse has to be limited to the vertical speed capabilities of the aircraft. If its not, the first PID will demand more vertical speed than the aircraft can handle. Now it becomes the pilot's resposibility to limit the Desired Altitude within the capabilities of the aircraft. Note that the two PID controllers in this example are of the same generic class. There is no principal differense between the controller that controls the Vertical Speed and the one that controls Altitude. The two controllers have to be tuned to achieve stability and smoothness. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 13:13:44 -, Richard Bytheway [EMAIL PROTECTED] wrote: That would be the responsibility of the autopilot designer. If he/she designed a control structure that used two separate controllers that acted on the ailerons, that would be his/her problem. In fact it might turn out to be a good thing. ;-) Does this imply that we also need a summer class/unit/module which can take the outputs from various controllers and sum them to feed to the actuator? Yes, a summer class/unit/module would be a handy tool. A gain class/unit/module would also be usefull. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 16:21:19 -, Jim Wilson [EMAIL PROTECTED] wrote: That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Do you mean a different controller algorithm for the different control surfaces? Or do you mean a different configuration for each control surface? I think we are misunderstandig eachother. Let me try to show what I think that you mean. Say we have two controllers, one is acting on the ailerons and one acting on the elevator. The one acting on the ailerons allows us to set a desired roll angle. The one on the elvator to set a desired pitch angle. Now do you mean that there should be any differences in the algorithms of these two controllers because they are controlling different control surfaces? They do not interoperate. On my Altitude Holder Deluxe[TM] they do. :-) Generally you will operate the system in a climb or descent mode using various techiniques (pitch hold, vs target, etc). Altitude hold is queued in ARM mode (armed) to take effect when the aircraft reaches an altitude that is within X feet of the target. At which time it switches to an altitude hold mode. AFAIK there are some aircraft that will even fly into the ground if you setup a descent and ARM a target altitude above where the aircraft is. That's another strategy. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 09:10:23 -0800, Andy Ross [EMAIL PROTECTED] wrote: I'd strongly suggest an architecture where the autopilot specifies a black box, with all input and output done via property nodes: ../roll-rate -++---+ /controls/elevator ../yaw-rate -+-- | Autopilot | -- /controls/ailerons ../heading -++---+ /controls/... What's inside the black box? That's what I want to configure. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 18:18:36 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. If nobody knows what's inside the autopilot, how can we make one? I want do design the black box, that is the kind of flexibility I'm looking for. Besides, I don't think it makes sense to have black boxes in an open source project. ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 22:30:17 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. I'm sure the performance of the current autopliot system is very good. But I think that it's not very flexible. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Here is my list of things that I think are wrong or should I say bad: * All aircraft have the same autopilot * Some functions are missing, like pitch-hold, and my favourite: aoa-hold ;-] * You can't tune the controllers By tuning I mean the manipulation of the proportional-, integral- and derivate-gains to achieve stability and smoothness. * Recognizing that there are a number of different strategies to implement a wing-leveler, or any other function, you are tied to the one that is hardcoded in C++. * The controller algorithm don't have integrator anti-windup (wich I consider essential) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel action set (feature request)
On Tue, 27 Jan 2004 18:17:53 -0600, David Culp [EMAIL PROTECTED] wrote: Panel actions presently come in three types: 1. toggle 2. adjust 3. swap For Innis' new 737 panel we could use a set action, that will set a property to the value of another property. For instance, when the V/S switch is pushed the property /autopilot/settings/vertical-speed-fpm should be set to the airplane's current vertical speed. I used this action to achive this effect: binding commandproperty-assign/command property/autopilot/settings/altitude-ft/property property/instrumentation/altimeter/indicated-altitude-ft/property /binding .../altitude-ft is assigned the value of .../indicated-altitude-ft -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a generic pid algorithm? Would we want to build in hooks to the generic pid algorithm so we can set up these sorts of limits? I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. As I understand it, the autothrottle predicts the airspeed 10 seconds ahead of time, and uses that as the input. I didn't know this, but it seems to me that this strategy is something that some autopilot designer has found out that this would be a good thing. If I were to design a autothrottle, knowing nothing about past autothrottle experience, I would use the current airspeed as input. Would the differential component of the PID algorithm be able to account for this? That might just do the trick. Would we want some code someplace that puts the predicted speed into the property tree for the generic pid algorithm to use, or would we want to build in some sort of property prediction ability into the pid algorithm (in case the 'd' component doesn't quite do what we want?) I think a hack is the way to go, and if we can use Nasal to do it we can implement this hack, the one-eighty-hack and any other hack that we might need. By the way, did you get my reply with answers and the updated PID algorithm?? I'm not sure I got through your spam-filter. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Thu, 29 Jan 2004 01:45:18 -, Jim Wilson [EMAIL PROTECTED] wrote: But to go back to the C172 example, does anyone actually understand how this issue is handled in a cessna autopilot or any of the others that might be installed in a 172? Will it stall the aircraft? Or...hmmm...trying to remember... does the 172 even have an AP for the pitch axis? A quick browse to the Cessna web site reveals that the C172 can be delivered with the KAP 140 Two Axis w/Altitude preselect Autopilot from Bendix/King. I just downloaded the Pilot's Guide from this link: http://www.n612sp.com/KAP%20140%20AUTOPILOT.pdf After browsing through this document, it is my understanding that the autopilot will stall the aircraft because it has no input telling it speed or angle-of-attack. I think Pilot's Guides could be waluable references when we begin to implement real world autopilots. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Thu, 29 Jan 2004 11:40:38 +0100, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I just downloaded the Pilot's Guide from this link: http://www.n612sp.com/KAP%20140%20AUTOPILOT.pdf It seems that this pdf file does not contain the entire document. For the complete document use this link: http://bkweb01.ais.honeywell.com/static/bk_club/pilotguides/techpubs/006-18034-_0.pdf -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS Compile
1.10.4-2 ed 0.2-1 ELFIO1.0.0-1 enscript 1.6.3-3 expat1.95.5-1 expect 20030128-1 figlet 2.2-1 file 4.02-1 fileutils4.1-1 findutils4.1.7-4 flex 2.5.4-2 gawk 3.1.2-2 gcc 3.2-3 gcc-mingw20020817-5 gcc2 2.95.3-10 gdb 20030303-1 gdbm 1.8.0-5 gettext 0.11.5-1 gettext-devel0.11.5-1 ghostscript 7.05-2 ghostscript-base 7.05-2 ghostscript-x11 7.05-2 gnupg1.2.1-1 gperf2.7.2-1 grep 2.5-1 groff1.18.1-2 gsl 1.3-1 guile1.6.0-1 guile-devel 1.6.0-1 guile-doc1.6.0-1 gzip 1.3.3-4 indent 2.2.8-1 ioperm 0.4-1 irc 20010101-1 jbigkit 1.4-1 jpeg 6b-7 keychain 1.9-1 less 378-1 libbz2_0 1.0.2-1 libbz2_1 1.0.2-2 libcharset1 1.8-2 libdb3.1 3.1.17-2 libgdbm 1.8.0-5 libgdbm-devel1.8.0-5 libguile12 1.6.0-1 libguile14 1.5.6-5 libiconv 1.8-2 libiconv21.8-2 libintl 0.10.38-3 libintl1 0.10.40-1 libintl2 0.11.5-1 libkpathsea3 2.0.2-1 libltdl3 1.5-1 libncurses-devel 5.3-1 libncurses5 5.2-1 libncurses6 5.2-8 libncurses7 5.3-1 libpng 1.2.5-1 libpng10 1.0.15-1 libpng10-devel 1.0.15-1 libpng12 1.2.5-1 libpng12-devel 1.2.5-1 libpng2 1.0.12-1 libpopt0 1.6.4-4 libreadline4 4.1-2 libreadline5 4.3-2 libtool 20020705-1 libtool-devel1.5-1 libtool-stable 1.4.3-1 libungif 4.1.0-2 libxerces-c212.1.0-1 libxerces-c222.2.0-1 libxml2 2.4.23-1 libxslt 1.0.13-1 lilypond-doc 1.6.8-2 login1.8-1 m4 1.4-1 make 3.79.1-7 man 1.5j-2 mc 4.6.0-2 mingw-runtime3.0-1 mktemp 1.4-1 more 2.11o-1 mt 2.0.1-1 nasm 0.98.36-1 ncurses 5.3-1 ncurses-demo 5.3-1 newlib-man 20020801 opengl 1.1.0-6 openssh 3.6.1p1-1 openssl 0.9.7b-1 openssl-devel0.9.7b-1 openssl096 0.9.6j-1 par 1.52-1 patch2.5.8-3 pcre 4.1-1 pdksh5.2.14-2 perl 5.8.0-2 perl_manpages5.8.0-2 pinfo0.6.6p1-1 pkgconfig0.15.0-1 popt 1.6.4-4 python 2.2.2-7 rcs 5.7-3 readline 4.3-2 rebase 2.2-2 rpm 4.1-1 rpm-build4.1-1 rpm-doc 4.1-1 ruby 1.6.8-1 rxvt 2.7.10-3 sed 4.0.7-1 sh-utils 2.0.15-3 sharutils4.2.1-2 splint 3.1.1-1 ssmtp2.38.7-3 sunrpc 4.0-1 swig 1.3.19-1 tar 1.13.25-1 tcltk20030214-1 tcsh 6.12.00-5 termcap 20020930-1 terminfo 5.3-2 tetex2.0.2-1 tetex-base 2.0.2-1 tetex-bin2.0.2-1 tetex-devel 2.0.2-1 tetex-doc2.0.2-1 tetex-extra 2.0.2-1 tetex-tiny 2.0.2-1 tetex-x112.0.2-1 texinfo 4.2-4 texmf20020911-1 texmf-base 20020911-1 texmf-doc20020911-1 texmf-extra 20020911-1 texmf-tiny 20020911-1 textutils2.0.21-1 tidy 030201-1 tiff 3.6.0-1 time 1.7-1 ucl 1.01-1 units1.77-1 unzip5.50-2 upx 1.24-1 w32api 2.3-1 which1.5-1 xerces-c 2.2.0-1 xerces-c-devel 2.2.0-1 xerces-c-doc 2.2.0-1 xpm-nox 4.2.0-1 zip 2.3-2 zlib 1.1.4-1 zsh 4.0.6-5 Use -h to see help about each section -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Compile
On Sun, 1 Feb 2004 06:48:20 -0500, Norman Vine [EMAIL PROTECTED] wrote: sigh There is a conflict between windows.h and some of the libstdc++ STL headers unless all of the STL includes are included before windows.h or visa versa otherwise some versions of the GNU compilers need NOMINMAX defined I *really* don't understand why this isn't done in the configure script or in simgear/compiler.h which should be included in all compilations /sigh FWIW To get around this I resort to specifying my compiler flags explicitly i.e. something like export CXXFLAGS=-pipe -O2 -Wall -DWIN32 -DNOMINMAX export CFLAGS=$CXXFLAGS ./configure Norman The -DNOMINMAX flag worked, thanks! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Controller tuning
I've slapped together a short document on controller tuning. - Tuning a PID controller After a control system is implemented the controller settings have to be adjusted until the control system performs according to the user's specifications. This process is called controller tuning. Trial and error tuning The most basic method of tuning is the trial and error method. This method involves adjusting the proportional gain, the integral time and the derivative time until the performance is satisfactory. The three settings are often adjusted separately in order to see the effects of the different settings. This process can be time consuming. It can be difficult to get started using the trial end error method. What kind of gains and times should one start out with? A typical approach for tuning a PID controller can be sumarized as follows: Step 1. Eliminate integral and derivative action by setting the derivative time to its minimum value (zero) and the integral time to its maximum value. Step 2. Set the proportional gain to a low value (0.5) and enable the controller. Step 3. Increase the proportional gain by small increments until continuous cycling occurs after a small set-point or load change. The term continuous cycling refers to a sustained oscillation with constant amplitude. Step 4. Reduce the gain by a factor of two. Step 5. Decrease the integral time until continuous cyclin occurs again. Set integral time to three times this value. Step 6. Increase derivative time until continuous cycling occurs. Set derivative time to one-third of this value. The proportional gain that results in continuous cycling in Step 3 is called the ultimate gain. In performing the experimental test to find the ultimate gain, it is important that the output does not saturate. If saturation occurs it is possible to get continuous cycling even though the gain is higher than the ultimate gain. This would then result in a too high gain in Step 4. Disadvantages of the trial and error method include: * It is quite time consuming if a large number of trials are required in order to find the ultimate gain and the integral and derivative times that result in continuous cycling. * The method is not applicable to processes that are open-loop unstable because such processes are typically unstable at both high and low gain values and are stable for intermediate gain values. * Some simple processes do not have an ultimate gain. Ziegler-Nichols method The Ziegler-Nichols methods of controller tuning are the closed loop and the open loop method. The closed loop method is quite similar to the trial and error method: Steps 1-3 are the same as in the trial and error method. Step 4. Take note of the ultimate gain Kpu, and the ultimate period Tu. The ultimate period is the period of the oscillations. Step 5. Calculate controller settings according to this table: Controller | Kp| Ti| Td | ---+-++--+ P | 0.5Kpu | inf. | 0 | PI | 0.45Kpu | Tu/1.2 | 0 | PID | 0.6Kpu | Tu/2 | Tu/8 | -- For more info on tuning and PID control systems follow this link: http://www.jashaw.com/pid -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Mon, 2 Feb 2004 10:55:05 -, Richard Bytheway [EMAIL PROTECTED] wrote: A question. When defining a cascade controller, is it important that the early stages of the controller go before the later stages in the config file? The Primary controller (the one that sets the reference set-point for the secondary) should be processed first. Alternatively, do the individual PID controllers get processed in the order they appear in the config file each frame, or are any dependencies worked out behind the scenes? The comment in the top of the generic-autopilot.xml claims that the controllers are processed in the order that they appear. AFAIK no dependancies are worked out behind the scenes. If order is important, I assume that you could get a 1 frame lag between each PID stage if they are in the wrong order. True. If it would affect performance will depend on the process dynamics. If the dynamics are in the order of the time between two frames then I guess it would. Still, I of course think that we should do it right, as Curt has done in generic-autopilot.xml. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
On Mon, 2 Feb 2004 18:39:23 -0600, David Culp [EMAIL PROTECTED] wrote: Thanks Curt, Jeff, Norman and Wendell for the slick new autopilot system. I've been playing with it, trying to adapt the generic autopilot to the 737. I see that I can set the autopilot to use actual mag heading, rather than DG heading, by setting autopilot/config/indicated-heading-magnetic to true. I wasn't able to get it to work until I changed a line in xmlauto.cxx, where the heading error is calculated. The current code finds the error by comparing the target heading with the DG heading. I changed line 630 to use the property /orientation/heading-magnetic-deg instead, and now it works fine. So, it appears that newauto.cxx allows for the heading source to be selected, but FGXMLAutopilot::update_helper() has it hard-wired to the DG. Or, very likely, I missed something obvious. The obvious thing you missed is the fact that newauto.cxx is no longer used, it has been removed from the makefile. So many of the properties under /autopilot/config/ do no longer apply. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
On Tue, 3 Feb 2004 17:10:07 -, Jim Wilson [EMAIL PROTECTED] wrote: Roy Vegard Ovesen [EMAIL PROTECTED] said: The obvious thing you missed is the fact that newauto.cxx is no longer used, it has been removed from the makefile. So many of the properties under /autopilot/config/ do no longer apply. Yes, but that doesn't solve the problem. We just need another calculation in the update_helper for the /orientation/heading-magnetic-deg value. How about synchronising the DG to the magnetic compass or to the true heading, depending on what you want? Wouldn't that solve this problem? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Faster responsiveness on the turn indicator
Hi, I am currently in the process of implementing the Bendix/King KAP 140 autopilot. This is a rate based autopilot, it uses the turn rate and rate of climb as its primary inputs. The turn indicator instrument implements a low-pass filter so that the indicated turn rate output from this instrument is a bit sluggish. This sluggishness is bad for controller performance because it adds a time delay. I see two possible solutions: 1) Increase the responsiveness of the turn indicator. I'm not a pilot and I've never seen a turn indicator in action so I don't know how resposive these instruments are, so maybe increasing the responsiveness isn't a good idea. 2) Add another output property from the turn indicator instrument with higher responsiveness. Comments? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
On Wed, 4 Feb 2004 13:28:39 -0600, David Culp [EMAIL PROTECTED] wrote: Beat me to it :) Here are two other calculations you'll need, vertical speed error and mach error. // Calculate vertical speed error static SGPropertyNode *target_vert_speed = fgGetNode( /autopilot/settings/vert-speed-fpm, true ); static SGPropertyNode *vert_speed = fgGetNode( /velocities/vertical-speed-fps, true ); static SGPropertyNode *vs_error = fgGetNode( /autopilot/internal/vert-speed-error-fpm, true ); vs_error-setDoubleValue( target_vert_speed-getDoubleValue() - vert_speed-getDoubleValue() * 60.0); // Calculate mach error static SGPropertyNode *target_mach = fgGetNode( /autopilot/settings/mach, true ); static SGPropertyNode *mach = fgGetNode( /velocities/mach, true ); static SGPropertyNode *mach_error = fgGetNode( /autopilot/internal/mach-error, true ); mach_error-setDoubleValue( target_mach-getDoubleValue() - mach-getDoubleValue() ); Dave I think this is taking it one step too far. We don't need to calculate vertical speed error, that is done inside the controller (when you use /velocities/vertical-speed-fps ans input and /autopilot/settings/vert-speed-fps as reference). The reason for the heading bug error calculation was to make the turning to the heading bug more intelligent. If we had used current heading as input and heading bug as reference to a controller it would have turned right all the way from 10 deg to 350 deg through 180 deg, insted of just turning left from 10 to 350. Our solution was to figure out how many degrees left (negative) or right (positive) we need to turn. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cygwin / SimGear / Clouds 3D compile problem
On Wed, 4 Feb 2004 22:01:55 +0100, Durk Talsma [EMAIL PROTECTED] wrote: Hi everybody, I'm having the following problem getting SimGear compiled on a Windows XP system, using cygwin: Compilation halts in simgear/scene/sky/clouds3d with a ton of errors about OpenGL functions being redefined elsewhere (see error msgs below). I'm using gcc 3.3.1 (cygming special), which is running on a recent version of cygwin (installed early Januari). I've done a full install of cygwin, including XFree86. I'm wondering if that's related to the problem. The installation manual says not to install XFree86 when using cygwin. Try uninstalling XFree86. If you have XFree86 installed the make process tries to use the GL libs from XFree86 (or something like that), and it looks like that's what's happening. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Wed, 4 Feb 2004 00:48:00 +, Lee Elliott [EMAIL PROTECTED] wrote: !-- Altitude hold. 2 stage cascade controller. -- !-- Stage #1 sets target rate of climb based on diff between current alt -- !-- and target altitude. -- pid-controller nameAltitude Hold (Altimeter based) Stage 1/name debugfalse/debug enable prop/autopilot/locks/altitude/prop valuealtitude-hold/value /enable input prop/instrumentation/altimeter/indicated-altitude-ft/prop /input reference prop/autopilot/settings/target-altitude-ft/prop /reference output prop/autopilot/internal/target-climb-rate-fps/prop /output config Kp0.1/Kp!-- proportional gain -- beta1.0/beta!-- input value weighing factor -- alpha0.1/alpha !-- low pass filter weighing factor -- gamma0.0/gamma !-- input value weighing factor for -- !-- unfiltered derivative error -- Ti20.0/Ti !-- integrator time -- Td0.1/Td!-- derivator time -- u_min-40.0/u_min !-- minimum output clamp -- u_max40.0/u_max !-- maximum output clamp -- /config /pid-controller Obviously, I've upped the u_min u_max here too. Heh! - I'll get the docs tomorrow... Some notes on tuning cascade controllers: When tuning cascade controllers it is common practice to first tune the inner loop or the secondary controller in Lee's example that would be the vertical speed controller, and then tune the outer loop or the primary controller. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn
On Wed, 4 Feb 2004 13:48:37 -0800 (PST), Alex Perry [EMAIL PROTECTED] wrote: From: Roy Vegard Ovesen [EMAIL PROTECTED] I am currently in the process of implementing the Bendix/King KAP 140 autopilot. This is a rate based autopilot, it uses the turn rate and rate of climb as its primary inputs. The turn indicator instrument implements a low-pass filter so that the indicated turn rate output from this instrument is a bit sluggish. This sluggishness is bad for controller performance because it adds a time delay. I see two possible solutions: A lot of autopilots have a rate-of-turn hold input, not just the KAP140, so this is a generic problem. Avoid any hacks specific to this device. Noted. My next project will probably be the S-TEC System Twenty/Thirty series. Which is also rate-based. I figure the control system wil be very similar. It is possible that the low pass is too strong, but I'd have to study it. The turn indicator is a gyro instrument and, unlike the VSI for example, doesn't actually have an inherent low pass that we _have to_ model right. So in the real world a responsive turn rate indication would be available, right? The low pass is primarily due to the fact that both the display routine and the underlying FDM are running in observable timestep increments. If we don't filter the data then the instrument looks different to the pilot because the increments actually modulate subtle changes in the indication so they become easier for the pilot to see and act upon. As a result, the aircraft becomes unnaturally easy to fly on instruments. However, there are other human-corrective hacks we can do to the data. 1) Increase the responsiveness of the turn indicator. I'm not a pilot and I've never seen a turn indicator in action so I don't know how resposive these instruments are, so maybe increasing the responsiveness isn't a good idea. Because the low pass is computed digitally without any noise contribution, you can back it out in the AP algorithm. I'm not suggesting you use a filter with a carefully-placed zero to recover the raw signal though. Instead, I suggest you put in a stronger differentiator term in the loop and/or use a separate roll rate feedback loop from the roll angle feedback. I could try that, but the PID algorithm also includes a low-pass filter on the derivate error, so that might kill this approach. Since the KAP140 (and S-TEC) do not get any input from the roll indicator, I will try to avoid that if possible. Bear in mind that the TC signal is a composite of rate-of-turn and of rate-of-bank because the gyro is mounted at an angle, so the instrument can indicate a standard rate of turn when the nose has not moved at all. Thus, your feedback loop might be responding to the bank data component. Yes, but that would also be the case for the real world KAP140 and S-TEC, right!? 2) Add another output property from the turn indicator instrument with higher responsiveness. The lazy solution is to ignore the property associated with the instrument and feed directly off the raw body data. The problem with doing that is (a) it is not intuitive when working on the XML configuration files (b) doesn't give the correct behavior for instrument failure situations Point (b) is one of my goals to avoid. I'm thinking that adding a second indicated-turn-rate property that is filtered with a higher bandwidth would be a good solution. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn
On Thu, 05 Feb 2004 00:05:00 +0100, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I'm thinking that adding a second indicated-turn-rate property that is filtered with a higher bandwidth would be a good solution. I just tried this, and the control system performance boost was quite noticable. :-) This would be beneficial for all turn-rate-based autopilot implementations KAP140, S-TEC and probably many more. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn indicator
On Wed, 04 Feb 2004 20:18:15 -0500, David Megginson [EMAIL PROTECTED] wrote: Roy Vegard Ovesen wrote: So I shouldn't touch the responsiveness then?!. But rather add a new property with better responsiveness. Out of curiosity, why do you think that the responsiveness should be better? It improves controller performance. But I still don't want to go beyond what is possible in the real world. I've flown briefly behind two small-plane autopilots (one newer, one older) and they were both extremely jerky things. Do you have any reason to believe that the AP you're modelling gets more responsive input than a real TC can give? No, not more respinsive than possible, but I thought that the damping in FlightGear _and_ in real world was only for display purposes. So maybe there would be a possiblility to get the signal before it was damped. After reading the article on the AVWeb site and noting this: The instrument also contains a dashpot in order to slow down the movement of the gimbal ... and The dashpot is replaced by a viscous dampener ... It seems that since the gimbal is dampened it can not output a more responsive signal. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn indicator
On Wed, 04 Feb 2004 17:18:33 -0800, Andy Ross [EMAIL PROTECTED] wrote: Roy Vegard Ovesen wrote: David Megginson wrote: Originally, the TC responded instantly -- I had to do a fair bit of work adding the slight lag to make it work like a real TC. The lag smooths out the indication a bit. So I shouldn't touch the responsiveness then?!. But rather add a new property with better responsiveness. What are you trying to model? Real autopilots don't have perfect instrumentation. If David is right about the behavior of the turn coordinator, then a real C172-class aircraft simply won't have the fidelity to drive your autopilot. Are you sure you're not trying to fix a bug with the real world? It was not my intention to do something that wouln't be possible in the real world, and this discussion has brought me to the conclusion that the TC is damped by design, and that I need to tweak my controller tuning. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC voice howto
On Thu, 12 Feb 2004 21:05:25 +, David Luff [EMAIL PROTECTED] wrote: Anyone got any wavefile editor recommendations BTW? I like GoldWave. www.goldwave.com I used CoolEdit (Windows) for the ATIS, but the trial period is now long gone, and when I went to buy it I found the guy had sold it to Adobe and the price had tripled. No thanks! I'm using Audacity now, but it's not entirely polished, and the sound is not in sync with cursor movement when playing a small selection in recent versions. Crucial factors are the ability to extend or contract a selection by either edge, and easy copy and pasting into a new buffer, plus display of time or byte position. You can chose to display time or sample position, but the time display has only 3 decimal numbers. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] flight path heading
On Mon, 16 Feb 2004 20:28:49 -, Jim Wilson [EMAIL PROTECTED] wrote: Does anyone have a formula handy for calculating the flight path of an aircraft in true degrees (direction of travel as opposed to the airframe heading)? My guess is that it'd be a matter of doing something with the lon/lat from the previous frame. Maybe there's something simpler with the current FDM output in FlightGear? The GPS instrument does this in the same way as you suggest (as do most real gps devices), take a look at the gps.cxx source file to see the details. I believe the actual formula can be found someplace in SimGear. But if you are just looking for the true flight path the beforementioned GPS instrument provides this. Take a look at /instruments/gps/... in the propertytree. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] GPS
I've added some more funtionality to the GPS module (gps.cxx). I can define a waypoint as lon and lat values, or I can input the waypoint ID (this currently only works for airport IDs). Now the distance, bearing and time to the waypoint is calculated. I can also set the desired course to fly through the waypoint, and the course deviation is calculated in degrees and in nautical miles. I also have an odometer and a trip-odometer. I used the Garmin GPS III Pilot - Owner's Manual Reference to find out what kind of functionality a GPS unit has. For now the GPS can only hold one waypoint, but I would like to extend that to a higher number in order to create a route (the GPS III Pilot can have 30 in each route). Routes could then be stored in plain text files, as could user waypoints. Comments? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
On Mon, 23 Feb 2004 01:04:05 +, Lee Elliott [EMAIL PROTECTED] wrote: I can see the gps entries in the tree but there're no values in them. Do I need a specific gps instrument to get some data? I think that currently the GPS does not get any power, I've modified the *electrical.xml file in order to give it some juice. Also I just mailed my diff files to Curt, so my changes probably hasn't been committed just yet. Some of the gps functions would be pretty useful when I'm working on an fdm. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
On Mon, 23 Feb 2004 02:10:47 -, Jim Wilson [EMAIL PROTECTED] wrote: I wonder if this could be incorporated (or interfaced) to the current waypoint management code. And, for the pilots on the list, do some GPS units also calculate elevations to plug in for VNAV operation, fuel estimation, etc? Yet another thought that seems to get mentioned here occasionally: a nearest airport function. Yes, the Garmin GPS III Pilot does have a nearest airport function. The algorithm for finding the nearest airport would be similar to the algorithm finding the nearest METAR station. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SimGear CVS build error
I get this error when building SimGear: if gcc -DHAVE_CONFIG_H -I. -I. -I../../../../simgear -I../../../.. -pipe -O2 -Wall -DWIN32 -DNOMINMAX -D_REENTRANT -MT glut_shapes.o -MD -MP -MF .deps/glut_shapes.Tpo \ -c -o glut_shapes.o `test -f 'glut_shapes.c' || echo './'`glut_shapes.c; \ then mv -f .deps/glut_shapes.Tpo .deps/glut_shapes.Po; \ else rm -f .deps/glut_shapes.Tpo; exit 1; \ fi In file included from glut_shapes.c:59: /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token In file included from glut_shapes.c:61: glut_shapes.h:12:1: warning: APIENTRY redefined In file included from /usr/include/w32api/GL/glu.h:37, from glut_shapes.c:59: /usr/include/w32api/GL/gl.h:80:1: warning: this is the location of the previous definition make[5]: *** [glut_shapes.o] Error 1 Any ideas? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear CVS build error
On Fri, 27 Feb 2004 09:39:14 +0100, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I should mention that I am using Cygwin. I get this error when building SimGear: if gcc -DHAVE_CONFIG_H -I. -I. -I../../../../simgear -I../../../.. -pipe -O2 -Wall -DWIN32 -DNOMINMAX -D_REENTRANT -MT glut_shapes.o -MD -MP -MF .deps/glut_shapes.Tpo \ -c -o glut_shapes.o `test -f 'glut_shapes.c' || echo './'`glut_shapes.c; \ then mv -f .deps/glut_shapes.Tpo .deps/glut_shapes.Po; \ else rm -f .deps/glut_shapes.Tpo; exit 1; \ fi In file included from glut_shapes.c:59: /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token In file included from glut_shapes.c:61: glut_shapes.h:12:1: warning: APIENTRY redefined In file included from /usr/include/w32api/GL/glu.h:37, from glut_shapes.c:59: /usr/include/w32api/GL/gl.h:80:1: warning: this is the location of the previous definition make[5]: *** [glut_shapes.o] Error 1 Any ideas? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 2D EFIS Instrument
Hi! I'm making an EFIS instrument, but I'm having trouble with a long pitchladder texture. It's a long texture that contain the entire pitchladder from -90 to 90 degrees. My problem is that it enxtends beyond the instrument: http://home.tiscali.no/rvovesen/Pitchladder.jpg How can I make the pitchladder texture only display inside the circle? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear CVS build error
On Fri, 27 Feb 2004 10:30:52 +0100, Erik Hofman [EMAIL PROTECTED] wrote: I think this is the problem where cygwin was installed together with XFree86. So far everybody has advised not to install XFree86 on cygwin, but recently someone suggested to configure using --without-x I'm sure I haven't installed XFree86. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear CVS build error
On Fri, 27 Feb 2004 10:40:39 +0100 (CET), Frederic BOUVIER [EMAIL PROTECTED] wrote: A correct solution would be to find out why HAVE_WINDOWS_H is not defined Thanks for the tip! I added -DHAVE_WINDOWS_H to my CXXFLAGS environment variable, defining HAVE_WINDOWS_H. I think this is a better solution that changing the source code. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 2D EFIS Instrument
On Fri, 27 Feb 2004 10:36:49 +0100, Erik Hofman [EMAIL PROTECTED] wrote: If it is a 3d model I was going to redirect you to the following link: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/docs/Model/fgfs-model-howto.html?rev=1.8cvsroot=FlightGear-0.9content-type=text/vnd.viewcvs-markup Maybe I should make a 3D instrument instead!? Since the version on the FlightGear website is quite out of date and Curtis hasn't updated it yet upon my request. But unfortunately it is hard to read it this way. Basically you would move the texture offsets rather than the surface itself. Is this possible with 2D instruments too? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 2D EFIS Instrument
On Fri, 27 Feb 2004 08:23:24 -0500, David Megginson [EMAIL PROTECTED] wrote: As the original author of the 2D instrument code, I *strongly* advise against building 2D instruments. Since I switched to an all 3D panel in the plane I'm working on, my framerate has gone from 10-15 fps to 20-30 fps (admittedly on a low-end card), even with larger textures. I think that the only thing missing from the 3D animation code now is text, and that should be easy to add. For the FPS Flat Panel Display System that I'm trying to make, a text feature is almost essential. We'll need to support the 2D code for a while because there are so many existing instruments that use it, but it's a serious mistake to start a new 2D instrument at this point. The 2D code still requires 3D rendering (since the instruments appear in a 3D scene graph), so there are no gains, but I'm guessing that the texture stacking for 2D instruments causes OpenGL state changes that are expensive, at least with my graphics card (GeForce2Go). Alright then. I'll convert my intrument(s) to 3D. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ATC readability
I find it a little hard to read the ATC messages that appear on the top of the screen. The dissapear before I get a chance to read them. Maybe I'm a slow reader, but still I would like them to be displayed a little longer. Using multiple lines might be a solution, that way multiple messages can be displayed at the same time giving some history to the dialog. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
On Thu, 11 Mar 2004 17:10:30 +, David Luff [EMAIL PROTECTED] wrote: One bug though - I don't see the instrument needles under Linux with an NVidia card. I thought you simply hadn't done them, until I saw them under Cygwin with an ATI card. I see the large tilting plane in the turn co-ordinator, and the AI, but none of the more 'needlish' needles. I've got no idea what the problem is. I too, experienced this, no needles in the instruments. I use a NVidia card under Cygwin. After installing the cvs version of plib, the needles appeared (I used to have plib 1.6.0). Another thing that I noticed about the pa28 panel was the plane in the TC was not transparent where it should be. The rgb file did have an alpha channel but because the file was only 256 colors the alpha channel was not transparent in FlightGear. It was OK when I opened it in AC3D, but not in FlightGear. Converting the file to 24bit colour solved this, but I think that this is a bug, perhaps in plib. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161/Models
On Thu, 11 Mar 2004 20:07:10 -0500, David Megginson [EMAIL PROTECTED] wrote: Was this in PLIB 1.6, again? The alpha transparency is fine using the CVS plib. I'm pretty sure it was CVS plib. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] GPS
Hi, This message is directed towards Curt and David Megginson. I sent my changes to the GPS instrument module, first to Curt and then to David, but I'm beginning to wonder if any of you ever got my e-mail. I've not heard anything and AFAICT they have not been committed. Am I being ignored? I don't hope so because I think that the changes I've made makes the GPS module quite usefull for navigation. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Error maiking custom FlightGear
I've added an electric-powered attitude indicator class: AttitudeIndicatorElectric. For now this is just a copy of the original AttitudeIndicator class. I've added it to the FGInstrumentMgr constructor and to the makefile.am. Now all the files in src/Instrumentation compiles OK, but when it's time to link in Main I get this error: Making all in Main make[2]: Entering directory `/home/royvegar/FlightGear-0.9/source/src/Main' g++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -pipe -O2 -Wall -DWIN32 -DNOMINMAX -DHAVE_WINDOWS_H -D_REENTRANT -L/usr/local/lib -L/usr/X11R6/lib -o fgfs.exe b ootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/A TC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_i n.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Bal loon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/Exter nalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/l ibYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/li bLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../s rc/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation /libInstrumentation.a ../../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/ libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../.. /src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Rep lay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../sr c/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephe m -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbuck et -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgseria l -lsgstructure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplib js -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut32 -lglu32 -lopengl32 -luser 32 -lgdi32 -lplibsl -lplibsm -lwinmm ../../src/Instrumentation/libInstrumentation.a(instrument_mgr.o)(.text+0x290):in strument_mgr.cxx: undefined reference to `AttitudeIndicatorElectric::AttitudeInd icatorElectric[in-charge]()' ../../src/Instrumentation/libInstrumentation.a(instrument_mgr.o)(.text+0x1180):i nstrument_mgr.cxx: undefined reference to `AttitudeIndicatorElectric::AttitudeIn dicatorElectric[in-charge]()' collect2: ld returned 1 exit status make[2]: *** [fgfs.exe] Error 1 make[2]: Leaving directory `/home/royvegar/FlightGear-0.9/source/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/royvegar/FlightGear-0.9/source/src' make: *** [all-recursive] Error 1 What I really don't understand is the [in-charge] thing. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AUTOPILOT
On Fri, 12 Mar 2004 21:33:04 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: Hi Guys I wonder if someone could tell me were I can find the instructions for the new autopilot system so I can redo the 737 autopilot to work. Browse to: http://www.flightgear.org/Docs/XMLAutopilot/ If someone has built an autopilot with the new system could they tell me the xml file so I might get an idea how it is done. There is a generic autopilot in the data/Aircraft/Generic folder. Or is there a key press to activate the autopilot using the generic autopilot xml. What I would like to know is how I get the switches like Heading,Vor/loc,Approach and the like to work now. This should become apparent when you read the docs and the generic example. You have to get the bindings right in the instrument xml file(s). The generic autopilot is accessible from the autopilot-menu. Here you can de-/activate the various modes. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS: data/Aircraft/pa28-161/Models
On Fri, 12 Mar 2004 10:03:00 -0500, David Megginson [EMAIL PROTECTED] wrote: Frederic BOUVIER wrote: I don't know for the original bug reporter, but I am using Windows and NVIDIA if it is of any importance. That could matter -- I'm using Linux and NVIDIA. Do you have trouble with transparencies anywhere else? Do other people using Windows and NVIDIA see a white rectangle behind the panel in the pa28-161? The image of the TC that Melchior linked to was exactly what I saw too. In addition I saw that the clock face was also white outside of the face circle. I opened both the rgb files in Paint Shop Pro and noticed that they both had only 256 colors, and all the other rgb files had 16 million colors. It seemed that only the rgb files with 256 colors had the transparency problem. If I opened the 3-d instruments in AC3D the transparency would be OK _for the 256 color images_. I'm using Windows, Cygwin and nvidia. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Getting the Autopilot to Work
On Sun, 14 Mar 2004 20:19:21 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: Hi Guys I am trying to make the autopilot work in A/C like the 172 and 310 but when I activate the autopilot Sw's nothing happens in fact I can have all Sw's activated at once.So how do I get the autopilot to work.This is the latest CVS build. The autopilot instrument panel in the 172 is probably bound to the old autopilot. Try using the autopilot GUI instead. It can be accessed from the autopilot menu. A last option is to open the property browser and manually edit the /autopilot/locks/... properties to activate the various modes. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Visualising forces
How about shifting the pilot-viewpoint-posistion proportional to the forces that act on the pilot in order to visualise them. A high g force would push the pilot down in his seat, shifting the viewpoint down etc. This is used in IL-2 Sturmovik and I think it does a good job of showing the forces that the pilot experience. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem Under Cygwin
On Mon, 15 Mar 2004 23:25:16 -0600, Jonathan Polley [EMAIL PROTECTED] wrote: I deleted my cygwin installation and started from scratch (somehow, I had X installed previously). Unfortunately, even though I made sure that X11 was not installed, the problem didn't go away. plib builds just fine, it is just SimGear that is having a problem. I will try to fiddle around a bit more tomorrow. I had this problem too. Review this list for a thread named SimGear CVS build error from about 2004.02.27 for a solution. I have this in 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 -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] The PID Controller
On Wed, 17 Mar 2004 16:16:02 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: Hi Guys After spending a couple of days playing with this thing I have a question or two. 1 After you get the mode oscilating how do you get it to stop do you have to continue to adjust all three or do you do one at a time. You should adjust one at a time: Adjust - observe results - adjust - observe - etc. untill you are happy. ;-) 2 How do you know if you are heading in the right direction what will make the oscilations slow.It seems to me that it goes at the same rate all the time with the same amplification regardless of settings.Is there one property that effects the rate and one the amplification or once again is it a combination of all three. Generally: reduce proportional gain (Kp), reduce derivative time (Td) and increase integrator time (Ti). There is no one property that effects the rate or frequency of the oscilations. We usually want to get the amplitude of the oscilations as small as possible, the frequency is more or less tied to the resonance-frequency of the process that is controlled. Any help you can give or something you should read(other than the ones in FG.I have read them but still am stumped)would be greatly appreciated. You could try searching for PID controller tuning in your favourite search engine. P.S Clarification.Where it says in the setup that Ti should be set to infinity does mean writing inf were a number would normally be. No, it means setting the value as high as possible. I'm, not sure if inf would be recogniced as infinity. In the latest CVS version this has been addressed. You can set the integrator time to 0 (zero). Now if you look at the PID algorithm you'll see that this does not make sense because it would lead to a division by zero. On the other hand setting Ti to the highest possible value might be a bit awkward, and the highest possible value for a double might be platform dependant. So I've decided to use zero to completely eliminate the intergator action from the controller. The code recognices setting Ti to zero and then removes the integrator action. Short answer: when it says that Ti should be set to infinity, set it to 0.0 (zero). The same can be said for derivative time (Td). Setting Td to zero would in the previous version lead to a division by zero. The new version recognices this and skips that particular piece of code (where the error is filtered). Summary: Set Ti to zero to completely eliminate integrator action. Set Td to zero to completely eliminate derivative action. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up! GPS output property names have changed
On Monday 22 March 2004 22:50, Jim Wilson wrote: The autopilot is broken, and who knows what else because someone decided to rename some of the properties being written by the GPS module. This isn't a serious problem but the change hasn't been announced here or even mentioned in the cvs log. Sorry, my bad! Anyway, this is the announcement we should have gotten on the list before the changes were commited. FWIW it is probably best _not_ to change property names in your modules unless the change is critically important. Removing the word indicated- from the names is a nice idea but IMHO trivial in the scope of things. All you are doing is creating work for others. I've changed the property names back to indicated-*. Get the files: http://home.tiscali.no/rvovesen/gps.cxx http://home.tiscali.no/rvovesen/gps.hxx -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Spinning gyro numeric model
Hi all! I've created a new model for the spinning gyro (Instrumentation/gyro.*xx). /** * Complex model of a spinning gyro. * * The gyro is driven by a torque. It is slowed down by bearing * friction and air friction. * The gyro disk is defined by radius [m], width [m], and * material density [kg/m³]. The disk is a solid cylinder. */ In the model I consider bearing friction torque to be constant. Air friction is only modeled for the outer rim of the cylinder, _not_ for the two flat sides. Modeling air friction for the sides is more complex as the velocity increases with the radius-- a point close to the rim has a higher velocity than a point close to the center. I suspect that the friction contribution from the two sides would be higher than from the outer rim surface, so I definetely should model this too. Any suggestions on how to model air friction on a spinning flat surface? The output for this model is angular velocity, angular momentum and a normalized spin. Angular momentum can be used to model gyroscopic precession. I only added normalized spin in order to be able to interface with the existing heading indicator and attitude indicator models. Now, I know that the existing gyro model and heading indicator and attitude indicator work great and that some might think that I am trying to fix something that is already working. I would argue that I am trying to improve on something that is already working ;-). But if nobody else share my point of view, I might abandon the idea. Comments are welcome! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spinning gyro numeric model
On Sunday 28 March 2004 21:27, Alex Perry wrote: My objections to people fiddling with the gyro model is because they usually want to take out the mechanical errors so it becomes a perfect instrument. From your description, you seem to be trying to make it a more accurate simulation of real life, which is certainly fine by me. Go for it! Yes, that is exactly what I'm trying to do. Eventually I'll have a go at the turn indicator and the other gyro instruments to try and make them as true to real life as possible. * The gyro is driven by a torque. It is slowed down by bearing * friction and air friction. * The gyro disk is defined by radius [m], width [m], and * material density [kg/m?]. The disk is a solid cylinder. Don't assume that the comments in the file, which were originally by me and then modified by David to try and make sense of what my code did, bear any relation to the actual engineering inside such a gyro unit. It doesn't ... it is simply a description of the simplified physical model that the code was written to implement. I created that model because it would show most of the errors, not because it is correct. Oh! This code comment is mine, I wrote it for the newgyro.hxx. I included it in the post as a quick way to describe the principles I'm trying to model. If you'd like to start from first principles and do a fully correct model, I suggest you contact one of the manufacturers and ask for engineering data. If you don't know who or how to go about doing that, let me know and I'll try to arrange it for you. Actually I think I've got the spinning cylinder model nailed (except for the air friction on the flat sides). I tried to contact a manufacturer, I think it was SigmaTek, regarding their System20 Autopilot Turn Coordinator. I was forwarded to the engineering department but never got an answer. When I try to model the actual gyro instruments it would be wery helpful to have engineering data. I just hope I don't keep getting ignored. :-( -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Maintenance log proposal
Hi! How about a log that records running time for each system (electrical, static, vacum etc.) and for the instruments and possibly the controls and ... This log can be stored in the users home directory as a simple text file (XML). There would be different logs for each individual aircraft. Now, one could calculate a failure probability for for example the electrical system based on the time that it has been operative. And as that probability becomes higher the system will fail. Fixing the system, or should I call it performing maintenance, would be as simple as resetting the running time in the log file to zero. You don't even have to get your fingers dirty :-) Comments? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RW light disappear
On Monday 12 April 2004 04:01, Dave Perry wrote: I just noticed that the runway lights disappear as I flare out in the c172. I've noticed this too. It seems that the transparent propeller disk is the reason. I tried stopping the engine on ground and that brought back the lights. One thing that is strange is that the propeller disk is only opaque to lights below a very low altitude. Noticed this first as I was completing the ILS RW 35 precision approach into KAZO (Kalamazoo, MI). Complete CVS update Friday evening the 9th (plib, SimGear, FlightGear, and base). This seems to me a new issue with this update. Dave Perry ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RW light disappear
On Monday 12 April 2004 17:28, Jim Wilson wrote: I noticed something similar with the F-16 at low altitudes. I'm starting to wonder if we need a select-deselect option for cloud layers that should not be visible to solve this problem? Is this an issue only from the cockpit view? I made some screenshots of the F-16. http://home.tiscali.no/rvovesen/f16-cockpit.png http://home.tiscali.no/rvovesen/f16-ext1.png http://home.tiscali.no/rvovesen/f16-ext2.png You can clearly see from ext1 and ext2 that the lights are not visible through the canopy of the F-16, but still the building in the background is. The cockpit shot is a bit harder to see but you can see that inside the darker region no lights are visible. The canopy glass of the F-16 has probably (I haven't opened the model in AC3D) some semitransparent material. The same holds for the propeller disk of the C172, and if you try the Cub I think it too has a transparent material for the propeller disk. I would say that it is an issue with semitransparent materials. If you try the 2d panels the lights are visible. But the strangest thing is that as the aircraft rises above som 50 ft above the ground the lights appear. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Sound in Nasal
Is there any way to play sounds from a Nasal script? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound in Nasal
On Friday 16 April 2004 23:38, Andy Ross wrote: Roy Vegard Ovesen wrote: Is there any way to play sounds from a Nasal script? Sort of. The current sound model is property-driven. You can create a new sound event (see the *-sound.xml files under Aircraft for examples) and drive it from a given set of properties. You can then set those properties from Nasal. There is, however, no way to load a *new* sound from Nasal. It has to be seen by the sound manager at startup to be played at runtime. I'm not completely sure what such an interface would look like, but it shouldn't be hard to do. What are your requirements? Very simple. I just want to make a beeping sound or a number of beeps to use when the autopilot is disengaged (or any other audible annunciators). -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound in Nasal
Thanks for the tips. On Friday 16 April 2004 23:58, Andy Ross wrote: If it is aircraft-specific, then the mechanism of putting it into the -sound.xml file is probably exactly what you want. I would say that it's more instrument-specific than aircraft-specific. Things like playing sounds from the UI are more problematic from the current interface. I'd start with a single beep.wav with an XML definition like: sim ... fx ... beep nameengstart/name pathSounds/beep.wav/path property/tmp/somewhere/beep/property /beep Now you can trigger the beep by toggling the property from false to true. With a little work with settimer(), you can get it to beep with different patterns and frequencies, etc... Let me know if you need more help. Hopefully I haven't misunderstood the sound configuration files. This isn't exactly one of my areas of expertise. :) I'm not either, but I don't think it's possible to put sound configurations into the instrument configuration XML files, or is it? Note that I'm not under the impression that that's what you suggested, or was it? :-} I'm confusing myself. Anyway maybe the ideal solution would be if there were a fgcommand to play sounds. That would then be trivial to call from Nasal, right? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] KAP140 Two axis autopilot
Hi, Curt has just committed my Bendix/King KAP140 Two axis autopilot. It is available in the default C172 3d cockpit and 2d panel. Please try it out. I have no hands-on experience with the KAP140, so there might (rather _will_) be some things that I haven't got right. Please let me know! The Pilot Guide for the KAP140 is freely available (12M PDF file) from the Bendix/King website: http://www.bendixking.com Read it to learn how to operate the autopilot. Note that it describes three versions of the KAP140, and that I've implemented the two axis version. Also note that in the REV mode one should set the heading bug to the backcourse not the frontcourse as instructed in the guide. This pilot guide was my only source for creating the autopilot. I would also like to mention that I've use Nasal extensively, and that it allowed me to do things that probably would not have been possible using only XML configuration files. Thanks Andy! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OpenAL runtime error
Hi Flightgear and Simgear builds ok on SuSE Linux 9.0, but when I try to run Flightgear I get this error message: Initializing OpenAL sound manager fgfs: pcm.c:1050: snd_pcm_writei: Assertion `pcm-setup' failed. I'm using openal version 20030811-83 and openal-devel version 20030811-83 as der standard for SuSE 9.0 -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL runtime error
On Sunday 25 April 2004 12:49, Chris Horler wrote: Flightgear and Simgear builds ok on SuSE Linux 9.0, but when I try to run Flightgear I get this error message: I'm also running SuSE 9.0 with the same default openal packages. I have VT8233/A/8235 AC97 Audio Controller that's a mainboard-integrated soundcard. Initializing OpenAL sound manager fgfs: pcm.c:1050: snd_pcm_writei: Assertion `pcm-setup' failed. I don't get this message. I do get sound and an openal message 'Initializing OpenAL sound manager'. Maybe something else is using the sound device? I did try to run twm instead of KDE to make sure that KDE was not useing the sound device, but I got the same error. I've also tried the orbz demo (a game) that is supposed to use OpenAL. That worked fine (under KDE), so I guess that there is nothing wrong with: sound device, alsa, openal. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear news letter
On Saturday 08 May 2004 00:28, Curtis L. Olson wrote: For an upcoming newsletter article I am [hopefully] writing an introduction to modeling aircraft flight dynamics in YASim. For a subsequent issue of the newsletter I think I'd like to walk the reader through the process of creating a specific aircraft model in YASim. I have borrowed a POH for a Super King Air 200/200C which gives a *ton* of great information for modeling the aircraft's flight dynamics, so I think this would make a great candidate for this exercise. (It would be nice to have a few more turboprops in flightgear, and the king air is just a really cool design and would be good to have anyway.) So my question is this. Are there any 3D modelers out there who would be interested in participating in this exercise by creating a (or adapting an existing?) 3D model for the King Air 200 and animating/texturing it? I don't know if there is any 3d models from MSFS land we could get permission to use/adapt? Is there anyone who would like to do a 2D or 3D cockpit? We have a nice 2D cockpit for a Beech 99 (which is similar) so that might serve as a reasonable starting point. I would like to take a shot at building a 3D cockpit. I've studied some pictures at www.airliners.net and found them to be a valueable source. If anyone has, or knows about anything that can be of help, please let me know. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Sunday 25 April 2004 23:31, Dave Perry wrote: Some feedback on OpenAL: I just updated plib, SimGear, and FlightGear from cvs. With the default Cessna 172, the sound does not change with throttle setings or RPM change. Also, the ident for the ADF does not go away when I turn off the ident or change frequencies. That is likely because the kr-87 adf is also active but it does not have a instrument panel in the default C172. You can turn it off through the property browser. So, bottom line: this is not a OpenAL problem. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: OpenAL runtime error
On Sunday 25 April 2004 16:42, Melchior FRANZ wrote: * Roy Vegard Ovesen -- Sunday 25 April 2004 11:44: Flightgear and Simgear builds ok on SuSE Linux 9.0, but when I try to run Flightgear I get this error message: Initializing OpenAL sound manager fgfs: pcm.c:1050: snd_pcm_writei: Assertion `pcm-setup' failed. I'm using openal version 20030811-83 and openal-devel version 20030811-83 as der standard for SuSE 9.0 Got the same here with Linux 2.6.5 and the OpenAL from SuSE 9.0. Then I replaced OpenAL with cvs/head and compiled again. Now it works. Did the same, and it works great! I did configure OpenAL with --enable-alsa and --enable-alsa-dlopen, but I can't say for sure if this is required. I just did it because a little voice inside my head told me to. :-) For some reason I also included --enable-vorbis. If we are going to have different samples for the entire rpm range, as Curt suggested, we might consider compressing. Thanks! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Joystick problems...
On Monday 26 April 2004 19:05, Mathias Fröhlich wrote: On Montag, 26. April 2004 18:33, Luca Masera wrote: Now I've another question. Due to the fact that I've the ThrustMaster Top Gun (...), for which a config file was added in the last release, I've tried to use it in FlightGear but it doesn't works. Truly it works, but seems that isn't recognized so the config file doesn't works right. What's the problem? I'd like to change the config file but it's impossible if the joystick is recognized like a two axis, two buttons joystick. However, Js-demo finds the ThrustMaster if it's connected. Why? I believe that the name in quotes must *exactly* (case sensitive?) match the name in the config file. Here js_test printout for my joystick: Joystick test program. ~~ Joystick 0: THRUSTMASTER Top Gun Afterburner ... I had problems with my Thrustmaster Top Gun joystick on Windows. The name included the registered trademark (R) character. It showed up as [] in js_test. There was no way for Flightgear to recognize the name (because of the (R) character). My solution was to uninstall the Thrustmapper driver for my joystick, then the name became somthing else without the (R). -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Error compiling ATCVoice.cxx
I get this error when compiling ATCVoice.cxx if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/ usr/X11R6/include -g -O2 -D_REENTRANT -MT ATCVoice.o -MD -MP -MF .deps/ ATCVoice.Tpo \ -c -o ATCVoice.o `test -f 'ATCVoice.cxx' || echo './'`ATCVoice.cxx; \ then mv -f .deps/ATCVoice.Tpo .deps/ATCVoice.Po; \ else rm -f .deps/ATCVoice.Tpo; exit 1; \ fi ATCVoice.cxx: In member function `bool FGATCVoice::LoadVoice(std::basic_stringchar, std::char_traitschar, std::allocatorchar )': ATCVoice.cxx:56: error: invalid conversion from `const char*' to `unsigned char*' ATCVoice.cxx:56: error: initializing argument 1 of ` SGSoundSample::SGSoundSample(unsigned char*, int, int)' ATCVoice.cxx:56: error: invalid conversion from `const char*' to `int' ATCVoice.cxx:56: error: initializing argument 2 of ` SGSoundSample::SGSoundSample(unsigned char*, int, int)' -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error compiling ATCVoice.cxx
On Tuesday 27 April 2004 16:05, Andy Ross wrote: Roy Vegard Ovesen wrote: I get this error when compiling ATCVoice.cxx It looks like you did a CVS update in FlightGear without grabbing the required changes from SimGear. Curt changed the API yesterday. I'm sure I grabbed Simgear too, but I guess I forgot to make install :-( Well, I just did cvs update of Simgear and Flightgear and now FG make has made it past ACTVoice.cxx. Thanks! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal in instrument config (was:YASim fuel problem)
On Thursday 29 April 2004 23:19, Andy Ross wrote:
This is a perfectly legal script, for example:
nasal
B52F
script![CDATA[
myFunction = func { print(Executing myFunction()!); }
print(Hello World!\n);
]]/script
/B52F
/nasal
When you start up, it will print Hello World! on the console. It
will *not* print Executing myFunction()!. But later on some other
piece of Nasal code could do:
B52F.myFunction();
Which would then print Executing myFunction()!.
I tried this inside an instrument config file, but it didn't work.
Would it be possible to implement the ability to include nasal code in
instrument config files. I know that one can have nasal code for the action
bindings. What I want is to define some nasal functions that are instrument
specific.
I've done this with a global nasal script in the Nasal subdirectory, but as
more instruments use nasal it seems wastefull to have a lot of global nasal
code that never get used. Example: the KAP140 autopilot control panel uses
the Nasal/kap140.nas script. AFAIK currently the only aircraft that uses the
KAP140 is the C172, but still the kap140.nas is executet for every aircraft.
One could put the kap140.nas in the *set.xml for the aircrafts that use the
KAP140 instrument, but I believe it would be better to make it instrument
specific.
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Altitude Hold Autopilot example
On Friday 30 April 2004 13:59, Jon Berndt wrote: I've made some more progress in building an example autopilot using the JSBSim flight control components. I already have a wing leveler for the C-172, but I added an altitude hold module last night. The idea - in words - behind the altitude hold concept (at least the way I have implemented it) is that once a target altitude has been set, one can determine the error between where you are and where you want to be. This error term is limited to 100, filtered with a slight lag, and then multiplied by 0.1 in order to get a commanded HDOT (time derivative of altitude, or rate of climb) of 600 ft/min. This is a slightly unusual way of doing it, normally the commanded HDOT would be limited to 600 ft/min instead of the altitude error. But this approach works great too. This error is run through the altitude hold switch, and either this quantity or zero is passed to a proportional-integral controller (PI). The output from these two components is summed, multiplied by an appropriate gain, and the signal is sent to the elevator. I have a plot online of altitude versus time as the C-172 is commanded to fly (from takeoff) to 800 feet, then 850, then 600, then 2000 ft: http://www.jsbsim.org/JSBSimAltHoldAP.pdf From the plot it looks like the altitude hold performs very well. But if you try another test where you control the throttle in such a way that the aircraft is unable to hold a 600 ft/min vertical speed. I think you will see that the integrator will wind-up as the HDot Error value never reaches zero. The autopilot is configured in JSBSim as follows: COMPONENT NAME=Altitude Error TYPE=SUMMER INPUT -position/h-sl-ft INPUT ap/altitude_setpoint CLIPTO-100 100 /COMPONENT COMPONENT NAME=Alt Error Lag TYPE=LAG_FILTER INPUT fcs/altitude-error C1 0.25 /COMPONENT COMPONENT NAME=HDot Command TYPE=PURE_GAIN INPUT fcs/alt-error-lag GAIN 0.1 /COMPONENT COMPONENT NAME=HDot Error TYPE=SUMMER INPUT fcs/hdot-command INPUT -velocities/h-dot-fps /COMPONENT COMPONENT NAME=AP Alt Hold Switch TYPE=SWITCH TEST LOGIC=DEFAULT VALUE=0.0 /TEST TEST LOGIC=AND VALUE=fcs/hdot-error ap/altitude_hold == 1 /TEST /COMPONENT This integrator will start winding whenever the elevator is saturating and still unable to achieve the commanded climb rate. COMPONENT NAME=Integral TYPE=INTEGRATOR INPUT fcs/ap-alt-hold-switch C1 0.0041 /COMPONENT COMPONENT NAME=Proportional TYPE=PURE_GAIN INPUT fcs/ap-alt-hold-switch GAIN 0.035 /COMPONENT COMPONENT NAME=Control Summer TYPE=SUMMER INPUT fcs/integral INPUT fcs/proportional CLIPTO -1.0 1.0 /COMPONENT COMPONENT NAME=Elevator TYPE=PURE_GAIN INPUT fcs/control-summer GAIN -1.0 OUTPUT ap/elevator_cmd /COMPONENT -- end -- I've got some ideas for future enhancements, including a scheduled target rate-of-climb, so that the aircraft does not try and achieve 600 ft/min near its service ceiling or something silly like that. Also to be added is an automatic cutoff or safety feature, and perhaps the use of throttle to control altitude as appropriate. I guess I really need to read up on specific A/P operation, but this is presently being modeled to give the ability for JSBSim aircraft to fly automatic batch runs for testing, etc. I am going to include this in the JSBSim automatic flight document soon, and will have a block diagram with this, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A couple of problems...
On Tuesday 04 May 2004 20:24, Jim Wilson wrote: In any case it'd be interesting to know if this method is anything like how a real AP works, both in the AN-225 and others, like the c172. My guess is that it isn't even close, and the whole heading intercept espeicially and nav1-heading-error method we're using is wrong. Maybe we can treat interception and ils hold as two seprate functions. I _guess_ autopilots separate the interception and tracking modes. Check out the KAP140 autopilot in the default C172. The nav/localizer hold mode is implemented with 3 controllers. One controls the ailerons to reach a specified turn rate. This turn rate is output by a controller that gets the desired intercept angle as input. The third controller outputs this desired intercept angle from the nav/localizer needle deflection. The second mentioned controller uses the heading bug as reference so the desired intercept angle is to the left or right of the current heading bug heading. Heading bug has to be set roughly to the radial or the desired course for this to work right. This works in crosswinds too. Try it! If this explanation was less than understandable (my fault entirely) then take a look at the KAP140.xml file under /Aircraft/c172p/Systems. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cesna autopilot seems messed up
On Wednesday 05 May 2004 06:17, Seamus Thomas Carroll wrote: To test if a problem resides with the cesna autopilot i tested using Add Waypoint and instead of the autopilot guiding the plane to the waypoint it just flys in cirlces until it spirals into the ground. This autopilot with the cesna did work correctly that last time I tried it a couple of weeks ago. Has someone changed cesna autopilot config file to cause this incorrect behaviour? The default Cessna (--aircraft=c172-3d and c172-2dpanel) have changed autopilot from the generic to a KAP140 autopilot. A new instrument has been added to the cockpit and this should be visible below the ADF radio. The KAP140 does not have a route manager so consequently you can not define a route for it to fly. For instructions on how to operate the KAP140 you should download the Pilot Guide from the Bendix/King website. Is it a problem with the set up on my end? You can of course edit your *set.xml file to change the autopilot back to the generic. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Has there been any changes to the use of FGRouteMgr
On Wednesday 05 May 2004 10:01, Erik Hofman wrote: Seamus Thomas Carroll wrote: Lots of the code is not important to you. Essentially i pull the (lon, lat) points from the database and add them to the SGWayPoint. Upon running my code after a cvs update the planes no longer follow the path but instead fly in tight circles until the plane eventually crashes. I cant seem to find the change that has occured to cause this effect. Has there been any changes to the autopilot or the FGWaypoint that may have caused this problem? I'm not sure this is related, but Roy Vegard Ovesen added a method to add two waypoints to the gps module which caused some properties to be renamed: The gps module does not use the route manager. The properties that I changed are very new and AFAIK nothing else uses these property names (instruments, autopilots) yet. I changed them because /instrumentation/gps/ was becoming cluttered with new properties. So I moved waypoint specific properties into a subfolder, wp. Be aware that the propery names that I have added to the gps module are subjected to change in the future (I will not change any names that were in the gps before I started working on it). If anyone creates instruments or autopilots based on the gps module, keep in mind that the property names could change and brake your work. I'm sorry for this inconvenience but the gps module is work-in-progress (isn't everything?!). -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cesna autopilot seems messed up
On Wednesday 05 May 2004 11:55, Roy Vegard Ovesen wrote: The default Cessna (--aircraft=c172-3d and c172-2dpanel) have changed autopilot from the generic to a KAP140 autopilot. I announced this change on this list http://baron.flightgear.org/pipermail/flightgear-devel/2004-April/027384.html -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cesna autopilot seems messed up
On Thursday 06 May 2004 04:11, Seamus Thomas Carroll wrote: Are there plans to add a route manager to the KAP140? I guess that a reasonable setup for a light aircraft like the C172 would be to have a GPS as the route manager. Currently, the FlightGear GPS module only handles two waypoints to calclulate a leg between the two. You would have to manually change the waypoints, or maybe use a Nasal script to change them automatically. The KAP140 (and I guess most autopilots) have no notion of route or waypoint. It only tries to fly the aircraft based on turn rate, heading bug, course deviation indicator, static pressure (altitude), pressure change rate (vertical speed) and glideslope deviation indicator. Of course the deviations could come from the GPS module instead of from the nav radio module to get the aircraft to fly to the GPS waypoint(s). That would require a change in the autopilot config file to make the controllers get input from the GPS. If not what property do I change to use the generic autopilot? I have tried different changing values in different xml files but with no success. To change autopilot config file of any aircraft look in the *-set.xml file for the aircraft. The entry for the C172 is around line 40: systems autopilot pathAircraft/c172p/Systems/KAP140.xml/path /autopilot *** /systems I guess you have to restart FlightGear for the change to take effect. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear news letter
On Saturday 08 May 2004 00:28, Curtis L. Olson wrote: For an upcoming newsletter article I am [hopefully] writing an introduction to modeling aircraft flight dynamics in YASim. For a subsequent issue of the newsletter I think I'd like to walk the reader through the process of creating a specific aircraft model in YASim. I have borrowed a POH for a Super King Air 200/200C which gives a *ton* of great information for modeling the aircraft's flight dynamics, so I think this would make a great candidate for this exercise. (It would be nice to have a few more turboprops in flightgear, and the king air is just a really cool design and would be good to have anyway.) So my question is this. Are there any 3D modelers out there who would be interested in participating in this exercise by creating a (or adapting an existing?) 3D model for the King Air 200 and animating/texturing it? I don't know if there is any 3d models from MSFS land we could get permission to use/adapt? I downloaded a MSFS King Air B200 by Chuck Dome and Mario Coelho. This appears in a text file in the package: I hereby declare this aircraft package to be in the Public Domain. Anyone may use it for any nonviolent purpose, including commerce, without permission. It should not harm your computer but, if you imagine it has, I accept no liability. So I guess that we are free to use that model. I tried to contact the authors, just to be on the safe side, but I haven't gotten any reply. I've started work on this model: http://home.tiscali.no/rvovesen/king_air_ext.jpg http://home.tiscali.no/rvovesen/king_air_cockpit.jpg -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] making instrument scales with MetaPost
On Tuesday 18 May 2004 19:09, Melchior FRANZ wrote: Andy has once posted a method to create instrument scales using Perl to output PostScript commands. While I like Perl, I'm not good at PS, so I tried an alternate approach: MetaPost. MetaPost is a spin-off of MetaFont, which was designed to create the fonts for TeX. Is comes with typical TeX installations and should be available on any Linux/Unix workstation. Here's a small MetaPost file that I used to make the Bo105 rotor tacho (which is totally made up; need some expert advice first): http://members.aon.at/mfranz/tach.mp (1.9kB) It's still quite trivial and does only use a tiny fraction of MetaPost's possibilities. Also, it's not the best coding style yet. I'll probably make a library with common functions (like arc) as I see need. MetaPost creates PostScript files, that I converted to png/rgb using convert/rle: http://members.aon.at/mfranz/tach.png (23kB) I also used MetaPost to create an instrument face for the fuel gauge of a King Air 200. http://home.tiscali.no/rvovesen/fuel.png (19,964 bytes) http://home.tiscali.no/rvovesen/rose.mp If your example is not the best coding style then I would say that mine is probably _the_ worst coding style. :-) Note that the fuel gauge starts at beginfig(2). Figure 1 is a compass rose. I used polar coordinates to draw the scale lines at desired angles and radii. I also used polar coordinates to place the numbers at the exact same angles as the lines. It looks to me like you have carefully chosen the cartesian coordinates to place the number labels at. I opened the postscript file with Gimp. Upon opening, one can select the resolution (DPI) and the amount of anti-aliasing of graphics and text separately. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get cesna to follow a set of way points.
On Thursday 20 May 2004 23:50, Seamus Thomas Carroll wrote: Hi Jim, I was the one who asked this question but when i tried to implement the solution it resulted in the same flight behaviour. I will detail the changes i implemented so you can see if i did anything incorrectly. 1) I changed, in file Aircraft/c172/c172-610x-null-set.xml, pathAircraft/c172/610x-autopilot.xml/path to pathAircraft/Generic/generic-autopilot.xml/path Did you see?: http://baron.flightgear.org/pipermail/flightgear-devel/2004-May/028021.html The *-set.xml file for --aircraft=c172 is actually Aircraft/c172p/ c172p-set.xml. This is the file that you have to modify. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: making instrument scales with MetaPost
On Thursday 20 May 2004 12:01, Melchior FRANZ wrote: BTW: this is my little transparency trick: in my fgfs.mp library file I have this: color foreground, transparent; background:=black; transparent:=white; white:=255/256white; foreground:=white; which lets white actually be written as 254/254/254 ... white enough (who needs true white, anyway), and transparent areas are 255/255/255. Note that 1/2a is the same as (1/2)a or .5a, and not 1/(2a). *** now I can draw foo withcolor transparent *** and later, in my Makefile I have lines like these: foo.rgb: foo.mp Makefile mpost foo.mp convert -density 1024x1024 foo.1 -transparent white -resize 256x256 sgi:foo.rgb One can also use Gimp to turn a color to alpha (Filters-Colors-Color to Alpha...). When doing this, the shades of the color becomes shades of alpha. For antialiased edges this works very well. Downside is of course that it is much more work :-( -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: making instrument scales with MetaPost
On Thursday 20 May 2004 18:34, Melchior FRANZ wrote: OK, here's a new version, just so you can see how easy instrument face creation with MetaPost is. Note that there's a function @() defined, that maps the real instrument angles to MetaPost angles. So I could directly input all the values as I saw them on the cockpit photo. This @() function proved to be very powerfull and it made creating scales very easy. I can see this function modified to create non-linear scales (exponential, logaritmic ...), scales that go counter-clockwise ... I renamed it to aout() and ainn() when I needed two of it, because MetaPost apparently did not like names like @out() and @inn(). I would recomend to anyone trying to decide how to create instrument faces to at least take a look at MetaPost. With a bit of experience it becomes quicker and a lot more accurate than hand-drawing. Download Melchior's example and start from there! I used the example file to recreate the King Air Fuel Gauge, and I'm continuing to create several other instrument faces for the King Air. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get cesna to follow a set of way points.
On Friday 21 May 2004 06:01, Seamus Thomas Carroll wrote: Thanks Roy, I looked at the post and it is dated the day i left so i must have missed it. I would like the autopilot to adjust to new waypoints faster but I do not know how to make the plane turn quicker using the generic autopilot. Looking at the documentation i am guessing i need to modify the u_min and u_max but after modifying the heading bug hold i am not noticing and improvements. Does anyone have a hint? AFAIKT the waypoint mode is tied to the true heading hold mode. What you can do is to modify the u_min and u_max around line 137 in generic-autopilot.xml to allow the autopilot to command a greater bank angle say 40 degrees instead of the current 20 degrees. But this might cause the autopilot to overshoot more or even become unstable. Remember: controller tuning is an art ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: making instrument scales with MetaPost
On Friday 21 May 2004 23:41, Melchior FRANZ wrote: * Roy Vegard Ovesen -- Friday 21 May 2004 23:26: This @() function proved to be very powerfull and it made creating scales very easy. I changed this to a unary operator #. So one can now write #10 and metapost will replace this by the angle that represents the scale value of 10% RPM. I can see this function modified to create non-linear scales (exponential, logaritmic ...), scales that go counter-clockwise ... Yeah. I uploaded a new version that contains a weird ASI with non-linear mapper #n. Looks strange. No idea what they had in mind. I guess that when one wants to monitor for example the approach speed it makes sense to have greater scale resolution around the approach speed. This document contains a lot of MetaPost hints and methods, and is a nice supplenet to the user manual: http://www.pragma-ade.com/general/manuals/metafun-p.pdf -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Alias in 3d instruments
Hi! I tried to use the alias feature in a 3d instrument config-file: PropertyList pathfuel_gauge.ac/path params tank-selectconsumables/fuel/tank[0]/level-lbs/tank-select /params animation typerotate/type object-nameNeedle/object-name property alias=../../params/tank-select/ interpolation entryind0/inddep-216/dep/entry entryind700/inddep-90/dep/entry entryind1400/inddep36/dep/entry /interpolation axis x-1/x y0/y z0/z /axis /animation /PropertyList And that worked OK, the gauge showed the contents of tank[0], the default. When I wanted to show the contents of another tank (tank[1]) , I used the same approach as for 2d instruments. I added this to the model config file: model nameFUEL/name pathAircraft/king-air-200/Instruments/fuel_gauge.xml/path params tank-selectconsumables/fuel/tank[1]/level-lbs/tank-select /params offsets x-m2.809/x-m y-m-0.757/y-m z-m0.556/z-m pitch-deg-38/pitch-deg heading-deg90/heading-deg /offsets /model But the gauge still shows the contents of tank[0]. Is the alias feature unavailable for 3d instruments, or have I used the params tag incorrectly in the model config file? I was planning on using the alias feature for a lot of switches, instead of making a lot of 3d-instrument config files. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Wind direction inconsistency
I was looking at the clouds at KSFO today and noticed that the clouds were moving towards the wind as indicated by the windsock. Windsock pointed towards 80 deg and clouds were moving towards 260 deg. I checked the environment subtree in the property browser, and sure enough the wind was coming from 260 deg, so the sock was pointing in the right direction. I also checked the weather conditions GUI window to make sure that the wind wasn't actually blowing the other way at the cloud layer altitude (it wasn't!). I checked the indicated airspeed, while parked heading towards the wind, 260 deg. It indicated 18 knots, the same as the wind-speed-kt property under environment. That made sense. It seems that the cloud layer is mowing in the wrong direction. After changing the wind direction and updating the cloud layer, they were stil moving directly opposite of what one might expect. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] King Air cockpit progress (and question)
Here is a shot of the King Air cockpit i'm modeling: http://home.tiscali.no/rvovesen/king-air-cockpit.jpg Also I have a question: The fuel panel texture on the left has two semi circles that have alpha 0% (transparent) in order to show fuel level gauges that are supposed to be placed slightly behind the panel. The fuel level gauge that is visible on the right side of the fuel panel actually has a textured face, but it is not visible through the transparent semi circle. Note that the Fuel system circuit breakers panel texture is visible through the transparent semi circle. The fuel level gauge has been included in the model xml file as a model tag. Could this be the reason why the gauge face texture is not visible? I believe David Megginson's Piper cockpit uses the same technique: A panel texture with transparent holes and instruments behind those holes, so I guess it should be possible. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 00:25, Lee Elliott wrote: This might be due to the ordering of the transparent objects relative to the non-transparent parts. Is/are the model objects in .AC format? I use Blender, and export to .AC format. If so (I don't know if this also applies to other object formats such as .3DS) try moving the transparent parts to the bottom of the object hierarchy/list. How do I do that? Editing the .AC file with a text editor? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 04:08, Ampere K. Hardraade wrote: I don't know how things are done in other 3D modelling softwares, but in 3D Studio, each effect has a seperated mapping channel. For example, if you want transparency in certain areas of a texture, you need to assign a map to the transparency channel of that texture inorder for those certain portions of the latter to possess true transparency. Usually, the map can be the same file as the texture itself, though you have to play around with the options a bit so that the transparency is based on the Alpha instead of RGB. Check this out: http://waylon-art.com/uvw_tutorial/tut401_a.jpg Notice the various mapping channels: ambient, diffuse, specular color, specular level, glossiness, self illumination; the list is quite long. As I said, I don't know how things are done in other 3D modelling softwares. Your best bet will be looking for the dialog box that allows you to apply different effects to a texture in the 3D modelling software that you are using. In Blender one can select, at least, opaque or alpha, but I guess that this does not get carried through in the export to AC3D format. AC3D uses alpha. But as you can see from the screenshot the holes _are_ transparent because you can see the other panel texture through it.But you can't see the gauge face texture through it. The difference between the other panel texture and the gauge face texture is that the panel texture is part of the plane 3d model, and the gauge face texture is included to the model through the model xml config file. I suspect that this is what is causing the problem. Regards, Ampere On June 4, 2004 06:25 pm, Lee Elliott wrote: On Friday 04 June 2004 21:44, Roy Vegard Ovesen wrote: Here is a shot of the King Air cockpit i'm modeling: http://home.tiscali.no/rvovesen/king-air-cockpit.jpg Also I have a question: The fuel panel texture on the left has two semi circles that have alpha 0% (transparent) in order to show fuel level gauges that are supposed to be placed slightly behind the panel. The fuel level gauge that is visible on the right side of the fuel panel actually has a textured face, but it is not visible through the transparent semi circle. Note that the Fuel system circuit breakers panel texture is visible through the transparent semi circle. The fuel level gauge has been included in the model xml file as a model tag. Could this be the reason why the gauge face texture is not visible? I believe David Megginson's Piper cockpit uses the same technique: A panel texture with transparent holes and instruments behind those holes, so I guess it should be possible. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 14:16, Jim Wilson wrote: So far this cockpit is really looking great! Very nice work on the control box. Thanks. I found some very detailed close-up photos of a cockpit that I've recreated with a vector drawing program (OpenOffice Draw). Scanning the other responses, I don't think this has been answered yet (sorry if it has). If your fuel panel is part of the main model, then it should be lower on the stack and what you expect should be working. However, I think this might be affected by a select animation especially if the fuel panel is grouped with objects like the fuel guage models (or other animations, but I assume the only animation on a fuel panel would be select). In any case the problem isn't going to be solved by changing texture/polygon/color properties. That hole looks sufficiently transparent to me :-) Frederic's solution to change the order using select animation in the xml file worked great. I also think that that was by far the most attractive solution too. Thanks Fred. I suspect that moving the fuel panel all the way to the bottom of the of the AC model file would not have worked. When including the fuel level gauge as another AC model, it would be placed below everything else anyway, right? If none of this helps, then send your models and configs and I'll take a look. That wouldn't be until Sunday night at the earliest, because of a trip down to Portland. FWIW when modeling flat panels with bezeled guages I'm not sure there is any advantage to using this method unless there's something specific being modeled below the panel surface (e.g. certain mag compasses). For example on the p51d and the cub it isn't all that obvious that the faces aren't below the surface. On the other hand you may need this method for that side fuel panel, because it is so close...not sure. I guess I would always try it without the transparency to see what looks like first. Keep in mind that there is a performance cost to rendering things through a transparency. Is there perhaps a difference when using a perfectly transparent er... transparency and a semi-transparent transparency, performance wise?! I've also thought about using a textured needle instead of an object colored one. The textured one might look a lot better with variable alpha creating an anti-alias effect, but I'm concerned about performance. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 21:34, Roy Vegard Ovesen wrote: Frederic's solution to change the order using select animation in the xml file worked great. Ooops! That wasn't select animation it was just null animation or whatever I should call it. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Tuesday 08 June 2004 01:44, Ampere K. Hardraade wrote: I've just find this out. Check out the Models/3ds folder in your home directory. There is a mesh of KingAir in there. I'm absolutely sure that I have looket through all the 3ds models at one point, but I must have forgotten that there was a King Air model there. That model is much more detailed than the model I'm currently working on. It has over 31 000 vertices while the one I'm vorking on has about 5 000. I'll continue with the one that I've benn using, and maybe move the cockpit interior into the detailed model when I'm done. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Clickable 3d instruments
The Hunter and the Mustang has clickable 3d instruments. This is achieved by including a transparent 2d panel with action hotspots at select locations. The 2d panel is included in the top-level aircraft model xml config file, so the hotspots become aircraft-model-specific. I suspect that moving a 3d instrument would require moving the action hotspots as well. I tried to make the 2d panel with hotspots instrument-model-specific by including a 2d panel in the instrument model xml config file: PropertyList pathswitch.ac/path params switch-valswitch/test/switch-val /params !-- Include a panel with hotspots -- panel pathAircraft/king-air-200/Instruments/switch-hotspots.xml/path !-- It would be nice to include this in-line instead of in a separate file -- bottom-left x-m0/x-m y-m-0.005/y-m z-m-0.005/z-m /bottom-left bottom-right x-m0/x-m y-m 0.005/y-m z-m-0.005/z-m /bottom-right top-left x-m0/x-m y-m-0.005/y-m z-m 0.005/z-m /top-left /panel animation typerotate/type object-nameLever/object-name property alias=../../params/switch-val/ interpolation entryind1/inddep20/dep/entry entryind0/inddep-20/dep/entry /interpolation axis x0/x y1/y z0/z /axis /animation /PropertyList The switch-hotspots.xml file is a small (10x10) panel with one big instrument with one big hotspot. This worked as expected. I was also able to reuse the switch instrument at different locations in the cockpit, as expected. Is there perhaps a limit to how many 2d panels with hotspots one can include? This method adds instrument-specific hotspots to true 3d instruments. It's a bit ugly but it works and is more reusable than the Hunter and Mustang way of doing it. I would also like to redirect you attention to my post: http://baron.flightgear.org/pipermail/flightgear-devel/2004-May/028549.html Thanks! Can anyone confirm that the alias feature can not be used for the 3d animation code?! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
