[Note: I’m almost positive this isn’t a new idea, but I figured I would share it, just in case.]
One of the many concerns with deep-space human spaceflight missions, is that all of NASA’s experience has been with missions close enough to Earth that mission control could be in direct and nearly instantaneous communication with astronauts. Worst case round-trip speed-of-light delays for the Apollo missions were on the order of 2.5-3s or less. But for missions even to NEOs, let alone Mars, you quickly end up with round-trip speed-of-light delays on the order of tens of minutes, to over 3/4 of an hour worst-case at Mars. It is a legitimate concern that NASA’s practical experience in mission ops has been so used to mission control being able to provide almost instantaneous feedback when problems crop up.
One very cheap way to fix this might be to intentionally start simulating speed-of-light delays between ISS astronauts and mission control (and visa versa). There are very few problems on ISS that really need real-time mission control help, and getting used to dealing even with problems with a built-in time lag would be useful experience for deeper space mission. If NASA can’t stomach the risk of doing this with a big space station like ISS, I can’t imagine they’ll ever have the intestinal fortitude to really do a crewed deep-space mission.
If desired, NASA could theoretically start with only a small delay, and then gradually build to longer times. For instance, once commercial crew starts flying, maybe they intentionally swap the whole USOS team out at once (instead of staggering the replacements like they do right now). Then start initially with no lag, but adding lag little by little, at about the rate that it would build up for a mission to an asteroid or Mars. You might make some exceptions for communication between astronauts performing research on the ISS and the ground subject matter experts they’re working with (since ISS isn’t just about preparing for deep space, but also about performing useful research), but make sure that they’re not allowed to talk with other NASA folks except via the speed-of-light delay simulated communications link. Also keep communication with friends and family on the ground routed through that delayed link as well.
My guess is that if they started performing this experiment on a regular basis, they’d likely learn all sorts of new things. Some things they’ve done in the past may translate fairly well to a delayed environment, while large parts of how they do things now may have to change. But really, if NASA wants to prepare for deep-space missions, why not start now when the risks are low? Not only would the mission control people learn better how to interact with crews at long distances, but those crews will also be gaining experience with interacting with mission control at long distances. My guess is even if a commercial deep space mission isn’t done exactly as NASA would (fairly likely), that there’ll still be all sorts of useful lessons learned that could be passed on.
And really this experiment wouldn’t cost hardly to add to the ISS manifest.
Does anyone know if NASA has thought of doing something like this? Any suggestions on how to run the experiment better?
Jonathan Goff
Latest posts by Jonathan Goff (see all)
- NASA’s Selection of the Blue Moon Lander for Artemis V - May 25, 2023
- Fill ‘er Up: New AIAA Aerospace America Article on Propellant Depots - September 2, 2022
- Independent Perspectives on Cislunar Depotization - August 26, 2022
Unionize the ground controllers and not only will you get the desired 45-minute time delay, the default initial controller response will be “Who wants to know?” That will be followed over the next several hours by five or six less helpful responses, including “Do I sound like an ECS guy?” “You’ve got the wrong freakin’ channel, and no, I won’t pass you along because that’s not my job,” and “Your problem isn’t my problem, capiche?”
George, you’re a brilliantly sick man. 🙂
~Jon
Two ideas
1) Possibly combine this experiment with the gravity level experiment proposed earlier instead of using the main station crew.
2) I wonder if a good source of information on these sort of issues would be US Navy submariners. Subs don’t have communications delay per se, but my understanding is that communication with submerged subs must take place through very low bandwidth ELF communications so it may take a while to get large messages through. So crews are still somewhat on there own outside of very specific messages such as “Launch the missiles.”
Ya aughta go on tour George… deliciously sick.
I’d recommend talking to the Mars Society.
One of the most enjoyable things I ever did when I was active with them was working as Mission Control for their Mars Desert Research Station. At least for the rotations we did, we had a thirty minute delay on all non-emergency communications.
That’s a big step from doing the same thing on the ISS, but maybe there were some useful lessons learned.
Just recently suggestion to someone that a novel, relatively low cost X-Prize would be a Lunar Delay Race (on Earth.) Teams in different categories would build and control vehicles in a race over a course through very rough terrain, teleop’d by video (and/or other instruments) on the vehicle held behind a 1 1/3 second delay each way. (Ie, lunar delay, 2 2/3 seconds.)
Straight race, fastest wins. Categories for vehicle weight/size, and maybe some school/kiddy categories.
It would be interesting to see whether (and how much) intelligence on the vehicle helps make up for the teleop delay. Whether you are better to strip away that weight (lidar/etc) and just use a simple camera and a guy with good anticipation on the joystick. Or whether having an AI see/avoid problems within the 2 2/3 second window allows the teleoperator to go faster, take more risk.
bombloader,
Yeah there are a wide range of doing shorter experiments without using the main station crew. The problem is that by definition, all of those are going to provide far less data, and in many cases provide that data in a less real environment. I would be happy to see those other alternatives (including doing delayed mission control on the xGRF mission and delayed mission control on a simulated Mars hab vehicle) done in addition to this ISS delayed mission control suggestion, not instead of it.
~Jon
“Just recently suggestion to someone”
Heh, didn’t see that. Clearly I meant “just recently suggestion too someone”.
Jon, we need a preview or post-edit function for the comments. You know, when you have a moment…
Mars society desert station usage in reverse for teleops testing from ISS might be interesting, for a mars orbit telops of mars surface devices that has been proposed in teh past. Though it might be useful to first read up on current best practices in terrestrial teleop remote mining operations. A fair number of mines (usually strip mines) are doing teleop dump trucks, and some are approaching full automation (for direct mining ops, not necessarily refueling or infrastructure work though).
Back when NASA was building the BioPlex Mars Habitat at JSC, there were plans to introduce Mars comm delays after the initial shakedown runs in the habitat. There was going to be a “switch to instant comm” mode built in for emergencies.
In addition there have been active studies at JSC, working with JPL, to do an “internet for planetary exploration”. They were looking at everything from predictive simulation for the controllers to try to anticipate problems, down to the nuts and bolts of how to adapt TCP/IP protocols for long time delays.
If NASA does hire a small commercial spacestation the effects of delays in communications could be one of the things tested there.
Not sure such an experiment would prove much, except perhaps exploring psychological effects of time delay. Those psychological effects are better and far more inexpensively established on the ground, as noted for Mars Habitat. Microgravity is probably not relevant to how humans respond to delayed communication. As to on-orbit operations, ISS was designed for real-time communication. So when things don’t work well with time delays, what exactly is being proved?
Doug,
While ISS was intended originally to use real-time communications for control functions, adapting it and then seeing what happens would likely be a lot more informative than any simulated mission. Practices at the Mars Habitat almost by definition have all sorts of simplifications that real life operations don’t. Which means you’ll never learn as much from it as you would form operating a real functional space vehicle like the ISS under those simulated lags. Obviously there are easier ways to get lower fidelity data via terrestrial analogs, but would that really prepare us for those sort of space operations as much as actually operating an honest-to-goodness mission with the lag built in would?
~Jon
“Obviously there are easier ways to get lower fidelity data via terrestrial analogs, but would that really prepare us for those sort of space operations as much as actually operating an honest-to-goodness mission with the lag built in would?”
That’s why JSC mission ops folks are working with JPL on this problem. JPL has done the missions with time delays, JSC can apply those lessons to terrestrial testbeds.
Slightly OT, but another area that you could add to a Mars simulation (which would also only work on an artificial structure like ISS) is to adopt a Mars day length. A large percentage of people can apparently adapt to 24hrs 40min (**), but are there long term effects for normal people trying to function month after month in that cycle? (A kind of slow onset cumulative sleep deprivation.)
You can’t simulate that on Mars Habitat/MDRS, since they are exposed to Earth-day sunlight. And more isolated facilities like Mars-500 and traditional sleep-timing/sleep-entrainment research don’t have real-life activities to pick up genuine stress of operating a mission. (Indeed, most sleep-timing research seems to struggle to find enough to do to keep volunteers occupied through the day.)
(** And a few of us even prefer it. Non-24/DSPD/etc.)
Actually the Mars Habitat simulation on Devon Island in the Canadian Arctic did run things on a 24h 40m sleep wake cycle during the Arctic summer with continuous daylight.
I learned this from a talk by one of the participants of that simulation so I can’t give a reference.