Servo Drift with Arduplane

[Rick Marshall]

Chris Anderson suggested that I try this forum to get answers to a reproducible defect I think I've found in ArduPlane.  The 3D Robotics Support Team was unable to help me and I think it may need to go to the developers.

I have ArduPlane 3.1.1 in a 3DR PixHawk used in a flying wing.  I've noticed that if I start a Mission to a waypoint (all servos fully armed), but instead of letting the plane fly the mission, I just sit the plane on the bench, the servos will begin to creep in a certain direction and rail over time.  I have the servos configured as elevons and the pitch component is affected, not roll.  On inspecting the log files, the nav_pitch typically rails first to max_pitch (up or down), then the RCOut channels 1 and 2 will begin to drift at the same time causing the servos to drift.  The drift may begin immediately or may take up to an hour before nav_pitch goes from 0 to railing.

I'm planning to drop the plane from a balloon, so I need it to be seeking the waypoint while suspended from the balloon, then once released, the autopilot controls the plane to the waypoint.  I tried a small test run where I dropped the plane from 1000 feet.  Since the control surfaces were railed, the plane headed straight down to the ground (did not recover under its own control).  I had to snap to FBWA to recover from the dive.

The log files of the test flight and several bench tests are here.  I would be happy to send further details about each log file.  Some of them I had to split into BEGINNNING and END since they were loo large for Mission Planner to load.  If you look at Nav_Pitch and RCOut Channels 1 and 2 you can see the servo drift over time.

https://onedrive.live.com/redir?resid=6497757CA6F5FCAF!17261&authkey=!AH9B3DKl8xYYO2o&ithint=folder%2ckmz

 I can reproduce the drift at will.  As I said, the creeping may begin after a couple minutes on the bench or may stay stable of an hour, then creep.  But once it happens it puts the plane in a state that isn't flyable (won't recover once it begins to fly).  I'm not sure what is triggering it to drift..  I'd be very appreciative of any help you can offer as to the root cause, work-arounds, of fixes.  Thanks!

Rick

[Rick M]

Today I tried to set the I value in the PID Pitch variables to 0.  The drift still happened, and it was almost immediate.  Nav_Pitch went to -24, and at the same time RCOUT Channels 1 and 2 began to drift, then rail.  (see attached files. )

[Paul Riseborough]

Rick,

Make sure you also set both  PTCH2SRV_IMAX and RLL2SRV_IMAX to 0 if you want to safely disable the integrators, as otherwise any offsets built up due to rounding errors will not be controlled. Also don't forget to zero the I gain on the roll channel.

A larger value of I gain (so that the trim corrects quickly) and a small value for IMAX set to just enough to accommodate variations in trim could be a better approach than turning off integrators completely and losing all ability to self trim. If you do this, you will need to also increase the D gain so it matches the I gain, and go up in small increments until it starts the oscillate, then back the I and D gain off to half the value it oscillates at. This will give you the fastest possible auto-trim rate, so it will rapidly unwind the trim offset when it is dropped.

-Paul

[Rick M]

On Thursday, October 23, 2014 9:31:38 PM UTC-5, Paul Riseborough wrote:

Rick,

Make sure you also set both  PTCH2SRV_IMAX and RLL2SRV_IMAX to 0 if you want to safely disable the integrators, as otherwise any offsets built up due to rounding errors will not be controlled. Also don't forget to zero the I gain on the roll channel.

A larger value of I gain (so that the trim corrects quickly) and a small value for IMAX set to just enough to accommodate variations in trim could be a better approach than turning off integrators completely and losing all ability to self trim. If you do this, you will need to also increase the D gain so it matches the I gain, and go up in small increments until it starts the oscillate, then back the I and D gain off to half the value it oscillates at. This will give you the fastest possible auto-trim rate, so it will rapidly unwind the trim offset when it is dropped.

-Paul

Thank you SO MUCH for your reply!  I'll try these suggestions right away.  I wasn't sure of the meaning or dependencies between the other parameters.  I can't find where the design documents are or more in-depth discussions on setting the parameters in the APM website (http://plane.ardupilot.com/).

