mantle-api issueshttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues2024-03-20T07:07:33Zhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/73Proposal to add UML diagrams to docs for further clarification of the interac...2024-03-20T07:07:33ZMartin StumpProposal to add UML diagrams to docs for further clarification of the interactions between classesThe documentation currently only shows, how singular classes and functions can be used.
However, it does not clarify how multiple classes and functions are meant to interact.
I propose to add UML diagrams to the documentation, wherever ...The documentation currently only shows, how singular classes and functions can be used.
However, it does not clarify how multiple classes and functions are meant to interact.
I propose to add UML diagrams to the documentation, wherever it makes sense to clarify such interaction.
To that end, we should settle on a definition of, and consise wording for the different subdomains covered by the API:
* Environment
* Scenario
* Simulator (Execution)
* ...
The diagrams could be added to a page that Doxygen calls a [Topic](https://www.doxygen.nl/manual/grouping.html).
See [add-plantuml-diagrams-to-docs](https://gitlab.eclipse.org/mstump/mantle-api/-/tree/add-plantuml-diagrams-to-docs) for a complete example using Doxygen with PlantUML and Doxygen Awesome:
![image](/uploads/c35954dbb6999edc1a9a1bb2b30a8422/image.png)
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)Martin StumpMartin Stumphttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/72Docs are incomplete, since the `mantle_api` ns is undocumented2024-03-20T07:07:33ZMartin StumpDocs are incomplete, since the `mantle_api` ns is undocumentedCurrently, Doxygen does not generate pages for most non-class constructs (e.g. enums and free funcs), since the `mantle_api` ns is undocumented.
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Te...Currently, Doxygen does not generate pages for most non-class constructs (e.g. enums and free funcs), since the `mantle_api` ns is undocumented.
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)Martin StumpMartin Stumphttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/31IEnvironment is not stepable2024-03-19T09:36:03ZMartin StumpIEnvironment is not stepableDear all,
`IEnvironment` does currently not mandate a `Step()` function cf. [`environmentInterface.h`](https://gitlab.eclipse.org/eclipse/simopenpass/opSimulation/-/blob/openscenarioengine-prototyping/sim/include/environmentInterface.h#...Dear all,
`IEnvironment` does currently not mandate a `Step()` function cf. [`environmentInterface.h`](https://gitlab.eclipse.org/eclipse/simopenpass/opSimulation/-/blob/openscenarioengine-prototyping/sim/include/environmentInterface.h#L24).
Is there a reason it should not be stepable?
Consider the following usage example:
```c++
std::shared_ptr<IEnvironment> m_environment;
std::shared_ptr<IScenarioEngine> m_scenario_engine;
SimulatorImpl::SimulatorImpl()
{
m_environment = std::make_shared<EnvironmentImpl>();
m_scenario_engine = std::make_shared<ScenarioEngineImpl>(m_environment);
...
}
void SimulatorImpl::Step()
{
m_environment->Step();
m_scenario_engine->Step();
...
}
```
If we agreed on making `IEnvironment` stepable, we could derive from `IStepable` e.g.:
```c++
struct IStepable
{
virtual ~IStepable() = default;
virtual bool PreStep() = 0;
virtual bool Step() = 0;
virtual bool PostStep() = 0;
};
```
The need for `PreStep()` and `PostStep()` would need to be discussed as well.
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/74Gather Requirements for Interface between Environment and Simulator2024-03-19T09:36:03ZDavid WeißGather Requirements for Interface between Environment and SimulatorThere has been a discussion about how a simulator would interact with the environment (e.g. stepping) and it was agreed that there should be a new interface class in MantleAPI for that (see https://gitlab.eclipse.org/eclipse/openpass/man...There has been a discussion about how a simulator would interact with the environment (e.g. stepping) and it was agreed that there should be a new interface class in MantleAPI for that (see https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/merge_requests/138). For this I would like to gather the requirements of such an interface.https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/39Discussion: EntityRepository - Calling Delete invalidates iterator of GetEnti...2024-03-01T09:07:30ZRené Parisrene.paris@in-tech.comDiscussion: EntityRepository - Calling Delete invalidates iterator of GetEntitiesFrom the perspective of a C++ programmer it seems totally natural, that the following construct is a bug:
```cpp
for (const auto& entity : repository->GetEntities())
{
repository->Delete(entity->GetUniqueId());
}
```
Yet, I'd like to...From the perspective of a C++ programmer it seems totally natural, that the following construct is a bug:
```cpp
for (const auto& entity : repository->GetEntities())
{
repository->Delete(entity->GetUniqueId());
}
```
Yet, I'd like to open a discussion here if this is the user experience, the interface should offer.
I thought about some ways to solve that, e.g. using RAII
```cpp
auto manipulation_context = repository->GetManipulationContext();
for (const auto& entity : repository->GetEntities())
{
manipulation_context->Delete(entity->GetUniqueId());
}
// when the manipulation_context goes out of scope it actually executes all delete calls at once
```Jupp TscheakAndreas RauschertMartin StumpJupp Tscheakhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/71MovementDomain is to inflexible for FollowTrajectoryControlStrategy2024-02-21T07:46:50ZDavid WeißMovementDomain is to inflexible for FollowTrajectoryControlStrategyCurrently every ControlStrategy has a predefined MovementDomain. For the FollowTrajectoryControlStrategy this is MovementDomain::kBoth. However the time of each PolyLinePoint is optional (as it is in OpenScenario). But only if the time i...Currently every ControlStrategy has a predefined MovementDomain. For the FollowTrajectoryControlStrategy this is MovementDomain::kBoth. However the time of each PolyLinePoint is optional (as it is in OpenScenario). But only if the time is given for each point, then the trajectory defines the movement of the vehicle in both domains. If there are no times given the trajectory defines only the path of the movement (in OSI it is then called FollowPathAction), i.e. the lateral movement. In this case the longitudinal movement has to be determined by other means. Since there can only be one ControlStrategy for each movement domain, in the current version of MantleAPI, it is not possible for the simulator the determine lateral movement in this case.Andreas RauschertAndreas Rauscherthttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/62Rename master branch to main2023-11-06T15:01:49ZRené Parisrene.paris@in-tech.comRename master branch to mainBoth the simulation core and the openScenarioEngine refrain from using the term "master" branch and follow the example of GitHUB (since Oct. 2020) to use a "main" branch instead.Both the simulation core and the openScenarioEngine refrain from using the term "master" branch and follow the example of GitHUB (since Oct. 2020) to use a "main" branch instead.https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/64Use virtual inheritance in IEntity/IController2023-10-27T10:17:25ZKarl SchrabUse virtual inheritance in IEntity/IControllerCurrently, this "diamond" inheritance scheme is not possible:
```plantuml
interface IIdentifiable
interface IController
class MyIdentifiable
class MyController
IIdentifiable<|-- MyIdentifiable
MyIdentifiable<|-- MyController
IControll...Currently, this "diamond" inheritance scheme is not possible:
```plantuml
interface IIdentifiable
interface IController
class MyIdentifiable
class MyController
IIdentifiable<|-- MyIdentifiable
MyIdentifiable<|-- MyController
IController<|-- MyController
IIdentifiable<|-- IController
```
This scheme would allow to implement common methods like SetUniqueId/SetName only once.
---
It could be realized by using virtual inheritance in IEntity and IController:
Now:
```c++
class IController : public IIdentifiable
```
Proposed change:
```c++
class IController : public virtual IIdentifiable
```https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/43Set Version for MantleAPI & OpenScenarioEngine2023-10-24T09:45:18ZXiao Panxiao.pan@ansys.comSet Version for MantleAPI & OpenScenarioEngineHi, all,
Currently, the absence of versioning in MantleAPI and OpenScenarioEngine makes it challenging to track changes, and manage dependencies. This lack of versioning can lead to difficulties to integrate into the simulator as a pac...Hi, all,
Currently, the absence of versioning in MantleAPI and OpenScenarioEngine makes it challenging to track changes, and manage dependencies. This lack of versioning can lead to difficulties to integrate into the simulator as a package instead of a a submodule.
To address this, I propose the process for versioning :
- Implement a versioning scheme, + indicating backward compatibility.
- Update the README or documentation to include information about each version, including release notes, known issues, and upgrade instructions.
- Currently, package manager integration is not possible before we switch to Bazel 6, but should be documented correctly to ensure compatibility with other dependencies.
- Use Git tags and releases to mark specific versions in the repository, making it easier to download a release.Xiao Panxiao.pan@ansys.comXiao Panxiao.pan@ansys.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/69second cmake or make call fails2023-10-24T09:44:55ZMichael Behrischsecond cmake or make call failsI am on ubuntu 22.04 and did a fresh clone followed by
```
cd mantle-api
mkdir build
cd build
cmake ..
make
```
This works just fine but if I issue another `cmake ..` I get
```
gmake: *** [Makefile:91: all] Error 2
CMake Error at /usr/...I am on ubuntu 22.04 and did a fresh clone followed by
```
cd mantle-api
mkdir build
cd build
cmake ..
make
```
This works just fine but if I issue another `cmake ..` I get
```
gmake: *** [Makefile:91: all] Error 2
CMake Error at /usr/share/cmake-3.22/Modules/FetchContent.cmake:1087 (message):
Build step for units failed: 2
Call Stack (most recent call first):
/usr/share/cmake-3.22/Modules/FetchContent.cmake:1216:EVAL:2 (__FetchContent_directPopulate)
/usr/share/cmake-3.22/Modules/FetchContent.cmake:1216 (cmake_language)
build/cmake/CPM_0.36.0.cmake:967 (FetchContent_Populate)
build/cmake/CPM_0.36.0.cmake:773 (cpm_fetch_package)
CMakeLists.txt:61 (CPMAddPackage)
```
(The reason why I wanted to do this is that I changed a variable in CMakeCache.txt and wanted to redo the configuration. But the error occurs also if I do not change the CMakeCache.txt)
I can also trigger the error by doing
```
touch CMakeCache.txt
make
```
Probably because this just triggers another cmake call.René Parisrene.paris@in-tech.comRené Parisrene.paris@in-tech.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/70Test uses deprecated API2023-10-17T11:38:22ZMichael BehrischTest uses deprecated APIinterface_test.cpp uses
```
auto& host_vehicle = repo.Create(0, "host", vehicle_properties);
```
It should probably replaced by
```
auto& host_vehicle = repo.Create("host", vehicle_properties);
```
at least this change makes the war...interface_test.cpp uses
```
auto& host_vehicle = repo.Create(0, "host", vehicle_properties);
```
It should probably replaced by
```
auto& host_vehicle = repo.Create("host", vehicle_properties);
```
at least this change makes the warning go away :-).https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/33Add mock code and unit tests to guarantee the stability of the API2023-10-17T11:23:41ZMartin StumpAdd mock code and unit tests to guarantee the stability of the APIDear all,
I believe we should begin adding more mock code and unit tests to guarantee the stability of the API in the future while working our way up to v1.0.0.
Creating mock classes for the whole API should be a community effort, sinc...Dear all,
I believe we should begin adding more mock code and unit tests to guarantee the stability of the API in the future while working our way up to v1.0.0.
Creating mock classes for the whole API should be a community effort, since it is tedious work that involves a lot of boilerplate code.
What we get in return, however, will be a way to automatically check for any break in the API, especially when we set up the CI for this project.
Additionally, consumers can use the mock code to implement the API.
I will provide a draft PR to start the discussion on how we could approach this.
I know that work has been started e.g. in `test_utils.h`, but as of now it is incomplete.
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/57Proposal for creating an OpenPASS project versioning system2023-10-13T06:59:04ZStephen RyanProposal for creating an OpenPASS project versioning systemHi all,
Here is a collection of the information of the versioning from the various issues and merge requests.
## Versioning
### From [issues/43](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/43):
It is proposed to u...Hi all,
Here is a collection of the information of the versioning from the various issues and merge requests.
## Versioning
### From [issues/43](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/43):
It is proposed to use the industry-standard Semantic Versioning from [semver.org](https://semver.org/). This is summarized as:
> Given a version number MAJOR.MINOR.PATCH, increment the:
> 1. MAJOR version when you make incompatible API changes
> 2. MINOR version when you add functionality in a backward compatible manner
> 3. PATCH version when you make backward compatible bug fixes
>
> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Tags should be the semantic version, prefixed with "v", see https://github.com/cpm-cmake/CPM.cmake/wiki/Preparing-projects-for-CPM.cmake, and as an example see https://github.com/gabime/spdlog/tags.
## Changelogs
### From [issues/43](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/43):
Ideally, the changelog would be automatically generated from the commit messages. These commits should be squashed. This can be done with the specification from [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), which works well with Semantic Versioning. As a summary from the website:
> The commit message should be structured as follows:
>```
><type>[optional scope]: <description>
>
>[optional body]
>
>[optional footer(s)]
>```
So, an example message could be:
>```
>feat: allow provided config object to extend other configs
>
>BREAKING CHANGE: `extends` key in config file is now used for extending other config files
>```
The ways to indication version changes are:
- As a type, `fix` corresponds to an increment in the `PATCH` version in Semantic Versioning.
- As a type, `feat` corresponds to an increment in the `MINOR` version.
- `BREAKING CHANGE` in the commit body or a `!` after the type/scope indicates an increment in the `MAJOR` version.
More details are on the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) website.
### From [issues/33](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/33):
Mocks and tests for the whole API would need to be implemented to detect incompatable API changes for incrementing the MAJOR version.
Benefits:
- Easy way of detecting major version changes, meaning API breaks. Automatic checking with CI.
- Consumers can use the mock code to implement the API.
Example implementation of the mock code has been done in [merge_requests/80](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/merge_requests/80).
- The mock classes are a replacement of `test_utils.h`, which is split into multiple files, with one mock per class. E.g., `MockEnvironment` and `EnvironmentTest` for `IEnvironment`.
- Currently contains mocks for `IIdentifiable`, `IEnvironment`, `ILaneLocationQueryService`, and `IEntity`.
- Tested on Mercedes-Benz use cases.
## Release checklist
There should be a checklist for creating each release. As an example, this could be:
- Create release notes from commits
- Update the README or documentation to include information about each version, including release notes, known issues, and upgrade instructions.
- Use Git tags and releases to mark specific versions in the repository, making it easier to download a release
- Etc.
## Remaining work for the first release
- [ ] Create API Mocks for each class.
- [ ] Setup CI so that changelogs can be automatically created and major version changes can be detected.
- [ ] Think about how to enforce commit messages
- [ ] Set up squashing merge commits for every merge request
- [ ] Need a well formatted template for merge commit messages
Anything else?https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/67Fix CI script for doxygen2023-09-27T13:45:46ZNaida GoroFix CI script for doxygen- Ensuring that `doxy_version` is set.
- Filtering should be encapsulated to a function.- Ensuring that `doxy_version` is set.
- Filtering should be encapsulated to a function.René Parisrene.paris@in-tech.comRené Parisrene.paris@in-tech.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/68CI Doxygen build: error: Problems running gswin32c.exe. Check your installation!2023-09-26T09:12:00ZRené Parisrene.paris@in-tech.comCI Doxygen build: error: Problems running gswin32c.exe. Check your installation!https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/63Lack of developer documentation2023-09-25T08:54:16ZNaida GoroLack of developer documentationhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/66IControllerConfig: Copy constructor incomplete and missing move constructor2023-09-20T11:17:16ZRené Parisrene.paris@in-tech.comIControllerConfig: Copy constructor incomplete and missing move constructorThe IControllerConfig only holds types, which are trivially copyable. Yet it defines a copy constructor, which unwraps the internal `std::vector<std::shared_ptr<mantle_api::ControlStrategy>> control_strategies;` and rebuilds them as new ...The IControllerConfig only holds types, which are trivially copyable. Yet it defines a copy constructor, which unwraps the internal `std::vector<std::shared_ptr<mantle_api::ControlStrategy>> control_strategies;` and rebuilds them as new unique_ptr (didn't know, that this even works)
See: https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/blob/master/include/MantleAPI/Traffic/i_controller_config.h?ref_type=heads#L34
Unfortunately the copy CTOR is incomplete w.r.t name and RouteDefinition and also lacks other typically declared constructs, such as the move constructor (Rule of 5).
I'd propose to remove the copy constructor, as shown here: http://coliru.stacked-crooked.com/a/4f41c78ad12d872bRené Parisrene.paris@in-tech.comAndreas RauschertRené Parisrene.paris@in-tech.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/65Pascal Name Conflict in MinGW2023-09-18T14:09:05ZRaghunandan Netrapalli MadhusudhanPascal Name Conflict in MinGWThe usage of current units library in the MantleAPI would generate a "pascal" name conflict when working on opSimulation in MinGW.
![image](/uploads/c877841c6d53e28add5c78935eb0d090/image.png)The usage of current units library in the MantleAPI would generate a "pascal" name conflict when working on opSimulation in MinGW.
![image](/uploads/c877841c6d53e28add5c78935eb0d090/image.png)https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/61Agenda for the meeting "IMap Interface - Revise current status"2023-09-06T15:23:31ZAnastasiia VolkovaAgenda for the meeting "IMap Interface - Revise current status"Hi all,
Please announce the topics you want to discuss on the meeting "**IMap Interface - Revise current status**" (28 July 2023).
Your offers will be gathered in agenda and a meeting summary will be compiled further.
Best regards, Ana...Hi all,
Please announce the topics you want to discuss on the meeting "**IMap Interface - Revise current status**" (28 July 2023).
Your offers will be gathered in agenda and a meeting summary will be compiled further.
Best regards, Anastasiiahttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/55Controller Interface too fractured2023-09-05T08:34:09ZRené Parisrene.paris@in-tech.comController Interface too fracturedAfter discussion with @arauschert, we came to the conclusion that the interface for activation and deactivation could need a refurbishment.
Reasoning:
Activation of both domains (lateral and longitudinal) should be executed in a single ...After discussion with @arauschert, we came to the conclusion that the interface for activation and deactivation could need a refurbishment.
Reasoning:
Activation of both domains (lateral and longitudinal) should be executed in a single command, allowing the environment simulator to validate if a controller is able handle the request.
Example:
- A controller only supports a both domains.
Before:
- Mantle always sends two commands, such as ActivateLongitudinal and ActivateLateral
Even if this happens within a single time step, it is harder quit with "unsupported mode"
After
- Mantle sends single command ChangeActivationState(true, true); // everything fine
- Mantle sends single command ChangeActivationState(true, false); // not supported
- Mantle sends single command ChangeActivationState(false, true); // not supportedRené Parisrene.paris@in-tech.comRené Parisrene.paris@in-tech.com