Skip to content

Changes

1.9.0

2025-10-30

  • Various performance fixes/adjustments. Under testing.

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

  • 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

  • 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

  • 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

  • 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.