ajburges

The question of which approach to follow depends on which losses bother you more. Radial components are components not increasing your orbital energy. Thankfully trig is non-linear so a 10° angle only saps 0.5% of your prograde component when integrated. Note: 30° robs 4.5% of your prograde component when integrated! Also note: these losses will worsen as eccentricity increases. A pure prograde burn will maximise the work of your dV, but it's harder to balance the burn correctly and control AoPe. Fixed heading burns tend to be slightly easier to execute while maintaining AoPe so can be more useful for precision maneuvers.

Does anyone know how distance is measured for waypoint activation for survey contracts? Config files suggest 15000 (m) but it lacks context. Is it a any point above any point within a 15000 m radius on the surface (a cone)? Or is it any point 15000 m from a line above the coordinates (a cylinder)? I ask because I am trying to calculate polar orbits that would perform ideal visitations without re-tasking.

OHara, thanks for that simple mechanism I got lost in the weeds and overlooked that simple division would give me the orbits then it was simply a matter of choosing a coprime number of revolutions to pair with it. I still have some questions about waypoint activation, but I'll ask that in seperate thread.

Didn't mention it in post but the title did specify stock. The useful instruments are the Kerb Net/Anomaly detector (FoV limited), experiments for survey contracts (are they lat/long limited or horizontal distance limited), and the resource scanner (practically not limited). Rubber ducking it out, I suppose the best sock polar orbit is the one (per scientific region) with the lowest time to come within survey distance of all equatorial points. Unfortunately, this varies greatly depending on the frequency of your orbital harmonics.

To clarify on finding an approximate resonance: I would like a better way to find orbital periods that follow a ground track that advances by x degrees every planetary revolution and/or by y degrees when a*x (mod 360) < x. I already have Kepler's law incorporated into my solver, but I can come up with a good way to solve given x and/or y.

Just wait till you have a lander with TWR low enough the gravity losses demand more dV than the map suggests! Edit: Why are you doing a Hohmann Transfer to synchronous orbit? Just launch to there and you use even less dV!

Everyone has sound advice, but I want to draw your attention to the root of you problem: The maneuver node system assumes instantaneous velocity changes. When burns are short (a fraction of an orbital period) the difference between your node and your burn is negligible, but longer burns will compound error. Long burn craft need integration of velocity over the course of the burn. That's a much more complicated problem to solve and KSP does not have tools to help solve it.

Discovered that the old thread of ideal scansat orbits got consumed by a forum change at some point so I'm working on a Google Sheet to help derive polar orbits with useful resonances with revolution period. I have calculators that can solve for altitude and resonance while calculating surveyed arc for given FoV, but the utility is limited beyond checking solutions. A few questions come up: What is the proximity toggle for orbital survey waypoints? In stock I think the most useful resonance orbit would minimize the time to visit all possible waypoints for contracts. Is there a better way to find an orbit of particular approximate resonance than brute force? The presence of non-discrete modulo arithmetic is a barrier I don't know a way to reverse.

Just making sure to voice support for doing it right over doing it fast. Be careful to manage communication to avoid building a hype train that needs too many boosters/struts to get off the pad! A lot of people would be thrilled with a refresh. Don't prime us for disappointment and I'm sure your work will be grand and well received. Avoid the trap of more time = more features, just say when you got delayed working out bugs or other back end issues. There's enough people on these forums familiar with code projects to defend you if the more naive make a fuss.

Are you looking for an easy or efficient transfer? Burning to get deeper into Duna's gravity well is probably not efficient. The Oberth gains would need to outweigh the losses from going the wrong way. Given that Kebin transfer from Duna elliptical is ~380 dV there isn't much room there for Oberth savings. Easy has already been covered: Leave Ike orbit for greater Duna orbit Transfer to Kerbin Enter Minmus orbit Efficient relies on not spending dV without getting useful potential/kinetic energy Calculate the necessary dV to transfer to Kerbin from Ike orbit (dV_duna_escape) Calculate the dV burn necessary to have approximately dV_duna_escape on Ike -> Duna SoI change Time Ike exit burn such that Ike is approximately in the correct position for transfer burn (a few hours early so SoI change occurs at correct phase) and you burn on the correct trajectory for ejection. If you track at least 3 SoI changes with trajectory planning, you should get transitions that lead to a Hohmann like transfer from Duna to Kerbin and be near rendezvous. You can skip to here with node planning, but mentioning the previous steps should help you visualize what you are doing. Halfway through the transfer, use fine trajectory adjustments to get a Munar intercept for an assist to capture into an elliptical kerbin orbit. Remember prograde, reduces energy, retrograde adds energy (or vice versa check against trajectory). You can also aerocapture, but a Munar assist capture will result in a higher Pe. Higher Pe is more energy in our orbit, The more energy in you orbit, the less dV you need for Minmus capture! normal for plane adjustment prograde + radial for pe height and time (Mun location) adjustments Munnar assist should help with Kerbin capture, adjust orbit for Minmus intercept.

Disclaimer: I was comparing values between 1.7.1 and 1.11.0. It is possible there was a change pre 1.11.0 that I missed. Ran both versions and compared parts in SPH with vessel mass readout.

Looks like they did change cabin masses while adding occupant mass. The one arm became 1 ton lighter fully loaded while the lab arm actually got a few dozen kg more massive fully loaded. Removing kerbals would increase the difference further. Looks like the root cause was the part rebalancing completely broke the station, but it did expose that ballast (or careful berthing management) would be needed for future artificial gravity projects.