This makes sense.  It is as though an integrated error is building up since the plane is sitting there, not correcting the error.  I'm OK with the servos railing, but once the drop occurs, I need the integrated error to go away as soon as possible so the plane rights itself.  I also didn't know the rule about the D and I matching somewhat.

I'll try out another bench test today with all the integrators set to zero.  If this works I'll see if I can turn up the integrators but bleed them off quickly.  I'll let you know how it works..  Thanks again!!!

-Rick 

[Rick M]

Yeah!  I think you are on to something!  I re-ran the 1.5 hour test with the integrator values zero'd out.  Here are the results (attached).

Specifically, I set to zero (probably not all of these were needed to be set to zero):

PTCH2SRV_I

PTCH2SRV_IMAX

PTCH2SRV_D RLL2SRV_I RLL2SRV_IMAX RLL2SRV_D STEEP2SRV_I STEER2SRV_IMAX TECS_INTEG_GAIN (was .1) - Not sure if this causes integration problems as well. YAW2SRV_IMAX

The RCOut Channels 1 and 2 went up and down a little, but basically stayed centered.  Same for NavPitch.  It seemed to drift a little an hour into the run, but then came back.  It might have been following the baro altitude (see graph).  If so, this tells me that the nav_pitch will certainly change if the plane is ascending on a balloon, and the RC Outs may tend to rail,  The key will be to have them center as soon as possible, once the plane is flying.  Let mw know if you think that's what's likely to happen.

I intend to do more bench tests with increased I gains but zero IMax's.  Once I can dial in a little more "I", I'll take if flying and trim it according to your suggestions.  Again, thank you for your reply! 

Rick

[Rick M]

Forgot to attach the Baro Altitude graph.

[Paul Riseborough]

Rick,

Don't worry about Nav Pitch (demanded pitch from the speed and height controller), it will move up and down with baro. A few notes you may find useful:

If you are not using an airspeed sensor it is essential that LIM_PITCH_MAX is set to a value that the plane can glide at without stalling. Similarly LIM_PITCH_MIN should be set to a value that doesn't overspeed the airframe. When dropped in RTL or other auto mode the TECS controller will be demanding a pitch angle close to LIM_PITCH_MIN which should pull back to the value set by LIM_PITCH_MAX as it drops below the demanded height.

If you are using an airspeed sensor and wish to glide at a set airspeed, then TECS_SPDWEIGHT needs to be set to 2.

I wouldn't advise zeroing D gains (rate damping) for an airframe that is being dropped, their is a chance it could tumble initially, and the D gains will help the recovery.

Dropping in auto modes can be a problem as the control loops don't handle the -90 degree pitch case well in these modes. It is safer to drop in FBWA and switch to auto when the nose has been pulled up, or after a time delay.

There have been few people asking questions about using APMPlane for high altitude balloon drops, so it might be worth the project creating a wiki page to share knowledge for this use case.

-Paul

[Rick M]

Thanks for the additional info Paul!  This is really helping.  From your previous suggestions, I ran a series of 5 tests to see if I could determine which integrators needed to be set to zero or could be turned down to eliminate the drift I am seeing on the bench.   Would you (please) look at the summary of the results I attached?  The XLSX file contains a summary of the parameters I changed for each test.  The Word doc gives a summary of what I was trying to test for and what I thought I saw (to be honest, its hard to interpret the results from black box testing, not knowing the design of the system).

Some of the results from the testing:  1)  I can eliminate drift if I keep TEC_INTEG_GAIN set to 0 (Pitch and Roll IMAX were also still 0, but I was able to dial back in I and D for Pitch and Roll). 2) Something appears to suddenly wake up Nav_Pitch to go from 0 to non zero.  You are right, it seems to follow Baro Altitude, but there is something else also affecting it.  3) RCOUT seems to follow the patterns of NavPitch 4) Seems I also need to turn down Steering Parameters (maybe since the speed is so slow, they also kick in?).

