Skip to content

Changes

2.3.8

2026-07-17

  • Fix #141 DVL Lock false positive when no data has been received. Thanks, Eric and Sebastián, for the heads-up and discussion (slack).
    • btv was inited with [0, 0, 0, 0], so the previous valid condition was trivially true exposing the widget with green color even though no data has been received yet.
    • Now btv is inited with [] and the condition for validity now includes btv.length > 0.
    • Also, a gray color is now assigned when btv.length === 0.

  • As with 'DVL Lock', other status widgets also adjusted to use gray color when no data received yet.

2.3.71

2026-06-15

  • Maintenance release upon the merging of several dependabot PRs.

2.3.7

2026-06-15

  • Map: optionally draw a labeled line between the latest positions of given platform pairs, showing the current distance between them. (Notion)

    Configuration: New optional monitoring section in deployment.yml:

    monitoring:
  distances:
    - from: MINI_USBL
      to: SHIP_GPS
    - from: CLUMP_USBL
      to: SHIP_GPS

    As seen with this deployment while replaying /compas/DATA/RAW/MBARI/MINIROV/20260313d1/lcmlog-20260313d1.05.

2.3.6

2026-06-11

  • Recognize LCM log files with #!LCM_LOG_FILE_VERSION...\n header before sync word. Example: /compas/DATA/RAW/MBARI/MINIROV/20260313d1/lcmlog-20260313d1.05.

    As seen with this deployment:

2.3.5

2026-06-09

  • Map: a platform can now be drawn as a to-scale boat outline instead of the fixed-size icon, by giving its real dimensions (in meters) under the platform's attrs in deployment.yml:

    platforms:
  VESSEL_NAME:
    ...: ...
    attrs:
      length: 83
      width: 13
      fillColor: 'red'
      strokeColor: 'red'

    When both length and width are given, the object is rendered as a boat contour sized in real meters, so it scales with the map zoom and reflects the vessel's footprint. It is drawn as an outline with an almost-transparent fill, oriented by the platform's heading. The existing attrs (strokeColor, fillColor) still apply.

    For UTM deployments the size is exact; for geographic (LATLON) deployments it is an approximation (fine at vessel scale).

2.3.4

2026-06-09

  • Depth: the topoGrid section in deployment.yml now supports multiple grids. The single path entry is replaced by a paths list, for example:

    topoGrid:
  crs: EPSG:32610   # optional; applies to all grids
  paths:
    - 20251008d1_Topo5cm_utm.grd
    - SomeOther.grd

    Each path is relative to the deployment directory, or to the share root if it starts with /. A position is looked up against each grid in the listed order and the first grid that has a value there wins, so adjacent or overlapping grids can tile a larger region.

    NOTE: Where grids overlap, list higher-resolution grids first so they take precedence.

    Breaking change

    Existing deployments using the old single path entry must be updated to use paths.

2.3.3

2026-06-01

  • UX: style/responsiveness improvements in the depth profile chart.

2.3.2

2026-05-28

  • Map: The top-right depth/position readout now also reflects external hovers as it does for the cursor on the map itself. External hovers so far: markers dialog, the depth-profile chart, and row hover in the planning tool dialog.

    Marker dialog:

  • Marker tooltip also includes depth information. (This tooltip remains preliminary, more for dev purposes.)

  • Map: Depth profile implemented and enabled for the measure tool (Notion task) and also for the planning tool.

    Click a segment of the measure path to show the depth profile between its endpoints in a box at the bottom of the map. The selected segment is highlighted, and the profile updates as its endpoints are dragged.

    The profile is sampled along the segment at the grid's resolution (a new backend endpoint), with the number of samples adjusted to the current zoom.

    Moving the mouse along the profile highlights the corresponding position on the map (with its depth), to help relate the chart to the map.

    Measure tool:

    The same interaction is also available in the planning tool: click a segment of the planned path to see its depth profile.

    Planning tool:

    Same also for straight-line segments of missions. The "selected" visual effect on the clicked segment for missions currently relies on the browser's native focus outline on the SVG path, which is browser-dependent. TODO(low-prio): a uniform, sticky highlight (matching the measure/planning tools).

    Mission:

2.3.1

2026-05-27

  • Map: Depth is now included in positions handled with the measure tool (Notion task)

  • Map: Depth is now included in the mouse position control (Notion task)

  • Map related style adjustments:

    • Draw a small dot at the ctrl-clicked position.
    • Set arrow cursor over the map (instead of the hand cursor), which is more intuitive for positioning information

2.3.0

2026-05-26

Dial can now show the depth at a given position on the map. (Notion task.)

This functionality requires a bathymetry/topography grid (an mbgrid/GMT HDF5 .grd file), which is to be indicated via new optional entry in deployment.yml, for example:

topoGrid:
  path: 20251008d1_Topo5cm_utm.grd

The path is relative to the deployment directory, or to the share root if it starts with /.

Note

As of 2.3.4 the single path entry is replaced by a paths list (see the 2.3.4 entry above); the path form is no longer supported.

A new API endpoint allows the UI to retrieve the depth as needed. Initially, this is only exposed in the map context menu for the clicked position:

2.2.9

2026-05-22

  • A context menu (ctrl+click, right-click) on the map is now dispatched to allow copying the clicked position to the clipboard (notion).

    In a future version this menu will be expanded with Lat/Lon and Depth fields as we complete some related tasks.

  • Improved basic animation button.

  • Controlled axes tooltip now only displayed when selecting one of the ROV types.

2.2.8

2026-04-28

  • Simplified Controlled Axes selection in the TXT mission editor (notion).

    Now with:

    • A dropdown menu with ROV type options, plus an 'Advanced' option
    • A checkbox to specify if altitude mode is desired

    • For initial inspection, a tooltip shows the assigned axes, in particular useful to verify the effect when selecting one of the ROV types
    • The 'Advanced' option allows the user to set the axes directly

2.2.7

2026-04-22

  • Monitor (aka "Spy") table now includes, for each channel:

    • A status icon, colored green to indicate recent activity
    • Time of latest message in hh:mm:ss.s format, with tooltip showing the full timestamp

    These columns use the new latest_msg_timestamp_ns field reported by LWS since v0.8.0.

  • Simplified LWS indicator as part of more pending adjustments since Dial started ingesting LWS_LCM_SPY.

  • When Dial detects failure to copy the simplified view URL to the clipboard (which is the case in non-secure contexts (http) except for localhost), it now opens a dialog to let the user manually select/copy the URL:

  • Simplified webapp view:

    • Now includes the deployment indicator: Only shows the deployment file path in tooltip
    • Simplified LWS indicator: Only shows connection status and websocket URL (not the list of other URLs, or ability to indicate a new URL)

  • Dependency updates (pinia, pinia-plugin-persistedstate)

2.2.6

2026-04-21

  • Significantly improves the backend-frontend async notification mechanism.

    • Changes in the following cases are promptly reflected on all Dial UI instances (as relevant depending on selected deployment):
      • Status of RRWS processes
      • Status of LLP processes
      • Mission script has been updated
      • Deployment file has been updated
      • Markers have been updated (see 2.2.5 below)

    • Conflict resolution mechanism for mission script and deployment files is similar to the one for markers: a dialog prompting the user to either accept the changes saved elsewhere or by keeping the current version.

  • Breaking change:

    The route for websocket connection to the Dial backend is now /ws (previously, /ws/bf).

    For example, compaslabdev's compose.yml now has: 

    DIAL_WS_URL=ws://compaslabdev.shore.mbari.org:4010/ws

  • The status of this websocket connection is reflected with a small circle at the top left of the page, with some details shown via tooltip:

  • Internal: code cleanup and refactoring

2.2.5

2026-04-13

  • Implements async notifications from backend to frontend to support the auto sync of markers across multiple frontend instances. (Notion)

    • Handling of the three backend-persisted marker kinds: 'Global', 'Deployment', 'Detections', with conflict resolution flow in case multiple clients have the dialog open with the same maker kind.

      Here's a conflict resolution demo. Both sessions have the Deployment marker kind open in their Markers dialog. When the right-hand session saves, the left-hand session is prompted to choose between Keep mine and Reload. Selecting Keep mine will in turn trigger the same prompt on the right.

    • Unique ID based client identification, in particular to handle self-notification. Client assigns itself a unique ID, which is indicated in header for POST/DELETE requests. Backend broadcasts message including the ID of originating client (originClientId).

    • Frontend auto-reconnection logic (with similar strategy as for the LWS connection).

    Note

    The "Auto sync of multiple Dial instances" feature introduces a new required env var, DIAL_WS_URL, to indicate the Websocket URL that the Dial UI will use to connect to the Dial backend.

    For the compaslabdev instance: DIAL_WS_URL=ws://compaslabdev.shore.mbari.org:4010/ws.

    The whole environment section for compaslabdev is like this:

    services:
  dialserv:
    environment:
      - DIAL_API_ENDPOINT=http://compaslabdev.shore.mbari.org:4010
      - DIAL_WS_URL=ws://compaslabdev.shore.mbari.org:4010/ws
      - DIAL_LWS_URL=ws://compaslabdev.shore.mbari.org:8765

      - PORT=4010
      - DIAL_LOGS_DIR=/compas/Sandbox/Dial/dial_logs
    # ...

  • Fixed logic for display of markers depending on kind selection. They are now consistently displayed depending on the checkboxes for "always display on the map", as well as on the selected kind in the Markers dialog.

  • File browser adjustments:

    • VueFinder component updated to 4.1.2, which seems to fix some issues.
    • By default, hidden files are not shown, and the latest path is remembered.
    • Entered vuefinder#161.
  • Maintenance (dependabot updates).

2.2.4

2026-04-13

  • In the usual deployment dispatch interface, to facilitate sharing the URL for the simplified view of the deployment, this version adds option to copy such URL to the clipboard:

  • Introduced env var DIAL_LWS_URL as part of core Dial configuration.

    Looks like this in the compaslabdev instance: 

    services:
  dialserv:
  # ...
  environment:
    - DIAL_LWS_URL=ws://compaslabdev.shore.mbari.org:8765
    # ...

    This setting is transferred from the backend to the UI for the connection to LWS. Previously, such setting was to be given by the user. The new server given config is the more appropriate mechanism in general, and in particular, to better support the new simplified view/dispatch such that the user does not have to deal with such setting.

    At startup, the UI now uses the configured URL for the connection to LWS. (The user will still be able to change it afterward if desired.)

  • Adjustments for simplified view: User-friendlier button for platform selection

2.2.3

2026-04-10

2.2.2

2026-04-10

  • Selected deployment ID is now reflected in the URL route, with prefix /deployment/ and deployment ID as the suffix, e.g., /deployment/path/to/deployment.yml. This will support sharing the URL of the Dial app for a given deployment, that is, with the user not having to first pre-select a deployment.

2.2.1

2026-04-06

  • Quasar upgrade: nvm install 24 && nvm use 24 && quasar upgrade -i. This should hopefully address several of the Dependabot alerts that have been reported over the last couple of months.

2.2.0

2026-04-01

  • Upgrade Quasar (quasar upgrade -i)

2.1.2

2026-03-13

  • The Python template for translation of SG scripts has been externalized. (Notion task.)

    • Only one template is recognized, and we refer to this as the "global python template".
    • The file name is GLOBAL_PYTHON_TEMPLATE.py, and expected to be under the configured Dial workspace. In the compaslabdev instance, this corresponds to: Sandbox/Dial/GLOBAL_PYTHON_TEMPLATE.py
    • If not yet existent, the file is automatically created as a copy of an internal template.

    • The Mission Scripts dropdown now includes such template for selection:

      which opens the editor:

  • Improvements involving the general handling of editor dialogs, including:

    • Modal behavior when there are unsaved changes
    • Better re-opening control

    Note

    Although multiple editor dialogs can be open simultaneously, Dial does not manage them as a windowing system, for example, there is no bring-to-front or drag-to-reposition support. To focus a covered dialog, please try closing and reopening it, or closing any dialogs on top.

2.1.1

2026-03-10

  • Base image: Added button to force image reloading. (Corresponding .tfw also reloaded.)

    Note

    As part of the testing, it was noted that a very large image like D621nav.png (7,796 x 28,997 pixels) fails to load in Dial, as fully decoding such an image would require an impractical amount of memory. For these cases, an alternative approach, like a tile server, would be recommended.

    (A browser can still open the image directly as it renders a scaled-down version without fully decoding the entire bitmap.)

2.1.0

2026-03-09

  • 'txt' mission scripts: Added parsing for:

    • altitude abs <value>
    • altitude rel <value>
    • depth abs <value>
    • depth rel <value>

    As usual, any instructions in the script (even if not recognized by Dial directly) are passed to MOLARS for validation and execution. But these are now recognized and rendered by Dial with a circle widget on the map (different color for altitude and depth).

  • Default twist limits are now 0.2 m/s and 0.2 rad/s.

2.0.9

2026-03-09

  • Enhancements to handling of real-time detections:

    • For just received markers (within the last ~2 secs):
      • A bit bigger marker to highlight the detection
      • Automatic tooltip display (this can be toggled)
    • Now showing the names of the classes that have been received
      • Shows number of detections per class
      • Checkboxes to select the classes to display on the map
      • Button to zoom map to the corresponding positions

    • Improved detection marker popup

      • Layout adjustments
      • Button to copy the marker to the 'My' set

  • Use new finder component (Vuefinder) also for deployment selection.

2.0.8

2026-03-05

  • Fixed regression as channelForUsbl was not handled properly. Exposed while testing with Sandbox/Dial/demo_SurRidge/deployment.yml. Also, a fix related to channelForFls.

2.0.7

2026-03-05

  • Marker style adjustments:

    • My, Deployment, and Global markers with a more typical marker icon (as initially implemented)
    • Detection markers:
      • "Static" ones with a similar marker icon but smaller (see "DeT" region in the screenshot)
      • Real-time detections markers as small circles (top center region)

2.0.6

2026-03-05

  • Adjustments/fixes in initial real-time detections prototype.

    • Now reflecting effect of the display (eye icon) checkbox
    • Also including the [ ] Cluster checkbox in the dialog
    • The marker display is now updated per the window size parameter even when no new messages are received.

2.0.5

2026-03-04

  • Initial prototype to handle real-time detection markers.

    TODO: documentation. For now, tooltips should provide some good idea ;)

2.0.4

2026-03-04

  • Added Detections marker category -- initial implementation.

    • For now, similar handling as with deployment markers in the sense that the detection markers are associated to the deployment, (file used is detectionMarkers.json).

    • Detections markers cannot be created, modified, or removed individually. They are in general intended to be read-only in Dial. As other categories, they can be loaded in bulk from JSON or CSV.

    General design and structure of this feature is still to be determined

    • Actual location of detections resources
    • Handling of real-time detections

  • Marker dialog layout adjustments

  • Marker adjustments
    • Smaller and simpler marker (circle)

2.0.3

2026-03-03

  • LCM log file playing now with explicit regexp parameter for lcm-logplayer execution to only subscribe to the channels indicated in the deployment, except any MOLARS related ones, .*feedback|.*status.

    For inspection, the tooltip shows the regexp value to be used for execution.

    (Some more details about the motivation for this adjustment are in slack.)

    Note that the websocket subscription to LWS continues to add LWS_LCM_SPY as well as .*feedback|.*status if the MolaRS section is defined in the deployment.

2.0.2

2026-02-26

  • Added integrated Dial release workflow. This was previously done via a local justfile recipe.

2.0.1

2026-02-25

  • Layout adjustments in status component that displays label, icon, and frequency value.

  • Joystick status now with only the icon (and detailed tooltip), and located at top-right corner of Controller block.

2.0.0

