Jim DiGriz

CKAN won't accept a PR to update the ksp_version_max to 1.3.1 without the mod author validating that it works on 1.3.1 and bumping the KSP-AVC version https://github.com/KSP-CKAN/CKAN-meta/pull/1320

I just patched the PEG node executor in my development branch to handle Principia maneuver nodes. So if you click "show on navball" then you get a maneuver node, and the PEG code will grab the osculating orbit on the other side of the maneuver node and use that as a target. It then burns down until it hits the orbit (it doesn't use the maneuver node so doesn't care that the maneuver node itself doesn't burn down). Of course if you use it for very long burns or low energy stuff when N-body physics is going to make the osculating orbit prediction over the course of the burn poor compared to the real N-body trajectory then that would void the warranty. The problem right now though looks like Principia's flight planner has some bugs, because when I execute the node and burn it down accurately (within a 3-4 dV on a 1073dV planned burn) i wind up nowhere near the flight planner predictions (i have to crank the flight planner up to 1356 dV to get an orbit that somewhat matches the orbit that i wound up in and the shape of the planned orbit looks off if I do that (and MJ reports i burned 1077dV). I don't have a release of that code since I just patched it an hour or two ago (and I did 2 releases yesterday so I'm feeling the release fatigue right now), but it'll go into the next release.

CKAN is crowd-sourced, you can just submit a PR to add Principia metadata to it.

If there's enough SAS to do it by hand, though, then MJ should be fine. And you should see MJ attempting to use the controls. I'd say something was wrong with the state machine (like you were trying to circularize inside of the atmosphere or something which could confuse the state machine and prevent the node executor from kicking in for the circ burn) but adding a RW wouldn't fix that.

It isn't the warp issue where pressing '.' forces timewarp to start and then the node executor runs normally? (it sounds like its not). And when the craft is spinning are the pitch/roll/yaw GUI outputs showing them centered or moving (i.e. is mechjeb issuing attitude control commands at all and there's insufficient torque, or is mechjeb just not issuing attitude control commands?). This is probably one of those picture-or-video-is-worth-a-thousand-words kinds of issues, because i can't picture what you're seeing at all.

Yeah there's "prevent unstable ignitions" and "use RCS to ullage". "use RCS to ullage" is pretty much perfectly safe to leave engaged all the time AFAIK. if you've got RCS, it'll then enable RCS and ullage up the engine before igniting it automatically. The "prevent unstable ignitions" one is a little bit trickier, since if you're playing with sounding rockets you may want to uncheck this one. With sounding rockets you can't ever ullage the sounding rocket back up, so preventing an ignition only makes certain that the upper stage will never ignite. If the upper stage ignition is in 'risky' status then you might get away with it. If you have "prevent unstable ignitions" checked then that will prevent the throttle up and you'll definitely waste the upper stage. Conceivably it could interact poorly with hot-staging as well. I don't know how to fix that bug. It tells you the work around though, manually select different points on the porkchop plot until you find one that works.

The changes to ascent guidance (which i think are still in dev) should have cleaned up some issues with Ascent Guidance trying to control the current active vessel rather than the vessel the autopilot was associated with -- without those changes I don't think you'll have much luck at all trying to do it all simultaneously. Of course you need to worry about physics range issues and FMRS may be a better solution anyway.

yeah wb9999999999999999999999999 on irc was mentioning something that sounded like a fuel sim bug on irc as well.

fixed in dev. @sarbian maybe time to release a 2.7.0? dev seems stable enough AFAIK right now.

You'd need to repro it with the dev version of MJ on 1.3.1 and post the craft file. If you can't, then it was another manifestation of the bug that is fixed in dev.

If you're not using the dev version that is probably an old bug related to when physics starts early on the pad (most likely due to a revert to launch causing a physics jolt).

If there's an encounter with the Mun/Moon the PatchedConic solver has some issues and needs manual help. You can zoom in on the low-dV section of the porkchop plot and then click points there and try them until one works well. Note that sometimes it bails completely, while sometimes you'll get a solution but it'll be slightly deflected by an encounter and your transfer will be off by a bit, so inspect your orbit after you've created the node.

for a 250t ship that's the same threshold. might need to be a higher number, though, it was based on one rocket test in stock.

