Control System Refinement

Over the last couple of days I have been working on the control system design. Originally it was going to consist of three main elements: a laptop, Raspberry Pi, and Propeller Chip. The laptop would run the pilot console program (written in python). The pilot console would display the video feed along with sensor information and extra controls, such as motor trim sliders for example. A usb gamepad would act as the primary input for controlling the rov. The laptop would communicate with the RaspPi over ethernet or WiFi through the tether. The RaspPi would have a program that sends the video from the camera module over the network, along with a python program that would act as an intermediary between the laptop pilot console program and the Propeller Chip. The Propeller would be responsible for controlling the actual hardware and managing any sensors. Here is a “diagram” of the setup:

[Laptop]~~Tether~~[RaspPi]–[Propeller]–{Hardware}

After a bit of cogitation I settled on a different, more “compact” system. In this new layout the RaspPi is moved to to surface and integrated into the pilot console. Here is a “diagram”:

[Touch Screen]–[RaspPi]~~Tether~~[Propeller]–{Hardware}
[LCD TV]~~~~~Tether~~~~~[Underwater camera]

The pilot console will hopefully be a handheld unit that consists of two screens, a gamepad, and a compartment for the RaspPi and it’s battery. One screen will be a 7″ LCD TV, the other a 7″ RaspPi touchscreen (the “official” RaspPi touchscreen advertised on the RaspPi website). The LCD TV will display the rov’s video feed, while the touchscreen will display the pilot console program. I’m not quite sure yet what method I will use to transfer data over the tether. I have a few ideas, but will save that for a later post. The camera will be an off-the-shelf underwater fish cam from ebay. I have used these in previous projects and they seem to work decently well.

So, what are the benefits of this revised system? Well, it provides two main benefits.

  1. It makes my life a little easier (hopefully). In the original system the python program was essentially broken up between two devices. This meant that I would have the additional overhead of getting the two parts reliably communicating over tcp or udp. While that’s not an impossible task, it adds additional complexity which not only takes more time to develop, debug, and maintain, but also adds a major failure point. With this new design those the parts are consolidated into one program.

  2. It simplifies the user experience. The end user doesn’t have to worry about installing a pilot console program on their laptop and trying to get it to communicate with the rov’s internal computer. The pilot console is now one device that is preinstalled with the appropriate software. All the user has to do is connect it to the tether and power the rov and pilot console on. No dealing with weird issues caused by the myriad of variables that are present with a “bring your own laptop” scheme.

Leave a comment