Archive for category Rockets

My God, it’s full of… disk drives!

What’s going on with the X-37B?

X-37B (USAF photo)

read today that the USAF has launched one again, on, I think, the 3rd flight.

What is unique about this vehicle compared to most other space systems is:

  • It’s reusable and returns to Earth (lands on a runway, ala the Space Shuttle)
  • It has a long on-orbit dwell time (270 days was supposedly the spec, with the second flight lasting 469 days)
  • Some significant amount of on-orbit delta-v for orbital maneuvering
  • Payload capacity “similar to a pick-up truck”

What is this thing for? The government has been strangely silent about its purpose, leading to a lot of random speculation, none of which makes any sense to me. The only thing they’ve said is:

“The X-37B is a risk reduction vehicle for space experimentation and to explore concepts of operation for a long duration, reusable space vehicle.”

I’m sure that’s true to some extent, but I’m sure that’s not all that is going on; otherwise why all the hush-hush?

Some of the theories I’ve seen claim that it’s:

  1. For spying on the Chinese manned space program
  2. For spying on random spacecraft in orbit
  3. Some sort of on-orbit anti-satellite weapon
  4. For repairing satellites in orbit
  5. A ground-attack (or ICBM interception) weapon (rods-from-god or similar)
  6. An orbital bomber
  7. For stealing satellites, like in You Only Live Twice
  8. Some professor at the Naval War College said “the Air Force has always wanted a crewed space plane, and this was the closest they could get”.

None of those make sense. One at a time:

1 and 2 – Spying on other spacecraft

The DoD is already pretty good at pointing ground telescopes at spacecraft in orbit. Remember they offered to check out Space Shuttle Columbia’s missing tiles back in 2003? Matching orbits and a close approach to an opponent’s spacecraft would be tremendously provocative (it’s not as if you can do it secretly), and how much more can you really learn by looking at a spacecraft up-close vs. from a distance anyway? Not enough to justify this doubtless hugely expensive program, I’m sure. If despite that, you really want to do this, you don’t need a vehicle that can land. As for spying on the Chinese manned space program, why would that be of any interest at all? (Besides, it’s been in the wrong orbit for that.)

So I don’t buy those explanations.

3 – It’s an ASAT weapon

So why does an ASAT weapon need to land? No matter how much the thing costs, it’s got to be cheaper to just build and launch a new one every so often than land it, refurbish it, and re-fly it.

4 – Repairing satellites in orbit

That’s crazy. Maybe if it were manned; if that’s what you want to do it’d be way cheaper to fly repair techs on a SpaceX Dragon. And what possible purpose would there be in having the repair-bot sit on orbit for a year, or have the capability to land?

5 – Rods from God

Again, no need for such a thing to land. If you really want to build that, sure build it, but why complicate things by having it land? Makes no sense.

6 – Orbital bomber

First, that would violate the Outer Space Treaty. I can see people wanting to get out of that treaty, but I think the US would do so explicitly rather than in this not-very-sneaky way. But, again, why does it need to land? Maybe you can make a case that the USAF doesn’t want to leave nukes on orbit forever – they want a way to get them back eventually. But there are many simpler ways to accomplish that – it can de-orbit the warhead with a parachute (ala Corona, as well as the whole Apollo program), they could plan on a future OTV or manned spacecraft to collect warheads in 15 years, etc. Plus, who needs another way to deliver nukes anyway? The Soviets are not coming back, and the Chinese only want to sell us stuff.

7 – Pac-Man (waka waka)

Snatching someone else’s satellite out of orbit would be an act of war. And difficult, because you don’t know where it’s CG is or how much damage it’ll take by being bounced around on re-entry. And why do you need your snatch machine to sit on orbit for a year? You can always just launch it when you need it.

8 – Manned spacecraft wannabe

Except they already built the full-size version (that flying pink elephant, the Space Shuttle), and this one doesn’t carry anybody. And a Dragon will be way cheaper, and NASA is already funding that. Not to mention Orion (oops… too late, I mentioned it. It’ll probably never fly anyway.) And, of course, they’ll have trouble getting even one brave soul to sit in a space the size of a pickup truck bed for a year (let alone finding room for oxygen, water, and food for that duration).

So what’s it for, then?

OK, here’s my theory. It’s a spy satellite full of disk drives.

The payload bay has some sensors, probably high-resolution cameras; maybe other things too. The rest of the payload is disk drives.

The X-37B collects data (pictures, maybe sigint, maybe other things), and stores it on the disk drives. Every so often it changes orbits in order to be able to look at some particular thing at particular times (or just to keep the other guy guessing). Once the disk drives are full (a year or so), or sooner if the data is needed on the ground sooner, it lands.

It lands so that the data on the disk drives can be read off.

Why not just radio the data down? Because there is way, way, too much of it.

Suppose the payload bay is 4 x 8 x 3 meters (roughly a full-size pickup truck bed). That’s 96 cubic meters (96 million cc). A 3.5″ hard drive is 101.6 x 25.4 x 146 millimeters, that’s 377 cc. So there’s enough room for about 250,000 drives. Figure a tenth of that after allowing room for the sensors, power supplies, and cooling (cooling is a big deal in space). 25,000 drives at 3 TBytes each is 73 petabytes. (BTW, that’s about $2.5M worth of disk drives; peanuts for the DoD.)

