KSP: Interplanetary Transport Ships I & II

Kerbal Space Program is my new favorite game, at least until Gran Turismo 6 comes out in the Fall. If you haven't tried it out yet, you should do so. (But only if you have many hours to spare while you discover just how hard it is to even get into orbit.)

Having gotten the hang of landing on Kerbin's moon (Mun) and return, I decided to move on to bigger and better things and build an interplanetary ship back in version 0.18 of the game. (It's still in development, so v1.0 is yet to be released.) The actual propulsive requirement for an interplanetary ship is not unreasonable, given the available parts, and Kerbals don't really care about other resources like water, food, and time. (Radiation shielding? Not important. They're already green.)

I speculated that the first Interplanetary Transport Ship could, with a Kerbin Orbit Rendezvous flight plan, make a trip to Duna, the Kerbol equivalent of Mars, and back. The trick is to dock two ships in low Kerbin orbit, transfer fuel to one, and then use whatever fuel is remaining in the second ship to boost two-ship combo towards deep space, into a highly-elliptical orbit of Kerbin.

The second ship then turns around and returns to Kerbin (using almost no fuel) while the fully-fueled ship continues to burn past Kerbin escape velocity and onto an interplanetary transfer orbit. It's very efficient, assuming you've timed your transfer correctly, leaving you with a nearly-full ship on the way to another planet, in this case Duna:

My method for timing the transfer was to print and cut out a paper triangle and wait for the planets to line up on the edges...

Another necessary technique for interplanetary travel is aerobraking: using the atmosphere of a planet (or moon) to slow you down, instead of rockets and fuel. It's a pretty complicated aerodynamics problem to figure out how deep into the atmosphere to go to reduce your speed by a desired amount. One option is to take multiple shallow passes, reducing your speed little by little, orbit by orbit. But what if you are attempting aerocapture: braking enough to be captured from a hyperbolic escape trajectory into a planet's orbit. There, you get only one chance. Too much and you are crashing to the surface. Too little and you are skipping back off into space.

Arriving at Duna on a hyperbolic flyby trajectory...set up for an aerocapture.

It turns out that there's some relatively simple calculating that one can do using only parameters readily available in KSP. I found this in a paper and presentation on aerobraking from an academic conference. There's still a lot of maths involved, but I arranged the important equations into a simple spreadsheet. Enter the current orbital data (speed and altitude) and the aerobraking altitude at periapsis (closest approach) for a particular body, and it will calculate the exit orbit. But does it work?

AAAAAAAAAAAHHHHHHHHHHHHH!

Aaaand capture.

After trying it out a few times on Duna and Kerbin, I can say for sure that that formula works. If you use the pre-aerobraking periapsis, the output orbit will be somewhat less energetic than predicted (lower apoapsis), but I think this is mostly due to the slight reduction in periapsis that occurs at the front end of the aerobraking pass. If you use the true periapsis from the middle of the pass, the result should be even more accurate. Of course, that's not useful for mission planning, so a more practical tip is just to leave some margin for error by targeting a higher exit orbit than you really want. 

The simple formula works for hyperbolic escape trajectories as well (possibly even better than for elliptical orbits, since the predicted periapsis is not going to change much when you enter the atmosphere on such an energetic, straight-line path). So, for aerocapture it's a very useful tool. Something from real-world rocket science is actually applicable to KSP! That was probably the most exciting KSP discovery for me yet. And it allowed me to get to low Duna orbit with essentially a full tank remaining.

Getting down to the surface of Duna is, without a doubt, the hard part.

As the Mars analog in KSP, Duna presents the same challenges to its potential landers as the real thing. The atmosphere is thick enough to permit the use of aerobraking and parachutes, but too thin to land on chutes alone, especially with the mass of a fully-fueled interplanetary ship coming down. I forgot that I had put four large parachutes on the ship for exactly the purpose of slowing it down, so I opted instead for a terrifying completely-powered descent on rockets. (Same as landing on Mun, but with much more gravity.) It was so terrifying, in fact, that I really didn't have time for screenshots on the way down. But here's the massive craft, landed safely on a slight incline:

The deorbit and powered descent took, in total, 2,059m/s of delta-v (the most convenient metric of propulsive effort, since it is independent of the mass of a craft). Though it didn't exist at the time, the official delta-v map of the Kerbol System suggest an ideal Duna landing from low orbit can be done on about 1,380m/s of delta-v, which I believe, since my landing was far from ideal. The ascent was much better, clocking in at 1,532m/s, plus an additional 110m/s for inclination adjustment to get in plane with Kebin's orbit for the trip home.

All tallied up, the round-trip mission from Kerbin orbit to Duna surface and back racked up 5,576m/s of delta-v from the primary ship and an additional 928m/s boost from the Kerbin Orbit Rendezvous ship. Had I used the ship as originally planned (staging all four side tanks and LV-N engines at the same time), the available delta-v would have been 5,685m/s, still enough to make the trip, but just barely. Mid-trip, I decided on the more efficient method of dropping two tanks at a time, reducing the weight of the remaining ship and extending the range a bit. But that gave me an idea for an even more capable ship, which I have now built...

Interplanetary Transport Ship 2

You'll also note the change in aspect ratio, indicating I can finally run KSP on full 1920x1080 on my new laptop!

This ship is built in v0.20 of the game, which has several new additions such as solar panels, new engines, and reentry effects (visual only, for now).

It's almost the same ship, and the launch booster is in fact identical, but there are subtle differences to the transport ship (what you see above) that make it much more capable than the last. The main difference is that two of the LV-N nuclear engines have been swapped out for LV-T30 liquid fuel engines. (Both engines use liquid fuel...the LV-N is much more efficient but also has much lower thrust.) This opens up the possibility of high-thrust ascent. The ship can even, just barely, lift off from Kerbin. (It would not be able to reach orbit, I don't think.) More interestingly, it has a comfortable thrust margin for lifting off from Laythe, the only other inhabitable body in the Kerbol system. Yes, this ship is designed for a round-trip mission to Laythe, just as the last was designed for a mission to Duna.

A Laythe mission would require very careful planning, and mostly likely both Kerbin and Laythe Orbit Rendezvous for refueling. (A total of three ships? Maybe even more.) And a completely powered descent to Laythe is pretty much out of the question - it will have to be parachute-aided. This is difficult since there isn't much land to target on the watery Kerbin-sized moon. However there's no fuel to waste tweaking the entry; almost an entire full tank of fuel is required for Laythe ascent, I think. It will be much, much harder than the Duna mission, but I think a relay team of these ships is capable of pulling it off, now that the problem of Laythe ascent stage has been solved by swapping two engines for ones with more thrust.

The beauty of the swap is that it doesn't hurt the efficiency of interplanetary burns at all. Two LV-Ns are just as fuel-efficient as four. The burns are just twice as long. Furthermore, the shorter LV-T30 engines leave enough room for some small fuel tanks. So although the ship is 3.9% heavier at launch than its predecessor, it carries 6.3% more fuel. A larger ratio of fuel to non-fuel means more delta-v. If used entirely for interplanetary burns (no atmospheric burns), and if the two empty tanks are dropped when they run dry, the available delta-v from the LV-Ns is 7,346m/s! Looking at the master map again, that's enough to go almost anywhere...

The mission outline might be something like this:

1. Two ITS2 ships dock in low Kerbin orbit. One is maxed out on fuel. The other is used to boost the first into a Jool transfer orbit, or as close as possible to one. (The primary ship can finish off the transfer burn.) The boost ship returns to Kerbin.
2. The first ship to Jool aerobrakes into an orbit that intersects that of Laythe. (Basically recreating this scene from 2010.) It then aerocaptures into Laythe orbit. All using minimal fuel.
3. Repeat steps 1 and 2. A second ship is now in Laythe orbit. The two execute a first Laythe orbit rendezvous. The lander ship (either of the two) is refueled.
4. Lander ship decouples and deorbits, landing on Laythe with the aid of parachutes. This is the trickiest operation, since there is very little land mass to aim for and almost no fuel can be wasted for tweaking the descent. Only a small burn at the end to slow the craft to landing speeds should be necessary.
5. Lander ascends, using most of its fuel to get into Laythe orbit and re-rendezvous with the orbiting ship.
6. The two ships return to Kerbin together, possibly first diving towards Jool to build up speed for a transfer burn? If this isn't possible, all crew and fuel would have to be transferred to one ship for the return. (Each ship is partially-crewed at the start for this option?)

It's a bit sketchy, but none of it seems impossible with the new ship. As long as it can get off of Laythe, the rest comes down to refueling waypoints. Before I take on the challenge, though, a few shakedown tests of the new ship:

A quick trip to Mun...

And my first landing on Minimus.

Did you know that it's possible to orbit a Kerbal on Minimus using jetpack propulsion? Deorbit did not go as well...

A test mission to the Joolian system, into Laythe orbit, and back is also in order to get a feel for transfer burn delta-v, aerobraking heights, and the best return path. (Dive towards Jool or direct from Lathe? My hunch is diving is much better.) I may also attempt to make some accessories to take. (Rover? Habitation module? Unmanned probes for testing Laythe descent trajectories?) For now, though, the primary ship looks solid and ready. Here are some specs:

Interplanetary Transport Ship II (ITS2)

Crew: 3

Empty Mass: 25.93t

Fuel Capacity: 34.00t

Full Mass: 59.93t

Engines: 2x LV-N, 2x LV-T30, 1x Rockomax "Poodle"

Maximum Thrust: 770kN (78.52t) 

Maximum Full Acceleration: 1.310g

Maximum Empty Acceleration: 3.028g

Range (Lander Configuration): ~5,340m/s

Range (Interplanetary Configuration): ~7,350m/s

NAB 2013: Where are the gyros? / New video editing software.

A couple weeks ago I was at the NAB Show with Freefly for the MōVI launch, the first product I've helped work on at the new job. That meant spending a lot of time doing the chicken head dance and explaining to people that there aren't actually spinning flywheel gyros on things anymore...

It's a camera gimbal, similar to what would be mounted to a helicopter or multirotor, that you can also carry around in your hands while it stabilizes the camera. (If you read this blog, I'm sure you know all about control systems and active stabilization so this probably doesn't amaze you as much as it still amazes the non-technical public...)

Since I spent nine hours a day at the booth talking to people about gyros (Wait, is this Maker Faire all over again?), I didn't get as much time as I would have liked to wander around this expansive tradeshow, which covered three whole buildings. (It's about 10x the size of the EVER Monaco Expo / car show I've been to a couple times.) There were definitely a lot of camera-carrying multirotors this year.

Here is just one of many....

I was mostly impressed by how it folded up.

There was also a giant two-story indoor flying tube where DJI showed off some of their products. And several outdoor booths with all manner of flying cameras ranging from GoPros up to big-budget cinema cameras like the RED Epic. Speaking of RED, they had a clean room installed on the show floor where they were doing live sensor upgrades to their new 6K / 100fps sensor. (So to watch the video it produces, you need nine HD screens in a 3x3 grid and it has to play in 4x slow motion...)

Most of the camera stuff at NAB is way outside my budget, but one thing that excited me was the Blackmagic Pocket Cinema Camera, which was also just announced at the show. It shoots raw or high bit-rate compressed 1080p video onto normal (but expensive/fast) SD cards. If I were planning to upgrade from my Panasonic HD camcorder in the near future, the $995 price is not that bad. The only real problem for me is that it weighs 355g, (maybe less than 500g with a small lens?), so I would be instantly tempted to put it on a multirotor, and then I would be at risk of crashing it all the time. I doubt it's as durable as my GoPro...

I think of all the NAB Show things I saw later read about on the internet, the one that caught my attention most was new, free-ish video editing software called Lightworks, by EditShare. I was pretty disappointed that the new Windows 7 edition of Windows Live Movie Maker is a stripped-down piece of crap, even compared to the at least somewhat functional WMM from the Windows XP era. (The old WMM had an active user community with lots of third-party add-ons for people who wanted to use it as an actual tool.) So a new piece of editing software that doesn't cost hundreds or thousands of dollars was definitely something I wanted to try out. And it looks like a very nice tool.

Maybe I was attracted to Lightworks because the desktop layout is almost indistinguishable from that of a CAD program:

Which of these is the video editing software and which makes 3D models?

