Gimbal control offset

[ghost]

In OSDK and OSDK-ROS versions below 4.x we used to control the gimbal using the gimbalAngleCtrlCallback callback which relies on setAngle in dji_gimbal.hpp. dji_gimbal.hpp is now deprecated and it is advised to use cameraManager but since that has no mention of gimbal I assume you mean gimbalManager.

Before OSDK 4.x calling setAngle with mode=1, roll=0, yaw=0, and a nonzero value for pitch and speed, would result in movement in pitch while yaw would follow the drone, meaning that the gimbal would always point forward, be horizontal in roll, and have the desired pitch angle. In other words, yaw was referenced to the body frame.

With OSDK 4.0.1, the only exposed non-deprecated gimbal control functions are rotateSync and rotateAsync in gimbalManager. No matter how we set the mode in GimbalModule::Rotation and the gimbal mode in DJI Go and invoke setAngle, yaw=0 will always make the gimbal point north. We need yaw to follow the drone or be set in the body frame instead of the global frame. How can we achieve that? We could of course reuse the deprecated interface but that does not seem like the right solution.

We are using M210V2 and M300.

[dji-dev]

Agent comment from kyle.cai in Zendesk ticket #41430:

Dear developer ,

Thank you for contacting DJI.

Sorry for the trouble and inconvenience caused to you. 1、The gimbalManager of OSDK used to control and set the gimbal. 2、The gimbal control in OSDK 4.x is based on the global frame. Due to product evaluation, the API under the body frame coordinate system is not currently considered, this may need to calculate the aircraft heading and control the gimbal direction by yourself now. 3、OSDK 4.x version will consider opening API to set gimbal mode (FPV, YAW Following, Free), you can continue to follow OSDK related function updates and releases.

Thank you for your understanding and support, hope you have a nice day.

Best Regards, DJI SDK Support Team

[ghost]

According to the inline documentation of GimbalModule::Rotation, the mode should affect the control. This is not the case.

[ghost]

We have attempted 2) by calculating the drone compass heading from the attitude quaternion and controlling the gimbal based on that. It works as expected for M210V2 and XT2 but not for M300 and H20T. The details below were observed with and M300 and H20T.

After accounting for the static 90 degree offset between the drone compass heading and gimbal compass heading due to them being referenced to east and north respectively, we see a dynamic offset between them and also what seems to be a sudden "step" offset. The dynamic offset varies from 5-8 degrees. The "step" offset non deterministically suddenly changes the offset between drone and gimbal compass heading up to ~45 degrees.

[dji-dev]

Agent comment from kyle.cai in Zendesk ticket #41430:

Dear developer ,

Thank you for contacting DJI.

1、Using the drone attitude quaternion to calculate the YAW angle to control the gimbal may need to consider the position relationship between the aircraft and the center point of the gimbal.(PTZ axis and UAV center point).

2、Please check whether the gimbal control is limited by the angle limit.

Thank you for your understanding and support, hope you have a nice day.

Best Regards, DJI SDK Support Team

[ghost]

Please elaborate on 1. We don't see how a displacement of a few centimeters can result in an offset of several degrees, especially since it is not constant. Also this does not explain why the gimbal is not centered in yaw upon reset from the OSDK or the pilot app when the OSDK is not used.

Regarding 2, the gimbal is not limited by the physical limit.

[dji-dev]

Agent comment from kyle.cai in Zendesk ticket #41430:

Dear developer ,

Thank you for contacting DJI.

Sorry for the trouble. According to your current information, it does not seem that OSDK controls the gimbal: "Also this does not explain why the gimbal is not centered in yaw upon reset from the OSDK or the pilot app when the OSDK is not used."

I would like to trouble you to confirm, if you don’t use OSDK to control the gimbal, is there a problem with only using the remote controller to control the gimbal? if so, It is recommended that you send an email to support@dji.com to confirm whether it is a problem with the product itself.

about "offset of several degrees" We will further reproduce and confirm this issue on M300, and we will promptly feedback with you if there is any progress.

Thank you for your understanding and support, hope you have a nice day.

Best Regards, DJI SDK Support Team

[ghost]

We are controlling the gimbal with OSDK during normal operation. I was trying to provide a bit of context to explain that we think it is a problem with the M300/H20T. The following lines aim to provide more context.

When we recenter gimbal yaw in the Pilot app (without our onboard computer connected) the gimbal most of the time does not look straight forward but is off in the clockwise or counter clockwise direction. This is obvious to the eye.

