Jim DiGriz

Members
  • Content Count

    413
  • Joined

  • Last visited

Community Reputation

169 Excellent

2 Followers

About Jim DiGriz

  • Rank
    Spacecraft Engineer

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

2,437 profile views
  1. You don't launch to a planet's plane to do interplanetary. Launch to the Mun's plane (plane of the ecliptic) and go from there. Actual launch optimization for interplanetary trips is a mildly horrendous optimization problem and has never been implemented in the KSP universe. It also just does not matter as much as anyone think it does. LAN would also be more important than inclination or plane for being able to do the correct b-plane targeting (you can efficiently eject from the system from a 90 degree inclination orbit provided that your LAN is correct so you do not require a plane change to meet the v_inf).
  2. Launch to Plane should be fixed in #955: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/955/
  3. Yep, Yep and Yep. The circularization burn is almost a stupid trick, it needs a lot of work done to the Node Executor to make burn precision that precise. And yeah, targeting the inclination and eccentricity could be done, that's just more math. And yeah, the actual porkchop interface is still not satisfying in numerous ways.... Also everyone an overhaul to the launch-to-plane math just landed. If you see anything wonky please report it. It sort of escaped into the dev builds without sufficient testing (I've gotten distracted with a bit of a minor family emergency). Make sure the field next to the launch to plane button is zero though, if its not your plane will always be off by that many degrees (kinda looking at nuking that or more aggressively forcing it to zero to eliminate bug reports due to that field).
  4. Yeah I'm very dissatisfied with that as well, but UX and adding more buttons is almost harder than math to get right though since if you move things around people get confused. Its also very cramped and squishy in the maneuver planner box (and look at everyone complaining about the size of ascent guidance on tiny screens before suggesting making it bigger). But yeah, it needs to be better somehow.
  5. Yeah think you replicated the problem I was seeing, look in the logs for that "zero miss phase" and "periapsis phase" and look for the dv values jumping around a lot. They shouldn't. They almost certainly are. Gotta lock down the optimizer more. And the psychedelic porkchop may be accurate, I just can't visualize it very well in my head. It does seem weird because you shouldn't be able to see individual orbits on that, and the porkchop omits interactions with minmus and the mun (and the jool moons) so nothing else should really be changing that much. Some of the weird stabbity bits of the porkchop plots I can't quite visualize what is going on there either though and those artifacts show up in professional publications.
  6. I think you should be able to play with it and it'll work if you don't try anything too crazy. If you do find it does weird stuff on non-crazy things that would actually be useful to know about.
  7. Meanwhile https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/948/ should hopefully fix the transfer planner. I'm at least able to replicate alex moon's numbers now from circular nearly-coplanar equatorial orbits to ejection. The porkchop numbers are still high by a few dV which I have a few things I want to try to fix those. EDIT: Well I already found one more bug. If you see it sometimes places a maneuver node which is wildly higher dV than the porkchop prediction that is now known: [LOG 22:27:51.687] zero miss phase before optimization = 14996932537.2083 m (763.306944838952 m/s) [LOG 22:27:52.041] zero miss phase after optimization = 64372.1103050466 m (1153.38572748793 m/s) [LOG 22:27:52.043] periapsis phase before optimization = -315746.987141928 m (1153.38572748793 m/s) [LOG 22:27:52.092] periapsis phase after optimization = -11.7580441570608 m (1153.40341200134 m/s) The m/s values should not be jumping highly like that. That is from a 90 degree inclination, 0.80 eccentricity parking orbit, though, so hopefully most users don't hit that. Probably know what the fix is for that one as well, but it'll take another few days.
  8. If you want a bit of promising developments I just found this paper: https://arc.aiaa.org/doi/abs/10.2514/1.G004048 That has a clearest explanation of apollo descent guidance I've seen, with successively increasing levels of tweaks to make it more and more optimal, but without needing to solve a full pseudospectral convex optimization problem. That bumps landing guidance up significantly on the list of things I might take a run at cleaning up.
  9. Right the problem is that MJ isn't built on particularly good foundations and I'm thinking about KSP2. So there's a reasonably solid ODE integrator in MJ now which is approaching the functionality of Matlab's ODE45, there's now Brent's 1-d minimization and root finding algorithms, there's a pretty well debugged Gooding Lambert solver, there's alglib.net's implementation of Levenburg-Marquardt for gradient descent rootfinding in N-dimensions, there's other stuff like Shepperd's solution for orbit propagation (and sometime soon calculation of the primer vector and state transition matrix). All of that is getting MJ on a much more solid foundation where its both more debuggable and easier to rip out large pieces of MJ in the event that KSP2 happens and hit the ground running. Some of that is noodling on issues that don't seem important but ultimately it leads to things like being able to simplify the flying sim to be able to more accurately land rockets (and maybe doing something about the parts sim in the fuelflowsimulation as well). So the stuff which seems pointlessly foundational can feed back into fixing bugs across the board by leveraging battle tested components (which is why I messed up Hohmann transfers which nobody really needed in order to get Brent's algorithm solidly tested). The idea of doing a multi-node KAC-like suspendable node executor probably is something that "well maybe that is more a plan for KSP2" comes up, IDK. Depends on when KSP2 happens or if it happens. And the problem is that I've never used rovers, and don't think I've ever touched the rover autopilot once. MJ is way too sprawlingly vast. Similarly I haven't had any time to play with any of the new features. And there's hundreds of hours of work that I'd like to get done ahead of that just to make rockets work better. I've got some code right now which implements a quaternion-based PID controller which might be a quantum jump up in PID control and fix a lot of the issues people have with controls which cuts across the board. Before I touched rovers/BG I'd probably look at fixing the rendezvous autopilot since there HAS to be a way to make that better and easier to use without wasting so much RCS. In the RSS/RO world people have been bugging me a lot about mid-course corrections since often plane changes in low orbit are very suboptimal. Could also do bi-elliptic transfers now that the maneuver planner supports multi-node planning (which is like a 4 year old user request).
  10. kOS is the answer. People keep asking for this, but the code is very difficult. I took a run at it awhile back and got frustrated with what I wanted to do with it. The existing code is actually very full featured, but tightly coupled to itself in ways that make it difficult to e.g. extract the ODE integrator. If the ODE integrator and the parts simulation of the flying sim were extracted to be more self contained then the remaining actual physics sim would be vastly simpler to debug and extend. Implementing features on top of the existing code is likely to produce a mess of spaghetti that nobody can understand.
  11. Yeah MJ really needs a proper finite burn executor. There's already a button though to omit the circularization burn completely from the porkchop and then you don't get the maneuver node. I've got plans of extending the UI to support targeting an inclination and an apoapsis (or SMA + ECC). I can probably include a button though to omit the second burn. At some point though I'm going to want to implement a flyby finder which will necessarily require dropping maneuver nodes on every flyby. There needs to be some kind of better solution to this -- ideally a multinode finite burn executor that target a list of orbits rather than a list of maneuver nodes and which can be suspended in the background and will wake itself up like KAC. #942 looks right. Still working on the buggy behavior, I went barking up the wrong tree last night, got a few things to try today. I don't think I have any need for more replication cases, it is pretty obviously broken in the coplanar case (I did a lot of testing in awful non-coplanar, elliptical cases that I assumed would be the best problems to find bug but never bothered much with the trivial cases). EDIT: I figured it out, just needed to keep reading further in the paper I was implementing. Replicated some values for Kerbin->Duna from Alex Moon's transfer planner in Matlab. Might have it fixed in a couple days.
  12. So the porkchop plotter for the transfers WHEN including the transfer burn will be off by a bit. Currently it is still just taking the difference between the helocentric transfer orbit and the helocentric velocity of the target planet and calling that the "capture burn". So there's a discrepancy of 200 m/s extra that I find when I actually plot it. That's a known issue. Oh yeah, delta-V maps have kerbin LEO to duna intercept of about 1060 and 600 to capture. And visibly it just looks poor to my eye, the transfers burn isn't very tangential to the parking orbit. And since it affects the porkchop plot equally, and from the logs it doesn't look like the optimization of the maneuver node is changing the dV much, it looks like its a bug in the new analytical burn calculator. Okay, that repos really simply. There's no workaround, I probably just have a math bug someplace to track down.
  13. What is in the logs? Also it helps if you annotate what the different screengrabs are, otherwise I'm stuck looking for clues as to what you're doing and what you are trying to highlight (sometimes it is obvious, but without seeing the buttons you were pressing sometimes its hard to tell what you are actually doing). Also, it is expected that the porkchop plots will differ from all the other existing transfer planners now. The calculations that MJ uses now takes into account noncoplanar elliptical inclined parking orbits. Alex Moon's planner specifies that it is from circular, equatorial orbits only (and I don't know if he's squashed the solar system down into a plane or not to keep the math simple). MJ used to use a circular approximation (so elliptical orbits were entirely broken) and the code was somewhat unreadable and might or might not have supported inclined non-coplanar parking orbits correctly. So far I'm having a somewhat difficult time replicating this, although I did notice that at first "box drawing" on the porkchop plot seemed to be entirely broken, although when I hit "create node" once after trying to draw boxes that it picked a completely insane transfer (incredibly expensive but it worked), then I clicked "reset" and it went back to normal. So it was like it was drawing the boxes and zooming into a section of the porkchop plot but wasn't display it back properly. IDK how that happened, and it seemed to magically fix itself. EDIT: Oh I seem to have figured it out. First create a node so you have a transfer and "initial orbit cannot be hyperbolic" comes up. Then draw a box somewhere reasonably expensive (like a small box around some "green" stuff). The porkchop display will not change, but the box selection will have been made. The press "remove all nodes" followed by "create node" and get some relatively insane ~4000 m/s transfer even though the display is saying that there should be much better transfers. Press "remove all nodes" followed by "reset" and then you can go back and draw correctly and it all makes sense. That seems to just be a UI bug rather than a math bug if that's the problem.