Hi all,

I am emailing DJI support and will post any solutions they offer here as well, but I thought I'd ask anyway if anyone has solved this particiular issue. I am trying to run the mop example from the OSDK sample code on a M300. I am using a linux virual machine as a "dummy" onboard computer, I have it connected to the OSDK adapter board UART port via a USB -> Serial cable and the OSDK USB port with a male-to-male USB cable. I am not using any of the advanced sensing stuff and am compiling with CMake. Baud rate is 115200.

The problem is, the "accept" part of creating a mop channel doesn't work for me. I get an error code of 5, which corresponds to MOP_NOTREADY. I have tried waiting for 30 seconds after activation to try to create the mop channel but I still get MOP_NOTREADY. If anyone has ever successfully created a mop channel on the M300 I would be interested to hear how you did it!

I have attached a picture of the output and here are some specs:

OSDK 4.1 for Linux

  

M300 RTK 02.04.0102

  

Remote Controller 02.04.0103 / 3.4.8.74

  

Battery 1 01.02.05.31

  

Battery 2 01.02.05.31

I'm facing the same issue. Did you find any solution? thanks

djiuser_jJXPkDigfbXw Posted at 9-10 08:16
I'm facing the same issue. Did you find any solution? thanks

Hi,

Yes I did, there's a lot to explain so I'll try my best not to miss anything.

First of all, the error code. This means that the USB did not initialize successfully. You must have the USB working for the MOP API's to work. If it were to work successfully it would block, waiting for a MOP client, rather than return the "not ready" error code.

How can you tell if the USB is working? If you are on Linux like me then when you plug the USB A male to male cable from your Linux machine to the Onboard SDK adapter box you should see that the DJI device enumerates properly on your Linux machine. Use dmesg and scan the output for any error messages, and that a DJI device has been detected and started an RNDIS server over the USB. Finally, use ifconfig and see if there is a new network interface that has populated, for me it shows up as "usb0".

If this new network interface is there, then the hardware layer is ready to go and you just need to make sure you use the OSDK correctly. This means making sure that you have the right USB and UART ports that you are setting the OSDK up with. For me this was /dev/ttyACM0 for the USB and /dev/ttymxc2 for the UART - but they could be different for your machine.

On compiling the OSDK:

Initially I tried to modify the CMakeLists.txt files because I thought all of the file nesting was too confusing and I wanted something simpler. I ended up just messing things up because I assumed that some of the libraries were for advanced sensing stuff and did not include them because I only wanted to make MOP work. I would reccomend not modifying the CMakeLists at all and just installing all of the dependencies it requires. For me this was:

libudev-dev
libusb-1.0-0-dev
libavcodec-dev
libswresample-dev
libavfilter-dev

I used apt-get install for each of those. There are some samples in the OSDK that require OpenCV, but you can disable those by passing a flag to cmake (-DADVANCED_SENSING=OFF). It's confusing because that flag just disables those samples, not building the advanced sensing static library. You actually do want advanced sensing just not those examples - so the flag works for that.

This may be optional, but I also used the -DOSDK_HOTPLUG=ON CMake flag because I wanted ALL of the USB features to initialize correctly in case some of them were needed for MOP to work.

So for compiling the OSDK my advice is (assuming you are in your build dir):

cmake .. -DOSDK_HOTPLUG=ON -DADVANCED_SENSING=OFF

Now that everything is compiled correctly the MOP sample should have been built and should run correctly. Again, if it is all working it will block and wait for a client.

Working beyond the sample I do have a few recommendations, which is that the OSDK api layer that is open source and sits on top of their "linker" is extremely shoddy. For example, the mop_server and mop_client classes are not coded correctly at all. I have rewritten those using the PSDK versions of those classes as reference. The PSDK MOP api works in the same way and the examples for the PSDK actually work correctly. What I mean by the OSDK versions being shoddy is that the "server" does not handle multiple clients or client connection/disconnection/reconnection at all. The actual linker calls that the open source api uses work fine, it's just the OSDK api layer that makes those calls that is not correct.

Finally, make sure you #define OSDK_HOTPLUG and #define ADVANCED_SENSING in your own code too in order for the USB to initialize properly. If you see during the setup output that the advanced sensing stuff has error messages that means that the MOP is not going work either. I don't know how they are related but that is what I have observed so far.

Hope that helps, good luck!

Thank you very much for your response, it gives a lot of insight. And I'm sure that it will help a of people that face this issue.

It turned out that the cause of my accept failing was very simple. I simply had to run as root (even though my  username belongs to the dialout group). Stupid me for not trying it earlier.