Smoking Ace Update

We are still alive. Just working on some other projects at the moment.

The Smoking Aces are still under construction. After flying the planes for hours on simulators and finally the real thing, we realized that you can't cheat physics. It makes for some interesting behaviors in short-coupled tail designs. What is kind of cool is that deeply-swept wings actually set the maximum angle of attack for the aircraft. We surmise that it is due to over-wing airflow. As the aircraft pitches, the airflow over the wing obscures the clean flow over the tail and finally completely blocks the flow.

Not so much block, but the distance between the tail and the wing is shorter than the mean turbulence. So the dirty air is not laminar enough to make a well-circulating flow around the tail. As the tail loses laminar flow and finally gets only turbulent flow it loses lift and finally stalls. This reduces the effectiveness of the tail and the plane rotates back to balance the tail input. This seems reasonable enough an explanation to the pitch wobbles, that are only partially-tamed by gyro input.

The first time we saw this behavior, it was exciting. Our pilot certainly thought so.

There is even a slight regression in our projects. Not so much as a negative thing, but more an artistic reawakening. I have to finish working up some drawings so we can discuss some design requirement changes. Building the Smoking Aces, we discovered that what we thought was a lot of space, was not. We also found out that 1000 in*lbs is a tough thing to take out in such a small space. Considering each wing applies this, we found some strange deflections in the air frame when the wings support large flight loads. These were certainly not unexpected, but we did not realize that our load paths were not as well controlled as we though.

Looking back through some old documentation, I found some of our original "Fat Man" designs. What we learned with the "Fat Man" was that fuselage depth or in its case root thickness was our friend. If you have healthy wing roots, there is a lot more space to manage payloads. More so, there is a trade off with larger thickness designs. The trade-off that is important is that often their curvatures do not change much.

When you build metallic structures, you see the need for structural caps. Without them, it is hard to fix skin to the structure without some heroic measures for the most part. Next time I will talk about some of the things that did not work for us.

UGV Autopilot Revisited

We have been working on lots of projects lately, mostly about the UAVs again. Only two hands and all, the last parking lot test that we ran were successful in clear areas. If you just wanted a clear circuit, our simple guidance system was good about being repeatable around 20mph. However, we want to get more in the low end in this, so that we can handle cornering better. The avoidance model is where we are looking for some help.

We are trying to get a working optical flow system to work at these speeds. You can get a working system at low frame rates, but we will need to increase our computing capacity to get it to work successfully at these speeds. Our issue we think, is in the matrix inversions. The determinant terms are making too many things blow up by divisions of small numbers. 

We are looking for anyone with experience getting an effective Kalman filter to work on Android. We have a few older phones, bhat we think would be a good platform for doing 2d control. Yes, I am mixing discussions a bit. If we can better estimate the net acceleration, it would help debug our optical flow system. We are having to bracket our responses so that the AI does not jerk the wheel. This seems to be an  issue. If optical flow can be used to manage the jerk, I think that we can even have moving obstacles in the scene and still reacquire the path with no issue.

It seems to be that the vectors estimated with Kalman divides by zero and runs a huge acceleration and that ruins the math for several iterations. Then the ringing dies out and the system cam go on, by that time we are either running for the hills because a dog liked the truck or because something blew across the scene. I have to find the math error. 

Contour 1080p HD helmet cam

So far so good with the helmet cam. We have been playing with its high frequency stabilization technology. This is pretty effective at taking the jelly and jam out of the motor shakes. Which is a good sign, it is effective at taking out suspension bob when riding a bike, but low frequency motion it can only do so much with. If you move the camera 3" it can't take the shake out of that. You would not really expect it to.

At night, or in low-light conditions it gives a pretty good picture until it is hard to see. Once you break that threshold it is too dim as well. It does have a pretty good sensor, it can pick up even small changes in brightness well and does well with edges.

At the moment, I have yet to get virtual dub to open a quicktime movie. None of the plugins that have been found work. Although I am loathe to say it, it may be better to just go the Quicktime Pro route. Legendary fail of customer support is always a reason why Mr. Jobs' overpriced fanboi kit rarely graces my workspace. It may be a necessary evil this time. Especially, if it can automatically export all of the movie's frames in one drop.

