[Ryan B]

Thanks for sharing this information with the community. I love learning about other interesting projects in this space.

[Ryan B]

Hi, Pierre.

Unfortunately I can’t read the detailed errors reported in your screenshot. This might be a laspy library issue. Try uninstalling laspy and reinstalling laspy v1.7 (e.g., pip install laspy==1.7).

-Ryan

[Ryan B]

Hi, ard.

Thanks for your question and interest in OpenMMS but unfortunately answering the question about whether or not specific GNSS/INS sensors would ‘work’ as replacements within OpenMMS is really several questions rolled into one, and very difficult to answer. The first thing I would look at is what are the position and orientation specifications for the sensor? OpenMMS is designed to produce a reasonable accuracy point cloud and the key component to achieving this is the GNSS/INS hardware and software solution utilized. For more information see this post, https://www.openmms.org/forums/topic/applanix-alternative/#post-894.

Cheers,
Ryan

[Ryan B]

Colourized point clouds (from lidar sensors) are realistically only produced by overlaying (simplification) images from RGB camera sensors onto the point cloud. Though I’ve read some interesting research somewhat recently on new approaches to this colourization problem.

-Ryan

[Ryan B]

Thanks for bringing this information to the community, derick. Hopefully the OpenMMS GNSS/INS post-processing solution will be 100% open-source, but highlighting what else is available within the industry via this forum is an excellent resource for many users.

-Ryan

[Ryan B]

Hello.

Unfortunately there is no simple answer to your question. I don’t mean to be vague, but there is no easy way to simply swap 1 sensor out for another. Voltages, communications protocols, physical size, interference characteristics, etc., etc. would all need to be considered to properly answer your question.

I’m happy to provide advice to as many very specific questions as you want moving forward.

Thanks,
Ryan

[Ryan B]

Hi, Traslavina.

Thank you for your positive and encouraging message. OpenMMS research and development has slowed down (ok, basically stopped) for the time-being but I still have big plans for tackling the GNSS/INS hardware and software problem that is necessary in order to substantially lower the cost of the solution. Ideally, the problem with be solved with a new, custom developed GNSS receiver(s) and IMU open-source hardware integration (using OEM sensors like the BD940 and STIM300) and open-source post-processing software. But it’s a big and complex problem so it’s going to take some time.

All the best,
Ryan

[Ryan B]

Hi, Zi.

Luka is correct in that the time and position information for each image captured by the Sony camera is not embedded within the JPG files’ EXIF metadata. What happens is the hot-shoe feedback sensor is wired into one of the Event Input pins on the Applanix APX-18 GNSS/INS sensor. Each time the camera captures an image a simple signal is sent to and detected by the APX-18 and an Event (basically a timestamp) is recorded within the APX-18’s binary .T04 file. As part of the post-processing workflow, a camera events trajectory file is generated as part of the Applanix POSPac UAV data processing step (see section 2.5 of the documentation for details). This trajectory file contains the precise timestamps and position and orientation estimates for each Event detected by the APX-18. Within the 7_preprocess_images script, one of the operations performed is that trajectory file Events are matched (simple sequential alignment) with the corresponding JPG files captured by the Sony camera during data collection and a new trajectory file is generated (see section 2.9 of the documentation for details).

I hope this helps your understanding of how the exterior orientation parameters for each image captured by the Sony camera are estimated within the OpenMMS solution.

Ryan

[Ryan B]

Hi, Michael.

The lever-arm offsets between the origin of the IMU frame and the origin of the lidar sensor frame are estimated based on the frame definitions provided within the documentation for each sensor and the high-precision 3D model of the CNC machined aluminum case. The lever-arm offsets between the phase centers of the GNSS antennas and the origin of the IMU frame are estimated using a laboratory calibration procedure (as described in section 12.9 of the hardware documentation, https://www.openmms.org/wp-content/uploads/html/openmms_hardware.html#calibrating-the-gnss-lever-arms). In an effort to simplify this calibration procedure for OpenMMS v1.3 hardware, an MS Excel workbook is provided that contains the embedded calculations for estimating the offsets based on the observations made during the procedure.

The boresight angles between the IMU frame and the lidar sensor frame are estimated using an in-situ procedure based on manually identifying planar surfaces in areas of the collected point cloud that were observed within overlapping flight lines (as described in section 2.6 of the software documentation, https://www.openmms.org/wp-content/uploads/html/openmms_software.html#lidar-sensor-boresight-calibration). The calibration procedure utilizes a parametric least-squares optimization of the RMSE for the planar surfaces to estimate the boresight angles.

These procedures have been tailored specifically to the OpenMMS project and therefore a bit of work would be required in order to generalize them for other mobile mapping sensors.

Hope this helps,
Ryan

[Ryan B]

Hello.

I am not aware of any other sources besides the DJI Store where you can purchase Livox sensors.

Sorry,
Ryan

[Ryan B]

Hello, Everyone.

Thanks for the inquiries into OpenMMS v2.0. It’s been a busy and stressful last 12 months, to say the least. Unfortunately, my research and work on hardware advancements, bug fixes, and other general improvements have not come to fruition yet. I hope to start dedicating time on a weekly basis to begin the hardware integration of the Livox Horizon lidar sensor (and internal IMU) and the Emlid Reach M2 GNSS sensor into the project. Once this is done, then the big task of developing an open-source GNSS-INS post-processing solution can begin.

I appreciate everyone’s continued interest (and patience)!

All the best,
Ryan

[Ryan B]

Hi Luka,

Thanks for the inquiry. Last day of grad school is tomorrow! I plan to start designing the aluminum piece to allow the Livox Horizon sensor to be installed within the current OpenMMS v1.3 case (objective #1 from above) next week. This will mark the official start of the R&D for OpenMMS v2.0! I will be posting updates as things progress.

Stay tuned,

Ryan

[Ryan B]

Direct Georeferencing (DG) simple means that the position and orientation of the mapping sensor(s) (ie., lidar or imaging) at the time of observation is estimated with respect to the position and orientation of a dedicated GNSS+Inertial sensor (ie., one or more GNSS antenna/receivers and an inertial measurement unit (IMU)). DG can be used anywhere with an adequate line of sight to the sky in order to make GNSS observations on any type of vehicle (ground or aerial-based). That being said, GNSS-Inertial sensors are designed to provide position and orientation estimates during periods of no GNSS observations (i.e., driving through a tunnel) but the precision of the estimates will begin to degrade when regular GNSS observations are unavailable. How quickly the estimates degrade is largely a function of quality of IMU being used within the sensor. Hope that helps.

One of previous videos showcases using OpenMMS being held in the hands of an operator and walking around an urban environment and mapping. See here, https://www.openmms.org/latest-openmms-video/

[Ryan B]

OpenMMS is a direct georeferencing solution and relies on a GNSS-Inertial sensor (i.e., the APX-18) for determining the positions and orientations (pose) of the lidar sensor and the Sony mapping camera. OpenMMS is planning on experimenting with SLAM-based processing in the future but currently does not support it.

• This reply was modified 3 years, 4 months ago by Ryan B.

[Ryan B]

Hi derick,

Sorry you are having difficulties with accessing the OpenMMS project data, but I have just (today) tested the download and extraction of the OpenMMS Tutorial 1 sample data from the Google Drive link using both a Mac and Windows-based computer, and everything worked perfectly. I don’t have a machine with a Linux distro currently spun up so I can’t more closely test your specific setup, but I haven’t experienced any problems with Debian when I was originally testing with it. Any way you can test using a different computer?

-Ryan

[Author]

Posts