Please take a look and let me know what you think.  The ultimate goal isn't really to eliminate the servo drift (I don't care if they are railed when the plane drops).  The bigger goal is to make sure the plane recovers once dropped (the integrations go away).  I suspect that I will need to dial back in TEC_INTEG_GAIN and others, but I don't know enough about how the system works in order to set all the parameters.  Last time I tried it, it almost cost me my plane from a 1000 foot drop!  Is there a way I can know that the drift will bleed off once the plane begins to fly even if he servos are off-center?

I have couple of related questions (see below)  however, they all seem to come from the fact I can's seem to find a good explanation of the system control for the plane configuration.  Either from a design point of view or a practical "here's how things are related and should be set up" (Yes, I've read the getting started pages).  I have the link to all the parameters, http://plane.ardupilot.com/wiki/arduplane-parameters/, but there is little explanation as to how they relate to one another.  For example, I didn't' know how the plane behaves as you described given the setting of LIM_PITCH_MAX and LIM_PITCH_MIN.  Is here a place I can go to for a more in-depth explanation of the design?  I'm a software engineer so I'm used to a little insight into the design.

Some of the other questions are:

1) How does Nav_Pitch ultimately affect RCOUT (what is NavPitch?).  I looked through the code and found SEVERAL places that affect its value. My testing keeps showing that RCOUT gradually follows NavPitch.

2) How does TEC_INTEG_GAIN affect RCOUT. 

3) What's the relationship between the TECS algorithm and the other algorithms found in the code affecting pitch/roll (in Attitude.pde, Arduplane.pde, AP_PitchController.pde etc).  Is there a PID loop controller and also a TECS potential energy/kinetic energy algorithm for speed and height?  How are these related.  Again, is there a system diagram that shows how the various control loops are related?  I'm guessing that I can't shut off TEC_INTEG_GAIN for real flights, but I don't know.

A couple comments on your recent (appreciated!) suggestions:

1) Thanks for the suggestion on the LIM_PITCH Settings.  Do I also need to set ARSPD_FBW_MAX and ARSPD_FBW_MIN to correspond to glide speeds? (not sure how PITCH limit settings relate to ARSPD limit settings if the plane goes too fast or slow at a MIN or MAX pitch.  I intend to do gliding tests and record the glide pitch and speeds and set these values.  Sound OK?

2) Yes, I'm running without an airspeed sensor (hopefully).  If I need one, I'll add it but for now, I was trying to stay simple.

3) Yes, the D values (and I values need to come back and hopefully I showed that that can be done without getting drift back (although I didn't try to dial back in the IMAX param).

4) The reason I was dropping in auto mode was that I was trying to use the code as-is (no programming modifications) and I thought that the only way to do timed things like "Release from balloon now" was to set it on a mission with delays and set-servo commands..  Also, the plane will be about 22 miles away when it drops, so it needs to execute commands all by itself (no radio).  So I don't know how I could send it up with FBW and have it time a drop and time a change to another mode such as auto.  If I've missed something, I'd really like to know.

5)  The plane will be dropped horizontally, not vertically down, so I was hoping to avoid the -90 degree problem (although in the vacuum of space, who knows).

6)   Good suggestion on starting a wiki page.  Yes, there is a discussion group on DIYDrones for balloon project.  I need to check in more with them (I've posted this issue on it but without response so far).  It would be really helpful to get descriptions of the system design so we could discuss our options more intelligently.

Thanks again for ALL your help!  I'm really excited to get this project moving again.

Rick

[Paul Riseborough]

Rick,

Drift in the demanded pitch angle from TECS when sitting on the ground is not a concern and turning off the TECS integrator will not completely stop it due to drift in baro over time. All the TECS integrators have wind-up protection and TECs will not demand a pitch angle lower than the min value set by LIM_PITCH_MIN.

Can you provide a link to the specific file containing the log for the drop where it wouldn't pull out? That link you provided goes to a directory with a lot of files in it.

Dropping in a level attitude will cause it to pitch down rapidly with the possibility it could over rotate (and flying wings can tumble). You would be better to drop it nose first at a very steep  angle (eg 70 degrees) in FBW-A and switch to auto when the nose has pulled up about -45 degrees. The problem with dropping in auto is that it could be getting rapidly switching bank angle demands as the nav controller does not work well in vertical flight (horizontal velocity is zero so it doesn't know which way to bank) and these rapidly chaningin bank angle demands can interfere with the pullup, particularly with an elevon model.

Ideally the priorities for a drop in thin air should be:

1) Stabilise angular rates
2) pull the nose up
3) level the wings
4) start navigating

