Last year my team decided to fly the M2 as an independent logging system on our Matrice 600 Pro. The idea was that the pictures on our Micasense cameras would be timestamped correctly via the DLS2. Then after the mission, we could take the LLH log with it’s timestamps, and rewrite new geotags to the .tiff imagery by matching up timestamps with the nearest time.
However, we ended up with a problem. After plotting the geotags from the Micasense cameras, and the gps location stream from the M2 LLH file, the timestamps for a given location are wildly different. We have noticed a nearly consistent 19s time difference between an image and its closest gps datapoint.
We have noticed this consistent error with Micasense and an ICI camera. Is there a standardized way to use LLH to replace the geotags of already-geotagged imagery? And what could cause this time difference?
I am a novice to PPK/RTK geotagging, so please forgive my lack of knowledge.
I’m not familiar with the Micasense camera with DLS2. How do you integrate this with M2? Could you please share pictures of your setup?
Reach M2 can record time marks to the raw data logs with microsecond resolution relative to the signal on the camera’s hot shoe.
Also, I want to note that the time stored in the image’s EXIF is the creation date (the time it was stored), not the time it was recorded. Therefore, there will be a difference between when the image was taken and when it was written in the EXIF header.
The LLH file is the position log of the Reach device, and without knowing the accurate time of when the image was taken, I believe it would be hard to interpolate the time in the LLH and the image. Further, the drone’s GPS clock should also be synchronized with Reach M2 to make this work.
Thanks @ruth.bongon for the response. I’ll attempt to explain further.
The Downwelling Light Sensor (DLS2) is what is sounds like, but also has an integrated GPS+compass. It connects directly to the camera. That way, the only electrical connection between the camera and the drone is a power cable. The M2 was setup similarly, where the unit received power from the drone, but was not connected electrically in any way to the flight controller or to the camera.
I know how to correctly use the M2 now, after some experimentation this winter. We plan on configuring one of the GPIO pins of the Micasense camera to go high when it captures so that it can be recorded as an event by the M2. But right now, we have a year of imagery, and a year of .LLH files from the M2.
The logic behind this was that even though they are two separate systems, we could geotag the images retroactively using a Python script that searches for similar timestamps → writes the new location to the image metadata. However, we are running into a significant time delay. At first we thought the same thing as you, that the difference was because of the time between it captured vs recorded the image. But the camera is capable of 0.5s continuous captures, so we know the images are being recorded quickly.
In short, we are trying to figure out why there is a 19s delay between the M2 timestamp and the image timestamp when looking at the nearest geolocation between the two systems. I have attached images of this difference from QGIS software. I have also included the raw drone GPS log, and you can see that it matches up with the image timestamps, and not the 19s delay of the M2 LLH log.
Many thanks for the help if we can get this figured out!
You are a genius! We have been genuinely stumped on this for a while. Hopefully in the future it won’t be an issue as we revert to using Emlid studio, Rinex, and the standard hotshoe->event method as described in the documentation here.
