If you haven't already seen it you might like Mavic Flight Log Retrieval and Analysis Guide
Last edited:
Help understanding crash on a balcony
- Thread starter CodaDiLupo
- Start date
- Status
Thanks for these very interesting observations. The fact that the drone position remained confined inside a well-defined neighborhood of the chosen point seems to indicate a working optical position feedback with decreasing precision with decreasing light intensity. If the flight mode was ATTI, the drone would have drifted away from that range, even though indoor there might have been little external excitation. It would be interesting to redo that experiment outdoor and see if the presence of wind ( low to moderate, not planning to sacrifice a drone to the joy of discovery lol) is able to break position control.
I would really be interested in assessing performance of the optical control system by analyzing closed loop signals like commanded x and y positions, VPS-estimated x and y positions and see how the tracking error influences the commands to the motors and at what threshold closed-loop is deemed not suitable anymore. It seems DJI is not giving away this piece of the puzzle
I rarely get to fly on windless days but my recollection is that on days where there was wind (it tends to be gusty for me) the short term VPS only position holding (low down) whilst hovering was slightly worse than in a windless environment but not much, excursions might have reached 1ft. 'Long term' I would say there was little to no overall drift.
Quite frankly I think it does a remarkable job.
Quite frankly I think it does a remarkable job.
I am not sure where I ever said that the crash was not my fault. I know that already and I started this thread exactly for that purpose, to learn. However, what I want to learn is not what I already know, i.e., that switching to ATTI found me unprepared to counteract the drift. What I am trying to find out are the trigger conditions that determine the switch from closed-loop operations in P-OPTI mode to open-loop operations in ATTI mode. I appreciate every ounce of support I receive and I am sure Meta is way more expert than I am. However, support ceases to be support when it starts tearing down my line of inquiry claiming that everything has already been clarified and refuses to even read my counterpoints. Since I am the author of this thread I was under the impression that it was my call to decide when I have reached my learning goal (or I understand that it can't be reached) and that everybody else had the full freedom to either support me along this path or ignore me. I did not know I had to shut up as soon as an expert called the problem as solved.
Last edited:
Grandpa
Well-Known Member
- Joined
- Oct 12, 2016
- Messages
- 127
- Reactions
- 160
- Age
- 71
No, you don’t need to shut up. You just need an attitude adjustment. All of your holier-than-thou attitude and snide remarks to those who offer you support show me it is not worth my time to engage you. Grandpa has left the room!
Talking about grandstanding. In your rush to the exit door you forgot to post that log evidence that would have resolved the issue.
mobilehomer
Well-Known Member
No need to shut up, but your long-winded replies, trying to sound intelligent, do just the opposite. As Einstein said - if you can't explain it to a six-year old, you don't understand it. No need for excessive verbage, brevity is priceless. Why do you need log evidence? Can you not learn from the experience of others? Sometimes the BEST reason is - "because I said so."
It would be my call too that VPS does a remarkable job. If we think about very simple flight situations with the drone flying a few feet from us in plain sight, having to resort to GPS for position control is really an overkill and would result in problems under many circumstances (indoor, when buildings cover a large part of the sky, etc.). That is why VPS has to be very robust. And that is why I am so keen on analyzing this flight in which the reason of the VPS failure is very hard for me to root cause. I had flown already along that path in the same light conditions on the way out without problems. It was not a problem of being too high above ground, as VPS had worked egregiously during portions of the flight at higher height.
It really boils down to two possibilities imho.
One is what @Kilrah conjectured, i.e., that the pattern recognition operated by VPS to estimate position is so complex that it can be randomly thrown off by a detail that is not discernible by such a high level considerations as "same place, same lighting". Such an occurrence should be easily discoverable looking at VPS logs, if available, and it seems to run contrary to the general feeling that VPS control is rather robust. Anyway, if this was the case, there is no remedy, as there is no way to forecast when it may happen.
The second possibility, and maybe I am unreasonably obstinate in still looking at this, is that there is some cross-coupling between the performance of VPS and disabling OA. The log do not seem to indicate that disabling OA automatically terminates VPS, which would be insane. However, the log shows that a few seconds after disabling OA VPS gets unexplicably replaced by GPS (with a very low satellite count) very shortly and then ATTI. There is something in this data that makes me suspect that disabling OA somewhat weakens VPS, making it less robust. This is what I really want to find out, because knowing this would lead to a more controllable transient situation.
There have been some quads that go crazy without gps and flyaway at full speed with no input control from the pilot responds.
Both OA and VPS can be disabled separately. VPS can drown the quad when flying low over the water, so time to disable for situations like that.
Did you really ask "Why do you need log evidence?". Have you really thought that through or you think evidence is just an irrelevant detail? Anyway, my answer is that "because I said so" stopped working for me after grammar school. The principle of authority was what governed theology and philosophy in the Middle Ages. It has been a few centuries since it has been replaced by the use of experimental evidence. With great scientific progress, I must say. And I am quite sure Einstein would agree. In regards to my writing style, if you don't like it don't read it. I grew up at a time in which the average attention span was enough that writing and reading complete sentences organized in paragraphs that explained concepts was common. Definitely writing one-liners whose implicit explanation is "because I said so" is not my style. I am sorry that you resent that I try to sound intelligent, but the more I read the less the efforts to achieve the opposite goal entice me. If you made it all the way to here, congrats, but I never asked you to do such a sacrifice.
Last edited:
mobilehomer
Well-Known Member
I am not referring to "authority" but EXPERIENCE!!! I can explain it to you, but I can't understand it for you!!
One of the biggest difficulties to fully understand this matter is that the information that is out there is either incomplete or completely incorrect. And this is true even for the official info coming from DJI. I fully agree with @Yorkshire_Pud that sports mode does not disable VPS, and there are tons of flight reports that vouch for that. Still there are articles like the one I posted previously that claim the opposite. They can be brushed off as inaccurate non-DJI sources. The screenshot below is from the official FM for Mavic 2 Pro/Zoom that I re-read upon invite. How can one really be sure of anything when even the manual is full of BS. SMH
Last edited:
Buddy, If you do not understand what the exact issue in discussion is and haven't realized that the plots that I posted from the logs provide the evidence that contradicts the claims of "EXPERIENCE" (in all capitals), I can't understand that for you. However, if you so wish, please go ahead and keep making generic statements on what we need to believe as reality, with no connection whatsoever with the issue at hand.
Can I ask you what contribution are you intending to bring to this thread? You did not bother to look at the actual issue at the origin of the disagreement with Meta4. Your only interventions have been to attack me for my style of writing and for having dared to present evidence from logs in disagreement with the claims made by your buddy. That to me qualifies as trolling, but I am open to hear your motivations
Last edited:
On CsvView, if you look at the flyCState signal, it only shows a generic state called GPS_Atti (weird name) for all the portions of the flight under closed loop control (i.e., P-GPS or P-OPTI) . Phantomhelp does the same but calls the state P-GPS. To see when actual GPS or VPS is used for position control, on CsvView plot the signals visionUsed and gpsUsed under State Signals -> General or the signals isVisionUsed and isGPSUsed under State Signals -> OSD. I am not sure what the difference between the two pairs is, but for the logs that I have analyzed they coincide. Unfortunately the csvView plotter plots both the region where a signal is active and that where is inactive in predetermined colors (instead of leaving the second white), which makes the analyis of a plot with both signals more laborious than needed.
Last edited:
I do wonder at times if their manuals suffer from translation problems.
With regards to the underlined, obviously that is in error as written ...... but.....VPS may not be available at large angles of tilt, I have not thought of that until now.
When I use sports mode out doors it is used to allow greater angles of tilt, generally for 'speed runs' but occasionally to fight a gust, plus I would tend to have the drone relatively high (100ft +). That makes me wonder if the underlined was written with angle of tilt limitations (if they exist) in mind but without explaining why VPS may not function.
With regards to the underlined, obviously that is in error as written ...... but.....VPS may not be available at large angles of tilt, I have not thought of that until now.
When I use sports mode out doors it is used to allow greater angles of tilt, generally for 'speed runs' but occasionally to fight a gust, plus I would tend to have the drone relatively high (100ft +). That makes me wonder if the underlined was written with angle of tilt limitations (if they exist) in mind but without explaining why VPS may not function.
To me this is a further clue that points in the direction that DJI conflates VPS and OA, as I have often found their manuals very misleading in that regard. More than a few times one was mentioned when I was expecting the other and flying experience did not reflect what was written. Seeing this confusion made in the manuals does not give me much confidence that some level of confusion was not carried into the firmware implementation
Really?
Or are you just confused about yaw errors, which are not what you seem to be describing.
A DJI drone without GPS does not go crazy or fly away anywhere.
It just does not happen.
No ... VPS does not drown drones.
VPS can have trouble providing horizontal position holding over water, but it does not cause drones to autoland in water.
That requires the flyer to pull down on the left stick.
What you are complaining about here is a subtle issue with translation.
The information you've highlighted is not complete BS.
It would have been more accurately translated to say that when the drone is flying at speed in Sport Mode, the obstacle avoidance system cannot function properly because the forward sensors cannot see far enough forward when the drone is tilted forward at 30°.
You think that the software was created by the people that translated the manual ?
The software was obviously created first by highly skilled professionals.
The manuals were translated later into many different languages, by people not quite so expert.
TL;DR. Summary:
1) you clearly know the correct translation because you know the original Chinese, right?
2) Engineers do not write manuals, but they provide the material to be put in it. Translated manuals are continuously vetted and corrected to make sure they represent the knowledge of the engineering team. Liability is involved.
3) This is what should make f-ups in the manuals particularly worrysome
Long version for masochists:
The Forward, Backward, Lateral Vision Systems and the Upward Infrared Sensing System are disabled in S-mode, which means the aircraft cannot sense obstacles on its route automatically
a subtle issue with translation. I would call a big effin blunder and I do not know of any translator, as horrible as they might be, that would randomly introduce the names of three subsystems that have nothing to do with the subject, unless they were present in the original. That would be such a subtle translation issue to render the whole manual a useless paper weight.
If you had worked on an oversea engineering development team for a product destined to the general public, you would know that product manuals (by reputable companies, of course) are not just pieces of garbage translated by incompetents who know nothing about the project. Especially for products that might expose the company to liability, like falling from the sky on someone's head, there is a huge effort to make sure that the manual describes the operations as they are implemented by the firmware. Since the information to put in the manual is provided by engineers and the translation is continuously vetted and corrected, my educated guess is that there is a very high likelihood that any confusion present in the final version of the manual reflects some level of confusion in the firmware rather than creative storytelling by an inspired translator. Chinese project managers do not particularly appreciate freewheeling creativity. I really doubt that DJI, with the dominant position it has gained in important markets as the English speaking countries, would put out a product manual not vetted by engineers. For this reason, the fact that the manual does not reflect the actual operations should be way more worrying for the user of the product.
1) you clearly know the correct translation because you know the original Chinese, right?
2) Engineers do not write manuals, but they provide the material to be put in it. Translated manuals are continuously vetted and corrected to make sure they represent the knowledge of the engineering team. Liability is involved.
3) This is what should make f-ups in the manuals particularly worrysome
Long version for masochists:
You guys are joking, right? Now I understand it, all those posts telling me that I should bow to expertise were nothing but a plot to make newbies like me, tired of the continuous verbal dueling, agree by inertia to something as preposterous as this. Because, honestly, when you say without the hint of a doubt that "It would have been more accurately translated to say..." there are only two possibilities: you either know the original Chinese or you are making this up. Considering the respect that surrounds you in here, I would hope it is the former. Let me remark though that if they really wanted to say what you stated, I would not call
The Forward, Backward, Lateral Vision Systems and the Upward Infrared Sensing System are disabled in S-mode, which means the aircraft cannot sense obstacles on its route automatically
a subtle issue with translation. I would call a big effin blunder and I do not know of any translator, as horrible as they might be, that would randomly introduce the names of three subsystems that have nothing to do with the subject, unless they were present in the original. That would be such a subtle translation issue to render the whole manual a useless paper weight.
Can you please stop assuming that everyone else is an idiot? No, I do not think that software engineers do translations overnight. They would have no time, considering the extent of a working day in China. However, I did work on enough projects, writing control code with engineers of several chinese companies that reading the definition of "highly skilled professionals" instantly brought a big smile to my face. Sure.
If you had worked on an oversea engineering development team for a product destined to the general public, you would know that product manuals (by reputable companies, of course) are not just pieces of garbage translated by incompetents who know nothing about the project. Especially for products that might expose the company to liability, like falling from the sky on someone's head, there is a huge effort to make sure that the manual describes the operations as they are implemented by the firmware. Since the information to put in the manual is provided by engineers and the translation is continuously vetted and corrected, my educated guess is that there is a very high likelihood that any confusion present in the final version of the manual reflects some level of confusion in the firmware rather than creative storytelling by an inspired translator. Chinese project managers do not particularly appreciate freewheeling creativity. I really doubt that DJI, with the dominant position it has gained in important markets as the English speaking countries, would put out a product manual not vetted by engineers. For this reason, the fact that the manual does not reflect the actual operations should be way more worrying for the user of the product.
- Status
Similar threads
DJI Drone Deals
New Threads
-
Last Week's Most Popular Topics (November 2, 2024)- Started by msinger
- Replies: 0
-
-
Latest version of FlyApp for RC Pro??
- Started by Filmarik
- Replies: 6
-
Is there a 1 click way to delete all photos saved to the smart controller?
- Started by matt@tcdrones
- Replies: 1
-
Forum statistics
