Logic level shifter

The Arduino normally runs at 5 V. The pressure sensor and accelerometer run at 3.3 V. The sensors could be damaged by 5V. What to do? Use a "logic level shifter"! It converts between 3.3V and 5V signals (bi-directional), so it works well with the I2C protocol.

The logic level shifter board hangs off the end of the 17 row mini bread board, hence the cluge of gator clips for this checkout (note to self: if ever make perf board or PCB include at least 20 rows). Also pictured is Arduino and Fritzing running on Ubuntu (an open-source hoe-down!).

Accelerometer

I have added an ADXL345 accelerometer for the reliable detection of launch. This sensor is over-kill for this simple function, as it has 3 axis sensing, and I am only using one (I might eventually figure out something to do with the other 2 axis). The launch detection criteria is now exceeding 2g (1g acceleration + 1g gravity) in the vertical direction. Since the launch acceleration should exceed 20 g almost instantaneously, launch should be easy to detect. Also, since the unit is intended to be powered up only when on the pad ready for launch, usual handling should not exceed 1g (causing a false launch detection).

The programming was much easier than I had feared, due to the availability of libraries for this sensor. It uses the same I2C bus as the pressure sensor, and the same 3.3 V supply from the Arduino, so it was easy to integrate. The accelerometer and pressure sensor breakout boards fit side by side (although rather snuggly) on the 17 hole row mini-bread board.

Schematic

Here is a schematic of the flight computer done in Fritzing.

I am just learning Fritzing, so it is a little crude. The batteries are actually AAA, and in one pack, but there were standard AA pack graphics available in Frizting. Also, I used a mini bread board, but Fritzing had a standard bread board available. But even a beginner like me was able to do a serviceable schematic fairly quickly, including making my own SparkFun 09694 BMP085 breakout board graphic in Inkscape.

Prototype flight computer

The "prototype" is "complete"!


I say "prototype" because I may not get around to building a next version. This has a cardboard structure that I had originally intended to be a non-flight prototype only for dry fitting parts (the flight version to be build out out foam-core), but it seems "good enough", so it may be the flight version.

Visible in the photo are the Arduino Uno, the servo, a mini breadboard with the BPM085 pressure sensor, and to the extreme right a sliver of the parachute (white, stowed). The bent paper clip is a pin that holds the door closed, and the servo pulls it out to allow the parachute door to open. The blue rubber bands push out a plate to force the parachute out. Not visible is a 4 AAA battery pack that supplies the power. The components are lashed onto the cardboard structure with fishing line, which worked surprisingly well. There is a switch, accessible through the open parachute door, that allows turning on and off the power. The USB cable can also be inserted into the Arduino for downloading recorded data through the open hole in the top (the USB cable is just stiff enough to insert without a long nose pliers).

The entire assembly has 175 g mass. This replaces a 20 g "gravity" deploy system, for a net gain of 155 g.

I say "complete" as it is probably ready for a flight test. I have run many tests, carrying it up my one flight of stairs to verify that it detects "launch" (a 1.8 m altitude rise), and "descent" (a -1.8 m change), deploys the parachute as expected, and records data. It has also survived a 3 m drop test (the height of my modest stair well) with no damage.

The Admiral Gorshkov

Our basic water rocket is named after Admiral Sergey Gorshkov, who is credited with the phrase "'Better' is the enemy of 'Good Enough'" (wikipedia). And our rocket certainly could be 'better'. The beat up fins are evidence of the many hard landing and water soakings while "fueling" that The Admiral has had. It had many flights with a "gravity" parachute deployment system (basically a cap that was meant to fall off at apogee). Out of ten flights, the gravity deployent system worked three times (not an impressive record). Other people have been able to "tune" their gravity system to a better success rate. We shall see if the Arduino based flight computer does any better. (The picture is with the prototype Arduino system, more on that later...)

Parachute Deploy Logic

The parachute deployment logic uses two criteria: 1) time since launch=6 s, and 2) time since apogee=1 s. The first of either of these criteria to come true will deploy the parachute. There was some rationale to selecting those values.

