My team works with point cloud data taken from various (i.e. different manufacturers) LiDAR sensors, and process the data for a robotics application. Until now, we were using a development framework that included visualization tools, but we grew tired of some of its quirks and decided to stop using it. We are trying to decide on which visualization tools matches our needs best. Some of the options include Matplotlib, for example.
As an engineer with background in mechanics, I immediately thought of VTK and ParaView (I just used ParaView, for basic visualizations also).
One of our hardware providers got a visualization software called VeloView, developed in ParaView; however, it only works for their sensor and also it takes data directly from recorded logs, while we are interested in processing data with our tools and then visualizing the result.
I think ParaView has great potential for our application.
My questions are:
How much work would it take to get time-varying point clouds visualized in base ParaView?
Is it possible to have multiple processes running at the same time? (I ask because we had problems with PCL’s visualization kit, specifically an VTK dll, when doing multi-threading)
Could we create primitives based on data inside the cloud? (Not necessarily using paraview for computing, we would provide the dimensions and position of each primitive)
Sorry if its a bit vague. If anyone had experience with VeloView that would be great, since it is open source, so I think we could end up modifying it to our needs and use it for other sensors too.
Hello,
Kitware also develops VeloView.
We do offer custom development based on it, you can see some examples here: https://blog.kitware.com/tag/veloview/
Specifically:
How much work would it take to get time-varying point clouds visualized in base ParaView?
It depends on how your tools can save it. If you save one pointcloud per time-step, you can directly visualize this with the builtin time-varying functions of ParaView.
Depending on your data handling, writing a reader can be fairly easy, but we can discuss the details if you are interested.
Is it possible to have multiple processes running at the same time? (I ask because we had problems with PCL’s visualization kit, specifically an VTK dll, when doing multi-threading)
It depends what you mean by this. We successfully show multiple sensor data using VeloView in the past.
Could we create primitives based on data inside the cloud? (Not necessarily using paraview for computing, we would provide the dimensions and position of each primitive)
Glyphs seems to be what you are looking for.
First and foremost, thank you very much for your quick reply.
I have been reading your blog posts and it seems like it could suit our needs. Glyphs are definitely sufficient for primitive handling; as for multi-threading, I was refering to having, for example, window A with the point cloud, and window B with primitives. So, from a single source (single data-log) we would want to get 2 different visualizations at the same time (my guess is that this is possible by just using different filters in each window, but some of my colleagues think this would need multithreading); this cloud is time-dependant i.e. it comes from a moving robot.
I think the plugin system is exactly what will enable us to apply our own algorithms to the cloud. As for sensors, we use not only Velodyne but also Ouster, Sick and Scala (in particular, Scala sensors have a FOV of 145 degrees), but I guess it’s a matter of parsing data from different sensors to the VeloView input format (although different sensors have different fields, for example Sick sensor doesn’t provide reflectivity, while Scala uses echo pulse width instead of reflectivity).
I’m really excited for this tool and looking forward to becoming a ParaView expert
Will keep posting questions as I work my way through the development of this solution.
Paraview and VeloView both can show multiple views. Each view can be different data, or the same data display in the same way or another.
So Yes multiple visualization of the same data or different one is definitely possible.
We have extended experience in writing parsers for different sensors, that would be a fairly straightforward work for us, should you chose to get paid support from us.
I’m looking to do something very similar for my company – extending VeloView to be able to take file or stream input from our LiDAR sensor.
From what I can understand after going through the VeloView code, the approach that seemed best to me is to
Create base classes vtkBaseReader & btkBaseSource
Rewrite vtkVelodyneHDLReader & vtkVelodyneHDLSource to be derived from the above base classes
Write new derived classes myCompanyReader and myCompanySource to support data from the new sensor
Would you recommend a different approach? I’ve been struggling with the details of getting this working – the concept makes sense to me, but in practice there are numerous hurdles before the finish line.
The paid support you suggest as an alternative, is that the support product? Would the work (for your team) on a new sensor parser fit within the included hours limit?
The paid support alternative can be either through our yahoo store support product (we start coding as soon as paid), or through designing a Statement of Work together (expect some delay negotiating & signing paperwork). We have ongoing projects using each options.
Both ways, we would need your data packet specs to assess the amount of time needed.
Ah, I pulled down and was working on an out-dated copy of the code. Thanks so much for the tip on the code refactoring! I’ll take a look and let you know if I have any follow-up questions.
