DBowman
-
Posts
648 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by DBowman
-
shhhhh!
-
I think it would be a huge boon for both players and sales!
-
Fantastic! thanks for sharing that.
-
@The Aziz Window planners and porkchops etc. are great, and I'm not saying don't add them. But the players will already know the maneuver node mechanic, so why not make it a little more general to expand it's utility? If I recall right, dragging the node also shows you celestial body positions at that time, so players would get a visceral appreciation of the synodics rather than magic numbers dropping out of an oracle. @mattinoz I don't think a node has to be bound to a vehicle, it's natural to think "if I was in the solar orbit of the planet what would happen if I burned like this". Also orphan/ghost nodes are useful, I often found myself playing around with nodes for satellites to plan trajectories for ships, why not just skip the middle man and drop an orphan node. The ability to use a rendezvous to see you are in phase to burn is actually pretty useful.
-
An easy way to plan Mun mission is to be in LKO, drop a maneuver node, drag the prograde till the propagated orbit kisses the Mun orbit, then drag it forward in time until it gets a Mun encounter, and fiddle it to tune. Using this method you can easily plan even a free return "by the seat of your pants". You cannot use the same method for interplanetary transfers, but if you gave some maneuver node behaviors to celestial bodies it would be that easy. Select Kerbin, drop a node, prograde till it kisses Duna orbit, ... At the end you'd have a time for a transfer window, and a delta-v (from heliocentric orbit, so you have to adjust somewhat, it's a guide). You can even seat of the pants the adjustment if you could set a vehicle node time to match the Kerbin node transfer, fine drag it to be at midnight (for outer bodies), set the prograde to the Kerbin node value, and tweak it down from there. Even "ghost nodes" make sense; drop a node in LKO and do the above to do preplanning without a vehicle, if you later rendezvous with the ghost node you know you are in phase to burn at the right place at the right time. (the node back propagates for the encounter detection) Reusing the concepts and code would deliver a lot of power for the players. This is really nothing more than we have now, just accessible in a new context.
-
I've had some reasonable success with LDV (achieved orbit, and able to improve excess prop via optimizing), but my method is a bit "brittle", and I really want to find a global maxima, not the local one I was near. Could you advise me on a more flexible way to get it done? My current method is to have a few "pitch segments" which I setup by hand (intending to let the optimizer tweak them later), the last one has -ve pitch and terminates when Ap alt reaches 250 km. The optimizer then controls pitch and duration for the circularization burn at Ap. If I (or the optimizer) tweaks one of the pitch segments "too much" the desired Ap is passed before the event that terminates on reaching Ap - so it never terminates. Adding a constraint on Ap alt doesn't seem to help. I guess I don't know how to tell it that it's a infinity weighted importance, and if it did bail it wouldn't have a gradient to follow (if that's how its' working). How should I approach it? Like the tute doc? 7 pitch segments and constraints on (C3 & Ap alt or Pe alt), (speed & Ap & Pe), something else? How close do the initial pitch segment settings need to be for the optimizer to "find something"
-
I have no problem with that! (well it's a bit tedious when you consider all the shiny math deriving the plot itself, maybe the data tip should have the UT seconds also? but I can do the KSPTOT date to UT seconds conversion no problems) With 365 days the KSPTOT year matches the UT seconds of the other tool. So that is excellent. Can I ask what the porkchop does re the inclination of E & C? I'd assumed, and am really hoping it respects the inclinations and isn't simplifying to coplanar.
-
Hi, sweet work with the textures. I have a hand crafted MAV trajectory that I can tweak within limits and see on the order of 5% prop use efficiency, the optimizer only sets the "get Ap pitch" and final circularization pitch and duration. if I push it too far the termination conditions don't happen at the right time and I have to rejig it manually. It's okay for now. I treid again with linear tangent, it cheerfully gives me a burn at 89 degrees all the way, I cannot figure how to tune the parameters so it's close. But the pitch program version is okay for now. Topic shift to Ceres. I'm trying to cross check KSPTOT porkchop against ATK STK and looking at UT it looks like they match, but the year seems odd. I have some independently derived EC trajectories, someone else did via ATK STK, with 180 day transit for 77 km/s total at UT 2466168.5, which they say is 15-Jan-40. https://www.aavso.org/jd-calculator will spit out the UT when prompted with 15-Jan-40. I did a porkchop plot and I can see that UT is right on a chop, and measuring by eye the x axis I can see trajectories like theirs (caveat they have departure and arrival orbits but your pork chop is just from "plant to planet"?) but the year in the tooltip is 6758, at 365.25 d/y shouldn't it be 6752? How do you work the "enter UT as date/time" I cannot get it to accept anything that is not interpreted as seconds. Any chance to have it show "regular" dates (also)? there is a screenshot here: https://drive.google.com/file/d/1zn3a2lxUGm0HyLrfLfr_ZecfByOElgrL/view?usp=sharing
-
Ah! awesome! now I see that I am launching due North man... (assuming planet blue arrow out the top is N) during the big coast to Ap roll and yaw angle both seem to flip between 0 and 360 randomly, I guess that doesn't really matter, but at the Ap burn they are both somehow set to 180, which I guess explains the "retrograde burn", I'm upside down and going backwards for some reason. Setting roll to constant 90 in initial steering model and having "continuity" checked only seems to effect the first event duration. After that I see roll = 90 in the graph but the trajectory starts heading North. I'll take another look at the example you gave me. Not going polar should also help the prop consumption... I set roll angle to 89.99 on all my steering models, it stopped the flipping, at the end of the coast to Ap the yaw sets itself to 180 even though the steering model box says RPA 89.99, 188.7, 0.0
-
NASAs POST2 - I guess giving away hypersonic trajectory simulators is not the done thing. Thanks for the RSS bodies.ini and your inputs. I managed to put together a .mat that gets into a 250x250 LMO with aero effects. I put some graphs and the .mat here (https://drive.google.com/file/d/1qaKIbTivOiqO-_CpD4lk8BKI5d9s9SGt/view?usp=sharing) Good things: 700 kg dry + 2-ton prop gets up with 47 kg prop left over. maxQ 170 Pa. Without the first event 10 km vertical it's 250-ish so aero acts like I'd expect. My bads: you can see after attaining Ap=205 km it decays a few km, the Ap is attained too early. The optimizer should be able to fix this right? Weird: look at the burn at Ap I had to make it optimize a pitch around 180 degrees, which sounds to me like retrograde burn, but it has a prograde effect. What is pitch exactly relative to? I assumed it was the ground radially beneath you? Oh and what's up with the LVD GUI? Sun and Mars? That happened after I set the vehicle initial state to be Mars not Sun. It's not important, but the plot with the planet and trajectory is cool. I feel like I can massage the .mat to get better performance out of it. My plan is to have "optimizer pitch rate and fixed target" events so there is just one thing in each even t for the optimizer to tweak. Prefixed with an "optimize pitch rate and target altitude" event. I kinda feel like I'll have to hand craft the parameters to be "close" and then the optimizer tunes from there? But maybe that means I only get a local optima? Any and all advice or inputs gratefully accepted. cheers!
-
I just want to get a sanity check on the ascent + aero-effects, I thought RSS might not be as sensitive to some parameters are LVD. NASA papers always reference a "protected" sw package that only gov employees "with a good reason" can get access to. One of those cases where you have an idea and keep following the loose ends.
-
I recall, since I need Mars you are thinking RSS or Copernicus data will be okay? I've no idea how suitable their temp & sun mult data is. I have Mars (alt,temp) data, but not yet sun mult
-
okay thanks, do you know what these represent? some googling => "something to do with scattering" (from Kerbin) atmoTempSunMultAlts = 0.00000000000,8.81521972656,16.05038867188,25.72923437500,37.87944140625,57.44012500000,63.90271875000,70.00000000000 atmoTempSunMults = 1.00000000000,0.30000001192,0.00000000000,0.00000000000,0.20000000298,0.20000000298,1.00000000000,1.20000004768 https://github.com/KSP-RO/RealSolarSystem/blob/master/GameData/RealSolarSystem/RSSKopernicus/Mars/Mars.cfg has some data for Mars, do you have a better source?
-
I coded a pitch program by hand. Pitch hard, Pitch gently till Ap hits 250, coast till at Ap alt, optimize pitch and time for circularizing burn constrained by semi major axis. That gets a 700 kg vehicle up with 740 kg of leftover prop from 4-ton initial, so I figure it's putting into orbit double the mass it needs to, so probably 2-ton of initial prop is enough. Maybe even better if/when I figure out how to optimize the pitch segments. Seems like one advantage of the linear tangent stuff is a smaller number of optimization params, and that they are more naturally linked by partial derivatives? Time to try out the plugins! Can you tell which of these I don't need to fill out for aero to work? (I'm guessing I need molar mass (at 0 km)) atmoTempAlts = 0.00000000000 atmoTempTemps = 0.00000000000 atmoTempSunMultAlts = 0.00000000000 atmoTempSunMults = 0.00000000000 latTempBiasLats = 0.00000000000 latTempBiases = 0.00000000000 latTempSunMultLats = 0.00000000000 latTempSunMults = 0.00000000000 atmoMolarMass = 0.0
-
So many problems! Thanks for looking at it for me. re #4 rocket equation and references for LMO mean thrust and prop should be okay or close, but that's why I want to simulate with gravity and aero. I've been playing around with the .mat you provided. I cannot get it to not push Ap out to 450 km before driving it back down again, which tells me it's way off optimal, the pitch control seems to vary only slowly at first, but my gut says pitch over hard early and ease back the rate of change. The graph of Dynamic pressure doesn't start till t=270, which is about where it get out of the atmosphere (atmoHgt=180) - seems odd. There are no errors in the log about troubles computing dynamic pressure. Maybe I'll go back to trying a piecewise linear pitch program?
-
Okay I loaded a SolarSytem bodies and tried to recreate your Mun LDV, but for Mars. I have shared them here https://drive.google.com/file/d/1ae2BXL5JWITsOJX5t4bo2M37uDKTSQ8z/view?usp=sharing well it seems to kind of end up somewhere... but I cannot figure out what is going on Could you please take a look and see if you can help me out? I'm shooting for a 250x250 LMO
-
Ah, that is kind of what I was afraid of. In my case it's not too bad, the mission is a few actions/events and my vehicle is simple, but it would be hard on someone doing something complex and finding a trivial error in the bodies file. I guess the "hack" you suggest would cover simple point errors. Thanks for your help. I'll start one from scratch in RealSolarSystemBodies.ini. Do you want to take contributions to fleshing out the real solar system? Mars pressure heights? Are the atmos temperatures likely to be significant? Mars is pretty thin? I just want to see an SSTO get up Ceres I have in mine now.
-
Thanks 2: yep I'd figured that out 1: parentID missing for Jupiter out, so I fixed those. Start KSPTOT: SolarSystem in porkchop plotter, open LVD: SolarSystem in vehicle initial state set frame options, Load your Mun .mat: KerbalSolarSystem in vehicle initial state set frame options. Um so how does one replace the solar system in an existing mission design? Do I need to start from scratch, replicating your mission .mat but in RealSolarSystem? Does that mean that if one is in the middle of designing a complex mission and discovers a small error in bodies (e.g. some pressure height error) then one has to start over?
-
Well, learning about what's wrong and how to see what's wrong, but still stuck... I added a "Drag" sequential even to turn it on, I didn't see where you had turned it off. Using the graphs I can see that the vehicle starts at 0 and sinks from there. The pitch angle is a constant 85 degrees, which seems "okay for now". I looked at throttle and it's set constant at around 22%, so the TWR starts at 0.265 and increases as prop is burnt. 3 t m0 so for Mars 11,133 kN required for TWR 1, throttle 0.22*35kN = 7,700 kN should be higher than 0.26 TWR. hmm Atmospheric pressure is 101 kPa. So it looks like it thinks it's on actual Kerbin, even through I am pretty sure I loaded up a bodies.ini where Kerbin had Mars data pasted over it (because of the hang when starting with ). I quit out completely. Started KSPTOT. Loaded Mars bodies. Started LDV, it said "trying to do something with parallel workers", I could see the initial SMA was 1600 odd which fits Mars, when the workers dialog disappeared it did some calcs, and SMA had changed to 300 - fitting actual Kerbin. Does the LDV or the mission somehow have some cached bodies info? I reset the vehicle initial state frame to Mun then Kerbin again, it "finds" KSP Kerbin SMA. Place a SolarSytem bodies.ini in the directory, restart KEPTOT. Load bodies.ini, see Earth and Mars in the porckchop window, compute a porkchop fine, start LDV, the please wait dialog pops, ..... seems to hang I put bodies.ini and MMAV.mat (your lunar thing minimally modified) here https://drive.google.com/file/d/1JumVLQtyLIBADzxow4aRu5LKL3V0zAV-/view?usp=sharing log shows: Operands to the || and && operators must be convertible to logical scalar values. Error in KSPTOT_BodyInfo/getParBodyInfo (line 115) Error in KSPTOT_BodyInfo/getCachedSoIRadius (line 149) Error in getSoITransitionOdeEvents (line 31) Error in AbstractPropagator.odeEvents (line 81) Error in ForceModelPropagator>@(t,y)AbstractPropagator.odeEvents(t,y,eventInitStateLogEntry,eventTermCondFuncHandle,termCondDir,maxT,checkForSoITrans,nonSeqTermConds,nonSeqTermCauses,minAltitude,celBodyData) (line 61) Error in ForceModelPropagator/callEventsFcn (line 70) Error in LaunchVehicleSimulationDriver/integrateOneEvent (line 119) Error in LaunchVehicleEvent/executeEvent (line 162) Error in LaunchVehicleScript/executeScript (line 293) Error in ma_LvdMainGUI>propagateScript (line 175) Error in ma_LvdMainGUI>runScript (line 150) Error in ma_LvdMainGUI>ma_LvdMainGUI_OpeningFcn (line 123) Error in gui_mainfcn (line 220) Error in ma_LvdMainGUI (line 40) Error in mainGUI>launchVehicleDesignerMenu_Callback (line 916) Error in gui_mainfcn (line 95) Error in mainGUI (line 42) Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)mainGUI('launchVehicleDesignerMenu_Callback',hObject,eventdata,guidata(hObject)) Error using waitforallfiguresclosed (line 9) Error while evaluating Menu Callback. I added Kerbin to my Solar System bodies.ini - that let LDV start up. But the Edit Initial State set from options popup is full of KSP solar system! So I guess that is where the "cached Kerbin" was coming from?
-
Cool! I started it up. I guess it has bodies.ini built in? loaded the mun.mat fine, what is the orange plume? failed steering optimization attempts? At first graphical analysis plots of altitude seemed to show nothing, but after running optimize mission the plots all had data. hmm it wanted network access, said something about starting parallel workers, firewall popped, and it seemed to run anyway before I'd decided what to do. I copied your mun.mat, closed LDV, loaded my bodies.ini which has Kerbin replaced by Mars data, opened LDV, loaded munCopy.mat, edited vehicle initial state to set it's frame to Kerbin (Mars), zeroed out all the lat lon alt velocities that appeared, save & close. I get a warning that drag model is disabled on events that exist in the atmos (Event 1) and that Min alt -1.0 has been reached or exceeded. I can make #2 go away by setting alt to 100 km, but that makes #1 go away also like I'm above the atmos. I added an Action to set drag with even termination on sol transition (never) which made the aero warning go away - is that the right thing to do?
-
oh I think I've done a bad thing; I set LVD Maximum Script propagation time to 3600 (I was thinking five mins, but obv and hour), and I think now it's going to run for 6 more hours... Is there any way to interrupt it? Killing the prog will loose unsaved changes, I think I had been changing a sequential event and it had been throwing 5 second exceeded warnings when closing them. Obviously my fault, but what is it actually doing on each event close/save? Some of the GUI is live, and the task bar icon occasionally highlights. I'm playing with a Mars ascent vehicle.
-
Thanks for the Mars reply above. I've been playing with MFMS. I added Ceres from (https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=1&orb=1). This source has epoch in days, is that also what your bodies.ini uses? I can just use that epoch? Also I noticed that your GM for Jupiter is gm = 1.266865349218008E+08 but https://en.wikipedia.org/wiki/Standard_gravitational_parameter is E+17, I see a systematic E09 difference so I guess just different units? For your reference I added: [Ceres] epoch = 2458600.5 sma = 4.142612098521883E+08 ecc = 0.0760090265983052 inc = 10.59406719506626 raan = 80.30553090445737 arg = 73.59769469844186 mean = 77.37209751948711 gm = 6.26325E+01 radius = 469.73 0 for atmos stuff rotperiod = 32400 rotini = 0 bodycolor = bone canBeCentral = 0 canBeArriveDepart = 1 parent = Sun name = Ceres id = 559 I found a cool EVEC with E1 vinf 3.9 km/s and E2 vinf 11.2 km/s. The idea being use the low dV to set all the heavy stuff in motion, and then have crew jump on in a minimal vehicle at the E2 pass. From a 200x200 km orbit and using V^2=Vesc^2+Vinf^2 and V=Vorb+deltaV then E1 needs 4,060 m/s dV and E2 8,041. So we steal 3980 m/s from Venus, nice, it cuts propellant to 30% of just doing the 8 km/s burn. here is a screenshot https://drive.google.com/file/d/1Qq3hKmghJmy5AJk68NC3dZiiX6UnC1mo/view?usp=sharing But I'm not sure exactly what is being minimized. I had checked "include departure Vinf" and not "include arrival Vinf" - but what happens regarding the intermediate deltaVs at Venus and E2? there is about 600 m/s done on those flybys. Also, although I calculate by hand the deltaV for E1 as 4,060 m/s from the departure Vinf, MFMS shows 25,606.8 m/s departure deltaV (-3,000prograde, 20,000normal, 16,000radial) I figure if I set up my initial orbit correctly I could make that be 4,060 m/s. So I'm hoping the optimizer isn't looking at the 26km/s. Are you able to clear up my doubts?
-
I switched bodies.ini to the solarSystem version by changing file names and started KSPTOT, LVD seems to hang while opening with errors in the log: Error in KSPTOT_BodyInfo/getParBodyInfo (line 108) Error in getAbsPositBetweenSpacecraftAndBody (line 15) Error in getSoITransitionOdeEvents (line 29) Error in AbstractPropagator.odeEvents (line 77) Error in ForceModelPropagator>@(t,y)AbstractPropagator.odeEvents(t,y,eventInitStateLogEntry,eventTermCondFuncHandle,termCondDir,maxT,checkForSoITrans,nonSeqTermConds,nonSeqTermCauses,minAltitude,celBodyData) (line 61) Error in ForceModelPropagator/callEventsFcn (line 70) Error in LaunchVehicleSimulationDriver/integrateOneEvent (line 91) Error in LaunchVehicleEvent/executeEvent (line 157) Error in LaunchVehicleScript/executeScript (line 272) Error in ma_LvdMainGUI>propagateScript (line 171) Error in ma_LvdMainGUI>runScript (line 148) Error in ma_LvdMainGUI>ma_LvdMainGUI_OpeningFcn (line 122) Error in gui_mainfcn (line 220) Error in ma_LvdMainGUI (line 40) Error in mainGUI>launchVehicleDesignerMenu_Callback (line 916) Error in gui_mainfcn (line 95) Error in mainGUI (line 42) Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)mainGUI('launchVehicleDesignerMenu_Callback',hObject,eventdata,guidata(hObject)) Error using waitforallfiguresclosed (line 9) Error while evaluating Menu Callback. I hacked Mars data over Kerbin in the default bodies and LDV starts fine again
-
Is it possible to loose the modulo on the true anomaly, so it goes 359, 360, 361? or translate the "seam" 180 degrees from the termination condition?
-
thanks! I read the Solar System Edge tute, genetic algos, cool. I better play around first...
