Jump to content

ajburges

Members
  • Content Count

    538
  • Joined

  • Last visited

Community Reputation

130 Excellent

About ajburges

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 u
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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!
  7. 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.
  8. 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
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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 stopp
×
×
  • Create New...