Overall, yesterday’s flight was a success in that we managed to launch the Mk5 into space without any major issues. The fact that the rocket was built almost exactly the same as the previously-successful Mk4 gave us a lot of confidence that there wouldn’t be any problems with stability during the flight, but there was a little bit of worry with regard to the extra girth of the inline probe core. It was placed just above the fins to maintain stability by keeping the wider portions of the rocket closer together. While we did notice a larger precession to the rocket’s spin once the 3rd stage was flying on its own, the spin rate was high enough to keep it pointed prograde during both its coast and its boost phases. Launching at 3° from vertical was another relative unknown, although again we had previous Mk4 data to help ease concerns. The Mk4 launch with a TWR of 4 raised its nose only 1° starting from 5° so we felt safe having only 3° of pitch to play with. Turns out we cut things a bit close as even with calm winds the nose of the Mk5 lifted to 89.4° during its initial ascent from the launch base. This will severely limit launch commit criteria when it comes to wind blowing from the east. Other than these two considerations the flight performance was very similar to that of the Mk4. While there were no major issues, minor ones were uncovered during review of the flight data collected both on the ground and from the recovered payload’s telemetry data unit.
Kerbed Control Errors
We identified two areas where launch controllers did not properly perform their tasks, much to the dismay of Flight Director Lanalye, who had spent countless hours drilling her team prior to the first Mk5 launch. The first mistake was made by the staging operator, who was monitoring the pitch of the rocket during coast phases and waiting for it to change 1.5° from the start of the coast to ignite the next stage. It turns out the second stage was ignited at only 1° of pitch change while the 3rd stage was ignited at only 1.2° of pitch change. The second mistake was in managing the TWR during the 3rd stage boost. The plan was to maintain a TWR of 2, which was achieved only if you consider the rocket to be on the surface. In reality the TWR upon 3rd stage cutoff was closer to 2.33. We have no idea why the controller has readouts for both TWR at surface and TWR in flight but they ended up monitoring the wrong one. The surface TWR readout has since been removed. For pitch monitoring, we will be using the AFCS during the next launch to inform the staging operator when the next booster should be activated, although they will still need to monitor the pitch themselves in case this new code fails.
Telemetry Log Errors
You can view the complete telemetry data here.
Our new onboard telemetry logger was completely missing throttle readouts, registering 0% throttle for the entire flight. It turns out we were reading the wrong value from the engine control system and will be fixed in the logging code. There was also a very large discrepancy in the measurement of distance traveled (not distance downrange) versus the value calculated using radar tracking from the ground. At the time the rocket entered space, ground tracking has the rocket’s travel distance at 71km while the onboard logger has 86km recorded. We’ll be looking into an alternate means of calculating travel distance for the second launch to see if we can make these numbers agree better.
Additionally, the amount of storage space for saving log data was not enough to last the entire flight. We ran out of logging space just after full chute deployment, which not only stopped data from being logged but terminated the entire program by throwing a runtime error. That’s not good! Thankfully all that did was prevent the code from detecting the splashdown so 99% of the code performed perfectly during the flight, with the remaining still untested. While the M-135 unit is highly expandable & has room for additional data storage, we were unable to make any such changes to the second Mk5 so we will be looking for a coding solution. The logs are already transmitted to KSC as well as written locally so as long as a signal is maintained the probe core will not write data to disk. Also when the disk fills up the logging will stop rather than crashing the entire program.
New Trajectory Rendering
Despite some problems there was still one resounding success of the telemetry logging and that was our new trajectory rendering program using position data collected every second during the flight. We can then plot it out in discrete intervals which allows us to not only see the overall path the rocket took on its trip to space and back but how it was moving during that time. Longer intervals between the arrows means it was moving fast, while shorter intervals means it was moving slow. Here is a closer look at the initial ascent:
You can clearly see how the rocket sped up in the first stage boost, slowed down towards the end of its coast, sped up and slowed down again during the 2nd stage boost and coast, then during the 3rd stage boost the intervals remain constant as we were maintaining a constant acceleration. This is a very helpful visual aid to gauging flight performance without having to stare a wall of numbers in a spreadsheet.
You can expect an update to our Automated Flight Control System repository sometime later today with various code changes to address the issues identified during this flight in preparation for tomorrow’s launch.