73 petabytes over a year is 25 gigabits/second. That’s 24×7, including when not over a convenient ground station.

How does that compare with the bandwidth available for a satellite downlink? I don’t know exactly, but the whole X-band is only 500 MHz, as is the Ku band. The Ka band is 2.5 GHz. That’s the whole band. You do the numbers.

[Edit, March 2013: There’s a mistake in the numbers above – a pickup bed is about 4 x 8 x 3 feet, not meters. But on further thought the X-37B is almost certainly using SSDs instead of rotating media, and the density of that is a lot higher. So I think the two mistakes roughly cancel out, without changing the conclusion.]

What can you do with that?

The Earth’s surface area is 510 million square kilometers (about a third of that is land). Let’s assume 24 bits/pixel (you can divide that up into bands as you like). Unless I made a mistake in the math, 73 petabytes is enough for pixels 40 centimeters on a side, of the whole planet.

Or, somewhat bigger pixels, but multiple copies in the disk drives, so hardware on-board the spacecraft can compare old images against new ones, and identify differences. You get the idea.

Makes Google Earth look kinda…lame.

[Disclaimer: This is just a guess; I have no inside info. Just imagination and a calculator.]

Slow-motion rocket videos shot with Nikon J1

On July 7 I shot some video with the Nikon J1 of the joint CMASS/MMMSC launch at the Tuckahoe Turf Farm in South Berwick, ME.

After my generally scathing review of the camera (more for missed opportunity than anything else), I figured I’d give it a chance to show what it can do with high-speed photography – specifically, I wanted to try the 10 Mpixel 60 frames/second mode as well as the 400 and 1200 fps high-speed video modes.

Here is the result:

I put it together in Sony Vegas. The blurry clips were shot at 400 frames/second (240×640 pixels). The blurrier ones are at 1200 frames/second (120×320 pixels). The video is at 30 fps, giving 1/13.3x and 1/40x speed. This video shows the full resolution output by the camera.

(To be pedantic, playback is at 29.97003 Hz (that’s 30000/1001); from what I saw in Sony Vegas, the Nikon actually records at 399.6004 and 1198.8012 fps – which makes an odd sort of sense if you know NTSC.)

As you can see, all the video is lousy. It’s poorly exposed (despite some fixing in Vegas), heavily overcompressed (in-camera) and oversharpened (again, in-camera). The 1200 fps mode is worse than the already bad 400 fps mode. You can’t control it. I don’t blame Nikon too much – the high-speed Casio cameras seem to have similar problems. On the plus side, most of the video was shot at a shutter speed of 1/5000 second, which is neat to do. A couple clips were at 1/10,000th (!).

The video is good enough for some technical purposes, but it’s not a joy to look at.

Finally, you’ll note that none of the clips are at that fantastic, promised, 10 Mpixel resolution (60 Hz). It turns out that although the Nikon J1 will record stills that fast (for 1/2 second), you can’t control the shutter speed while it’s doing it. I didn’t know that until I got there and tried it. The shutter speed it picked (on a reasonably bright day) was so slow that each frame had lots of motion blur in it. So I didn’t bother. Just another needless firmware-based disappointment from the Nikon J1.

I’ve put the camera and lenses up for sale on eBay. Such a shame, Nikon. Oh well – I’m getting excited about the rumors of the new Canon mirrorless ILC system; maybe they’ll do better.

Last flights of rocket glider Autonomy

Back on 28 October I covered the first 3 flights of the “Autonomy” (now “Autonomy 1”) rocket glider.

We flew it six more times, four times on 5 November 2011, and twice more on 19 November. On the last flight I forgot to arm the electronics (sigh)1, so this winter we’re planning to build “Autonomy 2”.

At the moment, the main problem we’ve been having is that the GPS loses lock on the satellites a few seconds into boost, and never regains it during the glide. Without valid GPS fixes navigation is impossible, so this is a major problem.

By way of background – the glider is meant as a way to prove out the navigation and control software for autonomous steered-parachute recovery of rockets; see this post for more details. Fellow CMASS member Boris K. built the glider airframe; I did the electronics.

(This post is adapted from the thread on TRF [more details there].)

Review of first flights

From the logged data in flash, on flights 1 and 3 (the bad ones), the parachute ejection was triggered by the failsafe “TimeToImpact” calculation, well above the 200 foot (60 m) deployment altitude. The rocket decided it was less than 4 seconds from impact while descending at > 30 MPH (13 m/s actually) so it popped the chute, despite still being well above the deployment altitude.

Only on flight 2 (the good one) did the 200′ altitude trigger a flare and then deployment.

Unfortunately, on flight 2 it looks like the GPS signal dropped out partway thru the glide. At first I thought this was because the camera (wrapped in foil) shadowed the GPS antenna, but looking at it again I don’t think that’s it. I don’t know what it is – I haven’t seen this on prior flights (under a parachute).

