Emlid

Community Forum

Affordable way to integrate Reach M+ with DJI Phantom


(Michael Lambert) #41

@wsurvey, I think you are experiencing the same thing that many of us have seen in mapping. It has to be after the last firmware update because I had no issues with the P3P or the P4P up until about 6 months ago. I probably miss 5 on 300 so it’s workable, but it sucks when those misses hit a crucial area.


(Hunter) #42

I missed some photos before. I thought it was the metallic shiny thing circling around my bird. Must have been the same thing that dropped the other P4P out of the sky shortly after…


(Michael Lambert) #43

Honestly, you spacing looks awesome so I can recommend post-processing you images to regain information from tose shadow/blown-out areas. What happened here? Obviously a good thing because of the coverage, just curious.

image


(Michael Lambert) #45

Yes indeed, cool project. The elevation overlay in DroneDeploy would be very handy in this case for drainage analysis. My problem with the skipped images is not so much the orthomosaic, but the missing data in the point cloud.

Do you utilize the point cloud and have seen gaps?


(WSURVEY) #47

hijack
hey Tobias, I’ve decided to go full lever arm correction with the IMU data on our P4P now. I’m glad i’ve seen you mention it a few times as i don’t think i’d have bothered. I saw about 20% reduction in camera station position residuals just over my old, simple correction when I implemented a rigorous calculation. it also shifted the timing offset by more than I expected (~10ms). no more ignoring the valuable IMU data.
/hijack

buying and flying a P4P is really simple, and you’re average joe can be mapping in no time flat with it and something like Pix4D. in the case of our company it’s inertia, familiarity and time cost which will likely prevent us going custom build. and i don’t think the boss will make time for me to build and test a custom platform. As for my M+ experiment it was just a thought one day that i could maybe hook it up and improve our accuracy and time with little investment. improve the time versus what i was already doing which was tracking the P4 with a total station (which i don’t think anyone else was doing). And that was an attempt to better the normal many-ground-targets way of doing things.

going custom will perhaps disrupt too much the comfort the other staff have when they all know how to fly with P4P. but it’s not impossible.


(Michael Lambert) #48

Yeah, those gaps look like things that would have been removed during DTM’ing anyways. What’s your acreage and point count?


(WSURVEY) #49

then i think you were lucky. i don’t ever remember not having the occasional dropped photo. sometimes it was the Map Pilot app contributing to the problems though. It used to be horrible when the on-screen dots caused memory issues and after about 100 or so photos it just became a random sh*t-show.

I just fly enough side and forward overlap to deal with it. more than a couple of missed photos occurring on two adjacent lines in the same area would be enough to mess up a mission though. thankfully this hasn’t happened yet.


(Hunter) #50

I removed posts to reduce thread clutter as were quasi-irrelevant to original post. I might start a project share thread separately if get around to finish.

But acreage off top head was just below 1,000 IIRC and point coint not sure yet but was planning to up point density during processing as computer allows. It was a long day as had to fly manual second half due to airport and DJI geofencing.


(Timmyd) #51

@chascoadmin question for you. The flight log TXT file on your iPad or Android device contains the precise time the photo was taken down to the millisecond. By using the TXTtoCSV converter program, you convert the flight log to CSV and open it in Excel. There are two columns to work with.

|CUSTOM.updateTime CAMERA_INFO.remainedShots|
|2019/02/08 17:35:08.089 3403

By using Excel (if then) statement you can find every record where the Remaining shots changes. That is the record that contains the time stamp for the photo down to the millisecond.

Now all we have to do is take that time stamp and convert it to the format in the Events file.

So we need to convert this format:
2019/02/08 17:35:08.089

And convert it to this format and save it as an events file:
FallingEdge_Week,FallingEdge_Seconds
2,032,586,847.56
2,032,586,850.16
2,032,586,852.76

This no longer requires the use of the sensor. You just mount the M+ on your drone, log and then create an Events file from the Flight Log.txt file.

