Jim DiGriz

  • Content Count

  • Joined

  • Last visited

Community Reputation

150 Excellent


About Jim DiGriz

  • Rank
    Spacecraft Engineer

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

2,256 profile views
  1. And just like that there's an #899 build for KSP 1.8 which has the shader.bundle in it and fixes drop-down menu issues and some other glitches: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/899/
  2. KSP 1.8 STATUS: Later today or tomorrow probably, time permitting on Sarbian's side, but generally Very Soon(tm). ModuleManager obviously takes priority for him to release first since everything depends on that. I've started working on 1.8 patches for MJ here: https://github.com/MuMech/MechJeb2/pull/1186/files
  3. Would need to supply a `Vector3d force_function(double time, Vector3d pos, Vector3d vel)` (so passing a function handle rather than Vector3d forcevector) at a minimum so that the supplied force would be a function of time and could be a function of the dynamics. Because you need to supply more than just the force on the next physics tick, and you want to do more than supply a constant force for all time of the simulation -- you want to be able to say things like "apply a force that acts opposite the velocity vector".
  4. @Eriksonn following some references from that Fukushima paper led to this paper: https://link.springer.com/article/10.1007/BF00053511 Which derives the gravitational field of a uniform density arbitrary shaped object using Polyhedron. Just skimming it it seems more accessible to someone with college calculus. It does it all analytically requiring no numerical integration or quadratures. My guess at a textbook that would cover integrating the series coefficients as integrals over the mass distribution would probably be (following the references in that paper above, and then following the recommendations on amazon to find something newer): https://www.amazon.com/Geodesy-Wolfgang-Torge/dp/3111174549/ Also I suspect that any graduate level classical mechanics course would cover that as well, but likely not in as much depth. I don't think there's going to be any undergrad text which cover it AFAIK. Certainly it wasn't covered in any classes of mine. Doesn't even seem like Arfkin + Webber covers it although it covers spherical harmonics and legendre functions so the basic math is probably there, but their slant is more towards quantum mechanics applications.
  5. This is the correct answer. I'm not really certain that box is useful at all in stock launches right now for launch to plane. It should probably always be zero, and that textbox and all the code behind it should most likely get removed (although not from the rendezvous function, just from launch-to-plane).
  6. BTW Ipopt looks like it is free to redistribute: https://github.com/coin-or/Ipopt My plan would be to wire that up to MJ by plopping the 3 O/S versions of the DLLs into the MJ source tree + builds and then doing the necessary to link to them, but you could probably wire that directly up to Principia's build system.
  7. Yeah I think I've abandoned PVG now in favor of discrete pseudospectral techniques, but there's an even larger learning curve to overcome. What I'm shooting towards is more or less this: https://www.tandfonline.com/doi/full/10.1080/0305215X.2018.1472774 The pseudospectral techniques applied to rocket guidance starts with Rea's thesis: https://dspace.mit.edu/handle/1721.1/8608 But using the flipped radau points: http://citeseerx.ist.psu.edu/viewdoc/download?doi= The analytic jacobian and hessian calculations that you need to do for that approach are complicated and what I'm breaking my teeth on right now: https://arc.aiaa.org/doi/10.2514/1.A32071 There's also the question of how to do mesh refinement that I haven't even looked at: https://onlinelibrary.wiley.com/doi/abs/10.1002/oca.957 Plus there's costate estimation to check optimality (and maybe refine convergence using the transversality conditions of the indirect ("PVG") method?) https://link.springer.com/article/10.1007/s10589-009-9291-0 Plus other refinements: https://link.springer.com/article/10.1007/s12567-017-0165-5 Right now I'm just playing around with different targeting conditions for a simple vacuum launch problem to be able to answer the question of "just wind up with a periapsis of 185km with the least amount of fuel burned" which I strongly suspect is not a 185x185 orbit, but just YOLO'ing it and throwing a numerical jacobian and hessian at it fails to converge. So I'm now trying to analytically take the derivative of the periapsis constraing with respect to cartesian coordinates and pondering my choices of coordinate system (although Rea's thesis makes a case for just sticking with cartesian for the general purpose case of terminal conditions). https://github.com/matt-weinstein/adigator That package might help with the analytical differentiation, but to do targeting of J2 you'd need to take the BLST elements and take partials wrt the coordinate system. So anyway that's why MechJeb development kinda stalled out for the past month or so... And I'd love to be able to take this package and integrate it with MechJeb but it is commercial/non-redistributable: http://www.gpops2.com/
  8. That should probably get turned into a bug report: https://github.com/MuMech/MechJeb2/issues Right now I know I don't have time to investigate, and I'm guessing sarbs doesn't either. Kind of vaguely hoping that one is a bug in KSP and it magically gets fixed because it looks weird and seems to be tied to that specific part. Either that or there's something unique about that part which exposed a bug in MJ.
  9. - I think that it gets it correctly in all cases, because the first block is responsible for adding or not adding mechjebcore to all the command pods. then the second block is responsible for overwriting all the unlock settings on all the mechjebcore modules. - RP-0/RealismOverhaul already adds mechjeb to all command pods and unlocks it all from the start, so this code disables itself and lets RP-0/RealismOverhaul handle it: https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_RecommendedMods/RO_MechJeb.cfg (plus a bunch more references to MechJebCore scattered around the configs) https://github.com/KSP-RO/RP-0/blob/6fb9c62edc1d467d01275b2030993e4aaf17a5b7/GameData/RP-0/Tree/ProceduralAvionics.cfg#L24-L46 there's some work going on right now to have MJ disabled when avionics are insufficient + disabled which is more the kind of integration that RO/RP-1 players want.
  10. Yep, I just removed that. I don't entirely understand how I tested it and that worked, but that should be removed on dev now. And the reason for going this direction is that it should get the use case correct where someone creates both MechJebUseCommandPod and MechJebUnlocked -- so that they have to use the AR-202 part but everything is unlocked from the start. Which is a bit weird, but it makes the full 2x2=4 block of uses cases all semantically correct. With the other patch it would have ignored the MechJebUseCommandPod "setting". Now that I look at it MechJebUseCommandPod should really be MechJebUseAR202, it reads like it means the opposite now.
  11. @steddyj I'm reasonably but not entirely certain that it is correct as its written. The first block should run first (at least I'd hope -- this is where the uncertainty lies) and should add MechJebCore to all ModuleCommand parts. Then the second block should run and it should update all the settings of all the MechJebCore modules. I fixed a silly typo a few minutes ago which might have been causing problems: https://github.com/MuMech/MechJeb2/pull/1165 Otherwise I checked this on a normal commandpod in stock and found that it worked correctly. Make sure to nuke the module manager cache.
  12. Just created a new dev build #884: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/884/ It has an update to that MM config file: https://github.com/MuMech/MechJeb2/pull/1164 You all should be able to: 1. make an empty folder in GameData named MechJebUnlocked 2. delete the ModuleManager.ConfigCache file to force MM to reupdate 3. restart KSP 4. gloriously cheat your way to orbit
  13. Stage and a half is going to be more problematic with PVG than with old PEG versions because it is fantastically much more accurate about calculations now -- which means that due to the dV being off it accurately computes that a rocket with those stats will never make it to your target and refuses to converge. You might be able to beat on it with a hammer and find some way to trick it, but its getting better about trying to hack it not working. I'd suggest not building 1.5 stage rockets, its probably going to be too much of a pain. Nobody has reported a workaround to me.