Geschosskopf

Howdy and welcome to the forum.
In my signature is a link to an old-but-still-valid introduction to KSP's comm system.  That will explain all reasons why you don't need to get overly complicated with your network but @Pecan has pretty well summarized it already :).
If you're sending a lone scientist, then I'm assuming you'll be returning the bulk of the data instead of transmitting, so you're primary concern is having a link so the probe core on the ship can handle SAS for the burns along the way.  Is that about right?  If so, then the 1st thing to understand is that you only need a link at all when you'll be doing those burns.  You can always wait a little while to transmit science until you get a link.
The best way to get this is to put a pair of the biggest relays you've got in highly eccentric polar orbits at both Kerbin and Duna, one going up and the other down.  This will always give you a link as far as the Duna system (unless the sun is between Kerbin and Duna) , over or under every planet/moon that could get in the way.  And this will also cover the bulk of the Duna system as well, plus all the interplanetary space in between.  The only blind spot would then be the back side of Ike near the equator when that's facing away from a direct line to Kerbin.  To fill this gap, put 1 (or 2 at most) small relays in medium-altitude equatorial orbits at Ike.  Then the link can come from one of Duna's polar relays to an Ike equatorial relay, and thence to the ship.
There is no such thing as a network that provides 100% coverage 100% of the time.  But with a fairly simple set-up like this, you can provide coverage everywhere and usually right when you need it.  You might have to wait a short time on the back side of Ike once in a while for the equatorial satellite to come over the local horizon, but this won't be very long and is easy enough to plan your burns (and any transmissions) around.
As mentioned, no matter how you set up your system, the sun will always come between Kerbin and whatever planet you're at somewhere along the way.  So when planning your flight, try to get to Duna before this happens, so you can grab your science and be ready to leave.  By the time the return transfer window comes around, you should have a clear shot home.
To avoid this worry, it's a good idea to put polar relays at every planet except Moho.  That way, you can almost always have a link around the sun.  This is especially important when you go to Jool because the size of that system means it takes months to explore, so the sun WILL definitely block the line from Kerbin at some point.  So any time you go to a planet for the 1st time, be sure to include a pair of polar relays in the plan.  Equatorial relays can wait until you actually want to land there.
 
 

Do you use the same settings for airplane and rover wheels?  
As I think I understand what folks with more knowledge of the system have said, the "damping" really isn't a shock absorber.  Nobody really knows what it is.  In my experience, it seems to be just another spring, pointed in the opposite direction of the real spring, but is stiffer (has a lower oscillation frequency and smaller magnitude for the same force applied).  So having more damper than spring reduces bounciness by putting more "stiffness" in the suspension.  However, both also affect ride height.  The less spring you have, the lower the vehicle sits under its own weight, so the less total suspension travel you have.  If you reduce spring to zero, the suspension will be bottomed out by default, which is generally a bad thing.  Thus, I find max damper and 0.50 spring gives a stiff suspension with still some travel for bumps and terrain irregularities.
As to friction, this seems to work both laterally (parallel) and vertically (perpendicular) to the ground surface.  Thus, a rotating wheel must fight its own friction to turn because it has to pull the tread up off the ground.  This reduces speed and increase power consumption, so is not generally a good thing for rovers.  The best way to climb hills with rovers is to turn off traction control, which basically kills power to the wheels when going uphill.  But for lander legs, high friction is a good thing.

Sepratrons!  This is the sort of problem they're intended to solve.  Aim them to pull the thing away and slightly off to the side so you don't land on it.  And only stage it off once you're already slow, well after the fires go out.
Alternatively, attach a TAC Self-Destruct to it set on the same stage as the heat shield's decoupler.  Then the heatshield will explode when staged and won't be a problem.  Plus you get fireworks!

It depends on the asteroid and what your ultimate goal for it is.  First off, there's the question of how much time you have before it enters Kerbin's SOI and what effect that encounter will have on the asteroid's subsequent trajectory.  These are constraints on your strategy.  If you don't have a lot of time to complete the contract, then you might have to finish the job during this pass.  OTOH, if you've got years and the Kerbin encounter won't put the asteroid into an inconvenient orbit, then you can work it into the desired position in solar orbit over several years.  Then there's the question of mass.  As and Bs aren't THAT expensive to wrangle inside Kerbin's SOI but Ds and Es seem cheaper to maneuver in solar orbit.  Cs are can go either way depending on your tech and how much you want to spend on them.
But the amount of maneuvering you need to do is a function of where you want or need the asteroid to end up.  If the contract is just to put it in ANY orbit, and you never plan on doing anything else with it once you've got it, then all you need to do is capture.  You don't need to change it's inclination or Ap/Pe afterwards.  If that's the case, then you can wait until they enter Kerbin's SOI.  But if you need to put them in a specific orbit, it's best to get them in solar orbit so you can make them enter Kerbin's SOI as close to the desired orbit as possible.
If you'll be catching it in Kerbin's SOI, the inclination change required for interception isn't that expensive.  Just launch with that inclination and go into a wide parking orbit.  Then just rendezvous with it once it's in Kerbin's SOI.  The best case for this is an asteroid whose closest approach to Kerbin is farther out than Mun.  Close to Minmus is even better.  This gives you plenty of time to rendezvous before the asteroid reaches is Pe, which is where you want to burn to capture it.
 
