JR-X1: My Rocket Project—How it works

The goal of my project is to fly a model rocket that, upon reaching its highest point, flies itself back down as a glider, using control surfaces operated by an onboard autopilot computer to guide itself back to the launch/landing field and a targeted, soft, horizontal landing.

As far as I know, this hasn’t been done before.

In my last post, I talked about the goal—summarized above—of my rocket project, JR-X1, and about some of the constraints that make it a challenging goal.

In this post, I’ll describe how it works, at a conceptual level—what are the building blocks, and how do they interact to make the rocket / glider do what I want it to?

Here’s a list of the major blocks, followed by fuller descriptions of each block:

  • the rocket body, which is also the glider fuselage;
  • the rocket fins, which are also the glider wings and tail;
  • the rocket motor and the motor mount, to which is attached a parachute;
  • the sensors that inform the aircraft of its location, orientation, velocity, acceleration, altitude, etc;
  • the control surfaces: elevons on the trailing edges of the glider’s wings, and rudderons on the trailing edges of the vertical tails, so there’s a control surface on the trailing edge of each of the four rocket fins;
  • stepper motors to move the control surfaces;
  • last but not least, the flight computer, which interprets data from the sensors, computes the path to the landing point, and initiates control surface movements to steer the rocket on that path.


The body needs to be streamlined to minimize drag, which has two effects. It allows the rocket to fly higher on ascent, because there’s less drag counteracting the thrust of the engine. And the higher the flight, the faster the glider on the way down, which is important because lift increases with airspeed.

I’ve chosen to streamline the body by making it with an airfoil cross-section, instead of a simple cylinder-with-a-cone-on-top.

This has two advantages: it produces less drag than the cylinder+cone design; and it provides lift on its own during the descent glide, independent of the wings. Just how it provides lift, I’ll discuss in a future post about aerodynamics in detail, but for now just believe this: As long as the glider is gliding with its nose pointed slightly up, the body’s shape provides lift additional to the lift provided by the wings.

The body is about 600mm long. This is a compromise:

On the one hand, the longer the body, the longer the wing “chord” it can support (the chord is the distance from a wing’s leading edge to its trailing edge). A longer chord gives more lift at a given speed.

On the other hand, the bigger the rocket, the more it weighs, resulting in a lower peak altitude for a given engine size, which argues for keeping the rocket as small as possible.

Another consideration—on a third hand, so to speak—the rocket needs to have enough room inside for the flight computer, the sensors, and the stepper motors. In particular, the main computer I plan to use, the Raspberry Pi 4B, is 59mm wide, about 5⅓”. The way the body’s airfoil shape is designed, that means the body needs to be at least 500mm long (~19½”) to be sure it’s at least 60mm at the widest part. I added 20% to allow for any minor errors in fabrication, so it has to be at least 600mm long.

In the end, I went with 600mm exactly—minimum weight that meets the capacity requirement.

Since first publishing this post, I’ve realized that this analysis is… incomplete, to put it kindly. The three original considerations—wing chord, weight, and capacity—aren’t wrong, but there’s a cart-before-the-horse problem. I’ve been designing the vehicle—the rocket glider—first, and then experimenting with various computers and motors I might use, tweaking the body design as needed.
Revising that approach, I’m now going to focus first on the flight computer and the stepper motors. Once I know what will be inside the vehicle, I can design the body to hold it. Stay tuned.
(I should have been suspicious of my reasoning as soon as I caught myself adding in that 20% fudge factor. I mean, really.)

Fins / wings and tail

The rocket has two large fins that serve as the glider’s wings, and two smaller fins that serve as the glider’s vertical tails, something like this:

The large “delta” (triangular) wings provide plenty of lift.

There are two vertical tail fins because rocket fins have to be placed symmetrically.

The elevons and rudderons are visible in this sketch.

Unlike the plump, rounded airfoil profile of the body, the wings and tail are thin, nearly flat, with just a slight airfoil profile in cross-section:

Wing cross-section, leading edge on the left

The reason is because delta wings work best if they’re nearly flat, with a sharp leading edge. (A future post will cover the aerodynamics behind that statement.) The geometry isn’t as aerodynamically important for the tails, but their weight and drag will be less if we make them thin as well.

