WASP (v1) ADP Controller Code Review

Overview

Although the rest of the ADP is a distributed set of objects communicating via CORBA, the ADP Controller is different. It contains a large number of objects and tasks, all running in the same process. This last aspect is (unfortunately) necessitated by the National Instruments and MegaVision libraries that disallow access from multiple processes.

This page contains the materials for several of the code review meetings. It doesn't contain what I said, only what I pointed at. Sorry.

Sources

The source code! (dun dun duuhnnnnnn!)

CORBA Interfaces

detail the CORBA interfaces here. explain relationships between objects. where does b2b happen? where does registration happen? where does fire detection happen? etc.

Class Tree

Class Relationships

Class Details

Tasks and Event Handlers

Within the WASP Controller process are a number of tasks and event handlers, implemented in one or more threads. Not all of them are directly derived from ACE_Task, although some should be (RTIE).

Listener

Listener is an event handler that waits for new network data to arrive from the Applanix unit. Upon receiving an Event 1 (Indigo camera trigger) or an Event 2 (Terrapix camera trigger), the listener decodes the event packet, extracting a navigation solution. This navigation solution is used as a triggering message for the various camera workers in the system; a NavSol is enqueued onto each CamWorker object's incoming work queue.

When the CamWorker for a specific camera dequeues this work message (near instantaneously), it converts the NavSol into a camera exterior orientation. Then it polls the camera hardware (which should have an image waiting)

This navigation solution is converted into an exterior orientation, and sent along to the appropriate camera worker objects (one per camera). These workers extract the image data from the camera hardware, combine it with the EO data, and pass it along to the rest of the ADP (via CORBA) using the CamCorbaPair object, which acts as a bridge between the CamWorker tasks and the ORB's task.

RTIE

There are 3 RTIE objects in the system. Within each object, a separate dedicated thread runs its looper function. This is responsible for polling the Indigo serial ports, decoding the packets that arrive, and updating the rest of the system depending on the decoded packet.

For example, another object in the system might send a query to the shortwave camera, requesting that the camera return its internal table of loaded NUC settings. The camera then responds asynchronously. This response is picked up by its associated RTIE object, which updates the table of known NUC tables in the system.

Driver

The Driver task is responsible for sending the trigger pulses to the National Instruments hardware and the Terrapix camera hardware. It can pause, choose to fire only the Indigo or Terrapix cameras, or have its timing changed via the Controller object's interface.

The Driver object performs a lengthy startup sequence, sampling the resolution of the operating system's timing support and adjusting its internal delay loops accordingly. In this way, it tries very hard to fire the cameras at exactly the rate that the user requests.