Patched Conics accuracy

[Nich]

So I launched my first Duna Mission in 1.0.5 and I have some questions?

Patched conics seamed very wrong.  I exited Kerbin's SOI at regular speed and lost my flyby.  I spent 20 dv correcting and set the PE to 600km due south of south pole.  At the AN what should have been an 8 dv correction became a 75 dv correction to put PE at 20km planer to Kerbol.  Upon crossing into Dunas SOI I needed another 100 DV correction.

 

Also while I have you is Dunas ATM seem much thinner I ended up crashing into duna before my parachutes were ever safe to open.

 

Any tips would be appreciated.  Luckily I did the flight in 1 go so I just reverted.  I will try again and post pics on the next attempt.

[Gaarst]

Nothing to do there as these errors are caused by limited accuracy in the variables used for orbital calculations. Different types of numbers have different accuracies (IDK if KSP uses floats, doubles or whatever) but you're never going to get 100% precision.
These inaccuracies are what lead to the wobble of almost-circular orbit and the randomness of flybys.

The best thing you can do there is to add some fuel in your ships to account for corrections burns, recall that even real spacecrafts often do correction burns during interplanetary missions.

 

And for the atmosphere, there were some changes from 104 to 105, Duna's atmosphere being really thin, the difference in drag can be significant as atmosphere is no longer dense enough to allow you to open chutes with just aerobraking. What I do is consider Duna landings as atmosphere-less landings and take enough dV in my lander to do a fully powered landing, or at least to allow them to slow down enough to open chutes.

[regex]

Yeah, the accuracy leaves something to be desired.  As I understand it, it boils down to flip-flopping between single- and double-precision floating point numbers and the subsequent loss of precision.  Basically whenever you cross over an SOI boundary you should slow down to x50 timewarp or less, and the game tries to do this already.  Still, even that sometimes can't help the situation so it's always good to pack extra delta-V (even NASA packs a safety margin of fuel).

E: ninja'd liek a baws

Edited February 3, 2016 by regex

[Red Iron Crown]

My tip would be to avoid normal time as much as possible, especially when crossing SoI boundaries. When on rails in timewarp the ships path is computed with Squad's orbital code, which uses doubles (64-bit) for greater precision and smaller error. When off rails at 1x time (or in physics timewarp) the games uses Unity's physics engine, which uses floats (32-bit) and isn't as precise. (Unity was never really meant for worlds of KSP's scale, minute though it might be compared to the real one.)

So if you stick to a low warp level, the floating point errors will be minimized.

[tomf]

Ohh, that is interesting. A few versions ago warping across SOI boundries was broken so I got into the habit of always slowing for SOI changes. I knew that it has been fixed but I didn't know that it was now better than the 1x calculation.

[Red Iron Crown]

It's been so for as long as I've been playing, it's just that higher timewarp rates across the SoI change could cause problems. The rule of thumb was to cross SoI boundaries as the lowest on-rails timewarp (5x). 

[Nich]

 I see I think I've also had problems when I immediately jumped to Max time warp and do better if I work my way up. I reattempted Duna transfer again and this time I only had about 30 DV of corrections

[Dafni]

About the new Duna atmosphere, it became now almost impossible to do a Curiosity style landing without doing almost all the work with the skycrane. I wont say this is bad or should be changed, Duna is not a direct Mars model after all, but I sure liked it much better with the more draggy atmosphere. It gave the game a nice in-between planet, as far as aerobraking and landings went, now its almost like just another atmosphereless body.

On the other hand, close to the surface the atmosphere is dense enough to upset non-streamlined VTOL landers at higher speeds. Kinda weird balance on the Duna atmosphere now IMHO.

12 hours ago, Red Iron Crown said:

My tip would be to avoid normal time as much as possible, especially when crossing SoI boundaries. When on rails in timewarp the ships path is computed with Squad's orbital code, which uses doubles (64-bit) for greater precision and smaller error. When off rails at 1x time (or in physics timewarp) the games uses Unity's physics engine, which uses floats (32-bit) and isn't as precise. (Unity was never really meant for worlds of KSP's scale, minute though it might be compared to the real one.)

So if you stick to a low warp level, the floating point errors will be minimized.

That is very interesting, I did not know that. Thanks for the insight

 

Edited February 3, 2016 by Dafni

[StarManta]

2 hours ago, tomf said:

Ohh, that is interesting. A few versions ago warping across SOI boundries was broken so I got into the habit of always slowing for SOI changes. I knew that it has been fixed but I didn't know that it was now better than the 1x calculation.

