I thought I would have to do some voltage conversion on the output of the Raven pyro channels to properly interface with the spare digital input/output channels on the UDB. However, I quickly realized that when the Raven pyro channel fires, its FET is taken to ground, so it was a simple matter to common the grounds on the Raven and the UDB and configure the UDB inputs as active-low. Then, whenever the Raven channel fired, it simply brought the UDB input low and signaled the Raven event to the UDB.
The UDB receives the Raven signals and uses them in the following ways:
1) Launch-detect: when the UDB is powered up, it actually utilizes 6 degrees of freedom – X, Y and Z accelerometers and the X, Y, and Z gyros…the accelerometers are used to measure the earth’s frame of reference and correct for any gyro drift…while powered up on the pad awaiting launch, the accelerometers continually keep the UDB’s orientation properly aligned and give the gyros their frame of reference.
For reasons covered earlier, at launch the accelerometers lose their value as orientation references since the earth’s gravity at 1 g is so overwhelmed by the rocket’s 5 – 30 g acceleration during motor burn.
The Raven detects launch by invoking an algorithm that signals whenever it senses acceleration greater than 3 g that integrates into a velocity that exceeds 3 MPH (this allows the rocket to bounce around a bit on the launch pad from gusts of wind.
When the UDB receives the Ravens launch signal, it effectively turns off the influence of the accelerometers in the DCM calculations and the gyros become the sole source of orientation reference. The gyros will begin to drift, but the drift during the relatively short period of interest (while the rocket moves from the launch pad to a point of motor ignition, say 10 to 30 seconds) is not significant enough to materially affect the DCM calculations.
2) Verticality-check: the Raven’s verticality-check trigger is constantly monitored by the UDB through another input channel and compared to the UDB’s ongoing angle calculation – if the critical angle off the Z-axis (the value is pre-programmed), e.g., 15 degrees, has not been exceeded when the UDB sees the verticality check signal from the Raven, the UDB will signal the HCX via its user-programmable input channel and fire the sustainer motor ignition.
If the Raven verticality signal is received and the angle has been exceeded, ignition is inhibited, i.e., sustainer motor ignition is aborted.
The logic contained in these steps allows that if the rocket’s angle has gotten too far past vertical, we would rather not ignite the sustainer motor and have the rocket just return for another attempt. The purpose of the system is to maximize the coast period in an effort to maximize altitude. Therefore, rather than waste an expensive motor that is simply going to go “sideways”, we would rather save it, have the rocket deploy back to earth and make another attempt after whatever corrections are needed to the rocket configuration.
As a tremendous side-benefit not initially on my radar at the start of my journey, is that in the event of an adverse attitude flight where the tilt angle is significantly off-axis and poses a safety threat, ignition will be inhibited by the system!
I flew three test flights of the RockeTiltometerTM/COS (May/June 2010) including at LDRS 2010 at Lucerne Valley, and the results were all that could be expected. All of the circuitry worked well and the firmware/software performed properly, including the ability to easily change the critical tilt envelope degree window.
There is no specification for the ADXRS gyro in regards to the maximum g load under which it will continue to operate. The specification includes a linear acceleration error and a maximum-g shock number, but nothing that indicates a maximum operating limit. In anticipation of utilizing the COS on a flight at BALLS 19 at Black Rock, Nevada, in the fall of 2010 where the number of g that the rocket would see exceeds 22, I wanted to be sure it would continue to operate well under those conditions. One of the test flights was flown as a single stage with a J1520 VMax motor to give it a pretty good ride. The gyros saw a g factor during that flight of over 21 g and all the data readings indicated that it performed perfectly.
I flew that planned flight at BALLS 19 in September of 2010. The rocket I flew was named Hermes 8, Mark III, and it housed the prototype RockeTiltometer and the Coast Optimization System (COS). The booster contained a Cesaroni N5800 C-Star and the sustainer a Cesaroni M2020 I-Max. My RockSim simulation predicted a 50K’+ flight.
Liftoff was great, but shortly afterwards the rocket started arcing over, finally breaking up at about 2,000’.
Though the flight was an obvious disappointment, the COS wound up saving my sustainer motor to fly another day. Since one of the parameters I had programmed into the Raven flight computer as a condition of ignition never came “true”, ignition was aborted. I had included a test that the rocket was above 16K’. Since it never achieved that altitude, the Raven never sent an ignition signal to the RockeTiltometer. In addition to the expense of the motor reload kit (~$370 retail) that was saved, the end result was much safer than it could have been if the motor had been tied to a straight timer for ignition. With the adverse event happening so close to the ground and the wild nature of the airframe sections at that point, motor ignition could have been a serious threat to the spectators.
On a better note, I altered the motor configuration to allow for the lesser waiver height allowed at Plaster City, CA for the annual Plaster Blaster event held in November of 2010.With an upper limit of 25K’, I used the saved BALLS M2020 sustainer motor in the booster and put an L995 in the sustainer, with an expectation of exceeding 20K’ if all went according to plan. Well, it did!
Hermes 8, Mark II, reached an altitude of 22,299’ with a coast time between booster burn out and sustainer ignition of about 11 seconds. When the Raven saw all the other pre-programmed conditions “true”, as it decelerated through 400 fps, it sent an ignition signal to the RockeTiltometer. Since the tilt was well within (9 degrees) the 20 degree envelope for which I had configured, when it received the ignition signal from the Raven, it in turn sent an ignition trigger signal to the G-Wiz HCX which then fired the ignition pyro channel and the L995 ignited. A great flight.
So, two different experiences, but in both cases the COS worked to perfection - very satisfying results and a nice payoff for the months of effort.
RockeTiltometerTM and RavenTM comprising one version of an integrated Coast optimization System (COS)
I then developed the next generation of the RockeTiltometer and the COS by fabricating a new printed circuit board which sits atop the UDB. The board has an interface for the Raven flight computer and the data logger, as well as a separate igniter FET circuit. Interestingly, the latest UDB has moved over to the Invensense gyros and as expected after our earlier tests, they work very well for our application.
So there you have it – a many-month long journey of exploration, learning, mistakes, frustration and ultimate joy. It was a great journey that had surprises at almost every turn.
Abort or Ignite? Along the way, I considered other information that might be helpful coming from the UDB. For a long time after deciding to pursue a tilt meter, I debated whether it should be used as a trigger mechanism for sustainer motor ignition, or as an abort mechanism, or possibly both. It seemed to me that the rate at which the angle was accumulating could be used to determine if I should trigger ignition or abort ignition. The faster the rate of increasing angle change as the rocket approached the edge of the angle envelope I had programmed into the UDB, the more likely it was that I should use it to abort the ignition. If the increase in angle was slight, and the Raven verticality check had not yet triggered, I thought that I could use the edge of the angle envelope as an ignition trigger. I discussed this with Bill and he was able to show me how the DCM could be easily used to monitor the rate of angle change. Once I have more experience with the basic tilt-ignition process, I likely will incorporate such monitoring.
Vertical Steering System I also early on recognized the desirability of using the UDB for vertical steering. I envision further adapting the UDB’s stabilization mode (it incorporates stabilization as well as navigation for its UAV function) to control servos that will be attached to what I call canarderons. Elevons on an aircraft combine both the function of elevators and ailerons. In a similar fashion I imagine two forward control surfaces that appear to be canards, but are able to articulate like elevons do.
[I noticed a while back a reference to a research paper by young Brian Guzek entitled Active Stabilization Flight Computer, wherein he proposes a vertical steering system, but suggests using articulated nozzles for the steering mechanism.]
Stabilization Roll and Aerobatics The UDB already has servo outputs to work the control surfaces of an unattended remote-control airplane. The firmware of the UDB needs to be modified only slightly to allow the elevon logic to apply to the canarderons. The trick will be to have a very high resolution of control (fine, precise mechanical advantage) over the canarderon surfaces due to the relatively extreme speed of the rocket compared to an airplane. A further extension of this principle would be to have the canarderons slowly roll the rocket around the Z-axis in order to help stabilize its flight path. Rocket aerobatics are even possible, such as increasing and decreasing barrel rolls as the rocket climbs into the sky!
Recovery Steering Another application that suits an adaptation of the UDB is as a recovery guidance system. You have access to servo controllers. There is also an input for a GPS receiver and firmware available for the UDB GPS reads (normally used for navigation assist). How about taking a GPS reading at the launch pad; then when the rocket deploys for recovery, deploying a parafoil type chute that has a servo/pulley steering system coupled into the GPS signals. The pulleys tug on the steering lines of the parafoil and bring the payload back to the launch pad GPS coordinates – all the basic GPS and navigation software already exists in the UDB firmware – all you really would need to do is figure out the servo/pulleys mechanics!
“A Guide To Using IMU (Accelerometer and Gyroscope Devices) in Embedded Applications”, Starlino, http://starlino.com
J. Geen, D. Krakauer, “New iMEMs® Angular-Rate-Sensing Gyroscope”, ADI Micromachined Products Division, Analog Devices www.analog.com
W. Premerlani, P. Bizard, “Direction Cosine Matrix IMU: Theory”, May, 2009
R. Mahoney, T. Hamel, J. Pflimlin “Nonlinear Complementary Filters on the Special Orthogonal Group“, IEEE Transactions On Automatic Control, Vol. 53, No. 5, June 2008