That is a good question. First I have to assume you are talking about a Velodyne LiDAR unit because I am not familiar with others. (They may or may not have the same requirements). Having said that the primary difficulty with integration is synchronized timing of the different devices. The second issue is orientation. You’ll need a high quality IMU for that. The Reach M+ seems to have PPS output and thus it’s possible to use that via some kind of clock buffer to split the PPS signal from the M+ to both the IMU and the LiDAR. The third difficulty is the GNSS. There are 2 issues with the GNSS; 1) the polarity of the TX signal and 2) whether $GPRMC or $GNRMC is being sent. I don’t yet have a M+ module but I assume it is the same as the original Reach module in these 2 GNSS issues. So you will have to invert the the polarity of the TX signal via a Logic NOT gate and you will have to replace/convert the $GNRMC to $GPRMC. The issues regarding PPS and GNSS must be dealt with or the Velodyne puck won’t be able to sync to and recognize time from the reach module. Once you have the Puck locked on good GPS coordinates it will also have good time (in microseconds past the hour). Now you just need to get orientation data from the IMU. Given data that is all synced in time you should be able to pull everything together to build a nice point cloud that you’ll then need to save in a format like LAS that you can then review in something like CloudCompare.
Here’s the problem I see with trying to use the Reach M+: While it can (seemingly) output PPS it does not output $GPRMC (I assume). It outputs $GNRMC (like the original Reach module). The problem is that the Velodyne puck does not recognize $GNRMC so it can’t get time from it. It might be possible to convert the $GNRMC outside of the module but then you are faced with a potential timing slip (due to the amount of time required to do the conversion). That tiny little slip can easily cause really ugly results in the final point cloud.
Hopefully someone will correct my assumptions about the Reach M+ because I would like to try it without having to run custom code on it to modify $GNRMC. Which even if I did I still might have to deal with timing slips as I am now experiencing with my custom code running on the original Reach module.
An ideal situation would be that the puck would recognize the $GNRMC. Maybe Velodyne will accommodate?
The first 2 letters after the $ sign in the NMEA message is the Talker ID and indicates the nature and source of information:
GP: GPS; GL: Glonass; GA: Gallileo; GN: combinded GNSS systems
(defined in the NMEA specification)
The u-ublox receivers can be configured how to use the talker IDs with the binary UBX-CFG-NMEA message.
In order to get GPRMC messages the Main Talker ID has to be changed to GP(GPS).
However I’m not sure how this will effect the rest of the system. It may be that changing the Talker ID will disable the other satellite information.
So, I put in a request at Velodyne that they support $GNRMC as well as $GPRMC. I’m hoping that since the 2 messages are identical except for the “N” and “P” it should be little effort for them to support both. We’ll see…
I almost forgot…
There there is one other issue: The puck want’s PPS set to 1 per second and to only be sent the single $GPRMC that must end within 500ms of the PPS rising edge and they want it sent at 9600 baud. In my testing I have found that the puck can handle multiple different messages but they must end at the 500ms mark or the puck has trouble synchronizing. The Reach module (at least the original) is sending many different messages 5 times per second so at at 9600 baud they take longer than 500ms. This could be solved by either having Reach module NMEA message configurable (not likely since they need everything they are currently getting) or by the puck handling a higher baud rate. I’ll request that later if they decide to support GN as well as GP.