Create Missions Endpoint

[jimjeffers]

This portion of the application is currently stubbed with a mock response:

The mock response we propose looks like this but you could add more data to make this more reusable as you see fit. The main gist is we need a straightforward way to request all applicable missions and or commands executed on a per deployment basis. Here is the complete body of attributes:

export interface Mission {
  eventId: number
  vehicleName: string
  eventName: string
  note: string
  user?: string
  isoTime: string
  unixTime: number
  endUnixTime?: number
  endIsoTime?: string
  status: 'pending' | 'running' | 'completed' | 'cancelled'
  commandType: 'mission' | 'command'
}

And here is how we mocked a simplified response for testing purposes:

const mockResponse = {
  result: [
    {
      deploymentId: 3000403,
      vehicleName: 'pontus',
      name: 'Pontus 24FishCAM',
      path: '2022-06-07',
      startEvent: { unixTime: 1656368134464, state: 1, eventId: 16926582 },
    },
    {
      deploymentId: 3000402,
      vehicleName: 'sim',
      name: 'testing tethysl again',
      path: '2022-06-21',
      startEvent: { unixTime: 1655854978299, state: 1, eventId: 16895057 },
      endEvent: { unixTime: 1655932918662, state: 0, eventId: 16896390 },
    },
    {
      deploymentId: 3000401,
      vehicleName: 'tethys',
      name: 'Tethys 177 Docking',
      path: '2022-06-21',
      startEvent: { unixTime: 1655830172082, state: 1, eventId: 16894484 },
      endEvent: { unixTime: 1655930304618, state: 0, eventId: 16896330 },
    },
   //...
  ],
}

Some questions:

1. Can we get past and future missions? If not can we at least get either past or future missions initially?
2. Does it make sense for the endpoint to return both commands and missions or would you prefer to have two different end points which we would then merge to present this view in the UI?

[carueda]

Thanks @jimjeffers .

While we focus on this, let me also copy some of my initial reactions on slack a couple months ago, that I think are still relevant, at least to some extent:

---

I would replace “Mission” to “CommandStatus” (or something “command” related) because submitting a mission is one of the many possible commands. Scheduling is for commands in general

---

We know there are several aspects TBD, but I’m adding an endpoint with preliminaries for this “command status” information. Initially, it will just provide the complete list of command and run events belonging to the given deploymentId.

---

the new endpoint is GET deployments/commandStatus

As captured in my notes:

• preliminary GET /deployments/commandStatus?deploymentId=<id> endpoint
  • Request:
    • Can indicate a maximum date (this mainly to facilitate playback later on). By default, this is the end of the deployment or no max date if deployment still active.
    • Specific event type, run or command; by default, both are reported.
  • Response includes:
    • DeploymentInfo (as with GET /deployments?deploymentId=<id>)
    • For each command within the deployment timeframe:
      • status, which is just TBD for now
      • relatedEvents, which is empty for now Again, very preliminary, just mainly as a basis to elaborate as we get input from @bkieft and others when the time comes.

---

For the ongoing Brizo deployment, you can try: curlie 'https://okeanids.mbari.org/TethysDash/api/deployments/commandStatus?deploymentId=3000418' $TD_AUTH

[carueda]

for reference, just ran that request with ongoing Pontus deployment:

curlie -s 'https://okeanids.mbari.org/TethysDash/api/deployments/commandStatus?deploymentId=3000426' $TD_AUTH

