Reference / Paper · 2025
Peak of Flight #656: From Paris to Apogee: A Tale of Two (Three?) Eiffel Towers Part 2
Apogee Components' Peak of Flight newsletter, issue 656 (2025-07-15).
- peak-of-flight
- apogee-components
- model-rocketry
Reference / Paper · 2025
Apogee Components' Peak of Flight newsletter, issue 656 (2025-07-15).
Apogee Components' Peak of Flight newsletter, issue 656 (2025-07-15).
Issue 656 / July 15th, 2025 Apogee Components, Inc. / ApogeeRockets.com / Colorado Springs, CO From Paris to Apogee: A Tale of Two (Three?) Eiffel Towers Part 2 Eiffel Tower Successful Flight at 2025 NSL La Jara, CO Issue 656 / July 15th, 2025 COVER PHOTO The 'Nose Cone' on the Eiffel Tower Model Rocket FEATURED ARTICLES From Paris to Apogee: A Tale of Two (3?) Eiffel Towers Part 2 by Martin Jay McKee Part 2 of 2 articles examining the path to a successful flight for the custom Apogee Components Eiffel Tower Model Rocket. Apogee Components, Inc. 4960 Northpark Dr. Colorado Springs, CO 80918 1-719-535-9335 www.ApogeeRockets.com About this Newsletter You can subscribe to recieve this e-zine FREE at the Apogee Components website: www.ApogeeComponents.com, or by clicking the link here Newsletter Sign-Up Editor-in-Chief: Tim Van Milligan Managing Editor: Michelle Mason Content Editor: Martin Jay McKee Layout Design: Ogden Sikel 2 Would you like to see your launch photo featured in the Peak-of-Flight newsletter? Submit your photo at apogeerockets.com. From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Pt. 2 by Martin Jay McKee In part I of this article (Peak of Flight #655), I shared the flight testing and analysis behind the first version of my Eiffel Tower rocket, along with some of the interesting challenges. The goal? To fly a scale model of the Eiffel Tower higher than the height of the real one: 1,086’ (331 m). Despite some creative data analysis attempts using genetic algorithms, the limited flight data wasn’t quite enough to pin down a believable drag curve. The results were interesting, though not yet acceptable. It was just enough to justify some of the assumptions made about the overall form of the drag curve, and to convince me that the challenge was still worth pursuing. In this second part, I’ll walk through the flights of the version 2 rocket, how the improved data logging made better drag estimation possible, and how those estimates ultimately led me to a successful altitude attempt. Along the way, we’ll explore even more analysis techniques, battle more practical difficulties with a building-shaped rocket, and consider ways this work might be improved and adapted for future projects. While the Eiffel Tower may be a silly project, and a silly shape for a high-flyer, the insights this project inspired are anything but. Figure 1: The second version of the Eiffel tower was externally all but identical to the first version except for being 20% larger and stepping up from a 29mm to a 54mm motor mount. 3 From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com The Need for More Information My original intention for the version 2 rocket had been to select a single motor that I hoped would achieve the desired altitude and simply hope for the best at NSL West. There was not supposed to be another flight test program working toward the altitude attempt flight, and this second part of the article probably wouldn’t even exist. A few weeks before NSL West 2025, I realized that my total lack of knowledge regarding what motor I would need to have a genuine chance was causing me stress. As such, I felt it important to fly the new version of the rocket on smaller motors to collect data that could be used to choose a final altitude attempt motor. In order to give the Eiffel Tower a gentle ride toward the goal, I was still targeting the Aerotech J99 (though I had been unable to acquire one despite having looked for several months). Thus, for the first test flight, I chose an I65 as a motor with a similar thrust profile and (estimated) maximum velocity. I did a couple of deployment tests in the Apogee Components parking lot to ensure that I had nailed down a reliable black powder quantity to safely eject the laundry (which was uncomfortably tight) and arrived at the launch on a somewhat breezy but otherwise beautiful day at SCORE in Pueblo. Having prepped the rocket (and having been appropriately taunted for intending to fly a foam core Eiffel Tower on full ‘I’ power), the button was pushed and the Eiffel Tower ascended to the air to an altitude of 599’. There were a couple of things of note even before the data could be processed. First, the nearly 600’ of altitude was somewhat under the full potential as the latter portion of the flight had, indeed, ended up horizontal. In fact, the vertical flight had slowed so rapidly that the motor was still producing thrust (albeit a very small amount) when the Blue Raven detected apogee and deployed the parachute. Secondly, a rough estimate of altitude vs total impulse implied that the J99 would, unfortunately, be insufficient to reach my desired altitude. Nevertheless, the flight was all but perfect. The parachute deployment was clean, and the rocket landed without damage. The basic summary of the flight is shown in Figures 2 and 3. Figure 2: The initial flight of the Eiffel Tower was on an Aerotech I65 to a height of 599’ (183 m). Plotted here are the measured vertical acceleration, vertical velocity, and altitude between liftoff at t=0 seconds and at apogee. This data was used in combination with the known weight of the rocket to estimate the Cd at different velocities. Coefficient of Drag and Motor Selection In a recent Peak-of-Flight (“Finding the Coefficient of Drag of your Rocket” #651), Tim Van Milligan discussed the process of calculating the coefficient of drag (Cd) of a rocket directly from the known burnout mass of a rocket, along with flight data from a datalogging altimeter (specifically, velocity and acceleration). I had chosen to use the Blue Raven as my deployment electronics for one primary reason. All I needed from a control standpoint was an apogee charge – any number of altimeters on the market could work for that. What made the Blue Raven stand out is its ability to record 4 Figure 3: Due to the low thrust at the end of an Aerotech I65’s burn, the Eiffel Tower rotated quite a ways off of vertical over the flight. This graph shows that there was a rapid rotation to around 15 degrees from vertical when the rocket cleared the launch rod, but then continued to rotate, reaching 100 degrees ( pointing slightly down) at apogee. This data was used to correct the estimated Cd for non-vertical flight. From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com Figure 4: The force diagram for the simplest method of Cd estimation found in equation 4. This method assumes perfectly vertical flight with a drag force pointing directly down with gravity and thrust pointing exactly against both. accelerometer and gyroscope data at 500 samples per second. I knew that I needed more data than I had collected on the first version to have a better chance of calculating accurate coefficient of drag measurements. As much as I love the properties of genetic algorithms as an optimization method. No optimizer is able to work without sufficient information. Model-based optimizers (see, for example, reference 1) take advantage of precious knowledge of how a system functions. With significantly more CFD analysis, I could possibly have generated a model to be used in such a model-based approach, but given the computational requirements of CFD, a more ad hoc approach was required. Due to the unique flight characteristics of the Eiffel Tower as compared to the standard rockets that Tim was describing in his article, it would not be possible to simply estimate the Cd curve from the coast period of the flight. This is because, in my flights of the first version, the coast period had been less than a second, regardless of the motor it was flown on. It honestly looks like the rocket hits a wall as soon as the thrust ends. This is reason that electronics had been installed in the first version. Motor deployment was always late. It had worked on some flights (due to the low terminal velocity of such a draggy rocket), but simply counting the data from the coast period would not result in sufficient data to complete the analysis. The best solution, then, was to estimate drag while the rocket was still under thrust. 5 From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 In theory, estimation of Cd while the rocket is under thrust is no more difficult than estimation while the rocket is coasting. As described in the earlier article, the process is to subtract out known forces, assume whatever remains is drag, and then calculate the coefficient of drag from that force. In the previous article, the forces considered were drag and the weight of the rocket (due to gravity). Since there are thrust curves for engines available, all that needs to be done is to subtract out the thrust at each time and use an estimated engine mass to calculate the rocket mass at each time step. Assuming the rocket is traveling perfectly vertically, the equation to solve should look something like the following: Where Tk is the thrust at each time step, mk is the rocket mass at that time, and ak is the acceleration (in the vertical direction) recorded by the flight computer, and g0 is the acceleration due to gravity. As presented in part I, drag can be further expanded as: Where Vk is specifically the velocity of the rocket in the vertical direction, and Cdv is the coefficient of drag of the rocket at that specific speed. It was important to calculate the coefficient of drag at multiple speeds because the data from the first version demonstrated that the Cd value varied with velocity, though the first approximation did not have high enough fidelity to show precisely how it varied. This is likely a result of the flow transitioning from laminar (at low speeds) to turbulent (at higher speeds). Total mass was calculated in the same way as outlined in the first part of this article, where: Such that the engine mass (me) is a function of the total impulse consumed, and the total mass (m) is simply the sum of the empty weight (m0) and the engine weight. As mentioned in part I, this is only an estimate of the engine weight over time, but it has proven to be quite an accurate estimate. 6 www.ApogeeRockets.com From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com Combining equations 1 and 2 and solving for Cdv, we find that: This final equation was used to get some initial Cd plots from the first flight of the version 2 Eiffel Tower. In this case, the acceleration term, ak, was taken to be the acceleration in the vertical direction. The resultant plot looked significantly better than the results from the first flight program. Still, equation 5 was quickly replaced because of a rather obvious source of inaccuracy. The portion of the flight I was calculating Cd over was not all vertical. The long-burn motors that the Eiffel Tower is flown on tend to have regressive burns (the thrust dropping consistently throughout the burn), which leads to the rocket weathercocking significantly in anything other than still conditions. Because there was limited time and flight opportunities before NSL West 2025 (an entirely arbitrary deadline for reaching the target altitude), the estimates needed to be as accurate as possible after only a couple of flights, and, as such, motion other than strictly vertical needed to be taken into account. The equation used for the bulk of the analysis is very similar to equation 5. Rather than a simple force diagram where thrust is pointing directly up and both drag and gravity are pointing directly down (see figure 4) a more complex force diagram was required that took into account the angle of the rocket (figure 5). Luckily, in addition to acceleration data, the Blue Raven provides rotational data. To correct for a non-vertical flight profile, the integrated orientation (also provided directly in the Blue Raven datalogs) was used to determine the angle from vertical, ak. The final equation corrected the weight contribution for a non-vertical flight profile. Figure 5: To take advantage of rotation data, equation 6 scales the contribution of the rocket weight. In this form, the force diagram shows that the weight contribution is not aligned with the drag and thrust. Rather, thrust and drag are in direct opposition while weight is projected onto the longitudinal axis based on the angle of rotation from vertical. It should be remembered also that, unlike equation 5, this equation treats the acceleration ak in the direction of travel of the rocket, that is, along the axis of the rocket, rather than along the vertical. For a vertical flight, of course, these will result in the exact same thing, but for real flights, they will diverge. This equation (which also has problems to be examined later) was used for all of the coefficient of drag determination prior to the altitude attempt flight at NSL West. In order to use the estimated Cd, especially from multiple flights, it is important to be able to combine the data in a simple way. The way that I chose to do this, mostly because it is simple to do so, was to use regression to fit a curve to the many sample data points that I had as a result of processing the flight data. Now, for simplicity, I used a polynomial regression to fit the calculated Cd vs V data (overview in reference 3) and a third-order equation as my fitting polynomial. This was an entirely arbitrary choice based on ease of use and speed of implementation. After flying the Version 2 model three times, I had significant data that could be used for fitting a curve. The estimated Cd curve from two of the flights matched almost exactly: Flight 1 on the I65 and Flight 2 on the 7 From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 J180, while Flight 3 displayed noticeably higher Cd values. Flight 3 was also undertaken in significantly higher winds than the other two, so the higher apparent Cd was almost certainly a result of higher drag due to that crosswind. Taking the data from the maiden flight only (on the Aerotech I65), Figure 6 shows the general form that the polynomial regression takes. It is evident that the curve fits relatively well, but the polynomial fit is used only in the range of measured velocities to ensure that unknown values are not extremely large or small as a result of an ill-fitting approximation. 8 www.ApogeeRockets.com Figure 6: This graph shows the coefficient of drag as estimated from the measured data along with the polynomial fit (in green) for the first test flight of the version 2 Eiffel Tower on an Aerotech I65. The estimated Cd values can be clearly seen to form two wide bands, one above the other. The lower band is the data from early in the flight where the velocity is low but the motor is producing maximum thrust. It is possible that this represents a reduction in base drag due to the effects of the exhaust plume. While similar results were seen in the data from all the flights, this wasn't included in the overall analysis as it represents so few datapoints in total. From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com Of course, once the coefficient of drag curve is estimated, it is used to estimate the altitude that the rocket can achieve with additional motors. Because equation 5 models rotation as well as vertical motion, a very simple 3-degree-of-freedom simulation was created to simulate the motion of a rocket in vertical and horizontal directions as well as in rotation around the center of gravity. The rotation can be driven by input data to reproduce the flight profiles from the test flights more accurately and, therefore, to make it more likely to replicate the flight correctly. The simulation really simplifies to a simple one-dimensional model (as was used for estimating the altitude of the first version) when used with potential motors. One thing this means is that the simulation is assuming a perfectly vertical flight and, therefore, a flight conducted with almost no wind. This fact made it clear that unless I found a motor that would exceed the target by a big margin, I would have to limit my altitude attempt flights to days where there was very little wind. Data Collection and Analysis & More Repairs Using the Cd estimation methods described in the last section, it became clear that the J99 was simply not up to the task of reaching my desired altitude. Given that I couldn’t find one to purchase anyway, that wasn’t a major problem, but the question that remained was, “What motor will work?” Somewhat uncomfortably, my calculations implied that I would need a K185. Somehow, the idea of jumping all the way up to a K motor in this particular rocket was moderately distressing, despite the history of the first version handling any motor that would fit. Given that my biggest concern after the flight on the I65 was that the structure of the model could stand up to the velocity of a K185, I decided to fly the rocket again at the next launch. Specifically, I wanted to fly it on a motor that would get it up to (or at least near) the velocity that the K185 would achieve. An Aerotech J180 was a good fit for a motor that got the rocket close to the same maximum speed, and I actually had one in my stash, so it was a no-brainer to use it. The flight was good, almost perfectly vertical to an apogee of 603’ (184 m), but there was damage as a result of a mis-packed parachute. This flight did result in some repairs due to the front of the rocket being crumpled on landing. However, this proved to be for the best because I was able to improve the handling of the ejection charge and enlarge the area for the parachute (as discussed in Part I). The data from the J180 flight was absolutely beautiful and the calculated Cd curve fell right on top of that from the I65 flight, so that was a solid vindication of the first test. Truth be told, the corroboration between the first two flights had generally convinced me that the K185 was a good option for an altitude attempt. Especially given the high altitude in Alamosa, I was pretty convinced that the K185 would successfully reach the Figure 7: This plot shows the estimated coefficients of drag for the first two flights of the larger (version 2) Eiffel Tower. The blue data represents the first flight on an Aerotech I65, while the green data represents a flight on an Aerotech J180. As can be seen, the data appears to match well for velocities larger than about 30 meters per second. However, for slower velocities, the estimates for the J180 motor flight end up being significantly lower. 9 From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com target. As such, I brought a 54/1706 casing and a K185 from our stock at Apogee just in case I decided to make the attempt (and, if I didn’t, I could always put them back). I had also brought a Cesaroni J145 long-burn Skidmark to NSL West. That motor was 100% intended to just put on a show. Obviously though, data is data, and I was able to get just a bit more information. When I flew the Eiffel Tower on the J145, the wind was fairly high which led to quite a bit of weather cocking. In addition, the rocket acquired quite a bit of horizontal velocity during descent, which led to some damage to the base legs of the Eiffel Tower when the rocket hit the ground sideways. Repairs were necessary, but not difficult. Figure 8: All of the estimated Cd values vs velocity for the three test flights (Aerotech I65 in dark blue, Aerotech J180 in green, and Cesaroni J145 in cyan). This graph demonstrates both the close match between the first two flights (I65 and J180), and the large deviation with the J145. While higher, however, the steep increase of the J145 estimate at low speeds (less than 30 meters per second) seems to match the shape of the I65 flight better. 10 From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com The night following the flight on the J145, I sat down to run the analysis one more time to make a decision about whether I would make the attempt with the K185. Using different combinations of the data from the three flights, I got estimates of 1040’ - 1090’... uncomfortably low. Then again, the estimates were still being done with an arbitrary multiplier to make the estimates fit more accurately, and when I ran the flight on the I65 and J145, the altitudes were underestimated, even when the flight on the J180 was accurately estimated. So, the decision was made to go for the target altitude given good enough weather conditions and minimal wind. Figure 9: The optimized fit of the 3rd-order polynomial to the three test flights (with Aerotech I65, Aerotech J180, and Cesaroni J145) shows moderate deviation at high velocities (due to the drooping leg of the graph), while at low speeds, the data from the three flights diverges significantly causing the regression to choose a central path. This regression resulted in an estimated altitude of 1040’, while a regression to only the first two flights (Aerotech I65 and Aerotech J180) resulted in an estimate of 1080’. 11 From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com Vive la tour Eiffel! Arriving nice and early (or, as early as I could) to the launch on Sunday, 25, 2025. I was met by absolutely perfect conditions. There was almost no wind, and it was not yet overly hot. It was an excellent day for a low-stress altitude attempt. Since I did not want to spend any money unnecessarily, I did not build the motor the night before, waiting, instead, to see what the weather was like. Since everything was as positive as it could be, I decided to proceed. I built the Aerotech K185 and installed it into the rocket (increasing its weight by a factor of three in the process!). Then I checked the functionality of the Blue Raven altimeter and the ematch continuity before filling and installing the ejection charge. Finally, I carefully z-folded the shock cord and folded the parachute before installing all of the recovery system. After filling out the flight card, the Eiffel Tower was very shortly on the pad, ready for flight. Of course, any major launch is going to be fraught with delays and somehow the flight queue slowed to a crawl as soon as the Eiffel Tower was ready… or, at least, it felt that way. It was a massive surprise how anxious I was for this particular flight. In hindsight, I’ve realized its not that surprising however. I was preparing to launch a foam-core board rocket on a K motor. The first one I had ever flown, and the most expensive single flight I’d ever done. In addition, if the flight failed to reach the target altitude, there wasn’t much I could do. As outlined right at the beginning of part I, the question that I had to solve wasn’t a theoretical one; it was a practical one. I wanted to find a motor to get a real, physical, Eiffel Tower above 1086’ (331 m). The Aerotech K185 was one of my only options… unless I stepped up to an Aerotech K270. That would require investing in a new 54/2560 casing, and it wouldn’t even really fit in the version 2 rocket. If the K185 didn’t work. I might just be stuck. So with all that running through my head, I waited as rockets were slowly sent on their way. Then, finally, time for the launch of the Eiffel Tower—a huge flame erupted from the base, and the rocket climbed skyward perfectly straight, and just kept going. Right at apogee, the parachute was deployed crisply, and the rocket floated majestically down to a landing just a short distance behind the pad it lifted off from. There was no question it was a beautiful flight. But the real question was, did it fly high enough? As the reader, you know the answer. Yes. It was successful. Otherwise, why would these articles exist? I wasn’t quite released from my anxiety yet, though. When I went to pick up the rocket, the Blue Raven began downloading the data (as it should), but showed a summary with an apogee altitude of 0 feet. You’ve got to be kidding me! Anyway, when I was back at my car, I exported the flight data and was able to process it on my laptop. 1151’ (351 m), success. In fact, I beat the target altitude by nearly 6%, approximately the altitude of my first Eiffel Tower flight. 12 Figure 10: A liftoff photo of version 2 of the Eiffel Tower. This flame being equal in length to the rocket is impressive given that the K185 that carried the rocket to 1151’ (351m) is a long-burn motor that takes its time to burn entirely. The Eiffel Tower is only just getting started in this image. From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com While the Blue Raven had a hiccup with the creation of the data summary, it collected all the data just as expected. The flight summary, seen in Figures 11 and 12, shows an absolutely perfect flight that was surprisingly close to the estimated performance with a K185 motor. An altitude error of 6% would not be unexpected in a standard rocket design software like RockSim, even when simulating a very standard rocket design. So, the fact that collecting the data from only three flights resulted in errors of well less than 10% (worst case) on the magnitude of the coefficient of drag curve is actually quite impressive. Actually achieving the target altitude after more than two years of work is a nice result, but so is the functionality of the data analysis processes that got me there. Figure 11: A summary of the acceleration, velocity, and altitude of the altitude attempt flight from takeoff (t = 0) to apogee (marked by the vertical magenta line). This is the raw data and several unusual spikes are visible in the acceleration data. Moreover, just before 1 second there is a strange dip in the detected altitude (from barometric sensor readings) that is likely a result of the non-ideal placement of vent holes on the sloped sides of the Eiffel Tower. Figure 12: The off-axis plot of the K185 altitude attempt flight shows how extremely vertical the rocket traveled. At rail tip off, there is an obvious jump (around t=0.4 seconds), but the angle remains almost constant until t=8 seconds, just before apogee. Up until apogee, the largest tilt is roughly 25 degrees, for a beautifully vertical flight. 13 From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 Error Source Polynomial Cd Fit Crosswind / Wind Variation Angle of Attack (AOA) Velocity vs. Mach Number Atmospheric Conditions Flight-to-Flight Scaling Limited Flight Set www.ApogeeRockets.com Description Used an arbitrary 3rd-order polynomial to fit Cd vs. velocity curve Different wind speeds and directions caused weathercocking and drag variation Cd was estimated without considering orientation vs. flight path. Used velocity directly instead of Mach for Cd modeling Pressure/temperature not corrected for actual flight dat weather Used single global multiplayer (e.g. 0.83) rather than per-flight tuning. Only three test flights used for drag curve fitting Improved Cd Estimation: The future Even the final estimates prior to the altitude making K185 flight were less consistent than I would have liked (a maximum error of 9.56% and a range of 4.35%. No doubt, some part of that variance is a direct result of the inevitable imperfect data. However, there is also a high likelihood that some portion of that inconsistency is the result of the simplified approaches that were taken to estimate both the instantaneous coefficient of drag as well as the smooth coefficient of drag curve. There are several ways that the data could have been used more effectively and there is the possibility that additional data could greatly improve the accuracy of the estimate. The variance in altitude estimates prior to the K185 flight is likely a result of several interacting error sources. These include assumptions in the Cd curve fitting process, environmental variability, and limits of the instrumentation setup, as seen in Table 1. A first point worth considering to improve consistency is that the equations used to estimate the Cd for the altitude attempt flight were theoretically well grounded, but did not return Cd curves that resulted in altitude estimates that matched all the measured flight altitudes. In fact, they were overestimating the drag in most cases. To better estimate the altitude, I made a totally arbitrary decision to multiply the estimated Cd values so that the estimated altitude on the J180 flight (which was the most vertical test flight) was as close to correct as possible. The “magic” number ended up being 0.83, for a Cd estimate of nearly 20% too large. Of course, this presupposes that the shape of the Cd vs. velocity curve was accurate, but that the magnitude was uniformly too high. That’s highly unlikely to be the case. In fact, because the simulation continued to underestimate the altitude of both the I65 and J145 flights with the change, its undeniable that either the Cd estimate or the 14 Likely Impact Moderate; affects shape Moderate to high Potentially high in windy flights Low for subsonic speeds Low (<1% estimated error) Moderate; affects Cd magnitude Moderate; risks overfitting Table 1: A list of primary sources of errors in the Cd estimation and altitude prediction algorithms along with some likely impacts. Many of these error sources can be improved with simple changes to the current code. Limited flight data is only solvable by expanded flight data collection but the effects may be minimized by better modeling and reductions of errors elsewhere. Some of the errors (such as crosswind and angle of attack effects) can only be fixed with the addition of other data sources. flight simulation was insufficient in some way. One approach to improving this source of error is to individually scale the data from each flight to most closely match the measured altitudes. The only reason that this was not completed prior to the altitude flight was time constraints. Before this processing system is used for another project, it needs to be added. From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 Another potential source of error has to do with the class of curve that is being fit to the estimated Cd points. To this point, I have used a third-order polynomial for fitting, that is, the coefficient of drag is assumed to be generally fitable by an equation of the form: Cd = C0V3 + C1V2 + C2V+ C3 Where V is a velocity in the range of the minimum and maximum measured Cd estimates. For velocities smaller than the minimum measured value, the minimum velocity is used and - similarly - for velocities higher, the maximum velocity is used. This model seems to have done a good job of estimating the curve reasonably accurately (after all, my estimate of the K185 flight was only low by 6%), but there is no physical reason that a third-order polynomial should be the correct model. Having looked at the curves more, I get the feeling that either piecewise linear fits or spline functions would be the best option. It’s worth exploring, as this is a place where further study could provide both interesting information and greater accuracy. While unlikely to be an actual source of error in this application, it would certainly be preferred that the coefficient of drag curve was estimated in relation to the Mach number rather than the velocity directly. I specifically made the choice when first writing the code to stick with velocity because it made reading the graphs much simpler. It was easier to mentally map the Cd at different points to my mental model of the flight. Moreover, the plotting of graphs can easily be done in relation to velocity even if the internal relation is to Mach number. Due to their higher speeds, Mach would be much more appropriate for standard rockets that, unlike a foam-core board Eiffel Tower, are likely to approach or exceed the speed of sound. As a point of interest, the maximum speed that the Eiffel Tower was measured at was over 200 mph; that’s not bad for what is effectively a paper and expanded polystyrene lampshade! Anyhow, reformulating the analysis and simulation code to use the measured Mach number rather than the velocity is a simple and straightforward way to make it more widely applicable in rocketry, and this should be done moving forward. This project only got away with the simplification because the maximum velocity of the Eiffel Tower was so far from the transonic region. www.ApogeeRockets.com Figure 13: A final composite of all the Cd estimates from the version 2 Eiffel Tower flights. The magenta data is for the final (altitude attempt) flight on the K185. The cyan data for the Cesaroni J145 flight. Green data and blue data (mostly hidden) for the Aerotech J180 and Aerotech I65 respectively. The final flight tracks extremely well with the previous flights. 15 From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 Yet another source of error is that the predictive simulation used only the velocity to estimate the coefficient of drag. This was of necessity, as the data that I collected from the Blue Raven did not allow for anything more than that. It is well known, however, that the angle of attack (AOA) of an aerodynamic body often has a large effect on the overall coefficient of drag. While an absolute measure of AOA requires something like a purpose-built probe (such as the multi-port probe outlined in reference 4), it may be possible to combine the IMU data (accelerometer and gyroscope) of the Blue Raven with GPS data (from, for instance, a Featherweight Tracker) to get an estimate of the angle of attack. Using GPS to track the actual path of the rocket and the IMU to track orientation, it would be possible to get an approximate angle with respect to travel. This may, very well, miss some wind-related effects, but it should provide a first approximation. With directly measured AOA data, Cd estimates could be improved greatly, but even this approximation (using readily available equipment) would be a step in the right direction. While not a potential error source, there was one source of cross-validation data that I did not tap for the version 2 Cd curves: the data from the original five flights of the version 1 model. As mentioned above, an arbitrary multiplier of the polynomial fit of the curve was used to make the simulation results more accurate. In addition to using a multi-pass procedure where the multiplier is automatically determined, it would also be possible to use the original flights to help identify the best multiplier. This would end up being something of a hybrid of my initial fitness-based optimization approach to finding the best curve and the later calculated estimates. What is handy about using the initial flight data, however, is that it is a completely separate source of information. Assuming that the rocket is flying fast enough that the flow is in the turbulent region (which, according to the most recent data, should be the case for even the E16 flight of the first Eiffel Tower), the Cd curve should be almost identical between the two models. As such, while the initial data was insufficient for the calculation of the curves in the first place, it could provide a useful validation for the calculated values that minimize the possibility of overfitting. A final point worth examining here is that all of the flights were done on different days and at two different locations. The atmospheric conditions were different for each flight, but I did not record the actual barometric pressure or temperature to correct the atmospheric model for the exact flight conditions. This is likely to only result in small errors in the estimates, likely no more than 1%. That said, one major advantage is that because the flight location, time, and date are known for all of the version 2 flights (quite accurately, since the Blue Raven uses the date and time from the controlling smartphone), historical weather data can be used to make such 16 www.ApogeeRockets.com Figure 14: The plot compares the acceleration, velocity, and altitude vs time of the actual, logged, Aerotech K185 flight (gray) and a simulated K185 flight (green). This simulation is based on a Cd curve that was generated using all of the collected data (the altitude attempt flight included). The measured peak altitude is, of course, 1151’ (351 m) and the simulated flight has an apogee of 1076’(328 m). Thus, the simulation has an apogee error of 6.51% below the altitude. From Paris to Apogee: A Tale of Two (or Three?) Eiffel Towers Part 2 Issue 656 / July 15th, 2025 www.ApogeeRockets.com corrections after the fact. This is another addition that I have not yet explored, but feel is a well-justified addition given the fact that such data is widely available now. In fact, it would even be possible to make the acquisition of any weather corrections automatic if a weather data API were added to the code currently used to process the flight data logs. Goals for the Future I’m sure I’ll fly the Eiffel Tower again. It’s too much fun not to. But, I feel pretty satisfied with the project as it was initially envisioned. Not only did the rocket hit the target altitude, but the pre-flight estimate was surprisingly close to the actual flight. I do have other crazy ideas tickling the back of my brain, of course. Maybe other similar high-altitude architecture. Burj Khalifa to over 2,717 feet, anyone? Perhaps not; we’ll see. More realistically, I will continue to refine the drag analysis and flight prediction tools that I developed to do the estimation. Flying a model of the Eiffel Tower over 1086’ was an absolutely silly proposition, but it guided me toward needing to solve many real engineering problems. From the parsing of high-rate flight data, to estimating and refining Cd curves, and finally prediction of the rocket’s altitude, there were many places where I had to stretch my knowledge to find a practical solution. The beauty of this approach is that it is entirely agnostic to the rocket. It could be used just as well with a minimum-diameter carbon-fiber dart as with a mid-power sport rocket, a middle-school science-fair project, or a card and paper model of the Notre Dame Cathedral. Across the board, the same framework applies. I plan to release the code I wrote on GitHub once it’s cleaned up a bit. For now, however functional it may be, the code is a mess. The project has already helped me validate two independent methods for estimating a rocket’s drag curve. And, while the genetic algorithm approach fell short with sparse data, I’m eager to revisit it now that I have a richer dataset. Ultimately, what I value most from this project isn’t the successful altitude attempt – although that was satisfying – but how much I learned in the process. If there’s a takeaway here, it’s this: we all need a “silly” project. It should be ambitious, maybe even a bit impractical. That’s the only way that a project will push us to learn and experiment in the corners of our hobby well beyond our comfort zone. Whether it is an extreme altitude or speed goal, a complex group project, an extremely involved finishing job, or a meticulous construction job, go find a project that will push you to do better. A project need not require large motors or electronics to inspire us to learn. Constraints make us creative. I’m not sure