Saturday, March 15, 2014

KSP: Mission to Laythe (and back).

Mission Summary:
Total M.E.T.: 984 days
Ships: 4 (2 to Laythe, 1 landed)
Crew: 12 (6 to Laythe, 3 landed)
Landed Mass: 56 tons
Furthest Distance from Kerbol: 82,000,000 km
Orbital Rendezvous: 4 (two in low Kerbin orbit, two in low Laythe orbit)
Quicksave Reloads: 4 (two game bugs, two landing retries)

After a nearly 1,000-day mission, I've successfully returned six Kerbals, including three that have landed on Laythe, to Kerbin. Laythe, the water moon of Jool (KSP's Jupiter analog), is probably the most interesting and challenging target for exploration in the Kerbol system. For that reason, I modified my Interplanetary Transport Ship (and proven Duna lander) to give it more range and more lifting power - just barely enough to pull off the trip...

...they hope.
A single ship would not be able to carry enough fuel to land on Laythe and return. In fact, I determined that even getting from the surface of Laythe back into orbit would require almost all the fuel the lander can carry. In order to have fuel for the journey itself, two ships would have to go. And each of those ships would need to be completely refueled in Kerbin orbit (by two more ships) before heading off. So, the mission as a whole required four ships (twelve crew) and four orbital rendezvous. Basically, lots of docking practice.

One of two Kerbin Orbit Rendezvous.
Docking and refueling in Kerbin orbit is somewhat routine, so I'll skip that part and focus on the bulk of the mission, which really has four parts: 1) Kerbin to Laythe, 2) Laythe Landing, 3) Laythe Ascent, and 4) Laythe to Kerbin.

1) Kerbin to Laythe

I've only successfully managed to even get to Laythe once before. Other attempts have been cut short by ship-eating game glitches such as the Deep Space Kraken. This time, I made sure to use quicksaves and also back-up persistent saves so I wouldn't be screwed if my ships randomly blow up in deep space.

Shit happens.
Game bugs aside, getting to Jool is not particularly challenging. According to the map, it takes about 1915m/s of Delta-V to get from low Kerbin orbit to Jool intercept. This is assuming an optimum Hohmann transfer orbit, which can be planned using this handy tool. The transfer orbit looks something like this:

Both of my fully-fueled mission ships managed the transfer with a Delta-V of about 1975m/s, almost perfect. (Part of the burn was done using the refueling ship to boost its docked fuelee into a more energetic Kerbin orbit. The fully-fueled ship would then detach and finish the transfer burn on its own in subsequent orbits.) Later in the transfer, some smaller course correction burns add a bit more to the total Delta-V required to get to Jool. But ideally, once a Jool encounter is achieved, very little additional fuel should be necessary to slow down, get captured by Jool, and ultimately, transfer into a Laythe orbit. Since both Jool and Laythe have atmosphere, this can mostly be done with well-targeted aerobraking.
Lucky Tylo slingshot. Remember kids: always aerobrake in the counter-clockwise direction.
I tried a couple different techniques for aerocapture and aerobraking: using Jool's atmosphere to slow down into a less energetic Jool orbit and using Laythe's atmosphere for a direct aerocapture into Laythe orbit. Which is better depends a lot on the direction of Laythe in its orbit relative to yours: if nearly parallel, less energy is required to aerocapture and it could be a good opportunity to do so. If you are approaching Laythe at a right angle, it might be better to wait for a better opportunity and aerobrake more at Jool instead. In either case, it's important to always approach Jool in the correct orbital direction (counter-clockwise, viewed from above) so that you're not setting yourself up for a head-on Laythe collision.

Ship #1, aerobraking away from Jool "set". 
Ship #2, aerobraking into Jool "rise".
The two ships took slightly different amounts of course correction and tweaking to get to Laythe. (In a few cases, an aerocapture was not completely successful and some fuel had to be burned to slow down to less than escape velocity.) But most of the fuel for this leg of the journey is just spent setting up the transfer. Here's a summary of the outbound trip for both ships:

Once the ships had both arrived in low Laythe orbit, it was time for the third rendezvous of the mission (the first between these two ships) in order to refuel the one that would become the lander. The second ship stays in orbit around Laythe and retains just enough fuel for the return trip to Kerbin.

First Laythe Orbit Rendezvous. 
2) Laythe Landing

I already outlined my landing strategy in this post, which includes my precision deorbit simulation tool. So here I can just review how it actually went.

