Please select Into the mobile phone version | Continue to access the computer ver.
DJI Vehicle threads hogging my CPU
117 1 2-2 16:38
Uploading and Loding Picture ...(0/1)

United States

Hi all,

I am using the OSDK 3.9 on a BeagleBone Black running debian, flying the M600 Pro. My application uses a single thread, and there's a particular section that is very timing-critical. I enter a tight loop for roughly 5 seconds, and it is imperative that I run this loop quickly. Typically my loop iterates every few hundred microseconds, which is good. However, I notice that there are occasionally large chunks of time skipped and my loop does nothing for around 3-10 miliseconds. For my application this is dangerous.

Sometimes it's just one "blip" during the 5-second section, more often several in a row, and occasionally the entire section is only able to iterate every few miliseconds for the entire time it runs. It's particularly this last case that is especially dangerous.

I'm quite sure there is little variance in the runtime of my own code (certainly not the orders of magnitude slowdown I'm seeing), and can only assume that some other thread that DJI's Vehicle class spins up is jumping in to do some work (monitor comms, etc).

In fact I notice in dji_vehicle.hpp that when the Vehicle is initialized it sets up a SerialReadThread, a CallbackThread, and a USBReadThread. I suspect these to be my culprits.

Does anyone know if I can signal these threads to stop until my timing-critical work is done? Or other ideas as to what else might be causing these delays?

As far as my interaction with the DJI OSDK, all I'm doing is:

LinuxSetup linuxEnvironment(argc, argv);
Vehicle* vehicle = linuxEnvironment.getVehicle();
if (vehicle == nullptr) {
        printf("Vehicle not initialized, exiting.\n");
        return -1;
vehicle->mobileDevice->setFromMSDKCallback(QueueSDKCommand, &linuxEnvironment);

at the start of my program (and I can confirm my QueueSDKCommand callback is not getting called during this section). Short of something else on the OS (to which I haven't added anything beyond the stock disk image) I can't think of anything besides these threads that would be grabbing these vital miliseconds from my CPU.

Open to any and all thoughts, thanks in advance!

2-2 16:38
Use props

South Africa

Is there an activate action when the delay occurs? Is it related to activation?It is best to provide the relevant terminal log that can withdraw the delay to confirm which part of the delay occurred
2-3 00:22
Use props
You need to log in before you can reply Login | Register now

Credit Rules