Home

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.

Romulus 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.

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.