I've never successfully gotten back from the surface of Eve. I've done apollo-style from Moho. Working right now on making some improvements to MechJeb to make planning and executing trips to Moho better (you can include an approximate capture burn now in the transfer planner and i did a bunch of debugging of the transfer planner optimizer to make it more reliable and accurate).

Yeah there's a line of code which is trying to settle angular momentum, it probably needs to be angular velocity instead. Ship size will matter. EDIT: possible fix: https://github.com/MuMech/MechJeb2/pull/973

Kepler-90 might be an amusing solar system to create with Principia: https://en.wikipedia.org/wiki/Kepler-90 Throw a few plausible, and vetted for stability, moon systems in there. Delta-V map is probably horrendous though(?), particularly for getting to that closest inner planet...

Was thinking about this thread on my walk to grab lunch and the other thing is that HyperEdit doesn't work with Principia either, and from what I understand the approach of removing Principia, tweaking your keplerian orbit with HyperEdit and then dropping Principia back in just corrupts your save. And then on top of that there's the issue pleroy brough up which was performance -- although I'm not sure I'd model it that way, you can probably get by with doing impulsive station keeping once per orbit, and you can take a nap for the rest of the orbit. You also would probably want to allow the algorithm to be a bit 'sloppy' for performance reasons (you'd probably look at the whole prior orbit, decide where you 'did' your station keeping, perturb the orbit there, then remove RCS from the vessel or something along those lines). Also, I'm not sure what kind of algorithm you'd want to use for station keeping since some N-body perturbations are going to be smoothed out by e.g. the lunar cycle. If you can just wait 2 weeks and let the moon yank you back into position then it makes no sense to fix your orbit with great precision right now. There would also likely need to be some kind of limits placed on station keeping and different station types of station keeping. LEO station keeping is reasonable. Station keeping at a libration point is reasonable. Random low energy orbits probably not so much (although maybe you could just grind up the user's CPU and waste all their RCS until that problem went away).

You're not suggesting anything that isn't obvious. Orbital decay, stationkeeping and low-thrusting-spacecraft-on-rails are all mod ideas that have occurred to everyone that has used Principia. The mod authors are a busy with issues more directly related to the N-body physics simulation though. I also doubt that the correct solution is tighter remotetech integration. The problem is more that you need a mod which looks at the actual principia orbit (not the tangent orbit) and applies a perturbation to the orbit and drains some RCS, and can handle that process through timewarping (which is why decay, stationkeeping and low-thrust probably all should go into the same mod), and remotetech has none of the correct internals for that.

Ah yeah, on kOS if you can trade continued fractions for single trig functions you'll come out way ahead, that makes total sense... Also yes you're correct about all of the above.

If you want a really up-to-date CSE routine along with some interesting historical background: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20160001446.pdf

