simulation issueshttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues2022-04-25T17:26:12+02:00https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/40Angle Calculation between Vectors Incorrect2022-04-25T17:26:12+02:00Til MohrAngle Calculation between Vectors IncorrectThe calculation for the angle between two vectors (e.g. https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/commons/-/blob/master/src/main/java/de/rwth/montisim/commons/utils/Vec3.java#L89) is implemented incorrectly.
See [...The calculation for the angle between two vectors (e.g. https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/commons/-/blob/master/src/main/java/de/rwth/montisim/commons/utils/Vec3.java#L89) is implemented incorrectly.
See [this](https://www.cuemath.com/geometry/angle-between-vectors/) and [OpenJFX Point3D Implementation](https://github.com/teamfx/openjfx-9-dev-rt/blob/master/modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java) for references.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/39ActiveMQ integration2021-12-17T13:39:41+01:00Evgeny KusmenkoActiveMQ integrationSimulator soll von ROS auf ActiveMQ umgestellt werdenSimulator soll von ROS auf ActiveMQ umgestellt werdenMattis HoppeMattis Hoppehttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/38Physical Collisions2021-11-26T14:28:38+01:00Evgeny KusmenkoPhysical CollisionsAt the moment collisions are detected, but there is no physical response.
Physical collision handling needs to be added.At the moment collisions are detected, but there is no physical response.
Physical collision handling needs to be added.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/37Simulate then Vizualize2021-11-05T13:55:40+01:00Evgeny KusmenkoSimulate then VizualizeIt is important to be aable to run the simulation first and vizualize the results later, e.g. for analysis purposesIt is important to be aable to run the simulation first and vizualize the results later, e.g. for analysis purposeshttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/36Descriptive Task results2021-10-24T16:00:12+02:00Jean MeuriceDescriptive Task resultsRight now, simulations only return `SUCCESS` or `FAILURE`. While the reason for failure can be better seen when using a GUI (like in the basic-simulator), this makes it hard to understand problems in a CI/CLI setting.
## Task
- Return ...Right now, simulations only return `SUCCESS` or `FAILURE`. While the reason for failure can be better seen when using a GUI (like in the basic-simulator), this makes it hard to understand problems in a CI/CLI setting.
## Task
- Return descriptive reasons when `Tasks` fail. (Ex: "Collided with ...", "Timeout", ...)https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/35Merge SpeedLimit and Navigation components2021-10-20T18:49:31+02:00Jean MeuriceMerge SpeedLimit and Navigation componentsThe SpeedLimit component performs very redundant computations compared to the Navigation component.
The Navigation component can send the `upper_speed_limit` message alongside the trajectory arrays.
This would be a "zero-cost abstractio...The SpeedLimit component performs very redundant computations compared to the Navigation component.
The Navigation component can send the `upper_speed_limit` message alongside the trajectory arrays.
This would be a "zero-cost abstraction" from the communication modelling perspective: a message that is not used by any other ee-component is automatically not routed and sent (by the EE-system).https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/343D World2021-10-20T18:44:20+02:00Jean Meurice3D WorldRight now, the world is 100% flat (at `z=0`) except the buildings which have height.
The rigidbody physics do not model the wheel-ground interaction properly.
Missing is proper collision-detection and collision-resolution with road/grou...Right now, the world is 100% flat (at `z=0`) except the buildings which have height.
The rigidbody physics do not model the wheel-ground interaction properly.
Missing is proper collision-detection and collision-resolution with road/ground geometry. (Requires #33)
There were previous ideas on how to make the world 3D. These can be found in `simulation/old-code/environment/.../geometry/height`
## Tasks
- Correct ground collision-responses in `RigidbodyPhysics`
- Ground and road height based on a noise function, OSM information (if any), image or other height information source (SRTM, ...)https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/33Detailed Road Geometry2021-10-20T18:44:21+02:00Jean MeuriceDetailed Road Geometry## Idea
Bring back the "detailed" road geometry: curves for the boundaries, lanes, proper intersection geometry, side-walks, traffic signs, ...
## Tasks
- Generate proper geometry from the abstract OSM road information
- Handle adja...## Idea
Bring back the "detailed" road geometry: curves for the boundaries, lanes, proper intersection geometry, side-walks, traffic signs, ...
## Tasks
- Generate proper geometry from the abstract OSM road information
- Handle adjacent road segments, handle intersections
- Handle number of lanes, transitions from different lane numbers, ...
- Register individual geometry-chunks as "static-objects" in the simulator
- Handle the collision response in the vehicle
- Add "stay on road" checks, ...
- Add proper rigidbody physics for the road-vehicle interactions
- Road markings ("vectorial"/spline representation) + type
- Sidewalks
- Traffic signs, lights, ...
## Notes
- Some old code that did this can be found in `simulation/old-code/environment`.
- *If old code is adapted, it should use the proper [Vector Math](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/wikis/dev-docs/commons/Vectors,-Matrices-and-Math)*
- This can be built up progressively:
- Generate simple rectangular chunks for the road
- Test the junction between segments
- Test detecting overlaps
- Intersections: simple polygons
- More detailed road geometry
- ...https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/32Scenario Folders2021-10-20T17:57:21+02:00Jean MeuriceScenario Folders- Handle sub-folders in the scenario-view
- Give the basic-simulator a [list] of scenario folders via command line to be shown in the "browser"- Handle sub-folders in the scenario-view
- Give the basic-simulator a [list] of scenario folders via command line to be shown in the "browser"https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/27Efficient Lidar Lookup / Lidar updates2021-10-20T18:57:18+02:00Jean MeuriceEfficient Lidar Lookup / Lidar updatesRight now the `Lidar` ee-component logic is highly inefficient: it iterates over all the edges of all the buildings in the map *per lidar trace* (8 per vehicle).
It also accesses the vehicle position in a conceptually wrong way.
Its mat...Right now the `Lidar` ee-component logic is highly inefficient: it iterates over all the edges of all the buildings in the map *per lidar trace* (8 per vehicle).
It also accesses the vehicle position in a conceptually wrong way.
Its math can also be improved.
## Spatial Acceleration
Use the grid acceleration structure in `CollisionDetection` and traverse it (up to a max distance) starting from the lidar "ray" origin. Then check the buildings referenced in the grid cell.
- Make `CollisionDetection` available in the [BuildContext](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/wikis/dev-docs/simulation/Initialization-Overview#build-context) for the ee-components.
- Implement a cell traversal + have a hash-set to remove duplicate checks on buildings (a single building can be linked in multiple overlapping cells)
- [Reference for implementation](https://www.scratchapixel.com/lessons/advanced-rendering/introduction-acceleration-structure/grid)
- Choose a sensible max distance for the lidar check after which the grid traversal is stopped.
## Accessing the position
Right now, the Lidar component listens for `true_position` messages. Such messages are intended as "measured position" for use by components that would actually need to get an estimate of the position in a real vehicle. (Such as the Navigation component).
The physics of the Lidar are not dependent on a measured position: they happen in the real world. The Lidar should thus use the position of the dynamic_object of the vehicle.
On the other hand, the distance measured by the lidar could be modeled as imprecise, for example introduction noise.
## Bonus Tasks: Clearer lidar math
- [IPM](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/wikis/dev-docs/commons/Vectors,-Matrices-and-Math#in-place-math-ipm) for the math: store the vectors in the Lidar object and re-use them using IPM functions.
- Vehicle "model matrix":
- The lidar "rays" (position and direction vectors) can be defined in the local vehicle space once.
- When computing/updating, generate one rotation/translation matrix (in extended coordinate space) for the vehicle
- Use this matrix in the `computeShortestDistance()` function to get the lidar ray position and direction in world space
- Overall edge/ray intersection math can be revisited (use simple dot products, edge "normals", ...) + **check if the intersection is "in front" of the ray** (does not seem to be the case/to be verified).https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/26Handle Collisions / Policy System2021-10-20T16:37:56+02:00Jean MeuriceHandle Collisions / Policy SystemCollision *detection* has been implemented between car and static-objects and between cars.
However right now these are just listed in the vehicle. (As can be seen in the *basic-simulator*).
## Task
- Connect the collision detection wi...Collision *detection* has been implemented between car and static-objects and between cars.
However right now these are just listed in the vehicle. (As can be seen in the *basic-simulator*).
## Task
- Connect the collision detection with the TaskStatus of the vehicle: Collisions should be a `FAILURE`
- The collision-detection system (simulator -> `CollisionDetection`) calls the `handleVehicleCollision()` and `handleStaticCollision()` methods of `Vehicle` when collisions occur.
- Handle the `IntegrationTest` of the `simulator` sub-project: The `JavaAutopilot` used in the test does not drive well enough to avoid collisions.
- Either improve the `JavaAutopilot`
- (recommended) or add a *Policy* system to the simulator (which can be generally useful)
### Policy System TODOs
- Create a `SimulationPolicies` class in the `simulation/commons` sub-project. (Why in this sub-project: would be used by the other sub-projects)
- Add booleans or other typed *policies* (ex: `NO_COLLISIONS`) with default values
- Add the policy class to the `SimulationConfig` so it can be specified in the scenarios
- On simulation construction: make the policy object available through the [BuildContext](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/wikis/dev-docs/simulation/Initialization-Overview#build-context) system.
- There could also be a *per vehicle* policy system (defined in the `VehicleProperties`) -> code that depends on policies (ex: collision handling) should then check both the global simulation policy and its own vehicle policy
- Use the policy for the vehicle collisions behavior
- **Document the policy system**https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/29OpenGL visualization2021-10-20T17:38:41+02:00Jean MeuriceOpenGL visualization## Problem
- Right now, the 2D visualization of the maps and vehicles uses the `Graphics2D` java class inside the `Swing` components.
- This is not a very efficient rendering method, especially for large scale cities.
- It is also not p...## Problem
- Right now, the 2D visualization of the maps and vehicles uses the `Graphics2D` java class inside the `Swing` components.
- This is not a very efficient rendering method, especially for large scale cities.
- It is also not precise: the polygon geometry can only be passed with integer pixel positions.
## Solution
Use OpenGL rendering.
- As OpenGL library (for example): [JOGL](https://jogamp.org/jogl/www/)
- [JOGL in Swing](https://www.tutorialspoint.com/jogl/jogl_canvas_with_swing.htm) (Still up-to-date ?)
- [OpenGL 4 JOGL sample](https://github.com/jvm-graphics-labs/hello-triangle)
- TODOs:
- Test a simple 2D triangle with a basic shader.
- Make it build and run using the JOGL maven artifacts.
- Make a *colored triangle* shader with an orthogonal view matrix, test binding it to the map controls (position, zoom). Render a simple triangle (or 2)
- Make a *colored line* shader, same view matrix, test a simple outline.
- Generate the building geometry in one VBO/VAO/EBO set.
- Use the already split convex parts
- The *convex* polygon parts can be rendered using the `GL_TRIANGLE_FAN` drawing mode
- In combination with the [Primitive Restart](https://stackoverflow.com/questions/4386861/opengl-jogl-multiple-triangle-fans-in-a-vertex-array)
- Use an Element-Buffer
- Use the `PRIMITIVE_RESTART` index to separate triangle fans for different polygons
- Since we only want to draw contiguous vertices, the `glMultiDrawElements()` method can be useful
- Generate the road geometry (or visualization lines)
- Generate the vehicle geometry (one VBO/EBO/VAO set)
- Same triangle shader, but give it a view+model matrix (pre-multiplied)
- All the debug lines/elements (AABB, building outlines, ...) can be in their own VBO/EBO/VAO.
- **Check the thread interaction between Swing and OpenGL**. The OpenGL calls are not thread-safe for a given context. Be sure that the OpenGL calls happen in the correct thread.
- [Swing Threads](http://www.javapractices.com/topic/TopicAction.do?Id=153)
**Note**: The existing visualization already "pre-generates" the geometry in some way to save computation. Changing to save this geometry in OpenGL buffer would not be a big change.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/30Time-control bugs2021-10-20T17:46:50+02:00Jean MeuriceTime-control bugs## Problem
The time-control of the visualization does not seem to be correct.
For example, with the "simulation-speed" set to low values (1/4, 1/8, ...) the control loop can stop advancing the simulation.
Generally, the visualization ...## Problem
The time-control of the visualization does not seem to be correct.
For example, with the "simulation-speed" set to low values (1/4, 1/8, ...) the control loop can stop advancing the simulation.
Generally, the visualization does not handle the rendering time well in order to prioritize the simulation speed.
## Fixes
A correct time-control loop should adapt the FPS to keep-up the desired simulation speed up to a certain minimum FPS limit.
Right now, the updates are handled in a java `Timer` callback. This is used in order to be in the GUI thread. However this makes the control loop logic hard. Ideally, the control logic should be as presented [here](https://gafferongames.com/post/fix_your_timestep/) (with fixed time-steps).
**If the [Async Simulation and Visualization](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/basic-simulator/-/issues/3) are implemented again**, the visualization control loop would be completely different since the simulation would not have to be updated in parallel.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/25Proper Logging2021-10-20T18:59:13+02:00Jean MeuriceProper Logging## Idea
Re-instate *proper* logging: well structured, controllable, efficient (using ifs).
## Task
- Define a *target tree* which would well represent the different logging points of interest.
- The different branches/leaves in that t...## Idea
Re-instate *proper* logging: well structured, controllable, efficient (using ifs).
## Task
- Define a *target tree* which would well represent the different logging points of interest.
- The different branches/leaves in that tree should be easily enabled/disabled for debugging.
- The code uses `if`s on its corresponding target before logging to minimize overhead.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/24Proper Error/Exception handling2021-10-20T17:43:13+02:00Jean MeuriceProper Error/Exception handlingThe entire simulator could use a proper error handling concept that would be used throughout all simulator projects.
Goals:
- Describe a concept for designing exceptions and how they are propagated through the simulator.
- It has to sup...The entire simulator could use a proper error handling concept that would be used throughout all simulator projects.
Goals:
- Describe a concept for designing exceptions and how they are propagated through the simulator.
- It has to support exceptions occurring remotely (autopilot, remote server) as well as in other languages (ex: c++ for the hardware_emulator)
- Ideally a comprehensible stack trace would show additional contextual information at different points in the call/catch stack.
- List all the *errors* (that are relevant to a *user*) and define a system to properly notify them.
- Define a system to properly notify *exceptions* (bugs/missing features).https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/28JSON extensions2021-10-20T18:50:53+02:00Jean MeuriceJSON extensionsImprove the usability of the JSON system for the configuration and scenarios.
Ideas:
- Support hex & binary
- Allow comments
- Units
- Duration: alternative representations (support various min/sec/... units)
- Reference to other files:...Improve the usability of the JSON system for the configuration and scenarios.
Ideas:
- Support hex & binary
- Allow comments
- Units
- Duration: alternative representations (support various min/sec/... units)
- Reference to other files: A special tag could be used to refer to a file relative to the current one. It would then be substituted. This mechanism could also be used as "template". The referred file would be loaded first, but the 'calling' file could still specify fields that would override the loaded file.
**Note**: The extensions should be correct JSON. So for example the Duration "units" extension would be specified in a JSON String. The parsing code must check the different cases and parse appropriately.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/31Async Simulation and Visualization + Data-Export system2021-10-20T17:46:50+02:00Jean MeuriceAsync Simulation and Visualization + Data-Export systemIdea: Run the simulations in another thread.
Advantages:
- Some performance improvement since one thread can run the simulation full speed, the other render the visualization.
- (Re-)develop the simulation data exporting. The relevant s...Idea: Run the simulations in another thread.
Advantages:
- Some performance improvement since one thread can run the simulation full speed, the other render the visualization.
- (Re-)develop the simulation data exporting. The relevant simulation data-points are saved per frame (can be a different rate then the simulation rate). The simulation "client" would register which data-points should be exported (to save bandwidth).
- The basic-sim can store the frames for a simulation. This allows to watch a simulation as it is simulated, but also to watch back/navigate the simulation using a timeline.
- This simplifies the time control logic between visualization and simulation.
- The data-export system can also directly be used to save simulation results.
- The data-export system could also be used to watch simulations remotely (would update the *visualization* project)
- A solid data-export system would make exporting any data (also inspection data for plotting, ...) cleaner and more generic.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/21Docu TODO2021-10-24T17:07:31+02:00Hengwen Zhanghengwen.zhang@rwth-aachen.deDocu TODO## User-docs
- [ ] "Autopilot configuration": What to specify ? Quick overview of compiling/running EMA-based autopilots ?
- [ ] SimLang/CarLang/MontiCore links in "Introduction to MontiSim"
- [ ] basic-sim "link to maven tutorial"
## ...## User-docs
- [ ] "Autopilot configuration": What to specify ? Quick overview of compiling/running EMA-based autopilots ?
- [ ] SimLang/CarLang/MontiCore links in "Introduction to MontiSim"
- [ ] basic-sim "link to maven tutorial"
## Dev-docs
- Intro
- [ ] "Intro" text?
- [ ] Overview of next sections & pages
- Simulation
- [ ] Properties: registering the classes (+link to JSON system?)
- [ ] Simulation Methods -> TODOs in wiki page
- [ ] Simulator class and simulation data
- EE-System
- [ ] EE System -> TODOs in wiki page
- [ ] Various EEComponents: explanation of their inner workings
- [ ] EEComponents Development: "How to create an EEComponent sub-class"
- [ ] EE Message reference: which component sends which message and with what type
- World & Geometry
- [ ] OSM loading
- Vehicles
- [ ] Vehicles overview
- [ ] Tasks
- [ ] PhysicalValues
- [ ] PowerTrain
- [ ] Collision: Vehicle objects and hitboxes somewhere?
- [ ] Rigidbody physics
- Visualizations
- [ ] basic-simulator
- [ ] debug-viewer classes (Viewer2D, PhysicsDebug, ...)
- General/Commons
- [ ] Commons Overview
- [ ] Describe "polygon-convexer" ?
- [ ] JSON-Serializer
## Other
- [ ] Move & update documentation in 'hardware_emulator/readme.md'
- [ ] In the `simulation.wiki` repository, there are a bunch of old documentation files under `TO_SORT`. These have to be integrated in the new documentation (or simply deleted).
- [ ] Add in Code: Link to relevant docu pages