Waypoint mission problem

[Skyscope]

the small difference in elevation at the lowest point of 4m

It only demonstrates the concept as an example. The difference would of course be greater the greater the difference in elevation and the shorter the lateral distance between the waypoints is.

He also claimed that it was overshooting the descent at the waypoint by a full 50’!

Like I said, I highly doubt that.

The point is, he claims several times, DJI is "stupid" by implementing the Mavic 3's waypoints like they did. I claim, his crash was an user error by not taking the interpolation into account. Anyone with a Mavic 3 Standard/Classic/Pro can check for themselves that the drone flies through each set waypoint.

DJI is far from doing everything right, and there is a lot of room for improvements in several areas with the Mavic 3 Pro too, but the waypoint function works as expected. I use it on nearly every flight, even in tight conditions, and never had any problems with it.

Since probably no evidence for his allegations is provided by the OP, this case is closed for me.

 

[GadgetGuy]

It only demonstrates the concept as an example. The difference would of course be greater the greater the difference in elevation and the shorter the lateral distance between the waypoints is.



Like I said, I highly doubt that.

The point is, he claims several times, DJI is "stupid" by implementing the Mavic 3's waypoints like they did. I claim, his crash was an user error by not taking the interpolation into account. Anyone with a Mavic 3 Standard/Classic/Pro can check for themselves that the drone flies through each set waypoint.

DJI is far from doing everything right, and there is a lot of room for improvements in several areas with the Mavic 3 Pro too, but the waypoint function works as expected. I use it on nearly every flight, even in tight conditions, and never had any problems with it.

Since probably no evidence for his allegations is provided by the OP, this case is closed for me.

I'm inclined to agree with you. Glad we have more reasonable minds to reassure us that the sky isn't falling, and everything is still working as it should be, while clarifying exactly how the waypoint functionality works in 3D.

 

[sbunting]

I recently created a waypoint mission on my Mavic 3 Cine. It was pretty simple, a gradual descent over some trees and then over a creek running through some adjacent wetlands. I created it, in flight, having read this thread first and decided against creating it on the ground with a map. So thanks everyone for all the discussion.

When I was done, the video was ok, but I wanted to make a couple of minor tweaks, on the ground, in the map. So the global speed was changed and the gimbal angle was adjusted slightly on the last waypoint. I decided also to move the last waypoint a little further out, 100 feet horizontally (height not changed), so drag and drop. Voila, save it, and fly it.

So I sent the bird out on the mission. At the last waypoint, the video stopped recording when it reached the last waypoint. The height of the last waypoint was app. 48 feet. Then boom, the drone started toward the earth quickly, descending just shy of 50 feet in 12 seconds. Fortunately as I was able to get it to respond to left stick up at a height of .6 feet, as the RC signal dropped 20% as it neared the ground, so aborting the mission and regaining manual control was less than instantaneous. There was precious little time between realizing a problem was occurring, responding, and having the drone respond. I was fully expecting to have to file a claim with DJI.

I've attached the flight log in a spreadsheet (at bottom of this post) The salmon-colored section shows where the waypoint mode was active. The yellow section shows where the video starts /stops. At the end of the yellow section is where the bird plummets nearly 50 feet after arriving at the last waypoint. It did what it was programmed to do when it hit the waypoint, video stops, altitude goes to 48 feet, and then mission over so RTH. Only the 48 feet that was programmed didn't occur. It was heading for thereabouts of 50 feet lower than that. I stopped it at the last minute.

In the flight log, I created a second sheet in which I took the height in feet and the lapsed time in seconds columns during which waypoint control was active. There is none of that curve during ascent or descent, so the speculation about drifting 50 feet above or below the waypoints heights is not a factor. It doesn't happen. You can easily see the nice straight lines of ascent and descent in the graph. Of course you can also see the 50 foot plummet at the end.

I've attached (In Dropbox Link at the end of post) a 720p video (raw) with the SRT burned in so you can see the flight metadata. Once the video stopped, boom, it started the plummet.

So my take away from this is simple. I thought I was safe by creating the waypoints in flight and making minor adjustments later on the ground. I think that logic is safe (but not yet tested), as long as you don't move or add a waypoint. I moved the last waypoint perhaps a 100 feet horizontally, but with no change to the height. Somehow, the new point was interpreted as about 50 feet lower when the mission was flown. This 50 feet is the same magic number that started this post and I have to agree with the fact that there is an issue. As my last waypoint was 48 feet, that "magic 50 feet lower" equated to 2 feet underground, which is where it was headed before I stopped it. And we are looking at a number, 50 feet, which seems to be consistent.

With the RTFM caveat about accuracy with waypoints created in 2D vs in flight (3D), why even allow "on the ground" waypoints to be created or their positions modified? One thing is certain, I'll never create or move a waypoint on the map again, even if I have a margin of error that well exceeds 50 feet.

As a side note, while I understand the frustration of the original poster, posts here should be civil and certainly less acrimonious. After all, we are all working together to solve problems and make flying our drones a safe and enjoyable experience. I appreciate those who, despite the tone of some of the remarks, stuck with this thread and helped work through it.

PS - RC Pro used

Dropbox Link to Flight Log and Video with Burned In Flight Data

 

[GadgetGuy]

I recently created a waypoint mission on my Mavic 3 Cine. It was pretty simple, a gradual descent over some trees and then over a creek running through some adjacent wetlands. I created it, in flight, having read this thread first and decided against creating it on the ground with a map. So thanks everyone for all the discussion.

When I was done, the video was ok, but I wanted to make a couple of minor tweaks, on the ground, in the map. So the global speed was changed and the gimbal angle was adjusted slightly on the last waypoint. I decided also to move the last waypoint a little further out, 100 feet horizontally (height not changed), so drag and drop. Voila, save it, and fly it.

So I sent the bird out on the mission. At the last waypoint, the video stopped recording when it reached the last waypoint. The height of the last waypoint was app. 48 feet. Then boom, the drone started toward the earth quickly, descending just shy of 50 feet in 12 seconds. Fortunately as I was able to get it to respond to left stick up at a height of .6 feet, as the RC signal dropped 20% as it neared the ground, so aborting the mission and regaining manual control was less than instantaneous. There was precious little time between realizing a problem was occurring, responding, and having the drone respond. I was fully expecting to have to file a claim with DJI.

I've attached the flight log in a spreadsheet (at bottom of this post) The salmon-colored section shows where the waypoint mode was active. The yellow section shows where the video starts /stops. At the end of the yellow section is where the bird plummets nearly 50 feet after arriving at the last waypoint. It did was it was programmed to do when it hit the waypoint, video stops, altitude goes to 48 feet, and then mission over so RTH. Only the 48 feet that was programmed didn't occur. It was heading for thereabouts of 50 feet lower than that. I stopped it at the last minute.

In the flight log, I created a second sheet in which I took the height in feet and the lapsed time in seconds columns during which waypoint control was active. There is none of that curve during ascent or descent, so the speculation about drifting 50 feet above or below the waypoints heights is not a factor. It doesn't happen. You can easily see the nice straight lines of ascent and descent in the graph. Of course you can also see the 50 foot plummet at the end.

I've attached (In Dropbox Link at the end of post) a 720p video (raw) with the SRT burned in so you can see the flight metadata. Once the video stopped, boom, it started the plummet.

So my take away from this is simple. I thought I was safe by creating the waypoints in flight and making minor adjustments later on the ground. I think that logic is safe as long as you don't move or add a waypoint. I moved the last waypoint perhaps a 100 feet horizontally, but with no change to the height. Somehow, the new point was interpreted as about 50 feet lower when the mission was flown. This 50 feet is the same magic number that started this post and I have to agree with the fact there there is an issue. As my last waypoint was 48 feet, that "magic 50 feet lower" equated to 2 feet underground, which is where it was headed before I stopped it. And we are looking at a number, 50 feet, which seems to be consistent.

With the RTFM caveat about accuracy with waypoints created in 2D vs in flight, why even allow "on the ground" waypoints to be created or their positions modified? One thing is certain, I'll never create or move a waypoint on the map again, even if I have a margin of error than well exceeds 50 feet.

As a side note, while I understand the frustration on the original poster, posts here should be civil and certainly less acrimonious. After all, we are all working together to solve problems and make flying our drones a safe and enjoyable experience. I appreciate those who, despite the tone of some of the remarks, stuck with this thread and helped work through it.

Dropbox Link to Flight Log and Video with Burned In Flight Data

Thank you for your valuable contribution. Hopefully, some our sophisticated flight analysts, who wanted flight logs, will still weigh in and respond. This is certainly worthy of further investigation.

 

[sbunting]

Thank you for your valuable contribution. Hopefully, some our sophisticated flight analysts, who wanted flight logs, will still weigh in and respond. This is certainly worthy of further investigation.

And, as you pointed out, there is an issue of dropping 50 feet, be it at the end of a mission or manually, with no stick input. There could be a common cause or two separate causes. It has to be investigated both ways, but the unexpected sudden drop of 50 feet, one reported in 10 seconds in manual and mine in 12 seconds in waypoint, is a glaring commonality.

 

[GadgetGuy]

And, as you pointed out, there is an issue of dropping 50 feet, be it at the end of a mission or manually, with no stick input. There could be a common cause or two separate causes. It has to be investigated both ways, but the unexpected sudden drop of 50 feet, one reported in 10 seconds in manual and mine in 12 seconds in waypoint, is a glaring commonality.

Indeed!

 

[sbunting]

I've read this post now several times. A lot of time and energy was consumed by bickering, criticizing, etc. I get it and I get why, BUT at the core of this is, in my mind and especially after yesterday, a very valid problem that the OP was reporting, one that can lead to a crash.

When people post to this forum, they can be at the time, also past or future, in a country that has very different laws, cultures, etc. Due process as we know it is nonexistent. I once reported a problem in this forum from an overseas client and it was immediately dismissed by one responder who said, in essence, "he said, she said, take it with a grain of salt", even when I had the logs. I had to strip out the lat/lon, but still dismissed by one respondent very bluntly.

The fact is, for one's personal safety or other NDA / legal constraints, revealing one's location, reason for flying, reason for using waypoints out of RC range, is simply not going to happen in this forum or anywhere else. A journalist can be flying a drone to a location to obtain evidence of crimes by a government. An intel specialist can be operating to gather important data. All the while this is being done, one can still experience problems or issues with a drone and need help or advice from this forum. They may discover a problem that will help others on this forum.

My point is just because a person is doing something in a way you find stupid, unsafe, or that you wouldn't do, you need to look beyond your own life's filter and be short on criticism and long on being inquisitive and helpful. Their methods of operation may very well be justified under extreme or unusual circumstances they can't reveal. I sometimes have to work overseas in a similar manner, so I get. Also, when devices are pushed to extremes, sometimes problems, otherwise not visible, come to the surface. So, when your fellow pilots operating under abnormal conditions, shall we say, come here for help or to warn others, keep that in mind and work with them.

Just my two cents...

 

[GadgetGuy]

I've read this post now several times. A lot of time and energy was consumed by bickering, criticizing, etc. I get it and I get why, BUT at the core of this is, in my mind and especially after yesterday, a very valid problem that the OP was reporting, one that can lead to a crash.

When people post to this forum, they can be at the time, also past or future, in a country that has very different laws, cultures, etc. Due process as we know it is nonexistent. I once reported a problem in this forum from an overseas client and it was immediately dismissed by one responder who said, in essence, "he said, she said, take it with a grain of salt", even when I had the logs. I had to strip out the lat/lon, but still dismissed by one respondent very bluntly.