Performing the same test with the onbaord computer connected, allowing us to have access to drone (attitude quaternion) and gimbal heading, displays an offset of up to 8 degrees between drone and gimbal heading after accounting for the offset caused by NED vs ENU. The offset is not static.

We have also experienced the difference increase to 90 degrees (after accounting for NED vs ENU) and start drifting when yawing the drone.

[dji-dev]

Agent comment from kyle.cai in Zendesk ticket #41430:

Dear developer ,

Thank you for contacting DJI.

I test it with M300(firmware: 01.00.0211) H20(firmware：01.00.0211) and OSDK master sample code: main_sync.cpp the result the result is as expected: ​ ​ ​

Could you please test it with the sample code ,In order to further confirm whether it is a product problem or abnormal use ？

Thank you for your understanding and support, hope you have a nice day.

Best Regards, DJI SDK Support Team
inline1406753770.png
inline-885165330.png
inline1261157201.png

[ghost]

The suggested changes do not compile. Please provide the file (including the implementation of subscribeQuaternion).

[dji-dev]

Agent comment from kyle.cai in Zendesk ticket #41430:

Dear developer ,

Thank you for contacting DJI.

Please check the attachment(main_sync.cpp), just for test this issue.

Thank you for your understanding and support, hope you have a nice day.

Best Regards, DJI SDK Support Team
main_sync.cpp

[ghost]

This is the result of running the sample script option m from the attachment above. The video clearly displays a clockwise offset. The video is available here (Gimbal_Offset.zip) or at the link below: https://drive.google.com/file/d/1yfWPECKPm6ah2xfD9jMK3d5DUPX3av4e/view?usp=sharing

We have confirmed the issue on two M300s. The video was filmed with the following equipment: M300: 01.00.0211 Remote: 01.00.0213 Gimbal: 01.00.07.47 Zenmuse H20T: 01.00.02.11 OSDK: 4.0.1 (with main_sync.cpp modified as instructed)

[dji-dev]

Agent comment from kyle.cai in Zendesk ticket #41430:

Dear developer ,

Thank you for contacting DJI.

There will be a certain angle error in the current control of the gimbal. You can read the YAW value of the drone's head and the gimbal YAW when starting up. Regarding the cause and accuracy of the error, we will submit for further confirmation ​

Thank you for your understanding and support, hope you have a nice day.

Best Regards, DJI SDK Support Team
inline1931987728.png

[ghost]

A minor offset is expected but ~10 degrees is completely unacceptable. The .03 degree offset you have marked on the video screenshot does not match reality. Please look at the gimbal in the video. It is clearly off by ~10 degrees although it is reported to be off by only .03 degrees.

We are looking forward to the results of your confirmation.

[ghost]

@dji-dev what is the state of this?

As mentioned in the previous post, the numbers marked on the screenshot do not match reality. In practice, we see a non-static offset of ~10 degrees between the gimbal heading marked on the screenshot (check the video) which effectively makes the gimbal control unpredictable and unfortunately useless at the moment. We have reproduced on 3 M300's.

[lorenzave]

@dji-dev just to add to @lorenzmhe, the test on the three M300s was done using the modified sync.cpp you provided, ruling out any ROS or own implementation issues. From what it looks like is that the measured yaw from the drone and gimbal report different values and when trying to set the gimbal with the drone's yaw we get an offset of ~10 degrees. We would mainly like to fix the gimbal looking straight as it was possible in the previous implementation, setting it relative to the drone and not in global frame.

[dji-dev]

Agent comment from kyle.cai in Zendesk ticket #41430:

Dear developer ,

Thank you for contacting DJI.

About this issue, the current temporary solution can use the following parameters to set gimbal YAW and random headers, and we will continue to improve related functional APIs in the future. ​

Thank you for your understanding and support, hope you have a nice day.

Best Regards, DJI SDK Support Team
inline1689481410.png

[AleksandrBon]

Dear @lorenzave and @lorenzmhe,

We have the same problem with H20 and X-Port gimbals (and because P1 based on X-Port we are sure that it also has same problems). When gimbals headings physically aligned with drone heading, in telemetry heading values can mismatch up to 30 degrees. We using PSDK 2.2.1 and OSDK 4.1.0. We understood that this mismatch originating from the fact that gimbals reporting magnetic heading (maybe even non-corrected by declination), whereas drone reports GPS heading, and as a consequence this mismatch not constant. Have you found some solution to calculate/estimate and remove this offset during the flight?

Thanks in advance!

[ghost]

Hi @AleksandrBon

We have implemented functionality to measure the offset before flight and use the value to correct the offset during flight. It is not ideal but it gets the job done.

[AleksandrBon]

Hi @lorenzmhe ,

Thanks!