simulation issueshttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues2021-10-20T18:44:20+02:00https://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/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/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.