The Auriga project

Computer Aided Cave Surveying

This is rather a long-term project of mine. I copied this page from my old web site - although it is a bit outdated, I keep the old content. See Introduction for an explanation of what this is about and the state of the project in the year 2000. I hope this is not too confusing...

What happened since 2000?

I stopped working on this project a few years ago. I had built the sensor module prototype and it worked more or less. There were issues both concerning handling and accuracy. I would have had to add an additional clino axis and create a compact layout for the whole electronics. In addition, the calibration of any compass sensor is rather complex. This project would need my entire spare time for more than a year or two... and would cavers be willing to pay a reasonable price for such an instrument? No. So the whole thing went on hold. 

Nothing happened.... until Luc Le Blanc contacted me. He was interested in the software part of Auriga and I handed the code over to him. He started working on it and, with an incredible amount of energy, he developed an impressive program (it is still called Auriga) you can use for entering and viewing surveying data in a cave. Even if you are only interested a little bit in this project, download his software and test it. It runs on a Palm handheld device, but if you don't own one, you can download a simulator that behaves like a real Palm on your windows computer. Try it - you'll be impressed!

• Luc's Auriga page
• Palm OS simulator

Resources

If you'd like to build an electronic surveying instrument yourself, there are lots of resources that might help you. First, there are some commercially available sensor modules. See my article for a list. I'd recommend the

• TNT revolution compass module (500 US$)

which is pretty accurate and, except for the limited tilt range, exactly what you need.

Introduction

See below for latest results! (this refers to the state of affairs in the year 2000...)

The Auriga project is about developing an electronic surveying tool to make cave surveying easier and less error-prone. Currently, the standard process is to measure heading and tilt with a sighting compass and clino, write the data down on some waterproof  paper and enter the data into a surveying program at home. 
There is lots of room for improvements here. The sighting instruments are difficult to use in low light conditions and narrow passages. Writing the data down and reading them at home from a mud-smeared paper also introduces the possibility of mis-readings.
Auriga addresses all these problems:

• inclination and heading measurements are made with an electronic sensor array
• data is stored electronically and can be checked still in the cave
• data can be exported to the surveying program at home

Hardware

To answer the most frequently asked question first: No, Auriga currently does not contain a laser ranger. The laser is for aiming only, you have to measure the distance with another instrument.
I experimented for several years with various sensors and processor boards before I finally came up with this design:

• Data processing, storage, visualisation and user interface: PalmPilot (I have an old PalmPilot Personal)
• Sensor box: Separate unit with PIC16F877 processor, ADC, laser diode, pushbutton switch
• Inclination sensor: High accuracy industrial electrolytic sensor for one tilt axis
• Magnetic field: Three MR sensors
• Power supply: Separate unit with alkaline batteries and linear regulators

Sensor box, power supply and PalmPilot

 Auriga sensor box

