Skip to content
Snippets Groups Projects
Forked from Eclipse Projects / oniro4openharmony / meta-openharmony
Source project has a limited visibility.
user avatar
authored

GT-Gen-Simulator

GT-Gen (stands for Ground Truth Generator) is a simulator designed to accelerate the development and testing of Advanced Driver-Assistance System (ADAS) and Autonomous Driving (AD) functions. It allows engineers to test and validate autonomous software functions in a virtual environment, eliminating real-world risks. This simulated environment called Ground-Truth is created in the form of an ASAM Open Simulation Interface (OSI) generated from a specific scenario (ASAM OpenSCENARIO) and a specific map (ASAM OpenDRIVE).

GT-Gen can be employed in two ways: as a standalone application designed to function alongside a Command-Line Interface tool (CLI), and, as a shared library that can be integrated into custom simulation applications.

Getting Started

Prerequisites

  1. Bazel
  2. C++ build environment
  3. Third-party dependencies can be found in the subfolder third_party
  4. For additional information: see dockerfile

Build and Run Unit-tests

# Build and test in the debug mode
bazel build --config=gt_gen //Cli/... //Simulator/...
bazel test --config=gt_gen //Cli/... //Simulator/...

# Build and test in the release mode
bazel build --config=gt_gen_release  //Cli/... //Simulator/...
bazel test  --config=gt_gen_release  //Cli/... //Simulator/...

# Run sanitizer checks
bazel build --config=gt_gen_san  //Cli/... //Simulator/...
bazel test  --config=gt_gen_san  //Cli/... //Simulator/...

Developer Notes

Pre-Merge Checks

The style_and_lint_checks step in the CI job ensures code quality and consistency. It perform a series of checks on each merge request. Checks Included:

  1. clang-format checks
  2. bazel buildifier checks
  3. shell script formatting

Use script locally:

  1. Prerequisites: ensure have the necessary tools installed: see dockerfile
  2. Run the script locally:
    ./utils/ci/scripts/check_and_fix/check_and_fix.sh

Code-coverage

The code-coverage report can be accessed at the following link: code-coverage report. This report is automatically updated after each commit is merged into the main branch and is also included in the artifacts for each tagged release.

To generate the code-coverage report locally, you can find the report under bazel-coverage/index.html by following the instructions below:

Use script locally:

  • For native Linux systems:
./utils/ci/scripts/build_and_test/code_coverage.sh

Tests Report

Access the detailed Tests report at the following link: tests report. This report summarises the outcomes of unit tests, including counts of passed, failed, disabled, and errored tests, alongside total execution time. This report is automatically updated after each commit is merged into the main branch and is also included in the artifacts for each tagged release.

Use script locally:

To generate the test locally, you can find the report under test_results.html by following the instructions below:

  • For native Linux systems:
./utils/ci/scripts/build_and_test/generate_test_report.sh

Versioning

TBD

Commit Message

Commit messages should follow the guidelines from Conventional Commits.

Type: The commit messages are prefixed with a type descriptor that communicates the type of change. The following is a summary of the possible types for a commit.

  1. feat: introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
  2. fix: patches a bug in the codebase (this correlates with PATCH in Semantic Versioning).
  3. Appending ! after the type/scope specifies that it introduces a breaking API change (correlating with MAJOR in Semantic Versioning).
  4. chore: indicates no production code changes. These are typically maintenance tasks. Subtypes can be added: chore(build):, chore(ci):, chore(style):
  5. Other types can also be used: test:, docs:, perf:, refactor:

Footer (optional) Any additional information about the commit, such as referencing issue tracker IDs.