<Qboid>
awang: I added the explanation for this acronym.
<awang>
!acr -add:GLOW Gross Lift-Off Weight
<Qboid>
awang: I added the explanation for this acronym.
<awang>
soundnfury: I didn't know about yarchive, but now I need to read it all
<awang>
lamont: I seem to have broken PEG again
<awang>
Pitch program has negative numbers
ferram4_ has quit [Read error: Connection reset by peer]
<awang>
Probably my fault since I may have been pressing launch into plane/window/etc. in the wrong order
<awang>
Also, question
<awang>
Does launching into planetary window also launch into the right plane?
ferram4_ has joined #RO
<lamont>
i have never done launching into planetary window
<lamont>
and always launched to plane of moon
<awang>
Never mind then
<awang>
And I can't launch into the plane of the Moon because Principia :(
<lamont>
interplanetary trajectories are currently very broken anyway
<stratochief>
I always shoot for a lunar plane orbit first, and ejections to other planets are usually fairly compatible with that
<awang>
Seems Venus is at a low inclination relative to the Cape, too, since MJ wants to launch to an initial heading of 120something degrees
<lamont>
realistically i don’t think that saves you a whole lot its likely a hyperoptimization, particularly compared to everything else wrong with the transfer planner
<awang>
What's a hyperoptimization? Launching to the right plane?
<awang>
And what's wrong with the transfer planner?
<awang>
Honest question
Senshi has quit [Read error: Connection reset by peer]
<lamont>
some KSP patched conics / trajectory projection issue that i don’t understand
<lamont>
it optimizes the projected directory down to a miss of nearly 0m but it never does an SOI transfer and the actual transfer misses the planet completely like its off by some very large dT
<lamont>
getRelativeVelocityAtUT is lying to me by a lot
<taniwha>
lamont: afaict, that's not a KSP function, unless you mean GetRelativeVel()
TM1978m has quit [Remote host closed the connection]
<soundnfury>
awang: :) once you've read yarchive, you'll (probably) know about as much as I do
<lamont>
including validting that when both orbits are around kerbol and target_orbit is the orbit of e.g. moho that i can drive either getTruePositionAtUT or getRelativePositionAtUT to zero and i do not get another SOI patch for an encounter and the resultant orbit doesn’t encounter moho, but it looks like a proper transfer orbit to moho, just for some reason out of phase
<lamont>
i’m suspicious that the `orbit.StartUT = t;` is doing something to make `orbit.getTruePositionAtUT(x[4])` off by t or something like that…
tty has joined #RO
<tty>
ARE YOU MAD THOSE NIGGERS ARE TRYING TO STOP TRUMP??
<tty>
EMERGENCY KKK AND NAZI COALITION MEETING IN #/JOIN
<tty>
ON FREENODE IRC SERVER --IRC.FREENODE.NET--
<tty>
FREENODE IS AWARE OF THE GROUP AND SUPPORTIVE BUT PLEASE
<SirKeplan>
can we just have a ban on 3 letter nicks?
<Bornholio>
lol
<SirKeplan>
ok bad idea
<SirKeplan>
:D
<Bornholio>
pap wpuld be sad
<lamont>
TheRealPap ✔
<Pap>
#FakePap
<Bornholio>
pap spacex is making me design my AC unit redundant Hoping i can post pics/cad render at least soon
<Pap>
awesome
<awang>
lamont: I'm seeing some odd inaccuracy with PEG
<awang>
Targeted 185km x 185km, got 310.725km x 155.322km
<awang>
It was a due east launch, so non inclination shenanigans involved
<awang>
~2.5 minute first stage, second stage burn was ~5 minutes
<awang>
Second stage started at ~0.45 TWR, ended at 2.14
<awang>
s/non/no
<Qboid>
awang meant to say: It was a due east launch, so no inclination shenanigans involved
<lamont>
my guess is thrust integrals or J^2 of Earth in Principia
<awang>
Is J^2 that significant?
<lamont>
although i would think J^2 wouldn’t matter as tgo approaches zero
<awang>
I also used a pretty slow pitch program
<lamont>
i think that is more for coasting IDK
<awang>
0.6 degrees/sec
<awang>
So second stage started its burn at ~95km, apoapsis ~215km
<lamont>
that is usually about what i test with
<awang>
Have to do that because with a faster pitch program the second stage doesn't provide enough thrust to keep stable against aerodynamic forces
<awang>
Oh, really?
<awang>
I've been using 0.9 deg/s
<lamont>
uh that’s quick
<awang>
Although that's with roughly 5 minutes to orbit, so that might explain that
<lamont>
yeah i typically use 0.4 to 0.7 ish
<awang>
Oh
<awang>
I guess I've been spending too much time with low time to orbit launchers
<lamont>
even with a titan-2-esque launch i usually don’t go beyond 0.7
<xShadowx>
............so i think we should reconsider this whole free speech idea :P
<xShadowx>
some ants just need to meet a shoe
<lamont>
freeze peaches only applies to the government
<lamont>
okay after writing that whole wall of text to taniwha i think i just fixed the transfer planner
<lamont>
think it was the orbit.StartUT = t line that was buggy and i was getting trolled by a Mun encounter
<awang>
Hmmm
<awang>
lamont: Is autopilot with PEG ever supposed to go into "Unguided Gravity Turn"?
<lamont>
yeah, if you do “start PEG after KSP stage” it definitely does, also if PEG can’t find a solution it may
<lamont>
from the code it looks like that is the only time
<awang>
Oh jeez
<awang>
I had that enabled and didn't even realize it
<awang>
My bad
<lamont>
also looking at the code, if you see negative degrees that means that peg was not in PegStatus.CONVERGED
<awang>
Must have clicked by accident
<awang>
Hmmm
<lamont>
i need to expose that better up front still, but the only way that happens now is peg isn’t stable
<awang>
Would PEG not updating at all also fit that?
<lamont>
not updating? that’s odd
<awang>
I assumed that was why I was getting into negative degrees
<awang>
The PEG pitch wasn't changing at all
<lamont>
yeah that sounds like its not even running at all, so yeah, it would never become converged
<awang>
Hmmm
<awang>
idk then
<awang>
I want to say that tgo may have been counting down
TM1978m has joined #RO
<awang>
But I'm not certain
<lamont>
yeah i cleaned up the state machine inside the controller but i really need to expose that properly in the UX
Wetmelon has quit [Ping timeout: 186 seconds]
<awang>
Tried another launch, got 267x169
<awang>
PEG seems to be missing the point where the vessel "falls" back to the target altitude
<awang>
So it's still burning when the vessel drops down below 185km
<awang>
Also seems to be burning with a pitch near 0 degrees at upper stage ignition
<awang>
So like it's overestimating how much speed it's going to get
<awang>
Then trying to pitch up when it falls short
<taniwha>
lamont: yeah, I suspect StartUT is messing things up.
<taniwha>
or at least the initialization of it
<awang>
soundnfury: Was it you that had issues with yellow planets?
<taniwha>
lamont: however, its only use in Orbit seems to be GetTimeToPeriapsis
<lamont>
awang: yeah that sounds like thrust integrals
<lamont>
and yeah, taniwha i think that was doing something. that was just a hack since otherwise orbit.StartUT is zero and the loop wants to use that, so i just unrolled it a bit so that the first PatchedConics.CalculatePatch call uses t then it uses orbit.StartUT after that.
<lamont>
i’m still seeing one transfer to moho having issues, but everything else seems to work well
<lamont>
(and there’s a mun encounter on the way out that may be messing things up)
<lamont>
oh is it possible i’m exceeding the number of conics?
<lamont>
no, CONIC_PATCH_LIMIT = 6 doesn’t help
<taniwha>
/maybe/, but placing maneuver nodes resets the counter
<lamont>
yeah but my transfer orbit start kerbin, has a mun SOI, then back to kerbin, then sun, then its supposed to be moho
<lamont>
so the sun orbit is the 4th conic past the burn, the moho one would be the fifth
<lamont>
although in the calculationi don’t see the mun encounter either so that’s weird too
<lamont>
i think the code just hates moho
<taniwha>
there is one possibility: the solver is failing to find that orbit intersect
<awang>
lamont: Anything I can do to help the thrust integrals out?
<lamont>
nope
<awang>
lamont: Also, does PEG allow for specifying argument of periapsis?
<awang>
Even if it requires a coast phase
<lamont>
heh yeah
<lamont>
sorta
<lamont>
the node executor does arbitrary orbit targeting
<taniwha>
lamont: unfortunately, my newer code /does/ have problems with close roots (ie where the orbit intersects are too close: it loses one)
<taniwha>
I didn't have the time to fix that, unfortunately :(
<awang>
But PEG doesn't hook into the node executor, does it?
<lamont>
awang: yeah it does, the code you’re using has PEG for doing node burns (part of the reason why i want to get the interplanetary transfer planner fixed is to watch PEG do accurate finite burns to interplanetary trajectories)
<awang>
Oh wow
<awang>
I wasn't aware PEG was capable of such things
<awang>
I thought it was pretty much for ascent only
<lamont>
taniwha: i’m not quite parsing “close roots” or “orbit intersects are too close”
<taniwha>
lamont: roots of the polynomial that gives you the closest and furthest points between the two orbits
<lamont>
yeah, you keep trying to turn it into a trajectory optimizer, but its really all about finite burns
<lamont>
ah
<lamont>
i’m not using that API
<taniwha>
you are
<taniwha>
by using patched conics
<lamont>
oh, you mean the intersection of the ship orbit with the mun orbit
<awang>
I'm tempted to start learning whatever maths are necessary to try implementing those more interesting papers
<taniwha>
lamont: yeah
<awang>
But then I try to read the papers and give up :(
<lamont>
yeah they’re hard papers
<lamont>
okay, but why after putting the maneuver node down, does the core KSP code accurately find the mun encounter but the MJ code doesn’t?
Shoe17 has quit [Quit: Connection closed for inactivity]
<awang>
lamont: Why can't they be easy? It's like it's rock---...
<awang>
Oh
<awang>
Right
<lamont>
rocket surgery
<lamont>
i think i almost understand primer vector theory, but i kind of need a simple problem to solve with it first
<lamont>
i might be able to replace the thrust integrals with an rkf45 integrator which would make PEG a lot better and would be a step in that direction, but modifying PEG can be weird (c.f. jaggers thrust integrals failures)
<awang>
What kind of math do I need to learn to understand this?
<awang>
I don't even know where to start
<awang>
Do you know why the jaggers thrust integrals failed?
<lamont>
graduate level calculus of variations
<awang>
Seems odd if they were the subject of a paper but didn't help
<awang>
....Wonderful
<lamont>
i suspect the space shuttle flew with different thrust integrals (the one in the technical note i cant track down) and not the jaggers ones because they were unstable, but that information is lost in the late 70s
<awang>
Ah, I see
<awang>
Have you tried contacting Draper lab and/or the author?
<awang>
If you haven't, I'll get around to writing an email
<lamont>
yeah i tried pinging them
<lamont>
i seem to be bad at social engineering
<lamont>
i just get /dev/null
<awang>
Hmmm
<awang>
I'm really not that good, either
<awang>
But it might be worth a second shot
<lamont>
go for it
<awang>
Wonder if a .edu domain might help
<lamont>
tfill@draper.com might be Thomas Fill who wrote the paper
<soundnfury>
awang: yes, it was me that had yellow planets
<Qboid>
[#130] title: Textures of Planet Packs Using Kopernicus are all Yellow | I am using KSP version 1.1.2, and have installed several planet packs that use kopernicus. Attached is a screenshot of the mods I'm using.... | https://github.com/Kopernicus/Kopernicus/issues/130
<awang>
lamont: Alright, thanks! I'll let you know if I get a response
<soundnfury>
converting all the DDS to PNG works around it
<awang>
soundnfury: Yep, that's exactly what my planets look like
<awang>
I'm on mac, though
<awang>
And I could have sworn that it was working for me previously