Version1:Software
From Albatross
The Albatross software is split into two main categories, software which runs on the plane (Embedded Software), and PC software which runs on the ground, including the ground station and the simulator.
See the Development page for the software development procedure.
Embedded Software
The Embedded software is split between code which runs on Snapper, and code which runs on the Supervisor. Both software is written in C, and communication between the PXA255 and the AVR occurs over the I2C link.
Snapper Software
Due to the complexity of Albatross, we spent considerable time evaluating the best possible framework for communication between the different system components. We decided to use UDP socket communication because;
- it is lightweight
- no need to store state information
- no retransmissions
- no latency for sender
- independent of medium (Ethernet, local, PPP)
- easy to implement, and easy to debug.
Each main task associated with flying the plane (stability, sensor fusion, hardware interface) runs as a independent process within the PXA255. These processes communicate using UDP datagrams (which can have a maximum size of 65,536 bytes). All inter-process UDP communication is multicast, each process can act on the data if it wishes to.
The contents of the datagram is described in more detail here: Protocol.
Architecture
There are a number of individual processes (daemons) running on snapper at any one time. All daemons communicate through UDP packets multicast onto the network. This allows all daemons to be run on the same system (such as during flight), or on different computers (such as for testing). This is especially relevant when considering the role of the simulator; by substituting the hardware daemon running on snapper, for the suimlator running on another computer, the rest of the system software is unaware of any change.
All daemons are listed below, for more information click on the daemons name to go to a page describing its operation;
Control
See Control
Supervisor Software
The supervisor spends most of its time idle, waiting for a specified escape sequence over the communications rradio. It also waits for any commands over the I2C link. With the exception of power on, it will probably spend most of its time asleep, to conserve power, and will only wake on interrupt (RS232, or I2C).
The datagram parsing code developed for the PXA255 may be reused (to some degree) in the AVR Supervisor to parse the datagrams from the ground station, and by the Groundstation communications code.
Architecture
etc...
Ground Station
see Groundstation.
Architecture
Screenshots
Simulator
We are not sure of the best way for the simulator to substitute into the system at this stage. It will at least have to replace the hardware interface daemon. It may need to listen to more information sources than the hardware daemon does (which will be easy due to the multicast functionality) and provide some sensory information. See Simulator
Architecture
Screenshots
Unsorted Stuff
FIXME
