Hi, first time post here, hoping someone can give me some steer.
I have a few Reach M+ units in my fixed wing mapping aircraft and generally they are working very well and this is proving to be a great product.
However, recently I did a trial on a new aircraft and I found that the events file has far less events than I have images (around 546 images vs 465 events). I also did a check against the overall number of trigger points from the flight controller and can confirm it matches the number of images.
This is my setup/workflow:
Camera is a Sony QX1, triggered from flight controller, with feedback to Reach M+. The camera was modified (by another party) to enable feedback and there is a single cable which connects to the āTime mark1 - 2ā connector on the Reach M+). The signal from the camera is 2 milliseconds on high.
I am in the UK, so use Ordnance Survey base station data to generate the corrections and bring the data into RTKPOST processing, along with the obs and nav files from the aircraft. I then use the KML/GPX converter to generate the GPX file for the events, which I then bring into Geosetter for geotagging.
For this particular trial, I managed to get around the issue by Geotagging with the time offset method, along with the overall GPX track file (ie. all GPS points) and all seems OK, but would obviously prefer to use the events GPX file to geotag.
When you bring in the GPX track into Geosetter did you make sure that the checkbox for all points was selected. There is some sort of filtering going on in RTKPOST that can cause points to be deselected automatically in Geosetter. I am not sure what they are doing, but I suppose it is some sort of accuracy/corrections condition filtering.
Hi Michael, thanks for looking into this. I can confirm that all the events are selected in Geosetter. Also, I just did a line count on the events pos file generated by RTKPOST and it shows there are only 465 events (vs 546 images) so itās not an issue with Geosetter.
I think this is similar my problem, my camera eventualy do 2 triggers continuos, first was did by shutter by cable, but the secund isnāt. I make my cable, using capacitor and micro usb connector.
My question is, how get geotagged to photos without events log ?
I will do arduino (nano) to do feedback register in M+ by timemark pin, how this pin work ? I send 3~5v pulse to do one register ? My camera havenāt hot shoe, I have cable to trigger by Pixhawk relay pin55, for each pulse to camera I like to do the register to M+, if this donāt work directly, I will put a nano arduino to send a correct pulse to Timemark (c1 port) in M+
This is almost certainly an issue with the update rate of the Emlid Reach that I also ran into. Make sure you donāt have too many constellations enabled. The defaults are not your friend.
Another possible issue are cycle slips. While e.g. Arducopter records events during cylce slips, Reach does not.
I have an issue with several flights and Iām writing a script to interpolate the missing events based on the Ardupilot log file and the time stamp of the images (exif). I will finish the script tomorrow.
The timestamps in the Arducopter logfile differ at maximum by 8ms from the events recorded by the Reach module. And the Arducopter logfiles provide yaw, pitch and roll values tooā¦ .
My approach is to only use the time difference from the Arducopter log and set the error value higher (since it is a cycle slip its >1 m anyhowā¦) . I do not aim for accurate positions for the lost events but for assigning the high quality time marks to the right images.
I guess that the attitude information within the cam messages is not affected by the drifting?
Something that I have found in testing over the last couple of months is that if you use GCPās the actual timing as long as it is relative doesnāt matter. Iām basically using the PPK just to get a more accurate position of all the images relative to each other. The GCPās place the map correctly.
Thatās a very good practice, and often how traditional photogrammetry from manned systems go. It puts the accuracy (not precision) on the surveyor rather than the photogrammetrist. In addition, flat surfaces are notorious at causing large elevation errors when in-situ lens calibration happens by default. Calibrate your lens and use the results for future processingā¦ it will reduce those z-errors significantly. On a final note, I also use a GCP as my base station location in order to link my airborne to ground control.
Using the point as a GCP is a manual selection in most software, so thereās no elevation issues during āATā or aero-triangulation of the photos. The base station may be included in the point cloud, however I use a DTM (not a DSM) for the ortho generation process. Those points should be discarded so that there arenāt projection issues.
In many cases, I have a DTM from lidar anyway, so I skip the point cloud process entirely.
Exactly what I was trying to verify! Thanks. Creating the end-user data to be analyzed from a DSM is a big problem that I have seen with many of the mainstream UAV mapping service providers. They have been trying to start using the DTM, but none of them are very good at it. Running the software and processing yourself is one thing, but letting another company do it for you is a completely different technique. My experience has been to use the service provider for flight, data storage, collaboration and exporting the point cloud. Everything else from there is done in our VDC department through Carlson Precision 3D Topo and other CAD softwares. This gives us much greater control of the modeling process and integrations and a cleaner orthomosaic becomes a by-product.
I will quit hijacking the thread now, but would definitely like to learn more about your platform. We currently use quadcopters, but I have been looking into introducing fixed wings so I will check out your website.
