Snark

Yeah, the problem with that rocket is that it's got that huge, draggy, probably lightweight fairing up front, and the heavy stuff back behind.  It's going to be aerodynamically unstable.
The first thing to try is, put some fins on the bottom.  Steerable fins would be best (e.g. the AV-R8 winglets), but even non-steerable fins would help, if they're big enough.  Put them as low down as you can manage.
The other thing is to start your gravity turn fairly early and keep pointing precisely as you fly-- that will also help flipping.

Is this useful?

(Not mine, this is something posted by Oren in IRC.)

If you literally don't have any antennas on the craft, then no, you can't transmit any science.  Antennas are the only way to do that.
(If the problem had merely been "I have an antenna but it doesn't have enough range", then all you'd need to do is to bring some powerful receiver close enough to it.  But if you have no antennas at all, then no, no transmission is possible under any circumstances.)
So, what can you do?  A few options:
Figure out a way to bring the craft back to Kerbin. Bring a crewed craft to it.  Kerbal goes, grabs the science, takes it back to a ship. Send a craft with an antenna and a klaw.  Grab it, then use the new craft's antenna to transmit. Just launch another spacecraft and go to the same places, and don't forget the antenna this time. 

Yes, there's something called "max Q"-- it's the point of maximum aerodynamic forces on the rocket.  Discussion of what it is IRL in spoiler.
Real-life rockets have to care about max Q, a lot, for a few reasons.  KSP rockets, however, don't have to care.  Technically max Q is there-- I mean, there really is some point at which aero forces reach a maximum-- but that's basically irrelevant and nobody ever bothers to keep track of it because it's not important in the game.
To understand the reason why KSP rockets generally don't care about max Q, it helps to understand why real-life rockets do, so that we can see why those reasons don't apply to KSP.
Reason #1:  Structural integrity.  Slamming a vessel through the air at several times the speed of sound is harsh.  It generates tremendous pressures and shockwaves.  It can rip a rocket to shreds.  This becomes especially important when you consider that rockets have to be built as light as humanly possible to maximize their dV, which means they tend to be made of thin, fragile materials-- you can't armor-plate 'em.  When engineers are building spacecraft components that are going to be slamming through air-- fairings, for example-- they have to decide "how thick or thin do we make the material".  Thinner is better for saving weight... but it also makes it less strong.  If you make it too thin, it'll buckle under the pressure.  So they want to make it "as thin as possible without being too thin".  To know just how thin they can get away with, they need to know "what's the maximum aerodynamic stress that this will be subjected to".  That's exactly what Max Q is all about, which is why people care.
Note that this applies not just at design time, but also at flight time.  For example, after running the numbers, they may decide "okay, we'll throttle down for a bit in early-mid-ascent, so that we wait until the air's thinner before we really hit the gas, so that we lower max Q."  That means more gravity losses, which can hurt dV... but if you've lowered the max Q, maybe you can get away with using thinner / lighter materials, and the weight savings may offset the increased gravity losses.
Why KSP rockets don't have to care about that:  They're made of magical, infinitely strong material.  Well, okay, not quite infinite, but it's pretty darn hard to cause a structural failure due to aero stress during ascent, unless you've built some weirdly fragile thing.  And in any case, KSP rockets are made out of immutable Lego-style parts, so it's not as if you have any choice of "use thinner or thicker materials".  Everything is armor plated.  Therefore, you might as well slam the throttle to maximum to conserve dV.  You don't have to worry about max Q because your rocket will never shred itself during ascent.
Reason #2:  Fuel efficiency.  A rocket needs a certain amount of dV to get to orbit.  There are two ways to lose dV:  gravity losses, and aerodynamic drag.  Gravity losses get worse if you're climbing slowly, so to minimize them, you want to accelerate as hard as possible as early as possible, and keep burning at the absolute maximum until you're finished with your ascent burn.  Aerodynamic drag, however, is the opposite:  it gets worse when you're going faster, and to minimize it you want to be careful not to go too fast when you're still down where the air is thick.  So, "what acceleration profile is the most efficient" will be some balance between the two.  It may be worthwhile for a rocket to throttle down a bit in the early part of a flight (so as to lower max Q and try to avoid too many aero losses too soon), then throttle up when the aero losses peter out.
Why KSP rockets don't have to care about that:  Kerbals live in an alternate universe with unrealistically tiny planets, which means orbital speeds are much lower.  Circular orbital speed in low Kerbin orbit is less than a third of Earth's.  This means that for most kerbal rockets, gravity losses are overwhelmingly higher than aero losses, since the rocket's not going so fast.  At any given altitude, there's some "ideal speed" for maximum efficiency, and that speed increases with increasing altitude.  Unless you've overbuilt your rocket with a ridiculously high TWR, a KSP rocket never "catches up" to that ideal speed during ascent-- the ideally-efficient speed is always faster than you're currently going.  That means you don't give a wet slap about max Q, because the answer to "when should I throttle down" is essentially "never".
 
I'm not an IRL rocket guy, so I don't know the degree to which IRL rockets care about reason 1 versus reason 2... but the point is, they have to care.  And KSP rockets don't.
So that's why you generally don't see much talk about max Q here in the forums.

Moving to Gameplay Questions.
Here's a fairly simple manual technique that works reasonably well: use a little trick with maneuver nodes and let KSP do the math for you.
Here's how it goes:
Put yourself into a suborbital trajectory,  so you're on a collision course with the ground.
Switch to map mode, and drop a maneuver mode right exactly at the point where your projected course intersects terrain,  i.e. right at the impact point.
Drag the handle of the node until the projected post-maneuver trajectory collapses to a point (i.e. Ap right at ground level where the node is).
Switch back to flight view, make sure the navball is in SURFACE relative mode (not "orbit"), and set SSS to "hold ".
Now you're set, and the maneuver node's burn time indicator tells you what you need:
The "time until burn" is how long until you go splat. The "estimated burn time" tells you how long your burn will be.
So all you do is wait until the time-until-burn is about 60-70% of the estimated burn time, then max the throttle.  For example,  if the estimated burn time is 10 seconds, you'd wait until it's about 6 or 7 seconds until the node before goosing it.
It's not *exact*, so you'll need to keep an eye on the terrain and make small adjustments as you approach touchdown,  but overall it works pretty well. 
Incidentally,  if you don't mind *some* mod assistance,  you may like to consider BetterBurnTime. It doesn't automate anything;  you're still doing all the flying yourself.  It just gives more accurate burn info on the navball, and automatically provides the above-described info (time until impact, estimated burn needed) without your needing to tinker with a maneuver node.

Aaaah, now I think I see what may be going on here.
In the stock game, there's no such thing as "pointing an antenna toward a target".  The stock comms system is very simple.  Every antenna has a certain "antenna power", and that's it-- there's no such thing as "aiming" them.  To find out whether there's a communications link between A and B, you just compare their respective antenna powers against the distance between them, do the math, and there you go.
However... there does exist a communications mod that does involve targeting antennas at things.  It's called RemoteTech.  Back before KSP added CommNet to the stock game in version 1.2, there was no comms system in stock.  Back then, the RemoteTech mod was basically the only game in town, if you wanted to build communications networks.
Then KSP 1.2 came along, with stock CommNet, and suddenly people didn't have to go to RemoteTech to have communications.  The stock game can do it.
That said, though... RemoteTech is still around.    It has a considerably more complex communications model than the stock game does:  antennas have to be targeted, they consume power all the time while turned on, there's lightspeed delay in signal transmission, it has a simple autopilot for automated commands, etc.
RemoteTech not only re-purposes the stock antennas, but it also adds several new antennas of its own.
Anyway, my guess is that the video you were watching was probably of someone playing with the RemoteTech mod installed?

Great, that narrows the scope of the problem.    So, this isn't an engineering problem-- it's a navigation problem.
So, basically you need to figure the following:
When to launch What path to take (i.e. what sequence of burns) How much dV it will need (so you can design your ship) Here's the executive summary of how to pull this off:
Eyeball where your target ship will be at intercept time. This is so you know where to aim. It's easy & quick. Figure out which launch window will take you there. This is so you know when to launch. Reasonably straightforward. Figure out what path you'll take, i.e. what sequence of burns. This is so you'll know how much dV you'll need, which is necessary in order to design your rescue ship. This step is the tricky bit, because it's where you figure out most of the navigation.  Design and launch the ship. This one's an engineering problem, not a navigational one.  So I'll assume you've got this covered. Plot the course. This one's just a verbatim replay of the figuring-out that you'll do in step 3 above, so therefore it's easy. I'll talk you through steps 1 and 2 here, then pause for a breather to see what you think before going on.
 
Step 1:  How to eyeball where the target will be at time of intercept
Well, that's hard to do precisely, but fortunately you don't need to.  For purposes of this step, you only need to eyeball it approximately, and in your particular case that's pretty easy to do. 
Why is it easy in this case?  Because you've got that nice, long seven-years-out-of-a-nine-year flight ahead of your ship.
It means that if you open your map view, you can already see where your troubled ship is going to hit its solar Ap, nine years from now.  So you just need to visually estimate "where is the ship going to be, around 2-3 years before Ap".  And that's easy to do, because those last 2-3 years are going to be when the ship is moving super slowly (because it's waaaaaay out in the outer solar system at the outer end of a very eccentric orbit), so it won't cover much distance during that time.
So all you need to do is look at where your target ship's solar Ap is, and then mentally estimate a point along the orbit that's "a bit" before that.  It helps that you don't have to get it exactly, because as long as you can get it somewhat approximately, that's good enough for launching purposes.  Even though you won't nail it perfectly, the error will be easily corrected by adjusting burns at launch time and won't cost an unreasonable amount of dV.
In other words:  If you picture the solar system as a clock dial with the sun at the center, all you're trying to guesstimate is "at which o'clock will the intercept happen", and as long as you get it within one or two clock-hours, you'll be fine.
(Note:  If this kind of wild-ass guesstimate bugs you and you'd prefer a more accurate picture, you could always just do a quicksave and then timewarp ahead 6-7 years to see where the ship is, then go back and reload.)
 
Step 2:  How to pick a launch window
This also is pretty straightforward, because you have a lot of flexibility here.  A digression into why it's so flexible and why you don't have to worry too much about this, in spoiler section.

Okay.  So, picking a general launch window is pretty straightforward here because you know what direction you're going (having estimated the intercept location in step 1 above).  You know that you want to eject from the inner solar system going in a certain direction.  So all you need to do is pick where to eject from Kerbin in order to make that happen.
There are a few ways to slice this, but there are two main types of path you could follow, both of which probably involve a similar amount of dV, so you should just pick whichever one is available soonest.  (Yes, there will be some dV difference between the two, but it won't be a huge difference and you've got a fair amount of dV to play with, and time's a-ticking so sooner is probably better.)
Broadly speaking, the two choices of trajectory you could take are direct and bi-elliptic.  More wordage below, but the executive summary of these two paths looks like this:
Direct path:  You eject from Kerbin in the solar-direction, and shoot out to the intercept in a fairly straight (i.e. only slightly curved) line. Bi-elliptic path:  The exact 180-degree opposite.  You eject from Kerbin in the solar- direction, such that your path takes you down to a fairly low solar Pe.  Then you wait until you get down to solar Pe and do a big burn there.  In other words, you eject from Kerbin going the "wrong direction" but then use the sun's gravity to make a U-turn. In case you're wondering, "what's the longest I'd have to wait for one of these windows to pop up, some analysis in spoiler.
TL;DR:  you don't have to wait all that long for a window.  Significantly less than half a Kerbin year, even in the worst possible case.
Okay.  Now that we've established that you won't have to wait too long... let's figure out which of the two path types you want, and when to launch.
To describe these, I'll go back to the clock metaphor again.  Picture the solar system as a clock dial, with the sun at the center and your target intercept location (i.e. nearly out at the distance of Neidon) as being on the rim of the clock.  On that scale, Kerbin is orbiting really really close to the central hub of the "clock".  To keep visualization easy, let's rotate our frame of reference so that the intercept location is at 12 o'clock on the clock rim.  I'm assuming you're looking down at the solar system from over the sun's north pole, so all the planets are orbiting counterclockwise.
So what we're trying to figure out is, "at which o'clock would Kerbin need to be located in order to launch on a direct path?"  And same deal for a bi-elliptic path.  Got it?
Okay, let's look at the direct path first.
Imagine the slowest possible scenario, where you're trying to optimize for "minimum dV" and don't care how long it takes to get to the destination.  In that case, you'd want to launch when Kerbin is at the 6 o'clock position.  That's because your transfer path is half of an ellipse, so you're going through 180 degrees of clock in order to get to the destination. On the other hand, imagine the fastest possible scenario, where you're trying to optimize for "get there as soon as possible" and you have infinite dV to play with.  You're shooting the ship like a rifle from a gun, and you'll be travelling in a nearly perfect straight line the whole way.  In that case, you'd launch when Kerbin is at the 3 o'clock position, because the target's at 12 o'clock and Kerbin-at-3-o'clock is where Kerbin is traveling in the desired direction, i.e. straight towards the target. So, those are the two extremes.  You're going to be somewhere between those two extremes, because on the one hand, you do want to get there reasonably quickly (you have to catch up to the target, after all), but on the other hand, you don't have infinite dV.
So, as a broad guesstimate, you'd probably want to launch when Kerbin is somewhere between the 4 o'clock and 5 o'clock position-- I'd guess closer to 4 than 5.
Okay, that's the direct-path launch position.  What about the bi-elliptic launch position?  Well, it's around 180 degrees away, so that would be likely between the 10 o'clock and 11 o'clock positions.
Right.  So.  Rotate your map view so that the intercept location is at 12 o'clock, and look at where Kerbin is now, and picture Kerbin continuing in its orbit.  Will Kerbin arrive at roughly 4-5 o'clock sooner?  Or 10-11 o'clock?  That'll tell you which one of the two main path types will open up to you sooner, so you can pick that one.
 
Sorry... I know that's a whole lot of words.  (I tend to do that a lot.)  But the actual concept behind it is pretty straightforward, and hopefully it'll be clearer when you actually look at it in-game.
Anyway... how's this so far?  Does it make sense?  Is it useful?  Too much detail?  Too little?  Just wanted to touch base before going on to the tricky bits in step 3. 

I get it myself from time to time, too (with engine shrouds)-- I think it's a stock bug.  It happens to me pretty rarely, and when it does, quicksave/quickload always fixes it for me-- I've never seen it not work.  So it's a pretty minor issue for me, given that it's a rare hiccup that's easily/reliably fixed.
Also, it never happens to me for heat shields, ever, just because I never have heat shield shrouds.    I've never liked the shrouds on the shields-- I find them ugly-- so I always play with a little ModuleManager patch that turns off the heatshield shrouds, and tweaks the connector node on the shields so that parts automatically attach snugly and directly to the heat shield itself, which is always what I want anyway.  Looks way better (to me, anyway), makes building ships more convenient.  The fact that it also happens to prevent the shroud bug for heat shields is just a convenient side benefit. 

Going to Duna is easy:  assuming you aerobrake and use a parachute, it actually takes considerably less dV to land there than it does to land on the Mun.
From LKO:
Landing on the Mun:  860 m/s transfer burn, plus 310 m/s braking to orbit, plus 580 m/s to land = 1750 m/s from LKO Landing on Duna:  1080 m/s transfer burn.  Aerobrake (free), land with parachute (free).  Ta dah!   
Coming back from Duna, though, is more expensive than coming back from the Mun:
From the Mun:  580 m/s to orbit, plus 310 m/s to escape and head homeward:  890 m/s From Duna:  about 1200 m/s to orbit, then 610 m/s to head home, total 1810 m/s. So, from LKO, you can do a round-trip Mun landing for around 2640 m/s, and a round-trip Duna landing for around 2890 m/s.
So, the Duna mission only needs about 250 m/s more than a Mun mission! 
 
Thing is, though... that it's different.  And so you need to adapt your strategy accordingly.  (The following advice assumes you're simply doing a Duna-and-return mission without involving Ike, just to keep things simple.  If you mine fuel from Ike, then of course it's a whole different ball game.)
First, make sure you don't waste fuel landing on Duna.  It's easy to faceplant there, since the atmosphere is so thin that if you Do It Wrong™, you can hit dirt at speeds much higher than parachutes can cope with.  There are a variety of landing strategies, but my personal favorite is this:
Put a pair of tiny drogue chutes on the lander, and one regular parachute. Drogues are set to open at the highest possible height, 5000 m.  Regular parachute set to open at 1500 m or so. Drogues kick in at around 600 m/s when low enough, which then slows the ship to the point that the regular chute opens. The regular chute won't slow it anywhere near enough to land-- it'll be like 30 m/s as it descends to the surface.  But then give it just a very brief blip of rocket power right at the moment of touchdown to cushion the landing. It's actually possible to spam enough parachutes to land on Duna on chutes alone... but I like doing the above, instead.  Reason:  you need so many parachutes that they're heavy.  The fuel you burn in that little-blip-right-at-landing is a lot lighter than all the extra parachutes, so it saves mass.
Second, take off efficiently from Duna.  Its atmosphere is a lot thinner than Kerbin's, and your local TWR is likely to be higher, so you can do a significantly more aggressive gravity turn.  Saves dV.  Do it right, and you can get to low orbit for around 1200 m/s.
One decision point is whether you want to do a direct land-and-return mission, or do an Apollo-style orbital rendezvous.  Both of these can be made to work, and it's not that big of a deal either way.  It's a matter of your personal preference and play style:
A direct land-and-return means that your lander has to have at least 1810 m/s of dV remaining, after landing.  So that's a respectable chunk, and it means your lander's going to have to be fairly good-sized, which in turn means it's going to be a fairly big (and therefore more expensive) craft upon takeoff from Kerbin.
In the Apollo-style mission, you leave an orbiting vehicle around Duna, and the lander only carries enough fuel to descend to the surface and then return to orbit.  There are a few ways to slice this.  You could make the orbiter be just a fuel tank, i.e. the lander is also the Kerbin return vehicle, and it simply refuels from the tank upon returning to orbit.   Or you could make the orbiter be the return vehicle, with its own crew pod and engine, so that you leave the lander parked in Duna orbit when you go home.  Either way works.
The Apollo-style mission allows for a smaller craft, because that's a big chunk of fuel that you're not schlepping down to the surface of Duna and back again.  This means that the overall mission can be smaller and therefore cheaper.  However, it does present more of a navigational challenge.  First, it means that on initial approach to Duna, you need to aerobrake to low orbit rather than descending directly to the surface, which is certainly doable, but it's challenging-- Duna's atmosphere is so thin and so vertically shallow that the difference between "aerobrake too much and go down to the surface" and "aerobrake not enough and go flying off into space" can literally be only a few hundred meters of altitude.  So it's finicky and will probably take a fair amount of trial-and-error to get right.  Also, it means that you need to be able to do orbital rendezvous and/or docking.
So, what it boils down to is:  Apollo-style is smaller and cheaper but needs more piloting and navigational skill; direct land-and-return is bigger and more expensive, but simpler to do.  Pick what works best for you. 
Also, make sure you have a good transfer window, both going to and returning from Duna.  The numbers quoted above assume an ideal transfer window.  If you've got a bad window, you would need a lot more dV.  There are a variety of tools out there to help with this-- my personal favorite is http://ksp.olex.biz because I like its simple interface and graphical display.  The TL;DR is that you should launch to Duna when Kerbin is 44 degrees behind it, and return from Duna when Kerbin is 75 degrees behind it.
 
And finally, the emergency-when-all-else-fails thing to bear in mind:  Kerbal EVA packs have a whopping 600 m/s of dV in them.  So, if you find that you've shaved it a bit too close and you don't quite have enough fuel to make the return-to-Kerbin burn from Duna... you could always go EVA, grab the science out of the ship, and then just thrust your way home that way.    If you can get to low Duna orbit, a kerbal has nearly enough EVA juice to fly all the way home to Kerbin.  Of course, there's no way the kerbal would survive Kerbin reentry... but you could always put them on a near encounter with Pe just above atmosphere, and then send up a rescue ship to snatch them as they go whizzing past.

It's not a "flag" in the sense of "a piece of cloth draped off a framework that a kerbal can plant in the ground."
It's a completely different, unrelated use of the  word "flag ", meaning basically "configuration setting".  It has to do with kerbal behavior.
The different kerbals have different "personalities", which affects the way they react to things in-game.  There's a discussion of it on the KSP wiki here:
https://wiki.kerbalspaceprogram.com/wiki/Kerbonaut#Personality
...Each kerbal has a "courage" and a "stupidity" rating.  These ratings affect how the kerbal "emotes" in various situations (i.e. excited, scared, etc.)  It has no effect on gameplay, it's purely just about their facial reactions.  In addition to courage and stupidity, a kerbal may also be "bad-ass". Unlike courage and stupidity, which are numbers  on a variable scale (e.g. a kerbal could have a tiny bit of courage, or a lot, etc.), being "bad-ass" is simply an on/off setting-- either a kerbal is bad-ass, or they aren't.  Bad-ass kerbals behave differently-- basically, they're super thrilled and excited by all kinds of crazy stuff going on ("Explosions?  Wheeeeee!") and never get scared.
Among the four kerbals that you start with in the game, Jebediah and Val are bad-ass; Bill and Bob are not.  Other random kerbals that you hire or rescue have a small, random percentage chance of being bad-ass.
Unlike courage and stupidity, though, you can't actually see anything in the game to indicate "this kerbal is bad-ass", other than their facial expressions in times of crisis.  For example, if you go into the Astronaut Complex and look at your roster of kerbonauts, for each one it shows you what their courage and stupidity ratings are... but there's nothing in the game that shows you their bad-ass status.
The reason you see this referred to as a "badS" flag is that that's what it looks like inside the game's files.  If you open up a save file (e.g. persistent.sfs) in a text editor and find the definition for a kerbal, you'll see something like this:
KERBAL { name = Jebediah Kerman gender = Male type = Crew trait = Pilot brave = 0.5 dumb = 0.5 badS = True veteran = True ... } ^ the place where it says "badS = True" indicates that yes, this is a bad-ass kerbal.
As for "why 'badS'", I assume that some programmer with a sense of humor picked that because saying "bad S" sounds kind of like "bad-ass".

...Not sure what you mean?  What "blueprint" are you talking about?  "unity file"?  "made completely into a mod"?  "REESES seat"?
Can you provide a bit more detail about what you're trying to do?

Same process that @bewing describes above:
EVA pilot #1 Space bar to let go of ladder ] key to switch back to ship EVA pilot #2 Space bar to let go of ladder P key to activate parachute Hit ] key until you're focused back on pilot #1 again P key to activate parachute.  

It only has the ground stations if you leave 'em turned on. 
There's a game option "Enable Extra Ground Stations", which is turned on by default.  Turn it off, and you only have KSC.  Then building a communications network becomes a bit more of a challenge.
(Of course even there you don't need to have a synchronous satellite if you don't want to-- for example, you could have a constellation of low-altitude satellites.  But it does give synchronous ones at least some point.)
My personal way I like to play:  1. Commnet enabled, 2. Require signal for probe control, 3. No extra ground stations, 4. Occlusion modifiers set to 1.0.  But that's just because I enjoy setting up comm networks and it's a major source of fun for me.

In the map view, click on the planet and then choose "Set Focus" in the little dialog that pops up.
When you're done and want to focus back on your ship, there's a keypress for that-- depending on your keyboard layout and how long you've had KSP installed, it may be the backspace key, or it might be the back-tick key (i.e. the key with ~ on it that's to the left of the 1 key on US keyboard layouts).
Note that a very handy thing you can do is to plop down a maneuver node in interplanetary space, then (before adjusting the node) switching focus to the target planet, then rotating the camera around until you can see the maneuver node out there in space, and then adjusting the node by dragging on its handles.  This lets you fine-tune exactly where your path will take you when you arrive at the destination.

What this means is that you've got two problems:
Something (likely aerodynamic force) is causing them to go inwards when ejecting, rather than harmlessly outwards which is what you want. It's taking a long time for your center core to move far enough forwards, relative to the ejected boosters, that it is no longer in danger of collision. It would help if you could post a screenshot of your ship-- that would let us give you specific advice, i.e. "oh, you're doing this!  Change that thing to be this way instead", you get the idea.
However, in the absence of a screenshot, we can offer some general advice.  There are various things you can do to help the problem.
Mount your radial decouplers as high as possible on the radial booster.  Or, put another way:  after you've placed the decouplers on your central core, you want to place the booster as low down on the decoupler as you can, so that the decoupler is near the front of the booster.  Specifically, you want the attachment point to be above the radial booster's center of mass.  Why is that?  Because that way, when the decoupler fires, its ejection force will tend to make the booster rotate outwards (because it's kicking the booster's nose outwards), which will then cause aero forces to move the booster away from your central core.  It's possible, for example, that your current design might have the decoupler attached below the booster's center of mass, which is bad-- that' because it's kicking the back of the booster outwards, which points the booster inwards, which makes aero forces slam it against your central core, which is bad. Mount the radial boosters as low as possible on the central core.  In general, what happens when you eject radial boosters is that they start to fall behind your craft.  That's because they're no longer thrusting, but your central core is thrusting.  If you can mount the boosters really low on your central core, it means that the central core doesn't have to travel very far before it "clears" them, i.e. it gets far enough ahead so that the back of the central core is in front of the forward tip of the boosters.  By that time, the boosters are behind you, so it doesn't matter if they move inwards and smash into each other.  Think of it as a "race":  the radial boosters move inwards to smash your central core, but your central core moves forward to get out of the way.  By mounting the radial boosters nice and low, you're stacking the deck in favor of your central core "winning the race" and getting out in front of them before they have a chance to wreak mischief. Use a more heavy-duty radial decoupler.  If you have a big booster, you may want to consider using the Hydraulic Detachment Manifold instead of a more lightweight decoupler like the TT-38K.  The bigger decoupler is heavier, yes, but it also has a stronger ejection force and does a better job of kicking the booster outwards. Use sepratrons.  These are little surface-mountable tiny SRBs.  You can attach them to your radial boosters in strategic locations, and set them up in the staging UI so that they activate at the same time you activate the radial decouplers.  Set them up so that their thrust moves the front end of the boosters away from the central core. If the boosters are big, add tiny fins on the front end, angled slightly outwards, so that the aero force on the fin will pull the nose of the ejected booster outwards and away from the central core. I find that in my own gameplay, 99% of the time it's sufficient just do do #1 and/or #2 above.    The latter options also can work, but I generally only use them in odd "edge cases" (i.e. unusual ship designs) where the first two don't do the trick.

Rocket engineering is all about tradeoffs.  You can't have everything.  Essentially, what you're asking for, here, is:
high dV high TWR few stages (you don't actually say this, but implicitly you're asking for a single stage) You can't have all three.  Any time you improve one of these three things, it hurts the others.
High dV means low TWR, and/or more stages.  That's because getting a high dV means you have to use high-Isp engines (which typically have low thrust), and also means you have to absolutely minimize dead weight (which means few engines, and discarding empty fuel tanks). High TWR means low dV, and/or more stages.  That's because getting a high TWR means using high-thrust engines (usually lower Isp), and having lots of engines (lots of dead weight), both of which lower your dV.  And getting a high TWR also means shedding dead weight other than engines, which means multiple stages. Having a ship that's only a single stage means you can't ditch the dead weight of empty fuel tanks and unused engines.  This means you're hauling a lot of dead weight and will get absolutely clobbered by the rocket equation (lowering your dV) and also by Newton's second law (lowering your TWR). So. You can't have all three, which means you have to pick what's actually important to you, optimize for that, and accept that you will get that by sacrificing everything else.  For example, if what you absolutely have to have is a high-dV interplanetary tug that's fully reusable (and therefore can't shed stages)... well, that means you have to accept that you'll have an absolutely abysmal TWR.
 
