If you are flying a UAV DevBoard in a plane without ailerons, you should be interested in a recent revision to MatrixPilot that will tighten the turns in waypoint mode, without overshoot. The above picture is the track of a portion of a test flight in an EasyStar. The control mode was switched from stabilized mode to waypoint mode with the EasyStar flying away from the first waypoint. So the controls performed a tight (less than 15 meter radius) "snap-turn", with very little overshoot.
Up until now, the only way to prevent turning overshoot with MatrixPilot was to use a large value for the yaw damping parameter. Although that certainly prevented overshoot, it made the turns very wide. The latest revision prevents overshoot, while still enabling tight turns.
The revision is rather simple: an optional negative feedback term equal to a gain times the roll has been added to the rudder control. The effect is to reduce the steering time constant. It is equivalent to controlling the roll rather than the yaw rate. It is something that has been on my list to do for a long time, I finally got around to it. Rana and Sid have been using this feature unofficially for some time, they encouraged me to add it. Also, there have been posts from time to time from other authors recommending roll-based steering. MatrixPilot has always used roll-based steering with ailerons, but until now, for mostly historical reasons, it used yaw-based steering with rudder.
The new parameter is ROLLKP_RUDDER in the options.h file of MatrixPilot. It is now available in MatrixPilot2.5 in the branches directory, or in the "developers" version in the project main trunk, or as a version 2.5.1 zip file. If you want to try it out, to start with set ROLLKP_RUDDER to the same value as YAWKP_RUDDER. For an EasyStar, set them both to 0.15, and set YAWKD_RUDDER to 0. For now, leave "dead-reckoning" and "cross-tracking" turned off, I am working on improving the performance of both of those. Right now they are not performing up to their potential.
The following is a portion of the track during a test with an EasyStar in which ROLLKP_RUDDER was deliberately set to 0, with YAWKP_RUDDER = 0.15, and a modest value of YAWKD_RUDDER (I forgot what it was.) to show what happens without rudder-roll stabilization. Note the large amount of slowly decaying overshoot after the snap turns.
So, if you are using MatrixPilot in a plane without ailerons, I highly recommend trying this new feature, it should improve waypoint performance.
Best regards,
Bill
Comments
Hi Bill,
what happens when there suddenly is not GPS signal anymore?
Does dead reckoning take over automatically?
I am aware there will be an growing error, but can one use this for some kind of "inhouse navigation"? E.g. to map the aisles of a supermarket, walking, without an UAV?
One would loose GPS signal the moment one enters the building.
Thanks,
Jan
Thanks Ryan, I have seen your post before. Your idea makes sense if you are not using dead-reckoning to compute position.
In your post, you said, "The largest contributor to this problem is the GPS lag."
I agree that if you use GPS directly in a heading controller, GPS lag will cause that effect that you showed in your post.
However, MatrixPilot offers an option to use dead-reckoning to compute position, which decouples the GPS lag from the control loops, eliminating the oscillations. The combination of dead-reckoning and rudder-roll stabilization provides very smooth, accurate, and stable heading control.
Consider the positional error created by the GPS group delay. For example, the uBlox has a group delay of around 1.25 seconds. That means, for example, if you are flying a FunJet at 50 meters/second, that is an error of 62.5 meters. Dead-reckoning eliminates that error.
Also, dead-reckoning refines the granularity of heading control. Even with a uBlox at 4 Hz, at 50 meters/second the plane moves 12.5 meters between GPS updates. With dead-reckoning providing positional updates as needed, you can run the navigation computations as often as you like. If you select the dead-reckoning option in MatrixPilot, navigation is computed at a 40Hz rate, which reduces the granularity to 1.25 meters at 50 meters/second.
Best regards,
Bill
PS, I am very impressed with the fact that you are a pilot, and manage to go to flight school, and still keep your hand in the world of diydrones. Keep up the good work!
I have sent you this before, but your rudder only approach would work in my scheme also. It greatly increases stability damping relative to Groudspeed vice having set gains or even ratiometric gains. This method optimizes the weighting of the roll gain in a very logical way. I'm not sure if it is 100% clear in the post so let me know if you have any qeustions as to what I'm doing. Very simple and when you see the layout its obvious why you wouldn't choose to do it anyother way.
3 more weeks of Flight school Hazing!
-Beall
Many many thanks for all you did !
With Warm Regards
Rana
Just to add a bit to my reply to you....
I did not add any more loops to MatrixPilot, I simply added a term to the yaw loop.
For rudder-only, MatrixPilot has three control loops for elevator, rudder, and throttle. Each loop is simply a weighted sum of various proportional and rate feedback inputs.
Best regards,
Bill
It really is a matter of taste what you want to call the loop that is using rudder-only to control the yaw of the plane for navigation. Call it whatever you want. I think of it as a yaw loop with roll damping.
In any case, what I now have in the loop that controls a "rudder-only" are three terms, but I recommend that you use only 2 of them, I left the third one there (yaw rate damping) for legacy reasons.
The two recommended terms are computed from a weighted sum of the following two inputs:
1. The deviation between the direction the plane is moving and the direction you want it to go.
2. The amount of roll.
The first term steers the plane in the direction you want it to go. The second term resists the first term.
Best regards,
Bill
Do you still have the yaw loop running and the roll term is used for damping or is the yaw loop completly eliminated.
I've only used aileron airframes so far, but I'm sure I'll be addressing rudder only airframes eventually.
B