This may require some modifications to the code to achieve the correct sequencing, but I can help out with that if required.

The only documentation that exists for the controllers is what is in their respective wiki pages:

http://plane.ardupilot.com/wiki/tecs-total-energy-control-system-for-speed-height-tuning-guide/
http://plane.ardupilot.com/wiki/roll-pitch-controller-tuning/

-Paul

[Rick M]

Hi Paul,

YES! I would very much appreciate your help!  I don't mind having to make code changes, etc. but I'm a bit lost in the design/code, and have no test bed to simulate modifications (yet!).

Here is a link to the "Dive Into The Ground From A Balloon".  https://onedrive.live.com/redir?resid=6497757CA6F5FCAF!19631&authkey=!ABI37cT0iSsvIoM&ithint=folder%2cparam

The file is 2014-10-09 09-45-32.log.  I also chopped off the front end of the flight in the log file and renamed it to 2014-10-09 09-45-32 - END.log since I wanted to zoom in on the drop and my Mission Planner doesn't allow me to zoom (I think I need a re-install?).

If you graph RCOUT for Channel 7, you can see the exact time  the "pin" was pulled and the drop occurred.  Once I started the Mission, the plane tries to go to a waypoint about a 1500 feet away.  The channel 7 "pin" moves in and out within 5 seconds letting me know that it is executing the Mission (I observed this).  Then there is a 15 minute delay and the pin is pulled.  I let the plane rise on the balloon within this 15 minutes and the pin was pulled  exactly on time automatically. (the real flight will have about and 80 to 90 minute delay, or if we get into the code, I can wait for an exact altitude).  The total drop was about 170 (meters?).  I had 1000 feet of line on the balloon tether, but there was a wind and the tether was pulled to an angle, and the plane is on about a 50 foot cord below the balloon.

Interesting to go back and observe what actually happened.  The servos were "railed" during the ascent, but as soon as the drop occurred they immediately went back to neutral.  The plane pitched down to -50 to -60 and stayed there (under control??)  until I took it over with FBW.  Interestingly, I had the LIM_MIN_PITCH limit set to -24, yet it seemed to stabilize at -60 (the servos did not call for UP).  The ARSPD_FBW_MIN was 6 and the ARSPD_FBW_MAX was 22.  The max GPS SPD it hit was 22 (not sure how accurate this is).  Was it thinking it could fly down until it reached 22 m/s?  Or will the LIM_MIN_PITCH be observed first and limit the speed?

I was using all the same trims for the plane (I think) that I used when I had a motor on it and it was flying missions.  I included the parameters saved file (Test Flight 10-09-14 - Marshall, also in the log of course), and the Mission Plan.  After trimming the plane with the motor, I then removed the motor/ESC/Battery and repositioned the inside components so the CG was in the same place and it approximately was the same weight (added a camera, GPS and new battery).  This converted it to a glider.   So I thought the plane would be trimmed to fly still.  Since the "crash" I took the plane out and threw it down a hill to see if it would still fly with the same trim parameters.  It wanted to nose down too much (not severely like the crash but I had to keep applying back stick in FBW mode to keep the nose up a little).  So I recalibrated the accelerometers and it seems to fly OK by itself if I throw it off a small hill.  I had to also change the PTCH2SRV and RLL2SRV from about .33075 to 1.7 (big change) since the servos didn't seem to move much.  I left the I and D as is.

