Has anyone encountered an issue when flying a mission that the drone would not be able to reach the waypoint but instead be oscillating in random ellipses around it? (also the height oscillates)
I first thought that might be some bug in the latest beta v4.21.2_BETA-g Build 30004040 released on Feb7. So I left the Beta in Play Store uninstalled and downgraded to v4.21.1-g (released on Feb2). With that it was a little better waypoints #1,#2 went fine, but the issue reoccurred when approaching waypoint #3.
Video illustrating the problem (with the Beta).
I tried two versions, one with straight lines, the other with curved turns but I got the same result.
I was successful with a mission at a different location on Saturday Feb5 (not sure which version of Litchi I had). I don’t really understand what could be different other than location.
The mission settings for the v2 (straight lines) were like this:
Yeah, I thought of that guys. But why am I getting smooth video feed when you say signal is the cause? As you can see at 1:33 of the video, the oscillation continued even when the signal was at 4 bars for over 20 seconds until I stopped the mission at 1:56. Does that mean only full 5 bards can guarantee me working waypoints with Litchi?
(I’ve test flown the full mission several times manually and I know this environment. I’m new to Litchi so I don’t trust it that much to fly environments I don’t know yet, finger on pause button all the time)
In the city it happens that the controller needs to adjust frequencies and for that moment you usually get 2-3 bars with Mini2, no big deal. I understand Litchi does the stick movements, it’s not autonomous waypoint logic in these drones, and probably the downlink of data is the first one to stop (although the video feed seemed just fine ).
Shouldn’t Litchi’s reaction to missing downlink data be “Stop” or at least “Lower the speeds” the closer the drone is to the goal? (thinking about this: Would lowering Cruising Speed help?)
DJI hints say: Don’t move sticks too abruptly on signal loss as the drone probably still reacts to your commands. When recording every time I simply continued (or stopped) my flight on signal loss (2 bars and less with video feed loss) and watched the footage in post pro it went just fine - based on my stick movements. So it seems the uplink control is working a lot longer that downlink.
Is the SDK somehow de-prioritized in how it can issue stick movements compared to physical sticks of the controller in lower signal cases?
By the way why does the drone travels over 9m/s towards waypoint 1 at 0:18 (signal 4bars), if my Cruising speed is set to 5m/s (14,4km/h) and Max Flight Speed to 6m/s (18km/h) ?
Another thing I just remembered I have changed since the successful missions are the EXP values.
Successful mission (with default settings):
Are these somehow in effect when Litchi controls the flight via SDK?
It’s rainy today, so I can’t get to test fly to rule out this new suspicion of mine.
“why am I getting smooth video feed when you say signal is the cause”
I wrote “controller signal”.
Control signal and Video feed signal are two different signals. Only Control signal is used to fly the drone.
This signal is also used for feedback to the controller and Litchi, like the drone position. When there are gaps in this signal the actual position of the drone and the transmitted position of the drone do not match.
While flying manually your feedback will be by vision (your eyes), using the Video feed signal.
“why does the drone travels over 9m/s towards waypoint 1”
A mission starts at waypoint 1 and only from then on mission settings become active.
I don’t know if EXP values have any effect. They don’t for drones older than the Mini-1.
I do get your point. However from my experience with DJI Fly upon signal loss, the video feed is the first one to go out. I usually still see the full telemetry (speed/height/map position, etc. no problem), it’s hard to tell which one goes our first - if the controls (uplink) or the telemetry (downlink) - kinda hard to test.
Also the Litchi app in my video shows pretty consistent data with the video video feed and the map position is moving smoothly. I would expect the data to be choppy if it wasn’t going through. And if there are gaps below 100ms I would expect Litchi to be able to deal with that.
Thanks for your explanation about the speed. Just checked my previous recordings, it’s consistent with what you’re saying.
So your Litchi waypoint experience with virtual-stick driven drones is mostly with Mini1 ?
Or do you have some Litchi flights with the latest supported drones behind you?
DJI Introduced EXP settings for Mini2 only in some November2021 update of DJI Fly app. Would be funny if they forgot about the implications for SDK Api. Will definitely test with defaults ASAP. And yes, will try to have full signal, although if it’s this signal-fragile I guess I can forget about waypoints with Mini2.
Kinda thought the GPS and compass precision will ruin waypoints. Never thought it would be the signal - that’s really one of the strong parts of Mini2.
I only have the Mini-1 (and Phantom3Pro, Mavic Pro and Mavic Air).
I’m still convinced all these issues are due to control signal interruptions because I have zero issues with my older drones flying the same missions.
As long as DJI sticks to Virtual Stick Commands, I wil not buy any new DJI drones anymore.
It just S***S.
Mavic3 is not yet supported, but will definitely be VSC (Virtual Stick Commands).
I don’t use the Mini1 for waypoint missions anymore.
Position accuracy (Horizontal & Vertical) depends on:
Number of locked satelites.
Compass callibration.
Windspeed.
Changes in air pressure.
Kp-index
Solar activities
And for VSC-drones and camera-viewpoint:
So @TriBar you were right the EXP settings had (fortunately) no influence and the only factor was signal strength. As soon as the signal fell on 3 bars it was never possible (tried 3 times) for the aircraft to reach waypoint and perform action. As soon as I moved and signal was full, the mission continued ok. Sometimes even 4 bars were a problem.
Probably slightly different RC location with better signal (4 bars over 3 with Beta) in my test with non-beta Litchi was the reason why the Beta performed worse on first two waypoints. So it’s not related to Beta either.
But somehow I have a feeling Litchi could do better job here. I believe I - just based on the instruments (no looking at the drone) - could be reaching waypoints manually better. Litchi somehow overreacts on the small delays/outages of the data.
Today I tried Dronelink - just a sanity test for the first time in wide open field. And even with 2-3 bars of signal it was doing pretty well - it seemed to do its best with the data it was getting. Going just slightly of course when I also saw signal outages including picture feed. Only once - when signal on 2 bars - it stopped the mission with a message “Telemetry delayed”.
Of course it’s hard to compare as the conditions were not exactly the same.
Now that I also have confidence in Dronelink I will try it to do this very same mission including the signal circumstances to see if there is a difference. It will take a while since (too bad, as I understand) Dronelink supports import of missions from Litchi only in their 100$ plan.
Nevertheless it seems Litchi will have to work a bit on their virtual-stick driving engine.
Have a look at this youtube video:
It shows how controller and aircraft orientation effects signal strength.
Also WiFi congestion (urban area’s) effects signal strength.
Mr. Kent has several video’s on the subjects “Antenna’s” and “signal strength”
Back to my original problem please. Litchi and my M2 fly path/height acceptably but still ignore the ACTIONS at waypoints. The M2 DOES oscillate but only at the start point of the mission but not at others. So, if you still think somehow its flying a CURVED route even if the setings say STRAIGHT, I have full batteries and signal strength, I now expect you to say I’m too close to the drone. I think LItchi needs more development, certainly on waypoint action commands.
At the moment, I leave ACTIONS blank and just start RECORD manually as a workaround until Litchi gets its act together.
I’m having the same problem. Not all actions are performed at waypoints. Seems to ignore some or all. It will stay, but not stop/ start recording or take pictures.
).
