Well, the good news first. We have made headway on obtaining our compass heading through the GPS chip. We have adjusted our parser to discriminate the NMEA strings based on their “tag” (default config. spits out 3 different strings) and to pull out the true heading. It is kinda cloudy today in meadville so we got a satellite lock but I don’t think that it was a great one.
The bad news is that the airplane still has the tendency to nose down and to the left. We did a little bit more ground testing today to rule out the presence of crippling motor noise. We didn’t notice much change of the leveling reflexes between throttle off and throttle on (1-100%). We did a little manual linkage adjustment because the trim on the radio was slightly off from the trim on the autopilot (very possibly leading to a left turn). We also doubled the amount of elevator throw that the airplane has when trying to correct an improper pitch condition.
Hopefully the weather clears up soon so that we can fly…
The UAV flew again yesterday afternoon for some more flight code testing. We now have a level flight sequences and turning sequences running on a timer. Level flight needed a little tuning as it had a tendency to roll to the left, and then dive. I updated the zero position of the sensors, and will make sure that our sensor is perfectly level. Turns seemed to work ok, but it was hard to tell with our level flight issues. We will be testing again this afternoon starting at 1:00 P.M at Robertson Field.
Once we get level flight and turns debugged our goals for the near future involve implementing our airspeed sensor and including throttle control into the auto pilot. Getting a working GPS is on the agenda too, but that is going to involve some help from Drew to get serial working how we need it to.
It when well until we brought the plane in for its first battery change. The plane was a little nose heavy from the sensors and had a hard landing. You can see the badness that this caused in the last post. We are working on repairing it though and expect the next flight to be Monday the 26th.
We have some flight video from last night on a camera that we borrowed from the library, but we are having trouble getting it off of the camera. We are close though…
Just a quick idea of how it flew… It flew great under both R/C control, as well as autonomous control. As of now we only have level flight stabilization (roll and pitch), with no yaw correction. There was only minimal oscillation about the axes when put into autonomous mode, which means that we have the sensitivity set pretty well.
The first landing didn’t go so hot… Since we had a bit more weight up front with the sensors, it seemed as though the airplane was a bit nose heavy and came down faster than usual. Flying at Robertson makes it hard to get a nice long glide slope, which allows the pilot to get the plane slowed down in time for landing. On approach, the front wheel got caught in the grass and snapped the front part of the plane off. The wing also broke in the middle where the spars join up, but broke pretty cleanly so it should be a quick fix. The first two pictures are of the broken fuselage and wing, and the third picture is of the fuselage being fixed.
Just giving everyone a heads up that we will be attempting our first autonomous test flights tonight at 6 P.M (weather permitting of course) at the Robertson Sports Complex Soccer Field. Anyone who is interested in seeing the airplane fly is welcome to attend. We will be testing our autonomous level flight stabilization, and possibly testing code that involves a few autonomous turns.
We have successfully implemented code that controls servos, and more importantly it does so based on our IMU. Here is a short video demoing our code.
We implemented a simple complementary filter to ensure that we are getting good data. Our filter also works entirely with integers! This means we avoid any problems we were having with real numbers.
One of the previous blog posts mentioned a possible problem with the data that we had collected from our X-axis accelerometer. While trying to characterize all of the axes with higher precision using a homemade protractor setup we noticed that even our Y-axis data was skewed. Prior to testing we updated the build of the Transterpreter and Plumbing that we were using to make sure that we were current.
My computer had been running slowly lately so around lunchtime I decided that I would take a break to update my linux distrobution to Ubuntu 10.04. After reinstalling the Transterpreter and Plumbing, all axes on the Razor IMU seemed to be working properly. Below are some graphs of how our data looks now.
This is the data retrieved from the X axis of our IMU
This is the Y axis data from our IMU
The best explanation for our problems is that the code in the transterpreter has been constantly changing, and we may have had a different ADC reference voltage each time we tested. Now that we have good data from our accelerometers it is time to implement the complementary filter which we will document soon.
We flew the airplane for the first time Saturday the 10th of July around 6:00 P.M. Once we took part in the wonderful picnic that Prof. Jadud provided us it was time to walk the airplane down to the west end of Robertson field. The airplane was noted to be slightly tail heavy in a pre-flight inspection, but the decision was made to continue with the maiden. The first three flights were rather unpleasant as the tail heavy condition was more severe than expected. Slowly weight was added between flights, and then the airplane was brought in for the evening. Damage was incurred on the nose gear as it was not robust enough to land with.
The plane was also flown twice on Sunday the 11th around 8:00 P.M. More weight was added to the nose, and the battery mount was modified to get it closer to the front of the airplane. Results of the modification and addition of weight prove to be successful as the plane flies much more stable.
On our Razor IMU there are three different MEM sensors: a 3-axis accelerometer, a 2-axis gyro, and a single axis gyro. We have been doing our best to get decent unfiltered data out of our IMU to understand better how it works and where the problems lie. The gyros give us relatively clean instantaneous angular acceleration data that we will be able to convert into a definite position around the X, Y or Z axis once we get our filtering processes implemented. The accelerometers have been giving us a bit more grief…
Ideally the accelerometers should give us a good idea of the angle we are above or below the horizon in each axis. This is achieved by mapping the units that are spit out by the analog to digital converter, to a range from -1 to +1. This range is necessary to make sure that when using the arccosine function (to find the angle) that we do not have any values in our calculations that give us a result that is undefined. This seems to work well with the Y axis accelerometer, but is not the case with the X axis.
When looking at the Y axis accelerometer data: at +90 degrees (above the horizon) we get an ADC value of about 610, at 0 degrees we have a value of about 512, and at -90 degrees (below the horizon) we have an adc value of about 410. This gives us about the same range of sensitivity both above and below the horizon. This is not the case with the X axis. As shown in Figure 1, the range that we have below the horizon is non linear, and is about twice the range that we have below the horizon. At +90 degrees on the X axis we have an ADC value of about 412, at 0 an ADC value of about 512, and at -90 degrees an ADC value of about 768. This behavior is not what we expected to see. We expected that both the X and Y axes should behave similarly considering that they are both in the same plane.
Figure 1: The X accelerometer seems to have a "dead spot" and non-linear values around 80 degrees below the horizon
We will have to wait and see if this is a defect in the accelerometer chip, or if it is just a trend that we will be able to filter out with our Kalman Filter that we are currently implementing.
A video that we took of this trend is below. The values on the screen are a bit hard to read, but correspond with Figure1.
More on the ardupiolt Mega and the Transterpreter. When we started the Transterpreter did not support Arduino Mega boards… this was a problem as we are using the Mega to fly our plane. Currently Matt, Drew, and Radu are working on getting us Mega support and are doing an awesome job. We should have it soon. Due to not having the Mega support right away we have been using a Freeduino to do all of our testing on so far.
It has worked great so far, but for the GPS we need 2 serial ports to see whats going on and we only have one. We did however emulate a running GPS and from that wrote a simple GPS string parser. Once we get the mega we may refine our parser, but as of now it works pretty good!
One more hurdle we have tripped over is that floating point numbers are not fully supported in the Transterpreter. We can use them but we can not print them to our screen and see whats going on so. We hope to have floating point printing soon. It has not hampered us to much though.
More to come a post on how we interpreted the output of our sensors.