(Since I wrote that last sentence, I’ve learned more about how tailfins—also known as vertical stabilizers—provide “sideways lift” to help control yaw. So the geometry does matter. More details will be in the aerodynamics post.)

Motor and motor mount

Model Rocket Motors from various online catalogs

The rocket motor is a standard, commercially available, model rocket motor. As mentioned in an earlier post, I don’t plan to make my own motors or fuel, because my liability insurance requires that I follow the Model Rocket Safety Code, which forbids homemade motors and fuel.

The motor mount is the adapter to fit the motor into the rocket body:

Typical motor mount (Image: Apogee Components)

A word about “motor” vs “engine.” Linguistic prescriptivists will say that a motor runs on electricity, and an engine runs on chemical energy. By that definition, one should say “rocket engine.
As it turns out, though, language evolves, and the two terms are interchangeable in common usage today. (One of the two major model rocket retailers uses “motor,” and the other uses “engine”.)
I usually say “rocket motor,” trusting that the reader will understand that I don’t mean a rocket powered by electricity.

You can see that the inside diameter of the motor mount matches the diameter of the motor/engine. The outside diameter of the centering rings matches the inside diameter of the rocket. The whole assembly slides into the tail of the rocket.

In typical model rockets, the motor mounts are glued into the rockets. However, on JR-X1, I want to be able to use motors of various diameters, so it will have three interchangeable motor mounts, for 18mm, 20mm, and 24mm motors.

I’m still figuring out how that will work.


“What?!?” I hear you cry. Why do you need a parachute if it’s going to land itself?”

Three reasons:

  1. One is the usual reason for carrying a parachute aloft: If something goes wrong while you’re up in the air, it’s nice to have an alternative to falling out of the sky and hitting the ground at 150mph.
  2. The second is for test flights. For starters, before I shoot $100 worth of electronics up in the air, I want to make sure the rocket that it’s on can fly reliably. Even after I have the computer installed, I’ll want to test it in flight before I let it control anything. Those test flights will work like normal model rockets, popping a parachute for a controlled descent and recovery.
  3. Finally, I may want a braking parachute so that it doesn’t rely only on the ground skid to come to a stop. The idea would be to pop the braking parachute just before hitting the ground (which is a design problem worth its own blog post. It turns out that measuring very low altitudes accurately, within the weight and budget limitations of a model rocket, is a hard engineering problem.)
    Update: I have found sources for lightweight, inexpensive LIDAR units that can measure up to a meter. LIDAR is like radar, but with light instead of radio waves.

The reason I’m describing the parachute just after the motor mount is because the parachute is attached to the motor mount, and the motor mount is in turn attached to the rocket body by a length of cord.


Fully loaded, JR-X1 will carry numerous sensors that collect the data needed for navigation. Right now, I’m envisioning the following:

  • 3-axis accelerometer to measure acceleration in each of the three dimensions;
  • 3-axis gyroscope to measure changes in the aircraft’s orientation;
  • Barometric altimeter measures altitude based on air pressure;
  • GPS to measure location and altitude based on GPS satellite positioning;
  • Magnetic compass to find North, and to detect altitude based on Earth’s magnetic field;
  • the LIDAR short-range altimeter mentioned above;
  • and maybe a pitot-tube-style airspeed indicator, which measures velocity relative to the air rather than relative to the ground.

Although some of this information is directly useful for navigation, much of it needs to be preprocessed before it can be used.

One obvious example is altitude: there may be as many as four values for altitude—three measured by sensors, plus altitude can be computed from the accelerometer data—so the preprocessing software has to come up with a “most likely” altitude value to give to the navigation component.

This preprocessor transforms the raw data into measurement values that can be used for navigation. This transform processor (“XFORM“) publishes the following:

  • The current location vertically and horizontally.
  • The current velocity vertically and horizontally.
  • The current acceleration vertically and horizontally.
  • The current pitch, yaw, and roll positions in degrees. Pitch is how much the glider is pointing up or down compared to its direction of travel; yaw is how much the glider is pointing left or right; and roll is how much the glider has rolled to one side or the other.
  • Pitch, yaw, and roll angular velocity; that is, the rate of change of the pitch, yaw, and roll position.
  • Pitch, yaw, and roll angular acceleration; i.e. the rate of change of the pitch, yaw, and roll velocity.