Also the altimeter data was really noisy – it makes it very difficult to figure out the sink rate while gliding. (See graphs at the end of this post.)

After fiddling on the bench a lot, I concluded that the source of the noise (most of it anyway) is small variations in the power supply voltage (3.3v) caused by load from the servos and radio (which draw on the same battery, but prior to the 3.3v regulator). I could see the altitude readings jump around each time a servo draws current.

Prep for 2011-11-05 flights

In preparation for the 11/5 flights, I made the following adjustments to the glider:

  • Reduced parachute deployment altitude from 60 m (200′ AGL) to 45 m (150’ AGL) to get more glide time.
  • Reduced YAW_FACTOR from 1.0 to 0.1 (100 to 10) to make it less sensitive. This makes the servo response less sensitive by a factor of 10 in yaw – this is the most I think it can be reduced and still have positive control in yaw.
  • Tweaked the port elevon 3 half-turns down to try to trim out gentle left-turning tendency seen on flight 2 of 2011-10-22.
  • Adjusted YAW_STOWED_POSITION from 0 to -1 (50 to 0) to induce a slow roll during boost to counteract any pitch tendency during boost.
  • Adjusted PITCH_STOWED_POSITION from -0.4 to -0.54 (30 to 23) to counteract pitch-up tendency during boost seen in 2011-10-22 flights. I think AstronMike was correct in his suggestion on TRF – this is caused by differential drag on the rudder (hadn’t thought of that – thanks for pointing it out!).
  • Lengthened the flare period from 3.0 to 4.0 seconds.

Most of these parameters can be tweaked on the pad with telemetry commands.

Second set of flights

On 11/5 we flew four more times. All four flights resulted in nice glides; the software tweaks seemed to help a lot. Ascent was nice and vertical, the yaw over-control problem got solved.

Unfortunately, the logged data shows that the GPS signal dropped out – again – after a few seconds on each and every flight.

On flight 1, Boris steered in the “yaw” mode, where he directly controls the yaw input to the servos. We used a “YawFactor” value of 10 (out of 100), so it was 1/10th as sensitive as on the previous flights.

Here is the video (first from the ground, then from the onboard camera):

 

On flight 2 we enabled autonomous navigation. As you’ll see, it overcontrolled a little bit (and because of the GPS dropout, navigation was impossible).

Flight 2:

 

After flight 2, we reduced YawFactor from 10 to 5, making it half as sensitive in yaw. This reduced the overcontrolling in yaw.

One flight 3, Boris steered it in the “forced navigation” mode. Here his knob inputs were used to force the navigation system to choose a steering command – this results in steering updates that are coarser and less frequent than in the “yaw” mode, but it allows the navigation system to learn from the response of the glider. Again, since the GPS didn’t work, the nav system had nothing to work from.

Flight 3:

 

For the last flight of the day we tried a larger motor, hoping for more glide time and more data. We got lots more glide time (a great flight), but again the GPS failure meant no useful data. This altitude (1300+ feet AGL) is about as high as I’d want to go with manual steering – any higher and it becomes hard to see which way the glider is pointed.

Flight 4:

 

The loss of GPS sync was again frustrating.

One possibility was a bad GPS unit – this was a new unit that had only flown on the glider. But it performed fine on the ground.

Another possibility was something about the glider flight dynamics that the GPS firmware can’t handle. The glider flies much faster than a parachute glides, while descending at a faster rate than an automobile normally would. Maybe this confuses GPS firmware that’s tweaked for use in cars.

The last idea I thought of was possible RFI from the camera, despite the foil shielding.

Prep for 11/19 flights

I corresponded with the GlobalTop (GPS maker) people – they said there is a dynamics setting in the GPS chipset I didn’t know about:

Regarding the dynamic conditions, you can execute PMTK command for setting. Our output speed is horizontal speed not vertical speed. Also, we don’t have higher accelerations.
PMTK command:
$PMTK302, MODE
Mode: Dynamics mode.
0 : Default ( fixed status)
3 : Slow Ground Vehicle (tractor, boat etc)
4 : Fast Ground Vehicle (car, train etc)
5 : Airbourne Low dynamics (<1g)
$PMTK302,3*2C<CR><LF>
//
Query Dynamics type
$PMTK402*34<CR><LF>:API_Query_Dynamics

Sure enough, the GPS was set to $PTMK302,0 (default) when I checked, so I changed it to $PTMK302,5 (Airbourne Low dynamics). I also ordered some of their new “PA6C” GPS units (successor to the PA6B I’m using now) – they said it has some features that make it (a bit) more immune to noise (a lot lower power, too).

Separately – I finally found the source of the altimeter noise. I was using the internal AVdd as the ADC reference voltage instead of the external pin. You wouldn’t think it would matter, since they’re both supposed be at Vdd – but it makes a huge difference.

Here are the results from my testing – the numbers are the standard deviation of the altimeter noise, in meters AGL:

The radio draws lots of current (> 100 mA) each time it sends a packet; so I used that as a way to test what happens when something draws lots of current.

AVdd reference, DCDC supply: 0.4 meters idle, 4.0 meters w/radio running
AVdd reference, battery supply: 0.8 meters idle, 5.5 meters w/radio

