conklech

Thanks for the comprehensive explanation. Why does the orientation of the craft, even with one-piece crafts, seem to cause such large instantaneous changes? And do you agree with the casual observation that things are worse in 1.0.2? I think I have a 0.90 install lying around; maybe I can do a comparison test over the weekend.

Your explanation is consistent with my guess; roughly, that there's some accumulating floating-point error involving rotation. The Krakensbane solution didn't completely disconnect the local and accelerating frames of reference, it just factored it out to get some more precision. I wonder if this corner of the sim could be revisited during the Unity 5 transition? I've done a similar test where I bounced in and out of (non-physics) warp to zero rotation; the same thing happens. The vessel of course rotates in the rotating OBT frame of reference shown on the navball; maybe some calculations are being done in that frame? It's actually a much bigger problem when you're actually rotating, e.g. to align with a small-delta maneuver node that jumps all over the ball because your orbit is fluctuating by more than the desired change. Setting up synchronous orbits for RemoteTech networks is a pain; I dropped that mod in part because of this bug. I'd be more willing to write this bug off as "oh, orbits are unstable in real life" if the orbital energy were decreasing rather than increasing. Furthermore, there's now an un-fun incentive to spend as little time off-rails as possible if you want to have reliable maneuver predictions. I agree that it's an existing problem that's gotten worse. I remember seeing jitters in 0.90, but I never watched long enough to notice whether there was a systematic error. These changes of a meter every few seconds are really disconcerting, especially in the stock game where you can't see that the semimajor axis is still sort of stable. Thanks for confirming on Windows x86!

KSP 1.0.2, Linux, 64-bit, Steam edition. Running a normal Ubuntu installation with an nVidia graphics card, using the recommended proprietary drivers. Expected behavior: An unpowered, single-part craft in a circular orbit well outside the atmosphere will stay in the same, stable orbit when time acceleration is off, i.e. not "on rails." In reality, low earth orbits decay slightly. As I understood it, KSP orbits outside the atmosphere are expected to be perfectly stable. Actual behavior: Apoapsis, periapsis, and semi-major axis all vary noticeably. In this test, starting in a roughly circular orbit, the orbit does not decay. The apsides change visibly, a meter or two per minute; the SMA (in this test) increases by a few meters per hour; the other orbital parameters change slightly. Impact: Maneuvers and intercepts are unpredictable unless you're constantly in timewarp. Physics feels broken. Trust issues. Fun level decreases. Reproduction steps and test case: Download game from Steam. Launch and immediately begin a new sandbox save. Construct and launch something into orbit. (You can see in the first screenshot below that I forgot the coupler on the first launch. That vehicle exhibited the same problem, but I wanted a single-part craft for the test, so I launched again. That's why there are two launches in the log.) (While the batteries are still alive, turn the craft a bit and observe the orbit changing. AFAIK, that's a different, known bug, so that's not what this post is about.) Disable the reaction wheels and turn off SAS; step away from the controls. Do not turn on time warp. (Physics warp also has different weird effects on the orbit. For this report I left physics warp off at all times.) Observe the orbit. Here are my observations. The apsides are from the screenshots; SMA is from the save file captured just after each screenshot, available below. (Apo+Peri/2+600 agrees to six figures.) If you look carefully you can see that the longitude of periapsis changes by a few degrees too. If you look in the saves, you'll see that all orbit parameters are changing. Observation 1: T+07:33, Apo 113,136, Peri 106,336, SMA 709,736.286620452 Observation 2: T+32:57, Apo 113,070, Peri 106,405, SMA 709,737.294459971 Observation 3: T+52:18, Apo 113,194, Peri 106,284, SMA 709,739.000280522 And here are the images. The apsides don't really show up in the Imgur preview, so there's not much to see. The KSP.log is here. I don't see anything interesting there; the NREs at the end are presumably because I Alt-F4'd the game at the end of the test. The three save files, in addition to the screenshots and log, are available here. In the save files, find the focused ship by searching for "pid = aa0eed81e6014276a778da4d41b363ea". I don't know if any of the perturbations are periodic. Some of the effect could potentially be related to the craft's orientation relative to Kerbin or some such. I could run another test tonight if there's interest.

This has been talked about on and off throughout the development of nuFAR, but I've never quite grasped what this means. Are the aerodynamic effects of "wing" parts calculated differently than the aerodynamic effects of, say, tank parts? Is a "wing" different from an ordinary rectangular part? And in particular, does building a fuselage/fairing out of (perhaps clipped) wing parts have unexpected side-effects? I'm excited to start my first nuFAR designs this afternoon!

Now that 1.0 has hit, a gravity turn calculator would be particularly relevant. The MechJeb thread has been spammed with a lot of attempts to get its curve-following ascent guidance system to work, with mixed success. An accurate pre-calculation would make things much more reliable.

Adding to the ascent profile discussion: In 0.90+FAR, I had good success executing true gravity turns using SmartASS as follows. First, rotate the vessel in the VAB so it's aligned due east. On the pad but before launch, engage SURF mode, with the appropriate heading (90 for a normal equatorial orbit) and pitch of 90. Press execute. Decide on your pitch-over angle. For a rocket with initial TWR around 1.6, I found 3-4 degrees with a pitchover about 100m above the pad to work well. I haven't spent enough time yet with NewStock aero to know what's best. Pre-input the pitchover maneuver into the SURF input. E.g. for a 4-degree pitchover, change pitch to 90-4=86. Don't press execute. Launch as usual. At the appropriate moment, execute the maneuver. (You can cue this by speed or altitude. We're going by heuristics here; I don't believe anybody's made a gravity turn calculator yet.) Watch the navball closely; once the surface prograde indicator is lined up with the vessel's heading, switch to SVEL+ mode to maintain a 0-degree angle of attack (which is the essence of the gravity turn). If your rocket is aerodynamically stable, you can and should turn off SmartASS once you reach a few hundred m/s and turn it back on once you leave the atmosphere. Lather, rinse, change your pitchover angle, and repeat until you reach orbit efficiently.

There are other CLI languages that should produce working addons. F# and IronPython are probably the best prospects, although I haven't tried either with KSP.

By gravity turn, I'm talking about a flight path that goes vertical for some distance, executes a single pitchover maneuver, and then maintains a zero angle of attack (follows prograde) at least until exiting the atmosphere. Choosing the correct pitchover parameters is pretty important in FAR, and presumably in the 1.0 aero model, because you're then effectively locked into that trajectory; for normal rockets, once you pass a few hundred m/s, maintaining an AoA beyond a few degrees is impossible. If your pitchover is too aggressive, you'll never escape the atmosphere; if it's too vertical, you'll incur potentially-huge gravity losses. Furthermore, if I understand correctly the trajectory is in large part determined by the thrust curve of the launcher, which obviously involves a number of variables. A pitchover maneuver for one launcher is not likely to work for another. For these reasons, it's been my experience that FAR launches involve either a lot of trial and error for each new launch platform, or throwing a lot of extra delta-v at the problem at taking a conservatively high trajectory. Okay, maybe that's the Kerbal Way; but... I see too modding-type challenges here; I don't know if either of them has been addressed. One is to reliably execute a pre-programmed pitchover maneuver, which doesn't seem that difficult. (It's not incredibly hard to do manually, but there's a big payoff for precision.) The second, which I'm more interested in at the moment, is to compute the correct pitchover. It seems that this should be a solved problem in the actual aerospace industry; I haven't yet done enough research to see. It'd also be nice to calculate a good value for "how much delta-V do I need to get into X orbit" rather than the existing rules of thumb. Is anybody working in this area? If so, I'd like to help (within my relatively limited means).