fibonatic

I do not think so, since having to deal with orbits which might not be stable over a long period can be annoying in terms of gameplay, because you can only control one craft at the time. And as simulations have shown, not all moons of Jool are stable. I am unsure if there might be a possibility for any of the unstable moons to collide with any other body (or probably pass through each other) and I am unsure how the physics engine would handle such an event. So at least the N-body gravitation implementation would significantly affect the gameplay. The improved integrator on the other hand would nice to have in stock instead of the default unity one, since it does not really affect gameplay besides making the physics calculation more accurate.

I came here to say basically the same things. Here are some of my comments/arguments: 1) There are already quite a few categories, such as bases already have their own. But I agree that for the probes contracts it would be nice to have an extra category, which will automatically be assigned to that probe when the contract is completed. 2) I think this has been mentioned before (at least on reddit) but it would also be nice to see an image and its info (like when you mouse over in the VAB or SPH, such that you known its mass) of the part testing contracts. And besides place satellites orbits it would also help if your suggestion would be applied to visual surveys, temperature scans, ect. Because especially with those on Kerbin it would be nice to know where they are, since after you have done a few some of those contracts, new contracts sometimes are basically positioned at the opposite site of Kerbin relative to the space center and those contract are a lot harder/take longer to do with airplanes. 3) I am also an advocate of this idea, but besides being able to hide them both separately, it would also be nice to be able to distinguish them when both are visible. Maybe by giving the offered contracts a higher transparency/lower brightness and/or giving them a dashed outline. Since these suggestions only apply to the tracking station and mission control, I would therefore also like to give some suggestions for the contracts UI while controlling a craft. 4) I often tend to do have multiple crafts fly at the same time and let each one of them complete multiple contract, to maximize the profit, optimize usage of in-game time and adding an extra challenge of managing/planning them at the same time. This however does often means that I have quite a few contracts open at the same time, so it would be nice to filter them (with this I mainly mean the list of contract information in the top right). I have two idea to filter contracts, namely filter them based on the SOI you are in, or assign contracts to crafts, which would mean having a list of assigned contracts for each craft (but it should be possible to assign multiple craft to the same contract). It would also be an option that if you would click on the marker/orbit in mapview (or part for part testing contracts) you would be given the option to jump to the information of that contract, however this does not enables you to easily see flag planting or science gathering contracts.

Actually L1, L2 and L3 are unstable and L4 and L5 are stable: "The triangular points (L4 and L5) are stable equilibria, provided that the ratio of M1/M2 is greater than 24.96". All Lagrange points have the property that you remain still relative to a rotating reference frame and thus also relative to the barycenter, however their stability refers to a convergent, or at least not a divergent solution when an object gets perturbed at one of these points, such as the (weak) pull of another celestial body. Horseshoe orbits will also be interesting to observe in such an reference frame, but this is basically also an orbit but around multiple Lagrange points (L3, L4 and L5).

If you would read the first post you would know that the plan for this mod also includes N-body gravitation. And like Dragon01 already stated, on rails planets requires you to solve Kepler's equation which has a trigonometric function in it, but also has to be solved numerically, such as Newton's method, which would require multiple function evaluations. I am not sure if squad is being smart not to solve this for bodies which have a circular orbit (eccentricity of zero), like Kerbin, Mun, Minmus, Laythe, Vall and Tylo, however for circular orbits you would still have to use trigonometric functions.

I am not sure what is meant by fixing the barycenters: If it is referring to viewing the orbital elements as seen from the barycenter, then according to my simulations this does not fix it. Or is it referring to fixing Jool onto the barycenter and thus Jool would not experience any forces from its moons? If physical parameters would have to be changed I would prefer not to change the difficulty relative to the stock game. Changing the mass of one or more moons would affect this, so I would prefer not to do that, however it is already impossible to land on Jool itself, so increasing its mass might be a possibility. Another possibility might be increasing the inclination of one or more of its moons, however this will affect the difficulty to transfer between them. The main problem is that Vall has a resonant orbit with Laythe and Tylo and gets kicked out by them (mainly because its mass is an order of magnitude lower). These moons are analog for Io, Europa and Ganymede. However according to this sheet of orbital elements the phase difference does not match the phase difference for 1:2:4 resonance. To fix this I set the mean anomaly (at epoch) from 0.9 to 3.14-pi=0.0016. This in combination with orbital elements interpreted from the barycenter, as stated above, it not yet enough to make them stable. My next attempt involved increasing the mass of Jool, also because this is an analog for Jupiter, which has relative to the sun and Earth a bigger mass than Jool has to Kerbol and Kerbin, this is namely of by a factor 4. However increasing the mass of Jool by a factor 3 already seems to make Vall stable for 63.4 years (2e9 seconds). Another option would be increase the inclination of Vall. Due to the resonance Vall should always have close encounters with Laythe and Tylo in one spot in its orbit and with the corrected starting mean anomaly the close encounters with Laythe should be 180° away from those with Tylo. So by placing the ascending node of Vall between those two points of close encounters should allow me to increase the distance of both close encounters when increasing the inclination. However after increasing the inclination up to 90° still do did not give an stable configuration. So concluding I would suggest that increasing the mass of Jool would be the way to go. If you want to keep the orbital periods the same as stock you could also increase the semi-major axes of all moons of Jool, this should not affect stability.

Thanks for replying to my posts. Every thing I know about Kepler orbits is mainly self-taught so I am not very familiar with the usual notation. I mainly base my calculations and equations of Newton's law of universal gravitation, Newton's second law and Kepler's laws. By the way my posts where about finding a stable configuration of the three heaviest moons of Jool. A related question on stackexchange asks why three Galilean moons around Jupiter, with 4:2:1 resonance, are stable. It does not have any answers, but it does has a comment with a few upvotes which is linking to a document about this. I have only skimmed through this documents and did not see anything about weight ratios. Maybe this is because it is only about Galilean moons, so not the general 4:2:1 resonance situation.

I am still not convinced, since none of your sources explain why G(m+M) is used. This is how I derived my expression for μ: Suppose you would like to construct elliptical orbits, with eccentricity e, of two body with mass m1 and m2, with a given semi-major axis a1 relative to the barycenter (a2 can be derived from m1 and m2), which initial conditions would you have to give them, assuming that the barycenter would be the origin of the coordinates system? For simplicity I will limit this problem to 2D (so inclination can be ignored), use an initial true anomaly of zero, and choose the longitude of the ascending node and argument of periapsis in such a way that unit vector of the initial position will be equal to the x-axis. The initial positions will be simple, namely: x1 = a1 * (1 - e) y1 = 0 a2 = a1 * m1 / m2 x2 = -a2 * (1 - e) y2 = 0 The initial velocities are harder, for this I will initially use μ1 and μ2 as temporary variables, which will have to be solved later. By using the following equation it can be shown that: vx1 = 0 vy1 = sqrt(μ1 * (1 + e) / (a1 * (1 - e))) vx2 = 0 vy2 = -sqrt(μ2 * (1 + e) / (a2 * (1 - e))) The total momentum should be zero (barycenter is stationary), so m1 * sqrt(μ1 * (1 + e) / (a1 * (1 - e))) = m2 * sqrt(μ2 * (1 + e) / (a2 * (1 - e))) m1^2 * μ1 / a1 = m2^2 * μ2 / a2 m1^3 * μ1 = m2^3 * μ2 From these equations it can already become clear that μ1 = μ2 = G * (m1 + m2) is incorrect. To derive the equation, which I mentioned in an previous post, I will use acceleration and the fact that r1 / r2 will be constant. r1 / r2 = m2 / m1 F = G * m1 * m2 / (r1 + r2)^2 acc1 = G * m2 / (r1 + r2)^2 = G * m2 / (r1 + r1 * m1 / m2)^2 = G * m2 / (r1 * (m1 + m2) / m2)^2 = G * m2^3 / (r1^2 * (m1 + m2)^2) acc2 = G * m1 / (r1 + r2)^2 = G * m1 / (r2 * m2 / m1 + r2)^2 = G * m1 / (r2 * (m1 + m2) / m1)^2 = G * m1^3 / (r2^2 * (m1 + m2)^2) μ1 = G * m2^3 / (m1 + m2)^2 μ2 = G * m1^3 / (m1 + m2)^2 When using these equations for μ1 and μ2 it will be clear that the total momentum will be zero. EDIT: I also found out that my integration method, also called position Verlet, is actually not symplectic because it does not use velocities (I am still a noob when it comes to symplectic integrators).

