|
Potential Design Flaw Exposed in Ascension LES Pad Abort Test
Today we were finally able to erect the rocket for the first time with the Mk1 capsule atop it – check the gallery above to see! Lack of any severe weather whipped up by the Monolith thanks to the A/C system allowed us to proceed with the Launch Escape System pad abort test, which was meant as a general demonstration of the LES while also ensuring that should an incident occur on the launch pad the capsule could fly clear. The LES is designed with 5 solid rocket motors, 4 of which thrust forward while a 5th thrusts off-angle to tilt the capsule away from the rocket. The tilted motor fires only briefly upon separation to re-orient the capsule while the remaining 4 push it clear. During the test however the 5th motor atop the tower burned for the same duration as the lower 4 motors, meaning somewhere along the line there was a miscommunication in design. You can see the full test in this video.
While we track down exactly where the flawed decision was made to install the same motor in all 5 engines, looking over the test data we can at least see that had this been an actual event the occupant of the capsule would have survived. Despite the tumble only 5Gs of force were experienced for the short flight and although the force of a potential fuel tank explosion triggering the LES would have added to the spin the capsule would have also been flung a bit higher and given more time to recover. As it was, the chutes barely opened in time to prevent the capsule from impacting at deadly speeds. The chutes are reefed and able to be controlled when opening to reduce stress on the canopy. At normal deployment speeds and altitude they would open in ~8 seconds. Allowed to open fully without reefing they can deploy in just over 2 seconds. The flight computer properly sensed the situation and deployed them accordingly, which was another win for the test. The video shows the capsule practically landing on the heat shield, which is only dropped after full chute deployment so that’s how close it was
The bad news however is that although the capsule protected the occupant, in this case Greggery the test dummy, Lead Engineer Simon suspects that the damage done to it will not allow it to fly again, even as a test article. In addition to the failed K2-X engine test earlier this month, this brings potential further delay to the Ascension program as the next capsule is not scheduled to be delivered until later this month, one of two new capsules ordered to hopefully carry a kerbal into space. Now one of them will be forced to be used as a test capsule instead. We’ll know for sure next week once the capsule has had a full inspection.
Progenitor Succeeds at Last in Returning Mystery Goo Samples
Check out the flight analysis of the recent mission this week to learn all the details of this routine mission, although the real highlight is the fact that this is the third time it was attempted. We took no additional funding to deploy the two follow-up missions after the first failure so although the contract payment was finally made in full it failed to cover the cost of the multiple attempts. Still, we were more than willing to take the financial loss in order to provide the scientific community with valuable data on the aptly-named “mystery goo”, which has potential applications for deep-space travel both in hibernation and radiation resistance. Scientists are still trying to understand the colonies of micro-organisms and we hope this new data will help them. In fact, the samples sent into space on this third flight were specially prepared with knowledge gained since our first attempt, so the multiple failures may ultimately have proven fortuitous.
We do not know if any more Mk6 rockets will fly before the Mk7 comes into service later this year, although we are still open to contract proposals should any agencies request a mission.
KerBalloon Reviews New Contract Proposals
Both the high- and low-altitude crews are home now from their latest missions, with the low-altitude crew just recently back from their Kongo River research trip. They will soon be deployed again but to where is still a question as several contracts are currently in various stages of negotiation. We’ve also had to purchase a new Utility Task Vehicle to replace one lost on the recent Kongo mission. The Agency was founded with 5 and now we are down to just 2, which isn’t enough to safely allow a crew to traverse with balloon equipment as a full convoy requires a pathfinder vehicle to seek out and avoid dangerous terrain and two additional vehicles to carry cargo vital to the mission.
ATN Database
The latest update for the Asteroid Tracking Network database is available here, containing 3,271 asteroids and 6 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 3/14/19
One day lead time yay! Joking aside though I spent most of the past week binging No Man’s Sky to collect all the crap I needed to craft a buttload of high-end objects collectively worth about 1.1 billion units. I split it with my friend and now we’re both mega-millionaires and can stop hunting down resources and just buy our way through the rest of the game, mwahaha. Which is good because he doesn’t have nearly as much free time to play as me so now we can both just concentrate on the storyline missions. Now that I have that good deed out of the way, I’m back to focusing on KSP for a while.
Mk6 launch
launch was routine on the back-end as well, with only one weird issue popping up on my first attempt – for some reason the rocket was extremely draggy, like up to 30kN of drag force when normally it peaks around 9-10kN. I couldn’t replicate it thankfully although I did look into it closely for a possible reason I could use to fail the mission, because although failures suck I do like how creative I can be with the reasons sometimes. I think maybe the game thought the air brakes were deployed somehow.
LES test
Yea so that’s actually how the stock Squad LES is made to work in the game. I didn’t adjust anything I just triggered it off and let it do its thing. Not quite what I had in mind, but it did give me an excuse to slow things down even further, which will help me build back up my lead time.
The chute deployment was actually adjusted down in the RealChute settings to a 1 second pre-deploy followed by a 1.5 second deploy, so it really does take just over 2 seconds to fully deploy. It was the lowest I could get and not have the capsule be routinely destroyed on landing. I wanted it to be close and still seem realistic and I think a little over 2 seconds works. Whether or not chute reefing can be dynamically controlled so much may be a bit of creative license on my part I don’t know I didn’t research it that deeply.
That stupid heat shield shroud was an issue again, but thankfully if I hid the shroud and just decoupled the capsule it would fall and rest atop the rocket, although if left there long enough it would slowly slide off-center so I had to be quick about repositioning the camera after I decoupled.
Yea that’s another annoying issue with CameraTools where decoupling a vessel shifts the camera position so I have to decouple then set the camera. Even though I disabled the shake option I still couldn’t get it to stop bouncing around a bit at the end when the capsule hit the ground.
Not much I could do about the parachutes disappearing after touchdown, that’s just how the game handles it and no one has bothered with a mod that changes the behavior. Although to be honest such a thing would be a bit troublesome to do in a way that would look good anyways.
I had to up the heat shield impact tolerance so it wouldn’t be destroyed on landing – the impact tolerance is mainly how the game determines impact force being translated through objects so the heat shield having an impact tolerance of 9m/s means it would be destroyed only so the game could move on and deliver force to the next object. it’s a simplistic model and in reality there’s no reason the heat shield should be completely destroyed during this test, so upping the tolerance only applies to this instance I haven’t set it higher for normal use.
I also installed Blast Awesomeness Modifier since things were exploding a bit too vigorously for items that don’t really have explosive elements.
It took several takes to get a result I liked, since the lower framerates of having the graphics turned up for the video capture also affected the per-frame physics calculations so the results were quite different each time.
Finally, that photo of the rocket standing on the pad with one umbilical detached had to be a two-photo composite rather than just a simple screenshot because fuck this game sometimes I swear. Unhooking one of the umbilical towers causes the rocket to want to jitter off the engine clamp, so I had to take a photo of the rocket with the umbilical attached, unhook it and quick take another photo before the rocket bounced around too much, then use the second photo to erase the attached umbilical of the first photo, which has the rocket properly in place. Yeesh.
Also I know how I want to fix the LES to work properly, did some testing already and should be a good method that will enable me to do even more with the LES than I originally planned.
Ops Tracker clock bug
This bug was something that had been dogging me since the original Flight Tracker back when I started the first KSA iteration in 2014. It’s a bit of a layered problem see since I started the game in September, which was during Daylight Savings Time. But obviously there is no DST in KSP so already my ingame clock was an hour off from the actual time once we switched back to Standard. Then of course switching to Standard affects the UT offset so now some times of the year the game clock is one hour off my local time and others its the same while also being alternately 1 hour off UT and 2 hours off. I don’t even know if I explained it well it still makes my brain hurt.
On top of all that I was completely misunderstanding how the JavaScript Date object handles setting time. I thought when I passed it a time value I was setting the clock’s UT but really I was setting whatever local time the user’s computer time zone was set to. So instead of adjusting the JS clock hours to display the KSC local time in the Ops Tracker I was offsetting the game time and everyone was always seeing their own local time instead of KSC’s local time (my local time EST/EDT).
That all still probably didn’t make any sense. Whatever, it’s finally fixed after 5 years and now everyone sees KSC local time in the blue event box and all UTC times posted in the vessel pages now have the proper hour offsets and the tooltip for the Last Update field properly converts UT into the user’s local time
And I’m spent. Going to play a bit more NMS then my goal is to bang out at least the next week by the end of this weekend.
