skunkforce / OmniView

This Repository contains the OmnAIView Software, which is used in the AW4null Research Projects
https://www.autowerkstatt40.org/
MIT License
3 stars 4 forks source link
gui omniview scope

example workflow

OmniView

OmniView is an experimental GUI for the measurement-devices of the research-collaboration AW4null. It's purpose is the display and the handling of data, generated by Auto-Intern OmniScopes.

Planned functionality

The plan of AW4null is to enhance car-diagnostics with AI-powered diagnostic-services. Diagnostic-services will be reachable through differen REST-APIs and will be specialized on a lot of different purposes. Physical-measurements of automotive-sensors will be taken, displayed in OmniView and send to an API at the users will. OmniView shall receive data from multiple generators, such as OmniScopes and OmniB-, OmniE-Clamp and OmniPressure. The data will come in as a binary stream of 24-bit integers. Since the incoming data represents measurement-samples in the time-domain, the individual channels will be synchronized. This is done in a currently non-public-repo of Auto-Intern, but will be separated into a .dll or .so respectively. The acquired data can be viewed on the OmniView GUI and may then be saved to the hard-drive in .csv or binary format. Anyhow, another possibility is to send the measurement to a REST-API provided by the THGA.

Phase One Development

In its first phase, only one API will be used, documented by this Repository. The API will be able to receive training-data for AI-training purposes.

Phase Two Development

Phase two will implement the interface to the data-producer as a vector of a multitude of objects, that encapsulate each an individual .dll or .so. The first two shared libs that shall be used will be a software-function-generator as well as an abstraction of the OmniScope, following the Unified-abstract-Dataproducer-Interface which is displayed in the UaDI-Demonstrator-Repo.

Phase Three Development

In phase three, OmniView will be extended to use a multitude of service-APIs that can be loaded at runtime. Architecture Diagram

Building OmniView

Building is currently only possible with specially provided access-rights, but will be made available to the wider public as soon as the migration to a closed-source shared-library for device handling has been done as described in Issue #36. In order to ask for access-rights, contact @bjoekeldude.

Anyhow, building IS available in CI. A push into any branch will generate a new binary, that can be downloaded via the Action-Tab.

Building requires cmake --version > 3.20 as well as a c++20-Compiler.

Linux

Prerequisites

In order to start the compilation, following packages need to be ensured:

In order to run OmniView it needs admin-rights right now:

sudo ./OmniView

Build-Instructions for Windows Systems

In order to build on Windows, you have to make sure to install the MS Build Tools for Visual Studio. Due to the layout of the Microsoft Download Page this package can be hard to find. Use this Link to Download https://aka.ms/vs/17/release/vs_BuildTools.exe. If it doesn't work, please make an Issue.

Prerequisites

In order to build the project on Windows, make sure, that you installed git for Windows, and set up an additional .ssh-Configuration for github in your CMD. The Windows Shell doesn't use the WSL SSH Configuration!

Installing

Make sure to select the following options in the Visual Studio Installer:

from the optional components select:

This installs approximately 9 GB of data.

Running the Build

In order to utilize the MSVC-Compiler on the Windows Command-Line, you'll have to set a whole bunch of environment variables. Thus Build-Tools provides an easy way to load all of them at one. Instead of runnign cmd you can just run the Developer Command Promt from your Windows Startmenu. This starts a Session with all env-variables set accordingly.

Run the following commands in the Developer Command Prompt:

git clone --recurse-submodules git@github.com:skunkforce/OmniView.git
cd OmniView
cmake -S . -B ./build -DVCPKG_TARGET_TRIPLET="x64-windows-static"
cmake --build ./build --config Release

The compiled executable will be called .\build\Release\OmniView.exe.

General Code Structure

The code should follow the c++ standard and contains the following structure :

Interfaces :

The following Interfaces are used :

popups.hpp handler.hpp regions.hpp Style.hpp

The functions are declared in the .hpp files and implemented in the .cpp files

Every function that does not depend on another function should be implemented in an individual .cpp file.

The functions declaration, implementation and usage can be found in the documentation. (right now there is no documentation)

Namespaces :

Namespaces should be used to prevent potential conflicts that may arise when functions are declared multiple times in an open-source project. However, they should only be used when necessary because the code should not be overloaded with unnecessary namespaces.

The different PlotRegions have namespaces for readability: SideBarRegion, DevicesRegion, ToolbarRegion, and PlotRegion.

The design and usage of the Regions can be found in the skunkforce/OmniView-Product-Vision Document.

Workflow: Adding new Code

To add new code to the project, follow these steps:

  1. Create an issue describing the bug you want to fix or the feature you want to add.
  2. Create a branch with the same name as the issue.
  3. Pull the code to your local device.
  4. Switch to your branch and start working on the issue.
  5. If the master branch has been updated since you started working, perform a rebase to incorporate the latest changes.
  6. Before committing, run the Clang-Formatter over the files you modified.
  7. For significant changes, create a commit with a clear description of what has been modified.
  8. After testing the code on your local device and ensuring proper formatting, push the changes to your branch.
  9. If the code passes the continuous integration (CI) tests, create a pull request for the master branch.
  10. Your code will undergo a review process.

Using the Clang-Formatter

To use the Clang-Formatter, follow these steps:

  1. Navigate to your /OmniView folder.
  2. Check if you have Clang-Formatter installed on your system.
  3. If Clang-Formatter is installed, use the following command in the /OmniView directory to format the desired file:
clang-format -style=file -i directory/filetochange

Note: You don't need to modify the -style=file option.

  1. To review the changes made by Clang-Formatter, use the command:
git diff
  1. Ensure that the Clang-Formatter configuration file is named: .clang-format.

Versioning

Versioning will only be used for releases in the master branch. Version numbers for software releases follow a standard format, typically consisting of three numbers separated by periods: Major.Minor.Patch. The first number represents the major version, indicating significant changes or updates that might not be backward compatible. The second number denotes the minor version, usually signaling smaller enhancements or new features that are backward compatible. The third number, the patch version, signifies bug fixes or minor updates without introducing new features. We are using this standard for versioning the different releases. Releases can be found on the right side of the repository. To keep a clean versioning, those versions will only be set by the current product manager @AKMaily.

To add a version to the master the following steps need to be followed in an empty directory :


 git clone git@github.com:skunkforce/OmniView.git

 cd OmniView

 git tag vNUMBER

 git push origin vNUMBER

Project Onboarding

In order to learn more about the project as such, you may visit www.autowerkstatt40.org or have a look at our online-learning resources

Support

This work has been supported by the BMWK- project number 68GX21005E

BMWiPicture