Arrowstar
-
Posts
2,549 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Arrowstar
-
-
16 hours ago, Bej Kerman said:
...fine, I guess?
Trying to do a reasonable amount of runs, like 15, even at the default iteration and population size, just causes the window to remain in its default layout without the information boxes ever showing anything or the map showing up.
A few things: First, is there anything in the ksptot.log file that shows up when you run the software? Any errors or warnings?
Second, could you show me a picture of the window with the RSS solar system data loaded into KSPTOT instead of the stock solar system? I'd like to try to recreate the issue you described earlier. To be honest, I'm still not entirely sure what's wrong, because the screenshot you provided does show plots and information in the text boxes.
-
2 hours ago, akyyy said:
Hi! I trying to create a simple porkchop plot based on this tutorial, but doesn't work.
RO/RP1 with RSS.
Simple Earth-Venus, if i use Transfer Window Planner, or Metchjeb2, it works, but using TOT I don't encounter Venus.
How close are you getting?
If it's close, you're running into the zero radius SOI assumption introducing some inaccuracies into the burn. All you need to do is tweak things slightly and it'll come in.
If it's really off, then this is a case where your initial orbit definition (the mean anomaly and epoch) are probably off and it's throwing you out into space.
Can you share some pictures or screenshots?
On 12/27/2022 at 10:39 AM, vitorboschi said:@Arrowstar Thanks!
I've seen this error log being generated when I try to add the "Set Kinematic State" event, which might be related to it not being added to the list afterwards:
Nonfinite endpoints or increment for colon operator in index. Error in lvd_EditActionSetKinematicStateGUI_App/populateGUI (line 284) Error in lvd_EditActionSetKinematicStateGUI_App/lvd_EditActionSetKinematicStateGUI_OpeningFcn (line 1357) Error in lvd_EditActionSetKinematicStateGUI_App>@(app)lvd_EditActionSetKinematicStateGUI_OpeningFcn(app,varargin{:}) (line 4540) Error in appdesigner.internal.service.AppManagementService/runStartupFcn (line 103) Error in matlab.apps.AppBase/runStartupFcn (line 69) Error in lvd_EditActionSetKinematicStateGUI_App (line 4540) Error in SetKinematicStateAction.openEditActionUI (line 443) Error in lvd_editEventGUI_App/addActionButton_Callback (line 427) Error in appdesigner.internal.service.AppManagementService/executeCallback (line 138) Error in matlab.apps.AppBase>@(source,event)executeCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 63) Error in matlab.ui.internal.controller.uicontrol.UicontrolRedirectStrategy/executeCallback (line 231) Error in matlab.ui.internal.controller.uicontrol.PushButtonRedirectStrategy/handleCallbackFired (line 13) Error in matlab.ui.internal.controller.uicontrol.PushButtonRedirectStrategy>@(varargin)obj.handleCallbackFired(varargin{:}) (line 19) Error using matlab.ui.control.internal.controller.ComponentController/executeUserCallback Error while evaluating Button PrivateButtonPushedFcn.Another, unrelated bug:
When I try to optimize this LVD mission, I get:
Error using optimfcnchk/checkfun Supplied function '@(x)lvdOpt.constraints.evalConstraintsWithGradients(x,true,evtToStartScriptExecAt,true,[])' returned NaN when evaluated; FMINCON cannot continue. Error in fmincon (line 672) Error in lvd_executeOptimProblem (line 30) Error in FminconOptimizer/optimize (line 106) Error in LvdOptimization/optimize (line 62) Error in ma_LvdMainGUI_App/optimizeMissionMenu_Callback (line 2865) Error in appdesigner.internal.service.AppManagementService/executeCallback (line 138) Error in matlab.apps.AppBase>@(source,event)executeCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 63) Caused by: Failure in initial nonlinear constraint function evaluation. FMINCON cannot continue. Error using matlab.ui.internal.controller.WebMenuController/fireActionEvent Error while evaluating Menu Callback.Thanks for these! I couldn't reproduce the second one, but I'll take a look into the first. If you come up with more concrete steps to reproduce that issue, please let me know.
-
4 hours ago, vitorboschi said:
- In some cases, while a chart manipulation tool is active (Pan, rotate, zoom...), you cannot properly interact with the events list: double clicking an event will not open the edit window, and right-clicking will open a menu with chart options rather than the usual event popup menu.
This, unfortunately, is an issue with MATLAB and not with KSPTOT. I've tried to work around it, but in general, when a figure's pan/zoom/rotate/etc tools are active, they block clicks to other UI elements, much to my chagrin. I can try to file a bug report with The MathWorks, but I suspect this one isn't getting fixed for a while.
Quote- When inserting a "Set kinematic state" action, I cannot set the epoch using the date/time editor. When I choose that option, the editor will appear, but when I click "Ok", the time is not set. Instead, the console will show this error:
Error using matlab.ui.control.EditField/set Unrecognized property String for class EditField. Error in lvd_EditActionSetKinematicStateGUI_App/enterUTAsDateTimeContextMenu_Callback (line 1536) Error in appdesigner.internal.service.AppManagementService/executeCallback (line 138) Error in matlab.apps.AppBase>@(source,event)executeCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 63) Error using matlab.ui.internal.controller.WebMenuController/fireActionEvent Error while evaluating Menu Callback.
Fixed! Thanks for the report. It'll be in v1.6.10 PR3, which I'll look into releasing next week.
Quote- Also when inserting the "Set kinematic state" action, in some cases it will not appear at the list after I change the settings and click "Save & Close". I couldn't find the exact steps to reproduce this one yet, but will report once I do.
If you can figure out how to reproduce it, please let me know. I've been running after bugs similar to this one for a bit and they've been hard to track down, though I have successfully fixed some cases where it occurs.
Quote- I noticed the initial state doesn't always match what I set as the scenario initial state (see image for ref) . Is that expected?
Your reference image shows the state being defined in the Body Fixed Frame, but the states shown in the main LVD window are by definition in the inertial frame, which is why you're seeing a difference. It's my intention to let the user change the displayed frame and element set shown on the LVD window for both initial and final state, I just have to get around to it.
-
3 hours ago, shootnscoot said:
Woah, 192 pages of posts... sorry for not reading but is there a Python implementation of this for those without MATLAB? I used to have matlab and then my computer (and backups) crashed. If no python version, anybody up for translation? Seems like an interesting project.
You don't need MATLAB to use this thankfully! You can freely acquire the MATLAB Runtime Environment from the install instructions in the OP. Install that and KSPTOT will just run.
Good thing, too, because it would take years to reimplement KSPTOT in python lol.
-
On 12/23/2022 at 7:07 AM, vitorboschi said:
@Arrowstar I've found a bug with LVD's node upload feature: it seems to always set the node execution to the end time of the event, even when it was set to execute the actions before propagation.
Okay, thanks for the notice. I'll take a look!
-
21 hours ago, theAstrogoth said:
Here are the details for the solution I’d found. You can see plots of the trajectory here if you scroll down a bit.
It also uses a fully specified, equatorial orbit, and the departure burn is still mostly prograde. The powered flybys are rather inexpensive (<50 m/s)
Awesome, that's for the data. Are the years and days there Kerbin or Earth years and days? I will see if I can't find this trajectory in MFMS.
Something I should look into is a quick method for determining the departure delta-v. Any idea how that tool computes it so quickly?
-
4 hours ago, vitorboschi said:
Now the problems:
- When I change the event 1 from Two body propagator to the Force model propagator, the orbit seems to decay to the ground, even though there shouldn't be any thrust/drag to the ship at that orbit
- Propagating it takes less than 5 seconds, but actually optimizing it is *very* slow. It can take multiple minutes between steps. I wasn't expecting that much from a simple mission like this one
Okay, so the issue is in how this is all set up. What you're running into is not drag but instead integration error that accumulates because you're going around and around Kerbin many times. This is sending you into Kerbin. You can get around this by tightening your integration tolerances (say, to 1E-10 for both absolute and relative tolerances). A better way to go about this, though, is to only propagate less than one revolution and optimize the initial time directly. Propagating for millions of seconds is always going to be awful for both run time and optimization time.
To your second point, after the initial propagations finish to compute the gradient, the optimizer needs to do a line search kind of thing and this is always done in serial. This is what's killing your optimization time, because it might have to repropagate the trajectory many times to finish each optimization step.
As always, getting your trajectory propagation time down as low as possible is the best bet to speedy optimization. Sub 1 second times are preferable if you can swing them. Also make sure you're optimizing in parallel.
QuoteRelated to that slowness, I'm curious: can I use two body propagators on steps that have only an impulsive delta-v (the instantaneous one) as the action (plus a non-zero event duration) to optimize that?
If by steps you mean events: yes, you can do that. No reason why not!
-
On 12/20/2022 at 1:17 PM, theAstrogoth said:
That's part of the point I was trying to make! As far as I understand it, you can't have 1) a really large space of flight times and departure dates, 2) fast search time, and 3) a guarantee of a good solution. No matter what, there are going to be some drawbacks to our default options for the things that affect these. No criticism of the MFMS intended
Since I enjoy digging into the cases where our tools "fail", in case there is an interesting reason or an opportunity for improvement, I spent a little time fiddling this some more. In case anyone wants to replicate any of these tests, here are the "general parameters" (using Kerbal time) for the trajectory as obtained from the video earlier in the thread:
- Kerbin -> Eve -> Kerbin -> Kerbin -> Jool
- Kerbin departure: Y2, D160
- Kerbin->Eve duration: ~199 days
- Eve->Kerbin duration: ~406 days
- Kerbin->Kerbin duration: ~695 days
-
Kerbin->Jool duration: ~1661 days
- Note that this one is outside the default range in the MFMS. Why does Kerbin->Jool have the shortest maximum duration?
- Ignore cost of arrival burn
The video uses unpowered flybys with deep space maneuvers, but they're very small course corrections, so the powered flyby approach could be reasonable as well. Assuming there's not a problem with my initial result, we already have a similar trajectory using powered flybys.
I revisited the MFMS to double check that the parameters I was using were correct, and I kept getting the same results as before. When I tried to provide a very narrow set of search parameters, working backward from a known solution (from either the tutorial video or the result from the KTI), it fails to find valid flyby trajectories and displays a warning. Relaxing the search parameters, it ends up back in the 3+km/s range.
I'll note that after retesting with the KTI a few times, I think that it's likely that my first result was a particularly lucky optimization run. Most of the time I end up with a result around 2km/s, unless I shrink the search space to a relatively small region around the known solution. Enabling DSMs seemed to make the search slightly more reliable.
Maybe this particular case might be one that benefits from the use of DSMs? That would explain why Krafpy's MGA Planner tends to do a good job even when the user doesn't narrow the search space very much.
Can I ask, does that 1100 m/s include the Kerbin departure? Because I can get MFMS to find a solution with about that delta-v if it's just the in-space delta-v after departure.
Keep in mind that with MFMS because you're specifying the initial orbit completely, you probably have large radial and normal components to your burn unless you get lucky and your departure orbit is in the right orbit plane to begin with.
-
11 hours ago, theAstrogoth said:
Side note: I was curious about whether or not the search strategy that @Krafpy and I use holds up to the one used by the KSPTOT, and it seems like the KSPTOT MFMS also struggles to find this particular solution. Using the same range of departure times and using the same mission settings (i.e. ignoring the cost of an arrival burn), the KSPTOT's best solution cost ~3000m/s, even after a few repeated searches. I'm confident that the MFMS can find the desired solution in theory, it's just that global optimization is difficult. You could try increasing the population size for the genetic algorithm in the MFMS (bottom right corner), but this can become computationally expensive.
A few thoughts here. First, make sure that the bounds on the flight times are reasonable for each leg of the trip. If the optimal trajectory is outside the bounds, it'll never be found. Second, make sure that you're specifying years correctly. KSPTOT lets users switch between Earth and Kerbal years and it's important to know which you're working with. Third, if there's no arrival burn, turn off the option to minimize arrival excess velocity since this won't be important anymore.
I'm sure MFMS can find a good solution to the problem, it's just a matter of setting things up correctly.
-
3 hours ago, Krafpy said:
@ArrowstarI remember on the screenshots you sent a while ago I only saw Lambert arcs connecting the different encountered bodies, considering flybys as instantaneous events (calculating powered swingbys analytically if I remember correctly), that's what I meant by "doesn't compute the details of in-SOI parts to be displayed".
Did you add SOI intersection points and in-SOI trajectories when you display the whole trajectory ?Sorry if my phrasing is bad...
Oh, MFMS has always displayed the flyby trajectories. It has to compute the flyby trajectories to minimize the burn delta-v, so it was trivial to just display those trajectories.
-
3 hours ago, Eddy119 said:
Do I leave the box checked for normal purposes? (Sorry for another question)
Yep, you should leave it checked normally.
-
Just now, Eddy119 said:
So does it mean if I uncheck it there is no departure burn from Kerbin?
No, it means that it won't be factored into the optimization problem's objective function. There will still be a departure burn.
-
3 minutes ago, Eddy119 said:
Hi, what does departure excess hyp. velocity mean in Flyby finder? I'm so confused by it...
The hyperbolic excess velocity is basically the speed above the gravitational escape speed at infinite distance from the planet. Give this nice Wiki article a read for more details: https://en.wikipedia.org/wiki/Hyperbolic_trajectory
-
On 12/16/2022 at 9:24 AM, Krafpy said:
From what I know, KSPTOT uses a similar search algorithm (a type of evolutionary algorithm), but I think it doesn't compute the details of in-SOI parts to be displayed, so it has less work to do and has probably more chances of finding good trajectories.
I do actually! I developed a semi-analytic way of computing the flyby orbit and the necessary powered flyby maneuver. It's really quick (because you don't have to solve it numerically), which is why the code runs as quickly as it does.
-
1 hour ago, Clayel said:
With a reasonable amount of delta-v, yes. Not with 3.2 km/s however.
What's a reasonable amount of DV here?
-
16 minutes ago, Clayel said:
It's probably the second one, I had about 7 or 8 waypoints in a 20 year transfer window. What would you say is a good amount of waypoints for a complicated gravity assist route? (I was doing eeloo to moho but I couldn't find a good one after a lot of searching)
I would bet you could pretty easily do Eeloo to Moho with just a Jool gravity assist: Eeloo -> Jool -> Moho. Give that a try maybe?
QuoteI also have a suggestion, you should allow a full stop of all runs in the multi-flyby maneuver seqeunce in case I notice that I put in something wrong and I have to manually stop all 50 runs before changing it.
This is a good suggestion. I'll take a look into adding this functionality.
EDIT: Implemented for next release.
-
14 hours ago, Clayel said:
Trying to calculate a gravity assist chain from Eeloo to Moho and I keep getting stuff like this, can anyone help?
This means that the solver could not find a feasible trajectory. Your problem is most likely one of two things. Either your departure window (upper and lower bounds) is too narrow or your trajectory is too complicated with too many way points and needs to be simplified. It's hard for me to tell with the image you provided unfortunately because I can't see the UI.
------------------------
In other news, with the upcoming release of KSP 2, I have been thinking about how I'm going to support it. I think, at least initially, all I'm going to work on is a new KSPTOTConnect plugin for KSP 2 that handles making the bodies.ini file and user upload of delta-v nodes. Any other functionality will have to be evaluated in the future to see if it's worth the time for me to get it into KSP 2. As always I'm open to suggestions and the like in this regard!
-
9 minutes ago, The Aziz said:
Or just a video being played, like every other time.
There have been images encoded in the background hum of that part of the video in previous videos.
-
Hi everyone,
I've built KSPTOT v1.6.10 pre-release 2. This is pretty minor but I had some updates pending that I wanted to make sure I pushed out so they weren't forgotten. On that note, if anyone has any bugs or suggestions to report, please let me know.
Here's the change log:
- LVD: Added new "LVD Console" tool (Tools menu -> LVD Console) that acts like a terminal/console and lets you interact with under underlying LVD data without needing to write a plugin to do it.
- Some performance improvements due to recompiling some MEX files.
That's all I've got. Happy orbiting.
-
3 hours ago, dlrk said:
In the RMS, what is the difference between the orbital epoch and initial epoch?
The orbital epoch is the time at which the orbit's Mean Anomaly is at. The Initial Epoch is the earliest time that the rendezvous could take place.
-
20 hours ago, TheUntitledGoose said:
A quick question is there any guide on how mission architect works?
There should be a tutorial that comes with the main KSPTOT download. You can check that out. That said, I would actually recommend trying to learn Launch Vehicle Designer (LVD). It's basically Mission Architect but way more powerful in literally every way. Feel free to check that one out too!
-
Tonight I've built KSPTOT v1.6.10 pre-release 1. Here's the change log:
- LVD: kOS control script now also takes with the CSV the orbit elements at the mission time so that it can display orbit element errors as a function of time.
- LVD: Now supports spherical harmonics gravity for the central body gravity.
- LVD: Added solar radiation pressure models (spherical and solar sail). Added associated UIs. Added event action to adjust SRP model. Added solar sail orbit raising example.
- LVD: Fixed bug with using the camera toolbar stuff causing errors and deleting context menus.
- LVD: Update initial state dialog to be a bit more compact.
- LVD: Added ability to view Drag Force in main view area.
- LVD: Added a Lagrange Point geometric point.
- LVD: Added height of terrain constraint + GA task, as well as height maps for all default bodies from Sigma Cartographer mod for KSP.
- LVD: Tons of performance improvements.
Please let me know if you have any questions or find any bugs! Happy orbiting.
-
On 8/21/2022 at 12:31 AM, TheUntitledGoose said:
Hello! As I've became a bit more experienced at the game and the tool, I was wondering about how you made your ship look at KSC using kOS.
I assume you're talking about that video I put up a year or two ago on Vimeo. It actually was pretty easy. In Launch Vehicle Designer, I created a custom reference frame with the spacecraft at the center, the X axis pointing from the spacecraft to KSC, and the Y axis pointing from the spacecraft to the Sun. I then used that reference frame to steer the vehicle, just setting the steering angles to 0 deg right ascent and 0 deg declination.
To get that into KSP, I used the LVD function which creates a special CSV file that is read in by a kOS script that comes with KSPTOT. That does the steering in KSP. Let me know if you have any other questions!
-
Just now, Drew Kerman said:
so this requires which mod(s)?
I believe the only solar sail mod I could find for the most recent version of KSP is Photon Sailor. I don't support the "giant laser from KSC that pushes you along" bit from that mod, but my stuff should handle the actual solar radiation pressure bit just fine.
[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]
in KSP1 Tools and Applications
Posted
Pretty sure I've got this one fixed but I'll check next week when I have more time to use KSP.