Feature: SeaTrac vehicle support

[rgov]

This branch adds support for SeaTrac vehicles.

The core SeaTrac node and protocol implementation are in the seatrac-api project.

[rgov]

Some testing today on IFCB 193 with the SeaTrac ROS node (which lives in the WHOIGit/seatrac-api repo). Power level and outlet status information is flowing into ROS just fine. Outlet control messages also work.

I worked on codifying some of the behaviors requested in Slack and in our June 3rd meeting.

1. There are two behaviors for deciding when to turn on Starlink:

   1. If we are at a high state of charge (e.g., 95%) and the battery is charging, we turn on Starlink immediately.
   2. If we are at a medium state of charge (e.g., 80%), and Starlink was last turned off some time ago (e.g., 24 hours), then turn it on. (Note there's no memory after the node restarts, so when PhytO-ARM is started, it will turn on Starlink immediately the first time.)

2. We send reminders to turn Starlink off at some interval (e.g., 20 minutes) unless we are at a high state of charge and the battery is charging. We use the same Slack web hooks defined in the /alerts parameter.

3. If we notice the Starlink outlet transitioning from on -> off, we assume the operator did this manually. We won't turn it back on until the off time limit is met again (FIXME I don't think this behavior is implemented correctly).

4. We remember that we've sent the message to turn Starlink on, so we don't spam the PMS and race against an operator turning it off.

Philosophy

This Starlink control feature starts to blur the boundary between the application and the operating environment, and data offload brings a whole new dimension of functionality beyond simple data capture or the perception → action control loops we've had before.

Hence, the architecture here tries to draw boundaries that are a little muddled and it could reasonably be argued that they should be different.

PhytO-ARM, which is deployed in a container, does not know about the network configuration of the host. So I have chosen to put the Peplink interaction outside of the PhytO-ARM container, and hence ROS is not aware of what is going on. Therefore it does not know which network uplink is active, etc.

Secondly, the rsync-based data offload occurs outside the container and is orchestrated by systemd, not PhytO-ARM. We support configurations where IFCBacquire and PhytO-ARM are running on separate hosts, so we cannot assume that the PhytO-ARM container has access to all data the system is producing.

The status of offload is also not propagated to ROS; the container cannot see the status of the host's systemd services without building additional services. There is also no simple way to determine when rsync is "finished", because new data is being captured continuously.

[mbrosnahan]

One request based on conversations within the operator group:
Rather than trigger of 80%<SOC<95% start of SL being >24 h since last operation of StarLink, better might be a simple time-of-day trigger. E.g., turn on StarLink for data off load at 8:30 AM ET (12:30 PM UTC) if SOC >80%

The reason here is that watch changes typically occur at 9 am. Bringing SL up in anticipation of this shift change provides an opportunity to view latest IFCB data together and also assess sea state, panel fouling, etc. via cameras. Lastly, there's likely to be at least some sun at this time so relatively low battery depletion rate and ample time to charge back after operator shut down of SL.

Re: rsync reliance
Ideally, rsync actions would prioritize most recent IFCB and rosbag data. I believe default behavior is for files to be pushed in alphabetical/numeric order which translates to oldest-files-first (caused by use of 8601 ISO format dates in IFCB and rosbag filenames).
On slack I suggested scheme where rsync 'jobs' might be initiated via a script that bins files by, e.g., ‘created in last 2 hours’, ‘created 2-6 hours ago’, and ‘created >6 hours ago’. These could be passed to rsync using option --files-from=FILE where FILE is generated by something like find /data/ifcbdata -name D*.* -type f -mmin -120 >> tmp.

[figuernd]

We could put the seatrac include behind a launch param like seatrac: true

[rgov]

Rebased onto #71 in order to resolve OutletStatus.msg conflict.

[Copilot]

Pull Request Overview

Adds support for managing Starlink power via a new ROS node that interfaces with SeaTrac vehicles.

• Introduces seatrac_starlink_manager.py to automatically enable, nag, and schedule Starlink based on battery state of charge.
• Updates package dependencies and launch configurations for SeaTrac integration.
• Adds configuration defaults and a rosinstall entry for seatrac-api.

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/phyto_arm/src/seatrac_starlink_manager.py	New node for SOC-based outlet control, reminders, and daily scheduling
src/phyto_arm/package.xml	Added seatrac as an execution dependency
src/phyto_arm/launch/seatrac.launch	Launch file hooking up the new manager node
deps/deps.rosinstall	Added seatrac-api repository
configs/seatrac.yaml	Default parameters for SeaTrac comms and Starlink thresholds

Comments suppressed due to low confidence (2)

src/phyto_arm/src/seatrac_starlink_manager.py:1

• [nitpick] This module lacks a top‐level docstring explaining its purpose, usage, and ROS topics. Adding one will improve readability and maintainability.

#!/usr/bin/env python3

src/phyto_arm/src/seatrac_starlink_manager.py:53

• There are no unit tests covering the power_level_cb logic or threshold transitions. Consider adding tests to verify automatic enabling and reset behavior.

    def power_level_cb(msg: PowerLevel) -> None:

[rgov]

This is deployed as of 6/17 so once it's running without errors we can merge this and track further changes elsewhere.

[rgov]

Some launch files need to be cleaned up.

• We probably want seatrac.launch to look similar to arm_ifcb.launch? arm_ifcb.launch only loads the AML if it's in a winch configuration, so we have to patch it.
• Determine if seatrac.launch needs to load the parameters or not.
• The network_data_capture node is required even though it sets required=false because we launch with --required.