Ordering parts and planning the build (7)

(I try to link to the products I used so you can find them more easily. If you purchase them from these links I may receive compensation from affiliate programs. I am not employed or influenced by the manufacturers or distributors.)

After spending a couple of weeks strategizing about the build and the tech to go into it my friends invited me and my wife to come visit them in Michigan for the 4th of July. Since we live in a big city there aren’t a lot of open spaces where you can perform a launch without having to worry about trees, power lines, and population, so I thought this would be a great chance to get in a few launches and collect some telemetry data that I can use to plan further iterations. The only problem: I had no rocket.

With only 10 days before we left on our trip I needed to order all of the parts, receive them, assemble them, and hope everything dries in time to be able to pack it all up for the road.

I had already been looking at Apogee for inspiration on body designs and what kinds of materials are commonly used. Normally I might stray from the more expensive specialized retailers and try to buy the raw materials from cheaper businesses, but with the time crunch I figured I could streamline the process by purchasing all parts that were designed to work together.

I settled on the Estes BT-60 (Body Tube #60, 41.6mm) for a few reasons. It was large enough to fit the camera payload and telemetry electronics without being so large it would be too heavy or experience too much aerodynamic drag. Apogee had a clear payload tube, fiberglass engine compartment, nose cones and other components in this size. It was also very close to the diameter that I had already used in my computer modeling, so I could easily adjust the digital models to be accurate to the real build without too much re-working.

In total, there are just over a dozen body components that I needed, and some other tools and supplies that I used to assemble it. Here’s what I went with:

I probably could have done well to order a fin jig like the one they sell on Apogee, and perhaps some vice grips as well, but I had a deadline and I was just going to go for it! Unfortunately USPS delayed my order by a couple of days, but I did receive everything just with enough time that some late nights made up the difference.

In my next post I will show you how I put it all together, as we get closer to our first launch day!

Achieving Stable Aerodynamic Flight (6)

(I try to link to the products I used so you can find them more easily. If you purchase them from these links I may receive compensation from affiliate programs. I am not employed or influenced by the manufacturers or distributors.)

Since I started working on this project I’ve had a lot of fun learning about aerodynamics. It’s something that only really matters once you put the parts together, but planning for an aerodynamically rocket is critical for success. There are a TON of great resources to help you learn about the science of aerodynamics. I’m going to include the videos that I found the most informative in here to help me illustrate the concepts that we will need to understand. After we cover the basics, I will show you how we can apply the concepts to our own designs using a rocket simulator as we plan to build the exact vehicle we need.

Basics of Aerodynamic Stability

Before we get started, we should establish the axes of a rocket, so we have a common understanding. The Z axis runs from the tip of the rocket to the tail, and then the X and Y axes run from side to side, sometimes in line with the fins (on a 4-fin model).

The three most important concepts in aerodynamics are the Center of Gravity, Center of Thrust, and Center of Pressure.

Center of Gravity is the point where the weight is evenly distributed on any axis you choose. This will change slightly over time as fuel is burned, which is something to consider in larger rockets with massive fuel tanks, but in smaller model rockets losing mass in the tail will only work to your benefit. On the Y and Z axes you want the CoG to be as close to the origin as possible. Moving the CoG along the Z axis will be how we achieve stability.

Center of Thrust is where the force of the motor(s) or thruster(s) is applied. You can change this using Thrust Vectoring or RCS thrusters to change the trajectory of the rocket. Typically your center of thrust will be at the rear, and optimally the direction of thrust is perfectly aligned with the X axis.

Center of Pressure is the center of the force applied on the body by the air flowing over it. This can be very dynamic, and there are a lot of ways to determine the CoP, some of which will be covered in this video.

Essentially the goal is to align the Center of Thrust with the X axis perfectly, then arrange the rocket body and payload in such a way that the CoG and CoP are at the origin of the Y and Z axes, and the CoG is forward of the CoP. This way, as the rocket flies the pressure forces acting on it will keep it pointing straight. This is usually achieved by adding fins toward the base of the rocket, which move the CoP backwards by giving added surface area to the body.

Unlike with engines (😂), bigger fins aren’t always better. There is a phenomena called Wind Cocking, which is caused when wind blowing along the Y or Z axes exerts more force on the tail of the rocket than the nose, tipping the body, and causing the engine to push the rocket into the wind. To avoid this you want to try to keep your fin size and shape just large enough to provide stability, but not much larger. Here’s a great video about estimating CoG and CoP, and properly balancing your rocket body so it is aerodynamically stable.

Rocket Stability – LabRat Scientific

Software Modeling for Aerodynamic Stability

Now that we understand how aerodynamic flight works, let’s talk about simulating the design. As I mentioned before, I have been using OpenRocket to do all of my virtual modeling so far. OpenRocket is a Java app, so you can run it on any computer, and it has some pretty simple components you can add and customize to suit your design goals.

For the first version of my rocket I had already done some shopping for parts, and settled on a clear payload bay for the 360º camera, a fiberglass engine compartment, and a pre-fabricated ogive nose cone. The fins that I used were made of balsa as well. With most of these components pre-determined, the two biggest variables would be payload placement/weight and fin size/shape.

As we discussed earlier the payload and engine weight and placement will both dramatically change the center of gravity. For the rocket’s maiden voyage I didn’t want to send up the camera, which only left the telemetry package, a mere total of about 60-80 grams, in the front and a large heavy motor in the back. This meant that the fins would have to be somewhat larger, to pull the center of pressure further back.

In the image below you can see what the rocket’s properties would be like with the motor I anticipated using and just the telemetry in the payload bay. I trimmed the tips of the fins to reduce the stability so the rocket would fly better if we encountered wind. Realistically, though, this was still a lot of fin in the face of any wind.

Version 1.0 digital model with an empty payload bay

When I add the 360º camera then the stability goes way up. This would result in a lot of wind-cocking, since the inertia of the heavy payload bay would exaggerate the tipping. This was about as far as I could trim the fins and still have a stable empty flight, though, so it would have to work.

Version 1.0 digital model with camera onboard

One of my favorite features of RocketSim is the ability to plot the model of the flight. There are a few considerations to remember here. The rocket takes off under power, and flies under power for a total of 3.5 seconds. After the motor burns out the rocket is in ballistic flight for about 6 seconds (the current model uses a 6-second delay) after which a charge detonates separating the engine compartment from the payload bay and ejecting the parachute. From this point the vehicle should gently descend back to the earth at a steady rate of ~-10m/s.

Plot of simulation altitude, vertical velocity, and vertical acceleration vs time

You can even adjust parameters like recovery chute delay and launch rod angle to accommodate for windy conditions and predict how far the vehicle will travel from the launchpad.

Plot of simulation altitude vs position

This last plot I found really informative, which shows stability over time. Note the first second or so, where stability is most critical. You don’t want the rocket to be unstable when it leaves the launch rod, because it may tip, and without enough wind passing over the fins it won’t correct itself, and may fly off uncontrollably.

Plot of simulation stability vs time

Finally, I’ll leave you with a couple of videos that I really enjoyed. The first one is very informative about rocketry on many levels, and the other illustrates how active aerodynamic controls works in the context of the F-22 fighter jet. In my next post, I will discuss parts, and the strategy I used that allowed me to assemble the rocket in just a couple of days.

Radio Telemetry – Choosing the right wireless transceiver (4)

(I try to link to the products I used so you can find them more easily. If you purchase them from these links I may receive compensation from affiliate programs. I am not employed or influenced by the manufacturers or distributors.)

Enough about imaginary fuselages and prototyping boards with everything built in, LET’S BUILD SOMETHING!

In my last post we proved that the Arduino Nano 33 BLE Sense had all of the skills necessary to track attitude and some movement, but how do we get this information to the computer for analysis?

There’s a great video from BPS.space that includes a segment about all kinds of ways to transmit and save telemetry data, and I definitely should have watched this before my first flight. It boils down to two different options – onboard storage and wireless transmission.

With onboard storage you can use an SD card writer such as the ADA254 or a flash module such as this one from Amazon. The basic idea is that the builtin memory on the Arduino Nano erases itself every time the system is rebooted to make room for the new data the program will have to process. If we want to store the data more permanently then we would have to add that capability ourselves.

Both of these add-ons use the I2C communication built into the Arduino platform, so we can add as many as we would like, but there are benefits and drawbacks to each. An SD card writer would allow us to write the data to a removable card that we can plug into just about any smartphone or read with an SD card reader on almost any computer. The downside is this storage can sometimes be a little slower to write or read, and because the card is mechanically connected to the pins on the writer with pressure from the bracket, it might not withstand the stresses of rocket flight well, potentially resulting in data loss or a lost SD card.

The flash memory add-on is a great option because it can be faster to write to, and doesn’t have the mechanical weaknesses of the SD card, but the major drawback is that you can only retrieve the data by plugging the flight computer into the USB port on your main computer to download the data.

Both of these are inconvenient as primary data transmission methods because neither provide realtime data monitoring. Also, if the rocket flight ends in rapid unscheduled disassembly or a vertically premature arboreal landing, the data is gone for good. More on what I’ll call RUD and VPAL later.

All of these systems are small and lightweight, so we don’t have to worry about payload limits, but I’d really only be interested in onboard storage as a backup, in case wireless telemetry cut out mid-flight. My primary telemetry option needs to be wireless.

In order to achieve wireless communications you typically want to use Radio Frequency communications, which simply means that it’s sending the signal using Electromagnetic waves. One alternative would be light, like the infrared diode and sensor used for television remotes. This isn’t very effective on bright sunny days, though, and can be interrupted by visually opaque interference, such as rocket exhaust.

Another RF alternative would be sound, but the frequency is too low to be able to fit a reasonable amount of data in the signal, and it travels through the air too slowly (our rocket could reach 0.8x the speed of sound). Also rocket launches are audibly noisy, which makes for an all around poor environment for audio communications.

Luckily there are quite a few available RF options for the Arduino. The Arduino Nano 33 BLE Sense even has a built in Bluetooth LE SoC (System on a Chip). Bluetooth LE is a great technology for close-range wireless communications, and it would offer some cool smartphone integrations, but at 100m max range it’s just not strong enough for a rocket that’s built for 1km flight. This limitation also rules out any WiFi options.

The main reason why WiFi and BLE are poor options is because they use higher frequencies to transmit more data at a time. The tradeoff with higher frequencies is that it requires more input power to generate the same amplitude of electromagnetic wave. Since our telemetry system will just be powered by a typical 9v battery, we need a lower frequency radio to be able to transmit further without requiring more power than the battery can supply.

Another design consideration in the US is which frequencies we are legally able to transmit on. Luckily most of the devices that we can purchase online are pre-approved by the FCC and don’t require licenses to operate, but you always want to be careful and make sure you choose a frequency that won’t interfere with important uses such as emergency services, aircraft operation, or life-sustaining medical devices.

US Radio Spectrum Frequency Allocation Chart

The massive chart above shows all of the frequency allocations in the US. Needless to say it’s probably just easier to google search the frequencies you would like to use and read what people are posting about them than to try to figure out licensing from a chart like this.

Installing the HC-12 RF Transciever on the Arduino Nano

I started out building with the HC-12 RF chip, which uses the 433MHz band. These chips are great because they’re tiny, cheap, low power and the low frequency gives them a longer range for less power input. The (massive) downside is that transmitting legally on the 433MHz band requires a HAM (amateur radio operator) license. I don’t have one of these, I don’t want fines, and it will take me a few weeks at least to study and take the test.

I was able to find an alternative 2.4Ghz chip that is somewhat larger with a more limited range, but since my first flights will not be very high power, I probably don’t need the full 1Km range yet anyway.

When you’re prototyping electronics you’re going to need to plug and unplug wires quite frequently, so you don’t really want to be soldering every connection every time (although even when I solder I quite frequently have to undo and redo my wiring). There are a few things that you will need, like resistors, a solderless breadboard, and some connectors. To make this easier I just picked up an electronics project kit that included every component I could possibly ever need. I also have a separate connector kit that I can either use on solderless breadboards, or to make more precise runs on a soldered circuit board.

Prototyping the HC-12 using a solderless breadboard

Another great thing about the kit is that it comes with a knockoff Arduino Uno. I wired this up to another RF module with the same configuration as the onboard system, and it’s ready to rock!

In my next post I’ll discuss exactly how you wire the transceivers to the Arduinos, and the code that is required to run them.

Basic Telemetry – What is the rocket doing? (3)

(I try to link to the products I used so you can find them more easily. If you purchase them from these links I may receive compensation from affiliate programs. I am not employed or influenced by the manufacturers or distributors.)

One important goal for this project is to be able to make automated in-flight decisions and monitor flight progress. To accomplish this we need some kind of flight computer.

Something you may not know about me – I love Arduinos. With just a tiny amount of programming and wiring knowledge you can build almost anything. The Italian rapid prototyping board has dramatically changed the world of inventing and product design. The Arduino system has been used not only by hobbyists, but educators, NASA and even the Department of Defense have been known to employ the tiny prototyping boards in research and development projects.

If we’re planning to keep the body as small as possible, an obvious choice would be the Arduino Nano because of its size. You can even try the Seeeduino, an offbrand controller that claims to be the smallest arduino-based controller on the market.

I wanted more than just to launch a controller board into the air, though. I wanted to know what it was doing. Where is it going? How fast? How high?

To be able to answer these questions you need a few components. The first is called an IMU or Inertial Measurement Unit. IMU capabilities are measured in axes, and axes are grouped into 3’s based on what they measure. The three axes of any 3-dimensional system are X, Y and Z. Think of a 3-dimensional graph:

The three axes, wikipedia.com

In order to understand how something moves in space you need to understand translation and rotation, which make up the first two types of sensor in an IMU. Translation is measured by an accelerometer, linear acceleration and deceleration (which is just negative acceleration) is quantified in g’s of force, which can be best explained as how strong the acceleration force is in comparison to gravity. One g is the same amount of force as you feel pulling you down at sea level, and 5g is five times that amount of force.

Rotation is measured by a gyrometer, which uses degrees per second (dps). 360dps on the z axis means you turn a full circle around that axis in one second. We sometimes refer to these motions by the Euler Angles – “pitch”, “roll” and “yaw” – when talking about flight. This is more difficult with rockets, since rocket bodies are typically symmetrical in two axes, so in rocketry we may describe the rocket as “rolling” if it is turning around the fuselage, but I am less likely to discuss “pitch” and will probably not use the term “yaw”.

Either way, here is a diagram from Wikipedia that more clearly explains how those terms are used in aircraft:

The Euler Angles as they apply to an aircraft

I mentioned that an IMU generally has three types of sensors, but so far I have only described two of them. The third one is called a magnetometer, and it is essentially a three dimensional compass. Magnetometers are essential because they can help tell us the absolute orientation, or attitude, of the rocket.

Now that we know how the IMU works, we need to figure out how to add one to the telemetry system. We could pick up one of the Arduino Nanos I mentioned earlier and connect it with an external IMU board, and there’s nothing wrong with this EXCEPT I want something smaller, and I love integrated components!

After some digging I found that I had started this project right on time, since Arduino had recently released the Arduino Nano 33 BLE Sense with integrated 9-axis IMU (and a lot of other goodies). This meant a simple plug-and-play solution that I could use to measure attitude and motion in flight, and it also meant access to an onboard thermometer, hygrometer and even a barometer, which I could use for measuring altitude.

I won’t go into the details of how to calculate altitude by using barometric pressure, but it is based on the principle that air pressure is generally higher the lower you are in altitude. As the rocket climbs, then, the air pressure should decrease, and some mathematical formulas allow us to use the change in pressure over time to estimate how what altitude we have reached, and we can use the rate of change to determine what stage of flight we are currently in.

Arduino Nano 33 Ble Sense – Amazon.com

Once the telemetry board (new designation) arrived I hooked it up to my computer and wrote a quick program that fed the signals back through the built in serial communications. I noticed that the data was a little noisy (the image below is of me shaking it around – not what I’m talking about) so I added some moving average logic to smooth out the values. Ultimately I took this logic out because I determined logging the raw values would result in the best data, and I could always do smoothing with the raw data at a later time.

In my next post I will discuss wireless telemetry, and the wonderful world of RF comms (Radio Frequency communications).

Arduino IMU data plotted in “Data Monitor”, sketch showing data smoothing

Imaginary Rockets – Modeling, Mocking and Planning (2)

(I try to link to the products I used so you can find them more easily. If you purchase them from these links I may receive compensation from affiliate programs. I am not employed or influenced by the manufacturers or distributors.)

Most people who know me probably wouldn’t be surprised if I skipped the planning phase and just started building a rocket, blindly trusting it would work. Kerbal inspired me, though, and modeling and testing virtual prototypes had its own appeal. I downloaded OpenRocket, and found that on this modeling software, much like in KSP, I could build outrageous designs and test them for feasibility without ever having to worry about the dangers of live testing.

Before I even got started building I figured it would be important to set a few goals of what I would like to accomplish through iterative testing and development:

  • Stable Aerodynamic Flight
  • 1km Apogee
  • 360º Video
  • Aerodynamic control (articulated control surfaces? thrust vectoring?)
  • Remote Telemetry
  • Powered Descent/Landing
  • Maintain Medium Powered Rocket Classification

I’ll go into more detail about each of these objectives in their own posts, but to summarize, I wanted to build a rocket under 1kg that could take a 360º camera up to 1km altitude. Meanwhile, I thought it would be fun if that rocket constantly sent telemetry data back to a computer, and was able to perform some tricks.

At first I thought it might be necessary to build a massive body rocket that can carry larger camera systems, since most 360º cameras are fairly wide, but with some searching I was able to find the Kandao Qoocam 4K – a 360º camera in a stick configuration, which will help greatly reduce the diameter of the rocket, and therefore improve A LOT of the aerodynamics, but I’ll discuss this more in my “Optics” post.

Kandao Qoocam 4K 360º Camera on Amazon.com

A 1km rocket isn’t easy, especially when one key limitation is that I’m not certified to fly anything over a G class motor. We can get further into motor classes and model rocketry certification levels, but suffice to say I was not going to just be able to strap more motors on it like you would in KSP. This time I needed to be a lot more strategic about my design choices.

I spent some time looking around for a suitable rocket modeling program, and settled on OpenRocket because it was straightforward, free, and cross-platform (which meant it would work on my Mac). There are a lot of great modeling programs out there. They range from simplistic, like OpenRocket, to complex all-purpose 3d modeling suites. Choose one based on your level of comfort or ambition, and employ google search liberally.

In OpenRocket you can change each of the design parameters of your craft, including weight, roughness, shape, placement, motors and timing. One major setback is there seems to be a bug when running on OSX that causes it to crash when switching back to “Side View” from other view modes.

Another big setback of OpenRocket, but also almost all model rocketry software I encountered, was that it isn’t built for modeling electronically influenced flight plans, such as off-engine recovery methods, chute delays, dynamic flight control or electronically timed staging. It’s not the end of the world, and I’m probably one of very few people who have this complaint.

The first versions of the MarkDart were very bulky. Before I found the Qoocam, large cameras led to large bodies, lots of engines, and ultimately nowhere near Medium Power classification.

OpenRocket rendering of an early, unfeasible version of the MarkDart

As you can see from the image above, it would have been a BEAST of a rocket, both in size and trajectory. While I would have loved to violate FAA airspace regulations, I’m not entirely confident I’m ready to be able to light 3 motors simultaneously, and the risk of rapid unscheduled disassembly would have been altogether way too high.

Another early/scrapped MarkDart design

Moving to the Qoocam allowed me to be a lot more realistic about the design, ultimately settling for a one-engine vehicle with a 41.6mm diameter body. The rocket would have a clear payload tube for the optics payload (that’s aeronautical engineering lingo for the camera), and a fiberglass engine/parachute compartment.

The final MarkDart1 design before ordering parts

In my next post, I will discuss building a system to understand what the rocket is doing at any given point in time, also known as telemetry.

Introduction – Space Frogs (1)

(I try to link to the products I used so you can find them more easily. If you purchase them from these links I may receive compensation from affiliate programs. I am not employed or influenced by the manufacturers or distributors.)

I think just about everyone has taken up a new hobby during the COVID pandemic. It just so happens that I spent a fair portion of our time in “quarantine” playing Kerbal Space Program, which inspired me to rediscover my love of rocketry. It wouldn’t be nearly as interesting, though, without a pile of convoluted tech. As it stands, I’ve only built one such rocket, and it only carried a small, somewhat dysfunctional remote telemetry package. Now I will start with the second generation of what I’ll nickname the markdart, and I’m going to try my best to blog about it.

I’m not making any commitments about the quality or accuracy of this blog. I’m not an engineer, this is not an “instructable”, and you should assume nothing I write about is safe, well planned, accurate, or best-practice.

What I do hope you take away from this blog is an inspiration to explore science and engineering without fear.

Kerbal Space Program

What do frogs have to do with rocketry? It’s not about the ballistic flight of amphibians post-leap, or the aerodynamic drag of pear-shaped amphibian bodies. It’s about simulation, exploration and inspiration.

Kerbal Space Program (KSP) is a game that lets players build and fly rockets and space planes, while employing realistic-enough physics modeling that teaches physics and engineering concepts like aerodynamics and orbital mechanics. It’s a beast of a game, with infinite possibilities, and some really fun missions that push players to build toward planetary exploration and scientific discovery.

The best part about KSP is that while fun and engaging, it’s a powerful learning tool for all ages, since it lets you experiment without fear of the consequences of real-world failures. Rockets are expensive and fail hard, so it’s way easier to experiment on a computer than on a real launchpad.


After countless days spent on KSP imaginary rockets weren’t enough, though. It was time to build something real.