I am not done testing the camera, but so far I recommend it. For the money, it is very usable, rugged and has a functional output that is good for tv viewing. Reliving past exploits are always a great way to kill  time while you lie to yourself about  how good you were.

Can't Get It Up?

Hey it happens to everyone...

No little blue pills, but a rainy afternoon is keeping us from seeing how the wings sit in the mount. There is a bit of concern that the lovely tolerance that made the spars so easy to insert, is making life hard for other reasons. It will not be an issue. As long as the system is stiff once it is bolted together. There is some concern that the foam may crush under side-load. That could be fixed but I do not see a good solution that will work.

The fix if necessary is a wing root cap. That is probably a good idea under most circumstances. However, what could it hold to? The thing that was great about the design was that it had little in the way of internal structure, it is foam after all. That may be limiting the usable weight in the end because you cannot make strong mounts between primary parts.

We will see. At the moment I cam going to see if 0.060" piece of Aluminum sheet will tip the system in the right direction. It may need more like 0.090"  to correct the wing tip height. I can't see that until it stops raining enough to take it outside and measure it. Ten foot wingspan makes it problematic to measure in the house. Oh yeah, it is being built in a 900ft^2 apartment that I live in at the same time. It is a good drill for the initial facilities that I will have in CZ. I will dream of the day of such a large place.

More to come...

More Practical Composites

After several weeks of analysis, I came to the conclusion that using a glass or carbon fiber reinforced balsa composite is one of the best ways for us to get the weight out. Our other attempts were plagued with uneven resin densities. We have good luck matching allowables for 2-4 layer lay ups, beyond 5-6 layers we start to diverge pretty badly.

The best results that we have seen is with 60min epoxy and making sure that each layer is well wrung out before it is let cure at normal room temperature, 77F. As the humidity goes over 80% the pots react differently. The biggest issue for the divergence we think is the number of pots of epoxy used. Something happens with the weight and density between the pots.

Make sure that when your layups are done that you have at least a 2-3 layer pot. If you need a much thicker lay up, I would make sure that you make enough for everything. Also it is an issue with the humidity in the room. Do not add alcohol to the resin when you mix in the hardener. If the mixture is missed, it will just ruin the pot. At worst, it will react exothermically and create large amounts of bubbles both make a mess of the part.

So Much For our Idea

We were thinking that we could roll our Schoolgirl UAVs with some great NEU 1915/1.5Y motors to swing our huge props in a dual-motor configuration. I am sure it would work, but I think we will put it into a pusher configuration.

We kind of knew that the motors were big. I got a pair of these 2.7kW beasts from the guys down at Esprit Model in Palm Bay,FL. They are another great supplier of rc stuff. Esprit Model is good about not advertising that they have hard to find stuff and then them being out of stock. Better to know, than to get an email two weeks later saying that they cleared your payment but that you will not get anything for four weeks.

So I got these beer cans. I mean the motors are as big as beer cans. Not an issue, they look great and have built in fans to help with air flow (heli version). I just think that motors are way too big for our school girls. The kevlar skin that we used is way too dense for the skin application. The carbon fiber equivalent material was great and the other airframe came out pounds lighter. I thought I could pay the piper by just putting down more power. It is not going to work that way. We will have to put it in a pusher configuration.

That is one of the cool things about the school girl. We can run with two under-wing motors, as a puller or a pusher. The changes do not effect the airframe much and really are about moving some power wires in the fuselage. It is really convenient. I hope the balsa kits come out well, it should be a great sport flier.

Phidgets Accelerometers, the Magic of Three-Axes

The three-axis accelerometer is a piezo-electric accelerometer that is about 1" square. It is pretty good and have never seen any issues with drift or orientation issues. It measures each axis in units of g Do not forget to convert to your units, so a reading of 1.2 is actually an acceleration of 38.6 ft/s/s. I just make a little helper function to convert the readings when the phidgets_accelerationchanged method fires.

Hopefully, that will help clean up your code by reducing the risk of double converting units. Even NASA makes this mistake. One of the first things that I set up is a library of unit converstion factors. That way it is less risky if the user wishes to see the measurements in , mks or cgs and my software interanlly uses US Customary slug-ft-lbf. I do not do any conversions in the code. Just read the electrical signals from the transducers and convert them to real units, consistent with the system. Do not try and convert back and forth within the code, it will just be miserable to find.