The dV required to reach a NKO asteroid in solar orbit is roughly the same as required to go to Duna or Eve, PLUS perhaps a fairly significant plane change.  And once you get there, you have another significant burn to match velocities with it, with no help from gravity, aerobraking, or Oberth.  And that's just getting there.  Then moving it requires a hefty chunk of dV as well (and the more massive it is, the more fuel this requires), and then you still have to capture it once you get to Kerbin.
For grabs in Kerbin's SOI, the dV to meet the asteroid isn't quite so much.  You get the necessary inclination from launch, then getting to your waiting orbit is about like going to and capturing at Minmus.  From there, it's not so much to get an interception, but you still have a fairly large burn to match velocities, and then of course the capture burn.  So it's still in the region of a Duna mission.
Speaking of fuel, you'll also need gobs of RCS.  As, Bs, and even Cs can be reoriented for burns by brute force, with sufficient RCS and torque.  With Ds and especially Es, however, it's often better to move your ship to the appropriate side of the asteroid instead of trying to rotate it.  Either way, you'll still use lots of RCS.
As far as physically making the rendezvous, the interface isn't too friendly when it comes to doing it in solar orbit.  I find that I have to make several correction burns along the way.  Get a closest approach within a couple hundred km, warp ahead a little, refine the closest approach to a few dozen km, repeat, until you get it down to 1km or less.  In Kerbin's SOI, however, the interface is no more difficult than when rendezvousing with a space station.
 
For capturing a small roid in Kerbin's SOI, it's a few weeks to a month, about like a MInmus mission.  For grabbing a big rock in solar orbit and capturing it into any old orbit once you get to Kerbin, it's usually several months, like a trip to Eve.  For grabbing a big rock in solar orbit, matching planes with Kerbin so you come in at Kerbin's equator, and then fine-tuning your Kerbin Pe to capture into a low orbit, you're usually talking at least 1 year, usually 2.  This is because first you have to ride to the asteroid's AN or DN with Kerbin, do the plane change, then ride to a good spot to burn to set up your pass by Kerbin.
 
It's much more brute force if you do everything in Kerbin's SOI, but that should only be for small roids which don't weigh much more than a heavy capsule and attachments, so brute-forcing them isn't a real issue.  For big ones, waiting for one that's nearly in the same plane as Kerbin to start with is VERY important:  it saves you gobs of dV both going there and then getting it exactly in Kerbin's plane.  The less dV you need, the better, because with the big ones, it takes LOTS of fuel to produce a given amount of dV.
This brings up the question of power plant.  You can capture a small rock into any old orbit in Kerbin's SOI with a non-extravagant LFO ship.  You can do the same for a C with a slightly extravagant LFO ship or a non-extravagant LV-N ship.  But beyond that, you start getting extravagant with nukes, or have to use ions and accept REALLY LONG burns.  To put a big rock in a low equatorial Kerbin orbit might actually require 2 or 3 ships for different parts of the job.  Maybe an ion ship to go meet it in solar orbit, match its plane to Kerbin, and get its Kerbin Pe out near Minmus.  Then a nuke ship meets it before Pe to do the capture capture.  Then a monstrous LFO ship with high thrust (and possibly mining to refuel itself from the rock)) brings the Ap and Pe down.

Well, mining asteroids in Kerbin's SOI has the same drawbacks as mining Minmus:   The effort involved is not worth the money saved on fuel.  But if you the goal of your game is to build out the Kerbin system (and nowhere else) with bases, stations, and whatnot, then adding an asteroid to the mix spices things up a bit.  Otherwise, unless you have a contract to get science from or capture a Class C asteroid, with no fine print that makes the project impractical, and which pays substantially more than you'll spend on doing it, then it's probably best to ignore it.  5500km Pe is no threat at all to Kerbin, and AFAIK asteroids aren't a threat even on an impact course.

