Frame of Reference Transformation

I took the data of the Logomatic and inserted it into an Excel spreadsheet. The data I had was simply the raw output of the gyro sensors. One nice thing about the Logomatic is that I was able to precisely define the sample rate that the Logomatic used while collecting the data. This made it easy to apply my integration formulae in Excel. I was easily able to apply the formula for the specific sensor and calculate the angles the rocket flew during the test.

The motor I used in the test flights was a bit underpowered so the rocket began to arc over almost immediately after launch – I worried about that at first but then thought maybe it was better since I would possibly get more relevant data that if it flew perfectly straight up to apogee. Since I was able to calculate the rate integration and determine the flight path angle (or so I thought at the time), I was quite proud of myself and very happy to have actually made what I thought was significant progress after such a long journey to that point.

I calculated the angles of the two different gyros and they looked very similar as I scanned down the column in Excel, convincing me that the performance of the IDG gyro was nearly the same as the AD gyro. I then plotted the data out into a graph for better comparison. The plots looked very similar, further convincing me of their like performance.

However, something I had not considered became apparent as I studied the curves. Though I knew that the rocket flight path had a continuous arc from my observation, the angles I had plotted grew as expected, but then diminished further along the flight up to apogee. Hmmm, that was odd. It was also not consistent with my observation that the rocket continued to arc over at a fairly steady state all the way up. What did that mean? Then it dawned on me. The rocket had rolled during it ascent to apogee and this threw the angle calculation off.

I slowly realized that the rocket, as it lifted off and began its ascent, began to arc over to the right, which in this case due to how I had it mounted caused the output voltage of the X-axis gyro to decrease which, when integrated, would indicate an increasing negative angle. So far, so good. However, as it got higher in its flight, the rocket rolled around the Z-axis such that the X-axis gyro now began to output an increasing voltage even though the rocket’s flight path continued to arc over to the right. If the rocket had not rolled, the indicated negative angle would have continued to increase, but since it rolled, the positive output when integrated began to cancel out the accumulated negative angle! The net effect was that the indicate angle was less than the actual incurred angle.

3-Axes Gyro/IMU

I thought about this some and figured I could simply incorporate a third gyro axis to track the Z-axis and include the rocket’s roll about the Z-axis into my angle integration formula. That seemed easy enough to do. I had hoped I was at the end of most of the hard technical aspects of the problem. But, I was slowly realizing how subtle all this was and that I just was not able to predict where things might lead. As my physicist friend shortly thereafter advised me and I found to be true, “You’ve just made the first baby steps towards the transformation of two coordinate systems, the earth’s and the rocket’s…”

At the time though, thinking about it some more, I started feeling that maybe it would not be so bad after all. If the rocket took off and arced over to the right 10 degrees, then instantaneously rolled about the Z-axis by 180 and continued to arc over another 10 degrees the actual angle in the earth’s frame of reference would be 20 degrees. The integrated angle of the gyro’s output would be 0 however since the roll would cancel out to cumulative angle. But, if I knew that the rocket had rolled 180 degrees, I could subtract the second part of the integration rather than add it and the result would be consistent with the actual tilt. Hmm, that did not seem too bad. If it rolled only 90 degrees, but I knew that, I could figure out how much to add and how much to subtract, or I could in that case use the output from the Y-axis gyro that would effectively have replaced the X-axis gyro with respect to the earths orientation or frame of reference. It seemed a bit complicated, but not insurmountable.

Linear Problem?

So, after realizing the need to most likely have to incorporate the Z-axis in any attitude calculations, I did more research. My thoughts going in at the time were that my solution was a straightforward, linear calculation. This was supported, or so I thought, in some of the additional research I carried out. Some of what I read seemed to indicate that if there is enough processing power, that it is a linear problem. However, from a practical point, transformations such as I needed to do cannot be done with microcontrollers and linear math. It requires using estimates or approximations of position rather than actual coordinates - this pushes it for all intents and purposes into a short cut, non-linear math solution.

That is, it is ultimately easier to throw some fancy math at the problem rather than grind through all the calculations needed. I learned that most such attitude coordinate transformation solutions rely on some form of a Kalman filter. Such a filter is a general mathematical construct that evaluates information from various sources and predicts and updates the evaluation in order to calculate an estimate of the actual solution.

I was anxious to throw this line of modified integration calculations thinking over to Bill and see what he thought. I wanted to see how tough this new direction I found myself headed in was going to be. I had seen references to Kalman filters on the DIY Drones web site and figured there was some code out there that I would be able to adapt, so, I was still not completely discouraged. I also figured that since my tilt project was really simpler than what I was reading about, I still thought that maybe my situation was a linear, less complicated problem.

