|
Kerbin I Ongoing Mission Updates
While this week wasn’t all about the Ascension Mk2 mission (the Dhumla received full flight certification and the Progeny Mk7-B dual-segment SRB was successfully test fired for the first time) it’s certainly dominated our attention due to the fact that the launch and mission control teams have had to work extraordinarily hard to salvage what they could of our original plans. Despite the crowd in Launch Control pretty much losing their minds (Operations Director Drew Kerman included) when the Viklun upper stage failed to hold its attitude during ascent and flipped almost completely over, Flight Director Lanalye and her team stayed focused and worked the problem. Their solution, rushed and messy as it was, didn’t get us up into a stable orbit but did give us plenty of time to figure out what to do about it. You can recap all the events of the Kerbin I mission so far after deployment (prior updates are in the Mk2 link) in this twitter timeline.
The first several aerobrake passes were used to allow the new mission operations control team in charge of Kerbin I to get a feel for operating the spacecraft in this unplanned environment – they’ve already had to deal with thermal issues and recovering out of safe mode twice. We also used the telemetry data it was sending us after each perikee dip through the atmosphere to determine how much drag was being generated during each aerobrake pass. Averaging the passes together over time (since the probe was tumbling we couldn’t use a precise value) has allowed us to now be able to make very accurate predictions out to several orbits, which is when we decided to attempt our first maneuver, which unfortunately did not execute.
The recent failure of the first attempt has been traced to an operational oversight in how we expected the probe to behave. Every time it connects with KSC, one of the things it automatically does is re-upload certain core files from our archives, which allows it to update any changes that may have been made. The maneuver code made use of a recent function addition to one of these core files, but the changes never made it onto the probe as expected. When the probe awoke from hibernation and accessed the “wake file” it was instructed to run after boot, the code for the maneuver failed to find the function it was looking for and caused an error. The onboard fault protection attempted to reboot to clear the issue but the error occurred before the wake file was purged so every time it would boot up it would crash, eventually triggering safe mode.
The reason the file was never updated was because the act of updating the files only occurs if the probe has a connection to KSC at the same time it is undergoing the boot up process. Coming out of hibernation boots up the probe core and then activates the antenna. Activating the antenna prior to boot when coming out of hibernation is not an automatic process because the probe will not always wake up within range of KSC and it is better in these instances to leave the antenna off to save power. So it must be instructed by the wake file to turn on if needed. So the conditions for a file update were never met during the most recent pass. This could have been caught if controllers had thought to check the size of the file onboard the probe against the one here at KSC, but the AFCS is only able to send down a list of file names in the probe’s storage, not their sizes. This additional oversight will be corrected for future versions so proper file transfer checks can be made.
Although looking ahead at the next two passes originally caused the mission team to decide to withhold another attempt on the upcoming orbit, additional discussion in the time since has led to the decision that we will give it another try sooner rather than later. We’ve already successfully recovered the probe from a tumble without much trouble and know it can be done within a minute, so there’s no reason why we can’t have it do the same thing just prior to apokee rather than before perikee like on our first attempt. The maneuver code has been modified to allow 2 minutes for Kerbin I to point retrograde and if for some reason it fails to do so by that time the maneuver will be cancelled, putting the probe back into hibernation until the next comm pass. If the probe remains healthy on its next pass starting at ~02:20 UTC we will upload the new maneuver commands – which will include the required function that crashed the last attempt.
If the maneuver is successful, what you see above will be the new plan for the entire mission. Lowering our perikee will accelerate the decrease of our apokee, which is necessary because at the current rate (the outer orbit line is actually two sandwiched so close together before the wider spacing after the maneuver) we would nearly run out of power before reaching out target altitude of 2,868.7291km. What is this altitude? This is the altitude at which a probe can travel in step with the rotation of the planet, an orbital position known as keosynchronous. Now, since we aren’t in a circular keosynchronous orbit that’s not what will happen here but this is not the goal. The goal is that from this altitude we can perform a test of the RTG casing that has not yet been done – dropping it from the highest operational altitude it was designed for! This was planned for a mission later this year since this one would not have originally been able to boost its orbit this high.
Once we drag our apokee down close to the target (projections show that by Orbit 14 at ~18:30 UTC tomorrow we will be at 2,862.064km), we will finally and officially enter into orbit by boosting our perikee out to 100km. With a stable orbit, we can take the time needed to determine when would be best to deorbit and ensure Kerbin I comes down over land so the RTG casing can be recovered and properly analyzed, along with the impact site. All these planned maneuvers, including the upcoming perikee lowering, will require 36.4m/s of Δv and Kerbin I still has 112m/s to spare. Even though that is also the same fuel used for the RCS system, what little maneuvering is necessary shouldn’t bring us anywhere near to dangerously low fuel levels.
As we come closer to the mission’s conclusion, assuming it has been done without any additional troubles, we’ll have a better idea of what power and fuel reserves are available for attempting to capture more photos from orbit, but for at least this weekend do not expect any new space picture attempts. The ones taken late Thursday are still being worked on and one of them seems like it could be made publishable.
ATN Database
The latest update for the Asteroid Tracking Network database is available here, containing 4,748 asteroids and 3 updated with new observation data. Here are the 35 asteroids that were discovered this past week.
 |
 |
