I am getting ahead of myself on this topic but maybe there are others who have dove into this possible combination already?
Velodyne Puck LITE lidar is light weight and has some impressive specs on paper.
I am wondering if RTK integration, using reach, would be an easy or difficult task. The wiring diagram shows GPS PULSE and GPS REC as seen below.
I think it would be a lethal combination! If anyone has any input or experience that would be great!
I do not see any issue in integrating them, but what would be the final goal? RTK in city is very challenging.
Point cloud data that would not require georeferencing would be useful as complimentary data sets for use with scanners such as Leica MS50 and the C & P series. Not requiring registration or targets would be awesome.
Deformation of concrete walls or structures, slope stability monitoring of open pit mines. A rover mounted set up for monitoring deformation of roadways.
Many of those applications you wouldn’t necessarily need accurate position but when the data is part of turnover packages it will be required.
Plus i just think it would be really cool! 
Now if we could only get a light weight, cheap FOG IMU!
Just about to post a new topic on this but I may as well continue this one…even though it’s almost a year old.
Wondering if anyone out there has successfully integrated this to make their own UAV mounted LiDAR imager?
I want to add this functionality for my business. Photogrammetry is great for certain applications, and under the right conditions, but the fine detail and consistency of a LiDAR, combined with vegetation penetration adds new possibilities.
The problem is that UAV lidar systems run anywhere from $40-150K.
After going through the DJI integration guide here it certainly seems possible to develop your own system.
From my own simple viewpoint it seems like you only need a gps module, IMU, and computer to process/store the data.
And seeing as the reach modules play nice with pixhawk, that could be used as the IMU.
I may bite the bullet and undertake the very expensive experiment of doing my own integration with a velodyne puck, reach module as GPS (and set of RS as base and GCP…or even using an RS on the UAV as the rover if payload/space allowed for it), pixhawk as IMU and a micro PC like a Zini.
However…before I do that I would love to know if someone else has tried (and succeeded or failed), or if someone more experienced than myself might have some words of advice or caution.
thanks!
I happen to be flying a Puck Lite myself as well as owning some Reach modules. Lidar poses a lot of challenges. In reality, no RTK gps is accurate or fast enough by itself. RTK does work with a good IMU though. The two need to work together. The IMU’s used on our autopilots are not “good” IMU’s lol. Good enough to fly, but you need good enough to sense the rotation of the earth good : ) Another thing to remember, even with a good L1L2 setup, we still have times that we get a poor position solution. In that case we rely on the quality of the IMU and being able to post process in Inertial Explorer. Basically, Lidar is isn’t easy. Sad but true. So while the Reach is a great setup, you would need something like a KVH fiber optic gyro. You getting back up to the mid 5 digit cost realm.
So how have you integrated the puck?
Would you NEED a FOG IMU, or would a high(ish) end MEMS IMU do the trick? such a thing could be had in the 4 digit range, and several of the integrated systems that I’ve researched are utilizing MEMS IMU.
32 MEM IMU’s a better result based on consensus processing?
From what I know, a full Mobile Lidar system (rotating laser + good IMU + RTK) start at 80.000 € and can go up to 300.000 if you go to a famous Austrian laser provider.
There is room for a choice of good components if you build it yourself !
Hi, so have any of you have gone forward with the Velodyne Puck integration?
First of all I’m kind of noob when it comes to Linux so I’m sorry if my questions are stupid.
I have an original reach module and I have most of the Integration with Velodyne VLP-16 working (I still plan to integrate IMU but that will happen outside of reach module where full GPS information will be considered). But I still have a small (I hope) problem remaining.
For PPS I wrote a small c program that does Interrupt driven GPIO swap between mraa 13 (GPIO128) and mraa 32 (GPIO 46). The program also reads GPS sentences from localhost:9001. It then filters out all but $GNRMC which I then change to $GPRMC (what the puck wants for time) and recalculate checksum. I then write (at PPS low) this modified NMEA sentence to /dev/ttyMFD2 which is then connected to the puck via TX pin. (The TX signal goes through a SN74LS04N to invert it just prior to actual connection to puck).
The PPS signal works and the puck shows “PPS: Locked” however the sentence output from the program only goes to the console. If I redirect the output of the program to /dev/ttyMFD2 the NMEA sentence then makes it to the puck and all is good. I suppose I could just live with it as-is but it bugs me that I have to do it this way. I don’t understand why I have to redirect the output of the program to /dev/ttyMFD2 when I wrote to that in the first place inside the program.
Why is the sentence going to console when I specified /dev/ttyMFD2 in the program? Also why does redirection work outside of program but not directly inside program?
Hi @catstitan,
Can you clarify the following questions, please?
Hi andrew,
Directly to /dev/ttyMFD2
It does but I can’t seem to write directly to it from within my c program.
I have Position output 1 off and output 2 set to TCP Server localhost 9001 NMEA.
I log into Reach console via putty SSH port 22
I’m using the latest firmware v2.16.1.
In my c program called “LaserSupport.c” I can read from TCP port just fine.
I use the following code to try to write a NMEA $GPRMC out to the COM port (changed from NMEA $GNRMC).
int ComOut;
char *portname = "/dev/ttyMFD2";
static void SetupComPort()
{
int ComOut = open (portname, O_RDWR | O_NOCTTY | O_NDELAY);
if (ComOut < 0)
{
Log ("error %d opening %s: %s\n", errno, portname, strerror (errno));
return;
}
SetInterfaceAttr (ComOut, B9600, 0); // set speed to 9600 bps, 8n1 (no parity) etc...
}
static void WriteComPort(char * str)
{
int len = strlen(str);
int sent = write (ComOut, str, len);
if (sent != len)
Log ("WriteComPort error sending '%s' wanted to send %d but only %d went\n",str, len, sent);
}
When I run “LaserSupport” the output from the write statement above just goes to the console not to the COM port.
If I run “LaserSupport > /dev/ttyMFD2” the output then goes to the COM port.
Yes
Hi @catstitan,
We don’t recommend to install on Reach any 3rd-party software, as in this case, we can’t be responsible for the correct operation of the device and its support.
Thanks.
Really? Then what is the point of this forum/thread? Unless you do the work I have already done and make it part of your distribution firmware there is no way to integrate the Reach module with any of the Velodyne LiDAR units.
I am going to ignore your advice and move forward without your support. Oh and since you don’t don’t care to support anyone on this thread you might as well remove all of my posts as well.
Thanks for nothing.
Wow really?
You changed the programming from a manufacturer who recommends against this. Why is it their fault they can’t help you???
I changed nothing. I added additional support that wasn’t provided by the manufacturer. For example the manufacturer does NOT provide support for PPS to an eternal pin. Without this you can’t time sync the puck. Also the manufacturer only provides $GNRMC NOT $GPRMC which the puck only knows how to read time info from. While the $GNRMC could be dealt with externally the PPS issue cannot be.
Besides there are other posts on this forum that specifically advises to do exactly as I have (in regards the PPS signal). So what’s the big deal now?
Nothing I have done interferes with the normal operation of Reach. I was only asking why I couldn’t write directly to the com port and only redirecting the output from my app works. Which is probably more of a Linux issue anyways.
If you know of a way to get the PPS signal out to a pin without running some code on the Reach module please share it.
If this forum is not about Hardware integration and the manufacturer has no intention of providing any support for doing so why have this forum in the first place?
Maybe so we can help each other do it? At least I tried to help the other 2k+ viewers that are interested in doing so. What help have you provided?
Sheesh…
@catstitan I think you are free to hack away on your Reach device.
If you are doing something that knowingly breaks the ReachView software (i.e. taking control of a serial port that is used by ReachView), then you can’t expect the authors of ReachView to help you do that. Not to mention that the next ReachView software upgrade might break your program or reset that part of the filesystem and wipe it out.
Maybe if you left the serial port alone and connected with Ethernet over USB and ran a TCP server for your program output, then it wouldn’t be affecting the operation of ReachView.
Now I can understand if you don’t want to approach it like that. It might cause you to need additional hardware to convert back to RS232 or TTL output.
You could also make a feature request to Emlid, and then if at some point they fulfill it, you won’t have to use your hack anymore.
And by the way, if you are writing to the serial port, make sure that is it not in use by another program ( lsof | grep /dev/ttyMFD2 ) and also make sure that your program user has either ownership, group rights, or permission to use that port. Good luck!