You convert to any system that is different than your base unit system until you display the data. You can easily set a flag in the display object that shows the data to the user and multiply out the measurements at presentation time via the decoration pattern. To be honest, the Phidgets API is awesome. It makes short work of connecting and managing their instruments, so the code to start an interface kit is not so different from the accelerometer.

do
{
//System.Threading.Thread.Sleep(10);
if (acc0.Attached)
{

Console.WriteLine("_acc0 attached");
//accelerometer events
acc0.Attach += phidgets_Attach;
acc0.Detach += phidgets_Detach;
acc0.Error += phidgets_Error;
acc0.AccelerationChange += _acc0_AccelerationChange;
}
else
{
Console.WriteLine("retry : " + retry + " waiting for acc0 attach");

}
retry++;
} while (retry < 10 && !acc0.Attached); #region helperMethods #region Phidgets event handlers ///

/// handle the phidget device discovery events
///

/// /// protected void phidgets_Attach(object Sender, AttachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " attached.");
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Attach( Sender, Args) :: " + _exc.Message +
"\n");
}
} //phidgets_Attach
///

/// handle the phidget device discovery events
///

/// /// protected void phidgets_Detach(object Sender, DetachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " detached.");
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Detach( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Detach
protected void phidgets_Error(object Sender, ErrorEventArgs Args)
{
try
{
Console.WriteLine("phidgets error : " + Args.Code + " " + Args.Description);
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Error( Sender, Args) :: " + _exc.Message +
"\n");
}
} //phidgets_Error
///

/// reads the acceleration from the Phidgets accelerometer
///

/// accelerometer object/// essentially an array of three doubles, one for each direction measuredprotected void _acc0_AccelerationChange(object Sender, AccelerationChangeEventArgs Args)
{
try
{
rawAcc[Args.Index] = Args.Acceleration;
}
catch (Exception _exc)
{
Console.WriteLine(
className + " protected void _acc0_AccelerationChange( Sender, Args) :: " + _exc.Message + "\n"
);
}
} //_acc0_AccelerationChange
#endregion

Another helper method that is constantly requested is converting from accelerations to roll and pitch. You can do the trigonometry yourself, but if gravitation is assumed to act in the -Z direction you can work out the basic orientation of the accelerating object. This can be fooled by large or quick orientation changes, but for the most part sampling frequency can fix this. So I would make sure that you do as little as possible that may muddy the event handler system. They are really fast and that is a good thing in this case.

///

/// calculate the euler angles from the local accelerations
///

/// acceleration toward the right wing, g [gravity multiples]/// acceleration toward the nose, g [gravity multiples]/// acceleration toward the ground, g [gravity multiples]/// headingprivate static void accel2euler(double Ax, double Ay, double Az, double Compass, out double[] EulerAngles)
{
EulerAngles = new double[3];
try
{
double g = Math.Sqrt(Ax * Ax + Ay * Ay + Az * Az);
/* Roll */
if (g != 0)
{
//EulerAngles[0]=Math.Atan2(Ay,Az);
EulerAngles[0] = Math.Atan2(Ay/g, -Az/g);
}else
{
EulerAngles[0] = Math.Atan2(Ay / 1, -Az / 1);
}
/* Pitch */
if (g != 0)
{
//EulerAngles[1] = Math.Asin(Ax/-g);
EulerAngles[1] = Math.Atan2(Ax / g, -Az / g);
}
else
{
EulerAngles[1] = Math.Atan2(Ax / 1, -Az / 1);
}
EulerAngles[2] = Compass; /* Yaw */


}
catch (Exception _exc)
{
throw new Exception(className + " public static void accel2euler( , " + Ax.ToString("0.000") + " , " +
Ay.ToString("0.000") + " , " + Az.ToString("0.000") + " , " +
Compass.ToString("0.000") + " ) :: " + _exc.Message + "\n");
}
}

The one thing you will notice is that you cannot get the yaw from the accelerations. That makes sense if you think about it, flat rotation perpendicular to gravity would not be measured. I usually run a compass in the systems too. That makes the 3-1-3 rotation easy to move between body reference frames and global reference frames. I would suggest that you multiply out the cells for the rotations in a separate method each so that you can just multiply them by calling each method in turn with an argument of the last rotation.

A Stability Manager is Good to Have, But You Could Wing It

More about the loathe and planning of your own autopilot. I used a hopefully simple system to handle the stability manager. I set up a system that uses a simple interface for strategies to get to keep the plane in the air. From this strategy interface, I developed several strategies that specialized in different aspects of managing the airplane's performance.

The strategies then calculate a solution and then pass it to the task manager. The servo manager pops the solution off the task manager's stack and gives. From the solution the servo manager converts the new inputs to a servo position map. It converts the map to servo motion and executes the changes. The Phidgets controllers that we use allow for several settings to be set as it moves the servos into position.

It may seem a bit "math nerd", but the cool thing about the Phidgets controller is that you can set the final position, the speed and the magnitude of the acceleration used to make the changes. In general, I leave it to figure out the acceleration. However, in coordinated systems it may be important to set the jerk of the servo arms so that you do not lock up linkages or other mechanical interfaces to the servos.

My strategies are simple. I tried to decorate a base object with virtualized methods, that way if I missed or the method's implementation did not just come to me the methods would have something by way of implementation. This seems to be a good way to handle this kind of "how the heck do I do this" programming. I am sure there are more professional ways of doing this, but here is how I did it.

///

/// used in the strategy design pattern, so that you can use different strategies and change
/// them by delegate
///

public interface IStrategy
{
///

/// execute the strategy but do not return any results
///

void Execute();
///

/// exectute the strategy, return the result
///

/// result of the strategy
object Execute(bool bResults);
///

/// exectute the strategy, return the result and a object
///

/// return a second resultant object /// result of the strategy
object Execute(out object Result);

}

public interface IStrategyResult
{
object ShowResult();
}

Now these are interfaces that I used to make a series of strategies to balance the different flight aspects and how to keep the system on course. These are run through at about 20Hz and the results are compared at 10Hz. That way decisions can be made at 5Hz and you can keep the whole thing from bumping into the data collection and servo motion phases. It happens, but if the frequency is high enough, we can miss a solution or two and still make it in time to decide which solution was best.

A simple markup model then decides which result is most successful and passes it down the chain. My biggest troubles are always how to correctly smooth the position and orientation data. They are effected by several different coupling and acceleration balances. I have heard about these Kalman filters that everyone loves so much, but have yet to be successful implementing one myself from scratch. I usually keep a simple integrator system to keep the changes small(er) and tend to stay in constant speed-level flight if at all possible. That is better for overall system performance anyway. You have to pay the piper for every energy change.

Business Opportunities in Central Europe or Brazil

Buzz Labs is looking for business contacts in Central Europe or Brazil. We are seeking interesting applications of UAS and UGV in most places or partners to help develop certain aspects of technologies for related projects. Our business is about developing technologies to support unmanned systems in general or how to achieve certain commercial or scientific requirements.

Maximizing our understanding of networking and aviation knowledge is allowing for fascinating new insights into what is possible even with the current states of technologies. We are most interested in multi-spectral image analysis, distributed pico-computing, alternatives to radio control, streaming technologies,power systems and system configuration.

Central Europe and Brazil are great stable markets that we would like to become a bigger player in. Please feel free to contact us with questions or ideas.

info@fatmanflying.com

Of Directors and Other School Marms

In my model, there is one king pin class. It does all of the general start to stop management of the system. The director class is where all of the managers hang from. I do not really hang a lot of factories off of the director, the  decorations to the class are minimal.

At start up, the director sets all of its properties from the configuration files and starts the managers. The managers in my model are:

• instrumentation manager, im
• task manager, tm
• ai manager, aim
• stability manager, stab man
• communication manager, comm
• display manager, display

This can be relatively complicated since the observation system must be handled by the director. The data flows from the instrumentation manager to the stability manager (stab man observes im). Task managers observe the communication manager to queue jobs, they also watch the stability manager. The Instrumentation Manager also watches the task manager, but only because it also contains the servo manager. Tasks go from the stability manager to the task stack and are then sent to the servo manager.

I thought this was the best way because whether or not the communications manager has a command, the task queue will be populated. The servo manager will then grab tasks and handle them in a first come first served pattern. If a command expires by sitting in the queue too long it is dumped by the task manager when the servo manager pops it off of the queue. As the system becomes more complicated, there could be more queues to do more things. However, tasks that require moving a servo always go to the servo queue.

I have read the great MAV blog by Tom Pycke. He has lots of things to say on the topic of real time operations. However, my idea is that they are not really so important. I do agree with him that his way of dealing with garbled or miscommunicated commands to the MAV is pretty interesting. My way seems to be not so bad either. The system must be able to fly itself, you tell it a basic plan to fly along. Any command inputs from the ground station are "exceptions".

Exceptions are easier to manage because you do them as soon as possible. When they expire you stop doing them, the system still tries to make the best of the situation and go back to the plan. This guidance could make a complete mess that breaks everything, in the case of coordinates that are for a different city. Your system may start flying off in a crazy direction trying to get home. However, that is why there are a few directives that the director knows and is the only one that can execute.

I keep a few tasks in the clip for a special occasion. My "director-only" tasks are:

• shutdown
• go to safe altitude
• land immediately
• idle

Shutdown is a good example of a game ender. If you shut down the computer systems and the current. For a UGS it may not be so bad, a UAS just falls out of the sky. In my overly instrumented systems, we have an aircraft on ground sensor. It is nothing as cool as a weight on wheels, but it does check to see how far the fuselage is off of the ground. This is to enforce a flight floor system, only in certain situations will it not try to climb to the safe altitude. In general, the safe altitude should be above the tree line. Altitude is safe for a UAS, this is not as necessary for a UGS but it can be interesting to have. Land immediately works for either kind of system, it forces the system to plot the fastest route to the start area/landing strip. Once the system arrives in the pattern, it will begin normal landing/parking processes. Idle is similar to shutdown, but it does not cut the power. It however, means RC override in implementation. The computer lets the system freewheel, this can be useful if the computer keeps doing crazy crap and you have to bring it back.

The ai (artificial intelligence) manager is the basis for the flight state. It reads the preset," at least we have somewhere to go" map and determines which mission phase the system should be in. Mission state is important information because it will time the use of instrumentation or cameras, as well as when to hit the "panic" button. The stability manager uses this to set system configurations and movement regimes for the  system.

A director class is a operator, directing the data from one manager to the other. The AI manager is where the state manager exists.  More on the AIM later, check in tomorrow if I am feeling feisty and have not cut myself up or glued something good to the table.

I almost forgot

Prototype two's wing is now almost complete. It will be mated to the fuselage hopefully tonight. I must have really bollocksed up using the pattern that I made on the first plane. It is a different diameter than the first. The second prototype has a more tear drop shaped fuselage that the first aircraft. I think it will make it easier to shore up the system with stringers than the purely round shape.

Before we get to actual code...

Before we hop off into any actual implementation, I would suggest that we sit and think about some basics. The very first thing that should be done is to come up with a basic skeleton of the code that you would like to write. This may impact many decisions down the line. Basically, a UGV and a UAS/UAV are the same from the code's perspective. The UAV/UAS use different actual algorithms for certain processes, but the data flow and data collected are not so different. Some data is read, a decision is made, a servo solution is calculated, servos are moved into position and then the system loops again.

One thing that I did, was to develop an object that was a sensor, ISensor. This will be the part that actually interact with any device. ISensorReading will also act as a fundamental contract for data. I would make sure that this object follows in general an observable pattern. That way it is easy to allow other objects to read its data, or to be notified when new data is available. This will make it easy for filtering algorithms to execute and work on the newest data as soon as it arrives. It will also make it easier to make the data collection to be asynchronously collected and processed.

Then I made an instrumentation manager, IM. The IM will have factories for each kind of sensor and observe instances of each of the instruments. This way if something happens the IM can close an instrument and try to reconnect with a new object. In turn, the IM presents data to other parts of the code as needed. No other parts of the code need to see the sensors or interact with them directly.

On top of the instrumentation system, should be a director layer. This will actually be the layer that does all of the work. It makes a nice break line between the device and the presentation, or intelligence. Separating the systems is an important object-oriented technique that is necessary for keeping the code healthy.

More about the director later... I will see if I can get some pictures in to make it easier to see.

Gyroscopes Are Fun!

Piezo-electric gyroscopes are fun. However, I certainly had to learn a lot of things to get a usable signal from them. Remember that  gyros report a rate of change not just an absolute value. This rate presents an interesting issue, that we have to integrate the signal at each step. You may want to use a more advanced curve fitting integration scheme than the one that I will present here.

