The second flight of the Progeny Mk5 was another success and very similar to that of the first flight in terms of trajectory and timing, which is a good sign because both flights were flown nearly the same way. As mentioned in our analysis of the first flight there were errors made in pitch calculation and TWR during the ascent which were corrected in this ascent. The changes were minor and did not affect the flight all that much – both rockets reached a 94km apokee and did so within one second of each other, both landed within 2 seconds of each other and both traveled the same amount of distance within 1km. During this flight the Automated Flight Control System took greater control over the rocket, decoupling the spent boosters, shredding the 3rd stage fins and actively monitoring the pitch. Flight controllers only had to activate the engines and throttle the 3rd stage to maintain a TWR of 2. The extra instructions running during the initial ascent up to MECO led to a greater power draw, but we also optimized the code that was checking for the parachute to be deployed and actually landed with more battery power available. There are several things we plan to do for this third flight based on the telemetry data that we have reviewed and also given that this flight will be the first to carry instruments in the payload section.
Greater Automated Control
We will have the computer take over operations for two additional aspects of the flight: payload instruments and engine ignition. The payload instruments will be controlled by a routine that will be called once the rocket has reached a predesignated altitude (in this case, simply reaching space). The routine will be loaded in as a separate instruction set so it can be easily tailored to changing payload instruments. The engine ignition will occur once the pitch has fallen below a certain change threshold, currently set to 1.5°. The code testing this was effective and launch controllers exhibited a 1-3second delay in igniting the engines during this last flight. We also placed test flags to trigger if the rocket fell below 100m/s of vertical speed, which it did during the second stage coast. This means we know the computer can handle also igniting the engines if this backup criteria is met.
Separation Coasts
The graphs above depict the angle of attack (over time in seconds) the rocket experienced during its powered ascent, and you can see that the second flight experienced a larger precession after the 1st stage separation which led to a much larger wobble once the second stage was detached, which is why the coast period after the second stage is 5 seconds shorter than the first flight (which may not sound like a lot but the first flight coast before third stage ignition was only 9 seconds). We believe this is due to the computer being so fast at detecting engine flame-out and decoupling the boosters that the thrust has still not fully tapered off and thus the lower stage bumps the upper stage slightly. We’ll be placing a 1 second hold on decoupling the boosters after flame-out is detected for a cleaner separation, which is roughly the same period taken by an actual launch controller’s reaction time. This one second hold will not be a simple wait statement because that could potentially interfere with accurate data logging, so will instead lead into a new run state.
Throttle Control Testing
The last thing we need to test before we can be hands-off the entire flight is the computer’s ability to calculate the amount of throttle needed to maintain a set TWR during ascent. We won’t always be using a constant TWR during ascents but we want the option to do so. The code will currently be built into the logger, and will output the calculated throttle percentage next to the column that displays the actual throttle percentage. Launch controllers will manage the throttle to hold a TWR of 3 during the 3rd stage ascent and we will see how the numbers match up after the flight.
Better Data Logging
We’ll be making several improvements to the type & amount of data being logged during the flight:
- Distance traveled is still wrong, and we will once again attempt a new method at calculating it
- The telemetry spreadsheet will include a Mission Elapsed Time column in seconds
- The time stamp in the operations log will use leading zeroes and default 00.00 for whole minutes to make the log entries more uniform
- In an embarrassing oversight, the dynamic pressure column in the telemetry spreadsheet has been outputting values in units of standard atmospheric pressure rather than pascals. We will alter this to output in kilopascals (kPa)
- Additional time markers in the operations log will include reaching MaxQ, leaving the atmosphere, entering the atmosphere and reaching 70km apokee during ascent
We should have these changes finished and uploaded to the AFCS repository tomorrow.
