Gimbal Pitch on resume
When I resume a mission with the mapping component with my Air 2S, the gimbal pitch sets to 0 and does not reset to the correct pitch, e.g. -45.
Popular Resources
-
<% blocks.forEach(function(block, index) { %>
-
<% if (imageHeight) { %>
<% } %>
<% if (block.name) { %><% if (block.html_url) { %> <%= block.name %> <% } else { %> <%= block.name %> <% } %>
<% } %> <% if (block.description) { %><%= block.description %>
<% } %>
<% }) %>
Comments
10 comments
This is due to the bug in the DJI SDK (no gimbal telemetry). They claim it will be fixed in the next version. For now, you can roll the gimbal wheel manually.
I wouldn't think you need two way telemetry communication to send a "set to x pitch" command where x is the pitch that the mapping component was set to. Why are you able to set the pitch when the component begins but not when it resumes?
Wheny you disengage the mission, dronelink reads the current pitch of the gimbal and saves that value in order to generate the reengagement mission (which is the mission that happens behind the scenes during resume). When it goes to read the pitch in the case of the Air 2S, there is no telemetry, so it mistakenly thinks it is zero. It might be possible to implement a work-around based on knowledge about the plan that was being run, but part of the issue is that the Map component, like many others, actually allows the user to manually modified the gimbal angle during the mission, and there is no way for us to know if this has happened, again because of the no telemetry issue.
Thank you for the reply.
Something keeps setting the gimbal pitch to 0 when the mission is interrupted, whether it be DJI or Dronelink. If you cannot store the user's modifications to the gimbal pitch during flight, please either remove the "reset to 0", or, if that is not Dronelink setting it to 0, please add a "set to original mapping component pitch" upon resume.
And I don't want to be argumentative, Jim... but when you say "it mistakenly thinks it is zero" when the telemetry is read... why would Dronlink write a mapping component that does nothing on resume when it finds that the gimbal pitch is zero? Why wouldn't the choice be to do something vs nothing? When nothing is done at 0 gimbal pitch, you don't end up with mapping photos, you get 1/2 sky photos :)
You also say "When you disengage the mission, dronelink reads the current pitch of the gimbal and saves that value in order to generate the reengagement mission". You just need to update that function to "fail" to the current component's pitch, instead of 0. That would solve my problem and shouldn't create others if it is just a fallback for when telemetry data fetch fails.... if you are worried about overwriting the user's gimbal adjustments during the mission, those are being lost anyway, see first paragraph.
Exactly, DJI introduced a bug, and we need to implement a temporary work-around until DJI fixes this bug.
We wouldn’t do this intentionally, of course. This is a case of DJI introducing a bug, which then causes another bug because our code always assumes that gimbal telemetry is available, which has been true on every single other DJI drone for the last several years up until this point.
Understood, thank you!
I am not much of a programmer, but handling how things break does seem like a chore; you have my sympathy.
Please let me know if you patch that little bug before DJI gets around to it.
Thank you for your help :)
I just pushed out a patch for this if you want to test it.
Hi Jim! I am up for testing that. I will try again tomorrow with my Air2S where I also saw this issue.
Does the patch require me to update Dronelink on Android or is it implemented when I see the 'kernel upgraded' message via automagic?
Hi Jim, how we can test the new patch? i,m having trouble mapping an area for several days, your response will much appreciated .Air 2s gimbal problem
This fix is already live in production (kernel upgrade).
Please sign in to leave a comment.