/*!

\page LITADomain LITA Domain Documentation

<hr>

\section LITAIntroduction Introduction to the LITA Mission


\li The "Life in the Atacama" (LITA) Mission is being conducted by Carnegia Mellon 
University (CMU), Ames TI Division and other partners, in the Atacama Desert in Chile. 
\li This desert has been selected for this campaign because it has little or no 
evident life forms, being extremely dry.  
\li The experiment there consists of scientists at CMU sending science plans to the 
Rover in the desert, after which the Rover executes the plan, addressing local internal and 
external conditions as they arise, including various status messages from other hadware. 
\li In tnis context, a science plan is a sequence of science activities, each with a specific
goal.  For example, drive to a specific location, takng one or more pictures, processing that data
for the use of other instruments, taking further images, etc. 
\li For certain images, the rover will use a suite of other instruments to examine the field of view of the 
cameras, to see if likely signatures of living orgnisms can be identified.  
\li Software consisting of a single IDEA Agent is used as the Executive in the Rover software 
architecture. 

\section IDEARole IDEA's Role in the LITA Misson 

\li The LITA Rover software architecture includes a planner (Tempest), an Executive, in this
case an IDDA agent, a Health 
Monitor, and Multiple Instruments, where here an Instrument is a device (such as a camera, or
a spectrograph, but also a drive controller) each of which from the point of view of the Executive, 
receives commands, and returns status.  
\li In this general plan, a single IDEA Agent plays the role of the Executive, processing the
science plan from the Tempest Planner, with the result being commands sent to each other
hardware device on the rover.  
\li The Rover is planned to operate ten hours a day, not all of which needs to be in 
motion.  Science actions require that the Rover be stationary.
\li The current Rover operation is to proceed at a speed of approximately one meter per 
second, for a total daily traverse of 10-15 km.  
\li One of the team members actually has the data identifying the location where evidence of life was found during 
last years Atacama field test.  These location, however, are kept in secret durng the present field test.
\li For last years field test, a laptop was used to steer and control the rover, but for this 
test autonomous control will be used.
\li A fluorescent imager is used (via green light) to look for evidence of life in the 
immediate terrain.  However, the rover is not able to retrieve any of the material, although 
it does have a plow allowing it to disturb the surface beneath it.
\li The Rover is 1.5 feet above the ground, to reduce the chance of damage due to rocks in its path.
\li The Rover uses a GPS for its location functioning.

<hr>

\subsection EXECOperations Executive Operations

\li The rover operations are set up so that either the Planner, or the IDEA executive is 
operating, but not both.  
\li The responsibility of the Planner is to generate a plan, consisting of a series of 
activities.  
\li This activity list, annotated with target times for each activity, constitutes 
a plan which is input to the Executive.  The plan can cover up to ten hours.
\li Activities include navigation, drive actions for the wheels, charging the batteries 
using the solar arrays, and science activities, such as using the imager.
\li The Executive (actually the Goal Loader in the IDEA Core) converts the plan into a 
series of tokens, one per input activity, plus token parameters, such as duration, or parameters 
to be given to an instrument via commands to it.
\li The Executive must also keep track of which of these goals have already been achieved. The 
result is called the goal timeline.  
\li If the Executive runs into a problem with the plan, it can throw away the future 
(already-planned) part of the goal timeline.  This is also referred to as freeing the future, 
in IDEA parlance.
\li The Executive maintains, besides the goal timeline, one or more internal timelines 
which are used to control execution of the goal timeline.   For example, a plan token on an internal 
timeline can cause the Executive to begin a new plan.  Of course, the plan token was placed 
there by the executive itself at an earlier time.

\subsection ExecutiveInternals  Internals of the IDEA Executive

\li The rover Executive consists, in the highest level, of the IDEA Core (currently IDEA-3, 
but soon to be IDEA-DEV) plus the LITA domain model.
\li IDEA-DEV is the latest (late 2005) version of the IDEA core which uses PLASMA (Europa-2)
as the plan database.
\li The current highest goal of the LITA team is rover robustness.
\li Once this is achieved, and proven, the goal will shift to improving performance.
\li The domain model provides the constraints which will be used to organize the planned 
activities into a timeline of executable commands sent to one or more of the rover instruments. 

\sebsection FaultDetection Fault Detection and Recovery

\li The Health Monitor provides notice of faults to the Executive.  The faults can either 
arise due to some external event (arriving at a rock or ditch) or an internal fault in the 
software.
\li The LITA model incorporates the response for each specified fault by specifying what 
additional token relationships (actually, time-adjacency-relationships) have changed, and which 
new ones must be added, as a result of the fault.
\li At the point that notice of a fault is received, the Executive must replan the future, 
using not only the remaining activities on the goal timeline, but also any response to the fault 
itself.  
\li In many cases, the recovery steps which must be taken depend on which activity was 
underway when the fault occurred. 

<hr>

*/