I'd still like it to fly a little more nose up (seems to fly very fast at a 1:6 glide angle), but don't know how to "trim" level on  FBW, other than telling it what level is during accelerometer calibration.

BTW, in the same directory, I updated the Drfit Tests.DOCX and Drift Tests.XLSX with a Test 6 showing that if I dial in IMAX to 500, I get the servo drift back a little but not too bad (also Test 5 results were mis-labeled in the previous XLSX file).  In light of re-examining the Drop Test, maybe the servos railing aren't the problem.  They seemed to go to Neutral almost immediately after the drop.  Hmmm...

Thanks again for all your help.  After you get a chance to review the Drop Test, let me know what you think was going on and what I should have adjusted.  If you think I should also go to the code for modifications, let me know.  So far, I've been able to download the source from git and compile it to .px4 with the PX4 Console.  I was also wondering if its possible to compile from Visual Studio.  I read the article on the wiki on this but it seemed to be for Arduino only compiles.  Let me know if its possible to compile for the PixHawk platform from Visual Studio.

One more thing:  If you want to see my video/pictures from my first visit to space, check out www.bertha2.com .  I sent a Styrofoam box with two cameras and GPS's in it to 106,000 ft.  Very fun.  I'm also a private pilot and love to fly.  Thanks again!

Rick

[Paul Riseborough]

Rick,

Looking at your log a few things stand out:

1) You were doing the ascent in an autopilot flight mode and because of the balloon motion, the autopilot loops thought they are flying and started winding up the integrators in the pitch and roll loops.
2) The IMAX values were bigger than they need to be to compensate for trim offsets.
3) When dropped, the integrator for the pitch loop was on the lower limit and took a long time to unwind due to the low I gain. Also the P gain was not high enough to counteract the effect of the integrator.

Recommendations are:

- do the ascent in manual and switch to the required autopilot mode just before the drop
- drop it nose down
- reduce your IMAX values to 50
- The airspeed estimation can cause problems with inconsistent gains when no airspeed sensor is fitted, as it relies on regular turns to estimate wind, and therefore airspeed. This airspeed estimate is going to be wrong in your application. I recommend SCALING_SPEED be to a large number (eg 150) which will force the autopilot to use constant gains corresponding to the low airspeed case. You will need to check that these gains don't cause it to oscillate in a dive.

-Paul

[Rick M]

Hi Paul,

Based on your last few suggestions and the settings I used when I last trimmed the plane to glide down a small hill, I've attached a file showing my best guess at the parameters for the next flight.

Could you take a look and let me know if you agree or if there are any other parameters that I should also set?

I think I'll try the "down the hill" test first, then re-drop from a balloon.  I'll try it in Manual mode going to auto just before the drop (with nose down).  Of course, for the real drop, I'll have to work out something else (code change or something).

Rick  

[Paul Riseborough]

Rick,

See mark ups in the attached file:

-Paul

[Robert Lefebvre]

Paul, I wonder if you could use a technique similar to what I used on Helicopters to solve some of this problem.  When we are not sure we're flying, the I-term leaks to zero.  This prevents any small errors from adding up to large I-term wind-ups.  

In my case, the problem happens because the Stabilize controller wants the helicopter to be perfectly flat. But when it's sitting on the landing pad, the I-term starts ramping up.  This can wind it up, and then it tips over when the rotor comes up to speed. So, I just have a leak rate back to zero which can cancel this out.  When GPS reports we're moving faster than 3 m/s, safe to assume we're flying, and then start using full I-term.

You could do something similar with airplane.  When your speed is low, such as sitting on the ground, or dangling from a balloon.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Riseborough]

Rob, the integrators are prevented from winding up when on the ground, the problem is that when dangling from a balloon, the combination of motion and height makes it think it is flying.

[Rick M]

Paul,

Thanks for the comments on these settings. I'll use them on the "down the hill test" and go from there.  I'll let you know how things turn out.

Rick

[Rick M]

Paul,

