Research by Ryan Beall and Chaz Henderson:

I did a little more refining of the model from the data previously described/collected from the Pixhawk.  The following are the results of System Identification and PID optimization.

The overall performance of the bank angle controller was suboptimal for our first flights.  It appeared to oscillate in numerous log files (2-3 degrees amplitude with a period of 0.5-1 seconds).  This was indicative of gains that were too high.  A significantly more accurate model was produced by finding a very clean step response in the data as seen below:

This was generated with regression so you can see that it doesn’t fit perfectly.  However, it was clear that this model was a drastic improvement to the previously submitted model.  The regression was also used to model the servo delay (0.04 seconds).  This was more of a black box approach and neglected any cross coupling in the yaw axis (fairly good assumption for this airframe)  The model above is:

As expected, this model is slightly over damped as seen by the pole-zero plot

 This model was then implemented in Simulink to verify performance with PID values used during flight:

Using gains that were close to default (what was used on initial flight), the following was the estimated response for a +-25 degree roll step response:

Roll_P: 0.4

Roll_I: 0.05

Roll_D: 0.05

This performance is very close to what was observed in the flight data logs which is very reassuring that the model is a remarkably close approximation of the aircraft/autopilot system as a whole.

Updating/tuning the PID values based on this approximate model, resulted in the following improved simulated performance

The PID values in the above illustration are as follows and will be used for the next flight evolution.

Roll_P: 0.13

Roll_I: 0.02

Roll_D: 0.04

Note that the P gain was cut in half and the I and D were decreased slightly.  These are pretty low gains compared to most aircraft but this airframe has an absolutely INSANE roll rate and my intuition of cutting the gain in half was well in alignment with the model's prediction.  Hopefully we see verified results on the next test flight... until then...

Fly Safe Fly Fast

-Beall

Research by Ryan Beall and Chaz Henderson:

Background

I took part in a research endeavor to analyze many facets of guided/autonomous parachutes this last 3 months.  There are many technical problems that require solutions for this project to be successful and the following analysis presented below is the culmination of 3 months of research dedicated to airframe system identification and proof of closed loop autonomy.  This project was comprised of two teams working in parallel.  The other team worked on increasing the parachute deployment reliability as well as manual control of a parachute.  Because our team was responsible for solely creating a model from logged flight data and proving low-level autonomy, it was chosen to use a reliable fixed wing airframe instead of the parachutes to more effectively solve the system’s problems without potentially being hindered by airframe reliability.  Proving our methods of analyzing the system on the fixed wing aircraft can easily be modified to the parachute airframe once it comes online.

Equipment

1:  Pixhawk Autopilot

2:  3DR Ublox GPS and magnetometer unit

3:  3DR 900 Mhz wireless telemetry modem suit

4:  350mAh Lithium battery (2 cell)

5:  3 Amp / 5v Battery Eliminator circuit (Hobby King generic)

6:  3 x 5gram servos (Hobby King Generic)

7:  Dollar Tree Foam board (1 sheet per aircraft)

8:  Hot glue gun / hot glue sticks

9:  Custom 3D printed parts for release mechanism (described below)

10: Ultimaker 2 3D printer

11: Laser cutter

Setup

The first part of our project was to design the airframe.  A small wingspan was desired to fit below the Arcturus UAV to ensure minimum interference.  We also didn’t want the high glide ratio of a glider, because we were aiming for flight characteristics similar to that of a parachute.  The design chosen was a delta wing plan-form with a very low aspect ratio.  The flying wing architecture is easier to build, is compact, and uses the least amount of servos for stabilizing flight.  This design did not utilize a motor.  It may be familiar to some of you as a version of the Punjet found at:  

http://flitetest.com/articles/ft-pun-jet-build

