RemoteTech
RemoteTech copied to clipboard
RemoteTechnologiesGroup
SMA-snapping to counteract satellite drift
Due to flight imprecisions it is practically impossible to properly align a relay network to be consistent across high timewarp. I propose that satellites should snap to any close semimajor axis (SMA) in these 3 events:
- Exit from flight.
- Switching to Vessel beyond the loading radius (2.5km)
- Exiting the loading radius of the active Vessel.
I imagine snapping to be done thusly in pseudo code: foreach (Satellite s in someSatelliteList) { if (thisSatellite != s && thisSatellite.mainBody == s.mainBody && math.abs(s.SMA - thisSatellite.SMA) <= somePresetDifference) { thisSatellite.SMA = s.SMA; break; } }
thisSatellite is the one that's being unloaded, correct?
An interesting idea. There will still be some SMA drift of the entire constellation as random errors get transferred between the satellites, but that shouldn't affect game play.
One potential problem is LKO. Can we make the precision criterion (which IMO should be a ratio, not a difference, to scale better between high and low orbits) small enough that you will never accidentally get two satellites locked to each other?
Indeed thisSatellite is the one being unloaded. Regarding the precision criterion, it should be intuitive to the player. Say the criterion is 0.2km; the player would then just need to know that they need to match both periapsis and apoapsis to within at least 0.1km. If the criterion scales with altitude, it would IMHO be way too complex and unintuitive in-game. Of course the criterion should be as close to the precision it's realistically possible to get to in-game. I shouldn't make it easier to align your network, just give it that last push of precision that's impossible to get but actually necessary if you want to maintain a network without spamming excessive amounts of satellites or realigning once every interplanetary mission necessitating high warp.
An alternative way to implement it would be with a grouping mechanism. We would need to continually do the snapping check and popup an option to either create a group if the check returns true on another ungrouped Vessel, or joining a group if the check returns positive on a common SMA of any existing groups within the SOI. This would get rid of any accidental grouping but would add a bit of extra gameplay complexity, which may be unwanted.
I must say though. Without having tested the mechanic in-game, I do tend to prefer a purely background approach with a simple and intuitive criterion over an overt grouping mechanism and/or scaling criterion.
Agreed. The game's too complex as it is, this is the sort of thing that would be best handled in the background. Re: relative or absolute criteria, I was working on the assumption that this system would be invisible to the player, so they wouldn't have to know exactly what it was.
Since matching both periapsis and apoapsis is harder than matching semimajor axis (I've done the latter plenty of times, but I'm not sure how many orbits it would take me to get the former right), how about making a criterion in terms of orbital period? E.g. one second tolerance?
I'm working on the assumption that the player has the bare minimum of knowledge of orbital mechanics needed to align orbits: I.e. Going for identical orbits in terms of periapsis and apoapsis and not even knowing what a semimajor axis is. Of course more experienced players would be able to use the mechanic to create much more complicated networks and still have them precisely aligned. I'm all for having the criterion be a certain difference in period. This variable would need to be visible in flight though. Hmm... AFAIK it isn't in Stock. Perhaps a toggleable overlay of period for all satellites within the same SOI in map view?
Ahh. Now I'm getting creative. With this feature, the flight computer could do well with a Pe:{time format} burn command. But that would be a whole other feature suggestion.
I don't see the point in this, or more importantly there exists ways to almost already achieve this. Using Kerbal Engineer and looking at orbital periods you can minimize drift to be less than 0.1s per orbit. For a Kerbin synchronous orbit it results in less than 24 minutes of drift per decade from your targeted orbital period. If you keep all satellite orbits within 0.1s of each other the drift would be extremely minor unless you are running the game for decades (in which anyone should expect some drift).
Basically, why is snapping needed when adding orbital period information and a quick explanation like the above is all a player would need to know? In fact, Scott Manley does a really good demonstration of this on his channel in this video from Interstellar Quest (It's for KSPI power transmission but same concept applies to this mod).
Expressing the result as "24 minutes of drift" as you have done is somewhat misleading. What really matters is the angular separation between adjacent satellites, and converted into those numbers things look a bit worse: a 0.1 s error introduces a 20 degree shift in relative satellite positions every 8 years. That's quite noticeable.
More importantly, if you place your satellites in a lower orbit than KEO (and there are plenty of valid reasons to do so), the time for the network to break up rises quite rapidly. For a network at a few hundred km, an 0.1 s error will lead to broken links within a year.
Please, give other players some credit. We've been using mods like KER to build all our networks, and they still drift out of alignment.
Alright, I do see your point now, especially when using lower orbits. I'm just not sure snapping into orbits is really the best solution. However, I can't think of anything better off the top of my head to get nearly drift free orbits without an absurd amount of effort.
I guess from my point of view I rarely ever use high time warp for long because I run many concurrent missions but I'm sure many players (especially those at the early stages of trying interplanetary transfers) would only do a single mission at a time. Added benefit this could help me evenly space mapping satellites, power relays... Alright I'm convinced this is a good idea.
IRL this is done with station keeping thrusters and I read somewhere that it takes something like 1-2 m/s deltav every few months to stay in the lane set for many geostationary and earth observing satellites. Maybe we require RCS and burn it at some slow rate for station keeping maneuvers?
I don't think that this is a bad idea. Its going to be quite complicated to implement and the ui could be crazy but right now people are editing saves and avoiding control and that feels pretty lame. On Jun 28, 2014 10:22 PM, "Devin Chollak" [email protected] wrote:
Alright, I do see your point now, especially when using lower orbits. I'm just not sure snapping into orbits is really the best solution. However, I can't think of anything better off the top of my head to get nearly drift free orbits without an absurd amount of effort.
I guess from my point of view I rarely ever use high time warp for long because I run many concurrent missions but I'm sure many players (especially those at the early stages of trying interplanetary transfers) would only do a single mission at a time. Added benefit this could help me evenly space mapping satellites, power relays... Alright I'm convinced this is a good idea.
— Reply to this email directly or view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/115#issuecomment-47445509 .
If you want to be hardcore about it, figure the dV change based on desired change in SMA and the planet's mass. Then find the average Isp of all RCS thrusters (reflecting as necessary for ModuleRCSFX), find the fuels they use (ditto), and subtract as appropriate. :)
That said, what's actually going on is (a) n-body stuff and (b) variations in the Earth's gravitational field itself that cause satellites to drift in real life; neither problem exists in KSP and precision errors are much less threatening...probably not enough dV to worry about, since this should only fire when you load and unload a network satellite, which, once you establish the network, should be rather uncommon.
I don't like the idea because it forces players to a particular play style. In this case, some players prefer to use ion engines for station-keeping instead of RCS. And once you allow any engine to be used for fuel, things get really complicated.
SMA-snapping is contrived and artificial, but IMO that makes it fit much better into how KSP works.
Well, since generally the problem with satellite drift over time is mainly one of satellites you're trying to keep synced in similar orbits get out of phase, why note a master > follower dynamic?
IoW: Launch a satellite into orbit. Then designate that satellite as the 'master'. The master's orbital parameters are stored for reference. Launch the next satellite into orbit, designate it as the follower, and if its within a certain magnitude of error from the reference orbit (like, tiny), then it gets Set-positioned into identical orbital parameters, has its phase angle from the master satellite stored, and gets reset after a certain level of 'drift' (out of phase) is achieved.
Launch two, three, and four satellites in followup and have them all lock on to the same 'master' and they sync up as a flying group.
For coding purposes, designating a 'master' would probably need to include code options good for scaling up. So, designating the 'master' could be called 'starting a constellation' and the player could name it. This name then gets appended to all satellites getting added to it.
There are all kinds of ways to get fancy, such as making them simulate station keeping and all that, but that could come later.
After reading more about it, Nathan is right. Many craft only need mm of delta v to station keep.
My original comment was not trying to be hardcore, just give a little flavor to the feature. Like all new features we should start with the smallest bit that makes sense. requiring that you have some kind of propulsion system on board is not part of an MVP
My opinions:
- This shouldn't require fuel. As mentioned, different players will want to use different systems, and the amount of fuel should be negligible. I wouldn't even check for thrusters or engines. Close enough is close enough.
- I like the idea of a button-list of craft with the same SMA when you're close to a synchronous orbit, and those buttons un-greying when you're close enough. Clicking on one of the active ones forces synchronisation to that craft on unload. This means the player needs to (a) opt-in to the adjustment, and (b) is given a visual indication when their orbit is "close enough". Ideally this should have toolbar integration, so players can open it only when they want to SMA snap.
- As mentioned, this is applicable to things beyond RemoteTech. It could be used for KSPI, ScanSAT, and so on. Unless it needs to be tightly bound to RT, I would suggest making it a separate mod (which may be distributed with RT). It also allows it to be completely disabled just by removing the auxiliary mod.
- Bonus points awarded to be able to explicitly placed synchronous craft into a group, give that group a name, and see that list later on.
After reading the whole thread here, I want to chime in that I agree with @pjf's comment above 100%.
[...] different players will want to use different systems [...]
...so why not make this configurable on a per-save (or even per-vessel) basis?
Perhaps something along the lines of
Enable SMA snap? -- checkbox
Use fuel for station-keeping? -- checkbox
Use RCS thrusters for station-keeping? -- checkbox
Use engines for station-keeping? -- checkbox
< list of checkbox/label pairs, one for each engine >
My preference would be for grouping with user input. For a user invisible method though I would recommend using a percentage tolerance of orbital period. That's effectively angular drift rate anyway. I do like the idea of requiring station-keeping burns (I currently do it by sending satellites with extra dV and engines that would be able to do it and then I actually do it when needed) but that is a whole load of complexity. If it is an option I would still say let any engine be allowed since if a user is going to "cheat" then I doubt he would use this option.
I agree with everything pjf said EXCEPT for the bit about it not requiring fuel. Real-world satellites have positional maintenance systems designed to keep the satellite in a specific spot on their orbit, and these systems have fuel. When that fuel runs out, the satellite's orbit is going to decay, and needs to be replaced or refueled.
I'd like to see some sort've part you could install on a satellite (very tiny, matchbook size maybe) that enables the ideas in this conversation (grouping, orbit design, etc) but very slowly (over the course of a decade or two, minimum, possibly based on the amount of fuel sent up) eats through fuel (ala food, oxygen, etc in TAC Life Support).
It should probably utilize existing fuel types.
That leaves it quite open to the question of what counts as fuel, especially when interacting with other mods. Perhaps requiring fuel can be a setting option, instead of a hardcoded yes/no?