These computed values are updated constantly as new sensor data comes in, and the values are passed to the computer’s navigation unit and pilot unit.

Control surfaces

The control surfaces are hinged flaps at the trailing edges of the fins.

Elevons are at the trailing edges of the wings; rudderons are at the trailing edges of the vertical tails.

Elevons have the functions of elevators and ailerons on a “traditional” aircraft; rudderons have the functions of rudders and ailerons. Hence their names.

Elevons control the pitch of the aircraft by moving up together to raise the nose, and down to lower the nose.

Rudderons control the yaw of the aircraft by moving to the left together to turn left, and to the right to turn right.

Elevons and rudderons work together to roll the glider left or right (for example in a banked turn). To roll right, the right elevon is raised and the left elevon is lowered, and simultaneously the upper rudderon is moved to the left while the lower rudderon is moved to the right. To roll left, the four control surfaces are moved in the opposite directions.

Stepper motors

Stepper motors are small electric motors that can be turned a precise fraction of a revolution by a computer command. One stepper motor drives each control surface.

Two components of the flight computer control the stepper motors: the trim control, and the pilot.

The trim control keeps the aircraft’s pitch, yaw, and roll at their “normal” values: nose pitched 20º up (because of delta wing aerodynamics); roll at zero to keep wings level; and yaw at zero to keep the glider pointed in the direction it’s going. If any of these drift from their set values, the trim control instructs the stepper motors to move the appropriate control surfaces to correct the drift.

The pilot component steers the glider to keep it flying toward the landing site. It sends commands to the control surfaces through the stepper motors to turn or bank, or increase or decrease the rate of descent.

Both the pilot and the trim control normally command relative movements of the control surfaces, which allows the stepper motor controller to integrate the two sets of commands.

For example, the trim control might be in the middle of correcting a slight roll to the left, by lifting the right elevon by 1º and lowering the left elevon by 1º. At the same time, the pilot could be commanding a pitch-up, telling the stepper motors to raise each elevon by 5º. Specifically, the pilot does not set the elevons to an absolute angle of 5º. The net effect of the two commands will be left elevon up 4º and right elevon up 6º, pitching the nose up while continuing to correct the roll.

A small computer (perhaps an Arduino) receives commands, interprets them, and sends signals to the stepper motors.

Flight computer

The “flight computer” is actually a small network of computers, each hosting the software components to perform one or more functions. This allows the components to operate simultaneously, in parallel.

Here’s the list of flight computer components, together with my current thinking about which computers will host which components.

  • Raw input: this interrupt-driven component reads the raw data from the sensors, and passes it to the pre-processor. It will probably run on the main computer, the Pi 4B, because its multicore architecture allows it to process multiple interrupts simultaneously.
  • Input pre-processor: First, transforms the data into standard units. For example, the data from an accelerometer may have a value from 0 to 4095 to represent acceleration up to 10 G’s; the pre-processor knows that ratio, and translates, for example, a reading of 2048 to 5 G’s, or 49 meters/sec2.
    The pre-processor’s second task is to compute the quantities derived from the sensor data; for example, it uses accelerometer and gyroscope data to compute current velocity and orientation. A full list of these derived values is above, in the Sensors section. I plan to run the preprocessor on the same computer as the raw input component.
  • Navigator: tracks whether the glider is on a path to the landing site; and if not, determines what changes of direction and/or descent rate are necessary to get it back on path.
  • Pilot: uses the input from the Navigator, together with the flight dynamics values (location / velocity / acceleration values, and pitch / yaw / roll values and their rates of change) to execute turns and adjust the rate of descent. The Pilot and the Navigator run together on their own computer.
  • Trim control: as described above, this component is responsible for maintaining steady pitch, yaw, and roll orientation in the absence of pilot commands to the contrary. Depending on how much compute power it needs, Trim Control could share the Pilot / Navigator computer, or it could run on a small, separate computer.
  • Stepper motor controller: Running on a small, separate computer (perhaps an Arduino), this component receives commands from the Pilot and Trim Control components, and drives the stepper motors accordingly.
  • Data distribution: using a publish / subscribe model, this component receives data (input and computed values) from components, and distributes the data to the components that need it. Could run on the main computer if it has the capacity, or could be separated out onto its own computer.
  • Logging: a record of every input, every computed value, and every command. Ideally runs on the main computer, to take advantage of its USB3 port for fast transfer to SSD.
  • Network: The various computers are connected by a high-speed, wired, switched Ethernet network. The network switch is a separate circuit board. The switch supports speeds of 10 / 100 / 1000 Base-T, to accommodate the Ethernet interfaces of any of the computers.