The fact is, for one's personal safety or other NDA / legal constraints, revealing one's location, reason for flying, reason for using waypoints out of RC range, is simply not going to happen in this forum or anywhere else. A journalist can be flying a drone to a location to obtain evidence of crimes by a government. An intel specialist can be operating to gather important data. All the while this is being done, one can still experience problems or issues with a drone and need help or advice from this forum. They may discover a problem that will help others on this forum.

My point is just because a person is doing something in a way you find stupid, unsafe, or that you wouldn't do, you need to look beyond your own life's filter and be short on criticism and long on being inquisitive and helpful. Their methods of operation may very well be justified under extreme or unusual circumstances they can't reveal. I sometimes have to work overseas in a similar manner, so I get. Also, when devices are pushed to extremes, sometimes problems, otherwise not visible, come to the surface. So, when your fellow pilots operating under abnormal conditions, shall we say, come here for help or to warn others, keep that in mind and work with them.

Just my two cents...

Unfortunately, the OP has not clarified or replied to the contradictions I have pointed out within his posts, so it is difficult to separate fact from hyperbole, and his snarky attitude certainly hasn’t helped!

The OP is the one calling everyone, including DJI stupid, while not explaining himself very clearly, and picking and choosing which posts he replies to, usually with great vitriol.

Nevertheless, there is a commonality between the gist of what he is reporting, bkushner's thread, and your post. We have your log and bkushner's log, so maybe @Meta4 or or one of the other seasoned data analysts can help.

 

[sbunting]

I have submitted this incident to DJI senior engineering along with an online interview and all logs, data, etc. What I find troubling from this incident is that even less than a foot off the ground, no obstacle avoidance intervention. I had it enabled and on as part of my preflight, but then it says "When under stick control". ??? We'll see what they say. Meanwhile, I'm going to try to replicate the situation, only make the last waypoint in a nice safe place with me able to physically intervene if need be and make the last height more than double the 50 feet margin. We have weather settling in on the east coast with rain and storms every day for the next two weeks, so when I can do so may be a bit.

 

[GadgetGuy]

I have submitted this incident to DJI senior engineering along with an online interview and all logs, data, etc. What I find troubling from this incident is that even less than a foot off the ground, no obstacle avoidance intervention. I had it enabled and on as part of my preflight, but then it says "When under stick control". ??? We'll see what they say. Meanwhile, I'm going to try to replicate the situation, only make the last waypoint in a nice safe place with me able to physically intervene if need be and make the last height more than double the 50 feet margin. We have weather settling in on the east coast with rain and storms every day for the next two weeks, so when I can do so may be a bit.

In the interim, the best way to get our experienced flight analysts to examine your flight log is the create a completely separate thread yourself, with the link to your flight log. I fear it is being ignored here, for obvious reasons. Then, maybe @Meta4 and @slup will weigh in. Just copy out your post #83 and create a "Request for Flight Log Analysis" thread. Our guys are far better than the so called DJI senior engineering guys.

Then, post a link to your own newly created thread here, stating you've moved the discussion into a separate thread.

 

[GadgetGuy]

Just found this video from a year ago which might explain everything!
The long flight times of the Mavic 3 batteries only exacerbates the problem of changing barometric pressure during a long waypoint mission, or a waypoint mission executed at the end of a longer flight. Solution is to minimize the time duration between takeoff and the flight over the tallest obstacle during your waypoint mission that you intend to fly closely over, or fly higher with more clearance to cover all potential changes in barometric pressure after takeoff.

Hidden Dangers of Waypoint Missions

 

[wienog]

RTFM!!!

