Development of the Caveatron


A few years ago, I started to get interested in how you might use electronics to improve cave mapping. I participated in a LIDAR survey at Devil’s Sinkhole, which was impressive but the equipment was big, heavy, slow and very expensive. I also saw some small survey equipment cavers were making such as the DistoX and the Shetland Attack Pony, which were also very nice and can speed up a survey by taking shot data, but were not exactly what I was looking for. The time consuming part is sketching, and I wanted to find a way to make it faster and more accurate. Rather than waiting for someone to make the cave survey device I wanted, I realized that I should just do it myself! I am an engineer by profession and had some programming experience as well, plus I got two of my fellow co-workers and cavers involved who had knowledge I did not: Steve Gutting has lots of soldering and electronics assembly experience and Gregg Williams who has extensive machining experience and could help with mechanical design.

My first idea was a basic device that produced LRUDs (left, right, up, and down) measurements continuously along a passage. Since a laser solution seemed too big and costly at the time, I thought ultrasonics might be the way to go. I had worked with some small ultrasonic sensors previously that were relatively inexpensive, so I tried them out in a cave and they seemed to work well. The idea for the first prototype of the Caveatron was to use 4 of these to get the LRUDs and to somehow to figure out the position of the ultrasonic sensors as you move. Getting compass angle and tilt was not too hard since small electronic modules with a magnetometer and accelerometer were not too hard to come by. Distance was another matter. Laser distos (rangefinders) would be the best solution, but they are almost all made with proprietary interfaces and there is no real way to communicate with them (except for some very expensive industrial models). As an alternative, I came up with the idea of using a remote transponder with it's own ultrasonic emitter that sent a pulse to a receiver on the main unit. An infrared LED in the main unit was used to send a signal to activate the transponder’s ultrasonic emitter. The time from sending the IR pulse until receiving the ultrasonic pulse gave a pretty accurate distance measurement (to a centimeter or so) at up to 15 m away.

The first prototype had a very basic interface with a numeric membrane keypad and a 2-line text LCD. It stored the LRUD data on a built-in SD card. After a few cave tests, it became obvious that the Caveatron had a lot of potential, including being used to take the regular distance, azimuth and inclination shot data. It also seemed that if it was going to do all these things, a better way of controlling it was needed. I came across some low cost touchscreen displays which would not only allow me to make whatever user interface I needed, but also allow data to be displayed to the user instead of just being stored. So I set out to build the first complete prototype including the display, the LRUD ultrasonic sensors, and added a laser pointer to accurately align it for taking shots and LRUDs. This prototype ran on 4 AA batteries. During testing, it worked well and was it pretty cool to watch it build up the LRUDs as you walked through the cave. However, with further testing some problems became apparent. First the compass calibration was erratic. It would stay relatively good for a time but then suddenly change for no apparently reason (found to be occur when replacing the batteries). Another problem, which became apparent on a longer trip in Deep Cave, was that after a few hours the ultrasonic sensors would start to behave erratically and eventually just quit altogether. After coming out of the cave, they would then go back to normal. I concluded that humidity was the cause, which was a major problem since it would only allow use for short periods in most caves.

The first Caveatron prototype with the LRUD ultrasonic transducers on the front of the unit and the ultrasonic transponder module at bottom.

About this time, I came across a low cost LIDAR scanner that was used in robotic vacuum cleaners and discovered that some people had figured out how to hack it and use it for other purposes. This LIDAR scans a full 360 degrees at 1 point per degree at 4.5 rotations per second. This sounded very interesting, so I bought one to try it out. Sure enough it seemed to work, so we built a new prototype based on previous version – still using ultrasonics for distance and a transponder – to test out the LIDAR in a cave. We tried it out in Robber Baron and after looking at the data, I was blown away by how great the data looked. You could view the cave in 3D and when looked at from inside the cloud, it was very recognizable! At this point in time it was only a point cloud, so still crude, but after working out more sophisticated post-processing of the data to get rid of noisy points and add surface normal, I discovered that it was fairly simple to render this point cloud into an actual surface to make solid walls and get a truly realistic looking 3D model that you could “explore” both inside and out. This was far better than what I had originally set out to do and nothing else like this existed at such a low cost and small size.

The final piece of the puzzle was finding a laser rangefinder to replace the ultrasonic transponder. I came across a blog where someone had found a disto with a hidden serial port that seemed to work. I ordered one and sure enough, it was possible to command it and get distance measurements back over that connection. It worked well and reliably acquired distance data out to more than 45 m at up to 3 measurements per second.

The second Caveatron prototype with the LIDAR on the front. This version also used the ultrasonic transponder for distance measurements.

One issue with incorporating the LIDAR is that it generates a lot of data. The original processor I was using (an Arduino Mega 2560) only had a 16 MHz 8-bit processor with 8kB of memory and 256kB of code storage. This was clearly not enough since LIDAR data was being lost and the touchscreen I was using exhibited slow refreshes. Since I had become familiar with the Arduino platform, I wanted to stick with it and fortunately they had just come out with a much faster design, the Arduino Due with an 84 MHz 32-bit ARM processor with 96kB of RAM and 512kB of code storage. The downside was that it used a different voltage and the different type of processor would require modifying portions of the code. Between all the new components, and the increasing complexity of the software, I concluded that I needed to redesign the system and rewrite the code from the beginning to be more flexible and easier to work with. The user interface components were written into a separate library, the GUI code was redesigned to be interrupt based and the code was re-written to divide it up into smaller re-useable modules.

Since I was essentially starting over, I wanted to use what I learned from the early versions to make this one even better. First, switching to a built-in rechargeable battery was necessary to avoid the calibration challenges I encountered with replaceable batteries. A 4400 mAh Lithium-ion battery pack was selected to provide more than 8 hrs of run time. The next piece was the touchscreen. The previous one had a low resolution and the two fonts it provided were too limiting for the GUI and hard to read. I found a new LCD that was slightly bigger with a brighter screen and with almost double the resolution (480 x 320 pixels) for about the same price. It also included an SD card slot that was more than 8x faster and a font chip with a wide range of sizes that were much more readable. It could also save images on the chip, so I could use it to store the on-screen button icons that Jill Orr had so generously created.

Other changes included a real-time clock with a small replaceable button cell that keeps time regardless of whether the Caveatron is powered on or off. A battery monitor board measures the charge of the Li-Ion pack and another board safety regulates charging of the battery. Other electronics provide the various voltages needed throughout the system. A piezoelectric buzzer is used to provide audio tones while taking shots and passage scans to reduce the need to look at the screen for feedback. About the only thing that didn’t change was the compass module, although a newer version was chosen with double the accelerometer resolution.

© Copyright 2020 Joe Mitchell

Make a site - Get more