egg|zzz|egg changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Clifford. We currently target 1.2.2, and 1.3.1. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/
<egg|anbo|egg>
the Δv countdown thing is tricky, because implicitly or explicitly it's just guidance, which means you need some sort of definition of what the goal of your manoeuvre is and what metric you minimize wrt that
<awang>
Stock maneuver nodes are designed for Project Orion ships?
<egg|anbo|egg>
maybe you can fudge it a bit, and just do some easy residual wrt the planned trajectory? maybe not? but it requires a few lunations of investigations probably
<egg|anbo|egg>
awang: specifically with dial-a-yield single-impulsion manoeuvres
<awang>
egg|anbo|egg: Maybe steal lamont's PEG code and use that somehow?
<awang>
"somehow" is left as an exercise for the implementor :P
<awang>
idk how PEG is used for MJ's node executor though
<UmbralRaptor>
Hah
<egg|anbo|egg>
probably can't steal lamont's code because license, wouldn't want to anyway, it would all have to be rewritten in Principialand (and I could just look at the ORIGINAL FOR A REFERENCE IMPLEMENTATION ANYWAY)
<awang>
Oh, there's a reference implementation?
<egg|anbo|egg>
I also have an easy feature request from lamont
<Qboid>
[#1659] title: Need Principia analog of UpdateFromStateVectors() + GetOrbitalStateVectorsAtUT() | To do accurate state vector projection this would be useful, and would be very useful for things like PEG. The general problem is to take state vectors (r0, v0) at t = now and integrate them forward to (r1, r1) at t = now + deltaT (not under thrust).... | https://github.com/mockingbirdnest/Prin
<Qboid>
cipia/issues/1659
<awang>
brb, nomz
<egg|anbo|egg>
PRECISE PREDICT
<egg|anbo|egg>
there's a logic flow diagram on page 75
<awang>
Oh huh
<awang>
That looks surprisingly simple
<egg|anbo|egg>
awang: I mean that's just precise predict, which is one subroutine in the whole mess (and beware the calls that are other subroutines on other pages)
<awang>
True
<awang>
I'm tempted to try reading the entire thing, but there's an intimidating amount of math there >_>
<GregroxMun>
egg what's with atmospheres not doing n-body
<GregroxMun>
wait no
<GregroxMun>
I had a more important issue
<GregroxMun>
when are planets gonna have orbit trajectories that makes sense?
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
NathanKell|Twitch is now known as NathanKell
NathanKell is now known as NathanKell|Twitch
icefire has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
armed_troop has quit [Quit: Bye]
armed_troop has joined #principia
technicalfool has quit [Ping timeout: 207 seconds]
<lamont>
egg: i half suspect that my PEG node executor in the new PEG code will fix that problem for Principia
<lamont>
the PEG code ignores the maneuver node itself and targets the orbit on the other side of the maneuver node
<lamont>
that’ll be the keplerian osculating orbit but as long as that doesn’t diverge substantially by the end of the finite burn, it’ll be fine
<lamont>
i just got home, and i’m going to fire up principia right now and see if it works that way or not
<lamont>
the principia prediction and the patchy conics are fairly wildly off
Mike` has quit [Ping timeout: 198 seconds]
<lamont>
the thing is that when PEG executes a burn i can see that it does a burn in that direction with that much dV (plus a 3-4 dV for finite burn effects, but that doesn’t matter much) and then i wind up on an orbit much more similar to the patchy conic orbit
<lamont>
i’ve also done another maneuver where i wasn’t doing it all in Kerbin-Mun barycentric and did all the work in KCI and looks the same
<lamont>
as far as i can see i’m executing the planned maneuver with 3-4 dV of the plan but winding up nowhere close to the plan
<lamont>
and simply visually the patchy conic orbit should look like a tangent oscullating orbit of the principia prediction and it does not look like a tangent orbit
NathanKell is now known as NathanKell|Twitch
Mike` has joined #principia
CommandoDiamond has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
<lamont>
oh possibly my save is hella borken from ancient principia versions...
<lamont>
nope happens in a fresh save
NolanSyKinsley has quit [Remote host closed the connection]
<lamont>
wait the osculating orbit changes like crazy, what...
<lamont>
nuking my save and starting over seems more sane
<lamont>
but still wonky
<lamont>
so, i think if you make the node.nextPatch stop doing wonky time varying whatever it is…
<lamont>
and it looks like the direction of the node simply rotates on the navball (like when you’re half an orbit behind it, its 180 degrees ish wrong on the navball)
<lamont>
if you fix that so that the maneuver node you put on the navball works properly and doesn’t dance around then PEG-MJ should be able to execute those nodes
NathanKell|Twitch is now known as NathanKell|AFK
<egg|phone|egg>
Lamont: inertially fixed is not checked
<egg|phone|egg>
So the marker is fixed in the frenet frame so it can serve as guidance
<egg|phone|egg>
Not sure what I can do there
<lamont>
fixed in the frenet frame?
<lamont>
can i just check inertially fixed and it’ll work?
<egg|phone|egg>
Well, the predicted trajectory will be poor then
<lamont>
hrm well its bedtime
egg|cell|egg has joined #principia
egg|phone|egg has quit [Ping timeout: 207 seconds]
<lamont>
inertially fixed is close
<lamont>
the orbit that i get out of it is close to the prediction
<lamont>
419 km periapsis at the Mun instead of 500 km
egg|cell|egg has quit [Ping timeout: 182 seconds]
egg|phone|egg has joined #principia
egg|cell|egg has joined #principia
egg|mobile|egg has joined #principia
egg|cell|egg has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
egg|phone|egg has quit [Ping timeout: 207 seconds]
xShadowx|2 has joined #principia
Dazzyp has joined #principia
Daz has quit [Ping timeout: 207 seconds]
Dazzyp is now known as Daz
xShadowx has quit [Ping timeout: 207 seconds]
egg|phone|egg has joined #principia
egg|mobile|egg has quit [Ping timeout: 186 seconds]
egg|phone|egg has quit [Read error: Connection reset by peer]
egg|phone|egg has joined #principia
awang has quit [Ping timeout: 182 seconds]
awang has joined #principia
<awang>
lamont: Might the difference between the predicted patched conic trajectory vs that from Principia come from the instantaneous burn assumption?
<awang>
When PEG executes the Principia node, does it do the half-before half-after approach it uses for stock maneuver nodes?
<awang>
Then there's the inertially fixed thing that egg mentioned
<awang>
And at least for Principia the frame that the maneuver is executed in can differ from the frame used for plotting trajectories
<awang>
So that could be why executing the burn in KCT vs KMB didn't affect anything
<awang>
Because the maneuver's frame was the same
<awang>
Unless you were changing the maneuvering frame
<awang>
In which case idk
NolanSyKinsley has joined #principia
awang has quit [Ping timeout: 186 seconds]
awang has joined #principia
Jesin has joined #principia
<lamont>
awang: changing the plotting frame / maneuvering frame doesn’t really seem to change anything
s_ has joined #principia
s_ has left #principia [#principia]
<egg|anbo|egg>
awang: lamont's issue is just that the burn is fixed in the Frenet frame if it's not inertially fixed
<egg|anbo|egg>
so the guidance is fixed in the Frenet frame
<egg|anbo|egg>
so half an orbit before the burn it's backward
<egg|anbo|egg>
it tracks the Frenet frame
<lamont>
that seems reasonably useless to everyone?
<lamont>
like for users trying to execute the burn manually the navball direction is going to be wrong, and it looks like its wrong in particular at t minus burntime / 2 when you need to start burning
<egg|anbo|egg>
lamont: no, the point is that you set guidance to "follow the node"
<egg|anbo|egg>
then you burn on schedule, and that's open-loop guidance for the burn
<egg|anbo|egg>
since the burn direction changes, the node moves
<egg|anbo|egg>
whereas the inertially fixed burn does not, as its name indicates (but it's less efficient)
<lamont>
ehm wut
<lamont>
you’re modelling finite burns?
<egg|anbo|egg>
well yes
<egg|anbo|egg>
that's the whole thing with the flight planner
<egg|anbo|egg>
it integrates
<egg|anbo|egg>
it integrates the burn too
<awang>
lamont: Interesting... I would have expected changing the maneuvering frame would change something at least
<awang>
Since non-inertial burns are relative to the markers on the navball, approximately
<awang>
lamont: Finite burns are why that guy on the forums was complaining :P
<awang>
Well, sort of
<lamont>
so i’m not sure you’re doing an optimal finite burn
<lamont>
and generally you can plan impulsive burns and rely on something like PEG to execute them with finite burn effects
<awang>
What do you mean by not doing an optimal finite burn?
<awang>
And I didn't know about PEG sort of compensating for finite burn effects
<awang>
Although the burn start time might have to be tweaked at the very least?
<lamont>
PEG is a finite burn algorithm. you tell it when to start and give it a target and it figures out the most efficient burn to wind up on the target.
<lamont>
PEG can’t tell you when to start the burn though, need a proper trajectory optimizer to do that
egg|cell|egg has joined #principia
<lamont>
okay it looks like if i turn off principia’s finite burn effects and use inertial i think it’ll work. although i hit a PEG bug where it shut off my engines halfway through the burn, so i have some other bug to fix first
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|phone|egg has quit [Ping timeout: 198 seconds]
egg|phone|egg has joined #principia
<awang>
lamont: Interesting, didn't know PEG was that general
<awang>
Although it seems that defining the target could be interesting for the more complex n-body trajectories
CommandoDiamond has joined #principia
<Mike`>
not sure if this is caused by principia, but have the following reproducible crash: i had a probe on impact course with earth, i switched to KSC and did a 10 million timewarp. The game hard-crashed, and i get no crash folder and no error in ksp.log
<Mike`>
principia logs give me a bunch of these failed checks with a trace: F0129 21:11:44.032804 32668 fit_hermite_spline_body.hpp:85] Check failed: tail.size() < samples.size() - 2 (9999 vs. 9999)
<Mike`>
when i reduce the warp speed to 1 million everything seems to be fine, so not even sure if this could be called a bug. :)
<Mike`>
in ksp.log i get "[WRN 21:11:40.323] [F: 2960161]: Vessel R-1 Debris crashed through terrain on Earth." plus "Vessel was destroyed."
<awang>
I'm pretty sure "check failed" indicates a crash from Principia
<awang>
That's an interesting crash, since it's similar to one I reported a while back that should have been fixed
<awang>
Mike`: I just remembered, a complicating factor is that my game runs at a super low framerate
<awang>
That might explain why I could crash with a lower framerate
<Mike`>
yes, i'm using clifford
<awang>
Huh
<awang>
I should check my own save
<awang>
Thought it was fixed
<awang>
It'll be a bit though
<awang>
Still at work
<GH>
[Principia] aw1621107 opened pull request #1702: Fix error reported by Clang (master...patch-2) https://git.io/vNSje
Jesin has quit [Quit: Leaving]
<Mike`>
awang, journal?
egg|phone|egg has quit [Ping timeout: 182 seconds]
egg|phone|egg has joined #principia
egg|cell|egg has joined #principia
egg|phone|egg has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
egg|phone|egg has joined #principia
egg|phone|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has quit [Ping timeout: 207 seconds]
<egg|anbo|egg>
lamont: but even with inertial, it's finite burn
<lamont>
you have a button to turn off finite burn effects
<egg|anbo|egg>
lamont: there's no non-integrated option
<egg|anbo|egg>
lamont: what kind of thing can the PEG target orbit be
<egg|anbo|egg>
lamont: e.g. can it be strongly influenced by J2?
<egg|anbo|egg>
lamont: could it be an arbitrary trajectory?
<egg|anbo|egg>
lamont: ah, there's the "instant impulse" thing, yeah
<lamont>
yep, that is the thing i needed
<lamont>
you’re trying to be too helpful with finite burn modelling
<egg|anbo|egg>
lamont: this seems like an extremely unsatisfactory path though, you knd of undo all that the flight plan brings and basically just do stock instant impulses
<lamont>
but you don’t. PEG does the finite burn and will wind up on your planned trajectory
<egg|anbo|egg>
for PEG yes, but life is not high-energy low orbit
<lamont>
that’s the whole point which is that you’ve got an unpowered reference trajectory that you want to wind up on
<lamont>
even so, in reality you have deviations in your trajectory due to unmodelled bits of reality (venting, solar wind, your thrust isn’t going to be perfectly controlled, etc)
<egg|anbo|egg>
yes, but to set up a *possible* reference trajectory, doing it by instant impulses from the actual is a poor choice
<awang>
Mike`: It's something to help egg trace what Principia was doing
<egg|anbo|egg>
lamont: I'm aware, yes
<awang>
There should be an option to record a journal in the Principia window accessible in the space center scene
<egg|anbo|egg>
lamont: I even document it :-p
<Mike`>
awang, ah, thanks.
<awang>
Mike`: It should be under a logging-related menu or something
<lamont>
the biggest problem is going to be areas where the keplerian approximation deviates significantly from the n-body integrated orbit over the course of the burn
<awang>
You technically don't need to be in the space center to enable journaling
<egg|anbo|egg>
lamont: but anyway, the point is, I think the correct way forward would be to pick up the *post-burn* trajectory as a reference, *not* to restrict the features of the flight plan to those that stock already provides
<awang>
But you have to switch scenes
<awang>
e.g. go from flight to editor, or from space center to mission control, etc.
<lamont>
yeah fair enough
<awang>
You'll see a JOURNAL.<timestamp> file in glog/Principia, next to the INFO.<timestamp> and other files
<egg|anbo|egg>
lamont: what kind of "reference trajectory" does PEG want
<lamont>
i’m somewhat unconvinced that players are really going to hit a lot of those orbits though
<awang>
It should be a fairly large text file with lots of hexadecimal digits
<lamont>
the keplerian tangent orbit at the end of the burn is what it uses now
<egg|anbo|egg>
its' going to be extremely counterintuitive if you have to ignore half the flight plan features to use MJ
<egg|anbo|egg>
lamont: no, I mean in principles, what can it take
<egg|anbo|egg>
can it take something nonkeplerian
<lamont>
yeah
<egg|anbo|egg>
okay
<egg|anbo|egg>
that's good
<egg|anbo|egg>
so really what you need is an entry point "gimme the trajectory after this burn and I'll find something for you"
<lamont>
i’m doing something vaguely gross to take PEGs predicted burnout position, project it into the plane of the orbit, then take the position and velocity of the orbit that vector is pointing “at” (PEG’s burnout might be high or low at that point) and then those values get used
<lamont>
“gimme the trajectory ‘near’ this point” where ‘near’ needs to converge to ‘where i’ll be’ after running through PEG a few times
<lamont>
that’ll probably give you headaches until you realize it doesn’t have to be precise it just needs to converge
<GH>
[Principia] MikeOnTea opened issue #1703: Crash during very high timewarp at space center https://git.io/vN9Uy
<egg|anbo|egg>
lamont: hmm
<egg|anbo|egg>
lamont: so then just the DOF in the post-burn trajectory whose position is (locally) closest to the given point in <some frame>?
<lamont>
at every step in that algorithm there’s a bit of a headache
stratochief has joined #principia
<lamont>
rp = rp - Vector3d.Dot(rp, iy) * iy;
<Mike`>
awang, thanks, won't do it today though, need to sleep. :)
<lamont>
that projects the burnout location into the plane of the target orbits tangent (iy = -orbit normal)
<lamont>
(orbit normal is a function of time in principia of course, and i’m not positive what the time will be)
<egg|anbo|egg>
ok so I'm confused as to what kind of function you need
<egg|anbo|egg>
I could just give you the whole iterable planned trajectory post-burn but that might be overkill
<lamont>
then i do some gross stuff which uses the true anomaly / angle from periapsis in order to pull the pos, vel off of the orbit at the true anomaly that rp is pointing "at"
<lamont>
i just need the pos and vel off of the post burn trajectory at the point which is closest to ‘rp’ (which is an abitrary vector, not necessarily in the plane or the radius of the orbit)
<lamont>
the true anomaly / periapsis stuff there is just a distraction
<egg|anbo|egg>
lamont: good thing it's not necessarily anything, because the plane of the orbit is meaningless to me :-)
<lamont>
consider rp.normalized which is a unit vector that i’ve projected into the plane of the orbit. i need the (pos, vel) off of the orbit that it is pointing at.
<lamont>
right righ
<egg|anbo|egg>
lamont: so, question (which applies to both your entry points), are you OK with using reflection to get one thing from the Principia C# adapter (namely the pointer to the Plugin object)? I really don't want to go the route of hiding a turd under a static rock for an entry point to find
<lamont>
yeah we already use reflection to talk to real fuels and shit
<lamont>
(and FAR)
<egg|anbo|egg>
ok
<egg|anbo|egg>
no need for static turds then :-)
<lamont>
i know how to write stuff so that it should turn into a fast boolean NOP check for non-principia users, and can memoize as much reflection as possible from tick to tick
<lamont>
there’s a possible problem with the “closest” point on a trajectory from another point not being a single point in princpia i imagine
<lamont>
for that i would say take the first point that isn’t in the past
<lamont>
and hopefully it converges so that the double-valuedness goes away as an issue
<lamont>
and if it does not
<egg|anbo|egg>
so there will never be a *single* one (if you predict two orbits you're screwed)
<lamont>
then you’ve got a legimiately non convex optimization problem
<egg|anbo|egg>
now finding the first one is technically tricky (what if you have tiny oscillations, etc.)
<lamont>
so maybe not first
<egg|anbo|egg>
in practice, walk the trajectory with a well-chosen timescale, same as what we do for apsides
<egg|anbo|egg>
that will do the job just fine
<lamont>
yeah it would have a natural timesacle of the time of the burn
<egg|anbo|egg>
(the well-chosen timescale is just "whenever there's a point on the discrete trajectory" anyway
<egg|anbo|egg>
it works for our apsides and closest approaches to target, should work for you
<lamont>
we should know the timescale within a percent or two for this problem
<lamont>
yeah should be very similar
<lamont>
anyway, it might be screwy due to being very far away from the solution — consider an ideal circular orbit at the equator where the burnout point is above the north pole. in that case pick any point on the circular orbit and start making progress towards it, and eventually it will converge to something sensitble later.
<lamont>
(not that PEG would ever do something quite that idiotic, but certainly non converged cases could be somewhat pathological, and it just needs a halfway reasonable guess to move towards convergence)
<lamont>
in that case if you pick t = now then it would start working against that point on the orbit and would just hunt forwards until it found the real solution
<GH>
[Principia] eggrobin commented on issue #1659: Additional endpoint that @lamont-granquist would like for guiding with respect to the flight plan:... https://git.io/vN9IJ
EricSan has joined #principia
<EricSan>
Hello, is there any way to use principia to allow the use of ion engines in timewarp?
<egg|anbo|egg>
not yet, we'd like to add that feature (also atmospheric drag) but those are in the far future probably
<GH>
[Principia] lamont-granquist commented on issue #1659: yeah q is body-centered-intertial. and i need the unpowered target orbit without any finite burn effects, and would need the unpowered orbit solution for times potentially before the end of the burn.... https://git.io/vN9LE
<lamont>
i wonder if PEG can work for ion engine orbits or not, i don’t know how they implement those kinds of trajectories
<EricSan>
thats too bad, but im not surprised as that sounds very complex!
<egg|anbo|egg>
lamont: hmm I'm confused by your comment
<lamont>
k
<lamont>
which part?
<egg|anbo|egg>
lamont: so I need to back-integrate the unpowered orbit from the end of the finite burn?
<lamont>
yes
<egg|anbo|egg>
"without any finite burn effects, and would need the unpowered orbit solution for times potentially before the end of the burn.
<egg|anbo|egg>
" << this part
<lamont>
yeppers
<egg|anbo|egg>
okay, that makes things a little tricky
<egg|anbo|egg>
(because I "just have" the planned coast, not so for its backintegration)
<GH>
[Principia] eggrobin commented on issue #1659: Ah, that makes things a little tricky, since we then need to integrate backward from the end of the burn; possible, but less off-the-shelf. https://git.io/vN9LF
<lamont>
yeah PEG may disagree with your prediction of burntime at first and may need to target the orbit at times before you’ve predicted the finite burn ends
<egg|anbo|egg>
yeah that makes sense
<GH>
[Principia] lamont-granquist commented on issue #1659: yes, so PEG does approximations that may very well converge to times before you've ended your finite burn simulation and started the coasting orbit. PEG will also start with guesses that are just 1 second ahead from where the burn starts (actually i start running PEG a few seconds before the burn is even supposed to start and just let it run). so it needs those negative timescales. https://git.io/
<awang>
Borked link?
<GH>
[Principia] lamont-granquist commented on issue #1659: so i'd like to grab this orbit object sometime early (like whenever the user pokes the 'execute node' button which might be days in advance). i will NOT want backpropagation to that timepoint. at some point i'll fire up PEG about 10 seconds before i want to burn. at that point i'll want backpropagation to "now", and will never need backpropagation to the past i think. https://git.io/vN9tB
<egg|anbo|egg>
lamont: wait, "orbit object"?
Rokker has quit [Quit: Connection closed for inactivity]
<egg|anbo|egg>
I wasn't describing an object here, just a function
<lamont>
okay, maybe i’m picturing it wrong then
<lamont>
i was assuming you’d hand me an object that i’d poke, rather than a global method
<egg|anbo|egg>
my idea is you get a function QP NextCoastPhaseDegreesOfFreedomNearest(Plugin* plugin, char const* vessel_guid, XYZ body_centred_inertial) (or maybe it returns a status and writes the QP to some out parameter)
<egg|anbo|egg>
lamont: giving you an object means I need to guarantee lifetimes to a third party across the interface which sounds like a nightmare
<lamont>
oh
<lamont>
C++
<lamont>
i’ve gotten so lazy with languages that have garbage collectors
<lamont>
yes
<lamont>
i need the velocity as well though
<lamont>
so qp, vp or something as output parameters?
<egg|anbo|egg>
QP is our interface type for "two XYZ"
<egg|anbo|egg>
XYZ is our interface type for "three doubles"
<lamont>
ah gotcha
<lamont>
then yes that would be fine, i can bust that up into what i need
<egg|anbo|egg>
yes we have good names, but that's precisely because the interface has weak C typing
<egg|anbo|egg>
on the C++ side we turn the QP into a DegreesOfFreedom<SomeFancyFrame>
<GH>
[Principia] lamont-granquist commented on issue #1659: oh yes, C++ and garbage collection -- forget i mentioned object handles. https://git.io/vN9tx
<awang>
egg|anbo|egg: Weak C typing?
<egg|anbo|egg>
well, C typing
<egg|anbo|egg>
no fancy quantities
<awang>
Where?
<egg|anbo|egg>
just double
<egg|anbo|egg>
in the interface
<awang>
plugin_adapter?
<awang>
Or plugin?
<egg|anbo|egg>
(that code isn't even checked in, it's generated from the journal proto; it's also journalled)
<awang>
Oh, so this is what you use to communicate between the C++ and C# side of things?
<egg|anbo|egg>
yes
<lamont>
i fear i’m going to need to build something similar in MechJeb at some point
<egg|anbo|egg>
all the P/Invoke declarations and extern "C" CDECL DLLEXPORT header declarations are generated from that protobuf
<egg|anbo|egg>
(as well as the code that journals and replays the journal)
<lamont>
to start with you integrate [ x , v ] as state which is a 6-vector and then costate is [ pv, pr ] which is another 6-vector, which is often treated as one 12-vector which then needs the mass state and any coast and burn times to be optimized joined to it to result in 13+ variables of integration minimum
<awang>
So I'll need to dig around in there for the flight planner changes I have lined up
<awang>
Looks fun
<awang>
Never had to play with protobuf code before