Integration for those not in the know is just finding the area under a curve. The catch is that, you will never be given a curve by the gyroscope. Not having a curve means that we must discretize the signal, from these step-wise readings we can write a formula that will help us back out what the absolute angle is in that direction. However, since we are integrating these formulae will not take into account small changes that happen to the signal between samples.

The simplest form of integration is, just calculating a rectangle. Your software will have to remember the last reading from the gyroscope and the last calculated  position.

angle change =dAngle* step length

so the basic formula would be,

Angle i = Angle i-1+ angle change

A better technique would be simply approximating the changes in the curve as linear segments and then calculating the differences as triangles or trapezoids.

This is a relatively bad way to do this, but is easy to understand. I would suggest using a multi-order approach to try and take into account some of the variations in these signals. The nuts and bolts of it is, is that the equation only works if the change in angle is relatively small compared to the current angle. If you are executing maneuvers and sampling relatively slowly this formula will lead your software astray. I would use a gyroscope sampling rate that is at half of the gyroscope's sample acquisition rate. Halving the sampling rate should keep the software getting into too much trouble from landing between readings and getting garbage.

Remember to read your manufacturer's guidance on this. It will tell you how quickly it can measure changes. We use several of these:

http://www.sparkfun.com/commerce/product_info.php?products_id=9094

They are 500 deg/s sampling rate at 2mV/deg. That is usually too small for our analog to digital coverter boards (A/D boards), so we lower that to 150 deg/s and get a better signal rate of 9mV/deg. This means that we can get a nice clean signal that is several bits wide from our A/D board. Remember that your I/O system will determine a lot of things about your code.

If you sample to fast, you can have lock issues, too slow and you do not get a representative sample. I would suggest that you shoot around 200Hz for samples, and then apply your filtering to bring it down to a rate to allow your other software to make decision on the filtered values as if they were the just read values.

There are better boards available, but the ones from Phidgets.com have a great API for almost any platform. Their 8/8/8 boards are great all-around boards, but do not have the highest sampling precision. For most things, it is plenty.

I really like the .NET support and the usb interface. Even I could figure it out from their examples in only a few minutes. Next time, I will show you how easy it is to connect to the A/D board and begin acquiring signals. The code samples from Phidgets are effective and describe most of the general functions that you will need to implement a system with their instruments.

Basic Quantities and Some Trigonometry

So You Want to Build a DIY Autopilot

Accelerations

One of the most important quantities for you to measure are accelerations. If your two or more-axis accelerometer is mounted along the traditional axes of the aircraft it will be the easiest to code for. The three traditional axes are:

• From the nose through the center of gravity on the line of symmetry, the Y-axis, roll
• From the center of gravity out of the fuselage toward the tip of the right wing, the X-axis, pitch
• From the center of gravity away from the earth, the Z-axis, yaw
  
     

Figure of Rigid Aircraft Axes

So, now for some basic Trigonometry, everyone remembers SOH CAH TOA.

In general, the following picture is true for a vehicle moving through space.

Figure of the Direction of the Force of Gravitation on a Body

As you can see from the image, the angle of pitch relative to the surface of the earth is the same angle offset of the weight vector relative to the z-axis in the body frame of reference. If we put our accelerometer so that one of its axes is parallel to the body's z-axis at its center of gravity we are measuring this offset vector. Which is really neat, because it means that we can express the angle of the body in level, non-accelerating motion as ratios of the accelerations

Pitch: 

The angle theta between the actual gravity vector and the measured gravity is related to the pitch of the aircraft (pitch = theta + 90°). If we know theta, we know our pitch! Since we know the magnitude of the earth’s gravity, simple calculus gives us our pitch angle:

accelerometer = cos (theta) * gravity

theta = acos (accelerometer / gravity)

And since pitch = theta + 90°

pitch = asin (accelerometer / gravity)

Woot, we calculated the pitch orientation of our airplane using an accelerometer. Pretty easy, huh?

The real formula that we need to use for the software looks like this:

pitch = atan2(accelerometer / gravity, z / gravity)

Common piezo-electric accelerometers return in units of, g, 32.17 ft/s^2 or 9.81 m/s^2. We also know some more things about the flight that let us calculate the angles relative to the ground. More on this later, it is a bit more than basic trigonometry to describe. These equations assume non-accelerating flight. You can use a magnetometer to get the relative plane in space with less math, but magnetometers generally take more interface programming in my experience.

Roll:

Roll needs a second accelerometer with an axis perpendicular to the first so that we can figure out the resultant vector between them and then the angle. Essentially the vector between the accelerometers becomes the "gravitational" acceleration and the relative readings lets us calculate the angle with an atan2 function. The second accelerometer will have some other things to manage such as the effects of the distance between them on the accelerations measured. Physics fun and none of the boring class.

Yaw:

Yaw is the hardest of the angles to measure. The only answer is to use a magnetometer or a compass. In many ways, yaw can be solved by dead reckoning. Dead reckoning is all that is important for most of the projects in the DIY garage. They will be covered later.

Next we will discuss gyroscopes and the beauty of rates and integral calculus

How I started writing a DIY Autopilot

My intention still is to write my own c# based autopilot. It is not trivial as I found out. Lots and lots of details are needed. The first thing that needs to be done is to determine the instruments that you will need to measure the quantities that you need to know to control flight. Even this seems to be a matter of opinion. For a reference, I found every group that I could that was writing their own version.

From my perspective the quantities that we need to know to control flight are:

• air speed, ft/s or m/s
• altitude, ft or m
• orientation, roll, but pitch is good

These are intrinsic quantities that are really easy to do yourself. Air speed is the model's forward velocity. Altitude is the vehicle's position relative to the surface of the earth. Pitch and roll are the angles of the vehicle relative to the ground. Let me rephrase that, roll is the angle between the right wing and a plane parallel to the ground. Pitch is also known as angle of attack. Pitch is the angle between the plane at the center of the vehicle located on vectors from the center of gravity to the right wing tip and the center of gravity to the tip of the nose and the relative wind.

At the beginning you will need to measure the following quantities:

• air pressure
• acceleration in at least two directions
  

Pressure taps are the easiest ways to measure air pressure in a flying vehicle. Piezo-electric accelerometers are cheap these days and are really accurate. In the next post we will talk about issues with these instruments and the physical quantities that you are actually measuring and how to use those as a basis for a control system.

For all of those inch haters, a quick note about units. You can do this in any unit system. It is unimportant. I will write a quick post on the conversions between the US Customary System and the metric (mks) system. Remember metric is actually several unit systems in one and you have to keep them consistent. Oh, and for those trying to buy nuts and bolts, Japanese manufacturers use odd metric sizes, European use even metric sizes, and the US Customary System/SAE is in units of 1/64th of an inch. So SAE/SAME will have three bolt sizes for every bolt size in the two metric systems. Remember that the thread counts are different though.

In my opinion, if the units are managed consistently then the issue is one of presentation to the user. Part of the display system of my code will show you how to do this with a simple object oriented approach.

Tiny 2.11

I need another u.fl connector-based antenna for the ground station XBee Pro modem. I found some at Sparkfun. Per advice, the best plan is to go for the cable and duck route. All of the electronics will be boxed to make them easier to shield from the high current wiring from the batteries to the ESC to the motors.

My current plan is to use:


SMA duck antenna

u.fl to SMA cable

Tiny 2.11 Out of the Box

For those of you following these projects, I have tried to wing an autopilot myself. It actually is getting there, but I thought. Better to get to market with a product before we spend five years debugging stuff that was just a dead end to begin with. I was reading around about each of the other projects on DIY drones. I was considering the Ardurino autopilot, but was a bit concerned of writing ANSI C at a register level. So I went with the Paparazzi autopilot which is well received and more finished to a level where I was willing to get my feet wet.

I got my Tiny 2.11 from Chebuzz in California/UK.

"unpaid recommendation" The guys at Chebuzz are great, I do suggest buying from them. They are better priced for the American market than the other assemblers, have great service and are willing to answer even my bone-headed questions. "unpaid recommendation"

Out of the box, well it came in a normal padded envelope. I was eagerly trying to figure out what each board did. Having returned from vacation, I had forgotten what I had learned. So, here are the parts I received from the "Everything You Need" kit from Chebuzz.

XBee Pro modems
modem0modem1modem2modem3modem4

Main Tiny 2.11 board with pico blade connectors
top
bottom

ESC throttle wire
black and white two pin