DJI have released a detect sense and avoid system with their Guidance unit and a new quad in the Matrice 100
Nothing too earth shattering about them. The new developers and ideas that might flow in DJI’s direction is interesting though.
Not quite so many DJI systems are being used by universities and research institutions as other open source projects. By their very nature open source autopilots can be fiddled with and changed to suit whatever is being researched. That code is fed back into the eco system and the open source autopilots gets cleverer.
A rising tide lifts all ships.
DJI need a hand keeping up.
Video : https://www.youtube.com/watch?v=P2Xdf0iEQ6A
Credits to Gary Mortimer from SuasNews :
http://www.suasnews.com/2015/06/36475/dji-matrice-100-and-guidance/
Comments
I just have to laugh at this.
Ok, so you have glued some other camera board to a consumer camera system. Now what? Where are the wires? How are you even going to route the wires through that gimbal? There aren't any holes through the axles or anything. Can that gimbal even be retuned to deal with the weight of the extra electronics, and the resistance of the wires?
This just screams "Me Too!"
Here's my take on this: http://droneanalyst.com/research/research-notes/dji-developer-platf...
The big question for me is whether companies will develop commercial drones on the Matrice and Guidance combination. If they do, they will have to compete with fully developed / application-specific turnkey products like senseFly’s eXom. That product was thoughtfully developed, is already in market, and has ready buyers - despite the relatively high price. Additionally, DJI will need to deliver a more compelling vision for developers than this initial promotion video showcasing a big-brotheresque use case of identifying illegally parked cars. - Colin
@John and @Rob,
Thanks for your reasoning. Seeing it as Rob points it I agree including Solo might have been misleading. Well, some more publicity shouldn't harm for 3DR tough ;). We honestly love the looks of SOLO and are pretty happy with 3DR supporting open source. DJI-wise i can't agree more with your comments. Having said that,
@John, I did argued this a while ago and still hold my thoughts. Microcontroller-based (with an RTOS) systems do not necessarily better than microprocessors. Quoting a previous thread:
The discussion with regard making the Linux kernel real time is an issue that has gone for long. There's some people claiming that there's no way to make such a system "hard realtime" (there's more here about the different realtimeliness). Many justify so pointing the complexity of the Linux kernel and some choose to use microcontrollers to get a deterministic and more controlled environment.
The fact with an autopilot is judging whether we need hard-realtime or not. If we look at current autopilots such as the PixHawk or the APM2 and we enable debugging options in the scheduler (described here for Erle-brain) you will all see that the scheduler misses deadlines, quite a few depending on how you configure your system.
So, do we consider an autopilot a hard-realtime system? Clearly it's not been that way and all the flight controller you gentleman are using do not do so. Let's assume (as we did months ago) that we can use the hypothesis that an autopilot should be "soft-realtime" (the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service). Given this scenario we need to define nicely the maximum latencies we should comply with. E.g.: if the autopilot loop is running at 50 Hz then each loop should take no longer than 20 ms. If it's 100 Hz then we'll need to meet a 10 ms maximum latency.
Linux autopilots allow exactly this. And we've been doing so with Universities all around the world for the last months.
@John, Erle-Copter and Erle-Brain (powered vehicles) have a store for themselves, code that can be downloaded and put to work instantaneously in the drone. We did not mean the Play Store or the App Store. We wrote a short tutorial about it in case you are interested.
Maybe we should call them behaviors?
@Rob_Lefebvre : Same point of view regarding the Matrice : count more than 5000$ for the platform + avoidance system without upside rangefinder by the way... SDK is focused on high level development which (I guess) is not relevant for educational projects based on vision or sense technology. Why showing non connected Flir sensor on the vid ? In my opinion this is advertisement...
Yeah, sorry Victor, but I think comparing your copter to the Solo is a bit disingenuous. The Solo is not a "developer drone". It is a prosumer drone, made for end-users, and available at Best-Buy. Can it be hacked? Sure. You can hack anything, even a Maytag washing machine.
This chart is a bit like comparing a minivan to a sports car, and having check boxes like "Seats 7" and "Sliding doors", then declaring the minivan a better vehicle.
If you want a fair comparison, you might look to something like... a 3DR Quadcopter, with a BeagleBoneBlack companion computer. Randy used such a thing for the red balloon finder at AVC in 2014.
The Matrice, while interesting because what it says about DJI's thinking, isn't really that interesting from a developer standpoint, IMO. Why would anybody want to pay that much money for a nothing special quadcopter frame, and a closed source autopilot which requires you to jump through hoops to unlock only some amount of flight control? You're also betting on the thing actually working right, because if it doesn't, you can't just go fix it yourself. DJI's track record for software updates on some of their other low-volume systems is not very good. Just ask the people with A2 controllers, or anybody with a DJI helicopter controller.
I understand your need to highlight your product, but when aiming for developers you need to remember how your target group thinks, and not use marketing logic that quickly falls apart in that crowd..
As a technical sales point native Linux for the autopilot for example is not necessarily the best solution for mission critical applications. Having separate autopilot hardware (RTOS) and a companion computer with Linux for higher order tasks is a more optimal approach. So while technically it is true that solo does not have a native Linux autopilot, that's hardly relevant when their solution is arguably better.
Further you know just as well as me that the Solo in addition to DroneKit, still also runs full blown APM underneath with MAVlink integration and accompanying ROS support of varying degree. But I agree you seem to be more focused on this aspect and better support it.
3DR Solo and Tower GCS available in app store - check
3G/4G - true, but then again if you included single frequency for radio control, telemetry and live video, custom controller with live HDMI output and built in flight simulator, gopro control etc. It would be the other way around.
Hackable - Hard to define what hackable entails, but open-source APM software, open-source dronekit to access solo specific functionality, hardware expansion bay and using standard connectors so that you for example can easily swap antennas should count for something.
IO - Granted we do not know the exact specifications, but we know Pixhawk 2 is very similar to v1 with improved sensors and new molex connectors, so we have a good idea what to expect.
John,
@John Arne Birkeland, can you provide arguments on why each box should be checked for Solo? Maybe you could offer information that the rest of us do not own yet.
I agree that the DJI Matrice 100 underwhelms and seems a bit half assed compared to a true open-source solution. But the erlerobotics comparison is a joke at best. Solo ticks of all the same boxes and more compared to the erle copter.
Seems to me a bit too much what they offer for what they deliver http://erlerobotics.com/blog/developer-drones-comparison/.
A github was created the 7th June : https://github.com/dji-sdk/onboard
You can find the pdf here : https://github.com/dji-sdk/onboard/blob/master/Onboard_API_Doc/Onbo...
Safety strategy:
"Due to the safety concern, since onboard API enables developer to implement autonomous UAV systems beyond line-of-sight, DJI has to impose more restricted control registration methods for MATRICE 100.
Before using MATRICE 100, a developer must register personal information on dev.dji.com (the DJI server), and then activate MATRICE 100.DJI Server generates App ID and an AES key to the developer.
Most part of the communication between the onboard device and MATRICE 100 is encrypted by this key, which reaches MATRICE 100 separately during activation process.
Authorization levels:
"When a developer register on dev.dji.com, an authorization level will be assigned to the developer according to application needs and programming experience of the developer.
The developer must save this authorization level (app_api_level) to the onboard device. This app_api_level will be checked during activation process. Different authorization levels unlock different commands that the developer can use.
Level 0, activation related commands
Level 1, monitor and non-flight control, including camera and gimbal control, flight data monitoring. This level does not involve direct control of craft motion.
Level 2, flight control. It contains not only motion control, but also some flight mode changing control commands.
In future onboard API, we will release more and more commands with different authorization levels."
-
1
-
2
-
3
of 3 Next