OpenSimulationInterface / osi-visualizer

**This repository is abandoned and looking for a maintainer.** A tool to visualize OSI data from two different sources. Data can be stored in files and replayed afterwards, or validated using a Python interface.
Other
39 stars 25 forks source link

Add lidar point cloud to visualization of sensor data #32

Open MEpping opened 6 years ago

MEpping commented 6 years ago

I split up my previous pull request, so that now this pull request contains the point cloud only (while the other one contains only the win32 fixes). I'm sorry for the confusion.

pmai commented 6 years ago

This seems to add files glpointcloud.cpp and pointcloud.cpp, but does not add them to the relevant CMakeLists.txt file, which causes the build failure seen in the CI:

CMakeFiles/osi-visualizer.dir/src/glwidget.cpp.o: In function `GLWidget::GLWidget(QWidget*, IMessageSource*, QMap<ObjectType, QTreeWidgetItem*>&, AppConfig const&)':

/project/src/glwidget.cpp:49: undefined reference to `PointCloud::PointCloud(int, QOpenGLFunctions_4_3_Core*, QString const&)'

CMakeFiles/osi-visualizer.dir/src/glwidget.cpp.o: In function `GLWidget::MessageParsed(QVector<MessageStruct> const&, QVector<LaneStruct> const&, QVector<PointStruct> const&)':

/project/src/glwidget.cpp:605: undefined reference to `PointCloud::UpdatePointCloud(QVector<PointStruct> const&)'

collect2: error: ld returned 1 exit status

CMakeFiles/osi-visualizer.dir/build.make:701: recipe for target 'osi-visualizer' failed

make[2]: *** [osi-visualizer] Error 1

CMakeFiles/Makefile2:68: recipe for target 'CMakeFiles/osi-visualizer.dir/all' failed

make[1]: *** [CMakeFiles/osi-visualizer.dir/all] Error 2

Makefile:129: recipe for target 'all' failed

make: *** [all] Error 2

Please fix this...

haoyuanying commented 6 years ago

The Y in OSI stands for the left direction in bird view (X points to the sensor 0° direction, by default, on screen the red triangle points to).

MEpping commented 6 years ago

@haoyuanying: Are you saying the coordinate system is different from my comment: x: up, y: out of monitor, z: right? But your statement that Y points left on the screen cannot be true, because we set the y component to 0 and it works just fine. Maybe you mean that azimuth points counter-clockwise? That would be up to debate, but I think in the automotive context it is more common to interpret it clockwise...

haoyuanying commented 6 years ago

The Y I mentioned is in OSI, to transfer the Y in GL, it should be placed on the Z (GL) position...

MEpping commented 6 years ago

@haoyuanying I agree on your orientation of the coordinate system. I'm confused why you think your change of the sign is correct. Consider the following example, let me know at which point you disagree: "left" would be (0, 1, 0) in "OSI-coordinates". This corresponds to azimuth = -90, elevation = 0. This should be (0,0,-1) in "GL-coordinates". My original code gives (0,0,-1). Your code gives (0,0,1).

haoyuanying commented 6 years ago

Hello, from "left" would be (0, 1, 0) in "OSI-coordinates". This corresponds to azimuth = -90, elevation = 0." The left hand should be +90° in azimuth, in OSI.

MEpping commented 6 years ago

@haoyuanying Ok, so you are saying that azimuth is defined to be pointing counter-clockwise in OSI. While this is the usual definition in mathematics it is quite uncommon in navigation. Could you please point me to the relevant paragraph in the documentation? Because I was wondering about this issue before. If it's not defined in the documentation your change should be reversed. Would be interesting to hear the opinion of long time contributors like @pmai on this, too.

haoyuanying commented 6 years ago

@MEpping Please read through the osi_common.proto, before the definition of Orientation3D: // The preferred angular range is (-pi, pi]. The coordinate system is defined as // right-handed. // For the sense of each rotation, the right-hand rule applies.

MEpping commented 6 years ago

@haoyuanying Ok, I agree that the flipped sign follows the description in the proto-files. This will produce a lot of confusion, because, as I said, in navigation azimuth usually points in the other direction. See e.g. https://en.wikipedia.org/wiki/Azimuth. However, since the counter-clockwise definition is at least as popular we run into these problems anyways, I'm afraid. So we can stick with your code and change the sign of azimuth on the sending side where necessary.

haoyuanying commented 6 years ago

The comments in the proto files are Doxygen compliant, and, they should be treated as official documentation of OSI...

ghost commented 5 years ago

@MEpping I am back again from parental leave and can pick up where we left. I can offer to schedule a call here?

vkresch commented 5 years ago

For now this branch is paused because it didn't work with the newest osi-visualizer changes. Feel free to update the branch feature to the stable version of osi-visualizer.