-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Multiple nodes editing #1936
Comments
Thanks |
If I wanted to take a crack at this and come up with a PR, where should I start? It looks like |
The first thing to do before starting to write code to resolve this issue is to figure out what the exact behaviour should be. We have been unsure about that, which is one of the reasons why we have not made progress here. Right now, the manoeuvres are specified with an absolute time, conceptually, something like “starting at 2019-02-17T00:38:52 UTC, impart a Δv of 300 m/s in the tangent direction, 5 m/s in the normal direction, 10 m/s in the binormal direction, with the Frenet frame defined by the trajectory in the ECI frame”. The problem is that with such a specification, changing an earlier burn is likely to turn later ones into nonsense. We think a possible approach here would be to somehow define the manoeuvre timings with respect to trajectory “events”, e.g., to define a manoeuvre as “starting at 30 s before perigee, impart a Δv of 300 m/s in the tangent direction, 5 m/s in the normal direction, 10 m/s in the binormal direction, with the Frenet frame defined by the trajectory in the ECI frame”. In our example, this would allow a lunar capture burn to be created with respect to the perilune, and thus to move with the injection, remaining a capture burn and requiring only minor adjustment after the rescheduling of the translunar injection. There are however many issues about the precise semantics that need to be sorted out:
There are probably many more issues like this. We need to get to a good understanding of the desired behaviour (including error conditions: we should reject changes to the flight plan that would lead to overlapping manoeuvres, to reordering of manoeuvres, etc.). Once we have figured out the exact details of the behaviour we want, we can start looking at the implementation (this will likely start with some changes to the
The Principia codebase is rather complicated (for instance we have dedicated libraries for handling physical quantities, reference frames, etc.), so you may want to take some time to familiarize yourself with it. Unfortunately we don't really have much in the way of documentation (the |
Indeed, helping us to figure out what to do would be extremely valuable, irrespective of the coding details. Maybe starting a shared document where we could throw ideas and have a discussion would be a good first step. We also need to think of the UI, so we'd want to have rough mocks/scenarios to decide how the user would control burns anchored at an event. Clicking on the Ap/Pe marker might be a good model. In general we are not particularly happy with the current flight plan UI so a major revamp might make sense. |
I'm completely on board with spec'ing this out before writing any code... I've spent enough time rewriting my own code to have learned that lesson. Some initial thoughts:
|
Keeping the absolute times would match what vanilla does, and might be a "good enough" solution to unblock further work like #1964 :) |
(Sorry for dropping the ball, we were on vacation.) I agree that a good first step would be to keep the absolute times while allowing the elements of the burn to edited. It seems simple enough, it would improve usability, and it would make it possible to evaluate the next steps. There are two prerequisites to this:
|
Would like to solicit input on error reporting. In the current UI (as of Fano), dragging a slider beyond the point that's acceptable (e.g., trying to move a manoeuvre after the end of the flight plan) causes the slider to effectively block and have no effect. It seems rather natural, although to be honest we don't tell you in any way why the slider blocks. In the next version (Fáry) we support text entry. So you can enter, say, a new start time for the manoeuvre and have it reverted without explanation to the previous value. This is increasing the "mysteriousness" of the UI. Once we start being able to edit manoeuvres other than the last there can be more failure modes: maybe the manoeuvre being edited overlaps with the next one or it causes some further integration to time out or the flight plan to go through a singularity (centre of a planet). How do we report this? We probably don't want to bring up a modal dialog box each time something goes awry but at the same time we want to communicate to the user details of what's happening. This being largely a UI question I expect at least as many opinions as respondents. Also remember that there are limitations to what Unity will let us do, at least with the GUILayout that we are currently using. |
I haven't played in many many days so I may remember things incorrectly.
If I remember correctly, there is a text area under the flight plan length slider (or is it on the main Principia UI?) where you display a message whenever the flight plan times out. You could repurpose it to show all errors. If the rest of the UI becomes smaller, you could increase the size of the text field to make it really obvious. The text colour of that field and any reverted values can be set to red to make it clear which values the user would have to tweak again. You may also want to make corrections to the flight plan silently in some cases; like extending the length of the flight plan if the entered node is farther in the future than currently permitted. This will of course place the responsibility on the user to not enter outrageously large value in there. |
Now, in Principia, if you want to edit the earlier node after planning many nodes, you have to delete the node in front of it, and adding it back after finish editing that node, and the effect to the after node would be a problem, because there's not a way unless you add it back on. But when there's too many nodes, it's kind of impossible to delete them and add them on again. The request is I can edit nodes earlier anytime, so multiple node orbit planning could get a solution.
Another request is choose to show how will next node be after completing this node, another way to say it is show the after node dynamically, so if there is a little error, caused by RCS or other things, Principia could still show wether the node you planned before is working or need fix, instead of delete the whole flight plan then add nodes back on again.
The text was updated successfully, but these errors were encountered: