Building the Cave Mapper: A Technical Deep-Dive

The Challenge of Underwater Cave Surveying

Traditional cave surveying is a slow, methodical process that is prone to error and detracts from the dive itself. The process involves repeatedly stopping to take measurements with a slate, compass, and inclinometer, then sketching the passage before moving a short distance to do it all again.

The goal was to create a device that allows the diver to simply swim, letting the technology build the map during the exploration.

The result is a handheld mapper that tracks the diver’s path and renders a stick map on a screen in real-time. No stopping, no manual data entry, and no post-dive recollection of details is required.

The Hardware

The mapper is built around the RP2350 (Raspberry Pi Pico 2). It was chosen for several reasons:

Dual Cores: This allows the critical navigation loop to run on one core at a deterministic 100Hz, while the second core manages the display, SD card, and user interface without interrupting the core navigation calculations.
PIO: The programmable I/O allows for the creation of custom hardware interfaces for sensors with non-standard protocols.
C/C++: Real-time sensor fusion of this nature requires low-level code for performance and control.

The display is a Waveshare RP2350-Touch-AMOLED-1.64, a 280x456 AMOLED screen with touch capability that offers excellent readability in dark, underwater environments.

The Sensors

Distance: AS5600 Magnetic Encoder

A key design choice was to measure distance by tracking line deployment rather than using sonar or LiDAR, which have significant drawbacks underwater.

An AS5600 magnetic encoder is coupled to a small wheel that rolls against the guideline. As line pays out, the wheel’s rotation is measured by the 12-bit encoder, and the distance traveled is calculated. This I2C sensor is inexpensive and provides high-resolution data.

Orientation: BNO085 IMU

The BNO085 is a 9-axis IMU with an integrated processor that performs on-board sensor fusion of the accelerometer, gyroscope, and magnetometer data. It outputs a stable quaternion with low drift, which greatly simplifies the sensor fusion implementation in the main processor. It is polled at 100Hz to provide heading data that is accurate to within a few degrees.

Depth: MS5837-30BA Pressure Sensor

This is a high-resolution (approx. 2mm of water) pressure transducer commonly used in ROVs and other underwater systems. Rated to 30 bar (300 meters), it is temperature-compensated and reliable. Due to its particular I2C timing requirements (clock-stretching), a custom driver was written for it using the RP2350’s PIO.

How the Two Cores Work Together

The dual-core architecture is essential to the system’s performance.

Core 1: The Navigation Loop (100Hz)

Every 10ms, it acquires data from all sensors.
It performs the core calculation: change in distance + orientation + change in depth = new 3D position.
It writes the new state to a shared memory buffer.
It includes logic to handle transient sensor dropouts.

Core 0: Everything Else

Renders the map on the display.
Writes navigation data to the SD card (at a lower 10Hz rate).
Manages the touch-screen user interface.
Monitors battery status.

The cores communicate via a custom-implemented shared buffer with a spinlock, as the 56-byte navigation data packet exceeds the size of the RP2350’s built-in FIFO.

A critical implementation detail is the use of double-precision floating-point numbers for position tracking. Using standard single-precision floats results in a rapid loss of accuracy due to rounding errors (an issue known as “catastrophic cancellation”). Double-precision maintains millimeter-level accuracy over the course of a full cave traverse.

Dealing with Bad Data

The system must be robust to sensor anomalies. The software constantly performs sanity checks between sensors. For example:

Encoder reports movement but IMU is static? The line may be slipping.
IMU reports movement but encoder is zero? The wheel may be jammed.

If a conflict is detected, the system flags the suspect data and alerts the user, preventing a bad vector from corrupting the map. The system can also handle transient sensor failures by reusing last-known-good values, preventing a momentary glitch from invalidating the entire survey.

After the Dive

The mapper logs the complete dive path to a .nav file on the SD card, recording position, orientation, depth, and sensor status at 10Hz.

A web-based 3D viewer, built with Three.js, was also developed. Users can upload the log file to:

Replay the dive path with a scrubbable timeline.
Color-code the path by depth or speed.
Switch between imperial and metric units.
Apply vertical exaggeration to better visualize the cave profile.
Save an image of the resulting map.

The viewer is mobile-friendly, allowing for immediate review of the dive path at the site.

What’s Next

We are looking for experienced cave divers who conduct surveys and are interested in becoming beta testers. If you can provide real-world feedback, please get in touch.