I copied to names of the elements from this google document, which uses that name for that column, without thinking. The top name actually does state "Argument of periapsis", however its abbreviation, LPE, seems to suggest longitude of periapsis. You are totally correct, I often switch those two (true/mean), however since most eccentricities are low (or even zero) and most starting mean anomalies are close to zero or PI, then the true anomaly will not be that different or in some cases equal to the mean anomaly. I have implemented the correct anomaly into my script now. Are you still referring to the mistake between true and mean anomaly, since cos(A(i,7)) is in the denominator? I used these equations I derived a while ago, which I think are correct. These equations can be simplified down to this: Again I used the mean anomaly instead of the true anomaly, however I did this consistently, so only the starting true anomalies of a few celestial bodies where off, but the other orbital parameters should be correctly translated. To be sure I also checked whether my approach gives the same results for position and velocity components as in document you linked to, by expanding all the vector products. My final results match, however I do use a different definition for μ. For my definition of μ I assume that the semi-major axis is given relative to the barycenter of that body and its parent body. Because for orbital elements the fictitious parent body lies at the barycenter, thus I changed μ to such a value that the gravitational force of this fictitious body would be equal to that of the actual parent body. The resulting μ then becomes μ = G * M^3 / (M + m)^2. I do remember seeing μ = G(M +m), however I good not think of a logical argument why I should use it.

I implemented Störmer-Verlet method: Xi+1 = 2 * Xi - Xi-1 + A(Xi) * h^2 with a step size as small as 10 seconds in MATLAB. I do have some about whether I implemented the barry-centric initial conditions correctly. I am not 100% sure if I even converted the orbital elements correctly in to positions and velocities. But here it goes, I assumed that the semi-major axis is measured from the center of mass of the it and its primary body, so Jool in this case. This means that the actual distance between the moons and Jool is bigger than their semi-major axes, namely by a factor 1+m/M, where M is the mass of Jool and m is the mass of a moon. I incorporated this an effective gravitational parameters of Jool for each moon: GMeff=G*M^3/(M+m)^2. I even tried to set their orbital periods to exactly 1:2:4 ratios with: SMA_vall = SMA_laythe * (2 * (M + m_laythe) / (M + m_vall))^(2/3) SMA_tylo = SMA_laythe * (4 * (M + m_laythe) / (M + m_tylo))^(2/3) I positioned all moons relative to (0, 0, 0) after which I placed Jool in such a position that the center of mass of all moons and Jool is positioned at (0, 0, 0). When calculating the velocities I also used the effective gravitational parameters. When defining the volcity of Jool I did something similar as with its position, namely I set total momentum of the Jool system to zero. After all this I added the position and velocity of "Jool" relative to the sun to each body of the Jool system. For the inital two positions I used: X1 = X - V * h/2 + A(X) * h^2 / 8 X2 = X + V * h/2 + A(X) * h^2 / 8 The actual function which I used for the initial conditions in MATLAB can be found here.

I was playing with simulations of the solar system of KSP. With this I also tried to get Vall to stay. For this I initially tried to use barycentric orbital parameters, but it did not help. I think that the masses of the neighboring moons are just to massive compared to the mass of Jool. For instance in a real world example of 1:2:4 resonance with Jupiter's moons Ganymede, Europa and Io, their mass ratios are in the order of magnitude of 10000, while those of Jool's moons have ratios in the order of magnitude of 100.