Is there any reason this will not work? And the precision should be very accurate. Let me know what you think? I am trying to find out how to convert between the two formats.

Giuseppe is the person who made me aware of the Flight Log having the camera events logged there.


(Timmyd) #52

Also by using this method, you are manually creating an Events file that will then be used in RTKLib or my case, EZsurv. The time in the flight log.TXT file should be using GPS time (from the P4P) so it should match precisely with the M+ time.

This is the link to download the TXT>CSV converter:


(Tobias Dahms) #53

If someone donats a significant sum to the Against Malaria Foundation I will integrate a function in my Timemark time machine that reads this text file and integrates the events into the corresponding RINEX file.


(Konstantin) #54

It is not good idea, because Camera sensor has it’s own time and every shot the camera sensor syncs its own clocks.
Sync time is 0-45 ms.
That means you will have not precise timemark event. Error is 0-45 ms. It is very big delay.


(Timmyd) #55

VanavaraDigital, I like others would be interested in Ashot for the sole purpose of not missing photos. It happens on every single mission.

But as far as using the timestamp in the FlightLog, I suppose the big question would be “when is the TS created in the FlightLog TXT file”. Is it pre-shutter, mid-shutter (as Ashot) or post-shutter? I have to believe using the FlightLog TS is much more consistent and accurate than using the LED blink.

Today or tomorrow I will compare the TS on each photo (Blink VS FlighLog) and see how they differ.

But the Ashot looks like a good paid solution none the less! Thanks for the reply.


(WSURVEY) #56

is this 0 to +45ms, or ±45ms?


(Konstantin) #57

it is 0 - (+45)
± 22 ms, if you will replace TM in rinex


(Konstantin) #58

hi, about what flight log you said?
Please tell me, where can I download it from my ph4pro?
I can do it tomorrow.
And please give me this log, I will see it today.

p.s. if you said about Log file on Pad, it is bad idea)))) Because we fly in the forest, int the city etc and the link are broken often.

AShot can do his job without RC link!

Thanks


(Timmyd) #59

https://www.youtube.com/watch?v=59pE9N3pXdg is a video on getting the log file.

You will need to download the TXT>CSV converter file.

Once you convert the TXT to CSV and open it up there are two columns you are looking at:
|CUSTOM.updateTime|CAMERA_INFO.remainedShots|
|2019/2/8 17:35:08.089|3403|
|2019/2/8 17:35:19.281|3402|
|2019/2/8 17:35:40.322|3401|
|2019/2/8 17:36:22.146|3400|
|2019/2/8 17:37:22.854|3399|

Each time the photo is taken the value for remainedShots will decrease by one. Now you can see the timestamp in millisecond for that photo. What I don’t know is when during the shutter actuation is that done??

I think Tobias is going to make his program so that it will read the text file and create the events based on the FlightLog TXT file. As long as the time stamp is very precise then this will be a very good method for creating the events file. I still want an Ashot for the sole purpose of not missing photos. Because DJI is not going to fix it.

Link for sample file. There are three files. Original, converted, and then where I tweaked the data in Excel.


Timemark time machine: a script to manipulate events within RINEX 3.xx files
(WSURVEY) #60

Interesting. My horizontal residuals in agisoft photoscan suggest ±45ms. I see residuals along track, forward and back, of up to 23cm, which corresponds to about 45ms in either direction. The vast majority are below 15cm though. I suppose this could also be interpreted as 0-90ms as well.

I wonder if LED driver duty cycle is adding its own delay on top of camera sync issue? And I’m seeing the compounded errors.


(Tobias Dahms) #61

Thank you for donating! Please send me the corresponding files (preferably does where the timemarks from the led are present).
If someone comes up with an idea how the derive the time offset I will integrate that solution into the script.


(Timmyd) #62

I am wondering if an offset is needed at all. How will we find out exactly when the log entry is created. At the very least by using this method it should be very consistent. Hopefully someone will know those answers :slight_smile: