FloppyRocket

The game does its best to tell you what it thinks you want to know. It isn't always right.

I wasn't asking for help.

I never claimed it was efficient ("typical" was the word I used), and I also said said that there are infinite possibilities. I wasn't the one asking the question on this thread, just trying to be helpful. Needless badgering is one of the reasons that people avoid posting on the forums.

Just getting above 70 km isn't sufficient information - how fast do you want to be going when you reach 70km? The rule of thumb is that you need 3400 m/s to get into low Kerbin orbit (80 km). A typical launch might use 2400 m/s to get an Ap of 80km, then a 1000 m/s circularization burn. There are an infinite number of variations possible.

Do any of your probe cores have a built-in antenna? If not, did you add any antennas?

@Xt007, you quoted my message, but didn't add any reply. Notepad++ here also. I don't use it as an IDE, but it is a very good code editor.

I haven't been actively investigating this. Early on I tried some simple experiments to duplicate the issue from the original topic (i.e. sudden shifts away from the intended pitch curve), but I wasn't able to observe any abrupt departures from the planned pitch. The only curious thing I observed was that the rocket I designed also had pitch control saturation, but I chalked that up to the pitch curve being aerodynamically difficult for my specific rocket design to fly. I have seen PID integral windup before professionally. It was not a happy experience.

Nine "steps", perhaps?

The thing you don't need is the 3400 m/s that got you into Kerbin orbit. You dispel the equivalent energy in the atmosphere when you re-enter.

Note that the delta-v numbers in the chart are all vacuum delta-v, not the atmospheric delta-v you'll see by default in the VAB. You'll need to adjust the setting in the VAB's DV menu so that is shows vacuum delta-v as you design your rocket.

You're going to intercept the Sun any time you leave the Kerbin SOI. No plan is needed.

@GRS No questions from me, I'm just not working on this project at the moment. I'm writing a kOS autopilot script for sending unmanned probes to Minmus.

Topic: How to traverse the list of orbit patches in a maneuver, without just using a huge set of if-statements. I did a few searches and couldn't find this topic, sorry if it is a duplicate. I'm trying to write a kOS script (based on the "cheerskevin" youtube series) that will auto-launch from Kerbin to a hoverslam landing on Minmus. This is his video series that uses a ternary search to find the time when the current trajectory will have the minimum distance to the Mun. I'm expanding the script so it can auto-land on Minmus instead. Obviously, the Mun occasionally gets in the way, so the trajectory planner has to cope with the maneuver having multiple orbit patches. Sometimes these Mun encounters provide a nice gravity assist, so that's handy. But my code has a problem. Is there a way to artfully traverse the list of patches within a maneuver node, so that I can find the right patch on which to base the "proximity to Minmus" calculations? I tried this sort of program flow (just pseudocode) if maneuver:orbit:hasNextPatch { set orb to orbit:nextPatch } ...within a loop, trying to find a patch that applies to Minmus, or stop when it finds that hasNextPatch is false,. But the assignment of "set orb to ..." doesn't seem to work. I got an infinite loop with every patch belonging to Kerbin. Update: Aha. I think I found the problem - I was stupidly using the variable 'obt" for my local orbit, but "obt" is a reserved keyword for "orbit". That might have been monkeying up the works. This seems to get the job done: // note: 'm' is the current maneuver node set orb to m:orbit. // traverse the list of patches until not orb:hasnextpatch { print "Body:" + orb:body. print "ecc :" + orb:eccentricity. print "Per :" + orb:periapsis. set orb to orb:nextpatch. } print "Final patch: Body " + orb:body. I'll leave this post here in case others find it useful. The basic task is to traverse all the patches from a single maneuver that causes a trajectory that starts in the Kerbin SOI, flies into the Mun SOI, then back into the Kerbin SOI, then into the Minmus SOI. That's four patches, all triggered by one Maneuver. - Tom

Thanks for the suggestion. I've gone idle on this project, as I'm at a low of enthusiasm for the amount of effort required for the Eve and Jool missions.

Thanks, that's what I was missing. Thanks, that's what I was missing. I am able to view the video from May 21 now.

I'm just seeing "An error occurred" when I try to play the video.

Re: "disabling the reaction wheels': Maybe set the Wheel Authority to zero? And then add some RCS thrusters to get pointing control for the circularization burn.

Interesting point. I have no idea if it is the same issue. How would I test for that (i.e. whether kOS is actually using the reaction wheels?) I'm not sure how to "completely disable" the reaction wheels. In the MK1 pod, the only RMB options are Normal, Pilot Only, and SAS Only. I could try putting something on top of the rocket that doesn't have reaction wheels. I should also say that the test rocket I"m using behaves totally fine if it just does a gravity turn without any kOS script running and with SAS off. The fins do their job even without a script running. So i don't really have a lot of evidence that my kOS launcher script is actually doing anything useful. It does roll the rocket to a 90 degree heading, and deflects the pitch control surfaces. The launch script does this to get off the pad: lock throttle to 1. //lock angle to 5.37e-8*alt:radar^2 - 0.00361 * alt:radar + 89.6. lock angle to 90 - (sqrt(alt:radar) / 3.14). lock steering to heading(90,angle). stage. wait 3. The rest of the script manages staging and throttle control to avoid excessive atmospheric drag and circularization. I can use either the quadratic or the sqrt() profile, they behave very similarly. Since steering is locked, the wait 3" doesn't do anything useful.

I've created a rocket similar to the one you posted, and using the steering method from CheersKevin video. It has a parachute on the top of a MK1 pod, rather than a launch escape tower. I set the reaction wheels in the command pod to "SAS only" mode, so that the first-stage steering is only via four "Delta Deluxe Winglets". The kOS script uses locked steering. It steers smoothly through the first stage burnout, without any oscillations. After the 1st stage loss of thrust, the kOS script stages, unlocks the steering, and enables SAS Prograde control. I didn't modify any of the built-in PID steering constants. I didn't encounter any problems. I wonder if the launch escape tower on your rocket is creating some drag-related oscillations.

Nice set of data. Do you also have any velocity data you can plot that goes along with pitch and altitude? Since you're steering using fins, airspeed is probably significantly important.

Wow, I have never heard of that trick either. Thanks!

PreciseNode doesn't do anything for you. It isn't about "not doing it right". It's about being able to make very precise adjustments to what you're doing.

The PreciseNode mod is good for making small changes (in time or delta-v in all of the maneuver directions) to get exactly the intended departure angle. I don't know if the new Maneuver Node features in the latest KSP version have made PN obsolete. Depending on how far out from Kerbin you make the mid-course correction, you can fix that magnitude of error with very little delta-v.

I've never heard of the "hit spacebar to reorient" trick. Is that documented somewhere?

My experience (which is small) is that Duna's atmosphere is weak and is only significant if you are landing at very low altitudes. Unless you're very good at selecting and landing at a specific location, I recommend you plan on a full rocket-powered landing.