Wanted to show you the GOOD news on the test flight.  I used the settings you suggested and trimmed the glider for the down-the-hill tests.  Even for such short flights, the glider performs very well and is able to fly a very short mission on its own.  I've attached 3 log files here if you would like to take a look:

https://onedrive.live.com/redir?resid=6497757CA6F5FCAF!20341&authkey=!ACQwMrDhQfbeggQ&ithint=folder%2cbin

The three files show

1) Three flights under FBWA.  I toss the glider, run it back up the hill, then toss again.

2) One flight starting in FBWA then almost immediately flipping to AUTO.  It seems (could be my imagination) that FBWA flight characteristics are different than AUTO.  AUTO seems much more stable and follows more closely to the LIM_PITCH_MIN value.

3) One flight set on AUTO in which I waited 10 minutes before tossing it (simulates balloon suspension a bit).  It perfectly took off flying the mission right away! 

I gradually changed the LIM_PITCH_MIN and LIM_PITCH_MAX so it would fly more and more nose up.  In the end I used 250 (Max) and (0) Min.  It is now flying with about a 1:6 glide ratio (more Shuttle like than glider, but for this application is really looks good).  I also increase the P from .4 to 1.5 and the D&I are set at .03.

I've also notices that I have NO control of pitch from the radio when I switch to FBWA (Roll still moves the servos, but Pitch does not).  not sure why that is.