VRef+ reference, DCDC supply: 0.2 meters idle, 0.36 meters w/radio
VRef+ reference, battery supply: 0.12 meters idle, 0.15 meters w/radio
VRef+ reference, LDO supply: 0.11 meters idle, 0.25 meters w/radio

(I used the battery – 2 alkaline ‘C’ cells in series – as a reference “clean” power source.)

So, as Adrian A. (of http://www.featherweightaltimeters.com/) said on the TRF forum, the LDO supply is cleaner, but only by a little – almost all of the difference comes from using the external VRef+ pin. I think the DCDC supply is clean “enough” once I use the VRef+ pin.

I also swapped out the GPS for another one, that I flew in rockets before (under a parachute) and had worked well there.

Final two flights – 2011-11-19

On the first flight I was optimistic that navigation would work. We flew it first on a ProX G125 because the day was extremely windy and we didn’t really know how that would affect things (we only flew it on calm days previously).

Here’s the flight as seen from the ground:

You can see the parachute ejected but didn’t inflate – it remained stuck in the nose cone. Luckily there wasn’t any damage on landing, but we’ll try to avoid this problem on the next glider.

It did about 400 feet AGL (as expected with that motor), but after apogee it just spun around, because the GPS lost satellite lock about 1.6 seconds into the boost (as expected) but never regained it after apogee (not as expected).

This is extremely frustrating. I don’t know why the GPS loses lock in the glider, but works fine under the parachute. I set the high-dynamics mode (as mentioned earlier) but it seems this didn’t make any difference.

I suppose it’s possible there is some interference from the camera electronics. We didn’t unplug the camera for this flight because I thought it would likely work OK with the dynamics setting. However the GPS works fine with the camera running on the ground.

I just got 5 new “PA6C” GPS units from GlobalTop. I won’t have a chance to fly them before spring, but they say they’re less sensitive to interference than the PA6B I’ve been flying. I hope that fixes it.

We have no video from the on-board camera because we haven’t recovered the glider (and camera) yet – the video is still in there.

This flight did serve as a test of the modified altimeter. The results are mixed. The altimeter readings seem to have much less noise on the ground and during boost, but just as bad as ever during glide.

The graph below shows time (seconds, X-axis) vs altitude (feet AGL, Y-axis) for 3 flights – dark blue is this flight, magenta is the very first flight of the glider (in October, similar motor) and yellow is the 2nd flight of the glider (also in October, obviously on a larger motor):

The rocket collects an altitude reading 25 times/second (every 40 milliseconds); that’s what’s plotted here.

You can see that post-modification (dark blue) there’s a lot less noise in the altimeter up until apogee. But after that there’s still very strong noise – the altitude jumps up/down by as much as 40 feet.

I think that perhaps what I’m seeing here is a ‘whistle’ effect of air blowing and vibrating across the vent hole on the bottom of the glider. If so, it only happens in the glide configuration (which is imaginable). There’s just the single vent hole, but the electronics bay hatch (opposite from the hole) is not airtight. Suggestions for how to rearrange things to avoid this (if indeed this is the cause) will be greatly appreciated.

At the top of the graph is the battery voltage (2 x LiIon) * 100 (in cyan). There are 4 distinct dips – these correspond to current drain from (1) servos driving the elevons to boost position upon launch detect, (2) servos going to glide position at apogee detect, (3) servos going to flare position at 150′ AGL, and (4) parachute ejection current.

For the second (and it turned out, last) flight, we went to a bigger Cesaroni 296H110 motor for more altitude. Here’s the video:

I realized about 5 seconds after the crash that I’d forgotten to arm the electronics before launch. That’s a bad feeling.

With the electronics disarmed, the elevons stayed in the boost position (streamlined) for the whole flight, and the parachute didn’t deploy. It crashed across the Pow Wow river in the swamp. I didn’t see where it ended up, but I know where it is within 30 feet or so. It didn’t seem worth risking pneumonia to wade across the near-freezing river to recover the wreckage, so it’s still there. (Boris thinks it might have landed in the river itself and gotten washed downstream.) Maybe once the river freezes solid this winter I’ll try to recover it.

Here is Curtis Heisey’s photo of Autonomy 1 on it’s last flight:

It looks like I have a busy winter ahead.

  1. This is the 2nd rocket I’ve lost in my rocketry career due to forgetting to arm the electronics. Like everyone, I’ve seen it happen to others too.

    So one of my winter projects is to build a box that will sit next to the launch pad. This will connect to the ignition leads from the LCO, and have a relay inside, with the motor igniter connected to the relay. The relay will not close unless the box gets a radio message from the rocket saying that it’s armed. I should have done it long ago.

MTK ($PMTK) GPS command summary

I’ve been collecting a summary of the proprietary extension commands for NMEA GPS modules based on the MediaTek (MTK) chipsets.

Here (click to download Excel file) is the summary of all the $PMTK commands I’ve found so far. The source documents (which you’ll need for details of the parameters) are on the Web – ask Google for them.

Not every command will work on every module. You can find out if yours supports a given command by sending it and watching for the response. $PMTK001,code,3 means it worked.

Many of the commands have three variants – a code that sets a parameter, another you can use to query the current setting, and a 3rd that the GPS uses to reply to the query.

If you know of others not in the list, please contact me (as much detail as possible please) and I’ll add it.

Rev 4.2.2 schematic and PCB

A long while back I posted a version of the schematic for the electronics for my project to build a GPS-steered parachute for rocket recovery.

Since then I’ve tweaked the board a bit, to the point where the hardware design is clean and bug-free (as far as I know).

So here is the current version of the board schematic and layout, including the original Eagle PCB files as well as a PDF version of the schematic. It runs nice and stably, and could be the basis for a lot of other PIC32-based projects.

Click here to download it (zip file).

Compared to earlier versions, this one uses a DC-DC step-down for much more efficient use of the battery, and includes the reed-switch driven power on/off system I described earlier.

You are welcome to do with this as you like (modify, republish, whatever).  To make it official:

Hardware rights: I hereby grant everyone and everything in the universe permission to use and modify this hardware design for any purpose whatsoever. In exchange, you agree not to sue me about it. I make no promises. By using the design you agree that if you’re unhappy the most I owe you is what you paid me (zip, zero, nothing, nada). That seems fair.

I do ask that you credit this site (http://nerdfever.com) and post as the source, just as a courtesy; but you don’t have to.

Eventually (maybe this winter), I hope to do a new spin that will run off a single LiIon cell (instead of 2 in series, as now), and that will provide a cleaner power supply to the pressure sensor and ADC; noise on the power supply is the main source of noise in the pressure sensor readings (as far as I can tell so far).  But this version works quite well as it is.

For more info about the board, leave a comment and/or see my earlier posts:

Rocket telemetry system (September 2011)

Update on latest Rev 4.2.1 PCB, tips and status (August 2011)

New Rev 4 hardware based on the PIC32 (December 2010)

Rev3 rocket electronics part 1: Hardware (December 2009)

First flights of rocket glider

Saturday 2011-10-22 saw the first three flights of the rocket glider.

(Most of this post is adapted from this thread where there are more details.)

Only one of the flights was really good, but we learned a lot from all 3; and the glider is in good shape.

Boris and I decided to name it the “Autonomy”. Our goal for the day was to get some flight information about the proper pitch setting for a nice stable glide.

There is still a lot of data analysis to be done, but you can look at the videos below. The whistling noise on the audio track is a good indication of relative airspeed, I think.

Flight 1 – Roadrunner G80 (115 N·s)

Video from the ground:

Video from the on-board camera (looking out the bottom of the glider):

Immediately after apogee the glider went into a sharp roll to the left. This was because I forgot to turn off the navigation system, which hasn’t yet been calibrated for the roll sensitivity of the glider. It commanded left yaw and put it into the roll. While spinning it lost lift and dived toward the ground.

The parachute deployed at 200 feet AGL as planned. No damage other than a very tiny zipper (similar to the one on Friday).

Flight 2 – CTI/AMW H54 White Longburn (168 N·s)

This was our best flight of the day. I remembered to turn off the navigation system.

Video from the ground:

And from the on-board camera:

The glider arcs over a little prematurely. Looking at the video, I think this is because the “straight” boost position for the elevons actually is slightly pitch-up, so the glider tends to arc up (toward the rudder) during boost.

I think we can reduce this in future flights by (a) adjusting the boost position a little bit pitch-down, and (b) adding a little bit of yaw command to the boost position to induce a slow roll during boost to even out any pitch-up/pitch-down tendency.

By chance the glider was right-side-up at apogee, and the transition of the elevon position from straight (for boost) to the glide position is very clear in the video. When the elevons go to glide position the glider does an Immelmann turn (due to the high airspeed at apogee – this was a pure accident) and then settles into a steady glide.

The really good news here is the glider does seem to be self-stabilizing due to the dihedral; regardless of what attitude it was in at apogee, if left alone it seems to settle into a stable glide.

During the glide, Boris was manually adjusting the pitch setting via the telemetry system. The effects of this aren’t too obvious in the video, but I’m hoping to learn more when I look at the logged data (servo position vs. climb rate, airspeed, etc.).

Three seconds prior to parachute ejection, as planned the elevons go full-up to induce a flare for airspeed reduction. This is hard to see from the ground video, but the pitch change is pretty clear from the on-board video.

I plan to look carefully at the GPS data from this flight (also correlating that with the two video streams). I hope to get a sense of the forward airspeed of the glider (at various pitch settings), whether or not we have enough control authority to do a full-stall flare (and how long it takes to do that), sink rate, etc.

Flight 3 – CTI/AMW H100 Imax (286 N·s)

On the last flight of the day we tried a somewhat larger motor, aiming to get more glide time and a chance to try manual yaw control.

This time I worked the radio controls (probably a mistake) and Boris ran the camera.

Ground video:

On-board video:

Again you can see the glider pitching up during boost, causing a premature arc-over and too high an airspeed at apogee. It’s more pronounced here than in the prior 2 flights.

It’s hard to tell from the ground video (Boris, you need to zoom in more!), but you can see that at about 0:13 on the on-board video, as soon as I switched on the manual yaw control, I massively over-controlled it and the glider went into a sharp left roll, and dived that way toward the ground, much like in flight 1.

Clearly the glider is VERY sensitive in roll (as predicted by some posters here).

On flights 1 and 3 (the bad ones), the parachute ejection was triggered by the failsafe “TimeToImpact” calculation, well above the 200 foot (60 m) deployment altitude. The rocket decided it was less than 4 seconds from impact while descending at > 30 MPH (13 m/s actually) so it popped the chute, despite still being well above the deployment altitude.

Only on flight 2 (the good one) did the 200′ altitude trigger a flare and then deployment.

Unfortunately, on flight 2 it looks like the GPS signal dropped out partway thru the glide. At first I thought this was because the camera (wrapped in foil) shadowed the GPS antenna, but looking at it again I don’t think that’s it. I’m not sure what it is – I haven’t seen this on prior flights (under a parachute).

For our next flights (November 5 is the schedule), I’ve made the following changes:

  • Reduced parachute deployment altitude from 60 m (200′ AGL) to 45 m (150’ AGL) to get more glide time.
  • Reduced YAW_FACTOR from 1.0 to 0.1 (100 to 10) to make it less sensitive. This makes the servo response less sensitive by a factor of 10 in yaw – this is the most I think it can be reduced and still have positive control in yaw.
  • Tweaked the port elevon 3 half-turns down to try to trim out gentle left-turning tendency seen on flight 2 of 2011-10-22.
  • Adjusted YAW_STOWED_POSITION from 0 to -1 (50 to 0) to induce a slow roll during boost to counteract any pitch tendency during boost.
  • Adjusted PITCH_STOWED_POSITION from -0.4 to -0.54 (30 to 23) to counteract pitch-up tendency during boost seen in 2011-10-22 flights. I think AstronMike is correct – this is caused by differential drag on the rudder (hadn’t thought of that – thanks for pointing it out!).
  • Lengthened the flare period from 3.0 to 4.0 seconds.

Maybe other things once I’ve looked more carefully at the logged data. We’ll see.

Update on crash of Thrud

As I mentioned a couple of posts back, my last flight, on 24 July 2011, crashed after reaching about 7300 feet AGL.

Another flyer – Stan Speegle of OROC – eventually found the crash site, and was nice enough to collect the wreckage and send it to me for analysis.  Here’s what I found when I unpacked his box:

That rocket won’t be flying again.  Interesting how high-speed crashes create “accordion”-like wreckage; very different from the result of low-speed crashes.

Despite the 280+ MPH impact, a lot of parts were still usable – the nosecone was undamaged (because it was ejected milliseconds before impact) and the G10 fiberglass fins can be used again, as can lots of little bits of hardware.

The only real surprise was that the apogee ejection charge hadn’t gone off at all:

The charge holder on the left was the backup; that fired a few hundred milliseconds before impact.

The holder on the right fired 240 milliseconds after (detected) launch; but the charge didn’t go off.  Unwrapping the flashbulb revealed that the bulb had fired, but not ignited the ejection charge:

This is the first time I’ve been able to confirm that AG1 flashbulbs don’t always ignite the ejection charge (I suspect, but can’t prove, that it happened once before).  Overall AG1 bulbs are still a pretty reliable ejection trigger, but clearly not 100%; from now on I’ll be using some kind of backup ignition with them.

The electronics PCB was banged up, but I was able to get it running again with some unbending and resoldering of pins.  I downloaded and analyzed the data stored in flash memory; it just confirmed what I’d already figured out from the telemetry.

Autonomous rocket glider side-project, status update

Over the last few weeks I’ve posted a bunch of updates to catch up this blog on the status of my GPS-guided rocket recovery project.

At this moment (September 2011), it seems that the main problem I’ve been having with getting the parachute to steer properly is twisting of the control lines (see previous posts). I probably should have figured it out earlier, but the problem didn’t become totally clear until I could see it happening with the on-board 808 keychain camera. I’d been misled by the results of flight #28 way back in July 2010, which seemed to work OK with a tiny 2.5″ baseline – but it seems that was just luck.

Before my next flight, I plan to redesign and rebuild the steering system so that it has a much larger baseline. The comment by Tom Hannan posted July 29 on the project page hits the nail on the head, I think – the GPS and steering mechanism needs to be mounted right at the pivot point of the parachute, not any further down. This should cut way down on the swinging. I’ll try to make the parachute lines much harder to tangle while I’m at it. I also need to implement a apogee-detect lockout for a few seconds after launch (to avoid the problems in my last flight, on July 24). I’m not sure when that will be ready – probably October/November.

At the same time, I’ve been working with fellow CMASS rocketeer Boris Katan on a closely-related project – a rocket glider with GPS-steered recovery, based on the same electronics and software. We started back in June or so. At that time I thought the main problem with the system was swinging of the GPS under the long parachute lines – the GPS could conceivably be swinging in one direction while the parachute flew in another, which would certainly confuse my navigation algorithm. Also, I knew then that I had lots of problems with line tangling preventing reliable parachute deployment. Boris suggested that a rocket glider might be a way to test the navigation system without the complexities of the parachute – no long lines and swinging, and no tangling.

I thought it was a great idea, and we agreed to work on it together – Boris is building the airframe of the rocket glider, and I’ll be installing my electronics and servos into it to steer it.  Boris started a thread on The Rocketry Forum about the project – there’s lots of info there.

Boris first built a 1/3 scale model of the final glider – here it is before flight:

This flew twice on August 11 – both times fine, proving the stability of the design (see the TRF thread for more details). Now he is building the full-scale glider – here’s a recent picture from Boris – you can see the hole in the 3″ body tube for the electronics bay:

The delta-wing glider will steer with two elevons, using two servos to drive it. This will give us both yaw and pitch control, so we can flare the glider as well as steer it left/right. The elevons will be set flat (minimum drag) for the rocket boost. Then after apogee the nav system will try to steer it back to the pad. When the glider gets close to the ground (100 feet AGL or so), it will flare (to minimize airspeed) and deploy a parachute for a soft landing. I’ll be building up a new set of electronics to go in the glider, and working on some minor changes to the way the servos are driven in software, to allow both pitch and yaw control. We’re aiming for a first test flight on October 22 – but no promises.

The other day I got an email from Mike Passaretti way down in Western Australia, who saw my project here, and is working on a similar one of his own. His very first test flight was last weekend. Mike seems like a very experienced engineer, and I think has a good approach. There’s a very interesting thread on his project on the Australian Rocketry Forum. Maybe we’ll have a chance to collaborate – that would be fun.

Now that I’ve caught up the blog, I can go back to work. Watch this space.

23/24 July 2011 – I finally figure out the problem (I think)

Another progress report on my GPS-guided rocket recovery project (follow the link for an intro & index of posts).

After the July 16 launch (see previous posts) I only had a couple of days to fix things before it was time to drive out from Boston to metropolitan Brothers, OR for the OROC Desert Heat launch.

I repaired my 3″ “Thrud” rocket, changed the apogee detection algorithm, fixed the servo pulse problem, did some quick testing, and then packed up the motorhome for the trip.

On July 23, I flew my 4″ SuperHorizon rocket with the new software on a Skyripper J144 in the spacious Oregon desert:

Apogee detection was a little late, but not as much so as before. Looking at the logged data afterward, I suspect the algorithm is working fine, but the vent holes for the altimeter are too small.

As you saw on the video, the parachute deployed but didn’t fully inflate at first – after about 8 seconds it untangles enough to fully inflate. Here is the graph of altitude (feet AGL) vs. time – you can clearly see the high descent rate slow down when the parachute fully inflates:

Once the chute inflated, I had a very nice descent with a good chance to steer manually. Unfortunately, the steering didn’t work at all – the parachute just descended doing another slow counterclockwise turn.

But I got a strong hint as to why – have a look at the onboard camera video:

I think this is a really cool video because you can see the packed parachute and hear the wind whistling just before ejection.

I should have figured it out before, but it is completely clear from this video that the parachute lines are badly twisted together right from the moment of inflation. With the lines twisted like that, when the servo pulls on one line, the other inevitably gets dragged along, so no real steering happens.

The lines untwist gradually, becoming straight just a few seconds before landing.

I wasn’t able to redesign things out in the field, so the the next day (July 24) I packed the parachute even more-er carefully-er and flew the 4″ rocket again, this time on a Cesaroni I195:

I had some ability to steer the parachute manually at the very start of the descent, but then lost it as the descent continued. And here is why:

My careful packing paid off – the parachute deployed untangled. Mostly, anyway – the line going to the nose cone can be seen draped over the two parachute control lines. This isn’t good, but it wasn’t so bad that it prevented steering altogether.

But as the descent continues you can see the lines twisting together. And that’s when I lost steering control.

After looking at this video, it became completely clear that the reason I’ve been having so much problems getting the parachute to steer for the last year is that my steering baseline (distance between the origin of the left and right control lines) is far too small – this allows the control lines to twist together under the parachute. I need to redesign the steering system to provide a much larger baseline.

The afternoon was the end of the launch, so I decided to get as much data as possible from my last flight, taking advantage of the rare chance (for me) to fly in a really big desert field. I put my biggest motor, a Cesaroni J395, into my smallest rocket, the 3″ Thrud.

The result was not good:

I lost sight of the rocket on ascent, and never found it again. But the telemetry worked. As you can hear on the video, the telemetry reported the rocket coming down very, very fast. And some observers on the ground thought they saw pieces coming off it near apogee.

I analyzed some of the telemetry data after the flight, and got the following graph:

(For more info about this graph, see http://www.microchip.com/forums/fb.ashx?m=637866)

The maximum climb rate on the way up was reported (by telemetry) as 302 m/s (676 MPH, about Mach 1). The descent rate reached 126.8 m/s (284 MPH) just before loss of signal.

A lawn dart.

Unfortunately, the telemetry didn’t have any valid GPS data, because the high vertical speeds seemed to prevent the GPS from holding lock on the satellites. My son and I searched for the rocket for over an hour, but never found any of it.

After the flight, I tried to analyze what went wrong. The telemetry gave an apogee of 7316 feet AGL (a personal record). But the telemetry also showed that the rocket detected launch at 93 feet AGL, then just 40 milliseconds (one cycle) later, falsely detected apogee and fired the ejection charge at a reported (but highly unlikely) altitude of 8 feet AGL. This immediate (and unreal) dip in measured altitude almost certainly caused the false apogee detection.

It’s clear from both video and telemetry that the parachute didn’t deploy just after launch. Launch mass was about 2.2 kg. Based on the published thrust curve of this motor, the rocket should have left the pad at about 22 Gs of acceleration; my best guess is that the 22 x normal weight of the nosecone just after launch was enough to keep it on the rocket despite the ejection charge.

My theory at this time is that the false apogee detection was caused by the high G forces at launch. Most of my rockets leave the pad at 4 to 6 G; this one left at 22 G. The Freescale MP3H6115A pressure sensor is known to be sensitive to physical flexing – probably the G forces flexed the sensor, leading to the false reading. I’ll have to implement a software “lockout” to prevent this from happening again.

The flight was a useful radio range check; the graph above plots time against AGL altitude, RSSI, and LQI, both scaled to 10,000 as the max reading (all from telemetry); as you can see the radio still worked well at a distance of about 1.5 miles, although the signal strength was starting to get low.

I did have a backup ejection charge setup. And it worked exactly as (poorly) designed. At 200 feet above the pad elevation, the rocket was descending too fast, so the rocket fired the backup charge. You can see the overpressure from the backup charge in the altitude graph (above). Unfortunately, 200 feet at 280 MPH is less than half a second. The backup ejection happened just 200 milliseconds before the last telemetry record was sent (when the rocket either impacted or went behind a hill shortly before impact); nowhere near enough time for the parachute to deploy. In retrospect, I should have made the backup system depend on the time to impact (based on descent rate) instead of simply altitude. Oops.

About a month later, the debris was found by Stan Speegle of OROC, who was nice enough to call and tell me about it. Sure enough, he found the parachute partly deployed, and the rest of the rocket smashed into tiny pieces. He’s promised to mail the wreckage back but I don’t have it yet – maybe I can still extract some data or video from it when I get it.

Flights with new on-board video camera

Over May and June 2011 I had a chance to think about what was going wrong in previous flights.

Since I suspected the GPS was getting confused by the swinging under the parachute (see my previous post), I decided the best way to debug the navigation system was to manually steer the parachute from the ground, while letting the navigation system run and try to figure out the correlation between servo position and turn rate, and the system lag.

So I built my “universal controller” gadget I described earlier – this has a knob that lets me manually control the servo from the ground.

I also used the time to install an “808” video camera into the electronics bay, looking upward at the parachute.  I hoped that a view of the parachute in flight might be useful in understanding what was going on with the navigation system.

Last, it seemed that my recent flights had all deployed the parachute a bit past apogee (late).  That’s not good because it means the parachute is coming out at a higher-than-necessary airspeed, which leads to much larger deployment forces and possible zippers.  So I modified the apogee detect algorithm to be more sensitive and trigger earlier.

On July 16 I got a chance to try these improvements.  The first flight was my 4″ SuperHorizion on a Skyripper H124 hybrid motor:

Parachute deployment was a bit on the early side.

Again, the parachute did not fully inflate, so I didn’t get a chance to try manual steering, or get any useful navigation experience.  I was lucky – there was no damage at all after the hard landing.

Here is the view from the onboard video camera – I think it’s kind of dramatic:

It’s pretty obvious from the video that the parachute lines are all tangled up, which is why the chute didn’t inflate.  This just verified that I still didn’t have a packing method that resulted in reliable deployment.

I tried again the same day with my 3″ Thrud rocket, again on a Skyripper H124 motor:

This was much worse.  The new apogee detection algorithm was much too sensitive, deploying the parachute too early, while still ascending.  The deployment forces broke the Kevlar cord attaching the tailcone to the rest of the rocket and resulted in a very severe zipper (the body tube was totaled).

The parachute did deploy OK, but again it just spun around in one direction for the whole descent.  I took over with the “universal controller” and seemed to be able to control the rate of turn, but I couldn’t get the parachute to fly straight.

The video from the onboard camera didn’t capture a view of the parachute (it’s just out of the field of view), but the audio track was unexpectedly interesting:

The “cycling” sound on the onboard video is the servo attempting but failing to move to the commanded position.  So part of my problem was that the servo wasn’t even moving when it was supposed to! (This affected only the servo on the Thrud rocket, not the one on SuperHorizion. But still.)

It turned out that I was sending pulses to the servo that were outside the range of what it could properly handle – if I sent a command for a large movement the servo would work, but commands for small gradual movements were ignored.

This wasn’t a good day.

Before the next flight I needed to fix the servo pulse problem, the apogee dection algorithm, and repair the broken Thrud rocket after the zipper and crash of the tailcone.