From the Desk of Drew Kerman
Out of Character Behind the Scenes stuffWritten on 2/6/20
Nine days since my last Desk Note to make it through one HELL of a launch week. Alright all things considered that’s really not too bad – except for the fact that I have literally done nothing but KSP, eat, sleep and coach (aka “real job”) for that entire time. No other games, no movies, no showers, no… oh alright I did get to spend dinner out with some old friends one night last week. I AM NOT A RECLUSE YAY!!
But seriously, the demands have been huge and even though I’m writing this 2 weeks before anyone will read this (will anyone read this anyways?) the stress is beginning to build. I’m not done with the mission yet and all I’m doing is adding more and more issues to the Ops Tracker github that need to be cleared out before this mission for the best experience I can deliver. The Ops Tracker as-is right now will function fine, but it’s a bit buggy in some areas regarding this mission and doesn’t have features I’d like people to use also in regards to this mission.
For sure will lose all my lead time after this, which sucks because as I’ve said before lead time is great because when I actually get around to writing things in detail that I only outlined it makes me thinks of things I could have or even should have done earlier. Like I wish I had 3 months lead time again so I could go back and add some MLP qualification activities like carrying a mock-up of the full Ascension Mk2 to the pad instead of just sitting outside the VAB waiting to be used for the first time. Ehhh, we’ll just see if it works… 😝
Okay let’s talk this Mk2 mission. OMG so many notes….
Mission planning
My goals were pretty simple – get up to a 100x100km orbit by any means possible. So last year I spent some time working with various ascent profiles in LVD until I came up with one that not only got me into the orbit I wanted but with plenty of fuel to spare in the event something went wrong during the ascent. This was not me planning for something to go wrong on purpose just being generally cautious as any mission planner should be. Overall though the whole original plan was generally done based on getting into this orbit then asking myself – well what can we do up here? The ideas were very simple, just deploy Kerbin I, demonstrate a controlled deorbit of the Viklun stage, demonstrate orbital maneuvering with the cold gas engine along with AFCS orbital operations capability and then perform another RTG impact test. Really after that initial ascent design things just worked out to have the Viklun stage deorbited over the waters on the third orbit with just enough battery power. So launch, orbit 1, deploy Kerbin I on orbit 2 and deorbit Viklun on orbit 3. After that I had no concrete plans for how to carry out Kerbin I’s previously-stated mission goals – was going to do that once I had an orbital trajectory to analyze.
Key fact: I had no idea if this was all going to work as planned. Hoped it would, but that was it. I did however purposefully not test to see if the RCS thrusters would have enough power to maintain Viklun attitude. I simply used what parts were available to possibly provide the control necessary.
Launch photo
It took me about 5 tries to get all the elements right – the key one being that I did not want the smoke to fully obscure the MLP. I wanted to make sure people saw that the rocket was indeed actually launched off the MLP, which it can do so long as I remember to use the cheat menu to disable max part temperatures otherwise the SRBs just destroy everything under them 🤣
One stupid mistake that ate up some time was realizing that I had forgotten to include the lightning tower floodlights for the photo. Actually I hadn’t forgotten, they were there but I also had the engine clamp moved up around the engine for earlier photos and knew if I tried launching it would flip out the rocket since the clamp is a solid collider and, y’know, clipping. So instead of just doing the smart thing and translating back down to the bottom of the engine I deleted and replaced it. The lights were attached and translated from the clamp so they got deleted too. In the end I just added them back in, took a photo from a similar angle and composited them into the launch photo. Yea I spent almost an hour making sure the lights were there when probably no one would have noticed. But that’s how I roll.
Launch delay
The original launch date was to be the 18th but then would be delayed to the 20th due to an issue on rollout involving the interstage shroud based on this twitter comment I received. I wanted it to be a bit of an insider joke to those that had followed my MLP Kraken attack. Obviously I couldn’t make it fall off that would be a huge delay but I was planning for one of the halves to have shaken loose during transit. When I actually went to write it up tho I couldn’t make it an issue that didn’t look like gross incompetence on behalf of the VAB build team & the Agency in general. Here we are staking all our reputation and future financial livelihood on this rocket that’s supposed to travel km/s rattling thru the atmosphere and a fairing jitters loose traveling to the launch pad at 2-3m/s. HRRRMMMMM… nope.
Still, I wanted the launch date later in the week just to give me more time and then realized since this was the first Mk2 rollout (so the no testing done earlier actually helped here) it would make sense to roll out at the start of the week and do lots of testing and checking before a launch later in the week.
Software testing
Because this mission would last several days it was absolutely vital I screw up as little as possible. Reverting & redoing during the mission could potentially mean hours wasted, hours I do not have. So there was much more testing of the onboard kOS instructions powering the AFCS than usual. I pretty much put every line of code I had written through an actual in-game test, just in general conditions and not approximating the mission. So I ran the ascent code without the pitch-over and just had the rocket fly straight up (so still didn’t know if RCS was sufficient for Viklun ascent). I used Hyperedit to get the Viklun and Kerbin I into just a circular orbit to test maneuver code and orientation commands.
I actually filed my first issues on the AFCS github tracker identifying some non-critical issues that I’d like to clean up for the next mission, while also fixing a few things in the bootscript that didn’t quite work as well as I thought they would for an extended orbital mission.
One example was hibernation, which I had to retool to accept no wake file on reactivation, no wakeup time at all in the event I wanted to do some storyline actions that fell outside what kOS was capable of, and also converting seconds to minutes on the timer part as necessary for longer-duration hibernations.
I also struggled with a weird issue caused by Kerbin I decoupling from Viklun, which would cause the comm signal to KSC to blip out in the middle of operation instructions and not be able to regain signal, which would freeze the probe core’s runtime environment. It took me most of the day to work my way down to the fact that the kOS probe core I was using for Viklun lacked a RemoteTech SPU module, which was on the stock Okto core and when that was decoupled (even tho it was not even switched on until that point) Viklun lost all ability to connect to RemoteTech’s comm network. Ugh, an annoying oversight on my part from when I enabled the kOS part to use RT months ago.
A final irritation I discovered in testing which I couldn’t fix and had to work around is the fact that when you enter flight with a kOS probe core completely powered off the game doesn’t even detect its presence. So when I power it on, kOS doesn’t give me the option to open up a console window to view its output. I have to go to the tracking station and back to the probe so that the kOS unit is switched on when loaded and the game recognizes that there even is one on the vessel. I really hope that’s fixed in the kOS version for KSP v1.8.1, or is just the result of a bad mod interaction that is no longer the case in the newer KSP.
Flippy Viklun video
This would have been sooo much easier if I could have just recorded it in one shot from the perspective of the ground tracking camera, but unfortunately a rendering issue disables the Smokescreen particles when the rocket travels too far downrange, so that was not an option and I had to go with onboard footage.
I also had to consider how I’ve handled past video where the KSA has explained how we don’t have the bandwidth to stream down video during launches and it is all stored for recovery. Since neither the Viklun or lifter would be recovered I had to go with photos being beamed down and stitched together to make a video.
So first I had to fly and record the launch from 4 different camera angles (the cam looking up at the 2nd stage from within the intershroud ended up being cut) and no it did not take just 4 flights unfortunately,
Once I had the footage it all needed to be cleaned up of microstutters (which still happen even with MemGraph) and also time-compressed since the game slows time to ensure it can carry out all the physics calculations required per second (so in extreme cases an in-game second can take 2-3 real world seconds and the video ends up being 2-3x longer than it should be)
Then I had to cut it all together and sync up the different camera views, getting around problems like the sun flare showing up on top of the booster camera lens shroud.
Once I had the actual footage clip I wanted to show I exported it out as a batch of PNG files at 12fps.
Then I had to manually delete the two frames between every third frame – this wasn’t actually so hard just tedious. Dragged 12 files at a time into a separate folder for the selection/deletion to make the process more manageable.
Finally I had to spend some time editing all the frames in the beginning showing the heat effects because they too were also appearing atop the camera lens shroud and also exposing the shape of things inside the rocket and fairings. This is still to some extent visible in the finished product but it’s not as recognizable – before I covered up the effects over the lens shroud you could clearly see the payload adapter and batteries outlined.
At last I could render together all the frames back into a movie.
The *actual* mission… so far
Alright here’s the real story.
First off, though I can actually launch off the MLP doing so does cause some minor jittery glitchy jumpy action on the part of the rocket that varies from flight load to flight load. So for the actual launch I did not use the MLP but the rocket was otherwise positioned height-wise as if the MLP were still underneath it.
How many launch attempts? JUST ONE! Yes, I actually saved it on the first try. Everything logged during the launch that is displayed via tweets and telemetry is COMPLETELY UNEDITED, those were all the actual commands that were sent when they were sent as I attempted to salvage whatever I could. I did not even pause the game after the rocket flipped to try and decide what to do. I just took the burn script and plugged in a time to begin that had already passed and a time to end that was way in the future and sent it, then could do nothing but sit back and watch and hope and OMG that was intense. When it ended up in a long-term decaying orbit I was just like – well yea I can work with this. It’s so close to being a stable orbit it’s understandable that people could see this as a story element for the sake of tension but nope, that’s just how it all actually turned out!
Now here is where I failed. I rushed the mission from this point on, dropping the probe down into a 50km aerobrake on like the 3rd orbit that nearly destroyed it and would have dropped my Ap into the atmosphere on the following pass where there would be no comm window to do anything about it and my attempts to save it by raising my Pe after the fiery aerobrake led me to run out of fuel. Mission over.
Well fuck that. Revert!
So the second attempt, taken from SECO-2 back in the orbit I originally ended up in after my saved botched ascent, I slowed down and realized I have days worth of battery with hibernation and there’s no reason the probe can’t stay like this for a few orbits so I can get an idea of what lowering my Pe would do in the long term. I mean it was still frustrating as all hell because the first attempt was like 3 hours of work I had to carefully erase, which also took like an hour, but taking a deep breath and really stepping back to view the larger mission over an extended time period was the point at which I realized how I needed to think about things.
So that first orbit, setting up for Kerbin I deployment was able to be done as said. One of the cool side-effects of the non-rechargeable batteries that I use is that they work by charging the normal rechargeable EC batteries. I didn’t need to include my nonRC versions on the Kerbin I probe because they would actually be switched off and unusable during launch so they wouldn’t drain, and Kerbin I has no alternator or means of generating EC so they would not recharge. The batteries on Viklun could be recharged by the alternator in the K2-X lifter engine during ascent so they had to be nonRC. Anyways, what this meant was I could enable the Kerbin I batteries and they would actually not drain until the nonRC batts had run out on the Viklun. So to keep power running through that first orbit required no manual power management from me.
The first safe mode event was a bit of story based on actual events. It’s not possible for me to make an actual safe mode in kOS because things can happen in the game that crash the runtime compiler and there’s nothing I can do about handling this gracefully since that is the actual mod code itself, not my scripts. So obviously you don’t launch something into space that can wind up in a unrecoverable state – all space probes have layer upon layer of fault protection so ground controllers can restore normal operations. So when an error actually crashed out the probe (it happened entering the atmosphere and has not recurred and I never actually tracked down why it crashed) I can reboot the CPU using the game interface to recover operations but for the sake of story it entered “safe mode”.
On that note it’s worth mentioning that there is some editing done to the command log file for story purposes but the vast majority of it is real output generated by the AFCS scripts running during the game.
While I’m operating the probe, I have Chronolapse running to take a screenshot every second, which I can reference later if I need to revisit the actions I took and remember what I was doing and why, as well as read data off the in-game displays. Doing this takes up way less storage space per second than recording video.
The mention of thermal problems is entirely story. Unfortunately KSP does not have a great heat system and thermal control of a simple space craft like this isn’t really much of an actual concern in the game. It does make sense though that the probe could be in danger of overheating given that it really does spend so much more time in the sun than originally planned, so I wanted to at least call that out.
I’m losing a lot of time because I have to learn lots of new things outside the game, which I also screw up and have to redo. Like calculating the distance traveled by Kerbin I using KSPTOT. I realized I was getting slightly different results depending on how I was asking it to calculate along the trajectory I was building based on in-game data (something I had to relearn from before the KSA reboot). Over time and distance the discrepancies were getting noticeable and I had to come up with a common means of calculating this so all future probes could be properly measured against each other. Basically I decided the current SMA of the orbit would dictate how many steps per event KSPTOT would calculate (more steps = higher accuracy, but at what point does adding steps become irrelevant?).
There’s also an issue with the SmartPart timer I use to countdown until the CPU is supposed to come out of hibernation – apparently reverting to the tracking station and back so much at some point broke it which means I have to enter into hibernation and then manually wake the CPU up using Action Groups Extended to bypass the lack of RT connection. I’m also manually switching on and off the antenna rather than using onboard commands – it’s a bit “hand wavy” but even though I could actually program it to work the way I’m doing it myself, doing it myself is faster and I need all the spare time I can get here.
The probe locking prograde so it faces retrograde is something that actually works thanks to MandatoryRCS which keeps rotation in effect throughout time warp. However I’ve found that it only works properly if I stay in the flight scene. Going to the tracking station and warping ahead, I come back to find the probe no longer pointed properly, although its spin momentum seems to be properly maintained. So I guess a bug, but one that can be worked around when needed at least.
I am also making sure to switch to flight scene every time the Viklun stage passes through the atmosphere so aerobraking has an effect at gradually lowering its apokee back towards the atmosphere.
Another noteworthy mention is that I’m generally refraining from using kOS’s built-in ability to query the current altitude of the vessel and instead I’m just using clock timings. So for example when the probe reaches apokee for its maneuver it’s not checking for altitude to start the maneuver it is checking for the proper time to start the maneuver. The time is taken right from KSPTOT’s calculations. This is because most small space probes don’t carry the heavy equipment needed to tell their own altitude.
The reason given for the missed maneuver is pretty much exactly what happened for real. I overlooked how the file on the probe would actually not get updated and the kOS runtime crashed when it attempted to load the burn script and couldn’t find the function it needed to call. This actually left it in an unrecoverable state within the game – even if I manually rebooted it would crash again since the script is set to run on wake and not deleted until after it runs, but it was failing to completely run. Given that this was actually my third attempt at performing the maneuver and I had already wasted a few hours on reverting from the previous attempts I was rather dismayed at being forced to try again. However I managed to save myself by editing the kOS compiled code in the SFS file to remove the stored wake file command so the probe could boot normally.
So the probe crashing at boot led to the triple reboot into safe mode that ended up in the story. And it wasn’t just because missing the maneuver added some more overall depth to the mission but also the fact that I didn’t want to take the time to go back again and revert but instead just keep moving forward.
2 weeks left. Time is running out!
A final note I hate to gloss over but this entry itself is taking up valuable time – all the mission planning is indeed being done without foreknowledge. I’m not warping ahead in the game at any point to see what happens. I am spending the time and doing the work in KSPTOT Mission Architect to properly model my aerobrake passes and propagate the trajectory out into the future to see what potentially lies ahead. The areobrake drag is calculated based on the data gathered from each pass and averaged together, not given to me by the game. I’m trying to “show my work” as much as possible and hopefully people like it. This also means that the mission’s future for me is still not fully known. The plan I explained in the Ops Summary above is what I will do my best to carry out, but I expect more mistakes will be made. And that’s good, because IMO that also makes for good story.
If anyone actually made it this far, thank you. I hope you enjoy whatever ends up happening this weekend.