I have not looked at that, I will try to check that out. Another option might to to just interpolate, since currently I only use 136 elements between which I already interpolate. I might even switch to quadratic elements (instead of linear) in my solver, which might allow me to reduce the amount of elements even more. And using variable spacing of the elements might also help reducing the amount of elements. PS: my kOS scripts basically has no comments. I intended to add them later (initially I just wanted to share it as soon as possible). However once I realized I made a mistake in my model, used to generate the launch path, I wanted to implement the new trajectory and have not got around to add comments.

I just discovered this thread and the idea sounds really interesting. I have not read all pages and only did a quick search and did not find anything similar, so excuse me if this has been suggested before. If we would like to qualify for a free ride then the cubesat should have some educational value. And one thing that came to mind was to see if a generated magnetic field has an impact on the radiation level. I did a quick search on the internet and only found this article but nothing about actual tests. What this would add in terms of hardware would be a geiger counter and a coil.

I tweaked my solver a bit, instead of searching between locked velocity bounds I now search between the initial value plus or minus a given value, which can be varied. This gives a result of 4297 m/s (it will get close to 4290 m/s if I set the termination criteria a lot tighter but it takes a lot longer). The resulting thrust and angle graphs look as followed: In these results the gravity turn happens much more gradually. I have not managed to find a good fit for these results which I could use in kOS (I initially tried a Fourier fit, however kOS seems to take a lot of time calculating 8 sin and cos terms resulting in a lot of delay in the control). PS I actually have not seen any results for other planets with atmospheres, so I thought I might as well be the first. For the launch height and target orbit I choose values which seemed realistic. For example when landing on Duna you want to use the atmosphere as much as possible and thus launch from a fairly low altitude, while for Eve landing is not the issue however picking your landing site can be hard so I used a value which was not to high and for Laythe I also used a low value since it will be very likely that you will land near a coast. For the orbital heights I just added a few kilometers above the atmospheric cut-off altitude. [table=width: 600, class: grid] [tr] [td]Celestial body[/td] [td]Launch height [m][/td] [td]Target orbital [km][/td] [td]Delta-v [m/s][/td] [/tr] [tr] [td]Duna[/td] [td]500[/td] [td]45[/td] [td]1275[/td] [/tr] [tr] [td]Eve[/td] [td]3000[/td] [td]100[/td] [td]9810[/td] [/tr] [tr] [td]Laythe[/td] [td]500[/td] [td]60[/td] [td]3200[/td] [/tr] [/table] The graphs for these results can be found here. Of course when designing rockets you would want to minimize the amount of mass used and thus is engine dependent, but these results might help as a guide when designing rockets, such as TWR and a rough estimate of how much delta-v would be required.

I should also have specified that the two velocities are relative to the orbital velocity. And the term which "takes care" of Coriolis also means that, if no other forces are applied, angular momentum is conserved. So without that term in my model a normal elliptical orbit would not even be possible, since v_theta would stay constant, while v_r would change. So I indeed would have a to high orbital velocity according to my old model when I would reach apoapsis. But with these eoms you do have to prevent that the radial velocity becomes zero.

The centrifugal component is the final component of the top equation, however it might be confusing because I divided everything by v_r. The same goes for Coriolis effect, but I did assume that the trajectories always stays on the plane of the equator. And to clarify ̉ۡs is the sidereal angular rotational velocity of the planet. However I do would like to thank you because I did forgot to incorporate the Coriolis effect in my model which did change my predicted optimal solution (closer to the values of my experimental results).

I have come up with the following equations of motion: Where C is variable containing all drag parameters and alpha the applied acceleration by the engine(s). I also used this to solve for an optimal solution numerically and got 4200 m/s for a 75 km orbit. I also tested this in KSP with the help of kOS, but was only able to reach orbit with ~4300 m/s.

