Ryan Beall's Posts (12)

Developer

3689676620?profile=original

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:

 3689677680?profile=original

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:

3689677647?profile=original

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

3689677693?profile=original This model was then implemented in Simulink to verify performance with PID values used during flight:

3689677727?profile=original

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

 3689677756?profile=original

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

 3689677806?profile=original

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

Read more…
Developer


3689676555?profile=original

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.

 3689676580?profile=original

 

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.

3689676605?profile=original

 

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:

3689676523?profile=original

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.

3689676461?profile=original

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.

3689676620?profile=original

 Drop/Flight results to follow in Next post!

3689676475?profile=original

Read more…
Developer

3689676661?profile=originalWritten 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: 

3689676646?profile=original

3689676677?profile=original

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.

3689676717?profile=original

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:

3689676738?profile=original

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:

3689676500?profile=original

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.

3689676661?profile=original

3689676753?profile=original

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

Read more…
Developer

Arducopter Flight data needed

3689386909?profile=originalI 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

 

Read more…
Developer

Improved Altitude Estimate

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

Read more…
Developer

Improved Wind/Position EKF

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

Read more…
Developer

Improved Heading Controller

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

Read more…
Developer

No Baro altitude filter for ArduPilot

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;

Read more…
Developer

Position & Wind Extended Kalman

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.

Read more…
Developer

Ateryx 2.0 - The happy medium

Here is something that might peak some intrest. I plan on selling my autopilot in the near future and would like to see if there is any intrest in my product.The autopilot world is hard to attract the hoby level audience because of the steep price jump in higher performance systems. The cheaper approach is to buy the DIY kits and depend upon the opensource code to carry you along. My product is a happy medium between the two.The foundation of the code that comes free with the purchase of the autopilot is capable of keeping the aircraft stable and holding airspeed and altitude. However, if you want to add more features you simply purchase the appropriate app for the job. For example I expect most people will want to purchase the cheap waypoint and track smoothing app. This may seem like overkill but it allows the user to purchase only the capability required to meet their mission thus keeping the price-point more flexible. Apps are listed belowSD memory card loggingWaypoint navigationAltitude terrain followingCamera triggeringWind estimationMagnetic headingCurrent sensor and loggingAutoLandingAutoTakeoffEtc.Ateryx2.0 = $1,000Apps = $800 - 100Ateryx 2.0 has hundreds of hours of flight tested proof in robustness so you spend less time setting things up and more time flying. Purchase what you want and nothing more. Feel free to contact me if you are intrested.ateryx.autopilot@gmail.comRyan Beall
Read more…
Developer

IMU nose Dive problem/solution

In Bill's recent pod cast he talked about how the imudevboard experienced a random nose dive or extreme over estimation in the pitch (theta) axis. His theory was that the noise due to engine/aircraft vibration was causing the gyros to give inaccurate readings. He said that he put the imu in foam and the problem went away. I don't know how repeatable his experience was or how many test vehicles this "technique" was run on, but I find it no coincidence that I experienced the exact same effect on my imu.Here is my theory:I did some quick number crunching on some equations and found that it totally makes sense that pitch would "depart reality" more-so than roll and very rapidly as both him and I have both observed.(edit)For a 30deg AOB turn at about 1.5g's total the attitude solution if improperly estimated would be off in roll a couple of deg and about 30deg in pitch causing this nose dive affect.(correction)For a 60deg AOB turn at 2G's the estimation in pitch was off by 10 deg if centripetal was incorrectly calculated. The error would be in the positive direction causing the stabilty loop to push the nose over causing the "imu nose dive problem"I was extremely surprised at how quickly pitch departed at very shallow angles of bank. So this lead me to suspect one thing beings my math modeled exactly what I was seeing in the air....centripetal. Here are the pitfalls I evaluated:Gps latencyGps bandwidthPropper velocity mapping into componentsSo I will discuss in orderLatency. GPS has it...big surprise well how much is it and how much can it affect the solution. Depending on the module I have read 10seconds to about 0.5. Well for my Ublox it was about 0.75 to 1.5 depending upon the rep rate selected and positional accuracy (number of sats). I plotted it out and you can see how poorly the centripetal was accounted for in my "car test run". It's ok but in its worst case scenario could be off as much as 13 deg....which is better than 45deg with no centripetal at all for the runs I did. However 13 off and 1.5 seconds late quickly would cause things to go southGPS bandwidth. Its at best 4Hz....need I say more. You are going to miss changes in speed quite a bit and loose a lot of accuracy. Also note the graph where GPS clearly is reporting the wrong speed at the wrong timeVelocity mapping: This is how you map the velocity into the actual body velocities. Most people assume that the speed reported from the GPS is always out of nose of the airplane. This is mostly true except for in climbs. It is safe to assume that the v velocity (out the wing) is zero but not the w (out the belly of the aircraft). The total of u and w are the SOG from GPS and you must break them up. I'm pretty sure the imudevboard code does this but if it doesn't this is another large source for mis calculation----------------------------------------------------All of these things together are issues that can clearly throw off one thing....Centripetal estimation which was why we determined there was a 30deg offset in our crappy estimation. So with that solved (use airspeed instead) the problem goes away. I have hours of flight time on my IMU both with and without GPS and the nonGPS filter has yet to diverge from reality under self stabilized flight. GPS filter on the other hand....it depended on the airplane the autopilot....amongst a lot of other random variables that never made sense like calendar day. Some days it was fine and others it wasn't on the same aircraft which leads me to my next topic.

<Noise/Vibration:Gyro drift is due to temperature. When I tried to follow the drift using an integrator in software we had issues. Same idea and same effects and just as random. Some days fine and some days not. The filter DCM or what have you is a very dynamic thing and if you try to model a temperature drift with an integrator (in my humble opinion) it will only work assuming that your other estimations are perfect. Else the other errors will map into your temp compensation.....which does happen no denying it. Its ok if your gyros don't move that much with temperature and you keep an eye on the integrator however its way too unpredictable of a problem to assume your error state is a fixed target....It simply isn't.I run a temperature comp on my gyros and get repeatable results every time. With my comp equations the end result is a gyro that will hold itself +- 5 deg for 5 min or so. There are a lot of other tricks here like circuit noise reduction and oversampling that can be done but this is huge if you want to keep your solution converged.As far as vibration.....If a gyro gave crap results because of vibration then it wouldn't be any use in a 6dof filter. Your accelerometers produce noise with vibration and hence the reason we use gyros. I just don't see any room for allowance of gyros to be noisy in vibration. Pick good gyros and temp comp them and so many problems dwindle away very quickly-----------------------------------------------------------------------------------------------------------------update: addressing the airspeed questionMy acceleration model

<Best Regards and good luck in the IMU world-Ryan
Read more…
Developer

Ateryx 2.3 has been in different levels of development over the past year or so but I finally got some motivation to clean up some code and pull it all together.Cloud layer has been at 800ft for the past three days so I have been weather canceled with my Navy schedule. Considering the UAV development is all low altitude stuff this was the perfect time to get some flights out on the autopilot. I got all of the gains tuned and let the navigation code go to work. The only bad part about the time off is that it has been really windy (25 knots gusting at times) that and I'm missing the T-34. Navigation code could be tuned tighter on the gains but even with the windspeed being 75% - 85% of the trim airspeed commanded, it still maintained its flight path in my small local park!I will have video up soon as well as data (if I can get my new sd card drive to work).Here is the platform I am using as a test bed:http://www.horizonhobby.com/Products/Default.aspx?ProdID=EFL2825

Read more…