Those are the building blocks of the overall rocket / glider design, and how they work together. In my next post, I’ll get into the aerodynamics of both the rocket and the glider.

JR-X1: My Rocket Project—Introduction

The goal of my project is to fly a model rocket that, upon reaching apogee, flies itself back down as a glider, using control surfaces operated by an onboard autopilot computer to guide itself back to the launch/landing field and a targeted, soft, horizontal landing.

As far as I know, this hasn’t been done before.

This post started as an email letter to my 41-year-old son, a software developer and a space and astronomy geek, because he had expressed interest in my rocket project a few months ago. After I’d been typing for a few hours (!), I realized I had more to say than I could fit into a reasonable-length email. The topic needed something like chapters.

That sounds like a series of blog posts to me.

So I copy/pasted the unfinished email into WordPress, massaging it only slightly to create this post.

Future posts will start getting into the aerodynamics, the flight computer, and the design process, but first we need to cover some basics, which is what this post does. Here I’ll

  • define the goal;
  • lay out some of the constraints—regulatory, legal, safety, and a couple of self-imposed constraints; and
  • offer a couple of personal notes, including the (mildly embarrassing) story of how I came to be interested in rocketry.
The goal is simply stated: to fly a model rocket that, upon reaching apogee, flies back down as a glider, using control surfaces operated by an onboard autopilot computer to guide itself back to the launch/landing field and a targeted, soft, horizontal landing.

Simple to state, but difficult enough to do that no one has done it yet, to my knowledge.

This “gliding descent” is similar to spaceplanes like the Space Shuttle — except without a pilot — or the X-37B. That is to say, “gliding descent” is a euphemism for “barely controlled diagonal plummet terminating in a high-speed skid,” as seen in the linked video clips.
Nail-biting, but it works.

There’s a problem with both of these spaceplanes, though: as good as they are at being gliders on the way down, they’re actually not very good rockets on the way up. That’s because their wings are designed to provide lift, that is, a force that pushes from the bottom surface of the wings to the top whenever the aircraft is moving. That’s great when the Shuttle (or X-37B) is gliding down, parallel to the ground, but not when it’s pointing straight up, as at launch.

At launch, with the Shuttle (or X-37B) pointing straight up, that force of “lift” is actually directed sideways, because it’s still pushing from the bottom surface of the wings to the top. Obviously, you don’t want a sideways force when you’re trying to go straight up, so the Shuttle engines have to compensate: they direct part of their thrust sideways in the opposite direction to counteract the “lift” . This sideways thrust, and the fuel to provide it, are basically wasted. Pushing sideways doesn’t help the Shuttle get where it’s going; it just keeps it from tipping over as it ascends.

In fact, this was such a problem on the early X-37B flights that they now put the spaceplane inside the booster rocket for launch; it doesn’t come out until it reaches the edge of space.

This leads to one of my self-imposed constraints: I want my rocket to be not only a good glider coming down; I also want it to be a good rocket going up.

And for a reason — the more efficient the rocket is, the higher it flies; and the higher it flies, the longer the glider flight coming down. A longer descent from a higher altitude is more challenging, which, to me, makes it more interesting.

This constraint becomes a design requirement: my rocket has to be symmetrical.

It has to have a round body; fins that provide no lift when it’s flying straight; and symmetrical placement of the fins. I really only need 3 fins — two for the glider’s wings and one for its vertical tail. But to keep it symmetrical, I need a fourth fin, opposite the vertical tail, resulting a glider that not only has a tail fin sticking up in back, it has an identical one sticking down.

What I’m doing is also different from other model rocket glider projects that I’ve seen online, because of a second self-imposed constraint:

I want my descent glider to be the same aircraft as my ascent rocket.

