![]() |
|
Software Software Architecture
This year the
software architecture was reorganized into a more modular design.
By having more programs with
clearly defines purposes, making changes to increase mission capability
is simpler.
Our program
suite consists of concurrent processes that write to and read from a
shared memory structure that can be accessed by any program. All the
code is written in C using a GNU GCC compiler and is run on a Debian
Linux distribution.
The programs break
down into three basic types: control, user interface, and sensors.
Control Code
The Sinister Penguin
utilizes three
primary control levels: behavior, operation, and mission.
The behavior level contains two programs.
One is the device controller that controls the position of
mission devices, and a program called maneuver that contains attitude
controllers that maintain desired headings, pitches, depths and speeds.
The depth control is a PID controller, with the depth
derivative obtained from an observer on the depth signal. The depth
controller has different gain and saturation values for the forward and
aft thrusters to account for hydrodynamic and buoyancy forces, allowing
more controlled descent. The pitch control uses a PI controller.
The heading controller has been unreliably since the vehicle was
shortened in 2009.
We tried
using PI, PD, and PID controllers for the heading, but were ultimately
unsuccessful.
We decided to
control the heading using a state machine, with constant voltage
commands for different error ranges.
When the vehicle is too far off course, it stops and rotates in
place until it returns to the correct track.
Additionally, the thrusters reverse the direction of rotation as
a sort of break as the vehicle gets closer to the ordered heading.
The operation level contains one program for each
objective in the competition.
This allows us to easily change strategies for individual
competition tasks.
Each of
the programs reads a corresponding text file that contains information
for that task, such as the correct order of the buoys, or the correct
bin to target.
Using text
files for this information allows us to make changes without recompiling
the software.
These programs
do not run concurrently, but are initiated by the highest level of
control, the mission level.
The mission level contains one program, the sequential
controller.
This program
reads a text file that contains a list of the tasks the vehicle is to
attempt, and the order at which to attempt them.
The program then uses a system call to run the correct operation
level program.
After the
task is complete, or is deemed a failure, the sequential controller
moves to the next task in the mission sequence.
User Interface
To
increase user friendliness, the user interface has been
significantly improved.
We have added the use of the GNU application
Screen. Screen is a window multiplexing application that allows for
multiple programs to be running simultaneously in
different windows.
The display can be divided into regions
displaying multiple windows, or windows can remain
active in the background.
This application allowed us to have live data
feedback, as well as add the use of a simulation
program. We also
have a user interface program that allows the user to
navigate menus on the vehicle and decide various modes
of operating the vehicle including remote control and
autonomous modes.
Finally, we have improved our data logging program to be
active only while the vehicle is running a mission, so
we can store more data that is useful, and our plots are
not disrupted by irrelevant data points.
Helpful Software Links: |
![]() |