In the future, I'll try longer "balloon suspension" times and throwing it off a larger hill.  I'd also be interested still in looking at the code to se if I can start off in MANUAL, then switch to AUTO before the "drop" (or follow the sequence you suggested in your earlier posts.

Rick

[Paul Riseborough]

Rick,

I haven't had a chance to check your logs, but a note of caution anyway:

Check the CTUN nav pitch(demanded) and pitch (measured). If measured pitch hasn't converged on the demanded pitch by the end of the glide, then you need to either adjust your elevon trim and/or increase the I gain to get it to trim faster (I gain  can be up to 2x the D gain) before adjusting the upper pitch limit to raise the nose . Otherwise when dropped from a higher altitude, the integrator could further pull the nose up and result in a stall.

-Paul

[Robert Lefebvre]

Right but, using a LeakyI when you are not sure if you're actually flying or not, could be a useful intermediary stage.  That what I'm doing, when our ground speed is low, we're not sure if we're flying or not, so use Leaky-I.  

Out of curiosity, briefly, how does Arduplane guess if it's flying or not?

[Rick M]

Paul,

Yes, it looks like on at least the last flight, nav pitch went up to 250 (lim_pitch_max) after being launched, while the pitch worked its way up toward 0 but never got to 250 (coincidentally this was lim_pitch_min, or pitch was just lagging behind and would have made it to 250 eventually).  I set the waypoint altitude above the plane so it would try to use lim_pitch_max (right?).  If the waypoint is below the plane (which it will be for the drop), will I also need to trim it to glide with lim_pitch_min?  Besides just trying to make it to the min or max pitch, what else goes into adjusting the pitch for a "glider" (no throttle).  Does gps speed (no airspeed sensor), or any other outside inputs play into what the pitch is?  It seems like instead of just trying to get it to a certain pitch, it also knows how to "fly the plane" (it is also adjusting the control surfaces up and down while trying to get to the max pitch.

Also, what did you mean by "adjust the elevon trim".  Did you mean physically adjust the flight surfaces or adjust some other parameter (e.g. elevon mixing?).

Rick

[Paul Riseborough]

Rick

Your demanded pitch angle in FBWA, stays at 0 degrees (i don't see you trying to control it with RCIN during FBWA), and the plane was pulling up to it towards the end of the glide. In auto it was pulling up to the maximum of 2.5 you had set, but this is too high and could stall it. Your upper limit shouldn't be higher than 0. Your lower limit should be set low enough to allow it to glide at a fast speed to penetrate wind during the early part of the high altitude descent.

You can force TECS to use a smaller range of pitch angles than is available to the pilot in FBWA, by setting the TECS_PITCH_MAX and TECS_PITCH_MIN values to different values, but unfortunately if TECS_PITCH_MAX is set to 0 or lower, the LIM_PITCH_MAX will be used, so this probably isn't useful in your case, so you will just have to perform the flare manually.

The autopilot adjusts the control surfaces continually to try and track the demanded pitch and roll angle. The demanded pitch angle in FBWA is supposed to be set by your elevator stick position, and in auto modes, it will be set dpending on whether it is above or below the demanded height.

You need to trim your plane in manual mode and then perform the RC calibration as described here: http://plane.ardupilot.com/wiki/arduplane-setup/first-time-apm-setup/

That will ensure you have a trimmed plane when you drop or launch it.

-Paul


If you would like a large range in FBWA, you can use different limits in FBWA t

[Rick M]

Paul,

Thanks for your comments and suggestions!  Really helps.  Looks like I should go back to the basics and re-trim, from scratch, the Manual, FBWA, and AUTO.

It was true that I didn't apply any up while in FBWA.  I did a ground test and noticed that I wasn't getting ANY travel on the servos from the elevator manual channel while in FBWA.  So I launched it and just watched what it would do. It flew by itself just fine (except it headed a bit down).  Could you tell me what your last line was suggesting:  "If you would like a large range in FBWA, you can use different limits in FBWA t..."  I would like to see more travel from the control stick while in FBWA, but seem to have lost it.

One other question regarding calibration.  When I install the PixHawk board, it is approximately level with respect to the cord of the wing, however, it is probably just close.  Also, when I calibrate the accelerometers, I'm just holding the plane at the approximate zero degrees and 90 degree angles.  So isn't it possible that I would like the plane to fly at 2.5 degrees (or some positive angle) to get a proper glide (i.e. the Pixhawk board might be at 2.5 degrees while the plane is flying perfectly trimmed for a downward glide.  Or do I need to be much more precise about the 1) mounting of the pixhawk board to go through the cord line (or some other datum line), and 2)calibrate to precisely zero degrees, etc.

I intend to install a hook on the bottom of the glider so I can launch with high start (giant elastic surgical tubing) and get much more height and longer flights.  I'll be able to performed better trims.  Stay tuned!

Rick

[Paul Riseborough]

Rick,

Answers below:

"Could you tell me what your last line was suggesting:  "If you would like a large range in FBWA, you can use different limits in FBWA t..."

It is possible to set TECS (which operates in auto modes) to us a smaller range of pitch angles by setting the tecs pitch limits to non zero values. Unfortunately, this is set up for power planes, so the max pitch angle in tecs cannot be set to a negative number, so it doesn't help in your case unless you are able to modify the code. If you wanted to change this behaviour, you would need to modify the following line:

https://github.com/diydrones/ardupilot/blob/master/libraries/AP_TECS/AP_TECS.cpp#L727

to:

if (false) {

This will enable you to set the maximum pitch angle used by TECS which is controlled by TECS_PITCH_MAX to whatever angle you need to achieve a flat glide in auto. The maximum pithc angle used by the FBW modes set by LIM_PITCH_MAX can then be increased to a positive number (eg 150)  that allows you to flare it. Note TECS_PITCH_MAX is in whole degrees, whereas LIM_PITCH_MAX is in centi-degrees, and TECS will use the smaller of the two angles.

" I would like to see more travel from the control stick while in FBWA, but seem to have lost it."

Having a positive LIM_PITCH_MAX and negative LIM_PITCH_MIN in conjunction with the suggested TECS modification should help, as should completing the RC calibration.

"One other question regarding calibration.  When I install the PixHawk board, it is approximately level with respect to the cord of the wing, however, it is probably just close.  Also, when I calibrate the accelerometers, I'm just holding the plane at the approximate zero degrees and 90 degree angles.  So isn't it possible that I would like the plane to fly at 2.5 degrees (or some positive angle) to get a proper glide (i.e. the Pixhawk board might be at 2.5 degrees while the plane is flying perfectly trimmed for a downward glide.  Or do I need to be much more precise about the 1) mounting of the pixhawk board to go through the cord line (or some other datum line), and 2)calibrate to precisely zero degrees, etc."

 You can have the plane glide at 0 degrees on the HUD by two methods. One is to tilt the board, so that it reads 0 degrees when the plane is at the preferred glide angle. The other is to adjust AHRS_TRIM_Y.

http://plane.ardupilot.com/wiki/arduplane-parameters/#AHRS_Trim_Pitch_AHRS_TRIM_Y

I think the steps you need to follow to get it to provide the full range of control in FBWA whilst having a safe range of pitch angles in auto modes are:

1) Complete the manual trim and RC calibration
2) Modify the line in TECS as suggested.
3) Open up the FBWA pitch angle limits set by LIM_PITCH_MAX/MIN to something like +-1500 which should give you adequate control to flare and do a fast glide.
4) Adjust AHRS_TRIM_Y so that you get a flat glide in FBWA with a zero nav_pitch demand (check that nav_pitch is zero in the Mission Planner Flight Data Status display). One way to do this is to check the logs from your manual flights with the plane trimmed to to a flat glide and observe the pitch angle. If for example, this angle was -1.5 degrees, then AHRS_TRIM_Y should be set to -1.5 / 57.3 (the equivalent angle in radians).
5) Set TECS_PITCH_MAX to the pitch angle you would like it to use when below the demanded height in auto modes
6) Set TECS_PITCH_MIN to the pitch angle you would like it to use when above the demanded height in auto modes

