mantle-api issueshttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues2024-03-19T09:36:03Zhttps://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/60Lifetime Concerns with std::string_view in OpenDriveRoadPosition and OpenDriv...2023-07-26T06:33:43ZXiao Panxiao.pan@ansys.comLifetime Concerns with std::string_view in OpenDriveRoadPosition and OpenDriveLanePositionRecently, we noticed that the type of the `road` variable in the `OpenDriveRoadPosition` and `OpenDriveLanePosition` structures has been changed to `std::string_view`. This change was made to avoid memory allocation and ensure constancy,...Recently, we noticed that the type of the `road` variable in the `OpenDriveRoadPosition` and `OpenDriveLanePosition` structures has been changed to `std::string_view`. This change was made to avoid memory allocation and ensure constancy, which can be beneficial for performance and safety.
This situation poses a challenge because `std::string_view` only provides a non-owning view of the data and depends on the existence of the original string throughout its usage. When the original string is destroyed by the stateless coordinate conversion function, any subsequent access to the `std::string_view` becomes invalid and leads to undefined behavior.
Possible solutions may keeping the original strings alive for the duration of their usage (store state in the map engine) or considering alternative `string` representations in cases where the lifetime of the data cannot be guaranteed.
Please provide feedback and suggestions on how to handle this situation.Xiao Panxiao.pan@ansys.comXiao Panxiao.pan@ansys.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/59New implementation of mantle_api::AlmostEqual() yields unexpected result2023-07-26T06:50:09ZEtienne PellanNew implementation of mantle_api::AlmostEqual() yields unexpected resultHi,
The `mantle_api::IsEqual()` method was updated and renamed to `mantle_api::AlmostEqual()` in [Common/floating_point_helper.h](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/blob/master/include/MantleAPI/Common/floating_po...Hi,
The `mantle_api::IsEqual()` method was updated and renamed to `mantle_api::AlmostEqual()` in [Common/floating_point_helper.h](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/blob/master/include/MantleAPI/Common/floating_point_helper.h) with [this commit](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/commit/009c93f1743c42186fe537025f562e9a5c0c35a5).
The following assertion :
`static_assert(!AlmostEqual(1000.0, 1000.1, 0.05));`
fails when added inside [test/MantleAPI/Common/floating_point_helper_test.cc](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/blob/master/test/MantleAPI/Common/floating_point_helper_test.cc).
In other words, `AlmostEqual(1000.0, 1000.1, 0.05)` returns `true`, when I would expect it not to.
This is an unexpected result given the method's name, and is inconsistent with the previous implementation.
The assertion seems to fail no matter the tolerance value, as long as it is positive and inferior to the absolute difference of `lhs` and `rhs`.
This is currently breaking a lot of our tests and blocking further feature integrations. Could you please have a look at it ?
Thank youMartin StumpMartin Stumphttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/41Discussion: Basic calculations on internally used vector type2023-07-27T06:54:34ZRené Parisrene.paris@in-tech.comDiscussion: Basic calculations on internally used vector typeFollowing @jtschea's comment here, https://gitlab.eclipse.org/eclipse/openpass/openscenario1_engine/-/merge_requests/121#note_1114246, I also think that it's a good idea to have some basic calculations on our vector type directly in mant...Following @jtschea's comment here, https://gitlab.eclipse.org/eclipse/openpass/openscenario1_engine/-/merge_requests/121#note_1114246, I also think that it's a good idea to have some basic calculations on our vector type directly in mantle, such as length.
Please feel free to put your ideas and thought on that here.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/35Add interface for logging2023-04-18T04:54:26ZDavid WeißAdd interface for loggingThere is currently no mechanism for logging of error, warning and info messages in MantleAPI. Therefore the OpenScenarioEngine logs all messages to the console using std::cout, which is not convenient for the user. I would like to introd...There is currently no mechanism for logging of error, warning and info messages in MantleAPI. Therefore the OpenScenarioEngine logs all messages to the console using std::cout, which is not convenient for the user. I would like to introduce a new Interface in MantleAPI with the following use case:
The simulator should be able to display logging messages of the scenario engine in its user interface or write them into a file.
The interface should be able to distinguish different kinds/levels of logging messages, e.g. error, warning, info.Reinhard BiegelRené Parisrene.paris@in-tech.comArun DasAndreas RauschertMartin StumpReinhard Biegelhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/29Discussion: Lack of possiblity to activate/deactivate controller2023-04-12T07:05:04ZRené Parisrene.paris@in-tech.comDiscussion: Lack of possiblity to activate/deactivate controllerIn the openScenarioEngine we're currently implementing the possibility to switch between default and user defined controller (during runtime).
The best we could do so far was to use the method `IEnvironment::AddEntityToController` withi...In the openScenarioEngine we're currently implementing the possibility to switch between default and user defined controller (during runtime).
The best we could do so far was to use the method `IEnvironment::AddEntityToController` within the [AssignControllerAction](https://gitlab.eclipse.org/eclipse/simopenpass/openscenario1_engine/-/blob/main/engine/src/Storyboard/GenericAction/AssignControllerAction_impl.cpp), but we don't see an option to communicate activate/deactivate via boolean flags as specified in the [ActivateControllerAction](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.1.1_Model_Documentation/modelDocumentation/content/ActivateControllerAction.html).
Any hints on how an enhancement could look like?René Parisrene.paris@in-tech.comDavid WeißArun DasAndreas RauschertRené Parisrene.paris@in-tech.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/28Discussion: Interpretation of points for Trajectories and SetPosition2023-01-23T10:05:15ZRené Parisrene.paris@in-tech.comDiscussion: Interpretation of points for Trajectories and SetPositionWhile working on the openScenarioEngine we came across the following situation:
- Coordinates coming from the openSCENARIO file defines positions w.r.t the center of rear axle.
- When communicating these points to the simulation, e.g. wi...While working on the openScenarioEngine we came across the following situation:
- Coordinates coming from the openSCENARIO file defines positions w.r.t the center of rear axle.
- When communicating these points to the simulation, e.g. within the TeleportAction, we use `IEntity::SetPosition(...)`
This method specifies the points w.r.t to the center of the bounding box, so we do a proper coordinate transformation before sending the data to the simulator
- Internally, the simulator uses the same definition as openSCENARIO and we reverse the coordinate transformation, which means that:
1. we do the same (reverse) transformation again -> highly inefficient
2. we need to know the properties of the entity (which is okay for SetPosition, as we are inside if the implementation of the Entity itself)
The actual issue arise when we now look at Trajectories. To be consistent with Mantle, we also translate the points to the center of the bounding box, but it is not our core component, which implements the actual trajectory. Instead we have 2 different modules interpreting the trajectory. That means that every module needs to do the same reverse transformation and needs to know about the offset to be applied. Note that we do not write directly to the Entities via SetPosition, which would solve that issue indirectly. Also potential calculations need the translated positions.
1. This is also highly inefficient
2. It opens the door for potential bugs
3. We need to propagate the translation to the modules
We propose to enhance the `SetPosition` method as well as the definition of the `Trajectory` by an optional enumeration defining, how to interpret the position and which defaults to the center of the bounding box.
e.g.:
- `SetPosition({1_m,, 2_m, 0_m}, AnchorType::CenterOfBoundingBox)`
- `SetTrajectory({{1_m,, 2_m, 0_m}, {3_m, 4_m, 0_m}}, AnchorType::CenterOfRearAxle)`
Any ideas about that?René Parisrene.paris@in-tech.comDavid WeißArun DasAndreas RauschertRené Parisrene.paris@in-tech.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/13TrafficSignalController2022-11-22T12:59:11ZRené Parisrene.paris@in-tech.comTrafficSignalControllerWe're currently working on the implementation of TrafficSignal related actions and conditions within the openSCENARIO-Engine.
In order to implement the [TrafficSignalControllerAction](https://www.asam.net/static_downloads/ASAM_OpenSCENAR...We're currently working on the implementation of TrafficSignal related actions and conditions within the openSCENARIO-Engine.
In order to implement the [TrafficSignalControllerAction](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.1.1_Model_Documentation/modelDocumentation/index.html), which refers to specific phases of a traffic signal controller, the MantleAPI needs to be enhanced.
Currently, we're thinking about introducing a controller repository for traffic signals, which can be used in a two stage process:
1) Inform a potential simulator about traffic controllers and the corresponding phases.
Pseudocode:
```c++
auto repo = environment->GetTrafficSignalControllerRepository();
auto traffic_signal_controller = repo->Create([[std::string]] traffic_signal_controller_name,
[[std::vector<mantleAPI::Phase>]] phases);
```
This also means, that we need to define a new mantleAPI::Phase datatype, similar to the definition in openSCENARIO (see [here](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/Phase.html))
2) Use the same repository for implementing actions and conditions
Pseudocode:
```c++
auto repo = environment->GetTrafficSignalControllerRepository();
auto traffic_signal_controller = repo->Get([[std::string]] traffic_signal_controller_name);
auto traffic_signal_phase = traffic_signal_controller->GetPhase();
```
We'll perpare an MR, but it would be great to have discussion beforehand, e.g. on how to properly define the `Phase` datatype.Arun DasArun Dashttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/3Naming of Scenario API2022-07-07T13:54:34ZArun DasNaming of Scenario APIAs discussed previously, we want to give everyone the option to propose a naming for the API. Currently the repository is called "Scenario API" and within the repository it's called "Mantle API".
@all Please bring your suggestions here...As discussed previously, we want to give everyone the option to propose a naming for the API. Currently the repository is called "Scenario API" and within the repository it's called "Mantle API".
@all Please bring your suggestions here. A decision will be made by 6th August 2021.2021-08-06