EmbeddedMontiArc issueshttps://git.rwth-aachen.de/groups/monticore/EmbeddedMontiArc/-/issues2019-02-25T17:52:25+01:00https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/CNNArch2Gluon/-/issues/2Refactorings required2019-02-25T17:52:25+01:00Evgeny KusmenkoRefactorings requiredPlease make sure most of the code is inherited from the MxNet generator. For instance in the generator class.Please make sure most of the code is inherited from the MxNet generator. For instance in the generator class.Sebastian NickelsNicola GattoSebastian Nickelshttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Middleware/-/issues/22Armadillo.h contains mingw specific imports2019-03-01T20:52:34+01:00Alexander David HellwigArmadillo.h contains mingw specific importsAlexander David HellwigAlexander David Hellwighttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/17Faulty search for minimal value in SplineDeterminator class2019-03-31T20:30:47+02:00Benjamin StutteFaulty search for minimal value in SplineDeterminator classThe method `getMinimumSplineForSetAndPoints` initializes the variable `minDist` with `Double.MAX_VALUE` but its content is never overwritten when a smaller value is found. Consequently, the comparison in [line 188](https://git.rwth-aache...The method `getMinimumSplineForSetAndPoints` initializes the variable `minDist` with `Double.MAX_VALUE` but its content is never overwritten when a smaller value is found. Consequently, the comparison in [line 188](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/environment/src/main/java/simulation/environment/geometry/osmadapter/SplineDeterminator.java#L188) evaluates to `true` with every iteration and the method always returns the last element in the given set and not neccessarily the correct one.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/16Bug in initialization of LinearSplineDeterminator2019-03-31T20:30:54+02:00Benjamin StutteBug in initialization of LinearSplineDeterminatorInside the [initBounds()](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/environment/src/main/java/simulation/environment/geometry/osmadapter/LinearSplineDeterminator.java#L66) method we check for...Inside the [initBounds()](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/environment/src/main/java/simulation/environment/geometry/osmadapter/LinearSplineDeterminator.java#L66) method we check for a `y` but assign an `x`-coordinate.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Middleware/-/issues/21ROS2: Message -> C++ generation2019-05-05T11:16:17+02:00Alexander David HellwigROS2: Message -> C++ generation.h files generated from .msg files can lead to compilation errors..h files generated from .msg files can lead to compilation errors.Alexander David HellwigAlexander David Hellwighttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Middleware/-/issues/20Automatic Clustering parameter search2019-02-16T13:47:12+01:00Alexander David HellwigAutomatic Clustering parameter searchE.g. try different values for sigma while using SpectralClusteringE.g. try different values for sigma while using SpectralClusteringhttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/15WorldModel.java: possibly several bugs in methods used to access wheel positions2019-04-08T10:44:32+02:00Benjamin StutteWorldModel.java: possibly several bugs in methods used to access wheel positionsBoth [`getDistanceLeftFrontToStreetBorder`](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/environment/src/main/java/simulation/environment/WorldModel.java#L349) and [`getDistanceRightFrontToStree...Both [`getDistanceLeftFrontToStreetBorder`](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/environment/src/main/java/simulation/environment/WorldModel.java#L349) and [`getDistanceRightFrontToStreetBorder`](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/environment/src/main/java/simulation/environment/WorldModel.java#L359) call `getBackLeftWheelGeometryPosition()` to determine the wheel position while it should be `getFrontLeftWheelGeometryPosition()` and `getFrontRightWheelGeometryPosition()` respectively.
Furthermore, the methods [`getDistanceFrontRightWheelToRightStreetBorder`](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/environment/src/main/java/simulation/environment/WorldModel.java#L377) [`getDistanceBackRightWheelToRightStreetBorder`](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/environment/src/main/java/simulation/environment/WorldModel.java#L387) return `minStreet.getDistanceToLeft` while it seems like it should be `minStreet.getDistanceToRight`.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/14Possible typo in doCalculationStep method of ModelicaPhysicalVehicle2019-03-31T20:31:11+02:00Benjamin StuttePossible typo in doCalculationStep method of ModelicaPhysicalVehicleShouldn't [this line](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/vehicle/src/main/java/simulation/vehicle/ModelicaPhysicalVehicle.java#L568) be
`double brakeAcceleration4 = simulationVehicle....Shouldn't [this line](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/vehicle/src/main/java/simulation/vehicle/ModelicaPhysicalVehicle.java#L568) be
`double brakeAcceleration4 = simulationVehicle.getVehicleActuator(VEHICLE_ACTUATOR_TYPE_BRAKES_BACK_RIGHT).getActuatorValueCurrent();`?https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Middleware/-/issues/18Test flatten algorithm with a comparable Component2019-02-16T14:08:23+01:00Philipp GörickTest flatten algorithm with a comparable ComponentDo not just test the algorithm for the right amount of connectors and subcomponents.Do not just test the algorithm for the right amount of connectors and subcomponents.Philipp GörickPhilipp Görickhttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Cpp/-/issues/28Add automatic test execution for cmake build script2019-04-11T18:49:39+02:00Alexander David HellwigAdd automatic test execution for cmake build scriptBasic idea:
Add to CMakeLists.txt
add_custom_target(run_${component.name}_StreamTests ALL
COMMAND ${component.name}_StreamTests
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
)Basic idea:
Add to CMakeLists.txt
add_custom_target(run_${component.name}_StreamTests ALL
COMMAND ${component.name}_StreamTests
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
)Alexander David HellwigAlexander David Hellwighttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/CarLang/-/issues/1Sensor Menagement2019-08-28T10:34:01+02:00Evgeny KusmenkoSensor MenagementCurrently when a vehicle is constructed, all available sensors are added to it. However, in a continuous simulation we will need to test different kinds of vehicles in the same scenario.
1. Please add a possibility to define sensors as ...Currently when a vehicle is constructed, all available sensors are added to it. However, in a continuous simulation we will need to test different kinds of vehicles in the same scenario.
1. Please add a possibility to define sensors as part of the car model.
2. Make sure that only the required sensors are added to a vehicle upon vehicle construction
An overview of the available sensors is available in https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/tree/master/sensors/src/main/java/sensors
have in mind that more and more sensors will be added over time; this should not affect the Car language, i.e. if a new sensor is added, we do not want to have to change the Car language.
Therfore, consider extending the sensor interfacePascal Maurice PortaPascal Maurice Portahttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/12PhysicsEngine does not check collisions of cars2019-02-26T13:58:41+01:00Michael OsetinskiPhysicsEngine does not check collisions of carsIn `simulation.vehicle.PhysicsEngine` is a method `computeCollision()`, which should compute collisions of a car with physical objects. The check for a car is wrong in this line: https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simu...In `simulation.vehicle.PhysicsEngine` is a method `computeCollision()`, which should compute collisions of a car with physical objects. The check for a car is wrong in this line: https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/blob/master/vehicle/src/main/java/simulation/vehicle/PhysicsEngine.java#L77 . As the comment says, collision should not be computed if the object is not a car, but the actual code does not compute collision if it IS a car.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/server/-/issues/13Refactor to Visitor Pattern2019-10-09T10:52:38+02:00Evgeny KusmenkoRefactor to Visitor Patterndouble dispatch to be refactored to visitor pattern, e.g. for collision detection in vehicle.PhysicsEngine classdouble dispatch to be refactored to visitor pattern, e.g. for collision detection in vehicle.PhysicsEngine classhttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/server/-/issues/12SimLang integration should use longitude+latitude2019-08-28T10:35:06+02:00Evgeny KusmenkoSimLang integration should use longitude+latitudenow, the simlang provides starting and target postitions for verhicles in terms of a simulator internal format.
there are several issues with that:
* this makes the simlang dependent on the impl of montisim.
* thi smakes simlang unsuita...now, the simlang provides starting and target postitions for verhicles in terms of a simulator internal format.
there are several issues with that:
* this makes the simlang dependent on the impl of montisim.
* thi smakes simlang unsuitable for testing , particularly in an automated continuous simulation toolchainEvgeny KusmenkoPascal Maurice PortaEvgeny Kusmenkohttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/CNNArch2Gluon/-/issues/1Move to Gluon backend2019-01-29T15:36:24+01:00Evgeny KusmenkoMove to Gluon backendSebastian NickelsNicola GattoSebastian Nickelshttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/RMIModelServer/-/issues/2Investigate generation of autopilot adapter2019-10-09T17:58:44+02:00Evgeny KusmenkoInvestigate generation of autopilot adaptercurrently the autopilot adapter is quite simple and most of the code is hard written
please check how the generator can be extended so that a suitable adapter (+ jni calls + (rmi interfaces)) are generated automatically and do not need ...currently the autopilot adapter is quite simple and most of the code is hard written
please check how the generator can be extended so that a suitable adapter (+ jni calls + (rmi interfaces)) are generated automatically and do not need to be adapted manually whenever the interface of the autopilot component is changed
@markus.bauer can show you how the ros generation process works. maybe it makes sense to omit the tagging stepJean MeuriceJean Meuricehttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/languages/EmbeddedMontiArcDL/-/issues/5VersionUp: Full name of instances are missing package prefix2019-01-09T16:09:04+01:00Alexander David HellwigVersionUp: Full name of instances are missing package prefixAlexander David HellwigAlexander David Hellwighttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Middleware/-/issues/17Flatten: only for a given number of subcomponent levels2019-01-17T12:26:51+01:00Alexander David HellwigFlatten: only for a given number of subcomponent levelsIdea: add new method with additional parameter: int level
Add to check for atomic component: level == 0Idea: add new method with additional parameter: int level
Add to check for atomic component: level == 0Philipp GörickPhilipp Görickhttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Middleware/-/issues/15Vergleich der Clustering Algos mit zufälligem Clustering(Monte Carlo)2019-03-12T20:34:42+01:00Alexander David HellwigVergleich der Clustering Algos mit zufälligem Clustering(Monte Carlo)Dinh-An HoDinh-An Ho2019-03-14https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Middleware/-/issues/14Simple name while resolving Port2019-01-10T14:43:34+01:00Alexander David HellwigSimple name while resolving PortPhilipp GörickPhilipp Görick