I think you are not understanding or misunderstanding this man. I had the same issue. When you make a waypoint mission in Dji Fly the flightpath 'curves' around the WP you set, sometimes passing many meters from the actual WP that was set. That is not such a big problem as you can take that into account when planning the flight. The problem is the same algorithm is used when changing height in the flight, just as when changing horizontal directions, when changing height the actual flight will pass several meters UNDER the set height. and that is a way more difficult situation to take into account when planning your flight.
I was in contact with DJI support for that and they examined several of my logs of WO-flights and acknowledged the problem.
I must admit that it is not yet solved in the lates firmware or fly-version.
What HAS changed though in version 1.10.6 of DJI Fly is that you can not 'Continue' anymore after signal loss and that is much more destructive.

 

[mobilehomer]

I think you are not understanding or misunderstanding this man. I had the same issue. When you make a waypoint mission in Dji Fly the flightpath 'curves' around the WP you set, sometimes passing many meters from the actual WP that was set. That is not such a big problem as you can take that into account when planning the flight. The problem is the same algorithm is used when changing height in the flight, just as when changing horizontal directions, when changing height the actual flight will pass several meters UNDER the set height. and that is a way more difficult situation to take into account when planning your flight.
I was in contact with DJI support for that and they examined several of my logs of WO-flights and acknowledged the problem.
I must admit that it is not yet solved in the lates firmware or fly-version.
What HAS changed though in version 1.10.6 of DJI Fly is that you can not 'Continue' anymore after signal loss and that is much more destructive.

The manual warns about altitude changes when using waypoints.

 

[Rockowe]

I'm in Cambodia flying out of signal range waypoint missions. So I'm flying toward Ankor Wat, to get some video. I decide to go to a high altitude to get the best shot. So when the drone comes back, it's doing a RTH, so I know something went wrong. I watch the video, and it when it went from the high altitude, to a low altitude, it overshot the low altitude by a mile, and went into the trees. Fortunately, the obstacle avoidance worked correctly, and it executed a RTH. This is something that I found by my house in the Philippines, when it almost hit the ground at a 30 feet wp. I told DJI about it then and they've done nothing to fix it. This is another reason I think they're stupid. Here's the email I just sent them:



A mission hit a tree, and did a RTH, because when your waypoint missions go from a high altitude, to a low altitude, it overshoots the low altitude by miles, and gets way too low. I told you this a long time ago, and you never fixed it. Great job!

IMPORTANT:
When setting up a Waypoint Mission - be sure to LAUNCH at the same Elevation as when you designed the Mission.
As I understand this, all heights used (in the FlyApp 'Waypoints' program) are based on the elevation of takeoff (Launch).

Lets say you set 30ft altitude for waypoint 1 and you take off from Position X, - the altitude will be fine if you takeoff (Launch) from all places at the same height as X.
However as I understand it ... if you launch from 100 ft below position X - then the Whole mission will be flown 100ft lower and may result in a crash ( especially in an area with undulating elevation - and without obstacle avoidance).

The app Litchi has a field to rather select "above ground" as a waypoint parameter... but waypoints 5 (for DJI) is said to depend on your Take-off (Launch) elevation.

ALSO RTH is based on your Launch Elevation
(as I understand it)

See "Waypoints VIII - Height Setting - Deep Dive"
(explaining the height issue)

Also as said above - there is an overshoot of altitude when travelling at speed - remember when descending - there is additional gravity helping - ... to overcome that requires huge force by the rotors. Changing from one altitude to the next going down, it makes sense that this should be done with extra leeway.
As an Example of this : I learnt the hard way 4 yrs ago when showing off my Mavic 2 in SPORT mode, descending at a steep angle, to a soccer field at speed - then Just above the Ground I wanted to shoot Upward - In Horror I watched the Drone at 70 km/hr Plummet into the ground after having Pushed the Elevation stick HARD up 5 seconds BEFORE ! (Lesson to Self: It takes time to slow the descent...)

Hope this helps

 

[sbunting]

Fascinating stuff! Clearly something else that must be taken into consideration on a waypoint mission. Extremely well done video.

