UmbralRaptop changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Fuchs. We currently target 1.5.1, 1.6.1, 1.7.x, 1.8.1, and 1.9.1. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly… | <egg> also 4e16 m * 2^-52 is uncomfortably large
<discord-> l​amont. — no but if you change 102 to be principia-aware and look at maneuver-node-in-the-future that takes care of it
<discord-> e​gg. — ah, right
<discord-> e​gg. — node-in-the-future is a harmless condition for stock too
<discord-> l​amont. — not really though? you can fly past a node in stock and still execute it because stock is insane.
<discord-> e​gg. — oh right you start before the node in stock
<discord-> e​gg. — so things start with the node in the future
<discord-> l​amont. — yeah and then it burns down weirdly and i think it can absolutely wind up in the past under certain circumstances
<discord-> e​gg. — so then, line 102 needs to check node-in-the-future if Principia, and 108 needs to work for one pnode
<discord-> e​gg. — and then it kind of falls into place I thnik?
<discord-> l​amont. — yeah
<discord-> l​amont. — i'm a bit busy right this second tho
<discord-> e​gg. — hah
<discord-> l​pg. — I'm getting the impression this won't work with 'instant impulse' mode?
<discord-> l​pg. — ("this" = the principia node executor in general, not the fix being discussed)
UmbralRaptop has quit [Remote host closed the connection]
UmbralRaptop has joined #principia
<discord-> e​gg. — Indeed.
<discord-> e​gg. — Instant impulse is a bit of a kludge
<discord-> e​gg. — (understatement)
<discord-> e​gg. — we should really have something for SRBs though
<discord-> e​gg. — bit of a mess if you have multiple SRBs with different burn times though
<discord-> e​gg. — and also bit of a mess if you have to deal with thrust curves
<discord-> e​gg. — so things being messy we have quietly ignored them
<discord-> l​pg. — the apparent lack of consideration for slow-ignition engines (i.e basically all engines in RO) is more concerning to me
<discord-> l​pg. — my own half-assed krpc executor takes a 'lead time' parameter, so it can know to start the burn 1, 2, 3 seconds before the node says
<discord-> l​pg. — my own half-assed krpc executor takes a 'lead time' parameter, so it can know to start the burn 1, 2, 3 seconds before when the node says (edited)
<discord-> A​mpersand. — (meanwhile at least in my Mechjeb install it usually waits like ten seconds after the node before lighting)
<discord-> l​pg. — ullage? (I punted on _that_ one. see also: half-assed)
<discord-> e​gg. — @Silavite @lamont https://github.com/MuMech/MechJeb2/issues/1276 so this doesn’t get lost in the backlog
<discord-> S​ilavite. — Thanks!
<discord-> S​ilavite. — I should elaborate a little bit more on this case.
<discord-> e​gg. — @Silavite note that in the meantime, using MechJeb to execute nodes should work fine if you have a single manœuvre planned
<discord-> A​mpersand. — It waits several seconds after the node before attempting ullage
<discord-> e​gg. — well, that is MechJeb not knowing about ullage issues
<discord-> S​ilavite. — The engine does stop running after the first node finishes. The spacecraft then reorients to the second node before starting the engine again (I was using the XLR81 which doesn't need ullage, so I don't know how ullage factors into this). Once the engine begins firing again, it continues to do so until fuel exhaustion.
<discord-> e​gg. — Yes, I understand, that is what we were discussing with lamont
<discord-> S​ilavite. — Ah, apologies.
<discord-> e​gg. — what happens is that Principia uses a single stock node, and just teleports it into the future
<discord-> e​gg. — MechJeb ignores that change, and keeps steering to it, not noticing that the manœuvre is done
<discord-> e​gg. — @Silavite I think your engine shutdown is just the MechJeb execution logic detecting that it is pointing backward, so that burning would be counterproductive, and thus shutting down until it is pointed the right way
<discord-> S​ilavite. — That sounds sensible. I'll try putting two nodes such that their vector directions are aligned and see how that behaves.
<discord-> l​amont. — @lpg in general the burntime/2 estimate is off by more than the spool-up time of the engine anyway
<discord-> e​gg. — yeah the spool-up is much more visible with the Principia thing being open-loop with a hard stop
<discord-> l​pg. — ^
<discord-> l​amont. — well i mean you've had that node executor now for all of a week?
<discord-> l​pg. — hey I'm not complaining 🙂 I haven't even gotten around to trying it out. just bringing up a possible oversight
<discord-> e​gg. — works wonderfully in stock which is all I have tried
<discord-> e​gg. — but tbh with open-loop and unmodelled things like spool-up (even if you took that time into account, some thrust occurs there), you are never going to get something very nice
<discord-> e​gg. — Principia is not going to model spool up anytime soon (SRBs sound messy enough and we have yet to get to them)
<discord-> e​gg. — and closed-loop Principia guidance sounds like a right mess, we would need a mechanism to define what you want to optimize, and then MechJeb would need to talk to us to check that...
<discord-> l​amont. — its better not to model spool up and just use closed-loop
<discord-> l​amont. — "the missile knows where it isn't"
<discord-> e​gg. — yeah, but closed-loop is hard :D
<discord-> l​pg. — I've had pretty good results from a trial-and-error'ed 'this engine needs about this much lead time' hand-entered lead time. I don't have a good suggestion of how to translate that into something user-friendly
<discord-> l​pg. — I've had pretty good results from a trial-and-error'ed 'this engine needs about this much lead time' hand-entered value. I don't have a good suggestion of how to translate that into something user-friendly (edited)
<discord-> e​gg. — yeah, the advantage with open-loop is that the missile need not know where it is at any time. It therefore need not know where it isn’t. In particular, it need not subtract where it is from where it isn’t, nor where it isn’t fom where it is, regardless of whichever is greater.
<discord-> S​ilavite. — So it doesn't need to obtain a deviation.
<discord-> l​amont. — it is a deviation
<discord-> e​gg. — closed-loop with Principia seems rather daunting
<discord-> e​gg. — do we have a viable guidance method based on multiple shooting?
<discord-> e​gg. — fancier things would mean a lot of optimization logic having to live in Principia code
<discord-> S​ilavite. — @egg Your hypothesis about the execution logic temporarily stopping the burn seems correct. I tested two (nearly) parallel nodes and it behaved as you predicted.
<discord-> l​amont. — i can't seem to ever dig myself out of launch rockets to actually get to node execution
<discord-> l​amont. — people keep on inventing stupid ways to break PVG
<discord-> l​amont. — (launches)
<discord-> e​gg. — hah
<discord-> e​gg. — I would love to have means to plan from launch
<discord-> e​gg. — but I have no idea how that would or should look like
Mike` has quit [Ping timeout: 190 seconds]
Mike` has joined #principia
egg|laptop|egg has quit [Remote host closed the connection]
egg|cell|egg has joined #principia
raptop has quit [Ping timeout: 378 seconds]
egg|cell|egg has quit [Ping timeout: 204 seconds]
Mike` has quit [Ping timeout: 204 seconds]
Mike` has joined #principia
<_whitenotifier-d13c> [Principia] gert7 commented on issue #2590: Vessels teleport/switch places upon EVA - https://git.io/JfaS3
<discord-> S​tandecco. — KSPTOT
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|cell|egg has joined #principia
<_whitenotifier-d13c> [Principia] gert7 commented on issue #2590: Vessels teleport/switch places upon EVA - https://git.io/Jfad8
egg|laptop|egg has joined #principia
raptop has joined #principia
<_whitenotifier-d13c> [Principia] eggrobin labeled pull request #2589: Use the Status message in the exceptions returned from the external interface - https://git.io/Jfaq5
<discord-> D​amien. — Ksptot compatibility collaboration project with arrowstar when
<discord-> D​amien. — Ksptot compatibility project collaboration with arrowstar when (edited)
<_whitenotifier-d13c> [Principia] pleroy closed issue #2585: principia.journal.serialization.Status should have a message - https://git.io/Jfz0v
<_whitenotifier-d13c> [Principia] pleroy closed pull request #2589: Use the Status message in the exceptions returned from the external interface - https://git.io/Jfaq5
<_whitenotifier-d13c> [Principia] pleroy pushed 2 commits to master [+0/-0/±4] https://git.io/JfabC
<_whitenotifier-d13c> [Principia] pleroy f5118d9 - Use the Status message in the exceptions returned from the external interface.
<_whitenotifier-d13c> [Principia] pleroy b7bfa89 - Merge pull request #2589 from pleroy/2585 Use the Status message in the exceptions returned from the external interface
egg|cell|egg has quit [Ping timeout: 189 seconds]
<discord-> J​ulexus Quandem. — Is this telling me that I'm going to crash into the moon in 44 and a bit days?
<discord-> e​gg. — hm
<discord-> e​gg. — it is not saying that directly, but 44 < 49 so I suppose that might be a hint that something is amiss
<discord-> e​gg. — does it fail to give you a longer analysis?
<discord-> J​ulexus Quandem. — yeah, the bar at the top of the orbit analysis window just gets part way along and then re-starts
<discord-> e​gg. — interesting
<discord-> e​gg. — we should probably indicate the lowest altitude over the mission duration
<discord-> e​gg. — it does look like your eccentricity is varying quite a bit
<discord-> J​ulexus Quandem. — I did a similar mission and the probe disappeared after a few months, to I'm assuming that crashed into the moon.
<discord-> e​gg. — yeah
<discord-> e​gg. — the selenopotential certainly makes things interesting
<discord-> J​ulexus Quandem. — I ran the mission forward for 35 days, my periapsis kept falling until I crashed into the terrain.
egg|cell|egg has joined #principia
raptop has quit [Ping timeout: 190 seconds]
raptop has joined #principia
<discord-> b​ofh453. — since it turns out i did *not* mention this in here:
<discord-> b​ofh453. — [9:36 PM] mofh: the thing with radar imaging is, upon recollection the frontend *can* be fairly simple, you just need to have full RX and TX equipment in the same location since you're picking up backscattered spectrum. like, in principle you can do SAR with a standard Ku-band TV sat parabolic reflector and a fairly simple transponder where the transmit end is effectively a TV sat spot beam
<discord-> b​ofh453. — [9:37 PM] mofh: like if you mounted the RX antenna on the sat and made the spot beam much more powerful (radar scattering spectra decay with the fourth root of the distance) you could do simple SAR with, say, EchoStar 9.
<discord-> b​ofh453. — you'd obviously need to feed the spot beam with the chirp pattern and do a bit of DSP on the receive end to convert that into images but yeah
<discord-> b​ofh453. — another example is the Goldstone Asteroid Radar
<discord-> b​ofh453. — which is literally just an alternate mode of the Goldstone #DSS14 high-power TXer, but the hardware is literally *all the same* as what is used to transmit command sequences to Voyager 1.
<discord-> b​ofh453. — @egg: ^
<discord-> e​gg. — @bofh453 hm; so sounds like excluding edge cases (and there are edge cases in optical too, e.g., coronagraphs) the hardware is unifiable
<discord-> e​gg. — then the question becomes, what are the dimensions that need to be modeled to prevent stupid reuse
<discord-> b​ofh453. — transmit power and antenna beam pattern (the latter is important b/c it both determines how the imaged slice looks like and also what your antenna gain is, and antenna gain counts for a *lot* in practise).
<discord-> b​ofh453. — are the two primary ones.
<discord-> b​ofh453. — but in practise it's honestly easier than optics in certain ways
<discord-> b​ofh453. — especially since you don't care that much about filters, and your noise sources (the sun, Saggitarius A*) tend to be fairly broadband so your solutions to them tend to be "aim away from them"
<discord-> e​gg. — also, re. opticks, we may need a materials scientist to understand noise, see also kspacademia
<discord-> b​ofh453. — bleh, that's actually quite tricky. *checks that backlog*
<UmbralRaptop> Pretty much just dark current, read noise, and I suppose radiation
<discord-> e​gg. — yes but how do those noises depend on temperature
<discord-> b​ofh453. — Johnson-Nyquist noise is relatively easy and dominates at high photon count
<discord-> b​ofh453. — at low photon count i think you're going to be dominated by Shot Noise
<discord-> S​irius. — Is this maneuver good?
<discord-> S​irius. — First time I'm doing a flyby of the moon with Principia
<discord-> D​RVeyl. — There is by def'n radio noise from the body you're pointing at. First order approximation I think you'd just take the body surface temperature and treat it as a blackbody emitter. This is... definitely wrong for some things that have different radio spectra (eg the Sun, Jupiter). If you're doing SAR imaging of a body, you can treat this as effectively changing your receiver's sensitivity.
<discord-> D​RVeyl. — (End result is it should drive your transmission power up.)
<discord-> S​irius. — And should I stay in MCEA when I'm doing the maneuver?
<discord-> e​gg. — MCEA is probably a good frame to look at things, yes.
<discord-> e​gg. — it gives you a nice overview, and that is what you want to check that you are doing the right thing
<discord-> S​irius. — Ok thanks
<discord-> S​irius. — I use a booster to do the TLI so I'm afraid it does wrong
<discord-> S​irius. — I use a booster to do the TLI so I'm afraid it does the maneuver wrong (edited)
<discord-> e​gg. — the flight plan does not know about decouplings, so you must decouple things before you create it
<discord-> l​pg. — given that's a solid anyway, decoupling won't help much. Instant Impulse, Inertially Fixed
<discord-> S​irius. — I've do that yesterday and it does a thing like that
<discord-> S​irius. — I'm afraid it does the same thing
<discord-> e​gg. — yes, because SRBs are not understood by the flight planner either
<discord-> e​gg. — did the Δv you planned match that of your SRB?
<discord-> l​pg. — the thing the planner doesn't tell you, when using instant impulse, is _when_ to burn. if you wait for the timer to hit 0, it's too late
<discord-> e​gg. — (but on the other hand, when you do not use instant impule, you should wait for it to reach 0)
<discord-> S​irius. — No, that's the tricky thing, I didn't use all my Delta V, but this time, the maneuver uses all my Delta V
<discord-> l​pg. — for the GCRC, 15s before 0 works pretty well
<discord-> S​irius. — I use the Altair
<discord-> l​pg. — can't help you then
<discord-> e​gg. — if you plan to use only part of your Δv on an engine that cannot be shut off, how is that supposed to work
<discord-> l​pg. — "2/3 burn time before 0" may or may not be a useful rule of thumb
<discord-> B​utcher. — @egg is there not a way to fix the planner?
<discord-> e​gg. — sure, but nothing is easy
<discord-> e​gg. — how do you deal with multiple SRBs with different burn times, how does the UI work to dictate what you use to burn, and if we want to start dealing with staging, how do we model fuel flow
<discord-> e​gg. — and modeling fuel flow is a rabbit hole wherein I do not want to go
<discord-> S​irius. — How much Delta V I need to do a flyby of the Moon?
<discord-> S​irius. — I have 3580 m/s but seems that's not enough idk
<discord-> S​irius. — 🤔
<discord-> l​pg. — ~3150
<discord-> l​pg. — gotta launch at the right time for that, of course
<discord-> S​irius. — Can I select a target (eg: Moon)
<discord-> S​tonesmile. — If you mean launch into plane using MJ, then yes, but be aware that the plane of the moon oscillates and might not be reachable
<discord-> S​irius. — @lpg It was telling me that I needed 2870 m/s to do a Moon flyby, is this possible?
<discord-> l​pg. — if you're starting from an unusual orbit, sure. not very likely though
<discord-> S​irius. — So, how I plan how much Delta V I will need?
<discord-> S​irius. — To do a Moon flyby
<discord-> J​ulexus Quandem. — I took just over 3200 for my moon impact missions, so a bit less than that would be fine
<discord-> S​irius. — Wdym?
<discord-> S​irius. — 2948 m/s is enough?
<discord-> l​pg. — if you're already in a highly ellpitical orbit, 10m/s is enough. if you're in low earth orbit, you need around 3150m/s
<discord-> S​irius. — Yeah LEO
<discord-> l​pg. — if you're already in a highly elliptical orbit, 10m/s is enough. if you're in low earth orbit, you need around 3150m/s (edited)
<discord-> S​irius. — With 9300 m/s to do an orbit
<discord-> l​pg. — that bit of information is of no use
<discord-> S​irius. — ?
<discord-> l​pg. — how much dv you use to get to orbit is not relevant when discussing TLI
<discord-> S​irius. — I was saying that to express the kind of orbit when I'm gonna do the burn
<discord-> l​pg. — how much dv you use to get to orbit does not gell anyone the kind of orbit you end up in
<discord-> l​pg. — how much dv you use to get to orbit does not tell anyone the kind of orbit you end up in (edited)
<discord-> S​irius. — Yeah, it's more how you use it
<discord-> b​ofh453. — > There is by def'n radio noise from the body you're pointing at. First order approximation I think you'd just take the body surface temperature and treat it as a blackbody emitter. This is... definitely wrong for some things that have different radio spectra (eg the Sun, Jupiter). If you're doing SAR imaging of a body, you can treat this as effectively changing your receiver's sensitivity.
<discord-> b​ofh453. — @DRVeyl this is pretty much accurate. honestly treating the sun as a relatively uniform in spectrum noise source is not a bad first approximation
<discord-> b​ofh453. — there's a DSN doc on modelling precisely this that i like, just a sec
<discord-> D​RVeyl. — Yep, there is. 🙂
<discord-> b​ofh453. — largely for @egg ^
<discord-> b​ofh453. — DESCANSO is a very useful resource here imho
<discord-> e​gg. — UmbralRaptop: come to think of it, doesn’t read noise determine the exposure time needed to detect something, with dark current defining the dimmest thing that can be detected ?
<discord-> e​gg. — hm, no, you can subtract a less-noisy dark current over a longer exposure, so I guess that factors into the exposure time too…
<discord-> e​gg. — gah
<UmbralRaptop> eggstra fun: multiple eggsposures for when there's a large dynamic range
<discord-> e​gg. — yeah I don’t think we want to start modeling that kind of thing
<discord-> e​gg. — (morally it just ends up being equivalent to different targets)
<discord-> e​gg. — otoh we need some sort of temperature-dependent model for detection thresholds, to prevent silly reuse (lest somebody use their pushbroom ground imager to look at the hubble deep field)
<discord-> e​gg. — otoh we do need some sort of temperature-dependent model for detection thresholds, to prevent silly reuse (lest somebody use their pushbroom ground imager to look at the hubble deep field) (edited)
bees has joined #principia
<discord-> l​amont. — @egg if i've got some overly complicated vector math like i posted yesterday that i want to convert from silly lefthanded garbage, to sane right handed math, within Unity. I just have to xzy the vectors back to right handed space, and then negate all the cross products?
<discord-> l​amont. — (oh and i need to fix north to be [0,0,1])
<discord-> e​gg. — @lamont the operations you need to perform are the same no matter what the handedness is
<discord-> e​gg. — however, to convert, you need to know what kind of animal you hold in your hand when you convert it
<discord-> e​gg. — if it is a bivector (pseudovector in physicist-speak), you need to change its sign
<discord-> e​gg. — so an angular velocity, a torque, an angular momentum, etc. should be flipped when changing orientation
<discord-> e​gg. — @lamont but tbh the easiest way may be to ignore the fact that things are left-handed; the calculations are the same regardless of orientation (because the laws of physics are invariant under change of orientation)
<discord-> 𒀯​ 𒄷 𒄈𒀭𒁇. — Just make sure to swap charges?
<discord-> e​gg. — (for your purposes)
<discord-> l​amont. — yeah except if you're setting up one of those bivectors
<discord-> e​gg. — no @lamont
<discord-> e​gg. — the laws of physics *are* invariant under change of orientation
<discord-> l​amont. — Vector3d n = new Vector3d(0, -1, 0); /* angular momentum vectors point south in KSP and we're in xzy coords */
<discord-> l​amont. — that line of code ain't invariant
<discord-> e​gg. — well, yes, coordinates are not invariant under changes of coordinates
<discord-> e​gg. — but the formulae are the same
<discord-> l​amont. — yeah maybe i've just been staring at this too long and i'm starting to doubt my sanity
<discord-> e​gg. — this is admittedly all made very dangerous by the fact that you have little in the way of abstractions above coordinates, and nothing to deal with the vector/bivector distinction or reference frames
<discord-> l​amont. — correct
<discord-> e​gg. — if you interact with a triple of numbers, then you are in coordinate-land; hic sunt leones