ALERT and CLARAty – Lessons Learned Michael Mossey – May 22, 2003

The idea of coprocessed spacecraft Typical radiation-hardened spacecraft CPU (slow) COTS coprocessor (fast but vulnerable to radiation-induced faults)

First ALERT demonstration of coprocessing and fault tolerance Software and hardware testbed: Gestalt navigator on Rocky 8 How processing was split between coprocessor and rad-hard Coprocessor: Macintosh G4 laptop Coprocessor (“laptop” or “G4” or “server”) : computation of disparity maps Rad-hard (“rover” or “client”) : Gestalt top-level loop and all functions besides disparity maps. Additionally, management of the laptop processes, and fault tolerance algorithm. Fault tolerance strategy Run the computation on the coprocessor N times, until the last two runs agree (Note: application on coprocessor run “from scratch”)

Network communications – assisted by CLARAty sockets G4 Laptop (“coprocessor”)Rocky 8 (“rad-hard processor”) Gestalt Remote stereo application Functions as TCP server Initiates process Initiates network connection

CLARAty sockets Generally served well. (simple, foolproof) Could have used a timeout (ACE will help)

Networking issues Problem: exceeded the maximum number of available sockets in VxWorks. Temporary solution: rebuild VxWorks with more memory set aside for sockets. Better long-term solution: don’t restart server process and maintain connection

Vision processing code (“JPL Stereo”) Comes in many versions ALERT-original: optimized for Altivec processing CLARAty version: tweaked to allow a wider field of view others on lab In the end, chose CLARAty version Lesson: we need to be aware of options, behavior

Modularity Gestalt – use abstracted pieces Vision processing code – drop in remote version transparently Distributed processing – a priority for CLARAty?