My GPS connects to the LiDAR’s interface box (use the ground, PPS, and Receive wires which connect to the ground, Sync-Pulse-In, and multipurpose_io pins respectively).
My system is running in ROS Noetic and I can visualize the LiDAR data by launching the driver.launch file. My issue comes from setting the parameters for the LiDAR to use the GPS. I am currently running:
After running this command, ROS visualizes the data but when looking into: (curl --request GET --url HTTP://os-.local/api/v1/time/ptp ) I see that the LiDAR is stuck in the LISTENING state. I looked at the metadata from my rostopic and saw that the multipurpose_io mode is not set to the parameter that I specified and rather it is set to “OUTPUT_FROM_ENCODER_ANGLE.” I also do not see this parameter in my driver.launch (I can see the timestamp parameter). Do I have a deprecated/incorrect version?
I have looked at other posts and cannot seem to find a fix for this. Notably, I have also checked the output from my Garmin GPS on an oscilloscope and saw the pulse working as expected. I checked the “Receive” as well and was able to see an output.
Any help would be greatly appreciated in trouble shooting ways to synchronize the GPS to the LiDAR. Thank you!
Hi @Snow-Svendsen this is not a parameter that the ouster-ros driver support currently. What I recommend in this case is to access the sensor configuration page directly set the multipupose_io_mode parameter INPUT_NMEA_UART value then save the configuration with persist.
Hiyas @Samahu thank you for the quick response. I have gone into the sensor configuration parameters and was able to set the parameters!
Now I am just stuck in the “LISTENING” state. I have been looking at the documentation for my Garmin 18x LVC, Ouster OS2 LiDAR, and other posts on this website (this one the most: Possible reasons that might cause PTP time synchronisation failure). No matter what I try, the GPS does not seem to be recognized properly by the LiDAR. (Notably, my “gm_present=false” and I am unsure how to change this). I would appreciate any ideas to solve this problem.
I am also happy to share my pinout configuration, oscilloscope readings, and LiDAR sensor configuration information if it would prove useful to this discussion.
Not sure if it helps but I recommend checking the firewall settings that it permits udp traffic on ports 319 and 320 (or just turn it off until you have this figured) plus check that the ptp profile in ptp4l.conf is set to either default or gptp as noted in here.
Thank you for the reply @Samahu !
My firewalls are down (my setup is in an offline network), and I have downloaded linuxptp and acquired the ptp4l.conf file. I do not see any parameter in this file that says "default or “gptp” but I have not made any changes since installation. My LiDAR remains in the LISTENING state. I will be reaching out to the Garmin Support team, but in the meantime, are there any other parameters I should look at to ensure GPS communication?
Note: I may purge the files and re-install linuxptp again to ensure the default is set.
So I have checked the documentation again and realized the polarity on one of my signals was set incorrectly. Now when I do [sudo tcpdump -i dst port 320] I get an output of [tcpdump: dst: No such device exists. I tried opening them manually and ensuring no firewall was up, but the command was still met with “does not exist.” I am not sure where to go from here. I have tried manually setting the parameter (to gptp and default from the command line) from the ptp4l.conf file, but my efforts have not made any progress. Any help would be appreciated.
I wanted to put these specs in here as well for reference:
I am setting up an Ouster OS2 LiDAR to use the clock from a Garmin 18x LVC GPS. I have currently set up the following parameters:
I have the white wire from the garmin plugged into the Multipupose IO pin, yellow wire from the garmin connected to the sync pulse pin. The GPS is also powered with 5V and grounded.
The LiDAR shows a blinking light on the multipurpose IO pin at a rate of 1s
You shouldn’t need to mess with ptp4l here as there is no PTP grandmaster running, just a PPS and NMEA source, so gm_present should be false.
To further debug you can inspect the output of the http://os-XXXXXX.local/api/v1/system/time/sensor endpoint. This contains PPS/NMEA related diagnostics including the last parsed NMEA message and count of pulses. If things are working you should see incrementing sync_pulse_in.diagnostics.count and multipurpose_ui.nmea.diagnostics.utc_decoded_count. You may have to adjust the NMEA plarity to ACTIVE_HIGH if you aren’t seeing decoded messages. Note some of these NMEA counts will not increment if you do not currently have a valid GPS fix.
If you share the response of this system/time/sensor endpoint we might be able to gleam what the issue is.
If things are working the output should look something like this:
