[Ryan B]

Hello,
Thanks for your interest in OpenMMS, we really appreciate it! Please use the Contact Form below or the Chat interface (orange bubble) in the bottom-right corner to get in touch with us.
Thanks again,
Ryan

[Ryan B]

Hi Francesco,

Your observations regarding the serial data being transmitted from the APX-18 to the Raspberry Pi computer are correct. However, this serial data stream is only used for Quality Assurance purposes immediately following data collection with an OpenMMS sensor (ideally while the operator is still in the field). I’m hopeful that viewing the OpenMMS Software Flowchart, found here, may help in your understanding of ALL the datasets collected by an OpenMMS sensor. Stated a different way, this serial data stream does not contain the low-level ‘raw’ GNSS and IMU observations from the APX-18 sensor. Those observations are stored directly within the built-in ~8GB of storage on the APX-18 itself. After completing data collection, the operator connects directly to the APX-18 via an ethernet cable and uses a web browser to navigate through the APX-18’s WebUI and download the respective .T04 binary file (see here for more details). All the ‘raw’ GNSS and IMU observations are contained within this .T04 file which is imported into the Applanix POSPac UAV post-processing software application, and processed with GNSS reference station data to produce the Smoothed Best Estimated Trajectory (SBET) ASCII file (see here for more details). It is this exported trajectory file that is then utilized within the OpenMMS software suite to produce a true colour georeferenced point cloud.

I hope my explanation helps your understanding of the GNSS+IMU data processing involved with the OpenMMS v1.3 solution.

Thanks for your interest in OpenMMS and for the question!

Ryan

[Ryan B]

Hi Luka,

Thanks for starting this topic! I am very pleased to see the community’s response to and interest in the OpenMMS v2.0 R&D. For complete transparency, I am in the final stages of my geomatics graduate studies work at UF which occupies >90% of my time and energy, so progress on the v2.0 R&D is going to be slow for at least the next few months. That being said, here are the planned initial R&D tasks:

1. Modify the existing aluminum case design of v1.3 to enable the installation of the Livox Horizon lidar sensor. Thankfully the wiring of the Horizon is practically identical to the Mid-40 so connecting the Horizon to the internal circuitry requires no additional modifications.
2. Modify the existing openmms_controller_livox.py to enable the collection of the raw IMU observations from the Horizon sensor.
3. Update the respective lever arm offsets for the new lidar sensor and perform an in situ boresight calibration for the lidar sensor and Sony mapping camera.
4. Collect and process datasets (using the existing OpenMMS post-processing workflow) to verify the accuracy and performance of the new Horizon lidar sensor.

These preceding steps will establish a baseline accuracy and performance reference for comparing and quantifying the proposed trajectory solution produced using the Livox IMU and the Emlid GNSS sensors.

5. Temporarily install the Emlid Reach M2 GNSS sensor and Tallysman GNSS antenna on the outside of the OpenMMS case and estimate the respective lever arm offsets.
6. Operate the Reach M2 as a standalone sensor (using the ReachView app) and collect raw GNSS observations at the same time as collecting data using the OpenMMS sensor (i.e., GNSS + IMU observations from the Applanix APX-18 and lidar + IMU observations from the Livox Horizon).
7. Explore using NovAtel’s Inertial Explorer Xpress GNSS-INS post-processing software to generate a trajectory using the raw GNSS observations from the Reach M2 sensor and the raw IMU observations from the Horizon sensor.
8. Compare and quantify the new trajectory against the APX-18 reference.
9. If the suitability of the new trajectory solution is confirmed, then the next round of R&D will focus on the hardware integration of the Emlid Reach M2 GNSS sensor within the OpenMMS case and electronic circuitry.

If the IMU observations from the Livox Horizon prove to not be of satisfactory quality, then other standalone IMU sensors can be explored using a similar approach.

Also… finding, leveraging, or developing a robust, rigorous, open-source post-processing GNSS+IMU software solution is a big goal of OpenMMS and will always be kept in mind within the v2.0 R&D. Any help from the community on this goal would be greatly appreciated!

Thanks for reading,

Ryan

[Ryan B]

Hi Giulio,