The Fuselage was widened to accommodate the Pixhawk and tapered in the back.  The wingspan was also increased by the same thickness added as the fuselage.  The first step in designing the aircraft, was to design the fuselage such that it could carry the autopilot.  The physical dimensions of the Pixhawk autopilot were what dimensioned the fuselage.  Essentially the whole aircraft was designed around the autopilot.  The second design constraint was the release mechanism.  The aircraft had to be able to release itself from the Arcturus UAV with it own servo release mechanism.  The space required to house the release mechanism was a concern.  However, shaping the fuselage around the autopilot gave ample room for the release mechanism as well as the telemetry modem, gps and battery.

The plans illustrated below were generated in Inkscape (open source version of CorelDraw) from the modified flitetest pdf vectors.

These plans were plotted on paper to lay out the electronics and do one last test fit to ensure scaling and servo cutouts were correct.  The Inkscape final plans file was converted to a vector file (generic SVG in Inkscape) in order to be printed on a laser cutter.  The black lines represent a cut that is all the way through the foam board, and the red lines represent a half score cut through the foam board.  The print settings for the laser cutter let you set the laser’s power and speed relative to the color.  Using scrap foam board, test cuts at different power levels and speeds were tested to get the desired performance per the respective color.  The final power/speed settings used for accurate cutting were as follows:

Black: Speed=20%, Power=100%

Red: Speed=20%, Power=55%

It was also found that using the flattest foam board possible ensured the most accurate cuts.  It was also very important to run the auto-focusing procedure for the laser every time cut was performed.

The aircraft was assembled using hot glue and box tape in typical flitetest.com fashion (build video).

The next part of the design process was to design the release mechanism.  The release mechanism comprises to two primary parts:  the base plate designed to spread the launch forces across the bottom of the aircraft and the hook capture device designed to capture the wire.  These two parts were drawn in 3D CAD (Solid Works) and then printed on an Ultimaker 2 3D printer.  These results can be seen below:

The base plate was glued to the bottom of the aircraft and the hook was attached to a pushrod connected to a servo.  The release interface was then tested and the servo was trimmed to minimum and maximum travel positions to prevent binding.

The Pixhawk was configured with the ‘plane’ software and stock PID settings were used for the initial flight.  The elevon settings, correct command orientation, as well as PID attitude feedback were all verified as correct.  The servos were reversed on the ground station until the correct behaviors were observed.  Channel 7 was used for servo pass through to actuate the release hook servo.

The transmitter mode switch was capable of selecting 3 flight modes on the autopilot.  These three flight modes were chosen in a progressive nature to ensure safe flight through the multi-flight test flight process.  For example, the first flight was setup with the following: 1: manual, 2: Auto tune, 3: Fly By Wire A.  This was to ensure that if the attitude PID gains were too high, the flight mode could be selected for manual control.  Return to launch and/or orbit was not selected for any of the 3 modes for the first flight because the underlying attitude controllers needed to be proven.  

On the first flight, it was intended to utilize the auto-tune algorithm for attitude control to further refine the PIDs.  The attitude PIDs recorded from the first short flight were not that much different from the stock PIDs.  The primary influencing gain of focus for these first flights were the proportional gains.  The stock value for these gains was 0.4 ( a fairly conservative value).  The short flight time only enabled the P_roll to increase to 0.43.

The aircraft was tested for release and physical interference with the Arcturus UAV.  The release mechanism successfully released multiple times on the ground and did not interfere with the Arcturus UAV.  All subsequent flights all had 100% successful drops.

 Drop/Flight results to follow in Next post!

Written by Ryan Beall and Chaz Henderson:

Data/Analysis

The flight data was logged on the micro sd card which was plugged into the front of the Pixhawk autopilot.  The Pixhawk is capable of logging various levels of data, but because the sd card used was 4gb, the default (all data logged) was chosen.  It was also set in the logging settings to only log when the autopilot is ‘armed.’  Only logging when armed helps cut down on useless data. 

The log .bin files can be pulled wirelessly through the ground station or pulled directly off the sd card using a sd card reader.  We used an sd card reader because it is drastically faster.  These files were then converted to .mat files using APM Planner.  These .mat files were then individually loaded into matlab for data shaping and analysis.

Data Shaping:

The Data was shaped using two triggers.  The first trigger was the channel 7 servo command to release from Arcturus.  The second trigger is the spike in acceleration sensed when the aircraft impacts the ground.  

Flight Path Analysis:

The matlab script was also used to illustrate the flight path and basic attitude hold performance.  Some of these example results can be seen below: 

The above is a great illustration of the expected glide performance of this aircraft at its current wing loading.  Above you can see that the mean sink rate is 995 ft/min, which equated to a mean glide ratio of 2.37:1.

Attitude Hold Analysis:

The below is a segment of the roll attitude hold performance during the orbit over the airfield.  The error tracking performance could be greatly improved with more tuning flights.  A comparison to the gains achieved using the auto tuning algorithm (used on this flight) versus the predicted gains from the model derived at the end of this paper will be an interesting follow on study.

It is clear that the roll attitude hold PID loop is working, but it is evident that with large perturbations in roll attitude, that the PIDs are underperforming and has room for tuning/improvement.

Results and Conclusions

The main focus of this study was to ultimately create a flight dynamics models from recorded flight data.  The flight profile analysis above demonstrated that our autonomous flight profile would be adequate for use in estimating this flight model using system identification tools.  As this was a proof of concept and the short amount of time between our range date and deliverable due date, only the roll axis was chosen first for system identification.  A full aircraft model will be developed next quarter.

The roll rate response versus the roll command was analyzed using a SISO matlab method.  The determined model for roll was the following:

The roll rate of this aircraft is "extreme"!  The dual rates and exponential have to be heavily utilized to manually fly this aircraft safely.  This fast response is also manifested in the model above.

The roll command pwm recorded from the flight was put back into the above model and compared to the actual roll rate achieved by the aircraft and can be seen below:

As seen above, the model mapped to reality really well.  There is some noise due to natural unstable air disturbances, but the overall performance of this model is respectable.  More tuning of the PIDs and test flights profiles specifically written for System Identification should help present a more robust model.  We recommend that the follow on study consist of more PID tuning with a more methodical input/output study using frequency sweeps on inputs to help get a more complete model.  It should be noted that this was achieved in three months spread over 6 two-minute flights during a one-day range evolution.  Producing this low fidelity model with this limited amount of time and data was a difficult accomplishment.  But with more time/flights in the following quarter, significant strides on this project are anticipated.

Drop Analysis:

 The following are matlab generated Google earth profiles of the recorded telemetry.  It should be noted that the under side of the wings are blue and the top side of the wings are red in the following illustrations.

Overall this was a successful quick example of how an aircraft can be cheaply prototyped quickly and how one could do a system identification of an airframe with the data provided from log files.  This project will probably evolve into an auto-tuning solution for PIDs of sorts but we will see what the next 3 months produces.

Fly Safe, Fly Fast

-Beall

I have been working on an improved altitude estimator for a while here but have been having issues with implementation.

The theory works fine but as seen above in the FFT of the accelerometer data, there is a significant ammount of vibration/noise in the sub 50Hz range.  This is due to out of balance props etc.  Needless to say, this proves to be very detrimental to estimating altitude and velocity changes when these vibrations are an order of magnitude greater than the actual accelerations felt by climbing and descending.  You cant really low pass filter or band pass filter this because you need everything below 60 Hz or so. 

So here is what I need from you guys:

Flight data that includes the following:

• dt in ms between samples
• phi,theta,psi
• barometric altitude
• sonar altitude (if available)
• ax,ay,az

make sure you notate units etc.  The more information on the data the better.  Thanks for the help and I will post the results.  I'm really hoping to get some data from guys with slick clean vibe free quads. 

Thanks

Beall

The barometric sensor alone in most cases provides noisy and drift prone measurements. I have been trying to come up with a simple way to implement a fixed gain filter to utilize the acceleration measurements from the accelerometers to help clean up the noise and also add a sanity check via sensor fusion.

