Written by Ken Monday, 22 September 2008 19:04

ROV Chronicles: Part 4

Software design

Most ROVs avoid using computers, relying instead on analogue electronics. We have decided to make our ROV smart, with its own on-board computer, and another computer to control it from the surface. Although this makes some of our design simpler, it does mean we need to design, write and test custom software – an engineering problem in its own right.

 

A lot of robotics researchers will tell you that phyically building the robot is the easy part – writing the software to make the robot do something useful is the hard bit. Luckily our ROV doesn’t require a great degree of artificial intelligence (at least not for the first prototype) – instead we will be using the software to replace a lot of custom electronics.

 

Software overview

The ROV software will consist of two distinct programs – a ‘server’ program that will run on the ROV, and a ‘client’ program that will run on a computer at the surface. The two programs will talk to each other via a software interface, using standard computer networking to communicate.

 

The server program will be responsible for controlling the ROV – it will take simple direction instructions from the controller on the surface (such as “forward 20% power” or “tilt camera down 40 degrees”) and translate them into signals to be sent to the motors. Because there will be five motors, and the movement commands could be a combination of forward/backwards, sideways, twist and up/down, the motors will have to be controlled intelligently to ensure that the commands from the surface are translated into the proper action.

 

The server program will also gather data from all the sensors (video camera, depth/pressure, altitude, temperature, pitch/roll, compass and possibly sonar) and send them back to the surface. Video will almost certainly need to be compressed in order to maintain a decent frame rate and resolution.

 

The client program will be responsible for receiving sensor information from the ROV and displaying it in a human-useable form – video on a screen, probably with the rest of the information overlayed on top of the video as text. Video will be saved to a hard disk for reference (and to act as a “black box” in case of disaster!)

 

The client program will also take control instructions from a joystick, to allow the user to issue movement instructions to the ROV. The joystick can be moved forward/backwards and side to side, but it can also be twisted (thus instructing the ROV to turn on the spot). Modern computer joysticks also include a “throttle control” that can be used to control the vertical thrust of the ROV. The Saitek ST290 joystick has been chosen for this project mainly because it includes these features for less than £20!

 

Advantages and possibilities of modular design

The interface where data is exchanged between the client and server programs is of key importance – it needs to be finalised at an early stage of the design process, and any changes to the interface will require BOTH programs to be modified.

 

Designing the software in this fashion has a number of advantages. Although the first prototype will have a very ROV-standard setup, with the client program on the surface computer being controlled by a human and the server program on the ROV doing the work, this doesn’t always have to be the case. It would be possible to run a version of the client program anywhere.

 

For instance, the ROV could be controlled remotely from a long way away over radio or satellite, thus allowing a “mission specialist” consultant to carry out specialist subsea work without having to be present on the ship carrying the ROV.

 

Alternatively, a version of the client program could actually be running on the ROV – either on the same computer as the server program, or on a separate “AI pod” – in order to carry out autonomous tasks such as following a pipeline, cleaning a structure or searching the seabed.

 

Changes to the ROV will require modifications to the server program, but (unless those changes mean the interface has to change as well) the client program can remain untouched.

 

Programming language

At this stage, all programming will be done in Borland Delphi. Delphi is a powerful windows-based programming language with an excellent Integrated Development Environment. There’s no practical reason the software shouldn’t be written in C, Java or some other language, but Delphi allows for very quick prototyping since it compiles and runs very quickly.

 

Open source?

A few people have asked me if I intend to release the software source code (and, in fact, the other details of the ROV) as open-source software so that other people can view, modify and recompile. The short answer is No – although I have no objection to open source (and think it’s a great idea) I don’t see any benefit to anyone else from having my source (it will, after all, only work on my ROV) and I don’t want to assume the extra overhead of documenting and maintaining an open source project.

 

Next time: Motors and controllers

 

Click here to discuss this article in our forums