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/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/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.com