The cool part about the filter is that it also estimates vertical velocity which is useful for altitude damping and control. The basic idea behind the filter is the Z or vertical component of the acceleration is derived using the body rotations to compare with the barometric measurement. The noise of the barometric sensor is rejected whenever the accelerometers disagree. The down side to this approach is it depends upon the accelerometers being less noisy than barometric sensor and also not being on a vibration intensive vehicle. The theory works but actual implementation is somewhat hardware dependant.

The real plus to this filter is the velocity estimate can be used for altitude damping and control. Instead of taking the derivative of the barometric sensor which is going to significantly increase the noise in the derivative term, you get a much cleaner vehicle state estimate with this approach.

The code is fairly simple but may require tuning based on units and hardware. I took the fixed gain approach to keep it simple and as a result looks like the following:

The thing to note here is these are all relative to the NED reference frame (ie: acc_z is not the body z acceleration it is the NED z acceleration)

Enjoy-

-Beall

I posted this earlier but did some tweaking on it to compare the Extended Kalman to my Fixed Gain Observer filters. I haven’t finished the FGO position filter but am really starting to lean more on EKF because the performance really is significantly better.

The idea for this filter is to fill in the gaps of the GPS position between the 1-4 Hz range for something like a quadrotor or just overall improved lag free navigation. You can clearly see how the fusion of more sensors can really increase your UAV's perception of reality!

**Edit, I improperly emulated GPS in the first pic so I added the correct pic. This shows how GPS comes in at 2Hz with noise and using a little logic and deadreckoning you can not only fill in the gaps but be more accurate than GPS is actually reporting. The GPS acts kinda like the accelerometers in the DCM algorithm, they keep the solution constrained.

Enjoy!

-Beall

https://www.youtube.com/watch?v=cipTQAUM-v4

Note** these are 100meter orbits with really strong winds to provide a setting for this test. Hence the reason why the autopilot has a hard time holding a perfect circle. However the improved algorithm is holding so much better in the high wind scenario than the original algorithm!

This is an example of how to eliminate the oscillation in ground track using a heading error>bank angle type proportional controller. The groundspeed of the vehicle determines its turn rate for a given bank angle. Typically you tune the PID (only P is needed) for a given trim airspeed and assume that the ground speed is fairly constant and something close to the airspeed. However when there is high winds, this isn't the case. The ground speed can change +-50% in some cases in and out of phase with the wind if not more.

This causes oscillations on the "upwind" side because the turn rate is so much higher. To take this nonlinearity out of the system, I added the turn rate equation into the mix and solved this problem. The largest contributor to this problem is the GPS lag. So using this turn rate equation in the middle, it makes the controller more predictable with the changing ground speed.

I made an attempt at a video so hopefully it will better explain what is going on here. Especially beings a lot of people are having this problem!

-Beall

I wrote down a napkin sketch of an altitude filter a while back and finally got around to testing it in the simulator. I designed it to improve the sensed altitude of the ardupilot. It is based on a fixed gain observer model and shows very promising results. The idea is to use the "lagless" airspeed sensor to give you a less noisy lagless altitude estimate. Enjoy!

K_alt = -0.01;
avg_aoa = 0.52*(pi/180); //alpha = 0.52 deg on the average
gamma = theta - avg_aoa;

alt_est = alt_est + Vair*sin(gamma)*dt;
alt_error = alt_est - GPS_alt;

alt_est += K_alt*alt_error;

Wrote up a wind estimator today. It is based off of a simple model which requires very little inputs from sensors.

psi - true heading (not course over ground)

theta - pitch

airspeed

GPS lat and long

It is a simple model. The wind model has no dynamics which helps simplify the solution. This asusmption is mostly true beings the wind direction and velocity doesn't change all that much for a given flight. The filter starts off by assuming the soltion is a zero wind scenario and then moves towards reality. It takes about 2-3 seconds to converge.

The non-linear state update equations are as follows:

Pn_dot = Vair*cos(psi)*cos(theta) - Wn

Pe_dot = Vair*sin(psi)*cos(theta) - We

Wn_dot = 0

We_dot = 0

Notice the filter resolves on a wind velocity of 15 ft/s and 090 deg heading.

Pretty slick how quickly it finds a solution.