• Content count

  • Joined

  • Last visited

Community Reputation

336 Excellent

About FancyMouse

  1. Yeah but then the incorrect part is, the original velocity is really -v, so if you change to 2u+v, your speed change is 2u+v-(-v)=2u+2v, not 2u+v-v=2u. Considering that u and v are in opposite directions (which is still my assumption - I haven't read your source yet), 2u+2v is actually much, much smaller than each of u and v themselves. Eh... still not right if I'm reading correctly - there should be only the first part, no second part of orbital speed. i.e. if Jool's orbiting at 4km/s, you enter Jool at 3.5km/s (relative to Sun), then your upper bound of gravity assist velocity change is 1km/s, not 7 or 8 or 9 km/s. And of course, all of these are ignoring bending - bending will introduce the extra sqrt(2-2*cos(theta)) factor, which we intentionally ignore for calculating upper bound.
  2. Actually, you know what - I don't know where your quoted reference come from, but if it starts from u and v in different directions (meaning my v is really its -v), then what we said both agree, meaning that after bouncing, the velocity of the object is indeed 2u+v. However, the v here has an opposite direction from the object's initial v, so the velocity change is really 2u+2v. This now agrees with my result with v sign-flipped.
  3. Read my EDIT section above. You could still argue it's correct in common cases, but it is a not-quite-useful bound since it's too large. And in extreme cases it will still be incorrect (e.g. a hypothetical Jool at 1m/s orbital velocity and you enter from a Sun flyby or retrograde orbit and Jool completely turns you around). Bouncing argument in general is valid, but you need to use the correct velocity/frame of reference, which you didn't. (I'm just rephrasing my same argument again, in your bouncing setup) If you have object A travelling at v, hitting another object B travelling at u (both in inertia frame), and assume B is huge such that its own velocity change can be neglected. Then object A in B's frame has velocity v-u. A totally elastic bouncing changes the sign, so after bouncing, A has velocity u-v in B's frame. Transform back to inertia frame, it is 2u-v. In particular this is not 2u+v. Total velocity change is thus (2u-v)-v=2(u-v). So it's 2(u-v), i.e. twice the velocity of A relative to B is the change, not 2u. In general, when there's an angle, it's really (u-v)sqrt(2-2cos(theta)). It's easiest to do all the calculation in B's frame.
  4. I have to disagree. I've never mentioned how trajectory looks like, all I've been saying is velocity change. Suppose planet's orbital velocity is v0, and your velocity is v (relative to planet P, upon entry of SoI of P). Assuming you enter retrograde and exit prograde. You're changing your Sun velocity from v0-v to v0+v, which is 2*v difference. This has nothing to do what v0 is. Absolute amount of change (we talk about change because it's the amount we get from a slingshot) is 2*v, not 2*v0. Another way of proving this is, suppose I use Jool for gravity assist. Let's look at the trajectory from entering Jool's SoI until leaving. This particular slingshot should give a fixed velocity change on your Sun velocity. Now, assume we move the whole Jool system (including your slingshot trajectory) way out so that Jool's orbital velocity becomes 1m/s. Now do I get a different velocity change because of this "upper bound" of 2m/s? ---- EDIT: okay you could still say it's an upper bound because planet's orbital velocity is usually much higher than your relative velocity from the planet (it would mean you either enter from a Sun fly-by trajectory or Sun retrograde orbit). But that would mean the upper bound is dumb - Jool's orbital velocity is still around 4km/s and it doesn't help much saying slingshot gives at most 8km/s, does it?
  5. You don't compare to something else. The inclination shown on AN/DN is itself a comparison between your orbit and the desired contract orbit. So you just need to make sure the inclination shows a value 0 degree. If it shows something like 1 or 2 degrees, it means you still need to adjust your inclination (start from putting a maneuver at AN/DN). If it shows 180 degrees, then you're totally going in wrong direction.
  6. You do have AN/DN, and they are shown in all your pictures. There are 4 markers on the contract (green) orbit, two of them are Ap/Pe, the other two are AN/DN. AN/DN are Ascending/Descending Nodes, btw. These are standard orbital mechanics terms and you can wiki them for definition and explanation.
  7. I think some terms need to be clarified here. Suppose we have a central star S, planet P where you want to do gravity assist, and a ship X, the thing that get doubled and applied to X's velocity in frame S is the velocity of X relative to P, not P's orbital velocity around S, nor X's around S. Because in a slingshot situation, X is usually on an escape trajectory relative to P, that's probably why people call it "escape velocity". It's not the periapsis escape velocity, though - it's the velocity upon entry of SoI. Your term "planet's orbital velocity", my understanding is it means P's orbital velocity around S. This has nothing to do with slingshot - if you have a huge planet far far away from the Sun, its orbital velocity is tiny, but it can still give a tremendous gravity assist. (And just in case people are picky, which does happen in this community - I do understand 2x is a theoretical unachievable upper bound)
  8. Another way to look for it is, if you have Commnet on and ground station on, you could turn on Commnet:Network in map view, find the first ground station to the west of KSC, that's KSC2.
  9. RC-001S is just 60kg heavier than OKTO2 that I would argue the extra mass is negligible comparing to the fuel saved, but this is not my point. I was merely saying burning maneuver hold has its advantages. I don't deny in some cases the extra mass will make a difference, but making the decision whether to use a probe core capable of doing maneuver hold (balancing mass etc.) comes after you know the pros and cons, not before. As a matter of fact, if you want a burn to change 45 degree inclination without other orbital parameter change, burning all the way normal/anti-normal is wasting about v*2% fuel (in terms of delta V, v is your current orbital velocity), comparing to plotting a maneuver node that points straight to the target velocity (which is not a pure normal/antinormal burn, btw). Let alone some other cases that could save even more.
  10. You'll be wasting fuel - intuitively, it's because you're changing your velocity vector along an arc instead of straight line. I do maneuver not aligning to axes all the time. One example is rendezvous - my inclination burn is usually combined with other components so that my orbit is tangent to the target's, so the final burn is easy enough. Second example is mid-course correction burn - Not only I adjust inclination, but also prograde/retrograde to adjust entry time, and radial/antiradial for correct argument of periapsis (if I'm not targeting equatorial orbit). It's much better to plan ahead and burn exactly what's planned, than burn in 3 directions trying to figure out along the way. It's all about efficiency - you could of course do them with 3 components decomposed and it is "sufficient" in terms of getting to a target velocity, but you could do better in terms of consuming less fuel by not burning in standard axis directions.
  11. 1. Use the rotation tool (shortcut key 3) with angle snap off (short cut key C) to slightly make your wings angle up. This creates a small AoA while your fuselage can still point prograde, creating maximum lift with minimum fuselage drag. 2. The engine above wing is making your life harder - because they create torque to pitch you down. I just ditched the two above-wing engines and rotated all the wing parts a little and it flies perfectly fine to me. At 10 degree climb angle it just constantly builds speed. Very stable. At 20km@1.1km/s I fire the nukes, at 25km I switch rapiers. I'm not in a perfect trajectory, though - since when I switched mode I'm not even at 1.2km/s yet, but it's ok - when oxidizer runs out, I'm at 2.2km/s orbital speed and nukes are sufficient to circularize. After circularize to 90x90 orbit, it's still like 3500 LF left. So your design is generally fine - just fix these small problems and it will fly. but there are some more suggestions 3. Using nuke is a big decision. Depending on the purpose of your spaceplane (low orbit only, or going further, or refuel at space station before going further?), in most cases you don't really need a nuke. Without nuke you can save a lot of mass on your plane - if you just want to reach LKO, you can definitely do it in half the mass you currently have, and ditching nuke is the first step.
  12. Your current setup means you just need to change your direction of your 230m/s velocity to a different direction at a correct point. So you plot a maneuver node at AN/DN. You first drag normal/antinormal of 230*sin(53)~183m/s, then drag retrograde until maneuver shows about 205m/s (this is sqrt(183*183+92*92) where 92=230(1-cos(53))). At this point, two orbits should roughly match, and then you can do fine adjustment from there.
  13. depending on if they're shorter than me or taller than me.
  14. "Forget to extend antenna" is my most frequent one.
  15. Kerbnet is stock. You right click a probe core and it should have a Kerbnet access button.