Jump to content

Stract

Members
 View Profile  See their activity

  • Posts

    23

  • Joined

  • Last visited

 Content Type 

Everything posted by Stract

  1. Stract
    The departure time is the same. The predictions of MFMS are more or less close to MA but from time to time it is difficult to match the trajectories between them. For example, if MSFS requires 3500 m/s prograde burn, MA optimizer gives 3400 m/s prograde and 1300m/s radial for similar flight (departure and arrival times are the same). I've asked you after couple of fruitless hours I've spent trying to put this trajectory into MA .
  2. Stract
    Thanks! I see, it makes sense. Probably since SoI's in RSS are much larger than in stock KSP, the difference between MA and Flyby calculations is also larger.
  3. Stract
    Sorry, I think I have one more question (I already feel myself too annoying ). As far as I can tell, Mission Architect works great with RSS, but I have some doubts concerning other functions of TOT. Specifically, I have difficulty with implementing multi-flyby path into Mission Architect. Here is the image: I've input departure orbit, suggested by multi-flyby maneuver sequencer, into mission architect, but the orbit around Sun after transition is quite different in MA and in sequencer. I'm not sure it is a bug since the results of multi-flyby maneuver sequencer were always a bit different from MA but this difference is significant. Could you please check that all corrections you did in MA for RSS are implemented in multi-flyby maneuver sequencer too?
  4. Stract
    Hi Arrowstar! I have one thing: for some reason two last pre-releases (with RSS gravitational parameter) has some problem with departure-arrival porkchop plot (that one on the very first page of TOT). TOT creates the diagram but then stuck on the window "Searching for optimal departure/arrival" with error sound. It happens with both GM and G(M+m) factor and with both stock and RSS bodies.
  5. Stract
    Works for me so far . I'll let you know if I'll find another issues but for now it seems TOT finally learn how to deal with RSS. Thank you so much!
  6. Stract
    Yes, for the upward transition the result is the same. TOT with GM parameter gives much better results than with G(M+m) if I put Charon on the right place in bodies.ini in advance. Well, that is strange. As I understand, I've made basically the same thing by switching to GM in TOT for SOI change calculations and shifting the position of Charon in bodies file to make sure it is in right place at this moment. Did you try to reproduce it? Upd: ok, I have a guess why you didn't succeed. If you just calculate velocity of Charon with GM factor then you'll get a velocity in wrong location, because the true anomaly of Charon with this factor would be wrong. You have to calculate velocity with GM factor BUT for true anomaly corresponding to G(M+m). Here I have an example for upward transition (I've edited convertRVVectOnUpwardsSoITransition.m function). It worked for my Charon-Pluto transition.
  7. Stract
    No, the ephemeris data are correct (well, if I understand the term right ). I'm talking about the following thing: suppose we have vectors v1 for velocity of the spacecraft and v2 for the velocity of the moon both relative to the central body. Then v=v1-v2 is the velocity of the spacecraft relative to the moon. What I've noticed is that at the moment of SOI transition KSP use the value for v2 as it would be in stock game. Maybe KSP calculates it separately from RSS using just orbital parameters from database as it always do. That's only my assumption and I it would be great if someone can confirm it.
  8. Stract
    Well, it is a bug of Kopernicus, not just RSS. As I understand, Kopernicus creates new solar system with this modification of orbital periods, but doesn't change the way spacecrafts are propagating (maybe it is not easy to change, I don't know). And unfortunately the game itself calculates relative speeds during SOI transition using default bodies mean motion. We can try to talk to devs about this inconsistency but I'm not sure they'll consider it as a bug.
  9. Stract
    Ugh. Great, just great... I think I've found the answer after all. I have a crazy idea that RSS calculates orbital periods using G(M+m) BUT use GM for calculation of new spacecraft speed during SOI transition. Look: I've modified bodies.ini by put there Charon position at the moment just before transition (to make sure the Charon mean anomaly at this moment is correct) and run TOT with GM gravitational parameter. Well, look at the screenshot. RSS way of calculations is VERY counter-intuitive... This is my modified bodies file. You can check it with mission file I've uploaded before, just choose old GM settings. If I am right then things become more complicated: TOT has to track SOI transition using G(M+m) to find correct location of the body but re-calculate new rVectBody and vVectBody during transition with just GM.
  10. Stract
    Ok, that's the story. Look at two screenshots: The first was made in Pluto SOI one second before entering Charon sphere. All parameters in game and in TOT matches perfectly. Second one was made two seconds later, already in Charon SOI. The altitude of the probe in TOT is fine (well, more or less), but velocity is wrong. I assumed that since velocity relative to Pluto in TOT is correct but velocity relative to Charon at basically the same moment is wrong then probably TOT used incorrect Charon speed by switching into new reference frame. Well, just my guess Link to the mission file <<click>>
  11. Stract
    Ok, I think I have an update. It seems initial epoch in TOT for RSS is correct after all. Periods of the planets are correct too, I've re-checked it manually more carefully - the true anomalies of the moons in TOT are the same as in the game itself for every given time. But still TOT have small but stable error for transitions at little moons. Maybe it is just a numercal error though. Good thing is that this error is noticable for little moons only and that this error is not grow with in-game time. So here is an example (picture below). The probe is going to enter Charon SOI in hour and a half. Game shows that periapse altitude at Charon is 212 km, while TOT expects -40 km. Other orbital parameters are also not exaclty the same. So if the position of Charon is correct (and it seem to be so), then maybe something is wrong with the SOI radius? On my picture I marked SOI transition in TOT body information and radius of probe just after SOI transition (green boxes). It looks like for some reason TOT made transition into Charon SOI 2 km below it's own database. It matches with altitude of the probe just after transition and predicted altitude in TOT (red boxes). I doubt this 2 km difference could create this error anyway but anyway I've decided to let you know I can upload mission file if you wish but this result is easy to reproduce, I've had similar situation in every try. Update. Just noticed: difference in altitude at the moment of SOI transition is tiny but the difference in vertical velocity is significant, 116.7 m/s in game vs 125.7 m/s in TOT. Just checked - velocity relative to Pluto just before transition in TOT and in game were similar. But if the speeds of spacecraft relative to Pluto are similar then maybe the speed of Charon is wrong here? Maybe TOT still uses old orbital speed while recalculating velocity in new reference frame?
  12. Stract
    Hi Arrowstar, so far most of the things works great! I've noticed only one issue: there are some problems with fast-orbiting moons like Phobos, Deimos or Charon. Predictions for fly-by near them are not as good as for other planets or moons, sometimes TOT didn't see SOI transitions near them at all. Orbital periods for them are fine (or at least good enough), so maybe the problem is with initial mean anomaly or something. At least I've input manually current Charon mean anomaly and epoch into bodies.ini, skip 20 years and put a probe into fly-by trajectory near it. The predictions were fine, while automatically generated bodies.ini didn't give SOI transition at all. I'll look at it more carefully but anyway it is a minor issue. Overall TOT handles RSS really good now. Thank you for this great instrument!
  13. Stract
    Sure, I'll be happy to try.
  14. Stract
    Yes as far as I can tell. Kopernicus Orbit loader contains the following lines: body.orbit.period = 2 * Math.PI * Math.Sqrt(Math.Pow(body.orbit.semiMajorAxis, 2) / 6.67408e-11 * body.orbit.semiMajorAxis / (body.referenceBody.Mass + body.Mass)); body.orbit.meanMotion = 2 * Math.PI / body.orbit.period; So yes, it seems RSS use G(M+m) for all planets and moons motion. Strictly speaking this is also true even for spacecrafts motion since the mass of spacecraft is neglidgeble compared to mass of any RSS body, so for spacecraft G(M+m) and GM are practically the same.
  15. Stract
    Hi Arrowstar! Yup, all I did is add this smaller body GM. As far as I can see, the only problem in TOT with RSS is that TOT calculates the relative position of planets and moons incorrectly, so every SOI transition creates an error. In my example stock TOT determined the wrong location of Earth on Sun orbit (wrong true\mean anomaly to be precise, caused by wrong orbital speed of the Earth) at the moment of SOI transition, which ended up in wrong Sun orbital parameters of a probe. By adding Earth GM into the function I corrected orbital speed of the Earth and hence the true anomaly of the Earth at that moment. So yes, my assumption is that adding GM of smaller body at every time TOT tries to locate the current position of planet or moon (i.e. at every SOI transition, every fly-by trajectory calculation and so...) should do the trick. At least it worked in my example.
  16. Stract
    I don't know how MechJeb deals with RSS, but at least the following seems to be true because it is easy to check: RSS calculates orbital periods using sum of masses unlike TOT. Actually I've played with TOT code a bit. I've changed the way of calculating the SOI upward transition in mission architect by replacing "[rVectBody, vVectBody] = getStateAtTime(bodyInfo, ut, parentBodyInfo.gm);" line with "[rVectBody, vVectBody] = getStateAtTime(bodyInfo, ut, parentBodyInfo.gm+bodyInfo.gm);" in "convertRVVectOnUpwardsSoITransition" function. After this correction mission architect became to predict orbits after upward SOI transition much more accurately. Here are exapmles for stock and modified TOT (TOT predictions for the probe on Earth escape trajectory and actulal orbital parameters after entering Sun SOI:
  17. Stract
    I doubt it. It appears orbital speeds in RSS depend on the mass of the orbiting planets, which can not be easily avoided. Probably the most simple way is to disable this feature in RSS itself, which I suppose should be doable.
  18. Stract
    Hi Arrowstar! About year ago I told you about problems with TOT in RSS (here is the link to that post). I didn't play KSP much since then but recently I've decided to look at this problem more carefully. And I think I've found a possible cause of it. As far as I understand, TOT calculates positions of planets by solving Kepler equation with parameters from bodies.ini. But the thing is planets in RSS (and probably any Kopernicus-created system) are moving not like in stock KSP. Orbital periods for planets in stock KSP are calculated as T=2pi*sqrt(SMA^3/GM) where M is the mass of central body. In RSS T=2pi*sqrt(SMA^3/G(M+m)), m is the mass of orbiting body. This makes orbital periods more realistic, especially for the systems where masses of two bodies are comparable, like Pluto-Charon system. That's why planets in game are moving slightly faster than TOT expect. I've checked it in game by putting a probes into orbits of different planets and confirmed that probes are moving slower than planets with similar orbital parameters. So that's my assumption. If this is the case then TOT requires a slight modification for non-stock Solar systems. It must calculate position of planets in time by using not parent body GM, but sum of Gms of parent and planet itself.
  19. Stract
    Thanks for the answer, Kerbas_ad_astra! Yes, you are right, FinalizeOrbit indeed adds the masses of two bodies to calculate the orbital period. But honestly I don't understand the purpose of this. It makes sense to consider a Mass of the Moon if you want to calculate a gravitational force between two bodies, but force itself does not determine the orbit, the acceleration does, which is the force divided by mass (Moon mass in our case). Orbital period should not depend on the mass of secondary body as far as I know. Addendum: ah, sorry, I understand now. Yes, if we consider a problem of two bodies moving around common center of masses then orbital period is determined by sum of masses. I'm not sure this rectification makes sense since central body in KSP is not moving anyway but at least I see the logic. Thank you.
  20. Stract
    Hi all. I have one probably stupid question about RSS, sorry if this kind of problem was discussed before. I've used RSS for a long time and I really enjoy this great mod. One day I've tried to use KSP Trajectory Optimization Tool to pre-calculate a complex flight plans, but after a while I've noticed that TOT calculations has some error, not large but noticable. I've spend some time trying to find the cause of this discrepancy. While searching, I've faced some strange thing I don't understand. For example, Moon in RSS has a SMA equal to 384308.437770707 km and Earth has a Gm=398600.4418 km^3/s^2, which gives an orbital period equal to 2371000 s. I've checked actual Moon period using KOS and it gave me 2356558 s. The difference is too big to be just numerical error. Then I've put a probe on the Moon orbit by console. As expected, the period of this probe was 2371000 s (approximately). With time acceleration it became visible that this probe indeed has lower speed than the Moon despite the fact their orbital parameters are exacly the same. So this is my question: does orbital speeds of planets in RSS coincides with two-body problem (which means I've made some mistake) or these speeds are a bit different (which could explain the error of TOT calculations)?
  21. Stract
    Hi again Arrowstar! Yes, it seems something is wrong with my bodies.ini file. The physical and orbital parameters seems to match with game data (and wikipedia:)). But when I played a bit with my first example (with the Mars), I've noticed that distance between probe and Mars is different in game and in TOT. One hour before entering Mars SOI this difference was about 1000 km. Also the moment of entering the Mars SOI in game happend 6 minutes earlier than TOT expected. Not much but probably enough to create this error in orbit prediction. So I supposed that position of Mars on its orbit in bodies.ini is slightly shifted from the in-game position. I tweaked the Mars mean anomaly in bodies.ini to fit the Mars fly-by orbit and finally succeded. When I changed the Mars mean anomaly by 0.00029 degrees, all data was matched with a good presision. Confidend that I've found the solution, I decided to do the same for Jupiter fly-by (the second example I've posted earlier). But here this method didn't work for some reason. My ingame Jupiter periapsis is 4.11 Gm, but I wasn't able to get it by tweaking Jupiter mean anomaly in bodies.ini. The tendency was good, the orbit parameters became closer and closer to correct ones while I've increased the mean anomaly step by step. The closest value was 4.05 Gm and about 1 degree difference in inclination, but when I changed the mean anomaly value just a bit more, TOT lose the Jupiter SOI completely. I've tried to play with epoch instead, but the result was the same. I've checked this in fresh game installation with RSS mod only, but the problem remains there. Still maybe it is just my game version (1.1.2), or something else.
  22. Stract
    Thanks for the answer, Arrowstar! Not really, the problem is still there. I've just made the following: I have a probe on Sun orbit which is going to enter Mars SOI. I created a new mission plan in architect, then import the initial state from KSP active vessel and created a coast to Mars Periapsis. Then I copied the final state parameters from TOT, fast forwarded the game until the SOI transition and compared these parameters with MechJeb. The results are shown on screenshots below. Same thing for Jupiter As you can see, the orbital parameters are not exactly the same, which complicated things if I have a mission plan with gravity assists.
  23. Stract
    Hi everyone and many thanks to the author for this incredible tool. It opened a huge terra incognita in KSP for me. Now I'm still trying to learn how to work with it but I hope I've understand at least the very basics of mission architect. I spent the whole day just playing TOT without even running the game itself, just trying to build the flight plan of my dream but I faced a small problem when I tried to perform it in actual game. Excuse me if the answer is already in this topic. I'll be very grateful if somebody will forward me to this answer then. So the problem is the following. I've created the flight plan in RSS, flight to Saturn with gravity assist near Jupiter. The launch and escape burn were more or less fine and now, after a couple of small trajectory corrections, my space station is on the Sun orbit forward to Jupiter. I decided to check if my actual orbit is good enough, so I imported my current orbit parameters as new initial state into mission architect (not manually, just right-clicking and choosing the option "get orbit from KSP). The thing is mission architect shows everything is perfect. But when I compared the parameters of expected hyperbolic orbit near Jupiter in mission architect and in the game, I've noticed they are not perfectly the same, though they are close. The game shows my periapsis near Jupiter will be about 5600000 km, while TOT says it is near 4000000 km. Of course my planned burn at Jupiter periapsis will not work because of this difference. I tried to upload this maneuver into the game and, as expected, the resulting orbit didn't pass anywhere near Saturn. Maybe it is not really big problem, I can slightly ajust my orbit manually to make it closer to what mission architect wants. But still it is the thing better to avoid. So can TOT calculations diverge from the game (without any delta-v maneuvers planned), especially across the SOI transitions, even if I input the initial state directly from the game? Or it is just I did something wrong? Thanks again for this tool, it brings a new life in game for me
×
×
  • Create New...