There is 1 main and 1 secondary reason for this happening.  Both of which are game issues.
Main Reason:  Floating Point Errors.  Every time you load/save/reload the game, or go look at another ship, the positions of all ships in flight get shifted slightly due to rounding errors with floating point numbers.  This essentially means that it is impossible to have a constellation of satellites with stable spacing over the long term.  Which is why you should never try to make a kerbostationary constellation.  Which means you should NEVER disable the extra ground stations.  If those are turned on, there's no need for a kerbostationary network.
Secondary Reason:  KSP utterly lacks the necessary instrumentation for spaceflight.  That's because it's not a simulator, it's a game, intended to by played by eyeball and luck, for larfs.  The ONLY important variable to maintain even mid-term stability (as in a few months to a year or 2) for a kerbostatinary constellation is the satellites' orbital period.  You want this to be the same for all satellites.  Inclination can be off a bit, Pe and Ap can be off slightly---those don't matter for maintaining spacing.  If those are a bit off, the satellites will librate around their assigned spot in the sky just like Ike librates around the same place in Duna's sky.  Close enough for government work.  But orbital period is the be-all and end-all because THAT's what determines the stability of spacing.  However, there's no stock feature that shows you the orbital period in fine enough resolution to be useful.  You need all the satellites to be within 1 second of the same orbital period, which is only possible if you use a mod that displays your orbital period down to the second, and your satellites have RCS pointing forwards or back with the thrust turned way down, so you can very gently tweak your orbital period to match those of the other satellites.
Do this and it will last a while, but not for years due to the floating point errors of the Main Reason.  Which basically means, constructing a kerbostationary network is a fool's errand.  Which means, you should never turn off the extra ground stations because that's what makes having a kerbostationary constellation necessary.

The higher the altitude of relay satellites in the ring around Kerbin, the fewer of them you need.  At geostationary altitude, you only need 3.  Lower down, you might need 4, 5, or even 6.  So it's generally cheaper to build fewer satellites because it only takes about 650m/s to reach geostationary altitude anyway.
HOWEVER, the ONLY reason to but a ring of relays around Kerbin is if you disable the extra ground stations.  Without the extra ground stations, your distant ships have to link back to KSC itself.  Because KSC will be facing away from the distant ship about 50% of the time, you then need to recreate the extra ground stations in space with the ring of relays.  Then the distant ship links to a relay on the back side of Kerbin, which links to 1 or more other relays in the ring, until one of these can link to KSC.  With the extra ground stations turned on, the distant ship links to one of these stations directly on the far side of Kerbin, and all the ground stations have landline connections to KSC.  IOW, both the extra ground stations and the ring of relays do the same thing---they let your distant ship link to KSC regardless of which way KSC is facing.  You need one or the other, but you don't need both.
In general, I recommend leaving the extra ground stations turned on.  The problem with any sort of relay ring is that stock KSC doesn't give you enough data about your orbit to put something in a stable geostationary orbit, or any other finely synchronized orbit at another altitude.  And even if you use a mod that gives you that data, the orbit won't stay where you want it due to floating point errors and a general lack of fine control over maneuvering.  So over time, your satellites will drift until eventually your neat formation of relays gets out of whack and you get gaps in the coverage.  So I find it a lot less of a bother to skip the whole thing.

Well, there are a few things in general you should be sure of:
1.  When you make the probe subassembly, be sure its root part is the docking port you plan to use to attach it to the SSTO.  So either start building the probe subassembly with that part or use the re-root too.  This is because when you go to put a subassembly into another ship, the subassembly's only attachment node will be on the exposed end of its root part.
2.  When building the SSTO, attach the cargo back to the fuselage, then the docking port in it.  Hold down ALT when positioning the docking port in the cargo bay, to be sure it will attach to the interior node in the cargo bay instead of the node of the stack part ahead of or behind the cargo bay.
3.  When placing the subassembly in the cargo bay, be sure to hold ALT so it will connect to the node of the docking port inside the bay.

Here are what I use in the stock system....
Most bodies have an L and an H value depending on sensors.  Once you get in position, open the Big Map to see if your little orbit hash marks along the equator are staggered above and below, either individually or in groups.  If instead the blue and orange hash marks line up with each other, turn prograde or retrograde and burn just a little (using RSC for this is best) until the hash marks are staggered.
L = Low level
Ore scanner (if you have disabled insta-scan) Multi-spectral/biome Lo-res radar H = High Level
hi-res radar Moho, Eve, Kerbin, Mun, Minmus, Ike, Dres, Laythe, Vall, Tylo, and Eeloo.  All these are within experimental error of the same altitudes.  Just get within these ranges and then adjust the hash marks with RCS as noted above.
L:  250-265km @ 86^ H:  760-780km @ 88^   Gilly, Bop, and Pol:  SOI is so small and orbital velocity so low that it has only 1 altitude.
L/H:  100km @ 85^ Duna:  Slightly different than the main bunch of terrestrial worlds
L:  380km @ 85^ H:  765km @ 88^  
 