I did a lot of testing, especially with the controller. My first try contained feedforward and only a P controller, however it turned out to be better to use less feedforward (I only calculated which acceleration would be needed to counteract gravity, drag and centripetal force) in combination with a PID controller. I also added some extra term to the radial velocity. Here is a sample video of a rocket with constant Isp (always 390 s): It used 4326.533 m/s of delta-v (KER says 4322 m/s, but I think that it uses g0=9.81m/s^2, while it should be 9.82 m/s^2) I also played around with the thrust to weight ratio at the launchpad by further editing the config file of the engine and got the following fit from it: For infinitely large TWR it seems to approach ~4303 m/s. I think that this figure might also be useful when designing rockets, such that you can find a balance between using a lot of engines such that you have a good TWR or less engines to save on mass. This is an improvement from my first take (4350m/s) but still not my predicted 4200 m/s, but still not bad results. EDIT: I just found out that I used an incomplete model for my solver (I forgot the Coriolis effect in the tangential direction). After adding this to my model I got 4325 m/s, so my tests in KSP did slightly better, but reasonably close enough.

I have a working kOS script and my first results tell me that my test ship used 4330 m/s of delta-v, which is 135 m/s more than predicted. One of the sources which will lead to higher delta-v consumption is infinite TWR at launch, which is assumed (the ship instantly reaches roughly terminal velocity). The ship I used had a TWR of 2.8 at launch. Another source might be that I did not worked out the derivative of the velocities to find the target acceleration, but used central finite difference (with h=0.5 meter and x is the radius). I also looked like the apoapsis during the ascent was getting to high, so I used another script to circularize. While coasting towards apoapsis while above the atmosphere it also becomes clear that KSP probably has insufficient "simulation" accuracy, since I see the apoapsis height the predicted by KER slowly drop while not in time-wrap (I would suspect that the physics engine of KSP uses Euler integration). I did these tests on my laptop. When I get the change I will also do some tests on my desktop PC and probably also record a launch and post it here. If anyone want to mess with kOS, here is my script (It does not have any comments but I hope most of it will be clear).

I do remember that abbreviation when looking at solvers, but I am not sure why I did not look into that one more. Maybe it was because I also wanted compatibility with Matlab, since that allows me to display and manipulate results very easily, however I think that PSOPT also can also be used with Matlab. Thanks, I will definitely look into PSOPT some more, but I am also glade that I came up with my own approach, since I also learned from it. I was more referring to that the "noob" launch path is vertical up to 10 km and then tilt 45°, so I thought it was worth mentioning that that altitude is some kind of tipping point. I was trying to look for an easy way to import my trajectory into kOS. Instead of copying all my points I thought I should just use equations, which fir on the data. I also tried to think about how to control this in KSP. The main control parameters are your throttle and your pitch, so I tried to fit my total surface velocity and the angle of the velocity. Finding a good fit took a little bit of work, but I succeeded. After this I also wanted to check if the fit did damage the required amount of delta-v, but it turned out to be slightly lower, namely 4195 m/s. Those fitted parameters might be able to be tweaked and maybe even reduce the delta-v even more, however I will leave that for now and I will first focus my attention on getting this to work in kOS.

