![]() ![]() I haven't dumped things into any tools to check this, but two DLLs stood out to me when looking around for a half remembered late night fix for frustratingly wobbly rockets (I was looking for and eventually found the PhysicsSettings.json) but I came across these two: "Kerbal Space Program 2\KSP2_圆4_Data\Plugins\x86_64\LuaPipePlugin.dll" and "Kerbal Space Program 2\KSP2_圆4_Data\Plugins\x86_64\LuaPipePlugin64.dll". Since theres been a lot of technical talk, bringing up WASM and other scripting potentialities, I'd like to point out that there might be a built in scripting language. I don't know what the right answer is, but at the same time the scripting autopilot got kind of dumped into MJ and then rotted and never improved, and that seems wrong. ![]() I can see obvious downsides to doing that as well as the internal API becomes public and breakages would require coordination, and some mods might have to be abandoned by the core API unless some LGG adopted them.Īt the same time it would allow customization of what MJ could do and the simplest plugin might only be data readouts without any autopilots. Then the core parts of MJ would provide core math support, core support for data from VesselState, core support for computing maneuvers, along with attitude control, the stagecontroller, thrustcontroller and common UI elements. Yeah if MJ3 or whatever was an explicitly modular framework so that the autopilots were external to the core codebase - allowing stuff like the rover/aircraft/landing/ascent/etc autopilots to be hosted "externally" and potentially managed by other developers that might be very interesting. This might be straying off topic, but its definitely difficult to jam experimental stuff like this into MJ right now.Ī MJ for KSP 2 would benefit from a more modular architecture instead of being monolithic (even if the current code has some modularity) But I think alglib now has a sparse convex QP solver that would be appropriate. That should lead you down the road of dealing with direct optimization and ~1,000x1,000 sparse matricies though. I have some Matlab code where I finally managed to get an optimal control approach working, but it took me years and would require implementing finite differencing (like Matlab's bvp5c) in C#, which alglib doesn't have, and I don't know if there's any battle tested implementations out there.Ī better approach for a launcher using very modern algorithms would probably use Picard Iterations or PIPG with convex optimization - which will be much less of a mathematical dead-end: That ascent won't be optimal in the mathematical sense, but it will be near optimal and should converge reasonably well without needing an overly precise guess, and the AoA constraint through the bulk of the atmosphere will nullify most of the highly nonlinear issues with the atmosphere.ĭoing full optimal control theory based ascents is probably the wrong approach and the mathematical approach in PVG absolutely fails to be able to deal with the atmosphere. Feed that into RKF45 or DOPRI45 and integrate that with a drag model and then feed the constraints on the terminal position into a nonlinear solver like the SQP method that alglib has now. What I would suggest these days for a simple launcher would be to model an ascent with a fixed heading and pitchover maneuver following a zero- AoA gravity turn (so two parameters there) followed by a fixed transition (altitude or something like that) to a bilinear tangent law of the form A + B t where those are vectors that determine the heading vector which is just the unit vector in that direction (so 6 parameters plus a normalization constraint on the magnitude of the 6-vector being equal to 1), plus the end time of the ascent as a final parameter. Yeah doing something like PVG on kOS wouldn't work because its too slow for numerical methods like that. PS: Maybe we should take that discussion to a different thread as it isn't about MechJeb per se? Tried to implement it in kOS, even, but gave up after I realized I would have to a) port all the math libraries from matrix multiplication on up and b) the kOS VM is at least and order of magnitude slower than a "simple embedded system" anyway. I'm actually very interested in that as well, ever since I read a paper on a closed-loop generic atmospheric ascent guidance algorithm based on optimal control that claimed to be "implementable on a simple embedded system". ![]()
2 Comments
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |