I have a feature request to enhance the the location accuracy of the time marks of aerial images.
The problem: there is some delay between when the camera has taken a photo and when the time mark is captured. When the UAV is moving this leads to a constant offset, where the time mark is either ahead or behind the UAV depending on flight direction and speed.
This delay is measureable in post processing and could/should be adjusted by the onboard emlid unit. There should be an extra field in ReachView in the Camera control tab, where the user can input this delay.
How much improvement can we achieve? In my case I use a Sony A6600 and an Emlid M2 with the hotshoe adapter and my delay is approx. 17 ms. This means an error of 8,5 cm at 5 m/s flight speed, 17cm at 10 m/s, 25,5cm at 15 m/s and so on.
I am not sure how Emlid processes time marks. If only the exact time is saved, when the camera is triggered, than this would be possible.
However if the onboard unit already interpolates between two coordinates and then saves coordinates, than this could be more difficult in post processing, since a new re-interpolation would be necessary.
edit. Ok, I inspected the RINEX file from one of my surveys and it appears, that only the exact time is saved as a camera event. In this case the compensation could also be done with a simple script before post-processing, that simply subtracts the delay from the camera events.
To do that I had to do a flight with lots of GCPs and let Metashape calculate the offset between the antenna and the camera. I always fly forwards and got an error in flight direction, that is dependent on the flying speed. If I know the physical offset and the one that is estimated I can calculate the time delay based on flight speed (which I also know).
I do believe, that this error is coming from the camera. I have read on various camera forums, that people have problems with the flash being delayed on the Sony a6300. Maybe this problem persists on the a6600, which I have.
However it would still be nice to be able to compenate for this, since the delay seems to be constant (as far as I can tell).
Front Sync would be the best option on a typical camera, that isn’t designed for photgrammetry.
However, 17 ms seems way too long. considering that normal sync-shutterspeed for a camera is max 1/250s or 4 ms, this would means that the camera would miss the flash-pulse entirely, which never happens.
You could try rear-sync, just to see if there is any shifts in the delay.
It seems like the offset is indeed related to the camera specifics.
We’ve created a setup with Reach that would minimize such issues: as I’ve mentioned already, Time Mark Pin is connected to the GNSS chip directly so that there’s no delay on the periphery connections. This allows the time mark to be recorded with very high accuracy.
However, the shutter trigger time is dependent on the exact signal shape on the camera’s hot shoe. So the delay depends on the specific camera and shutter shape. This means the delay will be different for each setup which makes it difficult for us to address it.
This is correct. I have even gone to the point of collecting the entire GPS track without events, shooting two checkpoints and synchronizing with the photos. This gets the relativity to centimeter level and the time marks very close, but the ground control points override and place the map correctly. If this is for PPK then you can put an offset in RTKLIB.
Could it possible be rolling shutter related? Do you use rolling shutter option in Agisoft? Rolling shutter effects can destroy the type of accuracy you are trying to achieve. When I want cm accuracy I throw up a quad and map at 5 m/s.
Did you ever lay out a bunch of ground targets - in a flat field - and set them as Independent check points to test if this offset exists in actuality? If it exists it would show up as a constant offset. Just wondering.
I’ve never dialed in using time marks (although I want to) and still use traditional ground control point targets (and check points) for crucial surveys if I want to be more confident in cm accuracy.
I don´t think so. I manually set the shutter speed to 1/800, which is much less, than the 17 ms delay I get.
That is exactly how I found this problem.
It is most definiatelly the cameras fault, I was just looking for a feature, how I can compensate for this. In the meantime I have a Python script, that modifies the RINEX data with the time delay and am getting much better results with the compensated time marks.