May 13 2010, 07:30 PM
How flexible is the MSL embedded software? Could it be modified "in situ" to accommodate teleoperation by humans in Mars orbit?
In my current line of work I work with underwater vehicles of various kinds. An Autonomous Underwater Vehicle (AUV) is a free-swimming robot with no physical connection to the surface. Since radio waves do not propagate through seawater and since acoustic communications are generally very slow, "real-time" human control of the AUV is not practical. Instead the AUV onboard software is designed for autonomous untended operation. MSL seems analogous to an AUV; the long Earth-Mars light-time eliminates the possibility of "fast" human response. So I presume that MSL onboard software is similar in its design to AUV software.
I also work with Remotely Operated Vehicles (ROVs) which are connected to a surface vessel via electro-optical tether. The ROV is operated by human pilots on the surface vessel, who use joy-sticks and other UIs to "fly" the vehicle and control its instruments in real-time. The vehicle software is designed specifically to accommodate the human-in-the-loop control; these control loops operate at millisecond intervals. ROV software design is quite different from AUV software design.
Let's be wildly optimistic and suppose that there is a human expedition to Martian orbit in the next twenty years, but no human landing yet. The orbital mission could bring its own tele-operated surface robots, but I wonder if they could also use MSL if it is still operational. Would it be possible to re-program MSL in situ to accommodate real-time teleoperation by astronauts in Mars orbit?
May 14 2010, 02:18 PM
I think that right from the start MSL is going to be power limited, so I doubt much more could be archived per sol without the time delay from earth (let alone after 20 years or RTG decay!) Re-programming would be the last of your worries.
Before anyone replies, consider both forum rules 1.6 & 1.9.
This topic is a little close to both blue-sky/sci-fi engineering and the manned spaceflight banned topics.
May 16 2010, 01:19 PM
Operating Lunakhod 2 at only a few light seconds from Earth was certainly much easier than operating a rover on Mars. This ease of operation enabled Lunakhod 2 to drive 35 km in just 4.5 months.
So far as MSL is concerned I once read that there were plans to operate MSL at night and that for this reason it MSL might have been provided with a searchlight. It was felt that the abundance of free power meant that round the clock driving might be possible.
I wonder if it would still be possible to perform 2 drives with MSL each day? Perhaps the first drive could occur early in the morning, followed by 5 hours of contemplation of images and then followed by a second drive in the evening?
May 16 2010, 02:07 PM
MSL has many things. Awesome cameras. A frickin laser beam. A sense of terror and awe, frankly. One thing it does NOT have is an abudance of power. Floodlights and night time operations have been mentioned by the interested public, but only because they see the RTG and think 'unlimited power'. It's not. It still has a power budget It still has to stop and recharge batteries. A year or so ago there was a story suggesting that auxiliary solar arrays might be added to MSL, such was the power budget. MAHLI is qualified to work at night (it's White and UV led's would probably make night time imaging the best type of imaging.)
With MRO and MODY - there's no opportunity for mid-day downlink of enough data to plan another drive.
May 21 2010, 06:55 PM
There is no doubt that MSL's software could be adapted to teleoperational modes of control for at least part of the system (mobility, arm use). However as Doug and the others mention there is a TON of other constraints that would preclude operations by orbiting astronauts (not the least of which is that MSL's RTG will run out of power long before any astronaut will ever get to Mars orbit).
One of the biggest constraints for operating a rover on Mars from the vantage point of a Mars-orbiting astronaut is the communication link problem. One trick is to place the astronaut's space station is in a highly eccentric orbit that "hangs" in the sky above the rover long enough to have a direct link (preferably during the Mars day when the rover's actuators are warmed up). The station could also actually hang in a areocentric orbit right above the rover's landing site. Likewise a network of TDRSS-like communication satellites would also do the trick and could allow the astronauts space station to be nearly anywhere nearby.
Due to the rover's power limitations it is not clear to me how much real-time teleoperational control of MSL would greatly speed things up. Like the MERs, MSL is narcoleptic, sleeping most of the time and moving very little (and slowly at that). The astronauts would have to have the patience of a saint.
Or we could save (vast amounts of) money and simply do what we did with MER and add new intelligence (software) for detecting conditions and science targets of interest autonomously. We need to get the basics done first and that is what we are doing right now.
As for driving more than once a day, it is not impossible, but it will depend on the temperatures and available power. We use a great deal of energy to simply warm up the wheel actuators before a drive in the morning. Doing that warm up heating at night might be challenging. We will see. We can meet our design requirements without multiple drives a sol.
May 23 2010, 04:58 AM
Thanks for clarifying those limitations guys. What is the RTG half-life? Sorry to hear about the narcolepsy - maybe some Java would cure that. ;-)
QUOTE (MarsEngineer @ May 21 2010, 10:55 AM)
we could save (vast amounts of) money and simply do what we did with MER and add new intelligence (software) for detecting conditions and science targets of interest autonomously. We need to get the basics done first and that is what we are doing right now.
At MBARI we've adapted the ground-based MAPGEN-Europa planning software used for MER operations, and it into our onboard AUV control system:
www.mbari.org/autonomy/Publications/ICAPS07-workshop.pdf It has been quite interesting and challenging to modify this software for a completely autonomous real-time system.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here