I wrote a tutorial for making simple systems that are modular and easy to expand as needed. The link is in my sig.
The nutshell version is:
It's always the distant ship talking to KSC.  Any intervening relays are best thought of as mere telephone poles.  The distant ship needs a direct antenna to send and receive messages.  All relay antennae do is pass the message along, but cannot initiate messages. Enable the extra ground stations.  If you don't, you'll have to duplicate them in orbit with a constellation of relays.  Both options make it so you're effectively able to talk to Kerbin as a whole, so don't have to worry about KSC facing the wrong way due to Kerbin's day/night cycle. Put 2 of the biggest relay antenna in highly eccentric polar orbits, one going up and the other down, at Kerbin and the central body of every other planet you care about.  These relays will spend the vast majority of their time high above or far below the ecliptic plane, so will be able to talk over or under all intervening celestial bodies EXCEPT the sun.  You have to talk around the sun.  So if you're going to Duna, it's a good idea to put a pair of big relays not only at Kerbin and Duna, but also at Eve, because at some point during a Duna mission, the sun will be between Duna and Kerbin for a while, so you can go around it via Eve most of the time.  And vice versa if going to Eve, put some relays at Duna. Put 1 or 2 short-range relay in orbit around any moon you want to visit.  These will let you talk from the far side of the moon relative to Kerbin without having to wait until you face Kerbin again (which never happens on the dark side of Mun anyway). Put direct antenna on your ships that are big enough to talk to the closest relay antenna. So say you're on the far side of Ike relative to Kerbin.  Then things would work like this:
The direct antenna on the ship links to the short-range relay orbiting Ike. The Ike relay links to one of the long-range relays in polar orbit at Duna.  If no other celestial bodies are in the way, the polar Duna relay links to Kerbin's surface and that's it. If the sun is between Duna and Kerbin, the Duna polar relay links to one of the Eve polar relays, which then links to Kerbin's surface. If Mun is in the way, then either the Duna or Eve (if necessary) polar relay links to one of the Kerbin polar relays, which then links to Kerbin's surface. As you get further from home, just add the same set of 2 big polar relays and 1 or more small moon relays to each planet.

IIRC, both the mods you mention use the Community Resources Pack (as do many other mods).  Installing any of those mods installs CRP, which adds those resources to the game and also makes it so the ore scanners can see them.

@bewing had some important points to remember.  I'll give you a few more.
To be able to communicate, you need 1 or more links between your ship and Kerbin (Kerbin now has antennae all over it so you don't need to talk just to KSC unless you disable the other ground antennae).  Being able to do this depends mostly on 3 things:  the range (all antennae have a max range which increases as you upgrade the Tracking Station), the type of antenna(e) involved (direct and/or relay). and whether some celestial body is in the way (but you can work around that for the most part).  As to range, the more excess range the antennae have compared to how far you're talking, the better the connection (more bars) so the less time (and thus, EC) it takes to transmit data.
As to antenna type, there are 2 general types:  direct and relay.  Direct antennae include all the original stock antennae, the new stock dipole, and all the ground-based antennae on Kerbin (KSC and all the new ones).  Direct antenna on ships can talk to Kerbin and relay antennae on other ships, but NOT to direct antennae on other ships.  Relay antennae are all new and can talk to anything:  direct antennae on other ships, relay antennae on other ships, and Kerbin.  Thus, the only way to have ship-to-ship communications is if at least one of the ships has a relay antenna.
The ground-based antennae on Kerbin are the most powerful you have at any level of Tracking Station upgrade.  At Level 3, they can talk to ships at Jool, provided the ship has a big direct antenna like the 88-88.  But they're direct antennae, so the signal can be blocked by celestial bodies.  Thus, the main reason you need relays is to provide bank shots around intervening bodies.  You can turn blocking off in the options and thus will never need relays, but what's the fun in that?  So assuming you haven't done that, you need to consider the sources of blocking.
The planet your at.  This happens all the time due to the planet's rotation (if you're on the ground) or your orbit around it.  This is the hardest to completely eliminate but you can reduce it to an acceptable minimum with a few relays. Intervening planets between the planet you're at and Kerbin.  This is very easy to eliminate completely. The sun.  This always happens at some point during interplanetary missions and can only be solved by relays at other planets, to make a path around the sun. So, let's say you have a lander on Duna and want to be able to talk to KSC most of the time.  For game purposes, you only need a connection when you're trying to transmit science or fly a ship without a pilot aboard, which really isn't all that often compared to the total mission time.  But for role-playing purposes, you might want the ABILITY to communicate as often as possible, at least every few hours throughout the mission.  This will require a network kinda like this:
Your lander on Duna has a mid-range direct antenna.  This talks to... A short-range relay antenna in low-medium Duna equatorial orbit.  This is so the lander can talk home when Duna is facing away from Kerbin.  The link will only exist when the satellite is above the lander, so will only provide coverage for about 1/2 of Duna's day.  If you want more than that, you need multiple satellites like this spaced out around Duna's equator.  Anyway, this talks to.... A long-range relay antenna in a highly eccentric polar orbit at Duna.  This is to be able to see above or below Ike towards Kerbin.  This talks to.... A long-range relay antenna in a highly eccentric polar orbit at Eve or Dres.  This is to talk around the sun when it's between Duna and Kerbin.  This talks to.... A long-range relay antenna in a highly eccentric polar orbit at Kerbin.  This is to be able to talk under/over Mun.  This talks to... Ground antennae on Kerbin.

