-
Posts
333 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by PLAD
-
-
I think herbal space program hits the nail on the head above. If Kerbin had no atmosphere it would take an explosive burst of 3336m/s to get to 11000km altitude, where Mun can grab your ship and throw it to Minmus. This is the absolute minimum for getting to Minmus. You could either go straight up, or blast straight sideways into orbit and then do a second departure burn to Mun, in theory if you do it perfectly the two ways would cost the same. (In practice the orbit method would cost more because you have to go up to clear mountains in your orbit, and the trans-Mun burn would have to be done at higher than 0 meters altitude and would lose Oberth effect). But once you add the atmosphere it gets complicated. The orbit-first method generally reduces gravity losses as your sideways speed drops the effective downward acceleration (thanks to the planet surface 'dropping away'), but raises drag losses as you spend longer in the air. The straight-up method drops drag losses as you spend much less time in the air, but you are fighting full deceleration the whole way so gravity losses can be much worse. Just from empirical experiments I find the straight-up method becomes more efficient at very high TWR values, though the break-even point also depends heavily on the drag of your vessel. At high enough TWR straight-up inevitably wins out though, because sideways spends so much time in the air. Most ships have TWR's far too low to reach the break-even point because of total mass considerations so straight up is rarely the best way to go (not to mention the aiming accuracy problems), but sometimes...
Even for straight up there is a point where raising the TWR no longer helps. In my best launch I got from launch to the 11000km apoapsis for 3736 m/s expended. The fuel used was the equivalent of 3790m/s in a vacuum, so we see I lost 54m/s from burning fuel in the atmosphere with a lower iSP. Mechjeb says I lost 65m/s to drag, leaving 335m/s in gravity losses. Let's imagine the Mammoth had a TWR of a million so the burn would be an explosion on the launch pad. (Ooh, I just had images of many past launches flash before my eyes). Now the gravity losses would be 0, but the dV of the ship would drop from the current 4092 to 3833m/s because all of the fuel would be burned at ground level where the iSP is only 295s instead of 315. I'd have to add about 204 m/s of fuel to the ship to get the 4037m/s expended dV for the whole mission. And the drag loss would be ferocious. My tests explode when I try 3500m/s at ground level, but I bet they'd be more than the gain from no gravity losses.
As an aside, note that if you make a custom motor that is the same as the Mammoth except the air iSP is 315 (same as vacuum) as RIC suggests then you'd cut 54m/s from my score. Or even a bit more as you'd have higher acceleration at launch. So I contend custom motors can thoroughly beat my score. Who will try it first?
I hate to take credit for my ship design as it is so similar to what cubinator used in his example. It's hard to beat a Mammoth on the bottom of a conical shape for high TWR/low drag.
-
Thanks so much for this application it seems like a lot of fun to use!
I am sorry to report I am having difficulty planning a fly by of Venus -> Mars. I managed to plan a route using the application with the following stats
I set up a dummy spacecraft with a prograde and normal as indicated in the calculator, however the alignment with venus seems to be out of phase by about 10-20 degrees. Could this be a false positive or am I just using the application incorrectly?
Thanks in advance as I am keen on getting this working!
OK, I set it up and it worked right- leave Earth on Y3 D78 at Vz 9530m/s, V prograde -1191, 165 days to Venus periapsis, and with a small tweak I got close to the Mars encounter at day 315. (I can't set up the Mars encounter exactly, because from deep in the Earth's gravity well a .01m/s change makes for a million km shift at Mars). However, the path goes through the Moon's SOI. This makes the path vary oddly as you shift time, could that be what's happening? Also, which version of RSS are you using? I haven't installed and tested RSS 10.3.1 yet. I checked the change log and the RSSKopernicus.cfg file and haven't found any changes that would cause such an error, but there's nothing like running it.
As a general aside, when I set the Vz and V prograde and start shifting time I often get more than one 'hit' where the path enters the target SOI, but only one of them will have the right travel time, if a hit doesn't have close to the right travel time keep shifting the departure time until you find one that does.
-PLAD
Javascript is disabled. View full album
-
OK, I could not get that last ship back to Kerbin. So I decided to make another run using what I learned from the first one, and this time landed with exactly zero fuel left (it ran out at 5m altitude and landed at about 4m/s, so survived). Changes were:
-Removed fuel to reduce takeoff vacuum dV to 4092m/s. This cut the total mass by 10% and increased the acceleration, thus dropping the gravity losses by about 50m/s.
-Launched 1 minute later, at 2:31:00, to raise Mun flyby altitude and cut Minmus SOI arrival speed by 18m/s.
-Landed at 3080 meters instead of 2665.
-Running out of fuel just before landing was also handy, slowly lowering the ship the last few meters uses a lot of dV, as long as you kill all but the last 5m/s or so low above Minmus you should be OK. If you have a large SAS! It tilted 18 degrees from vertical before the SAS saved it from falling over. I'm glad I wasn't sitting up in that cockpit.
So this is my final entry, 4092m/s. I am intrigued by how much more could be cut by using a monstrous high-acceleration ship, but balancing the drag losses of sticking more motors on against the reduced gravity losses would be a trick.
I tend to uses dV expended as recorded by Mechjeb as a guide, though it's complicated to confirm the numbers using the rocket formula because the iSP changes as the rocket leaves the atmosphere. But I would say that this mission got from Kerbin to Minmus' surface with an expended dV of 4037m/s. Your way is more useful for planning a mission though, since the number you are given by Mechjeb or KER as you design the ship is the vacuum dV. (Or the 0-altitude atmosphere dV, which is kind of less use for a rocket.)
Javascript is disabled. View full album
-
This is a very interesting challenge. I'm used to trying to do something with minimum mass, it turns out that is not always similar to trying to do it with minimum dV expended. As someone pointed out earlier, the key to this challenge is getting out of Kerbin's atmosphere with as little dV as possible. Using tricks like flying by Mun multiple times to set up the best Hohmann from there to Minmus, making low burns to maximize Oberth, etc. can save maybe 100m/s. But optimizing the ascent can save hundreds. At first I experimented with flat ascent trajectories and high acceleration to reduce gravity losses, but I kept hitting a wall at a bit under 3050m/s to LKO where the decreasing gravity losses where overwhelmed by the increasing drag losses (Mechjeb has a great option for tracking these, see my pictures). Then I discovered that a straight-up ascent solved both problems if your TWR is high enough! Normally straight up is a bad idea for several reasons-under a TWR of about 5 the gravity losses overwhelm any other advantage, and if you are going to land on Mun or intercept anything in orbit your lack of tangential velocity means the encounter will be at very high speed, also eliminating any dV advantage. It is also VERY hard to aim accurately, and especially to cut off the engine at a precise speed. At a TWR of 12 a 1-second delay in cutoff makes for a 120m/s error! But because I was aiming for a Mun flyby the lack of tangential velocity actually increased its effect, and the aim didn't have to be so precise as long as you do a correction shortly after cutoff. It all worked out. Normally getting to LKO would be at least 3010m/s, and the burn from there to a Mun flyby would have to be at least 845m/s, for a total of 3855m/s. But in this entry I got from LKO to the Mun flyby for only 3780m/s.
Total dV from Kerbin launch to Minmus landing: 4079m/s. And I landed standing up!
Now I'm trying to find a way to get back to Kerbin with the 309m/s left in the tank. I've never done it with less than 390 so I think I'm doomed.
Javascript is disabled. View full album
PS-How's that parachute for optimism? We had to put it there to convince Jeb to fly the thing.
-
I found the spindle and rotating hub from the DSEV mod to work quite well in 1.0.4. You can put BZ-52 radial attachment points on the hub and then attach whatever you want to those. It does need to have Infernal Robotics installed. And if you have a lot of mass spinning when you warp time the hub might rip off of the rest of the ship when you drop back to normal time. I think the persistent rotation mod might fix that. And it looks quite cool if you put the counter-torque ring on the spindle to make there be no net torque on the ship.
-
I just flew the "On_the_way_to_Duna_Flyby!.sfs" save, and here's my result. I came up with a procedure for the surface-to-Hermes flight, though it doesn't match the book exactly. I also finished my D-K-D-K test flight from a few days ago, where I used the same procedure. I contend that even in the book there must have been a coasting phase before the final engine cutoff. Consider- the MAV was doing 12 G's (120m/s^2) at one point, and had a total of about 6000m/s to burn. This would take 50 seconds at 12 G's. Even if the average was a third of this you would still have 9 minutes of coasting in the 12 minutes the book says it takes between launch and final engine shutdown. Anyway, my general procedure is:
1) Determine what the longitude of the MAV will be at launch time relative to the flyby periapsis of the Hermes. In my DKDK mission it was 90 degrees, in the mission below it is about 210 degrees.
2) From that determine the latitude that the MAV will be at when it is at the flyby periapsis longitude. In my DKDK mission, if you launch from 16 degrees North you will just be crossing the equator 90 degrees later. (then you would be at -16 degrees 180 degrees after launch, then back at the equator 270 degrees after launch, then back at +16 degrees after one full orbit.) In the mission below the MAV would be at about -10 degrees latitude at the flyby periapsis longitude, so I shifted the flyby South a bit. (Not enough as it turned out, I was eyeballing everything!)
3) Figure out how long before the flyby periapsis you have to launch by noting the orbit period at the flyby altitude, and how far you have to go from launch to intercept. In my DKDK mission, which had a lower flyby, it was only 21 minutes. In the mission below it was about 70 minutes. Launch due East into a circular orbit at that time.
4) If you did everything right the MAV's circular orbit will intersect the Hermes' flyby periapsis. Put a node at that point to match the Hermes' speed and direction. It will be a very big burn. If you get there a bit before the Hermes, end going a bit slower than the Hermes. If you get to the intersect a bit after Hermes, make the burn end with you going faster than Hermes.
5) After the big burn is done, (or modify it before it finishes if you are a Scott Manley-level pilot) set up and execute a small intercept burn that will leave you coasting to an intercept with the Hermes in, say, 40 minutes. You will have a final velocity-matching burn when you intercept the Hermes.
Javascript is disabled. View full album
This was quite fun. Your Hermes is stable enough to not wobble during most maneuvers. It would be nice to put RCS on it, though that could be deadly with a ship that big.
-
Well, I've finished the book. Hoo boy this gave me a lot to think about... (brow furrows)... hmm... you know, we could do a really marvelous copy of the path in the book if we wanted a nastier challenge. Wait, I just need a couple of hours on the supercomputer...
OK, I've got this really cool presentation! Oh darn, I've got it somewhere.. Oh, here: (Warning, spoilers ahead!)
In the book the Journey of the Hermes is Mars orbit-Earth 236 days, (pick up Taiyang Shen) Earth-Mars 322 days, (pick up MAV) Mars-Earth 211 days. There is also the original Earth-Mars in 124 days trip, but that takes place before the book starts, and for reasons I might remember to mention later it has a big problem to simulate. So let's start with the Hermes in orbit around Duna.
Javascript is disabled. View full album
So far I've only made it to the Kerbin flyby, but it looks like it will all work. You could even adjust the start D-K path so that the periapsis is originally 50 km or so as if you were going to aerobrake, then you would have to make a course adjustment at least a few weeks out from Kerbin to switch to the Duna return/flyby. Presumably without KASA's permission.
I've just downloaded your beta ships and save files, I shall try them out shortly. I just don't make ships that look as good as yours so I shall swipe those for my tests as well. I'll be back with more details in a couple of days. Look for new screenshots in the album above as I continue, too.
Oh yes- in my opinion there is a flaw in the book in that the Hermes somehow gets from an 8km/s (28,800kph) arrival speed at Mars to orbit in less than 6 days, and then somehow gets from a Mars orbit to heading back to Earth in less than 24 hours. since Mars escape speed is around 4950m/s tops that means it killed, then added, at least 3000m/s. At 2mm/s that would take about 17 days. They sort of suggest that it aerobraked into orbit, but at that speed it would take going deep enough into the atmosphere to brake at 6 G's to slow into orbit. I just can't picture the Hermes surviving that sort of force. It also makes it tough to simulate that part of the voyage. I've gotta think about it more.
-
I'm reading the book now. I'd had it on reserve on the library but that wasn't due for 11 days, so I went and bought a copy. Andy Weir should be happy.
I admit I've skipped ahead to the ascent to rendezvous with the Hermes, and it has some puzzles. Nowhere do I see a flyby altitude mentioned, though we can constrain it with what we are given. Here are my first thoughts for now, then back to reading...
-12 G's on ascent?!? That's crazy. Even if he'd cut the mass by more than half this suggests the original flight profile for the MAV was around 6 G's, which is massive overkill and rather dangerous. But it doesn't give us other clues. We know it had to go from 0 to 5.8km/s.
-It seems the nominal plan was about 12 minutes of thrusting followed by about 40 minutes of coasting to intercept. (note average acceleration would be around 6000m/s over 720s = 8.3m/s^2)
-Did the MAV have 2 stages? They talk of removing a first stage motor, which strongly implies a second stage to me.
-You can't coast to a 0-m/s intercept. If you are coasting towards a 0-meter intercept with a separately orbiting vehicle, you are in a different orbit than it is and you must have a relative velocity when you are closest to it. Either they would plan to have the MAV motors burnout right next to Hermes at 0m/s, or they would allow for a rendezvous burn to match velocities at closest approach after a coasting period. Since they planned for a 40-minute coast, they would have to plan for a rendezvous burn. It could be small, if it approached at 10m/s for those 2400 seconds that would mean burnout was around 24 km away from Hermes, but it would have to exist. In the book they seemed to expect no speed-matching burn would be necessary.
-It seems the MAV launched from about 4.3 degrees South of the Martian Equator.
Certainly the flyby was at less than 1000km altitude above Mars, probably much less. This would translate to less than 100km above Duna. In the interest of making the ascent reasonably simple I would push for there being two stages to the MAV, with a coasting period between the two firings. The first gets it up into a fairly circular orbit, and the 2nd, after a few minutes of coasting, pushes it to Hermes' velocity and within 100km or so of Hermes. Then we coast to a low-speed intercept where Hermes can use manuevering motors for velocity matching. A spacewalk then gets Watley from the DAV to Hermes. I think this can be justified within the book, they say "He'll get to orbit... but the intercept course may be compromised". I may be stretching it a bit.
Gotta go read...
-
Correct. In the beginning, my Hermes free-return trajectory was offset by 0.04063° from Duna's orbital plane, putting Hermes roughly 1,800km below and to the side of Duna at flyby periapse. When you factor in the flyby crossing over Duna's orbital vector and the DAV launch site location in the northern hemisphere as well, working out an intercept became a complete nightmare.
So now, Hermes is in Duna's equatorial plane.
The DAV site is presently situated 17° North of the equator. At this point, I'm not sure just how much of a problem that will be.. but at least it's a smaller problem than it was before I corrected the Hermes' orbital plane.
I've looked over your links and descriptions, and I'm impressed.. so now I have a question for you..
In the book, the MAV is flown directly to an intercept with Hermes, without establishing an orbit first, as you suggest to do. Certainly, this would have been made easier by the MAV launch site being on the Martian equator, as presumably was the Hermes' orbit. How feasible do you think it would be to recreate such a manoeuvre?
If you launch from the equator and the flyby plane is equatorial then it is just a matter of timing, but that doesn't mean it will be easy. You want to arrive at the periapsis point of the Hermes at the same time as the Hermes does. If you are not at exactly the right place on Duna's surface though, you will still have to coast for part of a circular orbit to the intercept time/place. From the sound of things you've probably figured this out already, but here's what I'd determine:
1) How long it takes you to get from launch into a circular orbit at the altitude of the flyby periapsis, both in time and angular distance around Duna. (For instance my last launcher took about 4 minutes and traveled about 12 degrees from the launch site to orbit circularization.)
2) How far around the planet you have to coast from circulization to intercept. This will depend on where you are at launch, for instance if you have to launch from the other side of the planet you will then have to coast almost 180 degrees before intercept. From the coasting orbit's period you can then determine how long the coast will take.
3) Now you have to iterate to find the proper launch time, since the earlier you launch the longer you have to coast, which means you have to launch earlier... since the coasting orbit altitude is set by the flyby periapsis a simple spreadsheet should be sufficient.
I want to stress that it would only be possible to go directly from launch to rendezvous in one burn if the Hermes flyby is timed such that you are sitting on Duna's surface just 12 degrees before the periapsis point exactly 4 minutes before the Hermes gets there (to use the numbers I mention above). Then instead of doing a circularizing burn you just keep burning to catch up with Hermes as it flies past you. If there is some really good reason why this is the only allowed launch profile (for instance does the launcher only get one engine ignition?) then the flyby of the Hermes will have to be adjusted to time it right. Let's see, Duna rotates once every 18 hours or so so you will have to be able to adjust your flyby time by +/-9 hours and be accurate to within a minute or so... oh boy.
Let's hear from the judges...does direct to intercept mean 'less than one orbit from launch to intercept' or does it mean 'one continuous burn from launch to rendezvous'? I will note that NASA called the ascent method the LEM used in Apollo 14-17 "direct ascent rendezvous", and that involved the LEM ascent stage going once around the Moon between launch and rendezvous, coasting most of the way.
-
Thanks for that, PLAD.. I'll check out your links, and work through your description until I'm sure I understand you correctly. But believe me, my original Hermes trajectory was truly weird.. the offset to Duna's orbital plane introduced all kinds of complications. At least now the planes are perfectly matched (to 5 decimal places.. yay!) we will have some kind of predictable foundation to work from.
Oh wow, does this mean that the Hermes will flyby Duna precisely in it's equatorial plane? That would make the return to Kerbin easier, but unless the DAV is right on the equator it won't be able to get into the Hermes' flyby plane without a dogleg, and step 1 of my procedure will be much harder.
-
Rendezvous with a ship flying by the planet you are on is not that hard, as long as you can launch into the plane of the ship flying by. For instance, if the flyby hyperbola is inclined 20 degrees to the planet's equator but the lander is sitting at 45 degrees north then it will be very expensive to get into the flyby plane. But if you don't have that problem, below is my procedure. I used this procedure 5 times in my Jool-5 entry, since I never put the carrier vessel in orbit around any moon, but rather dropped off the lander during a hyperbolic flyby and then picked it up at a later hyperbolic flyby. (it's a lot of pictures, the Tylo album shows the timing trick best, and the Bop album shows the launching into the flyby plane best.)
1) You might have to wait up to one planetary day (in this case 1 Sol) for the ascent vehicle (DAV) to move (on the planet's surface) into the plane of the flyby vessel, so start watching for the right launch time at least that far ahead. Plus you will need to be able to orbit the planet at least twice after you reach orbit before the flyby vessel reaches periapsis. Once you see the DAV in the right spot, launch into the flyby plane. You'll have to figure out the launch azimuth. Put the DAV into a circular-ish orbit that is tangential to the flyby perapsis. (so for instance if the flyby periapsis will be 800 km then put the DAV into an 800x800km orbit.)
2) Observe the first time that the DAV will be at the tangent point to the periapsis of the flyby path. Observe the time that the flyby vehicle will be at that point. If you took off early enough, the flyby vehicle will not arrive there until more than one DAV orbit period later.
3) Now place a maneuver node in the DAV's flight path that is right at the tangent point to the flyby vessel's path. Make that maneuver adjust the period of the DAV so that it will do one orbit of the planet and be back at the tangent point at the moment the flyby vessel will be there. It's nice if this 'timing' orbit requires roughly half the prograde thrust that catching up to the flyby vessel will take, so you can split one big maneuver into two half-sized ones.
4) I find a couple of small (~1m/s) tweaks are often needed about a half-orbit and quarter orbit before the rendezvous. Now just accelerate up to the speed of the flyby vessel as it comes screaming at you.
The key is that the timing orbit only has to be entirely within the SOI of the planet, and as long as the rendezvous point is not too high there will be a very large range of possible periods for the timing orbit, so you can compensate for any timing errors that the launch time forced upon you. Note that the lower the flyby will be, the better for the launch vehicle since it will get more benefit from the Oberth effect.
-
Any chance of a Linux port?
Sorry, no, at least not by me. I've never worked with Linux and don't know how to write for it. I can see the advantage of it though, the much higher RAM limit in 64-bit Linux must be great when you're running lots of mods. FF uses the MIT license, anybody can use what I've got to take a shot at it.
-
Awesome work with the OPM support. For future expansion have you thought about a way to support arbitrary systems? I believe KSPTOT used a plugin that could output a file describing all the bodies and orbits, there may be other ways.
Yup, I've thought about it. I admire TriggerAU's in-game adaption of AlexMun's pork-chop plotter, it just grabs the orbital elements straight from the game as it's running, so it can handle any system. So can TOT, I believe. Not FF, to add a mod system to FF I open up the mod config files and find the orbital elements and convert them to what I need for FF using Lambert.xls, then write them into FF, rather than somehow generating config files that FF would read at runtime.
But I have some reasons for wanting control of what systems FF is used for- the algorithm uses linked conics rather than patched conics, which means it assumes the planets change the direction of the ship all at one point, rather than noting where the planet enters the SOI and where it leaves it. For the stock planets this is plenty good enough because the SOI's are puny compared to the distances between the planets. But for something like flying between Jool's moons this would be too crude and there would be major errors. I also used a 5th-order approximation to determine the planet positions at a given time, rather than iterating some sort of Newtonian until it converges, and this would become inaccurate if the eccentricity of an orbit exceeds about .25. I do both these things to speed the program up, but it means I have to check every system to make sure my approximations aren't leading to bad outputs. There are also some tricky systems, like that one where Kerbin is orbiting a gas giant, that FF would be unable to deal with, since you have to leave Kerbin's SOI and the gas giant's SOI before you are in Kerbol's SOI.
I could write an app that read and checked a mod system's parameters and aborted before generating a config file if the system wasn't safe, but that would be a major project that would push everything else aside, so it's not in my plan for now.
-
Hello, this is a beautiful and superbly executed and documented mod you have here. I wrote a Flyby Finder for stock KSP, and I've recently upgraded it to work with your OPM planets too. Somebody just had a question about flying by Jool on the way to Sarnus, which I shall use to show what FF can help with in OPM:
Javascript is disabled. View full album
Note that it is still a bit tricky to set up the flight (especially where to fly by the middle planet, above or below? in front or behind?), but at least FF shows when the windows are. Detailed instructions are in the post.
Now I'm off to build a massive expedition to Sarnus.
-
I've been studying Kerbin-Jool-Sarnus paths as part of testing my Flyby Finder program, which I just recently upgraded to include the OPM planets. I've made a little summary below.
Javascript is disabled. View full album
I found that you can go K-J-S during every single K-J window (these repeat on average every 467 Kdays, the Kerbin-Jool synodic period) but that the KJS windows are only fast for a few times every 8132 Kdays (the Jool-Sarnus synodic period). I throw a K-J-S-U chart in there, it gets much more complicated with three planets but fast windows are there. I Haven't found a good K-J-S-U-N window yet, either Neidon or Urlum is in a bad spot when the other planets are good, at least during the first 30 Kyears or so that I've looked in. As someone noted, in our Solar System the outer 4 gas giants repeat positions roughly every 179 years (very roughly, after a couple of repeats Uranus gets too far out of place) so you might have to search a similar period in KSP.
-
An update note, I've just released version 0.82, which is strictly a bug fix. It gets rid of all false positives that would appear in high-energy sections of a plot, and restores some true positives that were getting filtered out before. In case you're wondering, version 0.81 was not released because it filtered too much stuff out. No changes to the operation or instructions. Now I'm on to another shot at double flybys, though this will take awhile because I haven't been playing the game enough lately, just testing algorithms!
-PLAD
-
Just a note I've posted an update to FFRSS, now it's version 0.82. This version is strictly a bug fix, I eliminated those pesky false positives that would appear in extremely high-energy regions (usually hyperbolic) of the charts. It also allows some true positives through that were blocked before in paths that go from one gas giant to another. In case you're wondering, version 0.81 filtered out all false positives with a vengeance, in fact it also filtered out too many true positives to be acceptable, once I had the revelation for 0.82. I'm now satisified with the Lambert algorithm, and it's on to another shot at double flybys.
I also updated the Lambert spreadsheet a bit.
-
Just a note, I've put the latest version of Lambert in the OP right under the links for FF. This version handles up to 6 bodies, does double flybys, and includes the OPM planets. It's still not exactly user friendly and I don't recommend it for the casual user, but if you want to see how FF works the math is all in there. It doesn't allow Kerbal time inputs but does translate the output dates.
-
Dunno why I didn't think to do this before, but I added a link to this in the RSS OP.
Oh wow, right near the top, too. I am glad you like it, RSS is a superb mod and I am in a bit of awe over the amount of work that must have gone into it.
-
I'm not ready to make a substantial addition to the output yet. I'm planning to fix the false positives problem first, then update the Lambert spreadsheet, and then take another shot at double flybys before I will take a hard look at improving the output. In my mind neither using an equatorial or ecliptic orbit is optimal, but as yet I haven't thought of a best way. (Especially for high-latitude sites like Baikonur.) Sorry for now.
-
This is really awesome. Thank you.
I have one question/request: I assume that in most cases a launch from an orbit that is coplanar to the ecliptic is usually better than starting from an equatorial orbit. Therefore I launch my interplanetary probes into such an orbit before going leaving Earth.
Would it be possible to calculate vz and v_prograde relative to that? Or is my whole approach flawed?
ta,
Gustav
That is an interesting question. It is true that the planets all orbit in planes within about 7 degrees of the ecliptic, but transfer orbits to the planets are usually more inclined than that. So having your parking orbit around Earth be precisely in the plane of the ecliptic might not be a particular advantage. What makes it so bad is adding the Earth's velocity to your Earth departure velocity. Imagine that you need an interplanetary transfer orbit inclined 7 degrees to the ecliptic. So you leave in an orbit inclined 7 degrees to the ecliptic relative to Earth. Your v leaving Earth's SOI is, let's say 4000m/s. Once you leave Earth's SOI and your reference is now the Sun, the 4km/s is now added to Earth's orbital 29km/s, and your 7 degrees relative to Earth becomes 0.85 degrees relative to the Sun. So in this example, with a Vsoi of 4km/s, leaving more or less prograde from Earth, your Earth start orbit inclination has to be about 8 times more inclined to the ecliptic (relative to Earth) than the interplanetary transfer orbit's required inclination (relative to the Sun). In summary, I think you can often save a lot by launching into an orbit that is not necessarily in the plane of the ecliptic.
Your other question is an intriguing. If I use the ecliptic plane as the plane to put the test probe in then it is trickier to put it there, since you will have to specify the inclination and the longitude of the ascending node precisely. When I use an equatorial test orbit no LAN is necessary. If you're hyperediting it up there I suppose it's no big difference. Then I would give Vprograde and vZ relative to that orbit and you could see what plane to launch into, same either way. But I wouldn't know what the inclination of the departure orbit is relative to Earth's equator, since vZ and Vprograde would be relative to a specific point in an already-inclined orbit and wouldn't add together simply. I'd have to figure out the ejection time exactly, beforehand, to give the inclination of the orbit to launch into. (Right now I just set vZ and vprograde into a maneuver editor and adjust the ejection time back and forth until I see the orbit prediction hit the target planet.) There would be one big advantage to using the ecliptic plane though- it's a lot closer to Canaveral's latitude than the equator, and it would be much less common for the test orbit to be less inclined than Canaveral. (When that happens my current way breaks down since you can't launch from Canaveral into a, say, 10-degree orbit.)
I have to think about it for a while. My way of defining the departure orbit is not nearly as good in RSS as it is in stock KSP (unless you launch from Kourou:)), and it's not perfect anyway. I don't want to promise anything.
-
What does it mean if I am getting a negative Equat. Prograde velocity?
It means the departure orbit is highly inclined. Remember that the Start Equat. Prograde velocity and Start equat Z velocity are to be applied to a test ship that is already in a zero-degree inclination circular orbit around the start planet. If you are in such an orbit around Earth at, say, 200km altitude then the ship is already going 7787m/s in a prograde direction (and 0 m/s in the Z direction). If the departure orbit was inclined 90 degrees then you would have to kill all of that 7787m/s and add vZ for the departure. So the program would say you have to add -7787m/s in the equatorial prograde direction (and something over 11200m/s in Z.) Of course in practice you would see the departure path for the test ship and use it to launch your real ship from the ground into a polar orbit at the right time.
And I must note that the program still doesn't handle the numbers right when the indicated start orbit inclination is exactly +90 or -90 degrees. It gives correct departure and flyby dates and so on but the prograde and vZ numbers are not right.
-
OK I'm releasing version 0.80 today. Probably the most important change is that it can now use Kerbal time (6-hour days and 426-day years) as well as Earth time. I also added several graphing options and the ability to use the Outer Planets Mod (by CaptRobau) planets.
I've put the new Dropbox links up in the OP and am adding the new instruction pages into the primer. Here is a primer for just the new features:
Javascript is disabled. View full album
The key points:
-To change the time mode (Kerbal or Earth) or the planetary system (Stock or OPM) you must clear the current search, or do it before you start the first search.
-Beware of making the 'search steps per period' too high. You can get more hits but it the search takes much longer. Remember the 4500 'flybys found' limit, there's no point in increasing search steps past the point where there are more than 4500 hits.
A vmax at SOI of about 4500m/s should get you from Kerbin to any planet in the OPM at least once per synodic period, try flight times of 600 to 8000 Kerbal-days.
-PLAD
-
I used the atmosphere in a flyby of Jool to set up an encounter with Eeloo in my Lowest Delta-V to Eeloo challenge a while ago, but that was before the current atmosphere models. The problem was that the energy the ship had when arriving from Kerbin was higher than what was needed to get to Eeloo, so to reduce the Eeloo arrival speed I had to bleed off energy at Jool. Because the ship was going slower after the aerobrake it also ended up in a more favorable departure direction. Jool's atmosphere had to kill only 142m/s so I think that high pass could be repeated in version 1.04 but I'm not sure.
This does not seem to be strictly what you are describing. If you look earlier in the mission I linked to you will see I fly by Kerbin twice because it cannot turn my ship enough with just one flyby. In theory one could use the atmosphere to turn the ship into the proper departure direction in just one pass, but you are going to lose a lot of energy to drag. In this example the ship needed to turn an extra 20 degrees or so while traveling at 4350m/s, let's see, that's about 200km (20 degrees of arc along the atmosphere) of traveling low enough in the atmosphere for it to turn your ship while it's going that fast, I picture astronomical drag losses even if the ship doesn't explode. I just don't see it as possible, the drag losses should exceed the benefit of the direction change by a huge amount.
It's not theoretically impossible though...
[WIN] Flyby Finder for Real Solar System Mod V0.85 [RSS12.0 for KSP1.2.2]
in KSP1 Tools and Applications
Posted
OK, the picture of the planet positions on what your system says is Y3 D78 solves everything. It was totally different from what my system shows on that day. (And I used a fresh-everything install of RSS 10.3.1, I had to update anyway!) I took a new save starting at Y1 D1 and ran it until the planets were in the same position as what you show in your picture. I put a third picture in the album above to show when it was- Y1 D237. Then it hit me.
If you go to the main settings in your install I think you will find this: "Displaying Kerbin Time-(6 h days, 426 d years)". You want to change that to "Displaying Earth time...". Y1 D237 in Earth time is the same as Y3 D78 Kerbin time.
I have mixed those two time systems up several times. I wish there was a different name for the Kerbin "day". We call it a "Sol" on Mars, for instance. In any case, happy trails!