Skip to content
DeepWaterExplorationPublic

About

Web-based driver and software interface for DWE.ai cameras

Resources

Stars

7 stars

Watchers

1 watching

Forks

Latest commit

 

History

1,298 Commits

Folders and files

Repository files navigation

dweOS

Backend CI Frontend CI Build Release BlueOS Plugin: Version

Web interface driver for DWE.ai cameras.

Installation

To install for any supported Linux system, run the following command:

curl -s https://raw.githubusercontent.com/DeepwaterExploration/DWE_OS_2/main/install.sh | sudo bash -s

Raspberry Pi Hardware PWM

In order to enable hardware PWM on your Raspberry Pi, you need to edit /boot/firmware/config.txt. See Raspberry Pi documentation for more information.

Add the following lines to the end of the file, and reboot.

[all]
dtoverlay=pwm-2chan

Frame Sync Board and rtpsender

dweOS sets the frequency of the DWE frame sync board over USB serial. If rtpsender.service is enabled (systemctl is-enabled -q rtpsender.service exits with code 0), dweOS acts as if the board does not exist. This is true even when rtpsender is not running. The board resets each time its serial port is opened or closed, so dweOS does not open the port at all.

While rtpsender is enabled:

  • dweOS does not set the sync frequency. rtpsender must configure the board.
  • Changing a follower camera's frame rate in dweOS does not change the sync frequency. If the camera and board frequencies differ, frame sync will not work correctly.
  • The frequency offset preference has no effect.
  • GET /api/pwm/frequency returns the last value dweOS stored, not the board's frequency. POST /api/pwm/frequency and POST /api/pwm/apply_from_fps store a value but do not send it to the board.
  • If rtpsender stops or crashes, dweOS does not take over the board. Disable the unit to give the board back to dweOS.

dweOS checks the unit state about every 5 seconds. If rtpsender is enabled while dweOS has the port open, dweOS closes the port.

Building for development

  1. Clone the repository
git clone https://github.com/DeepwaterExploration/DWE_OS_2.git
cd DWE_OS_2
  1. Build the project
cd frontend
npm install
cd ..
sudo chmod -R 777 ./
./create_release.sh

Building the RPi Image

git clone https://github.com/DeepwaterExploration/pi-gen
cd pi-gen
sudo ./build.sh -c config

The image will be found in the deploy folder. The latest release from github will be used for building the image.

Preview Builds

Every pull request can be installed before it is merged. The Preview Release workflow builds the pull request merged into its base branch and publishes it as the GitHub prerelease preview-pr-<number>. It also comments the install command on the pull request:

curl -s https://raw.githubusercontent.com/DeepwaterExploration/dweOS/main/install.sh | sudo bash -s preview-pr-<number>
  • The version badge shows the build as a preview, for example v0.7.7-pr556.a1b2c3d.
  • Every push to the pull request rebuilds the preview in place.
  • Closing or merging the pull request deletes the prerelease and its tag.
  • Previews are only built for branches in this repository, not forks, and are not published for BlueOS.

To return to the latest stable release, run the install command without a tag.

Creating a Release

Releases are versioned from frontend/package.json and use conventional commits to generate CHANGELOG.md. You need git-cliff, npm, and the GitHub CLI (gh).

  1. Run ./bump_version.sh X.Y.Z from a clean working tree. The script:

    • creates release/vX.Y.Z from the latest origin/main
    • sets the version in frontend/package.json and package-lock.json
    • regenerates CHANGELOG.md with git-cliff, which adds the new release
    • commits chore(release): vX.Y.Z, then pushes the branch and opens a PR after you confirm

    Use --no-push to stop after the local commit, or -y to skip the confirmation.

  2. Wait for Backend CI and Frontend CI to pass on the PR, then merge it.

  3. The Tag Release workflow tags the merge commit as vX.Y.Z and starts Build Release. That workflow creates a draft GitHub release.

  4. Publish the draft release in the GitHub UI.

The changelog starts at v0.7.4. Commits up to and including v0.7.3 predate conventional commits, so v0.7.3 is the baseline. To regenerate the changelog by hand, start from that tag:

git cliff v0.7.3..HEAD -o CHANGELOG.md

A plain git cliff without the range also picks up older commits whose messages happen to look like word: text, such as TODO: fix wifi.

About

Web-based driver and software interface for DWE.ai cameras

Resources

Stars

7 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages