I run into this earlier this morning. I lost connection with the AC for a second or two and it went through its up and down bobbing during those few seconds. The mission was POI focus defined. I was wondering if changing that to interpolate for all way points while leaving the gimbal pitch angles as they were defined by POI focus would resolve this issue in real flight (as it seems to in the virtual google earth render). Will test if I can but I doubt I will get to run this particular mission again.Thanks for the information, that is also consistent with my observations. But I thought it only affected the gimbal pitch. This is immediately noticeable because the recording is messed up.
This is of course a litle limitation and I could not find any hints about it.
Virtual Litchi Mission
- Thread starter namirda
- Start date
I don´t think that will works. After everything we've heard so far, for the correct gimbal movement during the real flight the connection to the RC is really important, not the WP settings. In the virtual google earth render the mission it always looked good, regardless of POI or Interpolate.
Of course, if you can do the test unexpectedly, please let us know the results.
Rockowe
Well-Known Member
- Joined
- Dec 19, 2017
- Messages
- 499
- Reactions
- 415
- Age
- 53
This is how it works-
The ANGLE that the Gimbal is at, at the Point of disconnection will be retained throught the disconnection-
For example if All your Waypoints are set to -45deg - then that is the angle for the WHOLE Mission... (It will retain this in and out of RC Range)
If you want to see the Gimbal VARY the angle from -45 deg to -20 then setting interpolate SHOULD be WITHIN the distance limit range of the controller -
======================================
TO CLEAR THIS WHOLE STORY UP and MAKE it EASY-
Interpolate and POI settings BOTH Change Gimbal Pitch.
POI = where you have an Actual POI to look at.
Interpolate = used where there is typically no POI - but you still wish to Vary Pitch angle.
The Earlier versions of Virtual Litchi INSISTED on all Points being Interpolated (not POI) to get the KLM file made for Google Earth. I'm not sure if that was fixed - Namirda (developer) would Know.
So Pitch angles May be Smoothly Varied from one to the other ONLY when the RC is in Range.
QuickFix: So... in your Mission Project...
A) ONLY vary the gimbal Pitch in areas you are SURE the RC connects to-
B) For all other points out of range - choose a Fixed Gimbal Pitch - say -30deg (safe) and fly the Whole 'OutOfRange' Leg on Interpolated - 30.
(This will Stop the intermittent popping upwards and bobbing you see as the RC connects and reconnects and tries to reset the Gimbal Pitch - all angles will be -30 for out of range)
Simple Workaround! - the same applies on Both LITCHI andDJI GO 4
Last edited:
Thanks @Rockowe for the explainer; and I do get what you are saying. But here is what I don't get.
If the gimbal maintains the last angle it was set to before the disconnect, this shouldn't happen (See below video, it is set to start at 0:51, right around where the bobbing happens). Why does it do this little dance?
In my mission earlier today, the disconnect (and the resulting up and down bobbing in the footage) occurred somewhere between waypoints 10 - 12. All waypoints along the circle (2-20) were set to Focus POI and they all had a gimbal pitch value of -30 degrees.
If the gimbal maintains the last angle it was set to before the disconnect, this shouldn't happen (See below video, it is set to start at 0:51, right around where the bobbing happens). Why does it do this little dance?
Last edited by a moderator:
Rockowe
Well-Known Member
- Joined
- Dec 19, 2017
- Messages
- 499
- Reactions
- 415
- Age
- 53
My observations
1) You exited to (or arrived from) the East (or RIght side)
… your Point of Loss of Signal could have been at the Points furthest from you. (10-12 on the Left side)
2) You have a POI in the Centre- which suggested that THIS was the Method you selected to calculate Gimbal Pitch (however small it VARIED from 10-12) . Not By Interpolation.
(My previous Workaround) was to NOT use the POI setting in Litchi (when out of range) but to set all (out of range points) to a Fixed Angle Interpolated - for all points - Out of range
… (including those IN range but CLOSE to the disconnect point) of the Mission.
THREE Solutions (Recommendations)
1) Come Closer to the Entire Scope of the Mission - (so that RC does not disconnect at all)
OR
2) Set all Points 9 to 13 to Interpolate at -30
OR
3) Climb Substantially at 8-14 to possibly avoid disconnection - from RC - (ie from where-ever Eastwards you were based)
Hope this Helps
That is correct, that is where the brief disconnect happened.
I think I will try this next time. Thanks again!
Interpolate causes smoothing of transitions between two POIs, rather than just jumping abruptly from one to the other. When setting up a mission I start with all WPs set to Focus POI and then go back at set them all to Interpolate. I also change the mission settings from Focus POI to Interpolate. When following this procedure it always ends up with smoothed transitions in pitch and yaw rather than any abrupt.
A new version of VLM (V2.5.0) is now available for download – the link can be found in the first post of this thread.
The differences from V2.4.0 are minor but interesting!
A long time user of VLM (@Tajino) noticed recently that the behaviour of his drone around POIs was inconsistent – he found that in some missions the drone pointed very precisely at the POI but in other missions the heading ‘wandered’ off the POI by a considerable margin.
In contrast the virtual mission produced by VLM focused well on the POI in all cases.
@Tajino followed this up with Litchi and learned something new about how they handle WPs and POIs in different circumstances. - at least it was new to me!
It seems that the way Litchi handle POIs depends on the mission type as follows:
VLM V2.4.0 was programmed to focus as well as possible on the POI in all cases and so missions of type 2) will focus on the POIs rather 'better' than the real mission.
The purpose of VLM is to give an accurate picture of the mission before it is flown and so in V2.5 .0 I have ‘downgraded’ the way that VLM handles POIs in missions of type 2) to better match the real mission.
The heading ‘wander’ in type 2) missions depends on the relative distances of the two WPs from the POI. If both WPs are a similar distance from the POI then the interpolation will be a good approximation but if they are very different distances from the POI then the ‘wander’ may be significant.
So the takeaway from all of this is:
I hope that all makes sense! And thanks to @Tajino !
N
The differences from V2.4.0 are minor but interesting!
A long time user of VLM (@Tajino) noticed recently that the behaviour of his drone around POIs was inconsistent – he found that in some missions the drone pointed very precisely at the POI but in other missions the heading ‘wandered’ off the POI by a considerable margin.
In contrast the virtual mission produced by VLM focused well on the POI in all cases.
@Tajino followed this up with Litchi and learned something new about how they handle WPs and POIs in different circumstances. - at least it was new to me!
It seems that the way Litchi handle POIs depends on the mission type as follows:
1) If a mission has ONE and only ONE POI and ALL WPs reference this POI then the focus on the POI should be excellent throughout the mission. This is actually a limitation of the DJI firmware - only one 'hotpoint' is permitted per mission.
2) In all other cases, the heading of the drone between two WPs will be linearly interpolated between the angles calculated at the WPs. This will result in good focus on the POI at the WPs but the heading will wander off the POI at points in between.
Tajino and I have both done a number of tests to verify what we were told by Litchi – and the results confirm the above.VLM V2.4.0 was programmed to focus as well as possible on the POI in all cases and so missions of type 2) will focus on the POIs rather 'better' than the real mission.
The purpose of VLM is to give an accurate picture of the mission before it is flown and so in V2.5 .0 I have ‘downgraded’ the way that VLM handles POIs in missions of type 2) to better match the real mission.
The heading ‘wander’ in type 2) missions depends on the relative distances of the two WPs from the POI. If both WPs are a similar distance from the POI then the interpolation will be a good approximation but if they are very different distances from the POI then the ‘wander’ may be significant.
So the takeaway from all of this is:
a) If you want the best possible POI behaviour then you must restrict your mission to a single POI and make sure all WPs reference it.
b) If you need more POIs in your mission but still want reasonably good POI behaviour then you should add extra WPs so that all WPs which reference a given POI are about the same distance from it.
c) If you can’t do either a) or b) then you will have to put up with a bit of POI ‘wander’ in your mission.
The fact that this issue has not surfaced previously probably means that the behaviour of V2.4.0 was satisfactory for most of us – however V2.5.0 should give a better match with the real mission even though the POI behaviour has in most cases been downgraded!I hope that all makes sense! And thanks to @Tajino !
N
Here is a video showing a Litchi mission - BOTH the simulation with VLM SIDE BY SIDE with the actual flight!
You may notice that there is a mismatch between the gimbal pitch. There is also a mismatch between the speed.
For any questions - please contact me through my website CONTACT tab - www.SkyCam.Studio
You may notice that there is a mismatch between the gimbal pitch. There is also a mismatch between the speed.
For any questions - please contact me through my website CONTACT tab - www.SkyCam.Studio
OzoneVibe
Well-Known Member
This difference is something I've know about for a long time, and written about. (I thought in Mavic Pilots, but I can't find it.)
This may explain a little better … a picture paints a thousand words, etc.
What your POI will create is the 5° for WP1, and 90° for WP2.
At the mid-point what you need is 20°.
But the Mavic Pro (in my case) will turn at a constant rate (between waypoints) so that, at the mid-point, it will be at 42.5° …. half way between 5° and 90° … and not pointing at the POI.
To overcome the worst of this, I add new WPs ever nearer the POI so that there will be new ones at 50% 75%, 87.5% etc … each time halving the remaining distance to the WP closest to the POI.
A perfect solution? Nope …. but far better than not adding the additional WPs.
This may explain a little better … a picture paints a thousand words, etc.
What your POI will create is the 5° for WP1, and 90° for WP2.
At the mid-point what you need is 20°.
But the Mavic Pro (in my case) will turn at a constant rate (between waypoints) so that, at the mid-point, it will be at 42.5° …. half way between 5° and 90° … and not pointing at the POI.
To overcome the worst of this, I add new WPs ever nearer the POI so that there will be new ones at 50% 75%, 87.5% etc … each time halving the remaining distance to the WP closest to the POI.
A perfect solution? Nope …. but far better than not adding the additional WPs.
Prismatic
Well-Known Member
Thank you for the visual explanation, @OzoneVibe, and your brilliant workaround. Building on your work, I think this illustrates:
As the drone travels between WPs, its heading changes linearly from what was specified for WPx to the heading specified for WPy. So at the midpoint of each pair of waypoints (the little empty circles with tails), the drone has "split the difference" between the green-line heading of each. That's the expected behavior, but it causes trouble when there's a large angular difference between WPx and WPy (as in your diagram). Adding in "extra" waypoints--WP2, WP3, and WP4 in my version--keeps the heading quite close to the desired aim rather than slewing off-target.
As I said, it's brilliant!
Last edited:
OzoneVibe
Well-Known Member
As is your graphic!
Indeed …. that's exactly what I do … any remaining "wobble" can usually be removed in decent editing software "stabilisation".
Rockowe
Well-Known Member
- Joined
- Dec 19, 2017
- Messages
- 499
- Reactions
- 415
- Age
- 53
This is a detailed Explanation Recorded on a LIVE Stream... (watch in HD or more)
See thread : - LITCHI - as a DIRECTION FINDER. (Another AMAZING reason to use)
Last edited:
Rockowe
Well-Known Member
- Joined
- Dec 19, 2017
- Messages
- 499
- Reactions
- 415
- Age
- 53
---------------
I noted this Glitch in 2018 - (in this same forum) -
...Read the explaination - Click here to go to the Report: Click HERE
Last edited:
Hi Wombat,
There is no 'phishing' going on.
VLM simply checks to see if there are any program updates available. This behaviour has not changed since V2.2 and so I'm not sure why malwarebytes should be complaining about it now.
You can safely whitelist VLM - but you have to take my word for that!
N
The domain name of the vlm server is namirda.dynamic-dns.net as you can see in the MB window on your screen.
It's not a website as such - just a simple data server.
N
Last edited:
Similar threads