Actually that's a bit odd because the CSER routine in that paper you've (reddy) implemented I believe is a Goodyear's Universal Variables implementation with Battin's normalized units, and my C# implementation of that handily beats KSPs Orbit class even though I haven't done the work to feed the prior solution back into the next solution as a hint. I think the code that ran in the Shuttle was more complicated due to needing to handle J^2 oblateness, but the CSER you've got should be pretty industrial strength (and fast because it had to run on the potatoputer in the Shuttle). At the same time, though, simplicity of code and validation of accuracy probably trumps everything else. If I could tame the inverse rotation / Krankensbane issues and just use the Orbit class, I would. And for terminal guidance, what I've found you need to do in the corrector is: - project rp into the iy plane - compute rd and vd from your targetting - if you are at tgo < 40 seconds you must release the target constraints with `rd = rp` - then do the normal vmiss and updating of vgo calcs The other trick then (from McHenry 1979) is that lambdaDot calculations are frozen at tgo < 40 seconds, so you DO NOT run the TURNR code: - rgo = rd - ( r + v * tgo + rgrav ) + rbias - rgo = rgo + ( S - Vector3d.Dot(lambda, rgo) ) * lambda; - lambdaDot = ( rgo - S * lambda ) / QP; Looks like rgrav estimate doesn't need updating in the early block either, etc. I suppose technically if you're not computing and using rgo in the TURNR code it doesn't matter what you do in the corrector with rd, but setting rd = rp keeps the meaning correct. Then during the last 10 seconds of guidance you should completely stop updating PEG and fly on the last computation of lambda, lambdaDot and K / t_lambda. Also during the last 10 seconds of guidance you should be counting down tgo and vgo based only on elapsed time and sensed acceleration. You can terminate the burn when tgo < TimeWarp.fixedDeltaTime. When you do, vgo should be 0.1 or 0.2 or some other very close to zero value. If it is not then there's either a bug in your vessel parameters, or there's a bug in your sensed acceleration, and those need to get fixed. The terminal guidance of PEG actually gets dramatically worse if your sensed acceleration adjustment to vgo is not fairly precise. I was seeing issues at 50-60-ish seconds out due to having botched the sensed dV. This is a known issue/feature of PEG (I think one of the two references below mentions it) I also had one kind of derpy issue due to incorrectly rooting my rocket to the payload decoupler on the injection stage and not having the root in the payload, which threw off the mass, threw off the acceleration and threw off the delta V calc of the stage, and i was winding up with vgo of 12-ish m/s and wasn't reaching the right orbit (and even if I'd burned to a condition like meeting the angular momentum requirements of the target orbit, or vgo nearly being zero, then the final calculations of lambda and K / t_lambda and vgo for the frozen value of lambdaDot at 10 seconds would have been off because the thrust integral calculations would have been off). I also included a phiMax / lambdaDot.mag * K clamp like: double clamp = 4.5 * Math.Pow(10, ( tgo - 40 ) / 40 ) * UtilMath.Deg2Rad; That is just because KSP users may do burns of less than 10 seconds or may do stuff like only use 10 seconds of a TLI stage upper to finish up orbital insertion. With the former you need at least one run through PEG to converge with a sensible clamped lambdaDot and with the latter its just going to give PEG fits in the terminal guidance period. So the clamp starts at 45 degrees at 80 seconds out (allowing rd position constraints to be fully satisfied until then) and the exponentially decays to 4.5 degrees at 40 seconds and 0.8 degrees at 10 seconds. Basically forcing it to progressively just burn towards vgo and not worry about turning rate -- but a very kerballed up solution to possible kerbal issues. The problem with clamping lambdaDot, though, is that when you do it, you're implicitly releasing the position constraint and creating a non-zero rbias term. Some light reading on PEG thrust integral stability analysis: https://arc.aiaa.org/doi/abs/10.2514/6.1982-1555 http://www.sciencedirect.com/science/article/pii/S0273117711001426 I did a build of the most recent / most stable MJ code I have earlier today: https://github.com/lamont-granquist/MechJeb2/releases/tag/mchenry8 That also wires up PEG to the node executor and I managed to get one of the worst rockets I have into a 185.2x185.4 orbit and then it successfully executed an ~9 minute burn from parking orbit that nearly hit Mars dead center. It is, however, using the CSESimple calc-101-based debugging routine right now so it might run slow on slower computers.

Well not quite exactly. That box is for inclination of the target orbit, not heading. Heading also is not constant during a launch but follows a great circle route (the sine waves around the globe that any orbit other than 0 degree inclination follows). The only launch that shouldn't change heading at all is a due east burn from the equator on kerbin to wind up in a 0 degree orbit (which arguably is very common in KSP, but it is an unusual exception in reality). So its not really an assumption. Making that box be the launch heading wouldn't solve any particularly useful launch problems (you can do it, but it would always be inefficient to hit whatever orbit you wound up in). It really has to be the inclination of the target orbit to be useful.

Hackintosh with 32GB RAM, quad core, GeForce 980. Used to run KSP on Ubuntu before.

I broke corrective steering in dev when I refactored all of the ascent guidance code. I've got some fixes to that in my branch so it does at least some kind of corrective steering now, but I had trouble replicating the old algorithm precisely (I had a lot of difficulty in reading the old algorithm since the code was a mess and the comments didn't match what it did). It should definitely not be used on dev right now though. EDIT: this will make it better, dunno if it will produce the same results as it used to: https://github.com/MuMech/MechJeb2/pull/958

There's still an order of magnitude less control going from the Mk1 to the HECS (which i see is what the OP is using which is 5.0 nM to 0.5 nM. If the engines are LV-T30's then the OP would have basically gone to zero torque authority. I'd rule that out first before redoing the whole rocket and payload. Then add some fins. Then, yes, consider the aerodynamic monstrosity you've built -- but this is KSP.