RaspSub Software Overview
Mar 8, 2015 @ 12:10am
The submarine is composed of two different applications, the first is the controller software, it runs the hardware, provides drivers for all the custom hardware I developed, and will eventually allow the submarine to operate independently from it's remote.
The remote, shown below is written to use GTK+3, it provides all inputs to the submarine (such as the joystick), and lets you view all the run data, including saved runs.
The software is broken down into two parts, the controller, running on the raspberry pi, and the remote running on a desktop/laptop whatever. Everything is written in C, and the two applications share
Raspberry Pi Controller SW
The raspberry pi controller software communicates on the I2C bus directly with the various chips on my custom hardware I talked about in an earlier post. It also communicates with the AVR via SPI and the network. All processed data is saved out into a log file and this log file is synchronized with the remote software.
Eventually the controller software will hopefully employ some navigation functions, so it can autonomously navigate, controlling the servos/motor on it's own.
Remote Control SW
The remote control software is built using GTK+ 3 for the UI, and the interface was built with glade. It provides joystick input and joystick configuration, which is used to control all servos directly. There are also settings windows to manage the various calibration constants throughout the system. Sensor values get graphed, and current values are displayed, when the camera is working that will show up.
Common code
Most of the code for the communication between the two is common, I developed a custom network protocol, a custom file format and console messages are handled by an error logging facility that handles locking of stdout and logs the messages, providing various severity levels. Additionally the network protocol uses both TCP and UDP, small messages are sent via UDP (like commands from the joystick), while large messages like video and recovered data logging are sent via TCP (since these larger messages require fragmentation and are not generally time critical, and retransmission can be handled at a lower level).
Roadblocks
During the development I've hit a number of problems, most of which were do to just difficulty in finding the right documentation. Turns out gtk_combo_box uses an MVC model, unlike everything else in GTK and it's barely documented at all, UDP can have connection errors, despite having no connection to reset.
