ROV Telepresence Software

NASA Ames Research Center

September 9, 1992

Kurt D. Schwehr
P.O. Box 11067
Stanford, CA. 94309
schwehr@cs.stanford.edu


1. Summary .................................  1

2. Detailed Description ....................  1
     2.1 General Design ....................  1
     2.2 Head Tracking .....................  1
     2.3 Data Logging ......................  1
     2.4 Zoom/Focus ........................  2
     2.5 Navigation ........................  2

APPENDIX A - Suggestions for future work .... 3

APPENDIX B - Navigatin Equations ............ 4
     B-1 General Concepts and Notes ......... 4
     B-2 Camera orientation ................. 5
     B-3 One Beacon Position Determination .. 6
     B-4 Two Beacon Position Determination .. 7

1. Summary

The NASA Ames ROV telepresence software adds head tracking, data logging, and navigation to the EXP512 software developed by Deep Ocean Engineering. In addition to the primary features, control of the Cohu camera's zoom and focus was developed, but not used do to damage of the camera. The software has been designed to give priority to head tracking, resulting in a 10 to 15 Hz update rate for the slaved camera. This rate was fast enough that the camera moters were responsible for almost all of the observer delay of pan and tilt. The science data is stored on disk in an ASCII file without interupting head tracking. The navigation system is bsaed on sighting oon navigation beacons - lights placed under the ice. The system is based on an Amiga 2000 equipped with a 7 port serial board and an Elchen anoalog to digital sampling board.

NOTE: The accompanying document, "ROV Software user Manual," provides information on how to use the software and its hardware components.

2. Detailed Description

2.1 General Design

The telepresence software uses the same event loop disigned into the DOE code. Some of the events happen every loop: head tracking, heading, depth, and time. The rest of the events only occur when the operating system sends them a message: menuing, navigation, and data logging. It is fairly easy to add new functions to the program. Just add an event trap to the main loop. If the event comes up, the code will switch over to the appropriate function. It is important that these event handlers are very fast. Any time they take adds delay to the head tracking and long delays (>15 seconds) can cause loss of science data.

2.2 Head Tracking

The tracking systen is based on a Polhemus 3 Space Isotrak. The program queries the tracker by sending it a "P". The head tracker reponds by sending the yaw, pitch, and roll which are converted into pan and tilt. The pan and tilt are then send off to Keithley modules to command the camera motors. The system is pretty robust. If the incoming data is bad, it flushes the input buffer and tries again the next time around the main loop. Unfortunately, the tracking code can be delayed by other functions in the code. Such things as disk writes will halt the tracking. This has yet to become a problem , but it must always be kept in mind when adding to the system. Currently, the primary delay in head tracking is due to the speed of the pan/tilt motors. They are slowed down by circuits that remove jitter. It is possible that the "head" could cause problems. The tilt motor is not very strong and may not be able to pull down the head's floatation. If not needed, the head tracking can be turned off via the main menu.

2.3 Data Logging

The data logging receives data from the serial port used by the CR 10 datalogger. The format of the data is comma delimited ASCII text. The Amiga's OS buffers the data and sends the program a message when it has data ready. The program extracts out important information (battery voltage and science sensors) and displays them in a window. The program also warns the operator when the datalogger's battery coltage gets low. It copies all the data into a 5K buffer. When this buffer is close to full, the program takes about 2 seconds to write the data to disk, emptying the buffer. The buffer is also written to disk when the program is quit. It is easy to add text to the buffer so it is written to disk with the science data: Copy the text in character by into the buffer and increment the character counter by the number of characters added. More sensors can be added to the datalogger's data by adding the data to the end of the stream. The program will ignore the extra data while extracting the primary science data and will write the data to disk without any additional code.

2.4 Zoom/Focus Control

The zoom and focus control code is currently commented out of the code due to the flooding of the Cohu camera. It is still in place. To get it back to working, uncomment all the zoom/focus code plus the countdown timer around the call to the datalogger function. Currently, the zoom/focus code is a bit on the touchy side. The Elchen board has some loose wiring that complicated development. However, the code does work despite these troubles.

The zoom and focus work by reading the status of two switches on the joystick control box. If the status of the two switches changes from the last time they were read, the program builds up a command string to send to the digital Keithley module. Since the control has three ports for zoom and focus (direction, zoom on/off, and focus on/off) the program shuts down focus if the user is zooming.

There is an added complication to the zoom/focus code: the data logger is on the same serial line. The way it is setup, every character sent down the line arrices at the Keithley. The Keithley echoes all the characters it receives to the data logger. The data logger and and the Keithley command sets are such that there are never any problems of conflict. When zoom/focus commands are sent to the Keithley, they cause the datalogger to pause its sending of data. About 45 seconds after the flow of data for zoom/focus stops, the data logger will start sending science data again. During the zoom focus, the data logger echoes all the zoom/focus control and responce back up the serial line. To avoid this messing up the science data, the program waits for several seconds after the zooming/focusing before checking fo science data. During this time, it continuely flushes the serial driver's buffer of the junk created by zoom and focus. This should not noticably slow down the dead tracking.

2.5 Navigation

The navigation code is based on a system of lights (navigation beacons) to be placed underneath the ice at the dive sight. 16 lights will be laid out in four different directions of four lights in each direction. The lights are to be about 125 feet apart. Each light can be individually turned on and off to determine which beacon is being abserved. The program has a table of the location and depth of each of the beacons. Once the light array has been laid out, the locations should be entered into this table. The default table is an idealistic representation of the light layout. The user must recompile the program after the correct coordinates are entered, so the navigation software is not suitable for the Amiga ROM drive.

The operator uses a navigation screen to center the subs camera on a beacon. Once the operator knows which light they are looking at, they use the mouse to select the beacon. The program has two algorithms for finding the location (See Appendix B). The simplest uses only one beacon and the ROV's depth. The second algothm is for use when the verticle angle between the sub and the beacon is too small, causing large errors with one beacon. This second algorithm requires the user to sight on two different beacons. The program presents the user with the calculated location for acceptability. The navigation code requires that the user always keep the depth in feet.

There is a second screen that keeps a record of the subs path on a grid. The center of the grid is the dive hole and the navigation markers are labeled with X's in the appropriate postions. The program draws a line from each subposition to the next. Due to lavk of further information, the program uses a linear approximation of the sub's path. At the bottom are the numerical location and the direction to the dive hole from the current position. Once the user accepts a location, it is displayed on the graph and put into the science data.

Page 3

Appendix A - Suggestions for Future Work

Page 4

Appendix B

World Coordinates
Spherical Coordinates
Conversions
Triable Geometry

Page 5

Calculate Theta and Phi from pan & tilt

Page 6

Calculate the world location with one beacon and depth

Error Estimate

Page 7

Calculate the sub location with two beacons and without using depth

Page 8