I do not have access to good optimal control solvers (tried ACADO), but since I also would like to understand the algorithm behind the solver I thought I would come up with one of my own. I haven't had any courses about optimal control during my study, so everything I kown is self-taught. Initially I came across the Hamilton Jacobi Bellman equation, which seemed applicable to this problem, however it did not bring me any closer to a solution, neither analytical nor numerical. My next idea was to see if I could get an analytical expression from the integral, which calculates the total expelled delta-v, using this expression: by using a polynomials for the velocities and then derive this expression for every coefficient to find for which values for the coefficients the integral would yield the lowest value. However no general equation for the integral seems to exist. After this I gave up on the idea of finding an analytical solution and came up with a finite element like method. For the velocities I used a finite amount of control point (for now evenly distributed with hiehgt) and interpolated between them. And to find the optimal trajectory I applied Golden section search on the velocity of every point and repeated this until solution does not change much any more. There is a little bit more to it, such as the boundaries, since I assumed that the TWR is not restricted and therefore the rocket could undergo an instantaneous velocity change at launch and circularisation. The optimal solution does gives a promising minimal amount of delta-v, namely roughly 4250 m/s, this is for a launch from 70 m (launchpad height) at the equator to a 75 km circular orbit. The velocities as a function of radius look as follows: The thrust, in terms of acceleration, as a function of radius looks as follows: The total acceleration clearly drops down after an altitude of 40 km, therefore I will also use this as a cut-off value for angle of the thrust in the following graph (since for low thrust levels the angle does not mean much). The following graph shows the angle of the thrust and the total velocity relative to the surface as a function of the radius: It is interesting to note that there is a very notable sudden change in angle a little bit before 10 km. However what I can not explain is why initially the angle is negative (moving against the rotation of the planet). I might try to implement this trajectory in KSP with kOS and test this in-game. PS: I might also post similar graphs for other planets with atmospheres, such as Eve, such that we could also compare our solutions for other bodies.

I have been playing with this mod for the last two days and is really awesome. However I would really like some more documentation, since I often try to combine code from different included bodies. And can someone explain what GeeALS means. An idea I got was that it means surface gravity but I am not sure. I would find it easier if I could set the radius and the mass or the gravitational parameter, since I assume that the SOI is defined as: PS: Here is a planet I designed (with Photoshop and Blender): However I have not been able to view this in KSP. For the texture I just made a 3D sphere in photoshop and rand the Difference Clouds filter a couple of times on the sphere and then changed the color range of the texture with some other filters and added some cracks with a brush.

I really like this mod. Just tested to see if it also does the Dzhanibekov effect (a.k.a. the tennis racket theorem) during time warp. I did not expected it to work and it did not, as can be seen in this video: I also do not think that this mod should though, because I do not think it has any real applications and most crafts might not even have an unstable axis of rotation.

I agree with mhoram about your formulation of acceleration. And your integration method is called explicit Euler method, which is probably the most intuitive and easy numerical integration method, but also one of the least accurate with a global error proportional to your time step-size. There are a lot of different numerical integration methods for ordinary differential equations out there, a well known family are the Runge–Kutta methods, which can easily get a global error proportional to your time step-size to the power of 5. So by decreasing your time step by a factor 1/2 will increase your accuracy by a factor 2^5=32. And there are even methods which have dynamic step-sizes, which will reduce your number of calculations while in a relative "smooth" part of your simulation. It is correct that you need a TWR higher than 2 to maintain TV, since the TV will increase with altitude, which means you need extra acceleration to achieve the new TV. (gravity will also decrease but a lot slower than the increase of TV). PS: I have tried to tackle the 2D optimal ascent trajectory my self using the toolkit ACADO[\url] within MATLAB, since I also would like to know what good ascent profiles are on other atmosphere bearing celestial bodies. These are the differential equations: where v_r is the radial velocity, r the radius, v_theta the tangential velocity, omega_s the angular velocity of the surface/atmosphere, mu the gravitational parameter, alpha_r the applied acceleration (force per mass) in the radial direction, alpha_theta the applied acceleration the tangential direction, H the scale height of the atmosphere and C a composed drag parameter (which removed the need of exp(r0/H)). However every attempt of a script seems the have the problem that it ignores all/most constrains, such as final radius and velocity or just jumps to it on the final step.

I have got the same issue with the current version 0.6.2.1 (also had it with the previous one, but did not play that much KSP lately). It started when my computer crashed due to overheating. Now KER does not work anymore when building, so calculating the delta-v. But after reinstalling (pasting) KER it worked again. But I do wonder what is causing this.

I do not think that this should be part of the vanilla game, since it seems cheating because it hectic situation, in which an actual astronaut has to think fast, you would just be able to slow every thing down and react without a sweat. However I do think that this adds value to people how want to take cinematic shots or want to render in good quality, but either do not have enough computing power or a huge craft. So if it would bet implemented I think it should be a toggleable option in the debug menu.