DragonOSD+ Autopilot configuration

Support related stuff, for various products
Post Reply
Daniel Wee
Site Admin
Posts: 2245
Joined: Wed 25 Feb 25 2009 8:00 pm

DragonOSD+ Autopilot configuration

Post by Daniel Wee » Fri 28 May 28 2010 9:57 am

Note: Unless you have GPS home position set - the autopilot will not function under any circumstances.

* If the autopilot is active - this will be indicated on the screen with a message "AUTOPILOT (nnnn )" where nnnn is "HOME" if you're not flying waypoints. If you do not see this message, then you have not activated autopilot successfully.

The keys to successful setting up of the autopilot functon are:-

1. testing a bit at a time
2. testing one part at a time (ie. turning to home, then climbing to cruise altitude)
3. being familiar with the menu settings and able to access them quickly
4. do as much testing on the ground as possible

To do this - the first thing you'd do would be to:-

1. Ensure that you have the Elev. direction and Rudd. direction set correctly in the menu options such that you can navigate the menu in the correct orientation (ie. moving the elevator stick down bring the menu selection down, moving the aileron stick right increases the parameter value.) Note that there are separate direction controls for menu navigation and for actual flight control. The two sets are found in different sub-menus with one set purely for menu navigation, while the second set for autopilot operations.

1b. Ensure that the Elevator and Aileron/Rudder directions are correct. You can do this using the control surface test in the root menu. When you activate it, the surfaces will move in such a way so as to climb and roll/turn right. This means that for a regular plane, the elevators will go up, the rudder will go right (looking from the tail-end of the plane) if connected, and the right aileron will go up while the left aileron will go down. If you are using a wing, the left aileron/elevon will appear to be not moving. If the movements do not correspond to this description, you will need to change the direction settings for the servos in the menu options.

2. Test the autopilot without the stabilizer or IMU working first.

3. Trim out your plane so that it flies more or less straight and level before starting your test.

4. Configure your radio so you can activate or de-activate autopilot mode with a switch.

5. Ensure that you are getting good satellite readings and a solid position fix (HDOP less than 1.3 would be good)

6. We will adjust the turns first so set ROCSTEPGAIN to 0.0 for this test. Also set the Auto and GPS stabilizer gain to 0.0. Remember that changes need to be saved if you want them to persist through a power-cycle.

7. In flight, with the default autopilot settings - fly in a direction away from home. Once you are flying more or less straight (and not in too windy conditions), activate the autopilot. Verify that the autopilot label is printed on screen. Now, without any stick inputs, observe if the plane is attempting to turn in the correct direction.

8. If the autopilot is turning in the right direction, de-activate the autopilot and fly in an opposite direction. Repeat #7 above and see if the autopilot will turn correctly in the opposite direction. Remember that when the autopilot is manually engaged (ie. with the switch), you still retain control over the plane so if you get concerned about the way the plane is going, you can override it with your stick inputs.

9. If the plane is turning the wrong way in #7 or #8, re-do the test to verify it. If it is confirmed, you will need to reverse the Rudd. direction in the menu. After that, try again. Note that reversing this setting will also reverse the way the aileron stick behaves in the menu navigation.

10. Once you have the plane turning in the correct direction, you can now assess if the plane is turning too slow, or too hard. If it is turning too hard, it may start to oscillate hard - ie. turning too hard and then correcting too hard. If this is the case, you may want to reduce APROTGAIN and possibly reduce ROTSTEPGAIN. Normally if it is close to where I want it, I tend to adjust ROTSTEPGAIN. It is preferable to keep ROTSTEPGAIN no more than about 8 but even that could be too much depending on the particular servo and setup. If the plane is turning too weakly, you can increase APROTGAIN and/or ROTSTEPGAIN. Increasing ROTSTEPGAIN too much will result in exaggerated snake-like oscillation movement.

Once you are happy with your settings - turn on the autopilot and see if it brings the plane back properly from about 300m to 500m out (making sure that your radio link can go that far in the first place).

This concludes the adjustment for the turning autopilot. The climbing autopilot will attempt to bring the plane to the cruise altitude which you may want to change in the menu. Other than that, the procedure is pretty much the same except that you are dealing with the Elev. direction, the APROCGAIN and the ROCSTEPGAIN. Instead of turning left or right, you want to observe if the plane is attempting to climb or dive depending on whether you are above or below the cruise altitude. You will need to increase ROCSTEPGAIN to around 3.0 to start with and go from there.