As @Palaceviking says, you've got a clipping issue.  It's possible to work around this, but usually at the expense of being able to re-dock the rover.  All in all, the clipping issue makes using the rear cargo ramp problematic.
If you're committed to using the rear cargo ramp, then you have to slide the docking port up the front bulkhead of the cargo bay enough that the rover's wheels are slightly above the cargo bay floor.  Thus, when you undock the rover, it will fall a short distance to the floor.  Also remember that because the rover is hanging from 1 end on a flexible joint, it will sag somewhat when physics loads.  So either you have to raise the docking port a bit more, or run struts from the rover to the cargo bay walls to hold it up.  These struts will break when you undock the rover so no problem there.  The problem is, you won't be able to dock the rover back into the cargo bay.  Either the docking port will be too high to reach, or you won't be able to reattach the necessary struts unless you use KAS/KIS.
It would be nice if you could put a docking port on the cargo bay floor.  However, this doesn't seem to work for a variety of reasons.  Thus, the only stock alternative that avoids the clipping issue is to use a "bomb bay" cargo bay instead of the tail ramp, and drop the rover out the bottom.  Then the rover will never clip the cargo bay.  But of course, in stock, you'll never be able to reattach it, and you have other design issues such as sufficient airplane ground clearance for the rover to drive out from under it, but that makes the rover have to drop further, which can damage it.
All in all, if you want to use the rear cargo ramp and get the rover back in the plane,  you pretty much have to use KAS/KIS.  Then you can redock the rover with a winch and have Kerbals attach struts to hold it in place.

AFAIK, a ship will always use the 1st antenna you put on it back in the VAB/SPH, and right-clicking on the antenna and selecting "transmit data" transmits stuff you want to keep without giving you a choice in the matter.  Therefore, your options are quite limited, but it can be done.  The options are:
#1.  Using KAS/KIS, have an EVA Kerbal remove all the lesser antennae and leave only 88-88s attached.  This IMHO is the preferred 
#2.  Move all the data you want to keep form their experimental parts into a detachable crew pod.  Then undock that pod, switch back to the main ship, right-click on the 88-88, and "transmit data".  But this only works if you haven't comingled experiments you want to transmit with experiments you want to keep in the same pod, because an EVA Kerbal takes everything stored in the pod.
#3.  Edit the ship in the save file so that the 88-88 is the 1st antenna listed in its parts.  However, editing the save file is not recommended, so be sure to save a backup beforehand.

