Wobbly Av8r

Not sure if this information is what you're looking for, but stabilizing a tumbling vessel is a matter of technique, and good technique is a matter of understanding both what your instruments are indicating and having a mental process by which you analyze and make control inputs to correct the situation. With that concept established, controlling a wildly out-of-control vessel is relatively straight-forward: Slow down rotational movement first (yaw/z-axis) using Q & E keys, then choose to slow horizontal (A & D keys) or vertical movement (W & S keys) finally followed by slowing the movement you ignored at the second step. Identifying the direction of rotational motion is straight-forward by observing the direction the horizon line 'twists' on the navball even if the horizon line is only moving around wildly. The reasoning for this is that as long as you are rotating about the z-axis, your x- and y-axes are swapping with each other every 90 defrees of rotation; thus it is important to slow/stop it first followed by focusing on ONE of the remaining axes to bring the situation under control most efficiently. If I'm not mistaken, the incident you referred to was Gemni 8, a reminder that good old 'stick & rudder' skills are always good to have on standby! Good luck!

Apologize, but after looking it over one more time I recognized also that (contributing to instability with any maneuvering) the amount of area you have in FRONT of the CoM is considerable - while wings and vertical fins can stabilize things, when you give it enough 'yaw', the airplane will act just like a rocket with a huge payload on top with little or no fins on the bottom (i.e. it will want to "swap ends"!) What @FleshJeb mentioned "I'd also double or triple the vertical tail, because the yaw stability is currently minimal" (more vertical fin-nage) will help solve the issue...

@king of nowhereDon't know if anything I posted was significant in your mind, but those really large "elevons" are the kind of thing that will cause you to have a wild ride; when you state that "this thing flies pretty well, as long as i never touch the control since leaving the runway" that's where I'd *start* to make it more stable. Keep in mind that every time you press one of the control keys (WSAD) you are giving a "full deflection" instruction to those controls - if you "tap" the control key, it may be less of an input only due to the fact that the key press duration was shorter than the time it takes the control to fully deflect. Furthering the problem is that as you get faster, the effect is increased. A couple of solutions to try: limit the total deflection of the controls, make them smaller or place them further inboard to limit their roll authority and see if that makes it a bit more manageable. [Edit: One additional observation, below]

I'm afraid that there is likely no silver bullet for KSP aircraft. In the spirit of conveying information on 'how to' rather than 'do this', I submit the following... Not trying to over-simplify physics, but in the void of space, the resultant path or motion of a vehicle is a consequence of, in essence, a thrust vector and its relationship to the center of mass interacting with a single gravitational body (yes, there are localized interactions, but they are just that - localized). While in the atmosphere, however, there are numerous aerodynamic couples that complicate the forces, and thus the path of the vessel. In steady unaccelerated flight, the forces of lift = weight and thrust = drag, but if *ANY* of those forces change, it results in a cascade of related changes that in reality even super-computers have a tough time calculating, much less your humble desk-top computer or lap-top, not to mention that the fidelity of the software cannot really approach the true dynamics of the process. All that said, KSP attempts to retain a level of 'honesty' to their simulation and in doing so makes things rather "squirrelly", so the solution falls upon the user's ability to both make a design that is not prone to over controlling (one in which small inputs result in large movements), but also has the ability to "finely tune" the control inputs to establish and maintain the lift=weight, thrust=drag relationship. Those two concepts translate into designs that fly a specific profile that varies only minimally with the corresponding gradual change in mass due to fuel consumption. That's the 'why', but in practice not the 'how'. The 'how' is made more possible by following certain design philosophies like not putting in an "angle of incidence" on wing/tail parts to enable a wider operating range OR building WITH various "angle's of incidence" knowing you will generally fly at one particular airspeed and will be able to set thrust and trim to maintain that condition. Also keeping the thrust vector as close in line with the center of lift so changes in thrust have minimal effect on stability is another consideration. Because take-off and landing speeds relative to the design speed are significantly different, separate lift considerations will have to be made to accommodate those flight regimes. Anecdotally (meaning I am aware my solution is one of many) once your design has allowed for overall stability as suggested above, using the trim feature (Alt-W or S) is key to achieving the 'hands off' flight path you desire, and once established, having SAS then turned on seems to provide a solution that allows x4 physics warp to speed things along without going out of control. Hope that helps... As always, YMMV. Good luck!

I've had a fair amount of success of using the Re-root tool on the grayed-out merge part before it is attached, to create a more convenient node from what appears to be an assembly with non-existent node. As an example, if the top of a "Merge" assembly terminates in a nose-cone, select the part that the nose cone is attached to as the root - then it will attach and be manageable as @bewing described above.

