Note: This is Part 2 of a series of articles on the development of the RockeTiltometer...
Envision tilt detectors placed in the avionics bay of a rocket sitting on the launch pad. You are facing the rocket, which is perfectly vertical, and looking straight ahead to the north. Though there are no pre-defined absolute model rocket coordinate reference systems, for purposes of illustration, we will refer to the axis that runs through the rocket from south to north as the X-axis, and the one that runs through it from east to west as the Y-axis. The Z-axis of the rocket runs through the middle of it from top to bottom. This will be our rocket’s X, Y, and Z coordinate frame of reference, and it is for our purposes defined with respect to the earth. So, with our rocket sitting vertical on the pad, we are arbitrarily defining that the rocket’s and the earth’s two reference systems coincide…we will discuss those frames of reference in more detail later on.
Aircraft Coordinate System
I ordered the Rieker tilt meters to trigger an output whenever they exceeded 15 degrees of tilt. I placed two of the one-axis Rieker sensors one atop the other and rotated one by 90 degrees. So now I had a two-axis, X and Y tilt meter that gave me an output signal whenever the tilt exceeded the 15 degrees in any direction (or so I thought at the time). My idea was that once the angle of the rocket became 15 degrees from vertical, or, if the vertical-sensing flight computer triggered its output channel, I would trigger sustainer ignition. My thinking changed over time, in particular the use of the tilt angle as an abort mechanism rather than a trigger mechanism, but I will explain all of that as we continue to work through my learning process.
I discussed my plans with a physicist friend of mine. I explained to him what I was doing. He asked me to explain the specific technology that the Rieker units were based upon. I did not know exactly so I went to the Rieker web site and deduced (never confirmed) that the devices contained a upward-pointed curved tube running along the orientation axis with some viscous substance to dampen out the travel of a ball that would travel inside the tube and cause something to trip once the prescribed angle was reached. He thought about things for awhile and made me realize that during the period of interest, i.e., coasting, the sensors would be experiencing negative gravity - as soon as booster burnout occurs, the positive g force the rocket was under quickly switches to negative g. The ball then, rather than staying in the bottom of the tube, as it should, would be floating up (think of yourself floating in a falling elevator whose cable had become unattached) and very prone to travel up the curved tube as soon as the slightest tilt occurred. That is when a serious recognition of the role of gravity began to enter the picture.
My first thought was ingenious (or so it seemed for a moment!) – just invert the Rieker sensors so that the tube would be re-oriented into the proper position for negative gravity. We thought about this for a while and came to realize that mechanical technology similar to the Rieker units would be troublesome at best.
Even while I was struggling with identifying a sensor to use, I knew that eventually I would have to somehow be able to actually use the output of whatever sensors I decided on. I started thinking about how to do that. I knew I would have some electrical output from the sensors. I was very familiar with electro-mechanical relay logic, but also knew that mechanical devices in a high g environment were prone to failure. I started thinking about using solid-state digital logic devices and at first thought I would use solid-state relays, but then I thought maybe solid-sate logic could work, particularly since I only had a few outputs to deal with. I was only slightly familiar with transistor-to-transistor logic (TTL), but assumed I could figure it out. I read about the various configurations of the available chips and then ordered a bunch of AND, NOR, and NAND chips.
Before I could get too far into the TTL stuff, I stumbled across the Parallax web site and saw that they offered a tutorial starter kit for microcontrollers. A microcontroller is a device that includes a microprocessor (a small version of the microprocessor in your home or office computer) along with other embedded peripheral devices such as input and output ports, power regulators, and memory. I knew of microcontrollers for a long time, but always thought they would be far too complex to learn. But now I had a mission that seemed to be a perfect fit for such a device, so I thought I would try to learn how to use them. I ordered one of the starter kits and quickly was immersed in the tutorial.
As it turns out, microcontrollers are fairly straightforward. I had a basic understanding of electronics and had done a bit of programming at various times in my life, so it was not too much of a stretch to combine the two and become familiar with the microcontroller. After going through the exercises in the book I felt relatively comfortable doing the simple things I thought I would need for my project. Later on, I took a Saturday morning microcontroller course at the local junior college to get a more in depth experience.
Simply stated, the microcontroller allows you to take various inputs from sensors, set up some programming to deal with what you sensed on the inputs, and then control output devices based upon those decisions. Perfect for what I needed to do to combine the vertical-sensing flight computer and my tilt meters and output a signal to the flight computer for motor ignition!
One of the exercises I came across while learning the Parallax BASIC Stamp microcontroller was an experiment using an accelerometer to sense tilt! Now that’s what I’m talkin’ about! Wow, something handed to me on a platter! The sensor device used in the exercise was a Memsic 2125 2-axis (X and Y) accelerometer that used a temperature differential inside a closed chamber to sense changes in gravity to its orientation. I started thinking that maybe this was the answer to the concerns about the mechanical “rolling balls in a tube”, since this sensor seemed more “solid state”.
I assembled the MX2125 circuit, copied and revised the code a bit, compiled it and downloaded the code into the microcontroller. The essential code was provided thankfully in the exercise. It used changes in the sensor output as the gas ball traveled along the walls in response to the tilt I applied to the chip. The code included the trigonometry calculations to develop the angles from the change of values presented at the chip output. It worked great. I set it up to trigger an LED whenever the absolute value of the tilt angle exceeded 15 degrees on either the X or Y-axis. Thought I was home free!
About this same time, I was at a ROC launch in Lucerne Valley prepping my 2-stage for a test flight. A fellow wandered over and watched while I was assembling one of the Roush Tech CD3 CO2 charges I was using for deployment. I mentioned that I was investigating maximizing the coast interval and told him about my Rieker units and the Memsic accelerometer-based tilt meter I had recently created. He paused for a moment and shook his head. I asked him what was wrong. His reply was that any sensor that is affected by gravity would not work. I was busy trying to get launched before the winds came up so his comment did not fully register at the time. Later, when discussing the topic again with my physicist friend, he had come to the same conclusion.
The problem gets back to the two different frames of reference I mentioned previously – the rocket’s coordinates and the earth’s coordinates. When the rocket is sitting on the pad vertical, the two systems are aligned. It is the earth’s frame of reference that is important, since it is in that frame of reference that tilt has its basis – i.e., the 15 degrees of tilt that is of interest is in the earth’s frame of reference relative to the Z axis (verticality).
Once the rocket leaves the pad it loses its physical reference to earth. If it has a sensor on board that can sense the gravity vector that it felt while it was sitting on the pad, it would still know whether it was vertical or not. However, once the motor ignites and the rocket lifts off, it is under a g force that exceeds 1 g (earth’s gravity). Any sensor that is monitoring gravity will lose any sense of the earth’s pull and its associated reference – the sensor cannot distinguish the difference between gravity and acceleration. Therefore the tilt in the earth’s frame of reference cannot be measured any longer. And, the converse is true – when the rocket reaches motor burnout the rocket is weightless for an instant and begins to experience negative g, the same phenomenon occurs but in the reverse. Unfortunately, even my thermal-based Memsic accelerometer is affected in this way. Hmmm…I was back to square one. This was getting harder all the time!
So now what? What other sensors could I try that would not be affected by gravity? I knew a bit about magnetometers and had seen some ads for the Transolve Flux Capacitor that relied on a magnetometer to sense apogee.
Transolve Flux Capacitor
Magnetometers. My physicist friend was very familiar with magnetometers and after realizing the issue with accelerometers, had come to the conclusion that magnetometers might be an ideal solution. The magnetic flux lines that extend from the earth are very stable and fairly easy to read. The problem with them is that they are very weak in magnitude and subject to interference from any nearby metallic influences – such as a long metal launch rail!
Anything that can influence the magnetic reading can be calibrated out if its influence is constant – e.g., if you house the sensor in an avionics bay with steel connecting rods, the magnetic distortion caused by the rods can be deducted from the reading effectively canceling out the rods’ influence - they always stay in the same orientation relative to the magnetometer. However, the launch rail is there while the rocket is sitting on the pad, but once it is launched its influence goes away. This makes the problem of dealing with a magnetic sensor a bit troublesome. But, it became a clear candidate in my mind at that point. You could after all, calibrate the sensor away from the pad just prior to launch, load the rocket on the rail, then when it lifted off the calibration you did would take effect.
GPS. GPS sensors also came to mind, but the resolution afforded does not really match up to the requirements for a rocket moving so quickly in such a small relative flight path footprint. I discounted use of a GPS sensor fairly quickly.
Gyros. Having been a jet fighter crew chief while I was in the Air Force in the late 60’s and later getting my private pilot’s license, I was aware of gyroscopes, but my vision at the time of gyroscopes was that of a huge spinning ball, and a very expensive ball at that. I quickly discounted gyros at that point too.
I was clearly running out of options.
Thermopiles. I did some more research on line and found several references to “level sensors”, inclinometers and tiltmeters, but once again, they all seemed to be based on accelerometers or balls-in-a-tube or similar gravity based sensors. Then one day after continually changing the arrangement of my search words in Google, I came across a reference to “thermopiles” being used to sense the horizon by contrasting the sky’s IR signature with the earth’s. I eventually was drawn away from using the thermopiles and never really explored them for a couple of reasons. For one, it did not seem that the thermopile sensors would give me the accuracy or preciseness of angle that I wanted. Additionally, it was recognized that the thermopile sensors did not work very well under a cloudy sky.
IMU. One of the references I saw on the internet mentioned something called an IMU to replace the thermopile sensor. Seems that it was difficult to fly the autopilot when it got cloudy, or when they had to come inside if the weather was bad - obviously a horizon sensor was not much good in those environments.
What’s an IMU I wondered? I seemed to remember something about IMU’s mentioned while I was watching some programs on smart bombs and cruise missiles. Off to Google again!
An IMU is an inertial measurement unit. It usually uses combinations of sensors to determine changes in a vehicles orientation. The sensors are typically accelerometers, gyroscopes and magnetometers. How many sensors incorporated into an IMU is referred to as its number of degrees of freedom (DOF). For example, if you have an IMU with accelerometers for the X, Y and Z-axis and a same number of gyroscopes, you have an IMU with 6 degrees of freedom, commonly abbreviated as 6DOF. Add three axes of magnetometers and you have a 9DOF IMU. Using the IMU to transform the vehicles orientation to the earth’s orientation turns an IMU into an AHRS – an attitude/heading reference system. Now I seemed to be getting somewhere!
Some of them appeared to output only the rate of rotation from the gyros (IMU), while others actually output Euler angles or vector references. One of my favorites among the more sophisticated ones is the VectorNav VN-100. The VN-100 is a great, 9DOF IMU/AHRS with an easy to use interface. As all the technology involved in getting to where I wanted to go got more and more complicated, discovering these all-in-one devices started me thinking it might be a lot easier to just bite the bullet and order one that output angles already – I would be nearly done!
VectorNav VN-100 IMU/AHRS
But, they are very expensive (for good reason, as I would better learn later on). I thought I should be able to come up with what I needed relatively easily using a couple of gyros. I did not need all the sophisticated sensor systems offered. All I needed were angles. Gyros were designed to sense rotation and be integrated into angles, right? I should be able to grab a gyro, do a bit of coding, and develop my own tiltmeter! Seemed easy enough and the individual gyros were not terribly expensive.
To be continued in Part 3...