In this picture, you can see some of the components: bubble level, red piezo pushbutton (totally waterproof as it's a solid piece of aluminium), microprocessor and laser diode (to the front). The ceramic inclination sensor is near the front at the left side. Below the processor PCB are the three magnetic field sensor modules and part of the clino signal conditioning.

How it works

To measure tilt and heading, you hold the Auriga box at one surveying point and aim to the next point using the laser diode. You have to hold the box exactly vertical, which is not difficult using the bubble level. When you think you're ready, press the piezo pushbutton. The microcontroller sends the measurement data continuously to the Pilot (about three measurements per second) and when you press the button, the software takes the measurement that was sent about 1s before you pressed the button. It would be possible to integrate some intelligence here: check if the readings are differing too much (and request a new measurement) or automatically select a measurement where the user has seemed to hold the box quiet steady. Or simply do some averaging. This needs still more experimenting with the user interface.

Screen shot of data processing subprogram

The Pilot program then calculates the heading and inclination and displays the values. On the screen, you can see the raw ADC data, the normalised X, Y and Z components, heading and inclination. Additionally, the magnetic field amplitude and the inclination of the magnetic field vector is displayed. These two values are quiet useful to judge if the field is distorted. The amplitude (relative to the calibration measurement) should always be 1 and the magnetic inclination around 60 degrees. The above screen shot shows a measurement of the box lying on the table, roughly pointing north with lots of tools lying around.

Data processing and Calibration

The inclinometer data processing is quiet simple. The raw ADC value is fed into a third order polynomial, resulting in the inclination value in degrees. It is accurate to less than .1 degrees over the entire +-80 degrees range which should be good enough for a hand-held measurement. I got the calibration values by fixing the clino to a high resolution rotary encoder and slowly turning it by 180 degrees (turning really slowly is pretty difficult - I finally solved that by driving it by the minute hand of a clockwork). A polynomial fit yielded the correction parameters.

Calibrating the magnetoresistive sensor array was much more difficult. Unfortunately, the magnetic field in my apartment is pretty distorted. Field strength varies from 0.5 to 1.6 and a compass shows heading errors of up to 90 degrees! I had to go out into open field to get a stable field vector.

In a first step, the ADC values are normalised by removing offset, amplitude and phase errors between the axes. I got these values by rotating the box around, storing the values and using an ellipsoid fit (Gauss linear least square algorithm) to get the ellipsoid equation for the data. From this equation, you can derive offset, amplitude and phase errors. Offset and amplitude are removed directly (e.g. y=(y-yo)/ya), the phase error angles are transformed in three vectors with the corresponding angles and the inverse of the resulting 3x3 matrix is used to remove the sensor misalignment.

The corrected field vector is then rotated around the bubble level axis by the measured inclination angle. Heading and magnetic inclination are then calculated from this resulting vector. The level axis is obtained by another least square fit of some data from rotating the box around this axis.
Currently, all calibration values are constants embedded in the Auriga source code. Exact north and horizontal reference values are simply added to the calibrated sensor output, but acquiring the calibration values is more difficult. Actually, only amplitude and offset needs to be recalibrated - maybe I add this feature later...

Software

The Auriga toporobot front end I wrote two years ago still needs to be integrated with the data processing software. This is mainly because I have to port the PilRC resource files to the Codewarrior environment I'm using now.
The toporobot front end of Auriga lets you:

• take surveying data from previous trips with you, zoom through the data in the cave and identify surveying points
• take the pilot into a cave and enter survey data there (not very comfortable though)
• check the data graphically in the cave and resurvey if necessary
• instantly view the data together with all existing survey points
• back at home, transfer the data to your PC and to your surveying program. (well, almost - the database converter still needs to be programmed...)

I haven't used the software in a cave yet and probably it needs a bit more programming before I would do that. But that's not much work.
Nice features to build into Auriga: (I'll do that myself when I've got the time):

• print data and graphics on a portable printer as a backup and as a base for your sketches
• display a rotating 3 D-view of the cave
• enter cross-sections and additional drawings using the digitiser screen
• add entrance co-ordinates and view multiple caves together to check for possible connections

 I'm not planning to reinvent surveying software - there is excellent software for use at home, but when on a surveying trip, you would need a laptop computer for that. Helicopter transport in the mountains is really expensive and you'd better avoid flying a generator to the camp just to power your computer. In contrast, the pilot runs a long time (several months in normal use) with two alkaline AAA cells.
But first, making the pilot cave-proof is the biggest problem. For "easy" caves just putting it in a clear plastic bag (like the waterproof document bags) might be sufficient, perhaps building a metal box to protect it during transport. Getting it really cave-proof is something else - putting the unit into a massive aluminium case could even make it dive-proof, but wouldn't let you use the digitiser screen, forcing you to make all entries with the six buttons (or something equivalent). I'll have to check myself which level of ruggedness is necessary. The digitiser screen is definitely a nice thing and makes operation much easier, but is of course not stomp-on-proof or drop-from-five-metres-proof.
 
"realistic" view of the emulator
 
emulator screen shot of graphical display

Latest Results

 I've tested Auriga during two ISAAK expeditions recently (Sägistal and Kosovo) and made some interesting experiences. Although I didn't have a real cave-proof case for the pilot and the power supply, both survived the trips quiet well. I checked most measurements against Suunto sighting instruments.
The current version of Auriga is clearly a prototype - there are a lot of things that need to be done, but it was very useful to have a "live" test in a real cave surveying environment to find out what's most unnerving.
 

• Handling: holding the sensor box horizontal using the bubble level is rather difficult and nearly impossible for long shots. Most times you can't view both the bubble level and the laser beam. I had expected to be this a problem, but it seems that this is the main problem for the accuracy. As there are no high precision dual-axis inclination sensors, one solution would be to add a lower precision tilt sensor for the second tilt axis with some acoustic feedback: If the user tilts the box to the left or right, it beeps with high or low frequency. One could measure the remaining tilt (e.g.. +- 5 degrees) and use this value in the geometry correction.
• Handling: The piezo pushbutton is pretty difficult to operate. It is rather insensitive and has no tactile feedback at all. Of course, the software beeps when you press the button, but when it didn't work, you have to aim again.
• Accuracy: Inclination has (not surprisingly) not been a problem (the sensor is calibrated to 0.1 degrees). Heading was mostly accurate to 1 or 2 degrees. I think the main problem is holding the sensor box horizontal - this easily generates errors of some degrees. Hard or soft-iron effects disturbing the magnetic field have never been a problem outside - the total magnetic field strength is always within +-1 % of the nominal value.
• Handling: Currently, the power supply is rather bulky and has a separate switch. It would be nice to have a small switch mode power supply (perhaps operating from 3-4 AA cells) with software-controlled shutdown. This shouldn't be a real problem.
• Aiming with the laser is not as easy as it sounds. Of course it' much easier than looking through a sighting compass, but for long shots (15 m or more) aiming gets rather difficult. One idea would be to use a small camera for aiming: You point roughly in the direction of the survey point, which could be marked by a small lamp (flashing LED or something). The camera could identify the position of the light point (perhaps by knowing the flash frequency) and measure the exact position relative to the sensor box tilt/heading. This would require an additional (CMOS/CCD) camera module, a frame grabber and some image processing hardware.
• Of course, having a laser ranger would be nice. We used one during the Kosovo trip and it was really great! Much easier than a tape measure. The question is if it would be much more comfortable to have it integrated in Auriga than having a separate unit.

Pilot Hardware

(this is rather outdated... museum reference only...)  One pages describing the pilot hardware is Pilot Hardware Main Page. I'll just give a short summary:
 

•  CPU is a Motorola 68328 "Dragonball". This is a CPU32 core with DRAM controller, LCD support, A/D converter and serial interface. Clock frequency is about 10 MHz.
• The display is a 160x160 pixel b/w LCD display. Normal operating mode is monochrome (1 bit/pixel) and can be switched to greyscale (2 bits/pixel). The display area and an additional writing area is covered by a digitiser, newer pilots do have a backlight.
• The unit is powered by 2 AAA cells using a 3.3V switched-mode power supply with gold-cap backup for changing batteries. There is no off-switch, the operating system just handles the on- and standby states quiet cleverly to minimise battery power.
• The operating system and all built-in applications are stored in a ROM. As RAM memory, all pilots contain pseudo-static dynamic ram memory chips that need constant refresh cycles (even when switched off). Data databases are write-protected and are usually unaffected by crashing applications (this happens frequently when programming!).
• ROM and RAM chips are located on a small pcb that can be exchanged to upgrade to a newer OS, more memory or both. PalmOS is very memory efficient, you'll never be able to fill 512K using the built-in apps.
• Connection to a desktop computer is accomplished via an RS232-interface (MAX3233 level converter for most lines). In addition to RxD, TxD and some status lines, there are two more port pins on the connector that can be used for additional data input.