Seaglider is a family of buoyancy driven autonomous underwater vehicles developed at the University of Washington. The IOP group at APL-UW has been leading that development for fifteen years and as of the beginning of 2023 is expanding its capability to directly support the community with software updates, technical support, maintenance, and new vehicles.
New vehicles will be our latest generation SGX, with 60% more battery capacity and more flexible payload options compared to earlier generations of the vehicle. Nominal displacement is 70kg. SGX uses the same ogive aft fairing as Seaglider but replaces the tapered forward fairing with a cylindrical mid-body fairing and a removable forward nose fairing. SGX is our team’s workhorse vehicle and has completed multiple year-long missions, including over-winter, under-ice Arctic deployments (longest is actually two winters, 22 months).
The current generation of vehicles are 15V univolt (replacing the original 10V/24V split rail architecture), use an ARM-based Rev E motherboard (replacing the TT8-based Rev B boards), an optional independent ARM-based science processor/controller (scicon), RBR Legato CTD, MCBH bulkhead connectors (replacing IE55), selectable magnetic or shorting plug on/off with software power off, and maintenance access from both forward and aft endcaps. Two sensor channels can be teed to both glider and scicon, offering options for fault tolerance and payload handling.
The latest glider firmware features improved mission scripting and autonomy, onboard automatic compass calibration, onboard automatic pitch and VBD trim, under-ice navigation and behaviors, more targeting options (fences, progress timeouts), improved depth loitering, more robust Iridium file transfer protocols (significantly reducing the need for file resends), new options to reduce upload sizes (primarily for under-ice backlog but maybe useful in other scenarios), and more. Early versions of some of these developments enabled our successful year-long missions to explore under and in front of Dotson ice shelf through an Antarctic winter, with current developments motivated by our work in the Arctic.
Basestation v3, released May 2023 under a BSD open-source license (https://github.com/iop-apl-uw/basestation3), represents a significant effort to improve QC handling and DAC submission, update to Python3, basestation-generated plots (removing any dependence on Matlab), automated flight model processing, and an entirely new web-based piloting and visualization application. The app is flexible and scalable. It works for a single pilot running a single mission over an SSH tunnel, requiring no additional database, web server, or firewall opening. It can also be run as a multi-user (or multi-institution even) piloting application with fine grained control of authentication and privileges, or as a public-facing web presence with no piloting features enabled. See seaglider.pub for examples of the new visualization capabilities.
Our development work focuses on the ARM branch of the firmware and basestation v3. We encourage users to upgrade and will help facilitate those upgrades. We are providing a basestation server, running v3, including visualization and piloting, in the cloud at no cost to users (see below). Basestation v3 software supports gliders running older versions of firmware and alternative sensors, and we will continue to work with users on compatibility issues.
We will offer updates for Rev B up to our last mission-proven version of that firmware, with the additional possibility of bug fixes. Note that we do anticipate subtle differences between our version of the code and what vendors may have deployed. Our code has always been the basis for every version of Seaglider, with licensees (iRobot/Kongsberg/Hydroid/HII) making minor changes. Where those changes offer significant support not otherwise available in the current version, we will work with users to try to find a path forward.
New central resources page for documentation and support links.
As part of our new support arrangements, all released firmware will come with features for under-ice missions with acoustic navigation. This includes RAFOS-based multilateration for position; ice avoidance based on temperature thresholding, altimeter detections, zero velocity, and seasonal/climatological ice maps; and mission scripting and control via the "exec" subsystem. The exec system allows an operator to construct a decision tree for glider control via changing cmdfile, targets, science, etc. in the familiar way, but via an automated mechanism executed completely on the glider without pilot intervention. Decision points on the tree can be based on numbers of dives, absolute or relative calendar dates, observed engineering variables, or target achievement (/timeout/too slow progress toward/...). A typical scenario might be to have the glider hold at a central location with long loiters at depth to preserve energy and once per month execute a section out and back or to another hold point. If while holding position the glider moves outside some watch circle, the exec system switches over to a branch that directs the glider to swim back (without loiter dives) to the central location. Once the central target is achieved, the glider switches back to long loiter dives until it next falls out of the watch circle or reaches a calendar point. Once battery voltage or a fuel gauge threshold are reached, the glider could try to swim in the direction of the most likely open water. For Antarctic ice shelf work we used scenarios that automatically controlled the approach to the face of the shelf, and then the routes and patterns that the glider executed while under the shelf, with timeout behaviors and bailout settings all defined as nodes or branches in the exec system.
IOP is running a basestation server in the cloud, seaglider.pub, for community use. This is available to all operators. There is no charge for the service. We hope that it meets the needs of a broad variety of users, but of course there are numerous viable alternatives for basestation support. Please inquire if you would like a copy of the policy for basestation use to determine if the community basestation will work for you. RUDICS is the only means of operational connection and operators will need to either bring their own RUDICS account or use SIM cards from our RUDICS account provider (CLS). Limited dialup service via PSTN is available for testing purposes.
IOP is currently producing and delivering SGX gliders. As of early 2025, anticipate lead-times of 9-12 months.
Seaglider is able to support a wide range of sensors. For our own research we routinely fly RBR Legato CTD or Sea-Bird unpumped CTD, Wetlabs optical, Aanderaa optode, Nortek AD2CP, Satlantic irradiance, Rockland microstructure, RBR optical sensors, and passive acoustics (our own internally developed PMAR system). Other members of the community have developed integrations for numerous additional sensors.
For new glider deliveries the standard payload is Legato, optical puck, and optode oxygen, but we can integrate any of the commercially available sensors listed above. In addition, the intention of the hardware ports, serdev, logdev and scicon interfaces, and the basestation extension architecture has always been that sensors on Seaglider would be configurable and installable by the end-user.
RBR’s Legato CTD is a good option for the core sensor in either new gliders or as an update to an existing glider for the following reasons:
Legato is fully supported on the glider via scicon and/or a serdev .cnf configuration, and in basestation v3. We would be happy to share our experiences regarding data quality and the comparisons we have done against other sensors.
As part of our stabilization and transition, SGX will be the only new vehicle offered. We are in the process of bringing a new 3000m vehicle online, DGX, and expect its first flight in 2025. We have retained the knowledge base and capability to build DeepGlider and are tracking requests for additional DG vehicles. Over the coming year we will assess demand, look at where DGX might broadly fit, and consider our production bandwidth to determine which directions we pursue for deep vehicles.