Bringing Home the Science Bacon

MRO recently passed a milestone of bringing back more data than all previous deep space missions combined.  To do this MRO was equipped with a large dish antenna and powerful radio, and is running a more powerful computer than it's companions on and orbiting Mars.  It gets a fair share of antenna time from the DSN antennae on the ground.

Science means collecting data, processing it for it's information, and analyzing the information.  All of these activities can be greatly facilitated by some degree of computer assistance. When it comes to remote-operated scientists (rovers, gliders, orbiters, diggers, swimmers, crawlers, hover-ers..) the computer has to do all the work.

Where it comes to an autonomous robot, or even partially autonomous, a balance must be struck between the amount of data that can be brought back (telemetry bandwidth), the amount of data collected by the science instruments, the amount of processing it takes to turn the data into information, and the processing ability of the computer(s) in the robot.  If the largest gating factor is the bandwidth, and you can gain 10x the science return by processing the data first, you may limit how much data you collect in favor of processing it into information.  If your biggest limitation is processing power, you may just concentrate on getting data off of science instruments and ready for transmit back.  The typical deep space mission has both challenges, and more.

There are terrestrial applications that have similar challenges.  Remote sensing networks, deep sea ROVs and robots, and some industrial applications, as well as military applications, may need to operate independently for periods of time, storing data for upload at the "next" connection.  There could be limitations on storage, processing ability, power, connection bandwidth. 

Some of the solution could be to run multicore.  You may be able to run a multicore chip at a reduced clock rate to save power and gain more processing power than a similar single-core chip at full clock speed.  By increasing the processing power, and using mixed methods (SMP,AMP) as in Mark's "Sea Of Cores...Now What?" discussion, you may be able to handle both steering data and processing it into information. This could increase the science return of the mission.  But with multicore, how do you balance the trade-offs and where do you focus your increase in processing power?

By simulating the whole affair you may be able to gauge how fully loaded your system is.  If you have processing power left, and also important, data steering capacity left, you may be able to share your telemetry stream with another project.  This is part of what NASA has done with the satellites orbiting Mars and the MER and Phoenix robots. The robots collect their data and do what processing they can, storing the results.  They are designed to send data directly to Earth, and do.  When possible, they can also transfer data to the satellites, borrowing some of their bandwidth.  By using a little slack-time in the orbiter's schedules, they're increasing the science return of the robots on the surface.

Increasing the processing power of one key system can increase the data-product returns of an entire group of systems. It can increase the returns both in terms of the quantity of data and quality of information returned.  With careful planning, the "more remote" systems can be coordinated to take advantage of data-stream offload, perhaps doing some data processing, or just collecting more raw data.  Prudent use of a virtualized / multicore system could be one great way of doing this.

None of the current Mars robots are empowered with multicore - when they were designed multicore wasn't as prevalent as today, and there are still very few multicore chips designed for the rigors of space.  There are plenty of off-the-shelf chips with multiple cores available.  Terrestrial based applications can start benefiting from SMP/AMP systems today.