2026-02-25

  • Put 'Joystick' status element inside the Controller block.

  • Improved UX for refreshing mission script listing (#100).

    • Now performed automatically when opening the Mission scripts dialog

    • New button in the dialog itself to manually refresh the listing

    Note

    The listing continues to be restricted to recognized files at first level of the missions directory that is sibling of the deployment file.

  • Monitor table now with a filter.

  • Added channelForJoystick and corresponding handling with a status element. Initial testing with channelForJoystick: ROV_JOY.

1.9.98

2026-02-24

  • General revision/simplification to make more use of LWS_LCM_SPY messages:
    • LWS_LCM_SPY now always included in regular websocket subscription.
    • No more reconnection when switching tabs.
    • The update interval setting (by default, 1500 ms) is now for the general subscription, and the field for it (ConnControl) is now included in the LWS dropdown. (Not in the Monitor tab as previously implemented.)
    • spyStatusStore now used in several places instead of msgStatusStore
    • TODO still some cleanup related to msgStatusStore.

1.9.97

2026-02-23

  • New controller status component:

    • Now handling optional channel entries channelForEffort, channelForControlRef, and channelForControlMode in PlatformDef.channelInfo.
    • There's also a new optional section PlatformDef.controller to indicate corresponding effortMultiplier and referenceDecimals settings for the value display (which by default are 1 and 2, respectively).

    Example: 

    platforms:
  MOLA:
    channelInfo:
      channelForEffort: MOLA_CMD_EFFORT
      channelForControlMode: MOLA_CONTROLLER_MODE
      channelForControlRef: MOLA_NAV_TGT_REFERENCE
      ...

    controller:
      effortMultiplier: 100

1.9.96

2026-02-19

  • Markers:

    • Added option to apply marker clustering. TODO editing of associated settings as we advance the functionality to reflect image detections/classifications.
    • Added button to zoom the map to cover all markers of selected kind.

    • Markers now with an optional color attribute (thanks Kevin). Note: for now, only effective via uploading from CSV or JSON. (There's no direct UI to indicate/change the color).

  • Monitor: The LWS_LCM_SPY subscription to LWS was done without indicating the optional update interval parameter. This subscription is now done explicitly.

    Note

    This was further adjusted in 1.9.98.

  • Fixed display of IMU component.

  • Fixed position and orientation displayed value based on appropriate channels.

1.9.94

2026-02-10

  • Frontend now remembers any played LCM files. The backend keeps track of any such files but, currently, only in memory. So, this is basically a preparation while a more complete mechanism is in place.

  • Backend: redirect /dial (no trailing slash) to /dial/. (Note: effective only for direct access, but an Apache redirect was also set on compaslabdev).

  • Frontend: style adjustments toward a bit more compact elements in main toolbar.

  • Frontend linting fully migrated to using oxlint.
  • General backend-frontend revision around ProcStatus.

1.9.93

  • More revision and additional typing in the frontend codebase for the various categories of messages (telemetry, MOLARS, LWS_LCM_SPY).

1.9.92

2026-01-28

  • Layout adjustments in left panel: (https://www.notion.so/compas-lab/2026-01-21-Dial-Check-In-2ef78e0f74b8800a816cc786b76a2315)

    • Initial common section with: heading-arrow, depth/range box, vehicle pose
    • A bit smaller heading-arrow box and depth/range box.
    • Some elements now displayed if corresponding channels are indicated in the deployment:
      • FLS (channelForFls); USBL (channelForUsbl)
    • TODO Other elements still to be properly arranged/displayed
      • for now, just moving "ATTITUDE" box to after the initial section.

  • Fix: Condition image streams dispatch to deployment actually having imageStreams defined.

  • Added a good part of pending typing for WebSocket events and message data in the frontend. This will facilitate making the message handling more robust in general.

1.9.91

2026-01-26

  • UX: Completed and enabled Vuefinder feature to navigate and interact with the file share. There might be some minor adjustments still needed, but it seems fully functional already.
    (The old dispatch will be removed but can still be exercised via shift-clicking the button.)

1.9.9

2026-01-21

  • Internal: rrws module also migrated to uv and ty.

2026-01-08

  • Internal: backend component migrated from Poetry to uv for dependency management. Also migrated from mypy to ty for type checking. This migration was much more successful than an initial attempt in late 2024. Along with the way more pleasant development tooling, worth noting that the docker image is now 626MB (down from 654MB with Poetry), compared to over 1GB in the previous attempt.

1.9.8

2025-11-28

  • Dependabot alerts addressed.

2025-11-26

  • Frontend: Adjusted logic to handle cases of received bad orientations: zero quaternion and non-normalized quaternion. TODO similar handling in rrws_service/dialserv. But there's pending discussion about this in general.

  • Adjustments in "lcm-logplayer" dialog layout.

  • Addressed Dependabot alert. Starlette: 0.48.0 -> 0.49.3. Also, FastAPI: 0.119.1 -> 0.121.3.

  • https://www.notion.so/compas-lab/Dial-Channels-Mapping-Refinement

    • Introduced channelForState to supersede channelForPosAndSpeed, but this one still considered for backwards compatibility.
    • Removed channelForHeading. The heading is now gotten from the orientation in the state.
    • rrws_service/dialserv: updated log_platform_model3d_update to get heading from the state (instead of from the removed channelForHeading) using provided quat2hpr utility and following same logic as in frontend (see rrws_service.py and spatial.ts).
    • Added channelForImu (optional).
    • Removed channelForAngularVelocity. This comes from the state now.

  • Refactoring involving spatial definitions and operations

    • new spatial.ts module
    • Regarding "point" definitions:
      • Point (utl/spatial.ts) - Domain geometry
      • Point2D (dvl/defs.ts) - 2D map/UI coordinates
      • Vector3 (lcm/types.ts) - LCM protocol messages

1.9.7

2025-11-24

  • Some more layout adjustments, including simpler deployment dropdown label in the top toolbar (no need to show the full deployment.yml path, which may be quite long).

1.9.6

2025-11-24

  • Improved responsive design to gracefully handle the selection of many platforms.

    • Horizontal scrolling of the selected platform tabs. Keep mouse pressed on the left or right control (indicated by the red arrows above) to perform the scrolling.
    • The buttons on the map now wrap instead of extending to the right.

1.9.5

2025-11-21

  • New implementation for the "Monitor" tab (aka "Spy"). This is based on the new support for this purpose from LWS (thanks, Kevin!).

    Future improvements include addition of status icons/colors and ability to open a detailed view for a selected channel.

1.9.4

2025-11-21

  • New (optional) baseImages section in deployment.yml: 

    baseImages:
  directory: some/path/to/base/images
    If deployment.yml includes this section, then the base images are taken from the given directory instead of being gathered from the sibling "images" directory. (Notion: https://www.notion.so/compas-lab/Dial-Handling-of-path-for-maps-and-scripts)

  • The Tab keystroke in the various editors now indents the current line or selection instead of moving focus to the next element. Shift+Tab will unindent.

  • More compact and reorganized platform trail dropdown dialog
  • The platform trail trajectory can now be animated, similarly as with other animations, but just a point in this case.

1.9.3

2025-11-11

  • Experimental: Initial use of vuefinder as a more versatile and professional dispatch of the /share navigation.
    • A simple click of the /share button continues to launch the usual dispatch.

    • To facilitate testing, shift-click the button to exercise the new dispatch. Note: Functionality is still incomplete.

1.9.2

2025-11-04

  • Some more performance related adjustments.

    • To facilitate inspection/diagnostics, the trail duration dropdown now shows S / T, that is, the current number of simplified points vs. total trail points.

  • Reduced position history update interval from 1.5s to 10s. Also, added {once: true} to all IndexedDB event listeners to prevent memory leaks.

1.9.1

2025-11-04

  • More performance fixes/adjustments!

    • An issue was exposed with the simplify package, which has been used to simplify the platform trails drawn on the map as a way to avoid slowing down the rendering (and reducing cluttering). It turns out it triggers stack overflows when the number of points to simplify grows to a few thousand (and this because of its underlying recursive implementation). So, now using a different package with an iterative implementation of the same algorithm.
    • The Leaflet smoothFactor parameter to create the polyline for the trail is now set to 0 because simplification is already done in advance, not to mention that the internal, unnecessary further simplification that Leaflet itself would perform also exposed stack overflows as observed during tests.
    • Tests with over 250,000 MOLA positions (from multiple LCM log files played concurrently) and covering more than 3 hours, showed some slowness but overall acceptable UI performance, and no stack overflows! These tests have been with a development version of the webapp, so the production version should perform even better.

  • To facilitate inspection of the data behind the platform trails on the map, the position history table (part of the Dev dropdown) now also includes, per platform, the duration of the captured interval, as well as the oldest and newest timestamps.

1.9.0

2025-11-03

  • Any "My markers" additions and modifications are now immediately saved. The only exception is the bulk deletion in the table, which continues to trigger a confirmation.

    (The other marker categories continue to include the reload and save buttons in the dialog.)

  • Various performance fixes/adjustments, including some that address memory leaks, so we should at least note much better behavior. Under testing.

    To facilitate testing and monitoring in general, a new monitor widget allows to see the current memory usage. The icon color depends on memory use versus limit: green if less than 50%; orange if between 50% and 75%; red otherwise. The details are shown via tooltip. Double-click the icon to get the information copied to the clipboard.

    Initial testing with long-running LCM file replaying and lasting several hours only occasionally showed the icon turning orange, then back to green.

    Note

    On Chromium browsers (Chrome, Brave, Vivaldi, etc.), hovering the browser tab shows memory usage that includes rendering, graphics, and other overhead. So, this may be significantly higher that the use shown by the monitor widget, which basically only considers JS heap allocations.

  • Internal fixes related to the obj.trail field (which maintains the displayed platform trail).

  • Layout adjustments in the trail duration dropdown:

1.8.9

2025-10-21

  • Do not auto center map when opening marker dialog, or when selecting category, as this can be disruptive. The user can still use the button for that purpose.
  • Internal: dependency updates to address dependabot alerts.

1.8.8

2025-09-02

  • New linear_twist_max and angular_twist_max parameters to indicate models.Twist in NavigationParameters: These two values are now also captured in the SG script dialog, and reflected in the SG script's python version that gets eventually submitted to MOLARS. Tested with Sandbox/Dial/test_deployment_molars/deployment.yml (compaslabdev).

  • In the SG script dialog, along with the download button, added copy-to-clipboard and view buttons for the python version.

1.8.74

2025-08-08

  • Added mechanism to offset the bounds of bases image for display purposes, which allows to correct possible discrepancies in the .tfw file.

    • These bound offsets, as well as the opacity, are stored in the local storage.

1.8.72

2025-08-01

  • SG script dialog:
    • Estimated total distance and time also added here. (Note: initial implementation.)

    • "Center map on centroid..." button also added here.

1.8.71

2025-08-01

  • Planning tool:

    • Fixed calculation of estimated time due to rotations.

      • NOTE: Each rotation is normalized to [0-180] for this calculation, that is, it won't necessarily reflect the actual rotation instructed to the platform.
        • TODO refine calculation to take into account actual instructed rotation.
      • If [x] Use constant heading is selected, then the estimated total time is only based on distance.

    • As the plan is updated, its display on the map is now centered on its centroid, not the first point.

1.8.7

2025-07-31

  • Planning tool: Now shows the estimated total distance and time, which are based on given linear and angular speed parameters:

    • New section at the bottom of the planning tool dialog to show this information.
    • Use the indicated dropdown to edit the speed parameters. These are remembered in local storage, and are not platform specific.

  • Fixed regression: Directly editing the WRT input fields (which are used in various dialogs) was not having any effect.

  • Other internal changes/fixes.

1.8.6

2025-07-30

  • RTE-to-SG conversion:

    • Now using heading abs and move bearing instructions.
    • Report when the SGE file cannot be parsed.

  • Improved layout of the mission script selection dropdown.

  • Basic preparations for handling of "lat/lon" coordinate system.

  • In the Mission Script dropdown for selection, include Display checkbox only for *.txt. (*.py and *.rte are not directly displayable.)

  • (frontend, internal): fixed state update upon deleting a script.

1.8.5

2025-07-24

Initial RTE file dispatching support.

  • RTE (*.rte) files are now also included in the mission directory listing.
  • The basic sequence for the user is as follows:
    • User selects an existing file.rte.
    • Dial opens the dialog above to show its contents as well as an automated translation to the SG script format.
      • This allows the subsequent usual handling as for any other SG scripts.
    • User has options to save a proper entry for the resulting file.rte.txt file, and to copy its contents to the clipboard.
  • Current translation is preliminary.
  • A syntax highlighting mode for SG scripts has been added to the editor.

1.8.4

2025-06-26

  • Adjusted WRT labels for clarity
  • New script name from planning tool now given .txt extension automatically.
  • For MOLARS request, avoid 307 redirect by doing GET /mission/ (with trailing slash), which is actually how it is documented.

1.8.3

2025-06-24

  • Enhanced planning tool with generation of a typical trajectory pattern according to some parameters, as well as integration with other parts of the UI, and various new related features.

    • Direct visualization of the trajectory on the map, with option to indicate the frame of reference ("WRT" for such display)
    • Options to:
      • Animate the trajectory to facilitate inspection and verification Mouse wheel can be used to speed up or slow down the animation.
      • Create new SG script (which can then be manipulated in the SG editor)
      • Copy the script to the clipboard (which helps update some existing script)
      • View the script, for quick inspection

  • SG script editor window also now with button to animate the trajectory.

2025-06-18

  • Mission planning
    • For each point, there's now a dropdown to update the position by selecting from the current platforms and the markers.

1.8.2

2025-06-17

  • Alignment with MOLARS in terms of displaying the planned SG mission on the map in the same way as it gets displayed from MOLARS for/during execution.

  • There are still internal adjustments to be made, including handling/inclusion of reference frame in the request, but this is a good step forward.

1.8.1

2025-05-07

  • Aligning with MOLARS
    • Separation of "controller" and "mission" states. The controller can be paused and resumed. A mission can be running or be canceled, but also, indirectly, paused if the controller is paused. The UI now reflects this separation. In particular, when there's no mission running, one can still pause and resume the controller. TODO: internally there may be variables that should be renamed to reflect this separation.
    • TODO: adjust interpretation and display of SG scripts as discussed in today's meeting.

1.8.02

2025-05-01

  • Preliminary, quick-and-dirty integration of BathyViz. An initial issue with the rerun display was fixed. Note: the viz seems as expected, but thousands of rerun-related exceptions can be seen in the dev console upon stopping the connection.

1.8.0

2025-04-30

Additions and fixes to the mission script handling in general.

  • The button to open the mission script list dropdown has been moved to the top of the webapp, next to the MOLARS control button.

  • The mission scripts dropdown provides similar functionality as before but has been revised:

    • Buttons to create and upload
    • Table showing the available scripts, each with options to display it on the map, and to delete it.
    • The WRT feature has been moved to the script dialog itself (see below)

  • To dispatch 'txt' mission scripts there's now an overhauled dialog:

    • Options at the top are for general file handling (reload, save, download, delete)

    Note

    There's also a button to open the planning tool, but this is still preliminary!

    • A dropdown with WRT options, which include:

      • (New) Input fields to directly indicate initial position and heading
      • The platform options as in previous Dial versions
      • (New) All defined markers (which can be reloaded as needed)
      • (New) In all options, button to center the map at the position
      • (New) When WRT option is selected, the map is centered at that position

    • A toolbar with buttons/indicators to:

      • Download the python version of the SG script
      • Display basic syntax validation result
      • Request validation against MOLARS
      • Request execution against MOLARS

    • (New) A form to indicate navigation parameters

      • They are not yet used by Dial for visualization
      • But they are included in validation/execution requests against MOLARS

      Note

      The SG script visualization performed by Dial has been adjusted but still needs to be completed to ensure proper alignment with MOLARS.

1.7.2

2025-04-23

  • Preparations for overhauled handling of mission scripts, intended to:
    • Unify .py and .txt handling
    • Incorporate trajectory generation
    • For now, I'm keeping the previous handling, which can be opened with button under the Dev dropdown
    • Tentatively, the new handling will be along the lines of:
      • A simplified dropdown for selection of an existing script, of to create or upload one (so, similar to the previous one but only for these three actions)
      • The "Display" and "WRT" options, which were preliminary, will be subsumed in the new handling; in particular, the WRT becomes part of the "origin" indication for the trajectory generation
      • A selected script will be dispatched depending on its kind:
        • Full-fledged .py script : dispatched with the codemirror editor
        • "Script Goal" : dispatched in a mainly graphical way (not a text one), with a tool similar to the planning one but with specific options for trajectory generation, etc. Internally, this becomes a python script complying with MOLARS's ScriptGoal mechanism. These SG scripts can be displayed on the map similarly to the txt ones (see below).
        • The existing .txt mission scripts will be handled/converted to the SG handling. Details TBD.

1.7.1

2025-04-11

  • Compatibility with odometry_light_t (see Notion task). For channelForPosAndSpeed, now extracting the position basically as follows: 
    const position = fingerprint === 'f45b9a4367a52cfb'
    ? msgData.event.pose.position
    : msgData.event.pose.pose?.position
    Thanks, Kevin B., for the assistance.

1.7.0

  • Initial implementation of a planning tool, mainly as part of a basis for determining actual desired functionality

    • Initially, inspired by the grid survey waypoint generation in Dash4.
    • New button in the map toolbar opens a dialog for the planning tool.
    • Parameters allow to generate a waypoint pattern:
      • length, width, rotation, number of "passes"
    • Generation needs at least a point (which the user can create by clicking on the map) and can either replace all the points, or append to the current list.

    • Usual editing mechanisms in place (clicking/dragging directly on the map)

    • Future considerations include:

      • Appropriate location to start the UI and association to current mission scripts
      • Generate (and viz) similar format as with the "txt" mission scrips
      • More in general, determine format for ingestion by MOLARS
      • Characterize typical waypoint/pose patterns, in some cases only requiring respective parameters and not necessarily an explicit list of waypoints/poses.

  • Marker timestamp:

    • Displayed in ISO format with microseconds instead of milliseconds e.g. 2023-10-01T12:34:56.789123Z
    • Editing is done via date and time widgets for selection of values. NOTE: once editing, only second precision is retained.
    • No direct manual editing but can be implemented later as needed.

  • TrackedObject now also captures timestamp from event?.header?.timestamp associated to channelForPosAndSpeed.

  • TrackedObject.timestamp now used for MarkerInfo.timestamp when creating marker for selected platform.

1.6.9

2025-04-09

  • Added map measure tool
    • New toolbar button toggles measure mode.
    • In measure mode, click to add points. Each point shows bearing, distance, and accumulated distance. Points are draggable; Shift-click removes a point.
    • Shift-clicking the toggle button clears the series.
    • When off, points/lines remain visible; hover point to view measurements.
    • Map auto-zooms to point bounds on activation (unless already in view).
    • Data is saved to local storage.
    • NOTE: we are in UTM and dealing with small distances, so basic Euclidean distance and bearing calculation should be sufficient for now. TODO adjust these calculations when dealing with Lat/Lon system per se.

1.6.8

2025-04-08

  • Added dialWorkspace to DialConfig to specify a workspace directory for the dial server. This location is relative to $COMPAS_ROOT_DIR, and is Sandbox/Dial by default just to reflect the place we've been using on compaslabdev. dialWorkspace is captured in DialConfig mainly to get exposed to the frontend, which directly uses it for resources like the global markers (and other files in the future). In the frontend, captured in DialUiConfig.dialWorkspace.

  • Implemented initial version of capturing a marker with the current position of a platform

    • this is via popup associated to the platform widget on the map
    • automatically captures current position and depth from associated information, also timestamp, this being the current time in ISO format TODO recheck with the team about desired actual format for the timestamp
    • The above immediately updates "My markers" in local storage
    • There's no direct editing as part of the above capture, but the user can then open the marker dialog for any editing.
  • Capture optional description and depth fields for markers
  • Implemented import of markers from CSV or JSON files
  • Implemented the copying of selected markers to the indicated target set
  • Markers now loaded and displayed at startup (the kinds the user has indicated as visible)
  • Selection of marker kind now also centers the map on its centroid
  • Refactored the handling of Map elements: There's now a base class LMapSupport with common functionality for map components to be added under <QMap>.

1.6.7

  • Now creating/updating global and deployment markers in the backend
  • Marker icon color assigned depending on kind
  • The markers are draggable only for the kind currently open in dialog

1.6.6

  • Marker handling enhancements
    • Maintain marker order and allow moving a marker up or down in the list
    • Selection in the table for actions like delete, download, etc.
    • This in preparation for more actions like exporting, copying, etc.
    • Download options: JSON, CSV

1.6.5

2025-03

  • Added map marker handling
    • A marker has a name and a position
    • Various editing options, both on the map and in the markers dialog table.
    • The markers are immediately saved in the browser as they are created/edited.
    • This provides a basis for backend persistence aspects including:
      • Saving such markers in the backend, initially with association to the deployment ID, and organized in files (similar to the mission scripts)
      • A source for definition of related entities like mission waypoints, and stations or "well-known" locations
    • Note: a leaflet workaround incorporated for production release (quasar build), so that the marker icons are captured.

1.6.3

2025-03

  • Added [x] Labels on map in MolaRS control to toggle display of waypoint labels on the map. They were always displayed, but the option helps declutter the map.
  • Not an off-by-one error in display of pending MolaRS waypoints, but just that the previous point right before next waypoint is still displayed to show connecting line between the two.
  • Fix #66 "Regression: bad refresh of txt mission lines on mouse hover".

1.6.2

2025-03

  • Fix #65 "Incorrect axes in quaternion to yaw conversion". Thanks, Kevin B., for the fix!
  • Added pin and close buttons to some dialogs to facilitate concurrent interaction with the map: 'Base Images', 'Image streams', 'Mission scripts'.
  • MolaRS mission execution: Remember 'Show' and 'Only pending' flags, which are now true by default.

1.6.1

2025-03

  • Rerun upgraded to 0.22 (from 0.16)
  • Enhanced RRWS logging
  • Added RRWS-LWS reconnection logic and timeout handling
  • Direct socket port allocation for RRWS's rerun server. On the UI side, you should see a much faster response when launching the RRWS process.
  • Frontend

1.5.3

2025-02

  • Maintenance frontend release.

    A significant quasar/vite upgrade. Always good to do upgrades, but this one mainly triggered by prevalent alert notifications.

1.5.2

2025-01

  • a poetry adjustment as it started complaining about the poetry export command
  • Resolved #52 "By default, enable the use of indexedDb storage for the position history"
  • cleanup: remove the now unused chroma dependency.

1.5.1

2024-12

  • Resolved #44 "Make platform (2d) widget size configurable". The platform dropdown now has a "Widget size" to indicate the desired size for the corresponding platform widget.
  • Fixed #45 "Dial-MolaRS: current waypoint dashed line disappears"

1.5.0

  • Maintenance release:
    • backend: via dependabot PRs
    • frontend: quasar upgrade -i

2024-11

1.4.9

MolaRS integration:

  • Distance to current waypoint is now displayed.
  • The set of navigation goal waypoints can optionally be displayed on the map.
    • Either the whole set or only the pending waypoints.
    • Tooltip for each position shows the waypoint index in the table for easier identification.

  • Platform widgets displayed reflecting associated pose data: position and orientation.

  • Hovering on every navigation goal waypoint get it displayed on the map.

    • Tooltip in this case shows details of the waypoint position and orientation.

  • The button to center map on the given navigation goal waypoint is now implemented.

  • There's now confirmation dialogs before cancelling the ongoing mission or deleting a navigation waypoint. (These confirmations can be skipped by shift-clicking the respective buttons.)

1.4.6

  • A general revision of the platform and trajectory positioning on the map, hopefully fixing some occasional misbehavior in terms of zoom level, centering on centroid of selected platforms, and fitting to bounds.

  • MolaRS:

    • Preparations to dispatch current navigation goal.

    • Reached, current, and pending waypoints are indicated, with associated actions (which are still being implemented).

    • The top-left button of the dialog can be used to position it on the screen (with a number of possible locations as supported by underlying framework) to facilitate viewing the map while interacting with the dialog.

  • Do not let Escape close the deployment editing dialog if there are changes.

1.4.5

  • MolaRS:

    • Added Pause/Resume for the ongoing goal. Any of these operations also involve getting the latest mission status.

    • Mission status is updated every few seconds.

  • Advancing #32 "Status icons, Hz, etc".

    • Added to ChannelInfo:
      • channelForAngularVelocity
      • channelForFls
      • channelForUsbl
    • Using the first entry of imageStreams.stereoPairs for the L-Cam and R-Cam status icons.

  • Very preliminary exploration with an "epsilon" approach to reduce overhead on the UI for dealing with high-frequency position updates, when such updates do not significantly change the last recorded position. The code has some additional comments.
    This is only enabled with the eps query param, eg: http://compaslabdev.shore.mbari.org/dial/?eps

  • Added the pending history clearing when selecting 'Clear trail' for a platform.

  • A speed parameter can now be indicated when launching a lcm-log-player instance (value passed with the --speed option).

1.4.3

  • MolaRS:

    • Preps to reflect the async status updates.
    • Now reflecting the symbolic name of send-goal response status constant value. For example: Status: 2: ACCEPT_AND_EXECUTE.

  • Platform tooltip now permanent (on the 2D map)

  • As a resolution to #33 "Platform position update becomes wrt to upper-left corner after a while" the 2D graphical view is always selected first when the app is started. More dynamic dispatch can be revisited later.
  • Code cleanup re #38 about platform coloring in dark mode, which is not planned to be pursued further.

2024-10

1.4.1

  • MolaRS:

    • Current goal can now be canceled.
    • Button added to get current poses, but use of this is TBD.
    • Preliminary additions toward more status and control of ongoing goal.

    • LWS channel subscription now also includes MolaRS channels, but these are still to be properly determined for relevant functionality in Dial.

  • Mission script handling:

    • Added 'New mission script' button in the mission scripts table. User is prompted to indicate the path to the new script, then the script is saved in the backend, and opened in the editor.
    • In the mission scripts table, certain features for .py scripts are disabled/not-shown as they are only implemented for .txt scripts.

1.4.0

  • More deployment related additions/adjustments

    • RRWS process also dependent on deployment ID, along with LWS URL. RRWS process subscription also using deployment channels (with option for unrestricted channels).
    • Deployment model expanded to:
    • Mission scripts now maintained in the backend: saving, uploading, deleting.
    • deployment.yml can now be saved from within the UI. There's also a button 'Activate the changes' to facilitate reloading the page.

  • Not reversing platform widget colors for dark mode while this can be revisited - https://github.com/CoMPASLab/dial/issues/38.

1.3.1

  • Back to using poetry for backend.

1.3.0

  • Platform deployment documentation section updated.

  • Resuming enhancing of RRWS handling to:

    • "externalize" the various 3D objects:
      • per platform
      • static objects like test-tank and terrains.
    • initially, via explicit settings in POST request

    • but eventually to be replaced by settings in the deployment file

    • In this version, some parameters for launching the RRWS process are now exposed, but this an interim step toward the more general handling.

1.2.3

  • Various adjustments and fixes toward successful exercising of dockerized Dial on atuncita.

1.2.1

  • Added notification dialogs about mission validation and submission actions based on responses from MolaRS. TODO when mission is valid (http://compaslabdev.shore.mbari.org/molars/docs#/mission/validate_mission_mission_validate_post), and depending on the particular mission as appropriate, an idea discussed with Kevin is to also include some payload in MissionValidation response that can be used to display the planned mission on the map and/or 3D view. Subsequent status updates can also be used -- still TBD.

1.2.0

  • Complete handling of base images per new deployment scheme. Changes both in backend and frontend. Summarizing the various commits:
    • deployment.yml's sibling images/ directory is now assumed to contain the base images.
      • This strategy intended to be similar to the previous handling
      • TODO consider indicating such base images (URLs) explicitly in the deployment file, which would be handy for example to refer to common base images across deployments.
    • List of base image is now shown in deployment dialog, along with the YAML content.
    • Activation of a deployment now also prepares the associated base images for optional selection in the map display as usual.
    • Simplified base images dropdown to take less space, with each entry including tooltip with the URL as well as button to open image in a new window (to facilitate inspection).

1.1.0

  • Advancing MolaRS integration:
    • Adjusted validate/execute POST payload to be text/x-python per updated MolaRS API.
    • TODO keep track of submitted missions, doing association around goal_id

1.0.3

  • Advancing MolaRS integration:

    • new QCodeEditor component for general display/editing of code (yaml, python, txt) (our usual "txt" mission handling now using it)
    • MissionScriptEditDialog now dispatches both "txt" missions and the new "py" scripts.
    • Validate and Execute buttons added to perform corresponding requests against MolaRS API.
    • TODO: team to determine whether support for "txt" scripts is still needed.

1.0.2

  • Initial MolaRS integration:
    • deployment.yml with new (optional) entry MolaRS to indicate the MolaRS API endpoint.
    • New MolaRS component in frontend, enabled when selected deployment includes MolaRS
      • Shows status of the various MolaRS services
      • Shows current mission as reported from GET mission
    • wrt current mission script dispatch (so far for .txt), when the script is .py:
      • TODO incorporate MolaRS dispatch: validation/submission/etc
      • keep the current .txt mission dispatch while new script dispatch is completed.

1.0.1

  • Deployment handling:
    • moved deployment models to separate module.
    • renamed store to just deploymentStore.
    • API deployment route implemented (notes in backend/dialserv/deployment.py).
    • At startup, frontend checks for any active deployment to load it immediately, prompting the user to select one if no deployment is active or if the selected one is not found.
    • When a deployment is selected, the app page is reloaded for activation.
    • Frontend now with new DeploymentControl (a dropdown at the top of page) indicating the active deployment and allowing to select a different one, either from a list of previously selected deployments, or via selection from the shared space.

2024-09

1.0.0

  • Refined configurability and UI launching (from dialserv and standalone)
    • dialserv image to also contain UI content for direct serving
    • UI content in the container can be overridden via volume mapping
    • But the standalone UI container continues to be available and functional (however, it may be removed as the overall setup is stabilized).
    • All testing satisfactory.
    • TODO update docker workflows
    • TODO config file cleanup (there are some now redundant files)

1.0.0.alpha

  • Successful initial testing running all components containerized!
    • All of this focused on deployment at compaslabdev as a comprehensive case, especially given the necessary access to a network share.
    • Other (linux) targets should not involve any issues.
  • Now launching of lcm-log-player instances as part of dialserv itself.
  • Now launching RRWS processes as part of dialserv itself. This is needed for a self-contained docker based deployment.
  • docker/compose.yml taking good shape for deployment
  • updated frontend-release.yml workflow, now generating mbari/dialui as image name.
  • api related refactoring in frontend:
    • added api.ts boot file
      • most associated replacements done
    • new dialUiConfig/dialui.yml as local file with configuration of for thr UI (dial api endpoint, dial server name to compose websocket URLs, etc.) Using a directory (dialUiConfig) to facilitate volume mapping in docker.
    • main page launched depending on availability of required config

  • dockerization with component integration

  • More preparations for deployment handling: syntax validation (though the deployment is initially to be selected as is, not to be edited just yet)

  • layout adjustments in LWS and RRWS dropdowns
  • better positioning of the image stream display (and only needing to indicate width)
  • releasing 0.9.91 with the various recent fixes and adjustments, still with the usual ad hoc scheme of separated components.

  • Adjustments in Dial's process handling (process termination often gets stuck)

    • after calling terminate, call wait with a timeout
    • TODO more robust handling

  • Fixed display of image streams

    • this is now based on explicit listener so no such events are missed
    • so, display now promptly updated as images are received, as well as the time difference between current and previous images (∆ in tooltip).

  • Advancing adjustments toward an integrated Dial system to facilitate deployment. The new dial container will:

    • become the actual dial backend service (superseding the SWS-based service used to serve the UI webapp)
    • include the frontend to be served under /dial/.
    • launch any requested RRWS processes

  • preparing deployment selection (from shared space) and subsequent activation.

  • rrws code reorg/cleanup while incorporating new parameters to allow Dial to indicate the desired channels for the LWS subscription (basically, the same as the Dial UI uses)

  • Some more "inlined" documentation about the RRWS control (as an interim strategy while things get stabilized and more properly documented).

  • Starting preparations (ad hoc for now) for integrating notifications from "ControlServer"

    The channel of interest would be go_to_pose.feedback, and the attribute in the JSON would be pose_target. That is a geolcm.pose_t which includes the position in the state estimator's frame of reference.

    • RRWS: also handle "SIM_MOLA*" channels to expose the simulated MOLA data. (As other logic in RRWS, this is all preliminary/ad hoc.)

2024-08

TODO capture proper configuration when launching dial to determine various things like backend endpoint. This is related to direct integration of such backend. (Dial frontend is still "separated.")

0.9.7

  • primary app color now as in the blueish part in the compas-lab logo.

0.9.6

  • improved handling of RRWS process and connection dispatch
    • Dial can launch a RRWS process in the backend for every LWS connection selected in the UI
    • The Rerun Viewer in Dial can optionally connect to the RRWS process corresponding to the selected LWS connection
    • There are controls to start/stop the RRWS process
  • reverted to using rerun 0.16.1 (both UI and in RRWS service) due to already noted issues since 0.17. Also tried the latest 0.18 on both sides, but still issues.
  • now using reported RRWS websocket port for Rerun Viewer connection
    • TODO improve coordination (upon start/stop/restart/LWS selection change)
  • Determining concrete handling of the RRWS process in the backend
    • added a RrwsControl component, included in top section along with other "backend" related components.
    • TODO Still under the Dev dropdown, but pending remove the preliminary:
      • RrwsConnectionPanel and RrwsProcesControDialog
  • Advancing orchestration of dial-backend and rrws services
  • Splitter position in main page is now remembered in local storage.

0.9.5

  • mbari/dial image now with ability to serve the webapp under both /dial/ and /. Some time ago, the webapp was made visible under /dial/ when we started integrating other services at compaslabdev. We set up an apache proxy to handle that /dial/ prefix in the URL, while having the webapp logic assume /dial/ for various resources. A direct, no-proxy use of the webapp (that is, accessible under /), was not possible until now.

    Note

    This solution might still be a temporary as we will eventually be integrating the dial backend component into the dial image itself, and such component can take care of the prefix handling.

0.9.4

  • Now integrating rrws as a subdir under the dial repo itself.

  • Now including subview selection in the main toolbar

  • The subview selection is now remembered in local storage
  • Moved toolbar to the top of the main nav view (previously, under the left hand side panel)
  • Retaining UI state in the 3D subview upon switching back and forth among the subviews.

0.9.3

  • Added SensorsStatusComponent
    • TODO: Complete impl
  • Added VehiclePoseComponent
    • TODO: Complete impl
  • Added DepthRangeComponent (based on DopplerVelocity)
    • TODO: Complete impl with appropriate values/units
  • Added AttitudeComponent (based on DeadReckoning)
  • Tab for the 'Spy' graphical (sub)view displayed with label "Monitor".

0.9.2

  • fixed regression of map base images failing to get displayed: The MapDisplay component (in RightPanel) is always inserted, but only displayed when 2D is selected. And this btw also retains the state there when switching back from other subview.
  • Refactored main page (aka "nav" view) to use separate LeftPanel and RightPanel components.
  • Moved the Heading widget to the top of the left-hand side of the main page (per current design draft; but all these impl adjustments are preliminary)
  • Along with 2D and 3D, also a 'Spy' option, with the Spy component moved there. (SpyPage and associated route removed; similarly, ReRun page and route removed.)

  • moved RrwsConnectionPanel (dropdown) to the new "nav" view when 3D is selected.

  • component subdirectories renamed to 'frontend' and 'backend'.

  • now with 2D/3D selection in the "nav" view
    • Note: as part of the preliminary general setup, there's not yet any explicit coordination or synchronization of what's visualized in these to alternative sub-views.
  • using a splitter in the "nav" view (mainly to facilitate determining a good layout,)
  • Changed layout of the "Nav" page in preparation for having the "Mola View". Instead of the previous vertical arrangement, it is now a row with:
    • Left: the platform tabs along with the indicators (doppler vel, dead reckoning, heading)
    • Right: the map with the platform positions and the mission trajectory.
  • Some style adjustments (but no layout changes)

2024-07

0.9.1

  • Reflect name change of Rerun Websocket Server to RRWS (from RWS).

2024-06

0.9.0

  • Adjustments related to the embedded rerun viewer, including some blueprint preps.

  • Layout adjustment: RWS dropdown is now always displayed (but this may change again as we update the Nav view, which is intended to alternatively allow for the usual 2D display as well as the (rerun based) 3D display.

  • The "dialserv" repo has been ("loosely") integrated here under dialserver/, while the UI code has been moved to dialui/. The rest of this README is as it was before the integration for the UI. TODO: update READMEs/ChangeLogs/docs/workflows/dockerization,...

0.8.5

  • Capture dialServerInfo in a single place

0.8.4

  • New "RWS" connection panel. Similar to the LWS one (allowing addition/selection of RWS server), but not checking for connection status as the URL is just passed to the Rerun Viewer.
  • Set label in LWS websocket connection panel to just "LWS" (instead of whole address). This to save some estate and in preparation for addition of new "RWS" connection.

0.8.3

  • Auto-refresh lcm log file playing status (every 5secs)

0.8.2

2024-05

0.8.1

  • Overall handling of:

    • browsing the compas share
    • highlighting LCM log files
    • playing them, showing status, and ability to stop and remove the process entries.

    All supported by the dialserv API.

  • added LcmLogPlayDialog

  • remember browsed compas share directory. This is in memory for when reopening dialog (not saved in local storage). Dialog now has a button to reload the root directory.
  • direct main button to open CompasShareDialog
  • initial compas share browsing and lcm log file playing supported by dialserv API. Locally: http://localhost:9000/dial/#/file-explorer-test

0.8.0

  • set publicPath: '/dial' to facilitate deployment.
  • Use node 22

2024-04

0.7.7

  • For "plots" view (ProtoPlots), adjustment to reconnect with no filtering so all messages are received. (Similar as how it was done for the "spy" view, SpyMain).

0.7.6

  • MissionScriptEditDialog adjustments:
    • made "seamless" so user can also interact with the map while having the dialog open
    • moved to the "left" position to reduce overlap with the map
    • Control+S to save the script
    • improved overall handling of events, in particular, to avoid the closing of the syntax error dialog to also close all ancestor dialogs.
    • now dispatched via $q.dialog

0.7.5

  • initial highlight of mission commands on the map while editing the script
  • some preps for reflecting ongoing editing changes in mission editor into the map
  • added set position <x> <y> command.
    • visual effect: a small circle, but no line connection with previous position
  • added confirmation dialog for mission script removal
  • code cleanup: removed the initial image stream conversion preparations done before we settled on the common JPEG payload format from LWS.

2024-03

0.7.4

  • Simplified dial entry in docker-compose.yml by removing the need to explicitly indicate the command (which is now indicated in the source Dockerfile). In case of needing to adjust the server log level (info by default), one can set SERVER_LOG_LEVEL in the compose file.

    On compaslabdev, the compose file looks like this:

    services:
  dial:
    container_name: dial
    image: mbari/dial:0.7.4
    ports: ['4000:80']

    volumes: [
      '$PWD/TEST_DEPLOYMENT:/public/deployment:ro',
      #'$PWD/deployment-lass-202310:/public/deployment:ro',
    ]

    restart: unless-stopped

  dial-proxy:
    container_name: LWS
    image: mbari/lcm-websocket-server:latest-dial
    network_mode: host
    environment:
      - HOST=0.0.0.0
      - PORT=8765
      - CHANNEL=.*
      - JPEG_QUALITY=75
      - JPEG_SCALE=1.0
    restart: unless-stopped

2024-02

0.7.3

  • Now ingesting binary payloads as supported by new lcm-websocket-server version, Each binary payload consists of LCM header, channel name, and the JPEG bytes.

0.7.2

  • adjustments in image stream options

  • show delta time in image display

0.7.0

  • Per 2024-02-13 meeting, in the main page (DvlMain):
    • Do not show the following: "Horizontal Velocity (body)", VerticalVelocity
    • abbreviate to "RPY" (for Roll, Pitch, Yaw)
    • save some space by removing the "m" from the units
  • preparations for image stream specification, including renaming platform.yml to deployment.yml to be more general.
    • rename platformUtil to deploymentUtil
    • more handling around "DeploymentDef"
    • websocket channel registration now including image streams
    • preliminary image stream display in main page, using new ImageStreamsDisplay component
    • added options for user to indicate the image streams to be displayed
    • re-open websocket connection when the selected image streams change
    • added options for user to indicate fixed size for the image display
    • added option for the QImg fit attribute
  • alternative, likely a bit faster hexStringToImageUrl implementation

0.6.3

2024-01

0.6.2

  • preparations to display images

    • testing with PROSILICA_L and PROSILICA_R channels
    • added ImageDisplay and StereoImageDisplay components, for now rather ad hoc, mainly to inspect timestamps and rendering performance
    • added timestamps/deltas to the image display to have better idea of time lag, etc.

0.6.1

  • dependabot updates

0.6.0

  • adjs to mission script editor.
  • upgrade quasar; upgrade axios.

2023-11

0.5.7

  • The following map display options and commands are now platform specific: trail-duration, clear-trail, line-simplification-tolerance.

  • Revision of the "wrt" options for positioning the selected mission. Per platform there are now two options: Latest position only, and latest position and heading. There's also an absolute positioning to position (0, 0) and heading 0.

  • Some documentation updates; and link to doc site from the app.

  • attrs.connectLines: false can now be indicated to avoid connecting the positions for a platform. The default is to connect the positions.

  • better control in mission script edit dialog (no esc-close if modified; using q-dialog..)

  • fixed widget creation: the heading parameter is in radian units!

0.5.0

  • added ability to download mission script
  • added ability to edit mission script
  • added "wrt" option for absolute (0, 0); 0) position and heading
  • show roll/pitch/yaw in degrees; add checkbox to toggle between degrees and radians.
  • fixed "wrt" repositioning, so it also considers current platform heading.

0.4.8

  • mission display
    • [x] initial interpretation of mission commands for display
    • [x] mission can be displayed wrt latest position of selected platform
    • [x] define and use widget per command
    • [x] apply correct heading
    • [x] apply correct bearing
    • [x] more details in command widget tooltip
    • [x] highlight corresponding widget when hovering a command
    • [ ] ability to directly move the mission trajectory
  • fixed L.control.mousePosition display regarding x and y (they are "lat" and "lng" respectively)
  • use chroma to reverse icon/trail colors when in dark mode
  • smaller platform svg icon (half of the previous size).

0.4.5

  • fixed mission script removal

0.4.4

  • mission script handling
    • [x] parse mission script (j test)
    • [x] load local file in webapp
    • [x] display list of loaded scripts (loaded in local storage, as part of the optsStore)
  • moved the "View" selection to the Dev dropdown

0.4.3

  • initial implementation of position history
  • opt-in for the moment to facilitate testing

  • using IndexedDB directly

  • implemented workaround for Firefox, so it opens the Base Images dropdown.

  • quasar upgrade -i

0.4.2

  • For "spy" view, quick ad hoc adjustment to reconnect with no filtering

0.4.1

  • "Dev" dropdown adjustments:
  • moved the "clear plots" button to the ProtoPlots page itself
  • adjusted the "clear message counters" dispatch

  • TODO msgStatusUpdater could subsume channelStatusUpdater

  • fixed reaction to object display selection

  • removed unneeded L.Control.Layers
  • some additional throttling
  • added MsgSummary in ConnPanel

  • ConnPanel now sets wsUrl with a suffix to indicate desired channels, a feature recently added by lcm-websocket-server.

    • Such channels are the ones of the selected platforms
    • When no platforms are selected, we still create the connection but with a dummy channel name for the subscription (that is, not expecting to then get any notifications). This allows Dial to still provide visual feedback that the websocket connection is in place.
    • Added a convenient platforDefsStore just to expose the defs in platforms.yml.

  • moved the trail to the "Trail duration" menu.

  • trigger update upon change in simplifyTolerance or trailSeconds.

0.4.0

  • renamed project to "dial". Note: did all main symbol rename changes, except (for now at least) for the optsStore to keep the associated local storage settings for users.

0.3.1

  • Handling png/gif as well.

0.3.0

  • Resolve #2 "Add deployment handling"
  • /public/deployment as container location to be mapped to a local directory corresponding to a particular deployment
  • Under the particular host directory, the following content is expected:
    • platforms.yml : file containing the platform definitions
    • images/ : directory containing any desired base images selectable for the map. With SWS json listing feature, app dynamically gets the list of images from the server.
    • removed addition of images via the GUI; also now no ability to remove from the list.
  • improved base layer selection under the "base images" dropdown itself.
  • TODO remove the need for the 'updateBaseImages' event: QMap can get the images directly to initialize the relevant leaflet elements.

0.2.2

  • added SpongeRidge_LASS_Topo_5cm_UTM.tfw to the ("embedded") base images

  • converted from .tif to .jpg as in previous cases: convert SpongeRidge_LASS_Topo_5cm_UTM.tfw.tif SpongeRidge_LASS_Topo_5cm_UTM.tfw.jpg

  • edit comments in docker-compose.yml, including how to mount a local platforms.yml file

2023-09

  • refact: moved reactor and ws to async
  • fixed typo in parameter

2023-07

  • added (+) and (x) buttons to add/remove selectable platforms
  • start using yaml to configure the platforms to be tracked

2023-05

  • optsStore: remove previously pre-defined base image at app startup
  • regenerated PortugueseLedgeTopo1mSlopeshade_ROI.tif to get the .tfw:
gdal_translate \
      -projwin 593944.0037 4062311.3692 595154.8654 4061075.4305 \
      -of GTiff \
      -co "TFW=YES" \
      geotiffs/PortugueseLedgeTopo1mSlopeshade.tif \
      public/img/PortugueseLedgeTopo1mSlopeshade_ROI.tif

convert public/img/PortugueseLedgeTopo1mSlopeshade_ROI.tif \
        public/img/PortugueseLedgeTopo1mSlopeshade_ROI.jpg
  • revise center-at-centroid request handling
  • added flyToBounds action for base image
  • preps for using .tfw info, along with image dimensions, to compute the positioning of the image on the map
  • cropped SpongeRidge_MAUV_Topo1m_UTM_Slope.tif to a ROI approximately as indicated on slack. I used QGis but then adjusted the command to also generate the world file (.tfw):
gdal_translate -projwin 583437.4743 4068101.3492 585578.9558 4066627.5396 \
               -of GTiff \
               -co "TFW=YES" \
               SpongeRidge_MAUV_Topo1m_UTM_Slope.tif \
               SpongeRidge_MAUV_Topo1m_UTM_Slope_ROI.tif

Just committing the generated JPEG, for which I used imagemagick to get a smaller size file (than if using gdal_translate):

convert SpongeRidge_MAUV_Topo1m_UTM_Slope_ROI.tif SpongeRidge_MAUV_Topo1m_UTM_Slope_ROI.jpg

Note: with an ad hoc default positioning.

  • added MousePosition to the map
  • moved section for editing/adding base images to a proper button on the map
  • some type related adjustments
  • add a small wait when switching ws servers, otherwise the new selected one may not get connected right away.
  • adjusted command for compasswebui in docker-compose.yml upon noticing SWS launch issue on the new Ubuntu VM: include --host 0.0.0.0. Interestingly, I haven't seen this issue in other VMs where I also use SWS for some services. (https://github.com/static-web-server/static-web-server/issues/134)

2023-04

  • incorporated initial base image handling

  • Using L.ImageOverlay, that is, regular images (jpeg, png, etc). whose explicit positioning on the map must be indicated by the user. GUI allows editing the relevant parameters.

    Did preliminary experimentation with some libraries that handle GeoTiff directly (leaflet-geotiff, ih-leaflet-canvaslayer-field); however, not as straightforward, some bad performance even with small image, etc. More work would be needed.

  • A "builtin" base image included with /img/ as prefix for the URL (that is, located under public/img/ in this repo). But the user can add new base images by indicating the URL and positioning parameters.

    Note: with the docker container (which includes a web server) one can use volume mapping to expose additional local files, for example:

    • assume local directory $(pwd)/images contains foo.png
    • map $(pwd)/images to /public/images when launching the container
    • in the GUI, add that image by indicating the URL /images/foo.png
    • then select that base image in the leaflet control to display it

  • fixed typo in various places: 'compaswebui', not 'compasswebui'

  • some code refact; msgStatusUpdater as a primary triggering of updates

  • style adjustments incl more compact info tables
  • fix: tabs were not initially displayed (only upon receiving some message)
  • docker related adjustments

  • general performance boost by throttling the gui updates This includes an objStatusUpdater, which internally keeps the state of all objects while throttled-updating objsStore.

  • add checkboxes to show objects on the map

  • include simplify.js (for the object trails) toward improving display performance
  • richer TrackedObject with ChannelInfo and addition state, all updated by objsStore.
  • TODO throttled gui updates
  • view selection: 'Nav', 'Plots', 'Spy'. ('Nav' for the tabs with 'nav1' and 'nav2') TODO DvlMain for specific given object
  • separate map display and better object display handling
  • phase 3 with some refactoring/reorg; added tabs; initial "tracking" of multiple objects; initial ("manual") types.ts; still delineating general status handling
  • TODO arrow size for the horizontal and vertical velocity widgets
  • added a fit bounds option
  • added map reticule, and allow adjusting the trailing time window
  • added map display for the dvl interface (taking code pieces from my mxm project)
  • using L.CRS.Simple for direct use of the metric coordinates
  • using empty base layer
  • includes buttons to center and reset
  • initial dvl interface (following https://dvl.demo.waterlinked.com)
  • advancing core mechanisms and some preps for dvl and lcm-spy like interfaces
  • ability to specify list of "known" websocket servers and select from there for the connection.
  • preliminary plot selection and configuration
  • channel definitions are captured in opts; initialized in a hard-coded way as with the initial plot selection

  • TODOs include:

  • appropriate viz and display of info for the various streams

  • mapping from channel definitions to applicable viz (plot) types
  • flexible configurability and/or enhancement of channel definition editing

  • more plot types

  • dockerize the app, so it can be launched like this

docker run -it --rm --init --name compaswebui -p 4000:80 "mbari/compaswebui:${VERSION}"

Then open http://localhost:4000/. See justfile.

  • throttling also the update of the scalar plots. This really seems to be helping with responsiveness even when playing back at 4x speed. NOTE: performance is kept in mind but not yet the focus of this development.
  • various additions and adjustments. Plots still preliminary while determining specifics per channel, msg type, desired combinations, etc.

2023-03-30

  • Initial version with core functionality and basic scalar and 3d plots.

2023-03-27

  • Basic skeleton with websocket connection, direct msg display, nothing graphical.