Good thought on camera focus. I forgot about it because I use camera aiming to access the rotors easier on the prototypes. Did the crew cabin mass get rebalanced as well? The asymmetric arms were carefully balanced in 1.7.1, but one holds over 3x as many kerbals. if empty mass was adjusted, that would explain how they got so out of whack. Regardless, the variable mass of cabin parts seems to necessitate a ballast system these days.

Prepped an album with the latest contra rotating mechanism concept. Frustratingly, this is the the tamest one so far so it's less illustrative. I was able to eventually trim the oscillations out by redistributing ore mass as ballast (as intended for this design). With 1.11 adding Kerbal Mass, I think redistributable ballast is now the way to go. I also have a single ring countered by a rotating ore tank in-line, but the significant difference in moments of inertia further complicate things as spin-up is unbalanced. Also have no idea how to approximate the balancing of the opposite forces of the ring mass vs the counterweight.

Having issues were my rotor pieces on stations. The counter-rotating arms are producing torque on the rest of the station that is misaligned with the center of rotation. Is there any way to eliminate this? Could this be caused by slight mass variations between arms? Note this isn't from uncanceled torque. I have visually verified the arms are rotating WRT the station in opposite directions. Concepts that worked in 1.7.1 without this issue get rotation around 1 RPM. Net torque is not consistent and varies. I would say Kraken like, but the forces are tame and disappear when rotors are stopped. This uncontrolled attitude change makes it impractical for a station. Furthermore SAS refuses to correct for it (I have a control point orthogonal to the spin axis I intended to point in the normal heading). Took a break around 1.7.1 when I got sidetracked and stagnated designing BG craft. Came back recently. I've been toying with designs waiting for mods to update and one of the items in design is concept artificial gravity habs for stations.

Thanks Hans. Looks like .3 is the ratio then (or close enough). I would look at Jr Drills, but they are too short to interact well with a Klaw. I was planning a modular asteroid tug that would have a seperate mine/refinery as a detachable head. Wanted to saturate a single ISRU in a mass efficient manner. Given I would want any orbital refinery to be solar powered for yield purposes, I don't think I'll worry too much about multiple ISRU miners. Each needs over 3 Gigantors in ec/s at 2x conversion! More still to charge battery reserve for passage through the umbra.

What is the most efficient extraction ratio of 'Drill-O-Matic' Mining Excavator to Convert-O-Tron 250 for asteroid mining? What I mean is how many drills are needed to saturate an ISRU with 2 converters active. I spent 1/2 an hour trying to look this up for a design, but decided to give up and ask. IIRC correctly the engineer level can be reduced out of the equation. Alternatively is it more effective to fill an ore tank quickly (with more drills) so you can avoid running drills on rails and avoid wasting asteroid ore?

Make note that the best time for a correction burn is not necessarily "halfway there". There is a trade-off between the velocity ratio of the maneuver and the time the changed course can propagate. Use a normal burn component and vary the time of the maneuver node to visually see what maneuver time maximizes you normal component efficiency.

That's possible (2700 m/s from LKO and only need to land with 900 m/s), but it seems like an odd mission profile. The only advantage of bringing your lander back to Kerbin's surface is the science for a vessel that has been to the Mun. It's essentially just a direct ascent lander without staging. Terriers or Sparks are the best for this as I mentioned due to mass considerations. What I find more interesting is a lander that makes multiple Mun landings. It can dock with a mother-ship in LMO for refueling or return to a station in LKO after an Aerobrake. The Aerobrake dV requirements are similar, but you don't need parachutes!

Wait, do you want a reusable lander or a SSTO capable of a Mun landing?

Moon and back to where? Assuming 1-3 seats and a science suite Mid/Low Munar orbit: Ant array or Spark. Ants are more efficient on dV, but 1 Spark gives plenty of thrust and spamming 6-8 Ants just looks silly if you know anything about rocket thrust physics. Kerbin orbit: Spark(s) or Terrier. You need much more dV to go from LKO to Mun and back. More care in design if you wish to aerobrake. This might push you out of the "weight class" where sparks dominate. Mun is about the biggest body you can consider Nerv engines. Even then you need a massive vessel for them to make sense.

Depends on role. Terrier and Spark engines are my goto. Sometimes I use Aerospikes. Considerations: ISP: more ISP means less fuel used per landing while there are corner cases where engine mass itself would eat into ISP savings, craft with more efficient engines almost always get more dV per unit fuel. (see Nerv, Poodle, Terrier) Length: shorter engines allow for shorter stacks which are easier to make stable on the ground. (see Terrier, Aerospike, Spark, Ant) Alternatively, surface mounts trade efficiency to remove engines from the stack length (see Twitch, Thud) TWR: more TWR means you need less engine mass to achieve the TWR you desire for landing. Not commonly considered, but this consideration is why you don't see many landers with Nerv or Ion engines.

You will get improved structural integrity if you attach things via nodes instead of surface attachment. Still bendy, but a marginal improvement.

Another thing to consider is polar relays are great for many things: > Resource scanner > Anomaly detection over several days (at sufficiently high altitude you can see the entire planet face in Kerb net). > With proper resonance, you are in a mapping orbit and can complete grab/temp scans above x contacts without fuel burn. Not to mention transmitting grav scans for every biome! > I like to use my polar relay as a synchronization timer in case my Draim constellation desynchronizatizes.

Hah! No it's still a problem. My Munar lander springs up near the equator and falls 20 m at the poles when loaded. If your craft are springing up on load, I find increasing spring strength can help. My hypothesis is resting position is saved but not spring compression, loading violently compresses the springs. Increasing spring strength raises the resting state recurring the impulse on load. If your craft drops on load, reducing spring strength can help the landing. Regardless, be extremely weary of overdamping. Setting it over 1 can introduce new problems.