(If it was me, I’d click on the “watch on youtube” icon in the lower right corner and select 480p and go full screen — but that’s just me.)
Flying a continuous tight circle pattern around a fixed ground reference point is about the closest thing we can get to parking an airplane in flight. It isn’t too hard to do a lazy orbit around the point, but we want to keep the radius fixed, even if there is a wind. This means that as we fly around the perimeter of the circle we have to continually vary our bank angle and turn at different rates relative to the wind so that our ground track maintains a perfect circle of the desired radius.
Here are some things to look for in the movie:
I’ve turned up the turbulence to moderate levels so the small aircraft gets bounced around quite a bit. Still in the last shot you can see that the flight controller has maintained a pretty tight circle the whole time.
This is a 3d model of the new ATI Resolution 3 (a small marinized UAS.) Stay tuned for more details if you are interested in that sort of thing.
FlightGear offers a variety of interesting view points and visualization tools, including smoke and trajectory markers, HUD overlay, animated control surfaces, realistic environments, wind and turbulence.
If you look carefully, you can see how the smoke drifts relative to the red/blue trajectory markers.
This is all part of a demo package I am putting together that shows things like autonomous-takeoff and landings, a gyro stabilized camera simulation, circle holds around a point, route following, a cool new UAS airframe under development — all mixed in with FlightGear’s wonderful prototyping and visualization features.
In previous posts I’ve described the process of carefully modelling the basic geometry and mass properties of a UAS in YASim to provide a real time flight dynamics simulation of the aircraft in FlightGear. I also described how we carefully modelled the blended body shape of our UAS using airfoil plots and spline curves. These curves were then imported into MoI and used as the basis to generate a smooth, flowing, organic surface shape. MoI is able to export the model as a 3d triangle mesh in a variety of formats including 3ds.
FlightGear can directly import 3ds models and render them in the simulator. However, I found that my model needed be cleaned up in several respects. All of this discussion relates to Blender – a very capable open-source 3d modeling tool. This isn’t intended to be a blender tutorial, but a brief overview of the steps involved in preparing a model for use within FlightGear
Surface smoothing: If you click on the above thumbnail you will see that the basic model imported from MoI is “faceted” or in other words, the triangle surfaces are flat and you don’t see the intended smooth curved surface. One of the first steps required is to select each “Object” and select “Set Smooth” in the “Buttons Window”. Repeat for each object in the model.
Inside-out surfaces: I decided for simplicity, I would export the model in the .ac3d format (a text based format) for final use in FlightGear. When I did the export I discovered many of the surfaces where inside out — the face normals were pointing in rather than out. This causes the surface to be displayed inside out and shaded wrong in FlightGear. So the next step required is to turn on the display of face normals, select each object individual (right mouse click), enter “Edit Mode” <tab> key, and flip the face normals if needed.
Orientation: FlightGear allows you to add an xml wrapper around your model to adjust the orientation of your model (flip it by 90 degrees for example) in case the model was developed for a different coordinate frame layout. However, since I was doing all the prep work anyway, I rotated the heading of my model by 90 degrees in blender so I didn’t need any extra transforms when drawing the model inside FlightGear.
Scaling: For convenience and due to the scale of this design, all the original work was done in inches. This transfered to the MoI model and thus to the blender and flightgear models as well. However, FlightGear requires units of meters so the model was grossly oversized when imported into the simulator. Blender has a scale function, so I selected the entire model and scaled it by a factor of 0.0254 to convert from inches to meters.
Control Surfaces: this aircraft is a flying wing and has as very simple control system. Each wing has a strip elevon that runs the length of the wing. Aileron and elevator inputs are mixed (summed) to produce the actual control surface deflection. In the real UAV, this mixing is accomplished in the flight control software. On an RC airplane this mixing would be done inside the pilot’s transmitter on the ground. In FlightGear, the mixing is done through the YAsim xml config file. Blender has a cut function accessed by typing “Shift-K”. I went into top view mode, drew lines for the control surface cuts and cut the mesh to create the elevons.
Textures and Painting and UV Unwrapping
This could be the subject of a book just by itself, but let me give a really quick summary.
Blender has a cool feature called “UV Unwrap” which is found in the “Mesh” menu when you are in “Edit Mode”. There are several unwrap options, but I found “Unwrap (Smart mode)” worked the best for my purposes. The following image shows how blender unwraps the mesh (in this case the wings and elevons.) In the bottom panel I selected “UV/Image Editor” and it shows the unwrapped mesh image.
Now here’s the cool thing. You can save this image out to a file and then import it back in. Blender will use the imported image to texture the file exactly as it has been unwrapped. So with this template image you would see a model that looks like a wireframe. I then loaded up the images in blender and labeled each panel with a big number. Inside FlightGear (or osgviewer) I could then identify which number corresponded to which panel (top left, bottom right, etc.) I further edited the template file to include this extra information. The result when drawn in FlightGear looks like this:
Now I have my “paint kit”. I can load up the templates in gimp (or photoshop), create a new layer, and draw my color schemes and markings over the top. For the wing panels, I did a quick hack of a coast guard-ish color scheme which looks like this:
I then export just the marking/paint layer back out to my texture files that the model references and the “finished” result looks like this:
This is still a work in progress. I have yet to animate the control surfaces. I also need to add a spinning propeller. The paint scheme is just a quick example and could use many many improvements.
With the paint kit established, a variety of paint schemes can be developed. Here are two more examples:
Official ATI scheme:
A gray camouflage scheme:
There are many steps required to model a new aircraft design in FlightGear. Primarily this involves creating a flight dynamics (physics) model and a 3d model of the design. Each step requires several sub-steps and there is always room for improvements and refinements. This is an example of an R/C scale UAV. Full scale aircraft are much more complicated involve detailed cockpits, many more animations, much more complicated 3d meshes, and much more work texturing and painting. Hopefully I have provided a taste of what’s involved. With a little effort any one can jump in and learn the tools to build simulated aircraft. But it does take time and patience.
Finally, here is a (sorry, kind of crude) youtube video showing the model flying inside FlightGear:
MoI (Moment of Inspiration) is a really interesting 3d modelling tool. There are two things that separate it from other tools in my view.
1. It has a very simple and intuitive interface.
2. It has powerful and intuitive primatives for drawing and manipulating curves and 3d surfaces. For example MoI allows you to define 2d (or even 3d) curves and then stretch a 3d curved surface between your curved lines–possibly with additional guide curves to control the shape. Like with any tool, it takes a little thought, practice, and planning to break down the structure and represent it using primatives, but MoI allows you to quickly create and edit some very complex and almost “organic” shapes.
You may refer to my previous post related to modeling with perl. I used a perl script (math + airfoil data + spline curves) to carefully define exact lengthwise slices along the fuselage. I then imported these curves into MoI and stretched a “network” surface over them. It’s about a 10 minute job in MoI and I have a beautifully smooth curved fuselage.
I adjusted my perl script to also generate the exact airfoil profile at the wingtip and imported that curve in the correct 3d location. This allowed me to quickly built an entire wing using the “sweep” function. I then added a motor tube (which is just an extruded circle to make a cylinder.)
I used a similar approach to create a nice curvy winglet. from the picture you can see I designed two different styles of winglets. I think I like the looks of the drooping winglets better. I don’t know yet what we’ll end up with on the real aircraft. We’ll probably design the wing tip so we can mount any winglet design that we’d like. You can also see in the background that I was playing around with designing a shaped vertical stab. These will mount inboard and be the primary yaw stabilizer. It took me no more than 10 minutes to create each winglet shape in MoI.
The ultimate goal is to create an accurate 3d mesh of the aircraft. This will be combined with the dynamics model to produce a realistic and visually compelling real time simulation of the design in FlightGear. MoI has several mesh export options and allows you to tune the mesh density so it is a perfect front end design tool for really nice 3d models.
MoI is a really awesome 3d design tool. I can’t speak highly enough about it. I am merely a novice at 3d modeling, you can browse the MoI forum and find many incredibly brilliant designs that the experts are creating. MoI is a commercial application, but if you are building “organic” shapes with curved surfaces, it is worth every penny.
Dynamics (Physics) Modelling and Flight Simulation
There are many great tools available to help engineers design and develop new aircraft and flight control systems. One such tool is the flight simulator. More specifically: an open source flight simulation such as FlightGear. Being open-source FlightGear is flexible and adaptable and can be used to solve or explore new scenarios that a proprietary software applications may never have anticipated.
FlightGear + YASim
Here I describe the process of modelling a flying wing in FlightGear using the built in “YASim” physics engine.
A brief word on yasim (wiki documentation): YASim is a physics engine that inputs a physical description of the airframe, the wing and tail surfaces, engines, landing gear, weight and balance, etc. In addition you input cruise performance numbers and approach performance numbers. YASim has a built in solver that computes approximate lift/drag curves for your model and then physically models the individual components in real time to produce the overall dynamic behavior of the vehicle.
For this example we are modelling a flying wing. To do this in yasim, I defined the inboard 3/4 of the flying wing as the main wings, and the outboard 1/4″ of the flying wing as the tail. Yasim allows you to define any number of surfaces in any arrangement, but this approach works out pretty well.
Notice that yasim “mirrors” the wing and hstab automatically so you only define one side in the configuration file. Visualizing your yasim configuration can be very helpful and can help eliminate math mistakes and typos. Here is a link to a Blender YASim import plugin. The image above shows the result of importing the flying wing configuration into blender.
Once the basic model has been crafted, it can be flown inside FlightGear. If you have provided correct geometry, correct weight and balance information, correct propulsion information, and correct cruise and approach performance values, YASim will create a model that flies very much like the real thing. However, YASim makes many internal assumptions and isn’t perfect, and most of the time we don’t have perfect data for our aircraft. So once the initial model is created it is worth flight testing and adjusting various parameters to tune the model towards real world performance.
For instance, control surface effectiveness can be tuned to get the correct rotational rates. Engine power can be tuned to get the correct rate of climb. Because YASim is designed around a solver that computes lift and drag for your design, if you increase the power of your engine, yasim will reduce lift and increase drag so that your specified cruise speed will still be met. Essentially this gives you an aircraft that is draggier but has better climb performance. In my case, our wing has an incredibly efficient glide ratio, so I ended up reducing power substantially from my initial guess. This created a wing with much less drag and much more lift. Climb performance was reduced, acceleration is slowed, but now it will glide forever just like in real life.
Because YASim uses the physical geometry of the design to compute forces and moments at each surface and then sums all of these up to produce the overall flight dynamics of the aircraft, it is possible to make changes to the airframe in simulation and observe the effects in the simulator. For instance, the flying wing design in this example has twin vertical stabilizers. If I want to test the effect on lateral (yaw) stability of moving these surfaces fore or aft, I can do that in YASim. A quick tweak to the config file is all that it takes to adjust the location of a surface. I leveraged the FlightGear autopilot + a simple nasal script to fly a scripted flight pattern. Basically I stabilize in straight and level flight. Then I input 1 second of full right aileron deflection, followed by 2 seconds of full left aileron deflection, followed by leveling the wings. Through this maneuver I plot the “side slip” angle (beta). This gives me an indication how straight the aircraft tracks through the maneuver with different vertical stab locations.
In the above graph the line number (0.48, 0.58, etc.) corresponds to the distance of the vstab behind the nose in meters (this design has a wing span of about 2.3m.) As you can see the further rearward the vstabs are placed, the more stable the design becomes (the straighter it tracks and the more quickly it recovers.) You may also see that as the vstabs are pushed towards the CG (about 0.37m behind the nose) the stability starts to diverge rapidly. But as the vstabs are pushed back to about 0.68m behind the nose, the stability increases, but we are starting to hit diminishing returns. According to yasim, we could push the vstab further back and get more stability, but perhaps not a lot more.
Other Uses for Simulation Modelling
Besides basic flight dynamics modelling and validation, a simulator can be very useful in many other areas of aircraft development. Flight control systems can be prototyped and tested. Higher level flight control systems (route following, circle holds, autonomous landings, etc.) can be effectively prototyped and developed within a simulator. Even payload systems can be modeled and prototyped inside a simulator. Any work that can be done at an engineer’s desk in the comfort of their office will be far more productive than in the field under harsh conditions when the pressure is on. And when something developed in simulation works exactly right in the real world on the first try it is just very very cool!
This is just a simple example, but it shows some of the power that a flight simulator can bring to the arena of aircraft design. Simulators are never perfect so you have to keep in mind how far you can push them and what data you can trust to pull out of them. As a design evolves and as you gain real world flight experience with the actual design, you can validate the simulator against real flight data and adjust and improve the simulation model. This design cycle leads to a positive feedback loop which creates a more and more realistic simulation model that yields more and more useful simulation results.
Are you insane? Yes, but in a nice sort of way (I hope!) 🙂
Since I’ve already admitted to being insane, you won’t mind if I explain the back story that let up to my evil plot. I work with a small high tech company (ATI out of Wasilla Alaska … and yes if you were wondering, but no I haven’t met her myself.) Some of the things we do is develop a variety of UAS related technologies. One project involves developing a marinized (water proof) UAS that can be launched from a small vessel and recovered in the water and generally operated with minimal infrastructure.
One of the guys on the project has wonderful artist talent and he hand carved the center section of our blended body flying wing design. It really looks sweet once it’s all together and in the air, but here is a close up of just the center section.
Well one thing leads to another and we decided we wanted to draw this up on the computer so we could cut molds, visualize and test design changes, etc.
But how the heck do you draw something like this. The only straight edges on it is where the wings plug in. The rest of it is totally free form and all blendy and curvy. I don’t see any cubes or spheres or cones jumping out at me. You are probably thinking of a few obvious approaches … make a mold from the prototype, laser scan it, etc. and sure those work for what they do, but they have draw backs … and we want the entire design on the computer and in a way we can play with it virtually.
As I started staring at the design and trying to analyze it’s structure and look at the outlines it occurred to me that the 3-view edges could be modeled pretty nicely with spline curves. I thought that if I could represent the outlines correctly, then I could create slices and march down the length (or width) sizing and blending my slices based on the 3-view outlines. At the end if I could only find a way to stitch the slices together, I would have a 3d model. That was the insane plan!
Here is a very simple spline curve. I could have used as many intermediate points as I wanted, but here I just have a start point, an end point, and one intermediate point. The curve will pass through all three points. In addition I can “clamp” the slope at each end. The following is a plot of a sample spline curve. With just a simple system like this I was able to model all the curves on our fuselage!
The following plot shows the right half of the fuselage from a top view (the front is to the left in this plot.) The leading edge is modeled with one curve, the straight edge at the top is where the wing plugs in, and the trailing edge is modeled with it’s own curve. Simple, and it’s already starting to look like something!
I don’t have a picture, but I did something very similar for the front view … one lazy curve from the top of the wing to the center, and a more aggressive curve from the bottom of the wing sloping quickly down and then flattening out along the bottom to maximize the volume inside.
Next I’ll walk you through the process of creating slices. One thing I haven’t mentioned yet is I have the outline of the wing’s airfoil as a set of coordinates normalized from 0.0 to 1.0. This way I can easily scale the airfoil to any size I want. The way the model is setup, the slice that butts up against the wing has to be an exact match to the airfoil, but as I step towards the center, I need the slices to more and more take on the side view shape.
So lets start simple. At each slice point I lookup up the leading and trailing edge positions from the top view curves. I use these points to simply size and scale the airfoil. I’m not worried about height or blending into the fuselage shape yet. When I plot out my different size airfoils they look like this … cool. But notice that the the leading edge of each airfoil size is horizontally the same as each other which doesn’t represent our model and makes the center of the shape much taller than at the wings.
The next step is to raise or lower each slice (and size it vertically) so that in addition to following the correct leading and trailing edge profiles, the slices also follow the correct top and bottom profiles. Here is what it looks like: Ignore the lines in the center, those are just an artifact of dumping all the slices into a single line plot. This is improving but there are still some things to notice. Obviously there is a problem at the trailing edge and also the thickest part of the airfoil is moving forward. We want the thickest part of the airfoil to stay in the same place as we move inboard with our slices.
In this next plot we divide the airfoil shape at it’s thickest point so we have a front and a back. As we march inwards (longer airfoils) we keep the center point fixed and streeeech out the front portion. (again ignore the horizontal line garbage.) The front of our model is starting to look really good! The trailing edge needs work.
In the next plot I simply align the trailing edge height of every slice to match the trailing edge of the wing. This cleans up the model even more and it’s really starting to look like something. However, we are still using the airfoil shape in the back half and we need to blend that into the center line shape so we have more volume in our center section.
The next plot shows the correct center section outline in the bottom rear (the top rear still needs work.) It’s hard to see from this plot but the bottom rear portion of the slices close to the wing match the wing airfoil shape and as we march inwards, they slowly blend into the correct fuselage shape. We need to do the same thing with the top rear of the slices.
The following plot is almost identical to the previous one except the top rear (left) has been curved outwards to make more internal volume. Again we match the airfoil shape near the wing and blend to the fuselage shape as we move inboard. This is the final plot. All our slices are looking really good!
The next task is to figure out how to stitch all the slices together to make a 3d surface mesh. Here are a couple technical details. I output the AC3D format because it’s a well supported (in the open-source world at least) and has an easy and well documented ascii format and structure. I won’t say too much about it. Basically I walk through each slice and create triangles that connect the points up with the neighbor slice. You can see the resulting structure from the following 3d pictures.
Because the model and the slices are all script generated, I can easily set how many slices to create and for each slice how many “chops” front to back I create. With a tap of the keyboard I can generate an incredibly finely detailed model to send to a CNC machine, or a more coarse model for real time visualization or simulation.
All the curves and dimensions are paramaterirzed, so if I want to change the length of the nose or the tail, adjust the overall depth, fiddle with the shape of the curves … it is all very easy and quick to do.
Here is the final 3d shape that is beautiful, sexy, and blendy and very closely matches the artist’s original hand carved prototype. (I just show the left half, because you know, mirroring the other side is just a bunch of busy work.)
Feel free to click on any of the plots or pictures in this post to get the full size version.
So there you go, a slick little 3d model generated by a perl script that lovingly captures the artists original concept and in a few areas goes a step further with curving and blending the shapes together.
This is a little proof of concept video I just put together. The goal is to always keep my aircraft’s shadow in the field of view.
Equipment: Senior Telemaster. Fly-Cam-One-3 with built in pan/tilt. Sparkfun 6DOFv4 IMU (it was laying around so I used it.) Gumstix flight computer. Ardupilot used for controlling pan/tilt servos on the camera.
The flight is 100% manually piloted. Camera is 100% automatically pointed.
On board I am running a 15-state kalman filter for attitude estimation. The filter converges to “true” yaw angle independent of ground track, wind, and magnetometer. This is actually critical for camera pointing.
On the ground I have small app I whipped together one evening that computes the sun location for the current time in ECEF coordinates. Then converts the sun “vector” to NED coordinates based on a GPS connected to the ground station (assuming I’m not ranging very far from my start point.) The code computes a new sun angle every minute. Finally, the sun vector is inverted to get a shadow vector and that is sent up to the aircraft as it’s target point vector (once a minute.)
Notice: sun vector * [ -1 -1 -1 ] = shadow vector.
Also: sun vector * [ 1 1 -1 ] = reflection vector (where we would be looking at the suns reflection off surface water.)
Also: sun vector * [ 1 1 1 ] = rainbow vector if we would happen to fly above the clouds (this would keep us looking at the center of a rainbow circle/arc.) 🙂
In order to run myself over with the shadow from the aircraft’s perspective I need to fly the airplane through the sun from the ground pilot’s perspective.
Disclaimers: this was my first time out trying something like this so the video is rough. The pan/tilt on the flycam is very low grade, but works well enough for a demo. I’m also flying with an IMU that is about 2 orders of magnitude coarser than I’m used to flying with, so that degrades my attitude estimation more than I would have liked (but the filter still converges.) I put very little effort into aligning the IMU mount with the camera mount, so there are certainly a few degrees of bias just from mounting issues. Finally, I only eyeballed the mapping between servo commands and pan/tilt angles so I’m in the ball park, but there are certainly errors there too. It’s a hack, but made for a fun afternoon. 🙂
I am changing acronyms starting with this post. Previously I was calling this an SAS for “Stability Augmentation System” but someone pointed out that this is technically more of a CAS for “Command Augmentation System”.
SAS implies a direct connection between pilot input and control surface deflection with some additional stability augmentation mixed in. CAS implies that a flight computer is translating pilot inputs into a “request” and the flight computer then tries to satisfy that request, but there is no immediate direct mapping between stick deflection and control surface deflection.
Just to review, the ATI “CAS” system internally tracks a target bank angle and a target pitch angle. The pilot is “flying” these target bank/pitch angles and the flight computer is doing it’s best to match up with the request. The pilot changes the target bank angle by deflecting the stick; the greater the stick deflection, the faster the target bank angle changes. This is similar for the target pitch angle. When the pilot centers the stick, the target bank or pitch angle is held steady.
If the pilot banks into a 15 degree turn (target bank angle) and centers the stick, then the flight computer will hold that 15 degree bank indefinitely or until the pilot deflects the stick again. Likewise with the target pitch angle, the pilot pulls the nose up or down with the stick, but when the stick is centered, the flight computer holds that pitch angle indefinitely (as best as is possible for the available throttle and airspeed and maximum control surface deflections.)
The system can limit that maximum bank and pitch angles to stay within “nice” limits. In addition, the system can limit that maximum control surface deflections to avoid abrupt and rapid attitude changes. Currently the system is rigged so that even if the pilot commands maximum pitch up angle (+15 degrees) and pulls the throttle to idle, there is not enough allowed elevator authority to stall the aircraft. This makes the aircraft very safe to fly and very predictable.
Here is some real world flight video from the same flights shown in the first video. The CAS system is active for all but the initial take off in both of these videos. You can see in some situations the system is working quite well, in some situations the flight computer cannot completely compensate for the natural airframe dynamics and environment effects (turbulence, etc.) and in a few situations additional tuning will be required:
1. We added some additional logic to slowly roll the wings to perfect level if the pilot puts the bank angle within +/- 10 degrees of level. It’s really hard to get it exact from a ground perspective, so the idea is to let the pilot get in the ball park and the system will take over and finish the job. Auto-leveling will only kick in after the pilot centers the stick so it doesn’t fight the pilot if the pilot is intending to bank the aircraft.
2. To mimic more natural flight behavior we automatically pitch the nose up by a few degrees when the pilot adds throttle and pitch the nose down by a few degrees when the pilot pulls the throttle back. This is much more “intuitive” for a pilot and makes the system more predictable and easy to fly.
This was unfortunately another windy day, and the telemaster is a self stable, “trainer” style airframe and thus roll and yaw are very coupled and the aircraft’s natural flight dynamics react quite a bit to even small wind gusts. This means the SAS isn’t shown yet in it’s best light. I guess I’ll keep apologizing for the weather and at some point move to a more stable airframe, or try to find nicer days to fly.
I will say one thing. Even when the aircraft is bobbing around on final approach in the turbulence, it’s nice to be able to fly hands off the aileron stick and trust the SAS system to immediately return the wings to level, even when we get knocked 10, 20, or even 30 degrees off kilter. I’m still fiddling and improving and I’m not totally in love with the system yet. But it’s good enough already that I miss it when I turn it off.
ATI has been developing a number of flight control system building blocks and we have been testing them on my Senior Telemeaster airframe. This week I decided to connect them up to create a simple SAS (stability augmentation system.)
Briefly, when flying with an SAS, the pilot is still 100% in manual control over the airplane, however we have inserted a flight computer in between the pilot control inputs and the control surface actuators. Rather than the pilot’s stick commands directly moving the control surfaces, the pilot stick commands are translated to roll and pitch “rate” requests. The flight computer keeps track of the target pitch and roll angles and adjusts these according to the pilot’s stick inputs. The more the pilot deflects the control stick, the faster the aircraft rolls or pitches in that direction. When the pilot centers the stick, the flight computer holds the current bank and pitch angles, even if there are throttle or speed changes, gusts and turbulence, etc.
Here is a video of my very first SAS test flight:
The first flight test went pretty much according to script. The basic mechanics of the SAS worked as planned and produced reasonably stable and smooth flight. Transition between direct manual control and SAS flight was smooth. After the flight I adjusted two things. First, my gains were set way too low. Even at full stick deflection, the system responded much too slow to be intuitive for an average pilot. Second, I had used an exponential control mapping. This means that near the stick centers, I have to move the sticks a lot to produce just a little bit of aircraft response, but as I near the extremes of the stick deflection range, the rates ramp up quickly and the aircraft responds at maximum (programmed) rates. Below are two plots that show the difference between linear and exponential input mapping.
I had a little fun on the first landing. I included it all in the video posted above. After a couple low slow approach passes followed by a go around, I figured I had enough confidence in the system to attempt a full landing. However, the combinations of gains being set way too low along with exponential input mapping meant my flare was way way way too slow and from the video you can’t even see any pitch up at all even though my stick was pulled all the way back. I hit so hard I sent the camera tumbling … sky / ground / sky / ground 🙂 Every thing was fine … I’ve had rougher landings once in a while even under pure direct manual control.
After this flight I tripled the gains and switched to linear input mapping and the result was something that is much more intuitive to fly and allowed me to do some nice landings on subsequent flights. The system still isn’t perfect and needs some more tuning and fiddling, but for the first day out in the field after a couple days of intensive coding, I am really happy with the results!
Here is some video from my last flight of the day:
One of the most challenging aspects of autopilot setup is tuning the gains for a particular airframe. When the gains are tuned poorly, the aircraft my oscillate excessively, it may lag way behind the target pitch angle or roll angle or velocity, it may never reach the target values. Poorly tuned gains could destroy an airframe in a worst case scenario, but often people just live with non-optimal gains that aren’t great but work well enough to get the aircraft around the sky. It’s hard to know what gains to tune and why and a person could play with the numbers all day and only manage to make things worse. It’s easy to spot a problem; often the aircraft will look like it is fighting itself even though it does make it’s way to where it should be, or it just may not do what you ask it to do.
Real World Experimentation
Today I did some test flying with one goal to improve the elevator / pitch gain. Previously my gains were set too low. The result was smooth pitch control, but the actual pitch lagged far behind the goal pitch and tended to oscillate slowly above and below the desired pitch angle. To fix this, I increased the proportional gain until the pitch became unstable, then reduced the gain by 50%. This doesn’t ensure optimal results, but works pretty well in practice.
Here is a short before and after movie
The first half of the movie shows a flight where the elevator gain has been increased until we have just crossed the threshold into an fast oscillating system. You will see it stabilizes from time to time, but any little gust or even a turn can excite the system and lead to oscillations. In the second half of the video the gains have been reduced by 1/2 and you can see the pitch is much more stable. One point to note is that both flights were flown in very windy/turbulent conditions. During the second flight I was seeing sustained winds at 20 kts, gusting to 25 kts. The aircraft was set to cruise at 28 kts for a portion of the flight and on one up wind leg, it just stopped in the sky. (28 kts = 32.2 mph)
Want to learn more?
If you are interested in more information on PID controllers and gain tuning, I wrote a tutorial several years ago explaining much of the basic theory that goes into a simple PID controller. I then discuss some specifics about the autopilot implementation used in the FlightGear flight simulator. This is interesting because my UAV autopilot uses the same basic FlightGear approach. In fact, it’s possible to develop an autopilot xml configuration file in the FightGear flight simulator, and then copy the config file over to the real UAV and run it with only a few small changes.
At the end of the tutorial I include several tips and strategies for tuning PID controllers.
My standard disclaimer is that my educational background is computer science; I do not present myself as a control theory expert; instead I’d just like to share what I have learned in a way that makes sense to me.