Task timeout on velocity control when switching from manual to OSDK.

[crish4cks]

Hi, I have modified the moveByPositionOffset method in order to use velocity control in place of position control. If I perform all the operations using the OSDK api, it seems to work fine with the simulator, but if I use first the radio controller to take off and move in air the drone manually (with the switch set to F) and then I use the APIs to land, take off again, and move, the last operation, namely the move, goes in task timeout. What could be the issue?

We are using a DJI M100 with a Manifold and OSDK 3.9. Here is attached the code: velocity_ctrl.txt

Thank you in advance for your time.

Best regards, Cristiano Urban.

[dji-dev]

Public comment from Bruce Cheung in Zendesk ticket #30571:

Dear Customer,

Thank you for contacting DJI.

If you do not modify the moveByPositionOffset method, will the same problem occur if you use the native sample for this operation? Was the operation in problem an actual flight test? If so, it is recommended to provide flight data (export from DJI Assistant2).

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

Best Regards, DJI SDK Support Team

[crish4cks]

Hi, thank you for your answer. First of all, I forgot to say that the last move after take off does not time out immediately but only once it has performed the operation. So, the move works fine but at the end it stucks going in time out and returning ACK::FAIL. That said, I've tried to use the original moveByPositionOffset provided by the OSDK and after some tests with the simulator I can state that the same issue doesn't occur in this case. But the point is that I need to control the drone using the function I attached on the first message, because it seems to work fine on both x-y and y-z planes on simulations. The original moveByPositionOffset does not work fine on z axis.

We have tried the drone in the real world only once and we had some issues also with the take off. We noticed a quite obvious discrepancy of behavior between the simulation and the real test.

Anyway, I will provide the flight data as soon as possible. Thank you for your time.

Best regards, Cristiano Urban.

[crish4cks]

Here we are: flight_data

[dji-dev]

Public comment from Bruce Cheung in Zendesk ticket #30571:

Dear Customer,

Thank you for contacting DJI.

It is not recommended to directly modify the moveByPositionOffset to the velocity control method, but it is recommended that you can write and encapsulate the required function according to velocityAndYawRateCtrl or flightCtrl API.

In addition, what is the actual flight situation corresponding to the flight data you provided? Can you describe it briefly?

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

Best Regards, DJI SDK Support Team

[crish4cks]

t is not recommended to directly modify the moveByPositionOffset to the velocity control method, but it is recommended that you can write and encapsulate the required function according to velocityAndYawRateCtrl or flightCtrl API.

Yes, of course, this is temporary. I will add a method with a different name instead of modifying the moveByPositionOffset. The point is that I don't understand what can be the problem with that function when switching from manual controls to software. If I do all the operations with the APIs, it works fine.

In addition, what is the actual flight situation corresponding to the flight data you provided? Can you describe it briefly?

The flight data I uploaded is related to a simulation, not to a real flight test. The next flight test is scheduled for the next week (hopefully on tuesday or thursday, depending also on the weather), so I will try to upload the real data next week in order to give you more informations.

Anyway, the data I provided corresponds to the following steps: 1) Take off and bring the drone to a certain position in air with the manual commands (switch positioned to F) 2) Launch a TCP server (written in C) on the Manifold 3) Launch the client (a Qt 5 GUI with a drawing area), and connect to the server running on the Manifold obtaining the authority 4) Send a landing command from the client to the server 5) After the drone is on ground send a take off command to the server 6) The take off command consists of a monitoredTakeOff + a move action on z axis in order to reach the height set by the user (for example 5 meters from ground) 7) The monitored take off works fine, also the move action works fine but at the end, instead of returning ACK:SUCCESS, it stucks for a certain number of seconds (the famous 40 seconds) and then returns ACK:FAIL with a "Task timeout!" message.

NOTE: the move method used on step 7) is the one I uploaded on the first message (velocity control)

If I use the original code of moveByPositionOffset this kind of situation does not happen, but as I said previously, while with the velocity control I obtain a shape that seems to be precise on both [x-y] and [y-z] planes, with the original moveByPositionOffset (position control) I obtain something that is coherent only on the [x-y] plane. If I try to draw a shape on the [y-z] plane, I obtain something that is flattened on the z axis.

Here below you can see some screenshots of the client:

Thank you in advance for your time.

Best regards, Cristiano Urban.

[dji-dev]

Public comment from Bruce Cheung in Zendesk ticket #30571:

Dear Customer,

Thank you for contacting DJI.

The point is that I don't understand what can be the problem with that function when switching from manual controls to software. Doing all the operations with the APIs it works fine. ==> The problem you are referring to is that manually switching to program control will result in "Task timeout!"The message? If you use the original code of moveByPositionOffset this kind of situation does not happen? If so, also suggest you can write and encapsulate the required function "according to velocityAndYawRateCtrl or flightCtrl API.

If you have any questions about the actual flight test, please feel free to contact us again.

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

Best Regards, DJI SDK Support Team

[mehow-juras]

I'd like to mention that we are experiencing a very similar issue. Our testbed uses an onboard Raspberry Pi connected to Matrice 100. It runs very smoothly in the simulation, however, does not seem to respond when tried out in real life.

Please find an example of how we set the flag and control data.

uint8_t ctrl_flag = (
        Control::HORIZONTAL_VELOCITY |
        Control::VERTICAL_VELOCITY |
        Control::YAW_RATE |
        Control::HORIZONTAL_BODY |
        Control::STABLE_ENABLE
    );

DJI::OSDK::Control::CtrlData data(
          ctrl_flag,
          (float32_t) 0,
          (float32_t) 0,
          (float32_t) 5,
          (float32_t) 0
          );

vehicle->control->flightCtrl(data);

I'd love to hear some more feedback on this topic.

[mehow-juras]

I've managed to resolve the issue. It was most probably caused by insufficient GPS coverage indoors, hence affecting the setup of the flags for HORIZONTAL_VELOCITY. That's why the drone did not respond to the commands. I've changed the mode to

uint8_t ctrl_flag = (
        Control::HORIZONTAL_ANGLE |
        Control::VERTICAL_VELOCITY |
        Control::YAW_RATE |
        Control::HORIZONTAL_BODY |
        Control::STABLE_DISABLE
    );

I hope it's helpful.