Not well.
Actually, the deorbit tool worked perfectly - it was the ship design that was fundamentally flawed. With full fuel, the lander is severely top-heavy and can only tolerate at most a 10-15º incline. Lacking sophisticated tools such as ground slope radar and any spare fuel to make last-minute adjustments, the Kerbals really have no choice about where exactly they land, and even the flattest continents on Laythe are covered with fairly steep sand dunes.

But, it's a damn water wold and I managed to hit land three times in a row. In all three cases, the Kerbals survived the landing, but in the first two attempts, the ship fell over and was destroyed. Rather than assigning the Kerbals colonial status, I used up two quicksave retries and finally stuck the landing on the third try.

...just barely.
Other than the two tip-overs, landing went almost exactly as planned. The deorbit tool provided an almost pin-point landing site prediction, the parachutes (drogues first, then main chutes) worked fine and slowed the lander to about 21m/s terminal velocity. The last quick burst of power to slow the ship to safe touchdown speeds was done from the in-cockpit view, so that I could look at the radar altitude and really be efficient with when to start the quick burn. As a result, it used only 1.9 tons of fuel, about as good as my best practice runs on Kerbin. (I allotted for 2-3 tons to be used for deorbit and landing.) The remaining lander, still almost fully fueled, weighed in at about 56 tons. It truly is a behemoth of a landing craft, but that's what it takes to get three Kerbals back into Laythe orbit.

3) Laythe Ascent

The ascent from Laythe was the most uncertain portion of the trip. Laythe is 4/5ths the size of Kerbin, and has a surface gravity of 0.8g. Consequently, it's a bit easier than Kerbin to launch from the surface into orbit, but not by much. And it's impossible to practice this stage of the flight, other than to launch from Kerbin. (This vehicle cannot reach Kerbin orbit, or even come close, so that test isn't very conclusive.)

The original ship (ITS1), which successfully landed at and returned from Duna, had one central "Poodle" engine and four super-efficient but low-thrust LV-N's. The biggest modification to ITS2 was replacing two of the LV-N's with LVT-30's, to increase the lift-off thrust-to-mass ratio of the lander to about 1.2g (1.5x Laythe gravity). Without this modification, it would have had no hope of getting off the surface. The LVT-30's burn through their fuel quickly, though, and get staged after about 90 seconds, according to my ascent simulator:

Laythe ascent profile. (Stage definitions here.)
After the LVT-30's and their fuel tanks are gone, the ship's thrust-to-mass ratio dips sharply (still greater than 1x Laythe gravity, barely). The two LV-N's and single Poodle struggle along to get it faster and higher. Finally, the Poodle runs out of fuel (it doesn't get jettisoned, though) and the LV-N's finish off the ascent. By this time, the thrust-to-weight is well below one, but that's okay because the rocket is moving fast enough sideways that the ground  is falling away from it. (Or at least, that's how I think about it.)

Laythe ascent speed and altitude.
By the end of the ascent, 400 seconds after lift-off, the ship should be in a stable circular orbit, hopefully at or above 75km, with about two tons of fuel to spare. Or so the theory suggests. Time to try it out!

Returning to the ship after one last look at the terrain.
Nighttime launch. Stage 1: All five engines at nearly max power.
Stage 2: LVT-30's and their fuel tanks are jettisoned, LV-N's and Poodle still firing.
Stage 3: Poodle engine shutdown, LV-N's efficiently finishing off the circular orbit, into a beautiful sunrise.
And, back in orbit!
For once, something worked exactly as planned on the first try. Well, not exactly: the actual final orbit was at about 120km instead of 75km. But I can't complain about extra energy. The fuel remaining was also right on target or slightly higher than two tons. Rather than burning some of it to get back to 75km where the orbiting sister ship was parked, it made more sense to bring the sister ship up to 120km. (If you're planning to leave orbit anyway, it always makes sense to burn pro-grade and increase the overall orbital energy of the lower ship for docking, rather than burning retrograde and decreasing the energy of the higher ship.) The fourth and final orbital rendezvous went without a hitch:

The two ships meet again. Val also making an appearance.
4) Kerbin Return

Here I deviate from my original flight plan a little, because I thought of an even more fuel-efficient way to get back. The original plan was to transfer about 50% of the remaining fuel to each ship, jettison the empty tanks and LVT-30's on the ship that still had them, and have both ship return independently on LV-N's. But this method would still involve carrying a lot of dead weight in the form of mostly-empty fuel tanks and Poodle engines that probably wouldn't get used again. So I came up with a better return configuration:

Fairwell, empty ship!
I transferred all of the remaining fuel into one ship, the lander, which had already jettisoned its LVT-30's during its ascent from Laythe. Then, I cut loose the entire second ship, the orbiter, except for the command pod with its three Kerbals. This newly-lightened single return ship would have plenty of Delta-V, much more than two ships on their own would have had. As an added bonus, I only had to keep track of one ship during the trip back. The down-side is I have left some space junk in Laythe orbit.

Never mind that, though, time to return home. I've done a Laythe direct return before, where I burn out of Laythe orbit directly onto a Jool-Kerbin transfer orbit. It's by far the most efficient way out. I did the math at some point in the past:

You can calculate the launch window and required angle of departure using this calculator. Just put in Laythe's orbital radius as the "parking orbit" for Jool. The time to leave Laythe is when it is at the position in its orbit around Jool that the departure angle represents. Sort-of a hack way to calculate it, but it works. Then all you have to do is exit Laythe's sphere of influence parallel to its orbit, with enough Delta-V to get onto a Jool-Kerbin transfer orbit. It should look like this:

Exiting Laythe SOI parallel to its orbit.
And with the correct Delta-V to get onto a Jool-Kerbin transfer orbit.
And it should take somewhere between 1,000m/s and 1,200m/s of Delta-V, which is remarkably efficient compared to the trip from Kerbin to Jool. It's by far more efficient than diving towards Jool and then doing an escape burn. (Although it wasn't intuitively obvious to me that that was the case - I had to do the math to prove it. Sometimes diving to a lower Pe and then doing a burn from there can be more efficient, I think.) 

Anyway, I royally screwed up the departure by trying to break up the burn into two parts.

Burn #1, to a Laythe Ap of about 2,000km.
Very nice scenic route out, but I forgot how quickly Laythe orbits Jool.
Burn now Laythe is way off the intended departure angle.
I didn't want to do one long (~8 minute) burn, so I split it into two with one final elliptical orbit of Laythe in between. This could work well, if I had actually planned it correctly. I routinely do this from Kerbin since the required transfer burns are huge and the ships are usually fully-fueled and heavy when they leave. But I forgot that Laythe orbits Jool much faster than Kerbin orbits the sun, so in just a single large orbit of Laythe, it has moved quite far in its orbit of Jool. Enough to severely mess up my departure angle. As a result, I used much more fuel than needed and my transfer orbit came out like this:

Far from parallel to Laythe's orbit = very inefficient.
And I have first thrown myself into deeper space...
So it was a good thing that I had plenty more fuel than anticipated for this leg of the journey. Lesson learned for future trips as well: plan in the extra time for the first burn or just do the entire Laythe departure burn in one go. One unintended benefit of this mistake was that the Kerbals got to see Eeloo, the elusive (oh, I get it now!) Pluto-like outer planet of the Kerbol system:

It's there, I swear. (Click to zoom.)
Anyway, more than a year later, and with a few course corrections along the way to fix my messed-up transfer orbit and get on the right orbital inclination, the Kerbals get their first glimpse of home:

The entire return trip took around 2,000m/s of Delta-V, almost twice what it should take and what it took last time I returned from Laythe. If I had tried the return method using two independent ships, they might not have made it back. As it was, with the single return ship, there was still enough fuel to pull it off. Here's a summary of the return trip Delta-V budget, an extreme worst-case scenario given how badly I messed up the departure angle:

The ship needed to slow down a lot at Kerbin, and it didn't have very much fuel to spare for an insufficient aerocapture, so I made sure to dive pretty deep into the atmosphere, targeting an after-aerocapture apoapsis of about 500km. Usually, my aerobraking spreadsheet tends to overestimate the Delta-V for hyperbolic orbits / aerocapture, so I was expecting to come out quite a bit higher. I had never tested aerobraking with docked ships, so there was also the non-zero chance of complete destruction. But actually, it worked quite well. It even makes sense physically, leading with the heat shield of the docked command pod. KSP doesn't model heat damage at the moment, so it doesn't matter much, but it does look cool:

And the aerocapture worked well, ending with an apoapsis of about 1,000km (less braking Delta-V than prediced, but more than sufficient for capture). Further light aerobraking passes lowered the orbit of the combined ship to about 100km.

The final step was to deorbit the command pods. I chose to do this one at a time. For one, I still wasn't very confident on the aerodynamic stability of the two-pod system. Doing one deorbit burn and then separating them was also out of the question: having two ships in the atmosphere at the same time usually leads to one disappearing forever. I had enough fuel left to deorbit one and then quickly turn around and put the remaining ship back into a parking orbit.