I sent Bill an email, describing my view and asked if it was indeed a relatively straightforward linear problem as I perceived, or if it were subtler than that. Disappointingly to me because of the implications to my project, Bill answered that it was indeed subtler. I should have known right?

Fortunately though, Bill also said that he had something he thought would help. Thinking back now, he was probably grinning a bit as he wrote that, having been through these type issues ages ago.

Direction Cosine Matrix - DCM

The Kalman filter is probably the most common approach to use for coordinate transformations. Another approach to the problem is the rotation matrix, or direction cosine matrix (DCM). The heart of the UDB’s attitude orientation system is the DCM, which Bill developed and adapted a few years ago with help from Paul Bizard (interestingly, a similar approach was being independently developed by Robert Mahoney about the same time – see reference section).

The DCM is another mathematical construct to keep track of attitude and orientation, but rather than being a general approach like the Kalman filter, it is designed specifically for tracking rotation. Because it is specific to the task, it is very effective and efficient. Therefore, the computations are fewer and easier for the microcontroller to process. There is extensive background material included in the reference section at the end of the article on Kalman filters and the DCM. Another advantage is that the DCM is not subject to some “singularity” solutions that cause some implementations of the Kalman filter to be somewhat troublesome.

DCM Block Diagram

In his reply to me, Bill offered that obtaining the X and Y angles I wanted from the existing calculations being done by the DCM-based UDB firmware was straightforward and that he could help me easily derive them. I worked with Bill and revised the UDB firmware accordingly. Soon I had a working gyro-based tilt meter!! In April of 2010, after nine months of work, I had the solution.

After working with me to adapt the firmware, Bill offered another insight. He made me realize that by monitoring X and Y for plus and minus tilt (i.e., right-left, front-back), I would actually be creating a “boxy” envelope rather than a true uniform tilt meter. What I needed was something that monitored the tilt orientation off the Z-axis, rather than monitoring X and Y. If I could do that, I would indeed have a true tilt meter with a cone-shaped Z-axis envelope instead of the boxy-shaped X and Y envelope. A few more emails, a bit more programing, and I had a working, gyro-based, true cone-shaped tilt monitor – the RockeTiltometer^TM!

The Coast Optimization System - COS

So, now that I had a sensor to monitor tilt, how to I put it into action?

  Single Axis Yaw Gyro

I had been using a standard UDB to develop my variation of the firmware. I had decided finally to go with the Analog Devices gyros for my project. They were more expensive that the Invensense ones, but Bill and I both thought they would ultimately make a better choice, so, I planned to replace the standard gyro breakout boards on the main UDB board with the AD gyros. Fortunately, SparkFun makes a breakout board for the ADXRS614 gyro. The pinout is a bit different than that of the ST Electronic gyros that are standard for the UDB, but since they are both single-axis yaw rate gyros, they can be made to fit and work just fine. I was planning on unsoldering the three standard gyro breakout boards and adapting three ADXRS614 breakout boards to replace them.

                         Standard UDB

             ADXRS614 Gyro w/ Modified Header

                                                            Modified UDB w/ 3 each ADXRS614 Gyros

As it turned out, SparkFun also makes the UDB boards for Bill Premerlani. It just so happened when I was working with Bill on my project, that he was in the middle of doing some research with some other new gyros for the next iteration of the UDB, so SparkFun had sent him a batch of boards without the standard gyros mounted.  Bill sent me one of the gyro-less boards. With a bit of guidance from Bill, I was able to modify the breakout boards and the UDB in order to supply them with a 5 volt feed rather than the designed 3.3 volt feed. With a modified header, they fit just fine and I was shortly in business with an ADXRS614 sensored UDB! I added a uLog data logger from SparkFun and mounted the components onto a fiberglass coupler bulkhead plate so the system could fit into my sustainer avionics bay.

Analog Devices-gyro-based UDB with uLog^TM Data Logger

What I did then was to insert the modified UDB in between two separate flight computers, a Featherweight Altimeters’ Raven and a G-Wiz Partners’ HCX. The Raven was already acting as the secondary dual-deployment flight computer in the sustainer, with the HCX as the primary. I then used the Featherweight Interface Program (FIP) to configure the Raven’s remaining two pyro channels to send signals to the UDB gyro-computer - one of the Raven channels signals launch-detect and the other signals its verticality-check.