The other thing we haven't mentioned here is refueling.  If you set up ISRU refining/refueling infrastructure at each of your destinations, then you make it easier to get where you need to go.  You can't mine xenon, which means in this case the best Isp you can get is LV-N.
So, let's do the math and see what your ship would have to look like, shall we?  You've said you want 10 km/s dV on your ship, and we know the Isp of an LV-N, so plug those numbers into the rocket equation.  10,000 m/s, divided by 9.8 m/s2, divided by 800 s (the Isp of an LV-N), then raise e to that power... and we get a minimum required mass ratio of 3.58.
That is, the total mass of your ship with a full load of fuel, divided by the dry mass (after it's empty of fuel), can't be any lower than 3.58.
Your ship consists of:  engine, payload, fuel tanks, fuel.  (I'm defining "payload" as "anything other than engine and fuel tanks".) It needs to be the case that (engine + payload + tanks + fuel), divided by (engine + payload + tanks), is no lower than 3.58. Abbreviating, (E+P+T+F) / (E+P+T) >= 3.58. For standard stock fuel tanks, the mass of the tank is 1/8 the mass of the fuel it contains.  So, we can say T = 0.125*F. And in this case, the engine is an LV-N, which has a mass of 3 tons. So, this gives us (3t + P + 1.125*F) / (3t + P + 0.125*F) >= 3.58 3t + P + 1.125*F >= 10.74t + 3.58*P + 0.4475*F 0.6775*F >= 7.74t + 2.58*P F >= 11.42t + 3.81*P So.  If you want to have a single-stage ship, powered by a single LV-N, that has at least 10 km/s of dV ... then the amount of fuel it has to carry will equal 11.42 tons, plus 3.81 tons of fuel for every ton of payload (where "payload" is defined as "anything other than the LV-N and fuel tanks").
Which means you're going to have a very low TWR.  For example, even if your payload is a paltry 8 tons... that means you'd need to carry 42 tons of fuel, with a total ship mass of 58 tons.  Which means, with a single LV-N, it would be able to accelerate at just barely over 1 m/s2.  And not a whit more.
And if you want more payload than 8 tons... the TWR would have to be even less.
 

Hello, and welcome to the forum! 
From the symptoms, my guess would be that the thrust vector isn't lined up with the CoM, e.g. if the engines' CoT is lower (more ventral) than the CoM.  But that's just a guess, it's pretty hard to tell without seeing the craft.  Could you post a screenshot?
(Certainly the control surfaces have nothing to do with the problem, since you're out of atmosphere and therefore they have zero effect on anything.)
Instructions for how to post a screenshot in spoiler, in case you're wondering. 
 

Wait, you're saying that you do have a Duna encounter, i.e. that when you do your ejection burn from Kerbin, it puts you on a path to hit Duna's SoI?  And that your problem is simply "after I get inside Duna's SoI, my Duna Pe is at too high an altitude and in the wrong place"?
Oh, okay.  In that case, the solution is really easy. 
Basically, don't try to fix the problem when you're inside Duna's SoI, because that's way too late-- you'll have to burn gobs of fuel to fix it.  The earlier you adjust your course, the smaller the correction you'll need.
Therefore, instead, drop a maneuver node on your trajectory when you're still in interplanetary space, for example 20 days or more before you hit Duna's SoI.  Then you can just very gently tweak the maneuver node to put your Duna path exactly where you want it, so that your Pe is at the desired altitude and latitude.  By doing the maneuver well before you get to Duna, it means you only need a teeny-tiny burn, probably only a few dozen m/s at most, maybe even under 10 m/s.  Even a 3 m/s burn has a big effect if you do it weeks before your encounter.
Note that the easy way to fine-tune it is:  after you drop the maneuver node, but before you start tweaking it, click on Duna and choose "Set Focus".  That will zoom the map to Duna and show you exactly what your path across its SoI will be.  In that view, then rotate the camera around until you can see your maneuver node sitting out there in interplanetary space, and then tweak the maneuver node handles; you'll be able to see exactly how your path will go, and get it just the way you like it.
For efficient capture, you want your Pe to be as low as possible, in order to take maximum advantage of Oberth effect.  Of course, if you're planning on using aerobraking upon arrival (an excellent idea), you'd need to come in pretty low anyway.    But even if for some reason you're not aerobraking, you'll want to get the Pe as low as possible without hitting atmosphere, for Oberth.

Hello, and welcome to the forum! 
I have no idea-- have never used that mod myself.
Normally, no, you're not supposed to have to do this.  It's supposed to just work.  If you've got a tourist contract, and you've got tourists on the ship, and you save the game, and later load the game, the tourists are supposed to still be there.  So:  either there's some problem with a mod, or else you've run into a bug in the game.
No idea-- basically, either "mod bug" or "stock game bug".  Might be interesting to take a look at the crew roster in the Astronaut Complex in KSC, and look at how those tourists are listed-- e.g. do they show up as "Killed", or "Lost", or what?  (Not that that will really answer all the questions, but it would be an interesting data point.)
In any case... if those tourists have just been suddenly and mysteriously devoured by the space kraken, that's certainly not your fault in any way, and you shouldn't be dinged for that.  If you still have the contract in your list-- i.e. if it's still waiting for completion and not showing up as "failed"-- then my suggestion would be this:  just pretend that the kerbals are still on board, complete the mission normally (so you have the satisfaction of knowing that you successfully did your part) ... and then, with a clear conscience, use the Alt+F12 cheat menu to force completion of the contract.

Moving to Gameplay Questions.
Small vessels are much more strongly affected by aerodynamic forces than larger vessels are-- the result of instability is the same whether you're big or small, but when you're small it happens a lot faster and more dramatically.
Anyway:  The easy solution is to just put fins on them (the Basic Fin works great) and make sure that your CoM is towards the front of the vessel.  As long as the CoM isn't in the back, and there are appropriately placed fins, I've always found that they fly just fine-- no stability issues at all.
Could you post some screenshots of vessels you've been having trouble with?

It basically comes down to this:
The design of each stage is going to result in a certain mass ratio, i.e. what fraction of the stage's total mass is fuel.  You don't want that to be too low (because then you're wasting lots of dead mass, and doubling the fuel would nearly double the dV)... but you also don't want it to be too high either (because then you're making your stage too big, and too much of your mass is dead weight of big empty fuel tanks).  So usually you end up with a mass ratio somewhere in the 1.5-to-2.5 region.  Given the typical Isp of KSP engines, that usually means you end up with something on the order of 1400 to 2000 m/s of dV in each stage, for "conventional" LFO engines (I'm not including the LV-N or ion engines).
So, that's a handy rule of thumb for efficiency:  each stage gives approximately 1400 to 2000 m/s of dV.  (Higher for high-Isp engines, lower for low-Isp engines.).  So... the way to answer the question "what's the best number of stages?" is to take the total dV that you need based on your mission profile, and just keep adding stages until you reach that amount.
The reason that "3 stages" is such a common design is that "1400-to-2000 m/s per stage" usually gives a well-designed three-stage rocket somewhere north of 4500 m/s of dV, which is enough to get to LKO with sufficient spare dV to go interesting places and do interesting things.  That's enough dV to get to Mun or Minmus orbit, or take a one-way trip to Duna or Eve, for example.
If you're only going to LKO, then two stages are generally enough, if designed well.  If you're doing something that's more dV-consumptive than "orbit Mun and return" or "one-way trip to Duna", then adding a 4th stage will get you nearly anywhere in the solar system.

No, it's a function of how kinetic energy works for the ship.  What you just said is not how it works.  Exhaust velocity doesn't enter into it, nor does reaction mass.  Because Oberth effect is not about the ship, it's about the orbit.
I realize that saying "yes it is" / "no it isn't" is not a good way to convince anyone on either side of the argument, so let's actually do the math, shall we?
Let's consider two cases.  In fact, let's consider the two cases I already mentioned in my original post above.  We have a ship that starts in 80 km circular orbit.  It ends in 12000 km circular orbit.
Case 1:  Two burns.  One burn to raise Ap from 80 km up to 12000 km, then a second burn at Ap to circularize. Case 2:  Three burns.  One burn to raise Ap from 80 km up to (for example) 1000 km, then a second burn at the 1000 km Ap that raises the next apsis to 12000 km, then a third burn that circularizes at 12000 km. Both cases start in circular 80 km and end in circular 12000 km, the only difference being that Case 1 does more of its burn at a lower altitude.  We would expect Case 2 to require more total burn than Case 1, since it's losing Oberth benefit, right?
Okay, let's do the actual math to figure it out.
Math in spoiler section.  But no peeking yet!
Result:  Case 2 requires 311 m/s more dV than Case 1 does.  That's the answer right there.  The amount of dV you've wasted due to losing Oberth benefit is 311 m/s.  I'm reasonably confident that that answer's correct, assuming I didn't hit a wrong key on my calculator somewhere.  If you doubt my number, you can set it up in KSP yourself to check; just put a ship in 80 km circular orbit and drop some maneuver nodes.
Okay, now comes the time to peek inside the spoiler there.  Notice that the only numbers I needed to plug in were orbital parameters.  Kerbin's standard gravitational parameter, and orbital radii.  That's it.  Those were the only numbers I needed.  You won't see a single mention of ship mass, or fuel mass, or Isp, or exhaust velocity, or anything at all about the physical characteristics of the ship.  Because they don't matter to Oberth effect.
That's that the actual math looks like.  So, if I'm wrong... care to show me what your math looks like?  Provide some equations involving exhaust velocity and such to come out with a correct answer? 
Might be nice to have a second opinion from perhaps the most respected physics nerd in the forums.  @OhioBob, care to weigh in?
 
Some other useful discussions, also involving people with physics background providing actual math to show that this is how it works:
Anyway, Geschosskopf, would love to see some math from you supporting your contention.  Take the orbital situation described (Case 1 versus Case 2), and use your numbers for exhaust velocity or whatever-else-about-the-ship to come up with a meters-per-second answer for how much dV is saved in one case versus the other.  Show us the numbers, please?
 

Hello, and welcome to the forums! 
(Moving your gameplay question to Gameplay Questions.)
A couple of things: 
First, "give or take five degrees" is actually quite a bit-- I don't know exactly how much "slop" it allows, but I'd guess it's likely a lot smaller than 5 degrees.
Second, when it says "180 degrees" ... please be aware that means orbiting retrograde, i.e. from east to west.  Are you orbiting in the correct direction?

Hello, and welcome to the forums! 
Here's your screenshot:

Note:  it's easy to get pictures to show up right in your post.  Instead of pasting the link to the page where you put your screenshot... paste the link to the image itself.  (You can get this by right-clicking on the image and selecting "Copy Image Location".)  Doing that and pasting the image link will cause it to get automagically included as an in-line image, as shown here.
Anyway, on to your actual question:
If two ships are in the exact same orbit but different locations along it, they'll just stay that way forever (same relative positions).  So, to make one of them get over to where the other one is, you need to make them have different orbital times, i.e. so that one of them takes more time than the other to complete an orbit.  Then the faster one will gradually "catch up" to the slower one.
So, in this case, the green ship is a bit "ahead" of the blue ship, so you'd want to either slow the green ship down, or speed the blue ship up.
You can slow down the green ship by burning a bit to raise its Ap some.  Alternatively, you can speed up the blue ship by burning to lower its Pe.  However, you'll be limited in terms of how much you can do that, since you don't want to lower its Pe below 70 km (since then you'd be hitting atmosphere).

It doesn't have to be in the front, per se.  Just don't put it way, way in the back, the way you did.
Think of it this way:
Picture your CoM as being the center of your ship.  More than that:  think of it as the pivot point, as if there were an axle running through it that your ship can spin around. There's a part of the ship that sticks out in front of the CoM, and a part that sticks out behind the CoM.  I'll call these the "fore end" and "aft end". Drag on the fore end of your ship (call it "fore drag") wants to flip your rocket arond and make it fly backwards. Drag on the aft end of your ship (call it "aft drag") wants to keep your rocket flying with the pointy end forward, the way you want it. Therefore it's your job to make sure that the aft drag's torque is bigger than the fore drag's torque. You make either end (fore or aft) have a bigger drag effect in two ways: Make it physically bigger and more "aerodynamically active". Make it longer so that its drag happens farther away from the CoM, because that gives it a bigger lever arm to work with. Ideally, yes, your CoM would be located in the front of the ship.  But it doesn't have to be.  It can be slightly behind the middle of the ship... as long as you have some nice robust fins that are located far far behind the CoM to compensate.
Your problem is that you've got the CoM way in the back of the ship.  This means you have a humongous draggy "front end" that comprises most of the ship, and very very little "aft end" to compensate.  And your fins aren't doing squat, because they're so close to the CoM that they have almost no lever arm to work with and therefore don't help you.
So.  You don't have to have the CoM in the front of the ship, it just has to be in front of the center of pressure.  (Sort of like the old joke about the two hikers who are surprised when a grizzly bear suddenly bursts out of the bushes and charges them.  One of them starts running.  The other says, "What are you doing?  You can't outrun a bear!"  The runner replies:  "I don't have to outrun the bear... I just have to outrun you.")
So... you do what you can to move the CoM as far forward as you can.  The way you do that is with all sorts of little incremental improvements, such as have been suggested on this thread.   It all boils down to:  Move the CoM as far forward as you can, and then put fins on it as far behind the CoM as possible.
What you've shown there has a low CoM.  But it's not a complete spacecraft.  What you just designed there is not an SSTO.  There is no way that thing will have enough dV to get to orbit.
What you've just shown isn't a "general satellite rocket", it's a "general satellite upper stage".  In a real launch, that craft wouldn't launch off the pad just as you've shown it; it would be sitting on top of some lower stages.  And that makes a world of difference.
Why?  Because those lower stages can be designed in a way that the CoM of the overall craft is as far forward as possible, and also so that the craft has fins far behind the CoM that can save the day.
So, here's my attempt to recreate your example craft.  Looks like you're using a non-stock antenna, so I've used the RA-100 as a stand-in.  Looks like the overall situation is about the same.

I'll set aside for the moment the fact that the payload on the front end is a horrible, terrible, no good, very bad design from the standpoint of aerodynamics.  Big antenna: ouch.  Stack size that goes abruptly from >2.5m to 0.625m to 1.25m to 0.625m to 1.25m again?  Ouchity ouch owie ouch.  That's the poster child for a problem payload, horribly draggy, and normally we'd solve it by putting a fairing around that whole thing.  But just to prove a point (i.e. that this is launchable, even as it is), I'll leave it alone. 
 
Okay, so here it is perched on top of a launch vehicle, i.e. something that can actually get to orbit:

You'll note that the CoM is, indeed, down towards the bottom of the rocket, which ain't great.  But... note that I've placed the SRBs so that they stick down as low as possible below the CoM.  In particular:  Look how far below the CoM all those SRB fins are.  Pretty far down, no?  This gives them a nice lever arm to work with, so they can compensate for that huge draggy nose sticking out way in front.
I've set up the staging so that it lifts on all four SRBs plus the Swivel on the bottom.  The east and west SRBs are running with thrust limiters of 70%.  The north and south SRBs are at 100%.  It lifts on all five, then ditches each pair of SRBs as they burn out.
Result:  It flies just fine.  Rock-solid steady.  Just start a gravity turn and follow all the way to orbit.
So, why is it stable?
It's designed to move the CoM forward, rapidly, as it burns.  Those SRBs get lighter fast.  And the central engine drains that bottom tank first.  So as soon as it has burned off a reasonable amount of fuel, that CoM moves way forward. This means that it's most unstable right at launch, before it has burned off the fuel, so the CoM is the farthest aft.  However... that's when instability doesn't matter much, because 1. it's going nearly vertical for that first little bit off the pad, and 2. it's going fairly slowly at first, meaning aero forces aren't quite so huge. As you can see, I've spammed steerable fins as far aft as possible. I also have the Swivel firing right off the pad.  Since it has gimbal, that also helps with stability, especially in the early bit of the flight before it's built up much speed so that aero effects aren't as strong. That upper stage-- the one that includes the FL-T800 tank, copied from your screenshot-- is still horribly aerodynamically unstable, by itself.  But that's irrelevant.  Why?  Because it's not by itself, it's on top of a bigger launch vehicle.  And by the time that the lower part is staged away and it is all by itself... well, by that time it doesn't matter that it's aerodynamically unstable, because it's way high up in the sky where the atmosphere is nearly a vacuum and aero forces become negligible.
Anyway:  I launched the craft above and easily flew it to orbit.  Never needed to use the Ant-- the entire upper stage (with FL-T800 tank and Swivel) made it to orbit, with quite a lot of fuel left over.
If I were to tweak the design so that the really-horribly-draggy front end were encased in a fairing, that would probably help it considerably.  But it got to orbit even without a fairing.  You can put pretty much anything in orbit, if you brute-force it enough.