Vehicle status¶

TethysDash aims to provide robust and comprehensive vehicle status reporting, so that status clients (like auvstatus) need not reconstruct the vehicle state from raw events on their own. This is not necessarily through a single endpoint: the status endpoint is a central piece, alongside others like /api/wp, /api/vpos, /api/data, and the asynchronous notifications.

The status endpoint reports the last deployment; the current mission, with its effective arguments, waypoints and timeout; the latest communications and next expected; and the latest GPS fixes and waypoint events.

See the API docs for the request parameters and response schema.

What clients can rely on¶

While the derivations are done in TethysDash, clients keep the flexibility to do their own interpretation:

• Items point to their source events. Each item derived from an event carries that event's ID and time, so a client can fetch the event and apply its own rules.

• Derived values come with their inputs. For example, each mission argument includes its default and the overriding event, if any; comms.nextExpected comes with needCommsMinutes and the latest reception it is computed from.

• No presentation. Staleness, thresholds, and colors are left to the client.

• Lower-level endpoints remain. /api/events and others are unaffected, so a client can adopt the status one section at a time and keep its own logic elsewhere.

• Policy choices become parameters when needed. Currently to (snapshot time) and fixSeparation. Others can be added as clients need them.

• Additive changes after the preview. Once the preview ends, new fields may be added, but existing ones will not be renamed or have their meaning changed.

Next expected comms¶

comms.nextExpected is only reported for missions with a top-level NeedCommsTime. For missions whose comms timing depends on phases or other conditions (for example, PAM's NeedCommsTimeInTransit and SurfacingIntervalDuringListening), it is omitted rather than guessed. A general solution requires the vehicle to report its own comms deadline (see #130).

Additions¶

If a client needs something the status reporting does not provide, or derives it differently, please open an issue. Anything of general use is better added to TethysDash than kept as client-side logic. Some improvements may also need adjustments in how the vehicle itself reports certain aspects, which are coordinated with the LRAUV team.