search

neuoy / KSPTrajectories

A Kerbal Space Program mod to display trajectory predictions, accounting for atmospheric drag, lift, etc.
GNU General Public License v3.0
144 stars 47 forks source link

Taking a predetermined future burn into account #128

Open joaofarias opened 6 years ago

joaofarias commented 6 years ago

I'm writing a kOS script to accurately land a booster back at KSC (Falcon 9 style) and I'm using the Trajectories mod to put it into the correct course when performing the boostback. This is working pretty well so far and I can consistently land within 5m of the target, which I think I can still improve with some changes to how the landing burn is performed.

The next big step is to add a reentry burn. Obviously, this burn will put the rocket off course and land far from the target. I was wondering if we can provide a specific burn to the algorithm, e.g. start burning at 30km altitude for 5 seconds, so that it already accounts for that when performing the boostback?

Not asking you guys to do this, I'll be happy to. I haven't had a proper look at the code yet but if you can point me in the right direction or give me your thoughts on whether this is feasible at all, that'd be great.

Bonus question: To get around not being able to predict the drag information for future vessel states, would it be possible to launch my vehicle with the grid fins deployed, generate and store the drag data somewhere and then tell the algorithm to use this data when calculating the trajectory below a certain altitude for subsequent flights?

fat-lobyte commented 6 years ago

Hey there! Yes, this would be theoretically possible I think, and I have toyed with the idea in the past.

There are 3 main parts required for that:

  1. Changes to the structure of the "Descent Profile", which is currently hardcoded to have 4 sections depending on the altitude. Check out this and this code.
  2. Implement an additional thrust term in the acceleration function, depending on the Descent Profile, probably around here.
  3. Come up with a good input scheme so that users can input the thrust manually, preferrably with a direction. That would mean inserting more or fewer than 4 sections into the descent profile, each one limited by altitude? I don't really have the perfect solution here, but we would definitely have to rewrite a serious part of the GUI here.

I guess if you're only interested in kOS, Point 3 might be moot, but eventually we should implement that too.

joaofarias commented 6 years ago

Heya! Sorry, I forgot to update this with my progress.

I've pretty much implemented points 2 and 3 (API only and separate from descent profiles) and it works reasonably well - the impact position is not very stable and seems to move anywhere within a ~20m radius. I'm not too sure why yet but haven't had time to look into it further and, for my case, that's something I can easily correct after the reentry burn.

I also reduce the mass of the aerodynamic model based on the fuel consumed by the burn.

I haven't looked into the descent profiles too much as I just keep the rocket facing retrograde most of the time (and definitely during the burn), which is the default profile. But it sounds good to me to have the burns be part of these profiles. I'll see if I can come up with something nice for this.

Thanks a lot!

fat-lobyte commented 6 years ago

I've pretty much implemented points 2 and 3

I'm curious, do you have a branch that you could show me?

the impact position is not very stable and seems to move anywhere within a ~20m radius.

20m? I'd call that pretty damn precise ;) Or do you mean 20 km?

joaofarias commented 6 years ago

I do mean 20m. I never said it wasn't precise :) What I meant is that the value changes every time it recalculates which I thought it was due to my stuff but I just did a quick test without it and it did the same so looks like it's normal.

I only have a local clone. I'll get it up on github soon and let you know. I'll refrain from doing pull requests at the moment since you guys will probably be busy getting it working nicely with 1.4+dlc. No need to worry about this now.

neuoy commented 6 years ago

I don't remember if it's already possible or not, but maybe you can add a manoeuvre node for this burn ? I'm not sure it works mid-way in the atmosphere though. Also nodes after (or during) aerobrake are difficult to tweak because they appear at the wrong place relative to the predicted trajectory. Maybe improving this system (displaying the node at the right place, or more generally completely override the stock orbit patches to account for aerobraking) could help ?

joaofarias commented 6 years ago

From what I understood, the current implementation of manoeuvre nodes instantly applies the full burn's worth of velocity so it wouldn't be accurate. Maybe we could do the other way around and use my stuff to calculate the correct burn for manoeuvre nodes. Based on the time of the node and the estimated time of the burn, we could calculate when to start/end the burn.

neuoy commented 6 years ago

Actually I had the plan to also include "real burns" in the Trajectories mod (hence the name which is more generalist than just "aerobraking" or other namesI had in mind). But I never started it. I think "real burn" + fusion of trajectory display with stock orbit patches would really add value to the mod. I have no idea how to do the latter though (or even if it's possible).