As @Zhetaan says, for any rover intended for use out in the field where it has to climb hills, set Traction Control to zero.  If you try to climb a hill with Traction Control > 0, you'll never make it.  Traction Control is useful only if you're trying to do laps around and between the KSC buildings at high speed.
Now, that will certainly help you, but it's not the full story for Minmus.  Minmus has like no gravity, and wheels rely on gravity to work because gravity creates the necessary friction between the wheels and the ground.  Without this friction, you can';t accelerate, turn, or stop very well using the wheels.  So, you have to design and tweak the rover to get a good grip on Minmus.  You have 2 main things you can do here:  provide downforce and tweak the wheels.  Or a combination of both.  Both at the bottom line increase the friction between Minmus and wheels, so the wheels work better.  We'll discuss tweaking wheels first.
Wheels have 4 tweaks you can play with:  Traction Control (already discussed---set to zero as a general rule), Friction, Spring, and Damper.  The last 3 are actually useful but they default to working in Kerbin's gravity, so if the gravity is significantly different, you need to make some changes.  Friction is the 1st thing to look at.  To change it, you usually have to click a button that says "Override Friction" or some such before the slider even appears.  If the gravity is lower than Kerbin's, increase the Friction slider.  If it's higher, decrease it.  The default (for Kerbin) is 1 and often you can increase this up to 5 (depends on the wheel it seems).  I've found that 2 is great for Mun and 3-4 works fairly well for Minmus.  Use the highest setting for the things with even less gravity than Minmus.
Spring and Damper (shock absorbers) are 2 halves of the same whole (the suspension) so should generally have the same value.  If you change one, you should usually change the other to match.  If you increase Spring without increasing Damper, you rover will bounce high and frequently under any gravity.  If you increase Damper without increasing Spring, you make the suspension more stiff, which can result in breakage, explosions, tumbles, and such.  Anyway, both create internal forces between the wheels and the vehicle proper, and these default to be scaled to Kerbin's gravity.  So if you do anything to these settings, generally you tone them down a bit for gravity < Kerbin, and up for gravity  > Kerbin.  HOWEVER, unless you're trying to go as fast as possible, expect to jump moguls, etc (Elcano?). you don't really have to mess with either of these very often.
So that's wheel tweaks.  As an alternative and/or along with, you can create downforce.  This normally isn't necessary on atmospheric worlds because they've got enough gravity to give you enough friction anyway, so no need for spoilers unless you're trying to set the land speed record on the KSC runway.  Downforce is for the low-gravity, airless moons.  What you do here is mount an ion engine on top (usually over the CoM) to thrust the rover down onto the surface.  An ion engine usually provides sufficient thrust and the fuel lasts forever, but then you have to provide the electricity, which might be a problem at night.  If you have downforce from an engine, then all bets are off for the proper wheel tweaks for a given amount of gravity.  You'll have to figure that out for yourself.
 
I'm hardly an expert but thanks anyway
 
Unless things have changed recently, you can tweak all wheel settings in flight.  This includes enabling/disabling/reversing sterring, enabling/disabling mortors, and all tlhe Traction Control Friction, Spring, and Damper settings.
 
 
 

Well, to start with, I've never gotten the whole "merge" thing to work right so I use regular subassemblies instead.  The whole process would go like this:
1.  Build the Pegasus by Itself
Design and build this in the SPH as if it's the only thing you're going to build.  This will eventually become a subassembly.
2.  Attach a Hardpoint to the Pegasus
Put this on top of the CoL of the Pegasus so the aerodynamic loads of the Pegasus don't try to twist it off.  The hardpoint will separate between itself and the Pegasus leaving no residue on the Pegasus.  It blocks crossfeed so the Pegasus will have full tanks when dropped, and it has an ejection force to toss the Pegasus clear.
3.  Create the Pegasus Subassembly
Attach any other part (such as a small box girder) to the top of the hardpoint opposite the Pegasus.  This extra part is just to facilitate making the subassembly so it doesn't matter what it is.  Now use the re-root tool to make this extra part the root of the Pegasus.  Open the subassembly creation page in the editor.  Now grab the hardpoint and pull it and the whole Pegasus below it off the extra part.  Drag this assembly over to the subassembly creation box and save it.  The Pegasus subassembly is now complete.
4.  Build the Carrier Plane
Start a new ship and build the carrier plane (or open a pre-existing plane).  
5.  Attach Pegasus to Carrier Plane
Open the subassembly tab, select the Pegasus subassembly, and attach it under the wing of the carrier plane.  The subassembly will be able to attach to the carrier plane only by the top end of the hardpoint (thanks to the re-rooting done above).  Attach the subassembly under the wing.  This will add the hardpoint's decoupler and the Pegasus' engine to the staging menu of the carrier.  Move these as needed so they don't conflict with the engines of the carrier plane.  I would recommend putting the hardpoint and the Pegasus engine together in the same stage, separate from and above the stage with the carrier engines.
6.  Save the Combined Carrier/Pegasus
Don't do any merging.  Just save the whole thing as you normally would.
7.  Conducting the Mission
Launch the combined thing.  When you get to the speed and altitude you want, hit SPACE to stage the Pegasus and fire its engine.  The Pegasus should detach cleanly and go flying off.  Quickly use [ or ] to switch to the Pegasus so you can control it.

Hmmm.  Is this a career game contract or one of the tutorials?  The term "mission" is a bit ambiguous.
Anyway, assuming this is a contract.......
When you say "months ago", was that in 1.0.5?  Are you playing in 1.1.2 now?  I've head that sometimes contracts in progress don't survive the game update.
But anyway, contracts in general sometimes fail to complete for no apparent reason.  It's always been that way, and happens to all types of contracts.  Worst case, you can open the ALT-F12 menu, go to the contracts tab, and mark this contract as complete.  It's not cheating if you actually did the work but the game is bugged
 

