Can't finish creating an "On The Fly Waypoints" Mission for Mini 3 Pro with Dronelink DJI App / S22+ Galaxy Phone
Hi,
Using the Dronelink DJI App Version 4.5.1(250), I can set all the "Marks" for the On The Fly Waypoint mission, but the mission does not save and the App closes prematurely when it comes time to give the Mission a name.
Does this function work in the MSDK5? Is this the correct Dronelink DJI Version? If not how can it be upgraded to try again?
Thanks,
Daniel
Comments
31 comments
Try updating to the latest version 4.9.0 (282) (I'm pretty sure Dronelink DJI will be on the same version as Dronelink) and try again
Thanks Martin, How do I do this Upgrade? I can't find it in the Google Play Store. (It seems there in no Auto-Update capability in Dronelink DJI).
Go here https://www.dronelink.com/download enter the required details and you'll end up with the correct app, it will never be on the Google Play store as there is something about MSDK5 that google won't allow it there
OK, That worked !! Will test again tomorrow. Thanks Martin.
Verdict - Good news and bad news.
Good:
1. The On the Fly (OTF) mission "OK" saved successfully with Dronelink DJI Ver 4.9.0 (282).
Bad:
2. 14 Actual photos saved when re-running the "OK" Mision, and the controller showed Photos are taken at 10 second intervals (is this a default - I did not specify it?). What determines ane Photo "interval" and can it be changed when saving the OTF mission?
3. But 33 Photos are estimated in Mission Estimate screen. (See screen shot). This is nowhere near the actual 14!. Bug?
4. I selected "straight" lines in the Advanced section when saving the OTF missions. The radius of default curves went to 22 ft however. That produced a very "curvy" outcome not like the straight lines I expected. What determines the curve radius when selecting "Straight lines" between waypoint when saving the OTF mission?
5. Altitude of the Marked waypoints recored differently than during the flight. Is this a bug / feature of linear interpolation? For example, Marks / Waypoints E and F were set to 87 ft AGL, but in the Web App show as 87' and 49' respectively. I would expect the each Mark altitude to be respected when each mark is set. See screen shot. A bug or a feature?
Screen Shot:
Hi Daniel. I may be able to help with a couple of your questions.
Number 2: The interval time is what it was set to the last time you used either the DJI app or DL. That value is stored in the drones firmware and doesn’t change unless the app allows it during the setup. If didn’t ask during the setup then you will need to change it first in the DJI app before next flight. Since you have it as a saved mission now you can also add a command at the beginning of plan for the interval time and it will use that value if you fly it again.
Number 4: When setting up a plan using straight, (Curved Radius) the default value is set to 20°. You can change the as well in that saved plan for next time.
Number 5: The Web app only indicates what the altitude is based on the ATL. There is no way for the drone or the app to calculate AGL. So the altitudes displayed in the plan is always based on the take-off point even when using AGL.
I fly a fair amount of AGL missions and there have been times when the altitude indicated is a negative value because I’m launching from higher than the flown area. Hope this helps.
Number 3: Not sure why there is a big discrepancy in the amount but it is an estimate. Looking at the screenshot it looks correct as there will be longer gaps between some because it would be flying faster than other parts of the path which it’s flying much slower on the tight turns since it’s capturing based on time. Other than that I don’t know why it would be that much off.
Hope this helps. Enjoy.
Very helpful Mike. It is logical some of the defaults are coming from the onboard settings (from the last mission). But it is perplexing the altitude of each "Mark" point is not coming over identically on their corresponding Waypoints. More testing tomorrow!
Daniel. Can you share the plan. Maybe I can look at it and see why. It sounds like there is some variation in elevation where it flew.
Sure, Thanks Mike. The flight was in a dead flat street.. Let me get you a clean flight with screenshots of the Mark points and resulting Waypoints.
OK, Thanks again Mike.
I built a clean 6 Mark (6 Waypoint) OTF mission.
- Marks 1 and 2 were at 25',
- Marks 3 and 4 are at 50' and
- Marks 5 and 6 were at 75'.
Problem 1: Mark 4 (50') created Waypoint D, but Waypoint D is not at 50', it is at 65'. The Waypoints are evidently not respecting their Marks. This is kind of dangerous for a flight through tight spaces! A Mark set at 50' should create a Waypoint at 50'.
Problem 2: Also the Waypoint flight created 8 jpg images when flown. However the Mission Estimate shows 17 Photos estimated. Large discrepancy.
The Shared Mission is here. https://app.dronelink.com/daniel-snyder/map-a-peninsula/plan/V8ANIJOXZ0iAJNiw8l6d/cqPRtVKNgmWBjMKcevPX
See Screenshots below.
Not sure why so DL will need to look at this and figure out why it didn’t set to the specified 50’. I looked at all the other waypoints and they have a specified altitude but for some reason waypoint D didn’t stick/ set even though you did set it at that altitude. Check all the waypoints and you will see what I’m explaining. Since it didn’t set to the correct 50’ altitude it would start ascending up from waypoint C’s 50’ and continue to ascend up to the 75’ on waypoint E. That’s the way interpolation works while flying to each waypoint which uses linear by default. It may be a bug but DL will need to look into this to see if it is repeatable and a possible fix. As far as the saved plan you can just change waypoint D to 50’ now and it will fly at those specified altitudes at each waypoint. Hope this make sense.
Still not sure why there is a big discrepancy’s in photo amount but usually it will only be a small amount when flown in the real world compared to the mission estimate. If it was able to actually fly a bit faster than there would be less photos captured but still the estimated 17 vs actual 8 may something DL can answer as well.
Thanks Mike, Exactly.
After you change the altitude to 50’ on waypoint D you can click on the 3D icon and view the path and see the interpolation between waypoints where it slowly ascends up. You may already know this but it’s a good way to check the path and see how it looks base on the interpolation. Then run on Google Earth and see how it will look. I ran it and overall it looks good. Obviously trees can grow but since you actually flew using the On the Fly you know there was plenty of altitude so it should not be an issue. Enjoy.
Yes, thanks. I still believe we have 2 bugs. The Mark at 50' should not be producing a waypoint 1t 65'. it worked correctly for 5 other Marks/Waypoints. And the photo estimates are over 100% off. Maybe Jim can check these.
Yes, thanks. I still believe we have 2 bugs. The Mark at 50' should not be producing a waypoint at 65'. it worked correctly for 5 other Marks/Waypoints! The whole purpose of recording OTF missions is to capture "Repeatable" flights. Having Waypoint randomly "miss their Mark" must be a glitch. (pun intended).
And the photo estimates are over 100% off. Maybe Jim can check these.
Yes, I agree as stated. Patience is a virtue. 😁
Does it always happen on the 4th mark or did it just randomly happen one time?
On the estimates, is the mission preview accurate?
Hi Jim. I don’t want to speak for Daniel but the two post he sent with screenshots show it has happened at least twice and on two different plans and different waypoints. Also both times the actual amount of photos taken was about half of what the mission previews indicate as shown above. I’m going to try and get out today and use the On the Fly waypoints and see what the outcome is for me and report back. I’ll try to run at least a few. Maybe it will help.
Hi Jim,
Seems to hit at random Marks/Waypoints in an OTF mission recording. Mission Preview mode shows the deviant Waypoint altitudes, not the captured Mark altitudes. Here is a similar one showing Marks 4, 6 and 7 are completely different than their corresponding Mapped Waypoint altitudes. When I convert the OTF mission to a Waypoint mission I get the Map altitudes - not the intended Mark recorded Altitudes.
Side Note - The large sweeping rounded corners on the above flightpath are not the expected "Straight Lines" selected during OTF capture. Cutting corners like that will fly me into many buildings! I think defaulting a 0' radius for the rounded corners setting would fix this when selection the OTF "Straight Lines". The 20' default radius is fine for the "Curved" selection in OTF missions, but 0' should be the default for the Waypoints when "Straight Lines" are selected. (see below).
I have 16 Facade jobs scheduled next week and was really hoping to use this feature with confidence. I know you are a wizard at making things right so let me know asap if you need more testing done.
Thanks Jim and Mike. Note I am using the DJI Mini 3 Pro with the DL DJI App. (ICYMI).
Sure Daniel. Curious why you aren’t using the Facade component instead of waypoints which will work completely different. Sorry, Not being nosey just curious. 😉
No prob. 2 Reasons. 1. just need a single 1-pass "roof level" circuit around the buildings (not any elevation wall sweeps like a facade would do), 2. need accurate mark points in the field (not pre-planned from my desk), since the site is always more obstructed than what google earth ever indicates.
The Mark-OTF mission recording allows me to fly to each corner "straight ahead" (with collision avoidance active), set each Mark facing the facade accurately. Then I can rerun the OTF mission in straight lines, camera facing inwards, taking intervalled shots. In theory I will build an accurate, repeatable plan that avoids obstacles. Something I can't do from creating a waypoints plan prior to getting on site or flying sideways onsite for the first pass. (too many crashes that way).
Got it. As for now at least the plan is editable and can be fixed very easily in seconds and then it can be re-run over and over. At least until DL figures it out. Good luck….
Follow-up: Here is the share for the other mission with the 3 bad altitudes, rounded corners, and 3x as many estimated photos as were actually taken. https://app.dronelink.com/daniel-snyder/aaa/plan/z6PKuhCrzKO2VPGuB09s/VtXtNEei1xinvA24bATB
Did some OTF waypoints testing on two missions with a bit different altitudes and waypoint amounts on each. Both missions when saved indicate the exact altitudes at each waypoint which was recorded during the set up process in those missions. So at least for me using my MA2 and iPad that is all correct. Possible it has something to do with the DL app while using the Mini 3 or Android device as some things are device or drone specific.
The photo capture amounts in the mission estimate and the preview are off. The one OTF mission took 23 actual photos and when I saved It and then ran as a mission it took 22. So the amount is correct when ran again as there can be a slight difference depending on several factors. The mission estimate however indicates 32.
The other longer OTF waypoints captured 46 actual photos but the mission estimate indicates 67 so way off. So it seems the more captures it takes the more off the mission estimate may be. Bottom line is it will capture the same correct amount based on the same interval time when re-ran over and over so should be fine but the mission estimates are incorrect. At least with my drone and device combo I had no issues with altitudes being incorrect as they were set during the set up process. Hope that helps Jim.
Daniel. I noticed when I add my camera photo component list at the very top in the plan and set the camera with the photo interval time to 3 seconds it then indicates the correct amount. The one OTF mission which took 22 photos and 23 when I ran it as a saved mission indicate 21 photos after adding the camera list with the 3 second intervals which is what I ran. So that difference is pretty normal as I mentioned before it is just an estimate. The most important thing is it will capture the correct amount when re-ran over and over based on the interval time you set. It may take time for DL to figure out why the mission estimate is off so at least for now you can add the interval and get an accurate amount if needed. Always thinking. Lol…. Hope that helps.
Hi Mike, I think since you used a MA2 (with MSDK4), you were using the DL App, not the DL DJI App for MSDK5. So perhaps not applicable, but a good lead for Jim to hone in on where the code behaves differently based on the MSDK differences.
Other question - did your flightpath produce straight flightpath lines or ones with large 20' radius curves? Another datapoint for Jim to identify differences.
Thanks, Daniel.
Yes, it’s a different SDK which is why I mention my setup so Jim may be able to narrow it down. The plan will always have rounded corners at 20° by default as I mentioned. Whether it’s called rounded corners or a straight path it produces completely straight paths which is different than the corner radius. The straight line wording was change to rounded corners a long time ago in the Web app so maybe they need to change it when using the On the Fly functions as well so it’s not confusing. The path is actually straight as you can see if compared to Bézier curves setting. It’s just the corners which is where it needs to turn. Maybe if they can add a preferred radius value when setting it up. I always use rounded corners and never use anything less than about 75° radius for my purposes but I understand your needs. One of the great features of the On the Fly functions is it can be saved and edited like any other plan to get it exactly how you want it. Simple enough. Good luck with the job.
Thank you guys for this thread, a lot of great testing and info here. What we have decided to do is as follows:
Nicolas Roberts. I think this will help those who Don’t understand the difference and how they work. DL staff always listens and improves the app. 👍🏼.
Please sign in to leave a comment.