It fixed it by actually slowing down on its own during SOI transition.

[*Aqua*]

For me patched conics are getting worse. They are flipping around like crazy, switching between a SOI change and no SOI change at all every 1/10 s. I then timewarp to the change (which the game still can't decide if it's gonna happen or not) and then - like magic - I entered the target SOI.

I have no idea what goes wrong here. Especially when I'm on a collision course with a moon.

[boccelounge]

On 2/3/2016 at 0:17 AM, Red Iron Crown said:

My tip would be to avoid normal time as much as possible, especially when crossing SoI boundaries...if you stick to a low warp level, the floating point errors will be minimized.

Ah, that's interesting.  I was going to post a similar question; I'm glad I did a quick search first.

I've been coming out of warp when crossing SOI's, thinking it would improve accuracy.  Thanks much for clearing this up.

[justspace103]

yeah ive encountered this. it happens when the game thinks you are leaving kerbins SOI, reentering it for a very short time, and exits on a "similar trajectory that is slightly off and messes up the manuver

[magnemoe]

On 3.2.2016 at 6:17 AM, Red Iron Crown said:

My tip would be to avoid normal time as much as possible, especially when crossing SoI boundaries. When on rails in timewarp the ships path is computed with Squad's orbital code, which uses doubles (64-bit) for greater precision and smaller error. When off rails at 1x time (or in physics timewarp) the games uses Unity's physics engine, which uses floats (32-bit) and isn't as precise. (Unity was never really meant for worlds of KSP's scale, minute though it might be compared to the real one.)

So if you stick to a low warp level, the floating point errors will be minimized.

Ok, mechjeb goes down to 1x and I always heard that you should do the transition in 1x to avoid problems. 

Good tips is to do an correction burn halfway, then an extra check say 10 days away to verify that all is well. New correction after enter SOI, than an final 30-10 minutes before enter atmosphere, part of the issue here is also accuracy of burn.

[OhioBob]

In general, the atmosphere of Duna isn't thick enough to slow a spacecraft down sufficiently to deploy main parachutes before crashing into the ground.  However, it's possible to get slowed down enough to deploy drogue parachutes.  The drogue chutes will then slow the spacecraft down enough to deploy the main chutes.  So you really need both drogue and main parachutes to successfully perform a parachute landing.  Even then, some propulsion may be necessary.

There was a discussion about this some time ago in which it was pointed out that parachutes should have a higher safe deployment velocity on Duna than on Kerbin because of the thinner air.  That's not the case now.  I seem to recall it being said that changes to this are planned for version 1.1.

[SgtSomeone]

Also each time the projection crosses an SOI it loses a little bit of accuracy, which is why it will only show you projections for 2 future SOIs at a time (there's a way to change that though by digging through config files). I've always been tempted to try to do a New Horizons-style Eve->Kerbin->Eve->Jool->Eloo path, but it gets to be way off by the second flyby. My rule of thumb is to do final positional accuracy for the next SOI, and only roughly approximate it in any SOIs beyond that. (i.e when around Kerbin, only roughly set your Duna flyby altitude until you're interplanetary)

[Blaarkies]

On 2/3/2016 at 7:12 PM, Dafni said:

On the other hand, close to the surface the atmosphere is dense enough to upset non-streamlined VTOL landers at higher speeds. Kinda weird balance on the Duna atmosphere now IMHO.

 

This reminds me of some documentary about Curiosity's landing, that Mars' atmosphere is too thin to be useful, but just enough so that you cannot ignore it.

Back on topic: The orbital trajectory predictions get way jumpy/flickery when I plan them:
- 100+ days in the future
- Chain up 4+ maneuver nodes

It gets to the point where I cannot even place a node at PEof a highly elliptical orbit. So I do the fuel station near Minmus thing, using highly efficient tugs and slight Mun slingshots to get fuel up to Minmus cheaply. Then launch my interplanetary ships almost empty to that station, fill up, then plan maneuvers:
- Retrograde burn to drop PE to 70km.

- Prograde burn at PE to achieve escape

I adjust the first Retro burn node so that the timing and final escape angle matches the trajectory needed for reaching say Eve. The thing is, that second node is really, really jumpy. If I manage to actually place it at PE, it starts moving up to 10 minutes forwards/backwards(flicker back and forth) when I add dv prograde.

Is there anyway to get around this? ...besides re evaluating maneuvers after every burn

Edited February 29, 2016 by Blaarkies

[Spheniscine]

6 hours ago, OhioBob said:

There was a discussion about this some time ago in which it was pointed out that parachutes should have a higher safe deployment velocity on Duna than on Kerbin because of the thinner air.  That's not the case now.  I seem to recall it being said that changes to this are planned for version 1.1.

For now there is the RealChutes mod, which is quite a bit more lenient on safe deployment speed (450 m/s is safe, vs the 250 m/s of stock IIRC). Also try shallower aerobraking altitudes.

Edited February 29, 2016 by Spheniscine

[Hannu2]

Orbit predictions, calculations and SOI detections are buggy. Unfortunately, they have been fundamentally programmed by using stupid algorithms (not suitable for this kind of purpose) and it is practically impossible to fix them without rewriting huge parts of code. So, they will stay buggy and we have to learn to live with it. Therefore it is necessary to make multiple checks and reserve dv for corrections. It is best to plan first correction immediately (couple of hours) after leaving Kerbin's SOI. Typically it is on first half on orbit and magnitude is 0-20 m/s (from Kerbin to Duna) if ejection was reasonable accurate. In first correction PE is roughly adjusted to somewhere near wanted value (0-1000 km for low orbit, 2000-4000 km for Ike encounter).

Next correction is planned immediately after executing first. It is 40-70 days before Duna encounter. Then it is time to adjust periapsis altitude and timing of the encounter so that you avoid Ike (or encounter it at optimal position if mission profile is such). Time is adjusted by varying prograde and radial components of velocity about 1 m/s per step so that PE stays at given altitude.

It is good idea to check everything just before executing the second correction. Then execute the maneuver and check everything again. Then it is time to warp on SOI change and make last fine adjustments when craft enters to Duna's SOI. There are several mods which give precise maneuver controls. Using one of them is very recommended if you try to achieve efficient interplanetary trips. Squad's stock numberless eyeballing maneuvering needs much extra dv.

I do not use parachutes in Duna. It gives more risks, restrictions and problems than avoid costs. Powered landing from low orbit needs less than 1500 m/s dv which is quite practical to have.

[Brainlord Mesomorph]

This is very interesting.

I found out about the difference between the projected course and the actual course the hard way, by smashing into one of the moons of Jool.  But I didn’t consider it to be a mistake, but a deliberate element of game play.

In a virtual reality sim, there would be no reason for projected course to be any different from actual course, the same mathematical model would produce both courses and the ship would fly precisely along its course.  But in reality that wouldn’t happen.  So I figured they introduced a rounding error deliberately to simulate that difference. (Kerbals aren’t very good at math)

That also worth noting that our piloting isn’t perfect, we’re never precisely aimed at the node, our timing is almost always off, and our burns are, at best, off by a few tenths of a m/s

Beyond that, the mass of the ship isn’t the same after the burn, as it was when you are plotting the maneuver.  And if you are plotting three or four burns in advance, there’s no way are ship will be precisely where you expected it to be a year later as you approach Duna.

And if it was, I don’t think that would be as much fun.

'EDIT: About Duna's air: Elevation is everything! Some of the mountains almost peek above the atmosphere. If you want to maximize aerobraking, try to put your ship at the bottom of the Rift Valley, where the air is thickest.

Edited February 29, 2016 by Brainlord Mesomorph

[taniwha]

While on rails (ie, timewarp at or above 5x), 32-bit floats are not used at all, so what you see really is what you get.

However, SoI crossing is another problem that has nothing to do with the precision of the calculations. Instead, it is all about sampling. Differences between projected and actual orbits after an SoI change are caused by differences in when you cross the SoI boundary. The projected orbit results from a calculated SoI boundary crossing time, but the actual orbit results from recalculating the orbit after "oops, we crossed the SoI boundary between last frame and this frame". This means there will be variations based on how much you were warping when you crossed the boundary, your velocity when you crossed, your exact positions on either side of the boundary, and even how far into the save you are (UT's precision will slowly drop off as the game progresses, but you will have to warp for something like 10000 game-years for it to become much of an issue).

Could KSP do something about it? Maybe. Is it worth the effort? Less likely. So long as you cross the boundary at a low enough warp (5x-50x (personally, I recommend 5x)), you should rarely lose an encounter to any planet with a largish SoI, and regaining should be cheap for smaller planets. Similar for aerobraking: have your periapsis about where you want it, cross the SoI "slowly" (warp), any adjustments should be trivial (if even necessary). I used to not warp at all when crossing SoI boundaries, but that can be a tad slow (real-time) and you then do get the fun of 32-bit/64-bit floating-point math.

Something else to keep in mind: in the real world, patched conics are only an approximation. Space agencies do not rely on them for anything more than planning (when can we go? how much delta-v will it cost? ok, add some for course corrections), though even that might be stretching things these days as they have sufficient data to just simulate it all to good enough accuracy that they can get away with smaller corrections. In other words: no matter how much you gripe about them, patched conics in KSP are more accurate than they are in real life.

Another thing to keep in mind: orbits are chaotic systems (even 2-body). Even the tiniest difference at the bottom of your trajector near Kerbin (say, 100km) will make a large difference to your trajectory past Jool.

KSP is extremely precise (53 (52 explicit) bits of precision when on rails (that's 17 significant figures in decimal)), though for the sake of speed it may not make full use of that precision in its solvers. However, if KSP's math was that bad, you could not rendezvous with an asteroid or another ship in solar orbit. I have done so several times. BTW, those 17 sigfigs get you micrometer precision at 1AU (Earth, not Kerbin).

[edit]Hmm, make that 17-34 micrometers, but still...

Edited February 29, 2016 by taniwha

[RocketPropelledGiraffe]

For the parachutes, just bring along some drogues. I use them all the time since 1.0.5 and feel a lot safer with them (I never used them before). You propably still need a little thrust for the final landing, but the parachutes do help even in the thin atmosphere.

The trajectory projection was always problematic for interplanetary missions when your encounter was close to the SOI edge, but I somehow got the impression that it is worse in the newer versions. Recently I encountered problems with a Duna transfer even for a projected trajectory within Ike's orbit, which used to work fine for me.

[Kobymaru]

 

1 hour ago, taniwha said:

Could KSP do something about it? Maybe. Is it worth the effort? Less likely. So long as you cross the boundary at a low enough warp (5x-50x (personally, I recommend 5x)), you should rarely lose an encounter to any planet with a largish SoI, and regaining should be cheap for smaller planets.

Similar for aerobraking: have your periapsis about where you want it, cross the SoI "slowly" (warp), any adjustments should be trivial (if even necessary). I used to not warp at all when crossing SoI boundaries, but that can be a tad slow (real-time) and you then do get the fun of 32-bit/64-bit floating-point math.

I gotta say, there are some effects where crossing the SOI "slowly" just doesn't cut it. I have quite a bit of a beef with the Duna-System, because it kicked out my perfectly placed synchronous satellites for no reason.

Also, when flying around, "surprise" encounters happen often enough:

 

There are even cases where people were pinballing around in the Jool system and got Tylo surprise-encounters. Gravity-Assist pinball is hard enough if the patched conics trajectories are correct, but if they don't even show encounters in the path, now that's just mean.

If I read corretly, some of this silly business might be fixed in 1.1. I really wish for it, but my hopes are not high.

 

 

Edited February 29, 2016 by Kobymaru

[Chaos_Klaus]

Actually it is very possible to do parachute landings on duna. You just have to build a craft that has sufficient drag and is light. Because that's what slows you down. Optimizing something for reentry is like the opposite of optimizing it for launch. Many people seam to forget that.

 

[regex]

Minor nitpick:

Quote

patched conics in KSP are more accurate than they are in real life.

So wait, what you're saying is that KSP's patched conics simulation is more accurate than one potentially written by actual scientists who would potentially use it for planning actual space missions?    How about just saying that the system can't get more accurate than those that are used in real life?  Especially since it is a demonstrably false statement if we take into account the 32/64 bit conversions KSP has to deal with because of the underlying engine; I can almost 100% guarantee you an actual space agency wouldn't stand for that were they relying on patched conics as much as we do.

[Red Iron Crown]

12 minutes ago, regex said:

Minor nitpick:

So wait, what you're saying is that KSP's patched conics simulation is more accurate than one potentially written by actual scientists who would potentially use it for planning actual space missions?    How about just saying that the system can't get more accurate than those that are used in real life?  Especially since it is a demonstrably false statement if we take into account the 32/64 bit conversions KSP has to deal with because of the underlying engine; I can almost 100% guarantee you an actual space agency wouldn't stand for that were they relying on patched conics as much as we do.

I took that to mean that patched conics are closer to the "reality" in KSP than patched conics are to "reality" in real life. Because "reality" in KSP *is* patched conics, while IRL they're an approximation of relativistic n-body.