{
    "result": {
        "deploymentInfo": {
            "deploymentId": 3000426,
            "vehicleName": "pontus",
            "name": "Pontus 28 FishCam",
            "path": "2022-10-11",
            "startEvent": {
                "unixTime": 1666199462487,
                "state": 1,
                "eventId": 17249934
            },
            "launchEvent": {
                "unixTime": 1666199472564,
                "eventId": 17249961,
                "note": "Vehicle in water"
            }
        },
        "eventTypes": "run,command",
        "commandStatuses": [
            {
                "event": {
                    "eventId": 17250901,
                    "vehicleName": "pontus",
                    "unixTime": 1666217837722,
                    "isoTime": "2022-10-19T22:17:17.722Z",
                    "eventType": "command",
                    "user": "Brian Kieft",
                    "data": "schedule resume",
                    "text": "schedule resume"
                },
                "status": "TBD",
                "relatedEvents": [

                ]
            },
            {
                "event": {
                    "eventId": 17249964,
                    "vehicleName": "pontus",
                    "unixTime": 1666201236613,
                    "isoTime": "2022-10-19T17:40:36.613Z",
                    "eventType": "run",
                    "user": "Brian Kieft",
                    "data": "load Science/sci2.tl;set sci2.MissionTimeout 8 h;set sci2.Lat1 36.32285 degree;set sci2.Lon1 -121.943979 degree;set sci2.Lat2 36.402559 degree;set sci2.Lon2 -122.240232 degree;set sci2.YoYoMaxDepth 35 m;set sci2.MaxDepth 50 m;run"
                },
                "status": "TBD",
                "relatedEvents": [

                ]
            },
            {
                "event": {
                    "eventId": 17249962,
                    "vehicleName": "pontus",
                    "unixTime": 1666201160299,
                    "isoTime": "2022-10-19T17:39:20.299Z",
                    "eventType": "command",
                    "user": "Brian Kieft",
                    "note": "Vehicle in water",
                    "data": "restart logs",
                    "text": "restart logs"
                },
                "status": "TBD",
                "relatedEvents": [

                ]
            }
        ]
    }
}

• since no explicit event types were indicated, both run and command are reported
• as a reminder, run type refers to missions per se, and command refers to any other command

[carueda]

Can we get past and future missions?

(I'll assume both past and future here refer to the relevant deployment, typically the ongoing deployment -- unless perhaps during a playback exercise as supported by dash4)

That commandStatus endpoint is in fact intended to provide all commands and missions that have been issued wrt the given deployment. What we still need is the appropriate logic to determine the status for each entry, as well as:

• ordered list of the pending queued commands/missions
• perhaps a separate list for commands/missions that have been scheduled for a particular time (not queued per se)
• others?

[jimjeffers]

@carueda this looks great. If I'm understanding correctly - we can get the past missions (runs) and commands via the commandStatus attribute in the response and that we would eventually be able to query scheduled or queued commands/runs once we get functionality in place.

For the commandStatus results -- the unixTime is the starting point correct? How would I determine the end timestamp of a run? Would it effectively be the startTime of the next event in the list? If it's the most recent item how would I determine the end time of that run? I'm thinking we'd have to check against the actual deployment events to determine if the deployment is still running and then deduce the most recent run is ongoing or in fact terminated?

For ease of use it might be best just to return two timestamps on each event indicating the end time or null if a run is considered ongoing. Thoughts?

[carueda]

the unixTime is the starting point correct?

correct.

How would I determine the end timestamp of a run? Would it effectively be the startTime of the next event in the list?

I don't think so. Still something we'll need to think through, but perhaps such "endTime" would be for commands/missions that have already been fully executed by the vehicle. That said, my general idea in the response above has been that the status attribute is actually accompanied with other associated attrs, in particular including a corresponding timestamp.

Will you need an endTime for missions that have been scheduled but not yet completed? In these cases I think you would instead be using the estimated "mission duration" discussed elsewhere... or are you suggesting that we include some sort of "estimatedEndTime" for the relevant entries here?

[jimjeffers]

@carueda I would prefer that the API could send over the endTime or status + timestamp. The less derived state on the client the better. I was originally thinking the estimated duration, distance, and depth was all handled server side. I can look into replicating the existing solution on the current dash client though. It'd be best if this routine was centralized somewhere on the server as a single source of truth rather than two different clients implementing these predictions in one form or another.

[carueda]

@jimjeffers Agree in general, but some "derived state on the client" will still need to happen such that, while the user is going through the mission preparation wizard sequence (say, when editing a waypoint's latitude value, or dragging the tentative waypoints on the map), it would be more responsive to reflect the estimates on the fly without necessarily relying on the backend for them (at least for duration, distance, and the like). As mentioned those are rather easy to compute UI-side. On the other hand, we can think a bit more carefully about estimates like "depth profile" associated to the planned waypoint trajectory (though a basic point-to-point strategy could also be handled UI-side using the google elevation api...)

[jimjeffers]

@carueda I'll take a stab at it on the client this week.