Intermediate-to-advanced user here. I’ve been doing photogrammetry and equipment integration a few years and finally had the chance to fly some tests over our calibration site with the Elanus Duo fixed-wing plane, Emlid M2, and Sony RX1RII (global leaf shutter) full-frame camera. With quality equipment, especially the camera, I expect pretty excellent results. Right now I’d classify my results as “good.”
Primary Problem: Image location accuracy in the direction of flight is poor. I can attribute this to one thing only; timing error.
Data supporting my analysis of the problem:
The Sony RX1RII has a leaf shutter that can flash-sync at all shutter speeds. In this case at f/4, I was running shutter at 1/3200 and ISO was not above 250. Good, sharp, crisp photos. Shutter feedback to the M2 that was collecting all constellations at 10Hz and average groundspeed was about 17m/s. Firmware was 28.1. RS2 was on-site for sub-km baseline.
This calibration flight was conducted in a double-grid at 120m and two additional altitudes (90 and 60m)for extreme model rigidity and confidence. Matching results are excellent and control matches with low error. Maximum lens distortion residuals are <0.5 pixel.
Two flights using different antennas BOTH showed the problem
Allowing “Adjust INS/GPS offset” in metashape optimizes a difference of about 25cm in the Y (flight direction axis). Again, both for the included helical antenna AND a higher gain tripod antenna (Ardusimple calibrated AS-ANT2B-CAL-L1L2-15SMA-00). The helical antenna is surveyed to about .4m behind the camera, and the Ardusimple is directly over the camera center.
Results are nearly identical when processing in Emlid Studio and Inertial Explorer, although I have a lot of double-events when processing the UBX through Inertial Explorer (IE). I’ve instead taken the timestamps from Emlid Studio and used them for events in IE.
Also out of 1250 photos in each flight, about 5 were missing timestamps. Luckily ardupilot was able to grab them or it would have been a nightmare to identify the photos with missing position data.
I analyzed your logs from both setups. The first setup contains 1251 timestamps, the second one - 1246 timestamps. I see all these timestamps in RINEX files in both cases. I also noticed that there are CSV files from Pix4D. They also have a different number of timestamps. Hence it looks quite strange to me.
Can you tell a precise number of photos in both setups? It’ll help us with the investigation of this issue.
1246 and 1254 “airborne” photos respectively. There could be some events before or after the flight that I didn’t count. The 00000018_Cam.xlsx and 00000022_Cam.xlsx files compared the PPK results to Ardupilot’s timestamps to identify the missing events.
I forgot to mention that I am also using the emlid hotshote connector and cable with one minor change in that I soldered another wire to the feedback wire to connect to the flight controller feedback pin.
I noticed quite strange details. Timemark’s quantity is more than the photo’s quantity in the first setup. In the second setup, it is the opposite. It’s possible that a manually modified cable could cause this issue.
Could you share photos of your hardware setup? We need to look at it for further investigation.
The photo quantity was airborne photos only; according the logs, there were 7 photos taken on the ground prior to becoming airborne in the first mission.
I don’t have pictures; is there any more information in the logs?
How many photos were made in this setup totally? I mean, including these 7 photos. If the total number equals 1251, everything works correctly. You can geotag all the photos and then remove the ones taken on the ground.
If you don’t have these photos anymore, you can cut the log to get rid of extra time marks. You can do it with Logs duration in Emlid Studio according to the beginning time of flight. I attached two screenshots as a prompt.
The .xlsx and .csv files in the shared folder contain the ardupilot-logged images. While they do not start logging at the same time, they should match, especially once airborne. That’s why I “discard” images taken on the ground prior to flying in my image counts. It gives us a consistent starting reference. There were 1246 “airborne” photos in the first mission and 1254 “airborne” photos in the second. After trimming off the ground photos, we’re missing timestamps in both missions. Ardupilot picked these up.
For the first mission, I’m missing two timestamps. Between 586331.455/586333.855 (seconds of week) AND between 586824.722/586827.552.
For the second, I count 11 missing timestamps. Around the following times (recorded by the autopilot, not by the reach).
589595.9
589841.9
589865.8
589946.6
589955.9
590027.9
590035.9
590107.9
590111.9
590117.9
590243.9
Most likely, missing timestamps are caused by the manually soldered cable. If possible, I’d suggest you record timestamps with the original cable and share results with us.
The cable is literally the same cable with one spot in the middle that the insulation was stripped and another 22ga 10cm wire was connected to it that goes to a GPIO pin of the autopilot. I don’t see how another sensor on the line should interfere with this, and it is necessary as a backup and to validate that the system is triggering as it should in flight.
Let’s discuss both setups separately and skip Ardupilot’s data for now. I understand that it shows the right number of photos, but Ardupilot doesn’t affect Reach’s data anyway. And we need to find out if there issues with Reach itself or not.
For the first setup:
1251 timestamps in the Reach’s log in the first setup
1251 photos in the first setup, including “airborne” and “ground” photos
If it’s correct, Reach works properly in this case.
For the second setup:
1246 timestamps in the Reach’s log in the second setup
1254 photos in the second setup, including “airborne” and “ground” photos
We found out that there were missing timestamps in the log in this case. Most likely, this issue can be caused by a modified cable. Even if changes didn’t affect time mark pin, we can guarantee proper work with the original cable only. That’s why I asked you to test it.