In my case, the plunge started at the last waypoint, only 4 minutes and 30 seconds into total flight. My thoughts are that it was not likely enough time from take-off to experience that much of a barometric pressure drop, but who knows. I just uploaded the DAT file to DJI's engineers and we'll see what they conclude. Whatever, I'll start a new thread when I get the results and see what the collective group has to say about the logs and what DJI has to say.

 

[sbunting]

As to the takeoff points between first mission and the same mission again with modification, I was literally standing in my previous footprints. So zero change in take-off elevation.

As for the 'curvature' applicable to the descent, the descents were all without any 'curvature'. Graphed (included on the second page of the spreadsheet), the descent was pretty much a nice steady slope. At the last waypoint, boom, that's when it headed toward the ground, fifty foot drop in 12 seconds, instead of an RTH, as was programmed. I had flown this mission once previously, having created it in the air, as recommended. I modified it on the map. I changed the global speed to 4.6 mph and adjusted the gimbal angle. I moved the last waypoint horizontally about 100 feet further out. That's it. When I flew it, once his hit the last waypoint, it went for terra firma.

 

[GadgetGuy]

What HAS changed though in version 1.10.6 of DJI Fly is that you cannot 'Continue' anymore after signal loss and that is much more destructive.

Thanks for the heads up on this new Trojan Horse in DJI Fly 1.10.6! The original LSMC (Lost Signal, Mission Continues) capability was too good to last long!

Is there any documentation or other thread about this, or did you just independently discover it?
Is this a new, or was it already changed in DJI Fly 1.10.4 or 1.10.0?
Has it also already been pushed out to the RC Pro?
Last RC Pro update I can find is 5.25.2023 which is still Fly v1.10.0

DJI RC Pro Release Notes
Release Date: 2023.05.25
Remote Controller Firmware: v03.02.02.00
DJI Fly App: v1.10.0
What’s New?

 Fixed an occasional issue where the compass calibration was unsuccessful.

 

[GadgetGuy]

Fascinating stuff! Clearly something else that must be taken into consideration on a waypoint mission. Extremely well done video.

In my case, the plunge started at the last waypoint, only 4 minutes and 30 seconds into total flight. My thoughts are that it was not likely enough time from take-off to experience that much of a barometric pressure drop, but who knows. I just uploaded the DAT file to DJI's engineers and we'll see what they conclude. Whatever, I'll start a new thread when I get the results and see what the collective group has to say about the logs and what DJI has to say.

Guy knows his stuff! I agree 4.5 minutes is too short for a significant barometric change. However, if the barometric calibration is incomplete before launch, it could create a false zero, relative to the intended elevations at each waypoint. It used to be highly recommended by bladestrike/Ken to wait at least two minutes for an accurate barometric pressure reading for accurate elevation changes. With the faster HP acquisition now, many may be launching with an inaccurate zero level that is changed when calibration is completed during flight, just like the HP being spontaneously reset after launch, when even more satellites are acquired. How soon after powering up did you launch?

Keep us posted on DJI's analysis.

 

[honkihonk]

What HAS changed though in version 1.10.6 of DJI Fly is that you can not 'Continue' anymore after signal loss and that is much more destructive.

Can anybody confirm this? I really don't want to lose the ability to continue after signal loss.

 

[sbunting]

Can anybody confirm this? I really don't want to lose the ability to continue after signal loss.

I just uploaded the latest firmware for the RC Pro (03.02.0400) and it still uses DJI Fly 1.10.0. Continue is still an option for Signal Loss. I note on DJI's website that there are two releases of DJI Fly since 1.10.0, including the latest you reference, which is 1.10.6. The version of DJI Fly on the RC Pro is controlled by the RC firmware and there's no independent update mechanism for the DJI Fly that I've found in the interface or the beloved manual. So for now, on the RC Pro at least, Continue remains an option. When DJI decides that DJI Fly must be updated as part of the RC Pro controller update, I'll know better. It's not like there's a choice on the RC Pro, if you update the firmware. Anyone else out there with an insight into this?