Thanks for your interest in OpenMMS. I have replied to you via email.

-Ryan

[Ryan B]

Hi Luka,

Thanks for the information regarding the issues with the 3D model embedded within the website. I will look into creating a ‘better’ assembled model for the current case design, and make it available for viewing and directly downloading.

There is no problem with the current case design; however, it has been designed to be constructed out of aluminum. I imagine there would be some structural integrity/rigidity issues if the current v1.3 case design were made using PLA/ABS 3D printed parts. The ‘new’ case design I mentioned would be optimized for 3D printing using carbon fiber infused PLA filament. It would be similar in concept to the case used for the v0.9-Beta OpenMMS sensor, as discussed here. The unknown Gremlin/force that plagued the v1.2 sensor design did not have to do with the case material. The v1.2 case was also machined out of aluminum. I believe that the issue resulted from positioning the GNSS-INS sensor in too close of a proximity to the main power circuitry inside the aluminum case. The 3D printed case used within the v0.9-Beta system actually proved to be very rigid and we experienced absolutely no issues with it, besides the case being rather heavy.

Thanks for your continued support!

-RB

[Ryan B]

Hi rmb,

I do not have any first-hand experience with the Livox Mid-70 lidar sensor. I did read through the online user manual and I agree that the Mid-70 does not include an internal IMU. The sensor appears to be very similar to the Mid-40, but with a circular field of view of ~70 deg. Besides the inclusion of an internal IMU within the Horizon sensor, the other primary differences between the two sensors are the field of view, angular precision, point rate, and weight. It really comes down to the application(s) you have in mind for the sensor that will ultimately determine which one is best. Hope this helps? Please let me know if you have any other questions.

Thanks,

-RB

[Ryan B]

Hi Luka and Andrew,

Thanks for adding to the discussion on an Applanix alternative GNSS-INS sensor for OpenMMS. Luka, you stated, “the goal of the open project is to have a free solution that can go toe to toe with commercial solutions”, and you are 100% correct! Practically all of the commercial UAS-Lidar solutions utilize commercial off-the-shelf (COTS) sensors within their imagery and/or lidar-based mobile mapping systems. OpenMMS takes the exact same approach, grab a bunch of commercially available sensors, and integrate them to produce a mobile mapping system. However, OpenMMS attempts to do so with complete transparency, and in such a way that interested users can potentially add their own ideas to the baseline implementation. Hopefully I’m right!?! I am in the process of investigating alternative GNSS-INS sensors to replace the Applanix APX-18 sensor currently being used. Luka, I just posted a somewhat detailed ‘future of OpenMMS’ response to your General Discussion Forum question, you can read the response here.

Understandably, when the concept of mapping is discussed, most often X,Y,Z coordinates are the first thing that comes to mind. It has become common knowledge that if accurate and precise X,Y,Z coordinates are required, RTK GNSS is the solution, which is not wrong. However, when it comes to lidar-based mobile mapping systems (i.e., dynamically moving mapping systems) having the accurate and precise X,Y,Z coordinates of your mapping sensor(s) during a data collection mission is only one half of the problem. The other half is having accurate and precise orientation (aka. attitude) values for your mapping sensor(s), and of course the solution to this is an IMU. Because the lidar sensor is observing features of interest that are some distance away from itself, it is the combination of the lidar sensor’s X,Y,Z coordinates, the orientation (i.e., direction) of the observing laser, and the measured distance to the feature that all factor into the accuracy and precision of the X,Y,Z coordinates calculated for the mapped feature. As lidar observations increase in distance, the more impact the orientation values have on the feature’s calculated coordinates. Hence, using reasonable quality IMU sensors is important. I hope this helps to better explain the roles of the GNSS and IMU sensors from the perspective of mobile mapping. Please let me know if you (or anyone else reading this) have any questions.

Thanks again,

-Ryan

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

[Ryan B]

Hi Luka,

Thanks for the positive feedback regarding the project, I really appreciate it. Hopefully over time more interested users will join the OpenMMS project, as creating a community is the top long-term goal of the project. I’m pretty sure we are all in agreement that lidar technology is only just beginning to emerge on a societal scale (self-driving cars, iPhones, UAV/drones, etc.) and the applications for the technology are endless, IMHO!

Regarding the state of the project, I feel a bit of background is necessary. The OpenMMS project materialized as a result of the academic research I have been conducting in an effort to complete a graduate degree in geomatics at the University of Florida (fingers crossed I’ll be done by mid-2021). However, my academic goals were the catalyst for the project and do not define the project’s scope. Meaning, the OpenMMS project is here to stay…indefinitely! Even if a community never emerges, I will still be actively researching the areas of lidar, photogrammetry, GNSS, INS, and eventually SLAM and AI. Slowly, but surely, new hardware integrations and software applications will be added to the project, along with improvements to the current solution. I can only hope others will decide to join the project!

At the top of the OpenMMS R&D list are the following ideas. Unfortunately, I do not have any time estimates for when these developments will begin.

1. Modify the current OpenMMS aluminum case to support the installation of a Livox Horizon ($800) and/or Avia ($1600) lidar sensor. I have purchased a Horizon sensor already.

2. Explore using an Emlid Reach M2 GNSS receiver ($500) in combination with a Livox Horizon or Avia lidar sensor as an alternative GNSS-INS sensor solution. I have purchased an M2 sensor already. The M2 will acquire the raw GNSS observations and provide the timing reference for the mapping camera photos and lidar observations, and the internal IMU onboard the Horizon or Avia will acquire the raw accelerometer and gyroscope observations. It would still be a post-processed (PPK) solution and therefore would require the use of GNSS-INS processing software. NovAtel’s Inertial Explorer Xpress or possibly Aceinna’s OpenIMU software ecosystem could be used. The ultimate goal would be to find/develop a 100% open-source GNSS-INS processing software.

3. Investigate using a ByNav A1-3H GNSS-INS sensor ($700) as an alternative to the Applanix APX-18. It would also still require the use of GNSS-INS processing software.

4. Develop an alternative OpenMMS case design that utilizes 3D printing rather than CNC milling. The goal is to provide a more accessible means for interested users to produce the needed hardware components.

We just recently submitted our first manuscript to an academic journal. If the paper is accepted I will surely be posting a News announcement here on the website.

All the best,

-Ryan

• This reply was modified 3 years, 10 months ago by Ryan B. Reason: poor formatting

[Ryan B]

Hi ard,

Thanks for the positive and encouraging feedback! There is a lot of information presented within the Documentation section of the site, but hopefully, it proves useful to you (and others). Please let me know if you have any questions.

-Ryan

[Ryan B]

Hello Marcel,

Thanks for taking the time to read and learn about the OpenMMS project. The current OpenMMS hardware (v1.3) only supports using the Applanix APX-18 GNSS-INS sensor. By supports, means that the OpenMMS documentation describes (in great detail) how the aluminum case and printed circuit boards need to be manufactured to physically integrate the APX-18 sensor into the OpenMMS hardware, and how the post-processing software workflows utilize the collected GNSS-INS data from the sensor (requiring the use of the Applanix POSPac UAV software).

For your reference, the latest pricing information I have for a single APX-18 sensor is (subject to change, contact Applanix directly for up-to-date pricing):

– APX-18 Sensor [Quantity 1]: $19,750 USD
– Trimble AV14 GNSS Antenna [Quantity 2]: $990 USD
– POSPac UAV Software (12 month maintenance) [Quantity 1]: $862 USD

For a total of $21,602 USD which accounts for 80% of the total OpenMMS hardware cost if using a Velodyne VLP-16 lidar sensor ($3,999 USD), or 91% of the total OpenMMS hardware cost if using a Livox MID-40 lidar sensor ($599 USD).

One of the long term goals of the project, is to, “entice sensor manufacturers to want their products to be integrated into the OpenMMS project, thus providing different accuracy and cost options for users and, in turn, new customers for the manufacturers”. However, no other GNSS-INS sensor manufacturers have yet expressed interest in having their sensor(s) integrated into the project. Of course any GNSS-INS sensor with appropriate size and weight characteristics can, in theory, be integrated into the OpenMMS project, but would likely require modifications to the case design and printed circuit board designs.

Stay safe!

-RGB

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

[Author]

Posts