Despite being a relatively new program (I'm using the Windows beta version), the interface feels very smartly developed and intuitive. Combined with a set of quick-start video tutorials, I didn't have to spend much time at all to learn how to do simple things like make clips, arrange a timeline, trim ins and outs, work with audio tracks, and add simple effects like fades and dissolves. The options for moving a cut are particularly nice: you can make clips on either side of the cut longer or shorter independently or have one get longer and the other get shorter at the same time (to keep sync). Maybe this is a pretty standard feature in professional editing software, but it's my first time using it and I can't imagine how to ever work without it now.

The only part of the workflow that was not quick and easy was exporting video. Importing from various formats works great, but exporting to something other than a hardcore (and huge) editing format was a challenge for me. H.264 support is through Quicktime, maybe? The new beta version may support native H.264 without Quicktime but I failed to make that work. So in addition to buying the Pro version of the software, you have to also have Quicktime Pro to create H.264 files? And then after all that the H.264 output had no audio (a known bug). Luckily, you can export the audio track as a .WAV, so after fooling around for a few hours to get the H.264 export to work, I still had to use my trusty all-purpose MEncoder shell program to reattach the audio.

I'm sure the export quirks will be worked out in newer versions of Lightworks, though. If the software stays the same price ($60 for the Pro version with full codec support, including H.264?), then it's an amazing deal for a real editing tool.

To test out the software, I've finally gotten around to collecting up all my random GoPro clips from around MIT, flying with my Talon quad. No fancy stabilized 3-axis gimbal for me (well, no gimbal at all...just taped to the bottom of the quad), so get ready for a rough ride:

Motor Dave is Back! (And so am I...mostly.)

I took a bit of a break from blogging to move across the country.

Loading up my cube during the coldest day of the year in Boston.

I escaped the Northeast right before the string of major snow storms and am now based in sunny Seattle at a company called Freefly Systems where I will be...doing pretty much the same thing I did in academia, over-engineer motor and control systems. I may occasionally re-post some cool videos from the job, but for the most part this blog will remain dedicated to my personal projects.

Some brief updates:

My custom-built glass table survived the trip, somehow:

The right angle joints rotate up to protect the corners of the glass. I totally designed it this way...

Pro-level ratchet strapping.

And I finally have enough room to put all four chairs around it!

If you ever find yourself needing to move a 100lb slab of glass across the country, let me know and I'll give you some tips.

I now own a car:

It's a bit wet in Seattle, actually....

If you don't believe me, figure out what this is a picture of.

Well, I own some fraction of a car...maybe 25%? More than I used to, anyway. Unlike Boston, It's pretty much a requirement for getting around. I haven't owned a car since high school and the car I had back then was worth less than my computer, so I'm glad to finally have something (hopefully) reliable and fun.

My Tesla coil in now only 3-4 orders of magnitude less impressive than a oneTesla:

I intentionally did not ship my coil with the rest of my possessions because I wanted to work on it a bit more before I left. (I promised Clare Fairchild that it would make some form of sparks before I left.) All systems seem to be working as expected up to this test which was at 48V DC input, so still low power. I carefully wrapped and shipped the coil separately so that I can continue to work on it here, when I get the chance, tuning it and turning the power up so that it can break out on its own. Once I get some respectable arcs, I will take another stab at writing a MIDI parser so it can play music.

tinyKart is a wreck, but it's getting a complete overhaul:

What

the

fuck 

happened

here?

Pretty much every part is covered two years worth of dirt deposited by snow and rain, including the most recent stretch of endurance laps run during a severe downpour at Maker Faire NY. Besides that, the damage report consists of: both pulleys and motor shafts (destroyed), one drive belt (destroyed), two spindles (bent), one brake mount (bent), both chassis plates (bent), and at least one full set of tires. Basically, the whole thing needs to be taken apart, cleaned, and fixed. However, that gives me the chance to do something I've wanted to do for a while: paint it.

Multirotor-assisted primer drying. Very effective.

It's done a lot more than we originally thought it would, so a bit of maintenance is definitely in order. It might take a bit of time to get it all back together properly, but when it is, it will look much better than it ever has, I think.

Lastly, Motor Dave is back! Dave Wilson, "Motion Products Evangelist" at Texas Instruments, has returned to the bloggernet as well with a new series on how to tune your PI controller, starting with Part I here. It's specific to the typical nested PI controllers involved in motor control (current, speed, position). If you haven't read his previous series, The Ten Commandments of Digital Control, you should. It starts here. I went to a TI workshop co-hosted by Dave about a year ago when TI's BLDC solution, InstaSPIN, was relatively new. At the time he hinted that there might be a future version: InstaSPIN FOC. Well, it's here now!

If you've been following my blog for a while, you probably have seen my many many posts of Field-Oriented Control, sensored and later sensorless implementations thereof. One thing I've not been very good with is putting out hardware that other people can easily access and play around with to try out this powerful motor control technique, without messing around with a lot of low-level code. (I like messing around with low-level code, but I can totally understand why most people hate that part.)

Anyway, you can now buy a kit for $300 that has enough power to drive a small electric vehicle motor and is loaded with a thorough FOC code library. Alternatively, you can just buy the control card with FOC library and develop your own high-power inverter stage. Or you can just buy the TMS320F28069 microcontroller with built-in FOC library and use it in your own hardware.

Though I haven't dug too deeply into the code, the basis for InstaSPIN FOC, and particularly the FAST observer, seems somewhat similar to the flux estimating structure I've used in my own sensorless routine. Flux is a nice quantity to observe, since it isn't speed-dependent like back EMF. The tricky part is keeping the observer happy at low speeds where not much rotor position information is available. InstaSPIN FOC seems to handle this situation using a "forced-angle" startup routine but then can also transition back through zero speed seemlessly when properly tuned.

I'm not sure it would cause me to deviate from making my own FOC software, but it's definitely something worth checking out. 

DRSSTC Δt4: First (Tiny) Spark!

This post is a bit time-delayed, but a couple of weeks ago, after spending way too long designing and building my first Tesla coil, I finally put the whole system together for some low-power testing. After switching from wired USB control to XBee wireless, there seems to be no more serial port hang-up at primary currents greater than 40A. So I can control the driving frequency, pulse length, and pulse duty cycle (including ramping) from my laptop. This should prove to be very useful for tuning the coil.

The supply voltage in the video is 30V and the maximum duty cycle is 50%. Driving frequency was 155kHz, which was experimentally determined to be the primary resonant frequency. I think the pulse length was ~15 pulses. Using a long insulated stick with secondary ground connection on the end, I drew small arcs out of the breakout point just to confirm that I was in fact getting high voltage. Nothing has been tuned yet, so the spark is very small. But yay, sparks!

I think the secondary resonant frequency is significantly lower, so I will adjust both the primary coil tap (to increase inductance, add more turns or fractions of a turn) and the driving frequency to attempt to get better amplification. The goal isn't to match the frequencies exactly, but rather to get them separated by the right amount to achieve good energy transfer during one pulse sequence of N cycles. For practical purposes, I can just tweak the tap point and drive frequency to get the best arc length at a given pulse length or maximum drive current.

Once it's tuned well at low power, I will incrementally add more voltage. :P

DRSSTC Δt3: Driver Testing

To start with, the MITERS-originated oneTesla Kickstarter is now up (and already funded!), so you can now buy your very own musical Tesla coil kit. It's pretty amazing: up to 23" sparks from a 10" coil using regular old TO-X IGBTs. And the custom MIDI interrupter can play up to two MIDI notes at the same time.

Anyway, work has been progressing on my Dual-Resonant Solid-State Tesla Coil. I finished most of the mechanical construction in Δt1 and Δt2, so that mostly left soldering and testing of the driving electronics. The power electronics comprise a MOSFET H-bridge, using just one IRFP4668 and one APT100S20B Schottky diode per leg (with the option to add a second FET per leg for higher power). This, combined with 2000uF of electrolytic bus capacitor and the ACNW3190 optically-isolated gate drivers form the power board, which rests on a large heat sink directly below the coil.

I found 10ft of energy chain and bought 10ft of shielding from the last Swapfest for making a a long run of shielded cable to go from the power board to the signal board.

The cable has 15V power, ground, and four differential gate drive signals, each in a cable shielded with signal ground. The gate drive signals are relatively low-impedance, since they drive the opto gate drive LEDs. At least a few mA is required to change their state, so they should be relatively immune to EMI, compared to logic-level signals. However, it's still very, very necessary that the LED drive lines be tightly grouped and shielded. The outer shielding is connected to RF ground at the base of the coil, and is mostly there to protect against arc strikes on the cable assembly.

The whole thing coils up for clean storage.

On the signal end, a wootstick 2.0 running an STM32F103CBT6 at 72MHz provides the brains. I was finally able to get the ARM micro to run at full speed (72MHz in this case). Over a year ago when I was first venturing into sensorless motor control I ran into a mysterious problem that was limiting me to 56MHz. Turns out it was a flash memory access latency setting, explained on page 60 out of 1096 in The F-Ing Manual. In case anyone else is having the same problem (I doubt it, since almost everyone else uses the standard peripheral library), the missing line of code was just:

FLASH->ACR |= 2;

Anyway, having full 72MHz operation is nice because even though there isn't much processor-intensive control code, the frequencies and timing on the Tesla coil are much faster than those of the motor controller.

The switches and lights on the right side control and indicate various levels of arming the coil, including the 15V gate drive power supply, a precharge and a main relay, and the logic power supply. In order to isolate the microcontroller logic supply from the 15V gate drive supply, I use the DCR021205 that worked so well on my 3ph v3.1 motor controllers.

Next up, my favorite part: testing gate drivers! For starters, I set up one of the timers on the STM32 to put out a ~150kHz gate drive waveform. (Two complementary pairs, 180º out of phase with each other.)

Having confirmed, that the timers and outputs were working, I hooked up the 10-foot signal cable and did my best to scope the gate signals themselves. I switched back to the analog scope, because it's just not possible to get as clean a picture of the rise/fall on the crappy digital ones (yes, I am a scope hipster). I also made myself a hack low-inductance differential probe for measuring the high side gate signal:

Since I chose all the gate resistor values with two FETs in parallel, the gate drive on a single FET was a little faster than I would have wanted. (Switching too fast causes major di/dt and dv/dt transients as the frequency content of the switching waveform starts to excite the parasitics of the gate drive and MOSFET.) So, to slow things down just a little bit, I added a bit more external resistance to the output of the gate drivers:

I swear this was the best way to do this...

With a total external gate resistance of about 8Ω, here's the low side turn-off and high side turn-on with no voltage on the bus:

The rise/fall times are ~100ns and the deadtime is about 377ns, using 220-ohm / 1.5nF on the deadtime generating circuit. With bus voltage, the turn-on and turn-off will be longer due to the Miller plateau, but it should still be well shorter than the deadtime. At 150kHz, two 377ns deadtimes accounts for about 11% of the PWM cycle. This would be a bit long for motor controller operation, but it's okay for the Tesla coil driver, which will spend most of it's on-time operation at or near 50% anyway.

As usual, I built a Visual Basic GUI to control the whole thing:

It sets the drive frequency of the resonant circuit (for tuning to the resonant frequency), as well as the duty cycle profile over a finite number of cycles that make up a single "pulse" sent to the primary. The duty cycle for each cycle can be ramped up to some maximum value, held, and then ramped down. The GUI also sets the frequency at which the pulses are generated, which is what will ultimately be used to play MIDI notes. Here's a quick video showing the GUI tuning process with just the primary:

You can seem me playing with the pulse lengths, as well as the drive frequency and some other parameters. A single pulse on the primary with no secondary present looks like this:

Close-up.

Zoomed-out.

The current on the primary (measured using a current transformer) rings up to some maximum value quickly as the square wave voltage excites the resonant circuit. (The current itself is mostly sinusoidal.) Then, after the drive pulse ends, the energy in the primary is slowly dissipated in its resistance. With a secondary in place, energy would be coupled into the secondary coil and the primary current would look a lot different. But for testing purposes, using the primary alone at low voltage allows me to actually scope things.

The first thing to check is the primary resonant frequency. From the design, I was targeting something in the range of 135-150kHz. Tapping the real-life primary coil at approximately 6 turns gave me a resonant frequency of 154.5kHz, measured by sweeping the drive frequency around to find the maximum ring-up. This gives a primary inductance at 6 turns of 10.6μH, since the primary capacitance was easily measured to be almost exactly 100nF. So, I'll probably have to move the tap out a little to get it in tune with the secondary. (The target frequencies for best coupling were 151kHz and 136kHz.)

Next, I wanted to use the decay time to estimate the real-life primary resistance. I could probably have just put in the peak values as initial conditions in a SPICE simulation of just the primary LRC resonant circuit. But, since I have a full SPICE simulation of the driver already, I decided to make things more complicated by having my VB GUI export gate drive waveforms to the SPICE sim, which would simulate the entire pulse sequence. I then tweaked the resistance value until the decay envelope on the SPICE sim matched up exactly with the one on the scope:

The magic number in this case was about 90mΩ, which seems accurate given that the skin depth on my 8AWG grounding wire is probably making it act more like 14AWG wire. But anyway, I now have a more precise simulation of the exact pulse sequence, including ramping and duty cycle control. This should be useful when it comes time to ramp up the power.

Speaking of which, I discovered the USB limit for this power system. As is also the case on many of my motor controllers, USB communication and high power simply don't mix and above a certain current (40A in this case) the GUI starts to get comm. errors. Typically, the micro and all the logic circuity can continue to operate without any issues - it's just a problem with the serial communication. Since I suspected this might be an issue, the plan is to use an XBee link to between my laptop and the logic board, the same trick I use to get data off of motor controllers while they're running. It may seem like running an RF link instead of a wired connection would be a bad idea in a Tesla coil environment, but I've been down this decision path before and the XBee always seems to win...

Next step: ramping up the power, tuning, and hopefully generating the first sparks!

Kerbals...in Space!

This might seem like a radical departure from the normal content of my blog, but I assure you that by the end of the post you will see that it is not. But yes, for I think the very first time I am going to post about a computer game! I'm not much of a gamer: the only game for which I ever achieved "fan" status was Gran Turismo, an epic racing game that frustrates most players because of the hyper-realistic physics engine.

Now I think I have achieved fan status for a new game: Kerbal Space Program, an epic space game that frustrates most players because of the hyper-realistic physics engine.

The Kerbals are a race of tiny green men who choose to go to the moon and do other things, not because it is easy, and not because it is hard, but because they seemingly have nothing better to do with their time and no monetary constraints or self-preservation instincts to keep them tied to the ground on their home planet, Kerbin.

"This will certainly go somewhere when we press the launch button."

The game has been under development for two years and is still pre-release. I was introduced to it by my brother back when there was only Kerbin and one moon. There is now a free version (v0.13.3) and a paid version (v0.18.1 at the time of writing). The paid version includes a vast solar system, more parts, and more features such as EVA (spacewalking) and docking. The real benefit of the paid version is that it gets you access to any and all future updates including the release version.

Thus far the pre-release versions have been true "open-world" games...except even that concept ceases to capture the nature of the game when there are six worlds and many moons to explore. While future versions will likely have "career" modes with a set of missions and a budget, the game right now has no concept of money or points. You build a spacecraft out of a set of parts, and then fly it to wherever you want.

Including, if you want, the top of the vehicle assembly building.

The parts inventory is made more entertaining by the descriptions of what each part does, which reflect the essential character of the Kerbals to some extent:

"The TR-18A Stack Decoupler is equipped with a (hopefully) small explosive charge, that will sever the structural linkage between itself and whatever it's connected to."

 "A monster of an engine for heavy lifting purposes, the Mainsail's power rivals that of entire small nations."

Also, parts are not limited to spacecraft: newer versions of the game include jet engines and aircraft parts, as well as a horizontal runway for commencing normal flight:

But although the sandbox aspect and the snap-together rockets and relatively humorous Kerbals make the game seem like it would be a good iPad app to kill time on the bus, the real nature and challenge of the game comes from the physics engine, which is based on real orbital mechanics in the Kerbol System, where planets are generally smaller but denser than those of the actual solar system. (Kerbin has the same surface gravity, 9.81m/s², as Earth, but is only 600km in radius.)

The first thing KSP teaches you is just how damn hard it actually is to get something into orbit. Getting into orbit is not the same as getting into space. A balloon can get into space (almost). To get into orbit, you have to both get out of the atmosphere and build up enough horizontal velocity so that you no longer need to spend fuel to fight gravity. (You fall as fast as the planet curves away from you.) For low Kerbin orbit, this requires a speed of about 2,000m/s.

But because you're fighting gravity and aerodynamic drag on the way up, the actual amount of propulsion needed is much higher than would be required to go from 0 to 2km/s in space. In fact, the actual speed increase (ΔV) you would be able to achieve in space using the amount of fuel required to launch into low Kerbin orbit is something like 4.5km/s. To put any sizable payload, like a ship that can go to the moon (called Mun in the game) and back, into orbit requires a pretty large rocket.

Note the speed is still well below orbital velocity.

So the next thing the game teaches you is what spacecraft are mostly made of: fuel. The rocket equation tells you that the ΔV you can achieve with a particular rocket is limited by only two things: how fast the exhaust is, which is a property of the engine, and what fraction of the rocket's mass gets thrown out the back. Only the ratio of starting to ending mass matters, so a small rocket or a large rocket can get into orbit equally well if they have the same engine and are both 70% made of fuel. The only reason to use a larger rocket is so you can put more final mass into orbit.

The realistic physics lead you to create multistage rockets. Once on stage's fuel is used up, you detach it to get rid of the dead weight (thereby increasing the percentage of the remaining mass that is fuel). There are also trade-offs among different engines: some have higher exhaust velocity but too low of a burn rate to produce enough thrust to get into orbit. These are better for maneuvering in space. So you wind up having to think carefully about the design of the spacecraft if you want to go farther.

For example, you can go to Duna, the Kerbol System equivalent of Mars.

Another cool feature just recently added to the game is docking. If you think aiming for a small moon is hard, try aiming for another ship which has no gravitational attraction with which to pull you in when you get close enough. Maneuvering two ships in orbit to the point where they could be docked was by far the hardest thing I've had to do in the game so far. But the reward is an almost unlimited ability to build larger ships or refuel in space.

The game does not (yet) have an autopilot that will help you launch, land, dock, transfer orbits, etc. But it does have a nifty maneuver planner that will show you the anticipated result of a maneuver at some point in your orbit. It will show you which way to point your ship and give you a countdown of how long to burn your engines to get where you want to go. But you still control the pointing and burning, so it's still a bit hard to do really precise long-range orbital maneuvers. For example, it's possible to do single slingshots but something like a Voyager trip would be very hard to do without a more advanced planning and autopilot system.

So far, I have been able to make successful trips to the Mun and return. I also made a one-way trip to Duna, which was punctuated by a harrowing untested parachute descent which barely cleared a crater wall.

Clearing the crater wall by about 1km while still going 0.5km/s...

Looking out from the crater rim to the landing site.

My current spacecraft, designed from scratch for interplanetary travel in v0.18.1, looks like this:

Stage 1 is driven by four Mainsail engines, the largest in the game, and burns for the first ~75 seconds of the launch. Stage 2 has a single Mainsail engine and burns for another ~85 seconds. These two massive stages are able to produce a total ΔV of 3.39km/s (Yes, I calculated it. As an interesting comparison, the ΔV possible from the two stages combined into one, with five engines all burning, is about 2.92km/s.) While quite heroic given the massive payload, this is not enough to get into low Kerbin orbit, so Stage 3 has to do some work on the way up.

Stages 3 and 4 combined are the interplanetary portion of the ship, designed for taking three Kerbals to the far reaches of the Kerbol System, and maybe sometimes back.

Stage 3 uses four of the "atomic" engines (strange name since they run on normal liquid fuel...) which are the most efficient stock engine (highest exhaust velocity). But they have relatively low thrust, so they're not great for getting off the planet. They work best for long burns to perform transfer orbits. Stage 4 is the lander itself, which uses the "Poodle" engine. This engine has enough thrust to get off a small planet or moon. You can see it landed on the Mun in the first image of the post.

Stage 3 and 4 can produce a whopping 5.67km/s total ΔV. That should be plenty to go to most destinations and back from some. I think it can do a landing and return from Mun, Minimum, or Duna, although the latter two are untested. A Duna return in particular would be hard due to the uncertain amount of fuel required to land on and take off from Duna. (Minimus requires very little fuel for this since it's tiny and has no atmosphere.) Other planets are either too massive or too far (or both) for a landing and return trip, I think. But flybys and one-way trips to almost anywhere should be possible.

But, Stage 3 consumes about half its fuel just to get into Kerbin orbit. That's why I was so excited to try out the docking feature. Now I can combine two ships in Kerbin orbit and transfer full fuel to one of them. I can even use most of the remaining fuel in the second ship to boost the whole assembly out into deep orbit, a trick that should bump the whole mission's ΔV starting from low Kerbin Orbit to something like 6.52km/s. That amount of fuel should provide plenty of deep space maneuvering ability for going to check out places like Laythe, a potentially habitable moon of Jool (Kerbol Jupiter)...

So many possibilities.

And now I feel the need to apologize for any number of person-hours of productivity this post will cause to be lost forever into deep space.