There are other settings for the autopilot but you want to start with these. If the turn direction is correct, the stabilizer should also be working correctly. For that you will need to set the maximum allowable gain, and, optionally, a gain control channel.

Note that you could, technically, perform all these tests on the ground while walking around the field with the plane and observing the movement of the control surfaces. If you choose to do so, you may want to use a very large value for ROTSTEPGAIN so that the servo movements are move easily visible, for when trying to ascertain if the autopilot is turning the right way. Also note that you need to be moving constantly or the GPS will not put out a valid heading which the autopilot needs.

Remember, change your values in small steps. It may take slightly longer but your patience will be rewarded. Conversely, impatience will most likely result in an accident. You have been warned.

Daniel Wee
Site Admin
Posts: 2245
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonOSD+ Autopilot configuration

Post by Daniel Wee » Sun 09 Jan 09 2011 10:20 pm

The autopilot starts with APROTGAIN acting in proportion to the error in the heading. Heading error is defined as the difference between your actual heading and desired heading. So if your heading is 0-degrees and your desired heading (for home as an example) is 160-degrees, then the heading error is 160-degrees. This heading error, is then constrained by MAXHDGCHG which limits the amount of error allowed. So if MAXHDGCHG is set to 90-degrees and your actual error 160-degrees, then it will be constrained to 90-degrees. If you error is below the limit, it is left untouched.

The error is then multiplied by APROTGAIN to derive the amount of corrective feedback required (for the servos.) With this scheme, you can cause the plane to turn harder if the error is bigger, and turn less if the error is smaller. MAXHDGCHG then limits the proportional component of this error-feedback (since too great a turn could roll the plane and you don't want that.) This allows a more refined response - giving higher response at low heading errors and still not too much at high heading errors. MAXHDGCHG, therefore, limits the range in which the full proportionality works.

The output of this process is the desired rate of turn. This is now checked agains ROTLIMIT to constrain the amount of turn to command. This is to prevent the process from generating too large a rate of turn input which could flip the plane. As such, increasing ROTLIMIT will allow the plane to turn harder, and reducing it will limit the allowable action.

The derived and resultant error feedback, also known as the desired rate of turn, is now compared to actual rate of turn of the plane (differentiated from GPS heading.) This derivative error is now multiplied with ROTSTEPGAIN to produce the final correction.

As you can see, many of these parameters interact with each other in a rather complex way. There are also several limiters in place to allow better tuning of the AP response. In general APROTGAIN is fed through to ROTSTEPGAIN, both being multipliers on the heading errors and used to govern the amount of feedback. However, there are several phases of the calculations where other inputs are injected (derivatives) to modulate that feedback.

APROTGAIN determines the initial response. The idea is if I have lost control, I don't want the plane to take its own sweet time turning back. The greater the error, the faster you want the plane to turn back. On the other hand, when it is almost pointing home, you don't want it turning too much. But 180-degrees error could be too much so you limit it with MAXHDGCHG so that it won't flip the plane even with 180-degrees of error, and still get a good proportional action.

Too high a value for APROTGAIN will likely result in a "snaking" action when RTH. This is because it is over-compensating for the error. So if your plane is snaking, you may want to reduce APROTGAIN slowly.

As for ROTSTEPGAIN, this acts on the derivative ROT from the GPS and so there is some latency (which is inevitable.) A faster GPS (10Hz for example) will exhibit far lower latencies than a slow GPS (1Hz for example) and will allow a higher value of ROTSTEPGAIN without resulting in over-compensation. The derivative latency is what limits how much you can compensate (and how fast you can react to any errors).

Again, there is some interaction and overlap between APROTGAIN and ROCSTEPGAIN. The optimal values are probably best determined through trial and error than from modelling the system. I do have some scripts I use to test various settings but to be honest, it's really hard to visualize the cumulative effect - even for me, though I wrote this from scratch myself.

The same logic is applicable to APROCGAIN, ROCSTEPGAIN, MAXALTCHG and ROCLIMIT.

Post Reply