The parachute should be deployed after the rocket has reached maximum altitude (apogee), but before striking the ground. The ideal time is not necessarily exactly at apogee, however, as the rocket can drift considerably during descent on the parachute (and there is less drift in regular flight). So, a balance of timing is reached between these two competing desires.

It is also desirable to not deploy the parachute at a high air speed, as this increases the loads (and could result in the breaking the lines attaching the parachute to the rocket). And the parachute should not be deployed before the rocket has reached maximum altitude.

The water rocket flight time and altitude profile may be estimated from online calculator such as Dean's Benchtop: Sim Water Rocket. For a 200 gm total empty weight and a typical “propellant” load (100 psig initial air pressure, 50% water fill), a 2 liter water rocket may reach a height of 77 m in 3.47 s. If the parachute is not deployed, it will reach the ground at 8.05 s total flight time, impacting at 26.5 m/s. So, why not just use, say, 6 s after launch as the parachute deploy time? This is roughly half way between predicted apogee and touchdown (without the parachute deployed).

The simulation assumes that the rocket goes straight up. With no wind and a stable rocket design this is a fair assumption. However, with wind (or a not so stable rocket, due perhaps to some mishap during launch), the rocket does not go straight up. This can reduce the maximum altitude attained and the flight time before touch down (a euphemism for impact, if the parachute does not deploy) to less than 6 second.

Also, different simulators use different assumptions (particularly about drag), and predict different apogees and flight durations.

One web site Water Rocket Safety Rules recommends “a recovery system which limits their descent rate at time of touchdown at ground level to a maximum velocity of 10 meters/second (33 feet/second).” This was used as a guideline for picking the logic for the parachute deployment 1 s after apogee. The rocket can accelerate downward at at most 9.81 m/s^2 (gravitational acceleration, neglecting drag), and in 1 s it reaches a maximum fall rate of -9.81 m/s (just under the 10 m/s maximum touch down velocity limit). This also keeps the air speed a time of parachute deployment to a low value, reducing the loads on the parachute strings.

If the rocket had a sub-normal launch and only reached 4.9 m height, it would impact at at most the 9.81 m/s speed (neglecting any lateral speed). If it reached a higher apogee, there would be time for the parachute to deploy and decelerate the rocket.

Unfortunately, this criteria does not limit the drift very much while descending on the parachute. The rocket descends only 4.9 m from apogee in 1 s. I suppose a more complex logic could calculate the maximum height above ground (apogee) attained, and deploy the parachute at some distance above ground (perhaps 20 m, verifying that apogee was great than this), but I have not implemented that yet.

Why include the 6 s launch time criteria at all? For a nominal flight, the rocket would reach the 1 s past apogee criteria before the time since launch criteria. However, the ability to sense launch is viewed as more reliable (and may be augmented in the future by an accelerometer), so this is provided as a back-up if sensing apogee is not accurate. Some parachute deployment devices use time since launch as the criteria (such as ), so it is a proven logic.

The time since apogee is a fixed value, if the goal is to stay under the 10 m/s fall rate. The time since launch criteria would ideally be variable, to account for different expected performance (due to initial pressure, water load, weight, etc.). This value can be changed by reloading the program (although that might be challenging to do at the launch site).

While this logic is intended to deploy the parachute at an altitude that will effectively limit the ground impact velocity, there is no guarantee that it will actually deploy effectively. So, launch only in areas large enough so that uncontrolled impacts will not be hazardous, and have all persons in the area aware that a launch may occur.

Flight Computer Functions

The flight computer shall:
- record the flight track time and altitude
- deploy the parachute

As the Arduino can readily interface with a pressure sensor to infer altitude, a servo to deploy the parachute, and has built in non-volatile memory it is well suited to this project.

An Uno has 1K of non-volatile memory, which is a little limited for data logging. However, this allows 250 time and pressure readings (at two bytes each) to be recorded. If more memory is needed, a memory card can be added.

A typical water rocket flight lasts roughly 60 seconds, most of that descending on the parachute. So, this would allow approximately 0.25 second data recording intervals, if recording starts when launch is detected. This will not yield much detail about the initial acceleration, as most of the "propellent" is consumed within 0.25 second.

The Uno has 32k of program memory, which should be plenty.