After numerous delays the third flight of the Progeny Mk5 was able to lift off into perfectly clear skies and light winds. While we had hoped for this flight to be the first fully-automated rocket flight in the initial planning for this launch series, we had to test one last little bit of code which meant although the majority of the actions on this flight were computer-controlled it was still not yet fully automated. The good news however is that review of the telemetry data has shown that the test code used to calculate the needed throttle for a specified TWR worked flawlessly and we can integrate it into our fourth launch for the first fully-automated flight. Not all the new code worked well however. For now, we have taken out the distance traveled measurements from the logger until we can determine a better means of devising this metric on the rocket itself. We will continue to use radar monitoring to track the rocket’s travel distance as it heads downrange.
The logging improvements worked out well, and the operations log is a lot easier to read with a well-defined time stamp column followed by the operations messages. We now have more accurate timestamps for additional mission events like entering/leaving the atmosphere and the point at which our apokee is higher than 70km to confirm that we will be making it into space (a very good chance, anyways). We also had a trigger to log MaxQ but it failed to fire because we forgot to update the variable keeping track of dynamic pressure to compare things to.
We will also need to do a better code review this time through, because we missed that there was still a command to immediately decouple the second stage booster after it flamed-out, which we determined in the second launch analysis was causing the booster to bump into the 3rd stage. As before, the immediate decoupling allowed the second stage, which still had a little thrust left, to give the third stage a relatively large oscillation, which is apparent in the plots below that show the pitch of the rocket over time (in seconds).
This oscillation is what tripped the third stage to fire so quickly and is also what is responsible for the rocket flying so vertically and coming down only 31km from KSC when we expected it to travel further than the other two launches while also going higher. Since this launch was partially botched thanks to the errant decoupling command, the 4th flight will also maintain a TWR of 3 during the third stage boost so we can get a good comparison on the performance difference not only to this flight but to the second flight that had a TWR of 2 when boosting with the third stage.
Another comparison between the first and the third flight
One thing this flight did make apparent to us though was how much body lift the rocket can generate when returning through the atmosphere at a shallower angle. As this flight went mostly straight up and straight down the rocket fell more vertically, but you can see the line for the first launch start to travel horizontally as the rocket entered the thicker air in the lower atmosphere.
We’re glad the code changes needed for this fourth flight are minor, because thanks to the numerous delays we have little time to work in any big changes. However we do want to share a quick preview of what we’d like to do with the boot system. Currently it loads operations sent from KSC and can run and store all these operations in memory. But if one operation file includes a “main loop” like our ascent.ks file that needs to continue to check things every few milliseconds, the boot program cannot accept any new instructions until the loop is over. We hope to change this so that operations files can each have their own “main loops” that the boot system will manage so various things can be monitored independently without having to resort to triggers and still allowing the boot system to accept new instructions.
That will all probably happen after the final Mk5 launch this week. We’ll have the code changes uploaded early tomorrow to the repository ahead of the launch.
