I was wondering if it is possible to access an HTTP server running on the onboard computer from a device (mobile or laptop) connected to the remote control on the ground. From the documentation, the uplink/downlink speeds of 24kbps / 16Mbps are satisfactory for our application.
Going over the available SDKs, the "SDK Interconnection" or "MOP" caught my attention that offers send and receive functions for Onboard and Mobile SDK (Payload as well). However, this means that the send/receive from the ground are exposed on an android based SDK, i.e.
UART Lightbridge USB
Onboard PC ---> OSDK ----> DJI drone ------------> R.C. ----> Android ---> MSDK
From this alone, it seems that we would need to develop network interfaces that are sending and receiving via the corresponding OSDK and MSDK methods. This might be easier said than done - especially for the android device.
My questions are:
Is there a smarter way to do this?
Is the implementation of Mobile SDK available? If so we can port the send/receive code to a Linux box to simplify the code
The MSDK is heavily encrypted.
I've been doing some reverse engineering on it. It's not easy, recommend older versons since they not encrypted.
There's no opensource if that what you asked. Will never be.
Everything sent from the drone is dumldore messages. You can decode them without the MSDK, but it's not completly straightforward.
The messages are partly documented here:
https://github.com/o-gs/dji-firmware-tools/blob/master/comm_dissector/wireshark/dji-dumlv1-proto.lua
If I were you I would connect a 4g modem to the onboard computer. Saves you a lot of time.
Related
Is it possible with OSDK4.x to command payload and flight actions and use the DJI Assistant 2 for Matrice concurrently?
Previously, we have been using the M210V1 with OSDK3.9. Using the DJI Assistant 2 for Matrice to simulate the drone flight is key to our ability to develop our system.
However, the M210V2 and OSDK4.x require the USB port of the drone to be connected to the Linux device running the OSDK, otherwise any payload (GimbalManager, CameraManager) actions throw an error - such as GimbalManager::resetSync.
This is not ideal for development since we cannot use the simulator (on MacOS) and connect the USB to the Linux device (there is only one USB port on the drone). Has anyone solved this problem?
Yes and no.
For 210, There is only one USB2 port and it is either for connecting to PC side assitant2 or connecting to onboard PC to get osdk stream. You can think it as a bug in design phases.
Yes, you can run part of osdk and run the simulator without the payload camera-related function. If I recall correctly, I can still "rostopic echo" the Gimbal orientation topic from the drone. Its only image topic that is disabled. You can simulate the GPS based flight in simulator and try to set gimbal direction. I remember this was achievable.
There is no way for you to run both simulators and get payload functions such as images from OSDK. so to get both image running and drone running in simulator that's not achievable.
If you really wants both at same time. I suggest you move to M300 which they have dual USB C interface for both camera stream and for simulation.
I would like to know all of Lightbridge, Phantom 4 Pro, Inspiron 2's controller and drones communication method.
I have many drones from DJI including Phantom 4 Pro, Inspire 2, and Matrice 100.
I want to create a Lightbridge system that is mounted inside the controller through PC programming.
Because the DJI drones I purchased connect the mobile device and the controller with USB cable, and the controller and the drone communicate with the Lightbridge, so the controller must be in the middle of the communication system, but I just want to control the drones directly through my PC.
As a result, how can I imitate the Lightbridge system to communicate with my PC, control (takeoff,landing etc.) , and capture live images.
So I'd like to know about the Lightbridge that helps.
Lightbride is a proprietary protocol. That means we (I work at DJI) do not disclose or document the details of its implementation.
On another hand, removing the remote controller would mean you create/provide your own transmitter which add quite a lot of complexity.
The best way for you to control the aircraft from the PC at this point is to write a mobile app as a bridge and control the app through your PC.
Now, this can be done in a wired manner:
You could write an Android app with the mobile SDK on a device with ethernet such as Odroid and chain it all together.
I need to run tests against physical mobile devices, and need to deploy unit tests to many concurrent devices at the same time.
Conceptually, this is similar to the Xamarin Mobile Test Cloud, or Microsoft Mobile cloud... but I need an on-premise equivalent so that I can test Bluetooth and GPS features
I'm looking to test 7 to 14 physical devices all connected to the same USB hub.
Question
How many devices can a single Mac / Windows machine talk to over a single USB port?
What are the power considerations I need to keep in mind while selecting hardware?
Here is a visual example of what I imagine, however this device is focused on charging, not connecting a USB backplane to a computer.
Per USB controller you can have a 127 devices (128 minus the controller), bu I am not saying you can simultaneously have 127 devices communicating to the host and maintain any type of data throughput, that is a different story....
The core USB issue with a lot of devices is the power draw. We use special Y cables that have a data only side and a power only side even when using the so-called "powered" USB hubs.
The really good cables that do this are typically found via companies that cater to audiophiles and as such are typically very expensive and work great but are overkill for this usage. But also avoid the cheap Y-cables where the data-only side is "ungrounded" as you will have data transfer failures. Low quality cables will kill data through-put and have you running in circles chasing test failures.
Consumer external USB hubs are not created equal and wildly vary in their power output and simultaneous throughput across each port. While most will do well with one/two devices talking simultaneously, many start failing when 4-8 devices are all talking. Also trying to cascade them for increasing the number of ports can cause failures across the entire chain. Make sure you have a good return policy where ever you can buying it from.
You did not stated the testing framework, but some Appium info:
For Appium-based Android testing I have use a combination of:
Android<-USB->Host(adb)
8 devices is about the threshold for reliable simultaneously (bi-directional) testing
Android<-Wifi->AP<-Host(adb)
A DHCP server handles assigning an IP to the Android device via MAC address so we can create a static mapping of ports to IPs for remapping via adb
8 simultaneous Appium servers (thus devices) running per Window server/host is about what to expect
This works for about 32/64 devices per dedicated AP.
Remember the AP has to be ~4/5 feet away from the devices for proper signal attenuation
Mobile cloud datacenters use EMI / faraday cages to isolate each mobile device rack where multiple servers, an AP and the devices are installed within each rack
Android<-USB2Ethernet<-Host(adb)
Not all devices support OTG, so this is not always an option, but works great.
A DHCP server is required just like the Android<-Wifi->AP setup
iOS is a totally different can of worms:
4 iOS devices connected to a Mac is about all you can achieve with reliable results.
Remember a separate Xcode Instruments is spun up per Appium server on the host.
Mac Minis work great for dedicated Appium test servers.
In terms of GPS testing, mocking is the easiest way to go. There are hardware devices designed for GPS testing that are use by the top tier app developers (mapping, traffic, avionics, etc..) but for an ad-hoc in-house device lab these are usually way to expensive to purchase and setup (EMI / faraday cages are needed enclosing the device and the GPS injector antenna).
Bluetooth can be a big problem in a device lab due to interference, pairing issues, etc..., having a number of devices in close proximity competing for a single (or more) bluetooth accessory can make the accessories fail to pair with any device. Basically bluetooth testing simultaneously does not work well, but you can use Appium to automate the turning the wifi/bluetooth/airplane mode on/off, but for Android devices this requires that they are all USB connected and not using adb to remap host ports to IP addresses over wifi...
Just curious to understand why iOS devices connect to sphero directly but an app needs to do it in Android?
Well that's what I guess is happening because sphero will keep flashing in identity colours in Android until an app completes a connection.
To add: to use the option that keeps the sphero alive on the charger while connected to the client, then IOS would not need an app running but Android would. Well the Android app could have a service running to keep a connection open with sphero.
But ideally a consistent behaviour would be better.
Kasuku, you're correct in your post, but you also need to consider that the operating systems that you are comparing are completely different. For example, in Android it is possible to directly access the bluetooth adapter and "manually" connect to a bonded device. In iOS, this functionality is abstracted out from the developer.
To address BTLE:
No, as of right now Sphero currently does not support BTLE hardware.
OK ... as usual this tag seems to be dead so I post my finding anyway:
Bluetooth hardware that wanted to connect to IOS, but were not following one of the standard profiles (e.g. headsets), need to conform to Apple's proprietary MFI (Made for IOS) protocol. So the connection is established by the IOS system and then it allows apps to access this connection.
But now newer IOS devices support Bluetooth LE so the MFI restriction no longer applies. I think Sphero2B is going to use this. Current Sphero hardware probably doesn't support BT LE. My next question is ... does sphero hardware support BT LE? ... but I'm not going to ask on this forum:)
Android on the other hand allows apps to negotiate the connections to paired devices.
Here's a link with more info:
Some blog
I have an Arduino application talking over USB to an application on Windows 8 using the MAVLINK protocol. The connection appears as COM3.
Is there a Windows application that can spy on this connection and display the traffic going in both directions? Raw bytes are fine, I don't need the protocol decoded.
You could log serial port activity using Portmon. (Edit: You need to first connect to the local computer via the Computer menu, and you must start capture on the port before a program opens it.)
You may not want to log USB traffic. Such a log would include a lot of extra information relating to the USB to serial adapter which is providing COM3. Portmon would only give you the bytes transferred over COM3, and the Mavlink protocol is entirely contained within that data stream. If you're sure you want to log all USB traffic to and from that device, then I recommend SnoopyPro. In Windows 7, you need to run it as administrator.
If you can use Windows XP in your environment, USB sniff should work for you. If you need something more powerful (and are willing to pay a fee for it) then USBLyzer might be a viable option.
The answer is SnoopyPro, and you can download it at:
SnoopyPro Sourceforge
This tool allows you to get USB information and also USB communication data. I used it in the past to know how a USB device worked in order to do its driver on Linux. I used this tool as a sniffer.
Basically, SnoopyPro allows you to intercept, display, record and analyze the USB protocol and all transferred data between any USB device connected to your PC and applications. It can be successfully used in application development, USB device driver or hardware development and offers the powerful platform for effective coding, testing and optimization.