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.
I definitely agree. We should have instrument values well modeled for the sorts of intruments typically found in smaller aircraft.
I have a masters-degree in control theory,
Ok, then I will depend on you to keep me from doing anything too stupid. :-)
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 ...)
I believe that some real life wing levelers are based on the turn coordinator gyro which is why I did it that way. I guess it boils down to how it's done in real life on which ever particular real aircraft we are modeling.
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 :-)
Yes ...
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.
That's an interesting idea ... and shouldn't be all that difficult to impliment.
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.
That is true, although for a typical C172 with it's laggy and inaccurate sensors, a proportional controller might just get you "close enough." It's easy to spot small errors in a sim, but in real life there are usually much bigger errors that hide that last 0.2% that the "I" compensates for. :-)
But hopefully in the end, this will all be handled in the autopilot config file which leaves the choice up to the person building the autopilot.
This is called cascade control.
I assume that it is a reasonable approach if there's an official name for it. :-)
In stead of (or in addition to) having <proportional>, <integral> and <derivate> components, I would like to see a <pid-controller> that incorporates all three and in addition features like anti-windup, reduced set point weighing, etc. Here's my suggestion:
(I'm not sure about the propert names)
<pid-controller> <name>Roll Angle Controller</name> <enable> <prop>/autopilot/roll-angle-hold</prop> <value>true</value> </enable> <input> <prop>/instrumentation/attitude-indicator/roll-angle</prop> </input> <setpoint> <prop>/autopilot/roll-angle-setpoint</prop> </setpoint> <output> <prop>/controls/flight/aileron</prop> </output> <config> <proportional> <prop>/autopilot/roll-angle-controller/proportional</prop> </proportional> <integral> <prop>/autopilot/roll-angle-controller/integral</prop> </integral> <derivate> <prop>/autopilot/roll-angle-controller/derivate</prop> </derivate> <!-- clamping is required for the anti-integrator-windup --> <clamp> <min>-15</min> <!-- minimum aileron deflection --> <max>20</max> <!-- maximum aileron deflection --> </clamp> <beta> <!-- set-point weighing --> <prop>/autopilot/roll-angle-controller/beta</prop> </beta> </config> </pid-controller>
The <one-eighty> hack should be moved outside of the controller.
Do you have any suggestions for better ways to handle this? For heading control, -370 degrees is a lot different than -10 degrees. At some point in the pipeline, we need to be able to remap results. Either we could build a ton of tiny building blocks (at which point we might be better off just writing the autopilot entirely in nasal) or we need to have a way to tell the controller to remap the results at various stanges in the pipeline.
A PID controller is very versitale, it can be a P, PI, PD or a PID controller by setting the proportional, integral and derivate gains, and in many applications a PI controller is good enough.
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.
With a PID controlle we should have the tools to build good autopilots. Then comes the art-of-tuning :-)
Yes. I'm worried that I might end up breaking a lot of the existing tuning. I will try not too, but it's something I'm nervous about.
I'm half tempted to commit what I have to CVS. But that leaves a lot of autopilot stuff temporarily broken. So, I'm leaning towards hacking on this until I've recovered 99% of the existing functionality before doing a cvs commit. That gives others a bit less of an opportunity to track what i'm doing though. I could send a tar-ball of changes if anyone is really interested.
Regards,
Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
