ITTROV - Software

Software Design for ROVITT (Emery Premeaux)



The software design for the ITTROV project was a challenge. First and foremost was to categorize how the software should work. This plan would guide the rest of the design process. Unfortunately, it changed constantly as I re-evaluated what was important, and what was not.
I wrote the PIC microcontroller’s code in C, using HI-TECH’s C compiler with their HI-TIDE Integrated Development Environment. The version I used is free to all, and will compile code for a select few PIC chips. I found that after working with the system for a while, I became very comfortable with the IDE and compiling structure. The C programming classes we took in the Bachelors program were very helpful.

In order to get the code onto the PIC chip, I used a programming device called the PICALL. It is connected through the parallel port and has its own software to load up the compiled program and burn it into the PIC.

The final step for the PIC was to return it to a prototyping board I had set up that replicated the circuitry still under construction for the ROV. The board had a clock circuit, a power supply, and the same MAX232 communications chip as the sub would have. The only difference between the test board and the real thing was that the motor outputs on the test board were LEDs rather than the motor driver circuit.

I had decided early on to design the code on the PIC in such a way as to allow the user to operate it from a serial communications program such as Terminal. This meant that all of the commands to and responses from the ROV would be human readable. I wanted the user to be able to enter a command, and the sub would respond back with text confirming the action.
The final system would allow for a separate program written in Visual Basic to control the ROV. This program would connect to the com port of the ROV and act as if it were human. It would read in the responses from the ROV and display status messages on the control panel. When the operator clicks on a command button, the software would take care of sending that command and verifying the ROV received it properly.

The software went through several revisions. The first idea was to accept commands in a string format, such as “1 100.” This would indicate motor one should be operating at 100%. Unfortunately after many days of scratching my head, I found out that the free version of the HI-TECH C does not include string INPUT functions. However it did include string OUTPUT functions. This is important because it meant I could make the sub respond back with a message like “Motor 1 at 100 percent” but I could not take in the command in the first place. In fact, all I could process in was a single character.

The final version of the revision code worked more like a conversation with the ROV. It went something like this:
Enter a Command: 1
Enter a value for motor 1: 1
Motor 1 is ON.

This worked out well, at first. While still building the electronics and integrating them to the frame it was helpful to be able to operate single motors at a time. After a while problems began to surface.

The first problem was that the code executed a sort of timed loop through the nested Select Case statements that made up the code. It expected the commands to occur at specific moments, and could not deal with them when entered at the wrong time. This often led to multiple tries re-entering the commands in the Terminal program. It was also very clunky to try to move the sub around. We need to turn on combinations of two motors. There would be a long time delay between getting both motors to turn on.

It was felt that the interface software on the laptop would alleviate this somewhat. It was being developed in parallel with the PIC code. I had to create needlessly complex code to deal with this ‘conversation delay’ between the PIC and the computer. To make things worse, I had to analyze the responses back from the PIC in order to determine when it was acceptable to send commands.

In order to get around some of this, I wrote the code to use subroutines. For example: Clicking on the ‘forward’ button would call two functions. Each motor has an “On” and an “Off” function. So “forward” would call the “on” functions for the appropriate motors. Each motor function then sets two variables: the motor number and the value (1 for on, 0 for off). This function then calls a final function to communicate this request to the ROV.

This isolated my problems communicating to only one section of code. After working on this process for a long time, I still could not get around the problems with the ROV. There would still be long delays between getting two motors on, if the second motor command ever even managed to get there. The whole deal was unreliable.

It was time for plan B. I had no plan B. It was 3 weeks to the presentation and I had no idea how to fix this. Eventually it came to me while no where near a computer. The design constraint of HI-TECH C was that I could only send one character at a time. So, why bother sending multiple characters to get anywhere?

I completely redesigned the ROV software with only one Select Case process. It now accepted u, d, l, r, f, b, and s. Up, Down, Left, Right, Forward, Backwards and all Stop. I then set all motors appropriately to the command sent. For instance, Up and Down will not affect the other navigation commands, and those commands will not affect Up and Down. However, when Forward is sent, all motors not intended for that command are turned off. This meant that I could only turn in place and not turn while moving forward, but it vastly simplified both sides of the code. The loop also ran much quicker. The ROV was not asking for commands in a timed manner, and accepted them at any given moment.

It was a joy to see my motor LEDs respond instantly to my requests. I was so happy in fact that I placed personality into the responses the ROV gives when it processes a request. For instance, when ‘f’ is sent, the ROV may with “Forward! Aye, aye, captain!”