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 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.
Body/Fuselage
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 it allows the glider to fly faster, 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, 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 “chord” of the wings 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 with 600mm exactly—minimum weight that meets the capacity requirement.
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:
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.
Motor and motor mount
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.
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.
Parachute
“What?!?” I hear you cry. Why do you need a parachute if it’s going to land itself?”
Three reasons:
- 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.
- The second is for test flights. For starters, before I shoot a hundred dollars worth of electronics up in the air, I want to make sure the rocket 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 recovery parachute when they reach the top.
- Finally, I want a braking parachute so that it doesn’t rely only on the ground skid to come to a stop. The idea is 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.
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.
Sensors
Fully loaded, JR-X1 will carry numerous sensors that collect the data needed for navigation. Right now, I’m envisioning the following:
- Accelerometers to measure acceleration in each of the three dimensions;
- Gyroscopes 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;
- 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, much of it needs to be preprocessed to be useful for navigation.
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 computes various generally useful values from the raw data. The preprocessor is p
- 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. 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 velocity; that is, the rate of change of the pitch, yaw, and roll position.
- Pitch, yaw, and roll acceleration; i.e. the rate of change of the pitch, yaw, and roll velocity.
- The direction to the landing point from the current location.
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 15º 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.
