Implementation

Trying to actually implement the above integration formula on the integer-only math of the Parallax BASIC Stamp was a bit onerous. I was using fractional conversion factors and performing division that resulted in remainders. I had some difficulty obtaining the gyro rate integration using this approach and the relatively simple, inter-only-math Parallax BS2pe. There are integer-only conversions you can make to do so, but the accuracy is limited and the processing power to do so is lacking with that microcontroller. I decided I really needed to move to floating point math capability. I would learn much later that a lot of my difficulty at this point was not due to these constraints, but rather another problem I did not recognize at the time.

In addition to the integer-only difficulty, there is no convenient way to accurately set the sample rate of the BASIC Stamp since there is no access to timer control or interrupts on the BS2pe. I had to essentially set up my code, then insert some programming feedback indicator loops (e.g., turn on an LED via my code, run a hundred samples, then turn off the LED and use a stopwatch to see how long it took to run the 100 samples. Then I would divide the stopwatch time by the 100 samples in order to know what the sample rate was. Then I would go into the code and change the sample rate factor in my calculations – but I was always playing with the sample rate factor because any time I modified the code, the execution time changes and therefore the time to take 100 samples changes - tedious.

Even when I got the sample rate routine sort of figured out, I was still having little success in generating angles. The angles I got were very erratic and always greatly less than the actual observed orientation of my setup. If I changed one of the formula factors by an order of magnitude I could almost get there, but it was very inconsistent in nature. It was very frustrating. Though I thought I was doing things correctly, my calculated angles always seemed to be about a third of the actual observed angle. I went over things in my setup and code a hundred times and did more research to confirm that my integration formula was right. I concluded that the “looseness” of the integer-only, non-interrupt processing of the BS2pe was the culprit. So, I searched the Parallax site for an alternative.

Floating Point Unit - FPU

I came across the microMega Floating Point Unit, or uMFPU. Cam Thompson has produced a great chip and created a great web site at microMega. At Cam’s site you can find support for using his uMFPU with a variety of microcontrollers. With the uMFPU, I felt would be home free since I would be able to implement floating point math, as well as precise sample rates.

The uMFPU contains, in addition to its built in floating point support, a couple of channels of 12-bit ADC, so it was a relatively simple process to attach my IDG gyro to one of the ADC inputs on the FPU, and then connect the FPU to the BS2pe. Among others, one of the built-in functions of the FPU was the ability to program/select specific sample rates for the ADC reads.

Serial Interfaces

The are two fairly common methods to interface peripheral chips with a microcontroller, I²C and SPI. Implementing one or the other is not too difficult, but doing so with the uMFPU was facilitated by BASIC Stamp-specific example code and demo programs provided by Cam on the web site. Since I had some SPI experience interfacing my earlier 12-bit ADC into the BS2pe, along with Cam’s excellent documentation, I had the IDG1215 talking to the FPU and the FPU talking to the BS2pe in short order. I figured I was getting much closer and good angles would be had in quick order!

Programming the FPU however was another learning curve and took a bit of work and study – just another in the series of bumps I was going through. In order to configure or program devices such as a microcontroller or FPU, the manufacturer will often create what is called an IDE – Interactive Development Environment. The IDE provides support for your programming by including access to various libraries of functions, utilities, compilers and the like to help keep you out of trouble and assist in developing your application. I had used an IDE from Parallax when I was programming the BS2pe, and now I had another one to learn for the microMega FPU.

The IDE for the uMFPU is very complete in this regard, even going so far as to allow you to describe what you want to do in simple written terms and then have it compile your basic statements into the machine language that the FPU requires to run. In addition, Cam was always ready to lend a hand to help guide me through the process. I doubt he has the time to spend with very many people at the level he was assisting me, but he was intrigued by my application with the rocket tilt meter and went out of his way to be helpful. The FPU is a beautiful device and fun to work with, though a bit daunting for a neophyte such as me.

microMega Floating Point Unit

However, with some hard work and Cam’s help, I was able to tackle the FPU and get my code running. However, I still was not able to get good angles! Oh, the frustration. I kept checking my formula to be sure I was not off by a decimal point or two in some of my factors. I changed out the sensors. I changed the microcontroller. I had Cam check all my code. Everything seemed to be OK, but I could not get any reliable data – again, the angles always seemed to indicate 30-40% of the actual observed tilt.

William Premerlani

As I was exploring all the various web sites during my research, I came across so many resources, microcontrollers, sensors, IMUs, autopilots and the like. My favorite sites were SparkFun and DIY Drones – SparkFun seemed to have all the goodies I might need and DIY Drones had a community of open source programmers and RC pilots that provided a wealth of information related to what I was exploring.

In going through some of the blogs on the DIY Drones site, I kept seeing references to the UAV Development Board (UDB) and a guy named William Premerlani. I found out that much of what DIY Drones had developed for their autopilot was modeled after Bill’s open-source UAV Development Board (UDB). Apparently, Bill was challenged by his son one day a few years ago to build an autopilot after they saw a UAV make a Transatlantic crossing. Though not expecting to cross the Atlantic, Bill took on the challenge and began to develop his own autopilot board and software.

William Premerlani’s UAV Development Board

I contacted Bill one day and told him of my project – he showed immediate interest and offered to help. After a few discussions with Bill to sort through what I had been doing, we realized that one of the pins on the gyro I was using needed to be grounded. Once corrected, I fired up my project and instantly had a working, gyro-based tilt meter giving me proper angles (January 2010)!

The UAV Development Board - UDB

Now that I fumbled my way and learned enough to actually do rotational rate integration and derive angles, I spent time discussing the more rocket-specific details of my project with Bill. I came to realize after really studying his web site and the related blogs, that with where I ultimately wanted to go, Bill’s UDB already incorporated so much of what I needed to get there.

So, after discussing it with him for awhile, I ordered a UDB and started to study the code on the UDB web site in earnest, ordering a couple of books on C along the way.

I did not expect to actually use the UDB for my tiltmeter because I wanted to use different gyros that it used. I figured I would experiment with the UDB, and then adapt its code and my gyros to a similar PIC-based development board. Bill had used a PIC microcontroller as the heart of the UDB.

Initial Gyro Flight Testing

While waiting for my UDB to show up, I wanted to determine if the Invensense IDG1215 dual-axis gyro sensor was actually the right gyro to use. I needed to know if it was capable of performing while under the stress of the g load experienced during a high-powered rocket flight. The datasheet for the sensor did not specify what effect linear acceleration had on its performance. My alternative, the single axis, more expensive Analog Devices (AD) ADXRS614, included such a specification that indicated it should not be subject to a significant error due to linear acceleration. Additionally, the AD gyro was what is called a Y-axis or orthogonal package meaning it needed to stand vertically on the board to sense X and Y, whereas in addition to including dual sensors in one package, the IDG1215 was designed to lay flat on the motherboard, possibly reducing other effects of high g forces, vibration, etc.

   Gyro Test Fixture w/Logomatic Data Logger

I designed a little fixture that I could fly in a “mule” rocket that would simultaneously record the output of the two different gyros during a test flight. I used another device from SparkFun, a Logomatic SD card-based data logger. With the Logomatic, I could connect both of the gyros simultaneously through two of its eight ADC channels, then download the data after the flight and compare the outputs.

I flew the gyros a couple of times (March 2010). The results indicated to me and Bill that there was not a substantial difference between the performance of the two designs, so I thought at that time I could probably get away with using the less expensive, flat dual-axes Invensense gyros.

I did note one interesting thing about the gyro output that I had not considered earlier in my tilt meter project. It set me back quite a bit once I realized what I was looking at. I was about to finally get a true hint about the magnitude of the project I had taken on. Another learning curve here we come!