Well, they cost the same, they're available at the same time, the make the same power, and they fold up into the same sized package.  Thus, the only difference between them is their shape.  Shape can, of course, be chosen for purely aesthetic reasons but it also has a minor functional aspect.
The main advantage of the 1x6 over the 2x3 is that more if its area is further out from the ship.  Thus, if you put them in the same place on the same ship and have the ship at the same orientation to the sun, more of the 1x6 will be out of the ship's shadow so it will produce more juice.  So the 1x6 is usually the better choice for spacecraft where the sunlight can come from any angle and thus ship shadows are frequent.
However, for stuff on the ground, the possible angles the sunlight comes from are much more limited.  This means you can control them or design for them, and a 2x3 will usually work.  Besides, for bases and rovers, the more compact shape is less prone to getting broken.

The SENTINEL is for finding asteroids that the Tracking Station cannot see itself.  These asteroids are usually in rather inclined orbits, perhaps elliptical as well.  Its primary job is to detect such asteroids that threaten Kerbin but it can also be used to find asteroids near other planets.  To do this, you must put the SENTINEL in a solar orbit slightly inside the orbit of the planet you want it to cover.  IOW, to cover Kerbin, you need to put it in an orbit between Kerbin and Eve.  To cover Dres, you need it between Dres and Duna.
Because most of the asteroids found by the SENTINEL are in rather inclined orbits, they are a lot more difficult to capture in interplanetary space than the normal asteroids you find with the Tracking Station.  Therefore, there's little point in launching a SENTINEL for your own purposes.  HOWEVER, there are many VERY lucrative contracts that ask you to launch a SENTINEL to watch for asteroids around a particular planet, starting with Kerbin and eventually asking for other planets.  And these contracts repeat and you can use pre-existing SENTINELs to do them without having to launch new ones.  This makes for a very nice late-game income stream.  I fund my late-game space empires with multiple SENTINELs at various planets all doing repeat business.  Millions roll in with no effort at all on my part.
The contracts always show a target orbit, which you can only see in the Tracking Center by focusing the view on the sun, or in the game only after a ship leaves Kerbin's SOI.  However, there are huge tolerances on these target orbits and you don't have to really get in them.  Thus, there's no need to adjust orbits of existing SENTINELs to fulfill new contracts for that same planet.
Anyway, once you put a SENTINEL in the "right" place (meaning pretty much any solar orbit between the planet it's watching and the next planet in), tell it to start looking for asteroids and leave it to it.  It will find the asteroids automatically and you'll see brief messages in white text appear in the upper left area of the screen saying the SENTINEL has found the Xth of Y total asteroids needed to fulfill the contract.  This is why they're such money-makers.  One in place and turned on, all you have to do is check for new contracts periodically and watch the money roll in.

Hmm, I've never tried putting multiple SENTINELS on the same vessel.  But my gut feeling is that this would have no effect on the rate of asteroid detection.  I think that's handled by ship, not detector.  Could be wrong, though.
But still, no need to fret.  I've never seen a SENTINEL contract that had a duration less than several decades and I've also never seen one that did not complete within a year, So no don't worry about the speed they work at.  Neither worry about fine-tuning their orbits.  Once launched, SENTINELS get frequent repeat business.  All the new contracts call for slightly different orbits but there's no need to bother maneuvering them as they still detect contract-satisfying asteroids without moving from their previous orbit.
I find SENTINELs the only way to do business late in the game.  Put 1 up for various planets as the contracts appear, put them in approximately the required orbit, turn them on, and away you go.  Periodically, check for repeat business or offers for additional SENTINELs watching other planets.  Millions flow in for  no effort on you part.  Yay!

Well, you have to upload the image file to some 3rd party site that hosts images, such as Imgur, Flickr, or whatever.  Having done that, copy the link to the uploaded image and paste it into your challenge thread.
Now, for folks to put it into their sigs, I've found you have to right-click on the picture of the image in the challenge thread and CTRL-C, then go to where you edit your sig, position the cursor and hit CTRL-V,  Sigs don't like links to images, they want the image itself.  Then it's up to the user to select the image and add a link to it.

First off, welcome to the madness forums 
Anyway, as you've no doubt realized by now, KSP is woefully lacking in basic, critical in-game information that is necessary to design successful, efficient rockets.  For a rocket (regardless of engine type) to get to space, it must have sufficient delta-velocity (aka delta-V or dV) to get from the ground to orbit, and it must have sufficient thrust-to-weight ratio (TWR) to overcome Kerbin's gravity.  It takes about 3400-3600m/s dV to achieve orbit and a TWR > 1.0 to get off the ground in the 1st place, but KSP doesn't tell you that, nor does it say what your rocket is capable of doing while you're building it.  So you have 2 options.  You can do a lot of hand calculations on paper outside the game to figure your dV and TWR from the stats of the parts (which the game DOES show to some extent) or you can use an instrumentation mod like Kerbal Engineer Redux or MechJeb, which do the math for you.  But anyway, you need to know where you stand vs. what you need or you'll never get to space, or you get there but waste a lot of money on more rocket than you need.  So I really recommend getting 1 of those mods if you haven't already.
But there's 1 other thing to worry about---going too fast during the ascent in Kerbin's lower atmosphere.  If you do that, your rocket will either disintegrate or flip out shortly after launch as it approaches Mach 1.  This means that too much TWR is a serious problem, so you want to make sure your TWR is < 2.0 to start with.  I generally go for about 1.5 for the lower stages and 1.5 to 2.5 for the upper stages, which works just fine.  Understand that a stage's TWR will increase as it runs due to fuel consumption making the rocket lighter, so you can start out pretty low and still end up with  high TWR.
And this, finally, is where we get into SRBs.  SRBs are used for the 1st part of the flight, from the ground up through the lower, thicker part of the atmosphere.  SRBs have a pretty high TWR individually and if you're using them at all, it's because you want them to provide a significant amount of the dV needed to reach orbit.  That means you'll have multiple SRBs on the ship, which means that the ship's initial TWR will be VERY high, too high to survive in the lower atmosphere.  So what you do is, on the 1st stage, add however many SRBs it takes to get the dV for that stage.  Then you right-click on one of the SRBs and drag its thrust limiter slider down until your initial TWR is about 1.5.  Now you're good to go.
To put this all together, you always design rockets from the top down and give each stage the TWR and dV it needs for the part of the flight it does.  So you start with the payload, say a small probe that will do a Mun flyby.  So you've got a small wad of electronics on top, and it needs a small engine with about 900m/s dV to get from low Kerbin orbit to Mun.  TWR doesn't matter for this engine as it will be in space and the light weight of the probe itself will automatically give it a very high TWR.  So that's your total payload.  Now you need to get this to orbit, which means everything from here down on the rocket needs about 3500m/s total dV and a TWR that starts out about 1.5.  You can usually make a relatively small, cheap, and simple LFO stack here that will have about 2500m/s and a TWR of about 1.5-2.5.  If you're going to use SRBs, that's all you need.  This stage will get from wherever the SRBs burn out to establishing a low Kerbin orbit.  This stage will not be running at launch---you launch on SRBs alone.   So then you make the bottom (or 1st) stage out of SRBs.  The SRBs need about 1000m/s of dV---add SRBs as needed to achieve that.  Now limit their thrust so that they proved about a 1.5 TWR at ignition.  In the stock game, limiting thrust has no effect on stage dV, so you're all set.
It is, of course, possible to have SRBs and the LFO core all running at once on launch (like the Space Shuttle and many other real rockets).  But this is only necessary if the SRBs alone can't provide a TWR of about 1.5, and that's generally not a problem in KSP with stock parts.

Hmmm....  The guy to talk to about pulling trailers is @Overland, the land-train guru.  However, I have a few suggestions.
First off, I see that the docking port attaching the tractor to the trailer is at a 45^ to the vehicle's centerline.  I would certainly change that so that it's inline.  Docking ports, especialy the smaller ones, are notoriously wobbly, and by having it at an angle to the direction of the applied forces, you're introducing multi-axis wobbles.
Also, I'd lock the gimbals of the jet engines.  I really hate KSP gimbals because they're so prone to overcorrect, they usually just introduce self-reinforcing oscillations.  And if you combine that with the wobbly problem from the angled docking port, I'm sure that will cause problems.
Those "ruggedized" rover wheels are also troublesome and have a long-known habit of grabbing the terrain and flipping the vehicle.  So you might want to use another type of wheel.  Or try @Claw's Stock Bug Fixes, which has a thing that addresses various wheel problems.
Another issue you might be having is that the high CoM, combined with the narrow width compared to height, is causing the trailer to lean left and right any time there's a slight course change.  This course change can come from either your input, SAS's steering input to hold the desired course, or changes in ground slope.  And all this will be amplified by the docking port wobble, whether the port is angled or inline.  In any case, when the trailer leans, its aircraft landing gear will be touching the ground on at a slight angle.  And as any spaceplane builder will tell you, this usually results in severe swerving and flipping out.