The software is broken into three components: the FrontEnd, the Body, and the Backend. These components are separated by abstract interface. The Frontend_Interface is for communication between the Frontend and the Body. The Backend_Interface is for communication between the Backend and the body.

Frontend

The frontend is basically the user interface. Because we use an abstraction layer between the Frontend and the body, we can have many different frontends. For example we can have a labview frontend that looks like top.vi from igvc2006. We can have a simple commandline frontend. We can also have a JAUS-based frontend. The frontends can be used interchangeably as long as they implement the protocol described in the Frontend_Interface.

Frontend_Interface

Body

The body is the main processing element. It will contain the navigation and state estimation code. It receives commands from the front end and data from the backend. It processes these things and sends commands to the backend (e.g. motor commands) and information to the frontend (e.g. success or failure) (not all of this is implemented yet, and the arrow on the image should be double-headed)

Backend_Interface

Backend

The backend primarily consists of device drivers. However, since we implement an abstract interface between the Backend and the Body, we have added flexibility. Drivers can be in a single process or more than once process (as long as they implement the protocol described in the Backend_Interface). The drivers can also be replaced by a simulator, that mimics the protocol, but simulates the data. Other processes can also use the Backend Interface. For example, a monitor process can silently receive all the packets that go across the backend interface and display the data. Or we can log all the data for postprocessing playback.


source for this image is at trunk/sw_design.ppt trunk/doc/sw_design.png


Proposed Changes to Software Design

  • Tasks to be completed
    • 2 minute Drill by Oct. 15th, run DPRG relative waypoint code with only 2 minute software setup time
      • This could include converting over drivers to C++
        • ChrisDerichs - Converting IMU Python Driver and C++ driver to send same packets
        • KevinBaker - Converting GPS Python Driver into something cleaner,
        • AndrewLynch - Converting S12 driver for C++, with possible expansion of software