After a closer examination, it does appear that you have a Rovemate mounted sideways - you'll probably have to turn off the reaction wheels when you are driving to maintain controllability as the control options are Forward (as they currently are) Reverse (which will just cause them to veer right instead of left) or Top, which *might* work as at least the reaction wheels will not be veering left or right, but who knows? Since you said it tested okay in Kerbin's gravity, you should be able to get the job done without abandoning it...

Not sure it will help, but under the PAW menu item [for the Probodobodyn Rovemate, if that is what you used, just above] "Control from here" there should be a few options to change orientation of the probe - maybe you can utilize that? [Control Direction: Up, Forward or Reverse]

The "exact" equation relating lift and velocity (if that's what you're looking for) is: L = CL x S x 0.5 x ρ x V2 where L is Lift (force) CL is Coefficient of Lift (derived from the angle of attack of the lifting surface) S is the Surface area of the lifting surface ρ (rho) is air density V is Velocity

While I agree with the premise of performing the reversal at Ap, I think the dV cost is a little higher - at 83Mm orbit I still was movin' along at 114 m/s. Even so, the total maneuver, tho, from wrong way orbit, through Ap up to 83Mm (135 m/s) , reversal burn (230 m/s) and then bringing the Ap back to requirements (135 m/s) in the correct orbit took ~500 m/s dV and 56 days to accomplish without respect to the additional timing that would be required to match the rough Ap and Pe of the required orbit. FWIW.

It appears that you have a lot of experiments on board - each one of those consume a certain amount of electricity - did you perform some experiments and/or drain the battery to the point of depletion? Are they consuming more power than the solar panels can compensate for? You can also check the PAW menu and make sure the wheels are powered, and so on...

While I agree with @James Kerman, on a perfunctory level I would check 3 things: Is there electrical energy available, either with batteries or solar panels? Do you have control of the vehicle? Are the brakes on? Tap the 'B' key a time or two, also check that the 'Parking Brake' is not on by turning it on & off using the icon near the altimeter that looks like a circle with an exclamation point inside of it...

Just to make sure we're on the same page, a 180° inclination/inclined orbit is a heading of 270°. Assuming that you were to keep your vessel oriented to prograde so that you're always heading in the direction of travel as you orbit Kerbin, an inclined orbit is a "great circle" that only initially maintains the heading (from the equator) that establishes the orbit, after which it oscillates in heading as it moves around the body. Take a look at the image below: If you maintain a powered constant heading throughout the burn (black line = same angle/heading), you will eventually end up over the pole as illustrated by the black line on the right - because as you proceed further north, the lines of longitude converge and your flight path will "curly-cue" up to the pole and no matter which way you turn at the north pole you're flying south! A true inclined orbit actually changes/oscillates heading as it proceeds around the body, similar to the red-dashed line, which when looked at on a flattened map (left) looks like a sine wave.

That looks pretty sweet - a lot of work that will pay off! I don't know about others, but I always appreciate knowing how things worked out, so thanks for that...

Huh. Well, now that you mention it... @Popestar are you sure you don't want to try and revert?!? Good catch, @HansAcker! Re: my recommendations to adjust orbit... "Nevermind!"

If you don't have enough dV to make the Radial burn (it is fairly inefficient), the other solution (other than adjusting the inclination at the AN or DN) is to wait until you are abeam the required orbit's Ap or Pe and perform a prograde or retrograde burn, as appropriate - in other words, you would be stretching and contracting your current orbit AT the points that need to become the Ap or Pe... If you have the time, this burn would be more efficient but would take the time to get through the various points of the orbit. [ Edit: here is a link to the same kind of question ]

Radial IN Radial OUT