That rules out one approach I’ve seen: reconfiguring the fins / wings at apogee. One design I saw, for example, had long, slender glider wings that folded, spring-loaded, into the body at launch, where they wouldn’t interact with the air during ascent; then an electronic switch would release them at apogee, and the springs would pop these long, slender wings out for the glide down. That’s very cool and very clever, but that’s not what I want to make.

This presents a tricky design problem:

The part that works as a rocket fin on the way up, also has to work as a glider wing on the way down.

The reason this is tricky is because the best rocket fins are small, thin, triangular shaped, and mounted at the rear; while the best glider wings have a wide wingspan and a thick cross-section; they’re shaped like long skinny rectangles; and they’re mounted near the center of the glider.

As I said, more challenging is more interesting.

The other big set of self-imposed constraints is implicit in the phrase “model rocket”, which has a precise definition in aeronautical law, in the national fire code, and in the amateur rocketry organizations’ safety codes.

Some major limitations imposed by model rocket laws, regulations and safety codes:

  • You can’t shoot a rocket from one place to another.
  • You have to launch straight up.
  • Your rocket has to make a soft landing. That’s for safety reasons—you don’t want your rocket coming down like a 100-mph lawn dart!
    For normal model rockets, this means a parachute descent. For my rocket, this means a gliding descent to a targeted, soft, horizontal landing.
  • No explosives on board (except a tiny black powder charge is allowed to pop the parachute). Model rockets are not fireworks.
  • The fully loaded rocket is limited to 1500 grams, about 3 lbs. Fuel mass is limited to 125 grams, about 4½ ounces.
  • Motors must be certified, commercially available model rocket motors — no home-brewed fuel or hand-assembled motors.
  • Total impulse of the motor(s) can’t exceed 160 newton-seconds.
  • There are rules for the size of the launch field based on the power of the motor.
  • Of course there are rules about fire safety, like don’t set the grass on fire in the launch field.
  • And so on.

Why would I work within this restrictive safety code? In a word, insurance. As a member of the National Association of Rocketry (nar.org), I’m covered by a five million dollar liability policy for any damage caused by my rocketry activities, as long as my rocketry activities are within the safety code. So, major motivation.

That’s (more than) enough about the goal and the constraints.

Here are a couple of personal tidbits.

This is an early concept sketch from my home whiteboard (everyone has a home whiteboard, right? No? Just me?) You can see I’m still figuring out the geometry of the fins/wings.

Concept sketch early May 2020

Why the name “JR-X1“? All my model rockets have a name and a number (they’ve all been simple kits so far). The number is JR-1 for the first one, JR-2 for the second one, and so on. Why JR? "J" for Jenny’s, and "R" for Rocket. The X is for eXperimental, just like NASA and the Air Force. I don’t know which JR number this one will be by the time it’s built, so it’s just X1 for now. And though I’ll have to lay eyes on it to know its name for sure, it’s likely to be named after my ancient Greek mythological spirit guide, Cassandra.

I did promise a mildly embarrassing personal note. It’s this: I got interested in model rockets for some very wrong reasons.

It started around the time those idiots were flying drones over Heathrow a few years ago, even shutting down the airport on a couple of days. I thought at the time, “If the military can make a surface-to-air missile that can take down an F-16, how hard can it be to make one to shoot down a 25-mph drone?”

So my engineering brain teamed up with my anger fantasy of shooting the damn things out of the sky, and I started planning how to make it work. Later, I got the idea of using air-to-air “missiles” (model rockets) instead of surface-to-air; they would be launched from an “anti-drone drone”. So I had to start studying the physics of flight, a lengthy undertaking.

At some point, Common Sense whispered in my ear, suggesting I at least take a look online, to find out if what I wanted to do was even legal. Unsurprisingly, it turned out that it would be very illegal, in so many ways. Like a $2,000,000 fine and life imprisonment illegal.

So I decided to let go of my dreams of righteous revenge. But the whole rockets / aerodynamics / engineering topic was so fascinating, I couldn’t let it go. So instead of dropping the whole concept, I morphed it little by little until I’d stripped out all the inconveniently illegal bits, and I ended up with the JR-X1 project. I’m OK with that. This project is challenging enough.

Stay tuned for my next post, which will cover the overall architecture of JR-X1, and future posts, which will get into the design process!