Step 1: Deorbit burn at the target crater.
Step 2: Undock.
Step 3: Turn around and quickly get back into orbit.
 By now I have almost perfected Kerbin deorbit using my precision deorbit calculator and can pretty accurately target a landing just off the coastal location of the Kerbal Space Center.

For the second deorbit, I decided to ride it out inside:

And after almost 1,000 game days and probably around 200 million kilometers of distance traveled, the two ships both landed within a hundred km or so of where they started:

The second splashed down probably 3km from the KSC...
So ends a mostly-successful mission to Laythe surface and back using a ship that wasn't really designed for the task. The technical parts of the mission, precision deorbits to hit what little land there is at Laythe and a first-attempt ascent, both went quite flawlessly based on the two simulators I made to assist. Transfers and aerobraking also went mostly well. The only real failure was the lander design itself - it's just too top-heavy to land on hilly terrain.

Overall, while it is immensely fun to plan and execute a mission with such little margins for error in terms of fuel, it's also time-consuming and tedious sometimes. Additionally, even if the lander could tolerate steeper inclines, this method of Laythe landing restricts landing sites to a location somewhere on the equator within roughly a 5º margin of error from the deorbit burn. There's no opportunity for exploring the surface, or even landing two or more ships in the same place. Every bit of fuel is needed for the ascent, so powered or rocket-guided descents are out of the question.

So a new, more flexible transport system between Kerbin and Laythe will be required for a sustained presence there. Larger transport ships and permanent refueling stations around Kerbin and Laythe are part of this. But most importantly, a new method of getting down to the surface and back up will be required. And towards that goal, I'll end with this teaser:

Tuesday, March 4, 2014

Link Update / Sensorless Gen. 1 Documentation

All of the documentation links on my site are dead.

It will take me some time to go through each one and re-link it to its new location. For the most part, everything will mirror to a Google Drive Amazon S3 folder, as such: is no more. For some reason it is without a doubt my most downloaded file. I guess I will take that as a complement. The new location is:

Other documents of importance in are moved to that same shared folder. Some more examples:

Since it's a shared folder, you can look at what else has been moved:
[Edit: Sorry! Google Drive disabled hosting. I've moved individual files over to Amazon S3 and will update links accordingly.]

In return for temporarily killing all of my documentation links, I will post some new old documentation that has been a long time coming:

Flux Observer-Based Sensorless Field-Oriented Control of  Surface Permanent Magnet Synchronous Motors (Gen. 1)
or, What Does the Flux Say?

This is an attempt to document my first attempt at sensorless field-oriented control (hence, Generation 1). The hardware implementation of this method was finished more than a year ago, but the documentation has been slow to catch up. I did a few posts on it, but only teased at the complete documentation of the Gen. 1 method. Well, here it is. Better late than never, I guess.

Originally, I expected this method to be a baseline, possibly the simplest implementation I could think of that would lead to more advanced techniques. Maybe Gen. 2 will be that step. But as is usually the case with my projects, just the act of actually building hardware and software has helped clarify my understanding of the problem, to the point where I could actually see the benefits of the simpler method and work it into an analysis framework that allows it to be deployed quickly and easily on new motors. And by quickly and easily, I mean with great pain and frustration unless you have a thorough understanding of how it works. Which is the point of the document, I guess.

For sure, the solution is not complete and not even ideal. It's just something that I use as a technical reference and might be useful in that context to others as well. I don't plan on commercializing the implementation because of the effort that would be involved in bringing it up to the level of being a reliable and user-friendly product, or even a development kit capable of being used by others to create such a product. (If it is to be commercialized, the improvements over Gen. 1 will be proprietary anyway.) But hopefully the information it has can be useful.

If you are looking for more of a developer-friendly kit / API for sensorless FOC, Texas Instruments has a solution called Instaspin FOC that I've been following since before it existed (motor control hipster-style): 
Although I can't be sure, I suspect the basis for it is also a flux observer. I'm sure the implementation is a lot more thorough, though.

Anyway, the field of motor control is vast and there is tons of information available. What's needed are people to take that information and use it, yes, but also improve it. Not just copy-paste into a system but also twist it into something different, find a better and faster way to do it, port it to new hardware. Not just ask questions about it but answer them in a new way. That's the challenging and fun part, IMO. Good luck!

Now back to fixing dead links...