[Rick M]

Hi Paul,

Thanks again for your guidance.

I followed your suggestions outlined in the 6 steps above.  I've attached a summary file showing the purpose of each run, what was changed between runs and the results.  The actual .bin files for the runs are here. 

https://onedrive.live.com/redir?resid=6497757CA6F5FCAF!21154&authkey=!ANvMykyOyS6eWxo&ithint=folder%2cbin

 I'm not very good at knowing what to look for in the logs so I made some notes of what I was looking at and what I saw.

The runs are a series of tuning runs (throw off the hill), followed by to AUTO mission runs.  I tried a high start, but the glider just crashed (very unstable on the elastic band).  So these are all "off-the-hill runs

I first tried setting AHRS_TRIM_Y from 0.06 to -0.06 to 0.04.  The resulting NavPitch was -1.04, 11.97, and -1.97 respectively .  Some runs show the NavPitch going from the -1.97 to 0.96 for no apparent reason (not sure what drives NavPitch).  So I couldn't get it to exactly 0 but it was close.  I left AHRS_TRIM_Y to 0.04.  I measured the angle of the Pixhawk board and it is pitch up positively 1.75 degrees  compared to the flat bottom of the airfoil (sort of a Clark Y shape)

More interesting is that Pitch always was a couple degrees more negative and wouldn't really go up to NavPitch.  I tried increasing the PID numbers and it seemed to improve but then would oscillate if set too high.

Once in AUTO mode (last two runs), the TECS-ph (pitch demand) was right around 0 (-0.017).  The pitch would start off -2 to -5 then work its way to zero.  For some reason the sp_dem was 9.244 (not sure what drives this, but it was always the same number).

It looks like it will fly relatively well if I put it up on a higher mission (e.g. another balloon drop or larger hill).  I'm not sure of its stability, or how I can test for it.

A couple of questions:

1) I'm not sure when I can say that the system is "trimmed".  I'm not sure what to compare to what for pitch, roll and yaw to see if the waveforms are lagging, etc.  And I'm not sure if I should compare different things when in 1) FBWA 2) FBWA using radio input and 3) AUTO.  For example TECS is only used in AUTO mode correct? 

2) I'm not sure what goes into determining  Nav_Pitch (pitch demand).  And I'm not sure of the two different pitch demands Nav_Pitch vs. TECS -ph and when hey are in play.

OK enough for now.  I did notice that you are the author of the TECs algorithm.  Vey nice.  Its an impressive piece of work!

Rick