Well, of course there is a way to adjust the orbit - create a maneuver at the point where the two orbits intersect and then perform a "radial in" or "radial out" burn, depending on which intersection you're at... [Edit: if you're in the same position as above, a "radial in" burn [[ at the intersection just prior to the required orbit's AN, from what I can see ]] will reorient your current orbit towards the required one...] [Edit second: I'm assuming the variation in inclination will not be significant, but if it IS beyond tolerance, you would want to adjust the inclination AT the AN BEFORE performing the radial in burn... but because the AN is BEYOND the first intersection I described above, you would do the intersection burn at the OTHER intersection (the one that is closer to the current DN) and in THAT case it would be "radial out" burn. Hope that isn't too confusing...]

Yeah - this problem occurred recently - you'll have to *roughly* match up Ap and Pe... then it will complete. Revert is good thing...

My experience with "probed, but uncontrollable" sub-vessels is with recoverable boosters. While it has only happened a few times and seems sporadic (so my advice is anecdotal at best) it might solve your loss-of-control issue: The solution I've found, prior to releasing or separating from any "probe-equipped sub-vessel", is to utilize the "Configure Naming" option on the "extra" probe's PAW (Part Action Window, the right-click contextual menu) and rename and designate each as a "Relay" as well as setting it to a priority of less than the default (which is 10). While this is probably achieved most efficiently during construction in the VAB/SPH , it can be accomplished in flight as well prior to separation. When done properly, this should not change the name of the overall vessel, which has a priority of 10. [If one of the probes is the "primary" controller, then only rename the other two...] I found that occasionally, when I did not take these steps, I would have a vessel with a probe lack any ability to control - but it was, IIRC, classified as "Debris" by default regardless of having a probe with power and antenna attached.

While I would love to be able to give you a direct answer ("Go to X position, change Y value"), the information I can give you is this: If manipulating the KSP GUI is too difficult, you may find editing .CRAFT files (or possibly the .SFS file that contains the particular instance of your vessel) to be more onerous to deal with - if you have "30-50 part clipped tanks inside each...2.5m short tank", you will have a difficult time identifying which tank is which - they have long, arbitrarily assigned ID numbers that computers are well-suited to process but not humans... and if the tanks you wish to empty are only in specific positions, well, the task will become an exercise in futility as you would have to look at data that numerically indicates how each clipped tank is offset from the parent part... << s h u d d e r >> If you're "Rain Man", please proceed. If you're like most of us here, @bewing's advice is probably your best bet. As an aside, if the amount of fuel is a constant, I would figure out how and where to place an equivalent tank or two that would imitate the CoM effect; if the fuel removal is dynamic (i.e. has to change during operation), at the very least I would reduce the number of tanks required (by a lot) so that I could use the "Fuel Tab" to open ALL the tanks' PAWs, pin the ones I need to manipulate and remove the rest...

The easiest solution I've found is to place "Toggle Play" as well as "Toggle Direction" under the Gear action group. [To clarify: the robotic parts are selected and their actions grouped to the KAL-1000 player, then the KAL-1000 unit itself is selected and the two actions of the player above are grouped to the "Gear"]

I've found that shrouds and fairings are a bit finnicky; shrouds will only 'protect' their contents when properly constructed - and this applies to fairings as well. I would investigate what the shroud terminates AGAINST to determine what the problem might be... And I'm not sure it's intentional, but the "structural tube" parts, while visually appearing to keep the integrity of parts placed inside them, actually do not - and behave as though there is no protection there at all and create very high drag profiles.

Just a guess here, but in general, whenever the payload diameter is larger than the base of the rocket (and I don't have a ruler on me, but I'm guessing that's the case here...) the aerodynamic forces tend to want to turn the rocket @ss-over-tea kettle in the atmosphere. I'm also guessing you have enough reaction wheels, fins and/or gimbal of the engines to counteract the destabilization caused by the aerodynamics, and the result you're seeing is the battle between those forces! And since you say it doesn't go out of control, I say "Well done, sir!" 'cuz when push comes to shove, that's the only real measurement of success in KSP!

So, what I've found while attempting to tackle the same problem is two-fold: 1) Getting the S-IB to separate cleanly while retaining the interstage ring, and 2) Getting the interstage ring to leave the rocket "nicely". Given the conversation about your choice of engine, I would humbly suggest you may be over-fueled... when I created my Saturn V Doppelganger, my booster tanks were more empty than full - and I used the more highly Apollo-like pieces to recreate a reasonable facsimile, as I'm sure most folks would prefer. Rather than try and describe little details (and thus bore you and/or anyone), I'll just post it to kerbalx: https://kerbalx.com/Wobbly_Av8r/Apollo-Saturn-V so you can get some ideas for how you might solve your construction issues... The solution I found for the interstage ring separation was to detach the S-IB with a TD-50 decoupler, the interstage ring being formed by a fairing which is not 'deployed' (as most fairings usually are) but 'staged' because it is attached to the S-IIC by one of the nodes of the engine plate upon which the 5 RE-I2 second stage engines are attached. One last note here - the T-50 Structural Tube section that I've seen used for this section is very 'draggy' and difficult to get to separate properly, hence the solution I chose.

While your orbit parameters looked pretty much right on in the top post / image, because the orbit is slightly elliptical, it doesn't appear that your Ap and Pe are in the same location as those of the orbit it was expecting... so I think the easiest solution would be to make a maneuver node at one of the two locations where your orbit crosses the specified orbit and perform the proper "Radial In" or "Radial Out" to "twist" the orbit into place. [Edit: One of the crossing points is at the (visual) 2:30 position relative to Kerbin in the top map image and would require a radial out burn. If your other parameters of Ap and Pe are still "on target" you should only need a radial burn] That's what it appears like to me, but I could be mistaken. At least check into the maneuver node to see what's possible... Good luck!