I made a very short loop mission just to verify that it would indeed RTH if it lost signal.
I lost video, but I continued to get telemetry data. The relative distance shown on display I had should have been within range but it stopped moving. After a few seconds I tapped on screen and got the message shown in the image.
I finally had to bring up DJI Fly and selected RTH which worked.
The failure to RTH on loss of signal is a big hairy deal.
On another note, I was under the impression that Waypoints could now upload to the drone.
The presence of “JoyStick” at top would indicate otherwise.
“SDK Error on Air 2S waypoint mission”
Update Litchi to v2.14.2
“The relative distance shown on display I had should have been within range”
The RC-N1 has directional antennas, any object between the RC and AC can cause loss of control and/or video feed signal, especially yourself.
“but it stopped moving”
Your screenshot shows a speed of 15mph.
“I finally had to bring up DJI Fly and selected RTH which worked.”
Which proves there was NO loss of control signal.
The RTH button on the RC would have worked too.
“The failure to RTH on loss of signal is a big hairy deal.”
As long as you have telemetry data and the LED’s on the RC are not blinking there’s NO loss of control signal, you only lost video feed signal.
“I was under the impression that”
I assumed that…, I was told that…, I thought that…, etc.
Inform yourself about the facts !
ALL DJI drones that use the DJI Fly app are controlled by Virtual Stick Commands (VSC) during waypoint missions.
After the video stopped it continued to show movement and the general direction and speed should have been enough to get back within range - as I stated I KNEW it would lose signal briefly and I wanted to see if it would correctly trigger RTH. I chose this pat5h and height specifically to test that response. Capiche?
The screen shot was - for lack of a better term - “frozen”.
Nothing was being updated. I waited for a few minutes which should have been plenty enough to return but it didn’t. So two things you failed to understand:
1 - it did not initiate a RTH as it should on a lost signal.
2 - there is a CLEAR indication that there was some type of error with the SDK.
3 - a reasonable conclusion would be is that the two behaviors are related since it is stated that RTH should have been initiated.
4 - I had heard on the MavicPilots forum that they had “fixed” having to use sticks to do waypoints. So it was not so much as assuming as testing.
From your description, you lost video feed, not the RC/AC control signal. If that is the case, RTH would NOT have been initiated as it never lost the RC signal.
I’m not sure who on Mavic Pilots would have said that the A2S no longer users virtual sticks for waypoints but that information is incorrect.
There have been several updates to the IOS version of Litchi lately as well as an update to the IOS SDK. You would be wise to install the latest IOS version (2.14.2) of Litchi.
Unless ‘Signal Lost Behavior’ is set to ‘Hover’ or, in your case control signal was never completely lost.
Have a look at the video in the “VIRTUAL STICK COMMANDS” post I refered to above and see how the drone behaves between WP10 and WP12.
If you want to test RTH upon signal lost, just turn off the RC during flight at a distance of 6m or more (set signal lost behavior to Landing). Capiche?
Thanks but I checked TestFlight several times and it still shows no update. I’ve also checked my emails.
I’m running the latest version of everything including iOS that is available.
Apparently I’m being less than clear about the circumstances causing misunderstanding. I tend to be terse when describing things assuming folks will fill in the blanks. Sorry.
This is a test loop that I made years ago around a local school and their track field that I know will lose signal at the farthest corner. It has been tested with my Mavic Pro, Phantom 4 Pro, Spark and now the Air 2S. They all lose signal there. I am also intimately familiar with when they usually regain signal and generally speaking all aspects of how I expect things to go.
I was hoping to be pleasantly surprised by O3 but I guess that was asking too much.
Anyway, if it continues to follow the flight path (normal for all my other drones) I normally regain signal within 10 seconds or so as it comes down the street at the end of the field. With the Air 2S I continued to get telemetry for a short bit but then it was as if the screen froze, Nothing was getting updated. I waited about 2 minutes which I should have heard the bird returning. Nothing. I tapped the screen to see if it was responsive and I got the error message. I had to do it three times to finally capture the screen shot since it went away fairly quickly.
I then had enough and brought up DJI Fly - which was NOT running prior to this. I initiated RTH and it came home. Incidentally when Fly came up I had video feed and all telemetry so it was in fact within range as I had surmised. I wish I had thought to look at the map for current position but at that point I just wanted to get it home. It had to have been close to where it lost signal since it took some time to return. I have checked all settings and in both mission and app parameters the signal loss/end of mission is set to RTH. I have been using Litchi practically since it came out - I’m not a n00b at this. Normally I consider Litchi top shelf software and have had no issues up to this drone.
In summary Litchi was acting like it had no idea what was going on. Nothing was updating. I suspect - as a software developer - that the SDK error left the app in an undefined state where the normal operation was suspended.
I hope this has been a more clear - if verbose - description of the issue.
I think you meant to say set signal loss behavior to RTH.
But - please read the more verbose description of the problem I posted.
I think there are some misunderstandings on what I was reporting.
I’ll summarize:
1 - Litchi was unresponsive and acted like nothing was coming in. The values were frozen.
2 - when I brought up Fly it had video and all telemetry.
My conclusion is that something was amiss in the Litchi app after it lost signal and there is a plain error message from the SDK. As a software developer that tells me that an SDK function threw an exception and the app regurgitated the error code it got back from the exception. It would appear that Litchi failed to code a comprehensive exception handler to actually recover from the error.
In any case can we agree that an error happened and this is my attempt to inform Litchi what happened so it can be looked into? I know it’s much more fun to assume operator error but part of why we beta test is to report back on things we find that aren’t right.
Hover, Land & RTH are all Signal Lost Behaviors. Land would be saver in this case.
As a Beta tester you should have posted in the “Beta Feedback” section.
As an experienced DJI user you should know that execution of Signal Lost Behavior (Hover, Land or RTH) is determined by the drone itself, independent of whatever app is used, even when flying without any smart device connected.
I’m running a version of Litchi that is newer. See:
I don’t know if there is an inconsistency between your version of Litchi and the SDK but making sure all software is up-to-date would be the first thing to verify after encountering the strange behavior that you describe.
I now understand your description of the issue. It doesn’t sound right that Litchi should freeze. I normally don’t fly where I would loose the signal so my experience with signal loss is not at the same level as yours.
Yes they are all behaviors. Landing as an option would be entirely situational and I’m not sure you would know enough about the area to make that call. I prefer that it come back.
I’m still learning how badly DJI has crippled the new drones and teh Fly app and I’m guessing RTH behavior is one of those. Indeed I reviewed the info and it appears RTH is triggered by the aircraft always on signal loss. I believe your statement only applies to Fly and these midrange drones.
The older MP, P4P the settings were uploaded to the drone as part of the mission. You lost signal they kept plugging along. Battery RTH was the only thing that could override. Some settings must still be uploaded because you can set RTH height.
Just an oddity - the manual says the drone will reverse course for 50 feet after signal has been lost then make a beeline for home. Presumably the logic seems 50 feet should regain signal at which point it can navigate back with more assurance than flying blind - not to mention you could override the RTH.
As far as beta feedback - It sure looks like that’s where this is posted. Not sure why you’re trying so hard to find fault with my bug report.
Here’s what’s crazy - the app details says it’s 2.14.1 (3133)
It says the previous build is 2.14.1 (3133)
Crazy. I’m going to uninstall and reinstall to see if I can get the version you’re talking about.
Mystery maybe solved. Testflight appears to be buggered as far as the beta.
The appstore shows the CURRENT version as 2.14.2
So I’m just going to install that one and send a report that Testflight is falling down on the job.
