Jonathan Capone Technical Portfolio
OMEGA sections How It Works Research Context Data
How It Works chaptersOverviewSensingValidationMapping
OMEGA

How OMEGA works.

OMEGA combines field logging, point validation, and map generation in one workflow. The Arduino Mega records GPS, sonar, water temperature, IMU orientation, and UTC time, writes the full survey record to SD, and produces a filtered mapping dataset that Python converts into bathymetric surfaces and overlays.

GitHub Repository Part 1: Sensing Part 2: Validation Part 3: Mapping Research Context Data
Overview

OMEGA is organized as a measurement pipeline.

The system moves from acquisition to validation, from validation to logging, and from logging to reconstruction. Each stage has a different job, and each stage leaves a record that can be inspected later.

Workflow

From field reading to map output

1. CaptureGPS, sonar, temperature, IMU, and UTC time are sampled in the field.
2. ValidateFix quality, fix age, depth stability, motion, and spacing are checked.
3. LogThe logger writes the complete record and a cleaner mapping dataset.
4. ReconstructPython builds depth surfaces, contours, and geographic overlays.
Two records

The SD card keeps the full survey history and the accepted mapping points. That separation preserves the field record while keeping the surface model tied to a stricter set of conditions.

Codebase

Where the logic lives

  • arduino/rov_logger_mapping.ino handles sensor input, validation, display, and SD logging.
  • scripts/csv_to_png_depth_interpolated.py builds an interpolated depth surface from accepted survey points.
  • scripts/csv_to_png_depth_contours.py generates contour plots from the same mapping dataset.
  • scripts/csv_to_kmz_depth_overlay.py exports a georeferenced overlay for Google Earth.
System structure

The workflow joins sensing, validation, logging, and mapping.

The sonar estimates distance from acoustic travel time. GPS attaches each reading to location and UTC time. Temperature is used in the sound-speed correction. The IMU tracks platform orientation. Validation logic decides whether a reading enters the mapping dataset. The Python scripts then reconstruct a continuous surface from accepted points.

Sensing

Acoustic depth measurement

Sonar returns a range estimate, not a finished map. The depth value depends on pulse travel time and the assumed speed of sound in water.

Open page
Validation

Accepted points

GPS precision, fix age, motion state, spacing, and depth stability determine whether a reading becomes part of the mapping dataset.

Open page
Mapping

IDW reconstruction

Python converts accepted survey points into a gridded surface with inverse distance weighting, then exports map images and geographic files.

Open page
Research

Scientific context

Hydrography, sound-speed correction, spatial uncertainty, and bottom change provide the research frame for the system.

Open page
Current thresholds in the code

Mapping conditions are defined explicitly.

The Arduino code sets limits for GPS quality, fix age, platform motion, and sonar correction. Those values determine whether a point is kept in the accepted mapping dataset.

Parameter Current value Role in the survey
sonarCalSoundSpeed 1500.0 m/s Baseline sound speed used when correcting sonar range.
sonarCalTempC 20.0 °C Reference temperature associated with that baseline sound-speed value.
maxMapHdop 1.8 Rejects fixes with poorer horizontal precision.
maxMapFixAgeMs 2000 ms Rejects stale fixes that may no longer match the platform position closely.
maxMapSpeedKmph 8.0 km/h Limits mapping when the platform is moving too quickly.
maxMapPitchDeg 10.0° Rejects mapping points when pitch exceeds the allowed range.
maxMapRollDeg 10.0° Rejects mapping points when roll exceeds the allowed range.
Outputs

The same survey supports multiple kinds of analysis.

One field pass can produce several different outputs. The accepted mapping CSV keeps the point dataset. Interpolated PNG maps show the reconstructed surface. Contour plots emphasize slope and relief. KML and KMZ files place the result in geographic space for viewing in tools such as Google Earth.

Data products

What the workflow produces

  • Raw or complete survey logs for field review
  • Accepted mapping points for reconstruction
  • Interpolated depth rasters
  • Contour visualizations
  • Georeferenced overlays and KML/KMZ outputs
Interpretation

What the outputs depend on

Output quality depends on survey spacing, GPS precision, sound-speed assumptions, platform motion, and the interpolation settings used in Python. The map is a reconstruction built from accepted points, not a literal image of the entire bottom.