DJI is the only major company that I've experienced demands you install an APK on your android instead of providing something via the app store. Something is completely broken with their software development, though their hardware seems quite nice.
I own a HEXA robot, I was a kick starter and paid a price for it.
When I first purchased the robot it never required phone GPS. And that now if you disable it at any point it disconnects you from the robot. It sits gaining dust because I wish not to use an IOS app with GPS enabled for no reason.
Questioning support to why this is required they said "people are happy with GPS on" and that was that.
I look at it sadly because it runs Linux, has full root access and so much potential. But, I just don't like the fact that could be potentially tracking GPS coords back to HQ.
The one good experience I've had with customer support for a hardware+software company was for the Eufy cameras by Anker.
Opening the app would stop the audio stream that was playing. No reason to do that while showing me a list of cameras. The audio stream should have been interrupted only once one selects a camera to view and listen to.
I wrote customer support and after some explanation and friction, they understood and a fix was released about two months later.
On that note, does there exist a company I could buy cameras to install at home, that 1) doesn't force me to go through some cloud, and 2) sells products to European market? I was excited about buying some Amcrest cameras, only to then discover it fails point 2) - I can't just get them without complex and expensive sourcing process, and should I do it anyway, jumping over the voltage difference between US and EU grids.
(I mean, I probably could make Amcrest stuff work if I tried hard enough, but I am at the age where spare time is precious, so I was looking for something that I could order and install without hassle or tinkering with mains electricity.)
They definitely have Meraki MRR envy but nothing they've tried so far has really stuck. However, aside from network gear, every product line is an island that does not interop with anyone else's products.
UniFi Protect only runs on their NVRs and "Dream" routers and only works with UniFi cameras. The wireless cameras only work with Protect because otherwise there's no way to get them on the network. Once a camera is paired to Protect, you cannot get a standard RTSP stream directly from it (but you can restream RTSP from Protect). They've got a Doorbell camera that doesn't send ring notifications or video to HomeKit / Alexa / Google Home.
There's hack-y stuff to make Protect work with standard RTSP cameras. And a HomeBridge plug-in to get HomeKit. But it's all subject to breakage and YMMV.
All that said, Protect is pretty great. I'm a (mostly) happy home user.
I assume HEXA isn't a drone then? There's legit (well, at least regulations) reasons why they'd need GPS for that. But if it's ground based that's silly.
Is the connection to the robot using Bluetooth Low Energy? I believe certain BLE-related APIs are gated behind the permission setting because scanning for BLE beacons can give the app very precise location.
Would be nice if users could give BLE permissions but _not_ GPS or wifi-based location permission to an app.
> Would be nice if users could give BLE permissions but _not_ GPS or wifi-based location permission to an app.
Not sure about iOS, but Android supports that for several years now (to the point where a given app only gets BLE access to one device it cares about which prevents data leakage).
This is supposed to be against app store policy, but I haven't found a clear way to report these sorts of violations. You can contact a regular support person, but in my experience they just say that if the app passed approval, then I must be incorrect.
The McDonald's app does some similar BS. You can't do anything in the app without granting the "precise GPS" permission, using a digital coupon in-store requires full GPS permission. If you use the "Ask me each time if I want to share" option, it will still reject you and tell you it needs to be always-on.
Apple may have paperwork DJI can fill out while Google may not. Being compliant can be a huge ordeal and it is quite possible Google does not offer what is required.
Alternatively it's probably a lot cheaper to offer an apk while for Apple there is no other option than the app store requiring all kinds of paperwork and lawyer fees.
DJI used to have the "Mimo" app in the play store. It was rated very low, 2.3 stars. The app required users to allow the permission to read the phone's IMEI. If you denied that permission, the app closed. Myself, and I'm sure plenty of others, have reported this to the play store as something against the play store policies. Perhaps Google gave in to the complaints eventually and told DJI, enough is enough with your crap, who knows... And that made DJI say, "enough is enough with _you_, we're big enough to distribute these outside the play store and keep our invasive tracking and permissions".
The drone apps work for me although installing the APKs is annoying and I moved on to litchi anyway. At least my very old spark still works.
The mimo app on the other hand is straight up garbage. The thing never works right if it even connects to the device at all. I regret buying that thing (it's the osmo mobile version 2 or 3). It's so bad I don't think I will ever buy a new dji device.
I love flying my spark but the battery life is trash and my Air 2 isn't fun to fly (it's more of a utility van than a fun little sports car). I'd love to get a replacement for my spark. It's probably better to just build my own at this point.
DJI once bricked all Vision 2+ drones with a software update a year or two after launch and offered zero support because it had newer models in the market.
Most hardware companies operate this way: their devices are on fixed release schedules, and once they're done, they're "done." Virtual Flight was part of the release cycle for some drone or another (I think the FPV potato, if I recall correctly?) and now that it's done, there's nobody allocated to or tasked with fixing it.
So, software is treated the same way. Engineers copy and paste whatever stuck-together yarn ball of code off Gitee they need to produce an artifact which passes QA, then ship it.
The problem comes in when there's software that needs to live for a long time in the real world - Virtual Flight, for example, was broken by some Apple update or another, and their Fly app has to support a broad range of drones so it creaks under the weight of everything being pasted together.
IMO, almost all "hardware" companies trying to make software are the same way. From industrial controls to mobile phone vendors. If anything, DJI have gotten better in recent years about after-sales updates, fixes, and support than they used to be.
Ok you’re saying DJI doesn’t understand that modern software is build on top of a moving base whose interface changes over time. It’s called lifecycle support
>it might be illegal to support an existing product when more profit can be extracted from building a new one.
Lol no, that's just a reddit opinion. Business judgment rule means businesses have a huge leeway on how to do business, outside of fraud or intentionally trying to cripple the company.
Unrelated to drones (but is a hardware/software manufacturer)- I would like to call out Axis (as an Axis network cameras) as one of the rare positive lights in this mess. They clearly state how long their products will be software supported, and they stick to that minimum and frequently go well beyond that minimum.
Axis has products that are over 10 years old that still receive frequent security only firmware updates. If they can do it across hundreds of different hardware products, then these companies can too. (in fact, Axis was doing it well before this became a main stream issue)
Do you think this is related to the fact that they only sell hardware (i.e., no subscription costs for the software)?
Shouldn't they already factor in the cost of app support for the next X years when selling the product?
I assume the same principle applies when you purchase an iPhone.
Though in this case, DJI may not see Virtual Flight as core software for their product.
Yes, 100%. In places where they get software residuals (agriculture and enterprise, via FlightHub and other services), development is constant because a team stays assigned to it.
I do think that in recent years DJI have gotten way better at budgeting for after-sales support on mainline products. The Mavic 3 series have gotten consistent and meaningful updates for quite some time now. This Virtual Flight app was always kind of a joke and I’m not really surprised it’s abandoned.
> Shouldn't they already factor in the cost of app support for the next X years when selling the product?
Depends what you mean by “should”. If you mean that they should because it would be the right thing to do, sure. If you mean it would be competitively advantageous, well I rather doubt it. Consumers have almost uniformly demonstrated that price trumps all.
Price and marketing. For better or worse[0], the consumers are putting trust into marketoids and their emotionally manipulative messaging, that focuses on imaginary nirvana-like experience, and completely omits how the experience is likely to look like a few months after purchase.
--
[0] - Sadly, it's likely for better. The world after most people get an accurate feel for how much they can trust companies will be a very bad place to live in.
I suspect some of this is why more recent DJI drones have an OS and screen on the controller, because that way they have a single set of hardware to target, and even if some future Android release breaks backwards compatibility they can simply choose not to update to it and the controller will still work.
I think hardware companies just view programmers as, like, EE that aren’t even trustworthy enough to put in charge of keeping the magic smoke in the chips.
Yep. Take a look at Parrot's support for the Disco and Bebop drones. As of a few months ago, the FreeFlightPro app[1] no longer connects to Parrot servers so that you can login to your account on their servers, and only then connect to the drone a few feet away from you.
All this obsolence, just so that they can sell you the new Anafi drones (which will be similarly obsolesced).
Thank god for the Ardupilot community[2ŧŦ] stepping in to open up their drones for at least some semblance of autonomy, so that people can once again control the devices that they've purchased...
ŧ: admittedly some ex-Parrot developers helped port some stuff over.
Ŧ: Andrew Tridgell (of "reason for chaging VC in Linux from BitKeeper to Git", and other true-coder fame) is pretty active here. It's a very talented community.
Thanks for the post about this. I have a Parrot Disco that I was planning to take for its first flight in about two years next weekend. Honestly these companies need to be sued over this behavior. Shutting down the servers without updating the app to work without needing login essentially bricks a product that I paid for.
For Disco you're in luck, there are some really decent ardupilot-based projects out there[1]. Plus, unlike the Bebop camera which is inaccessible via the shell (you can only use the Parrot SDK), the Disco camera can be commanded to stream/record with a few simple commands, and even bound to controller inputs.
A caveat with the controller: it needs to have custom firmware[2] to get it communicating with ardupilot, and to get the firmware onto the controller you need telnet/adb into it via SkyController→usb→ethernet→usb→Laptop adaptor(s) setup.
For a ground control system (GCS), there's three to choose from: Mission Planner, APM Planner, and QGroundControl[3] (ignore the rest, use this one).
For configuring the drone, mission planner is pretty good... but you can also just use MavProxy[4] which is a fantastic commandline program that all the GCSes use in some way, and can even be installed in Termux/Android.
This is why hardware manufacturers should be required to place schematics and software source code for all components into escrow, and it becomes public when they discontinue meaningful support and or shipping a product.
Can you elaborate? AFAIK the GPL just naively enforces that something needs to be and remain open source. How can it turn closed source into open source?
The problem is that the software is most likely not composed by them in any meaningful way. If you take apart any proprietary firmware and controlling application you are almost certain to find boilerplate code provided by the chipset vendors (protected by NDA) glued together with other code from other vendors with a GPL violating Linux backend.
Recent example: I patched in to my 3D printer's mainboard using a TTL to USB and opened up putty and guess what shows on the console?
> Linux version 3.4.39+ (zhanglei@ubuntu Revision:543)
That's less of a problem for a hypothetical law requiring either longer-term maintenance or enabling users to perform that maintenance themselves. Manufacturers would just have to make adequate contractual arrangements.
Maybe if it's a tiny country that makes up virtually no market share. If it's a major market like the USA companies will find a way to comply with the laws to continue marketing their products.
There is also the fact that this particular software is running on a platform that seems to wear breaking changes and backward incompatibility as a badge of honour.
I am just imagining this, or did it feel like 10-15 years ago breaking changes were a big deal, and companies went out of their way to provide an upgrade path. Now my flutter app from 3 months ago won't even compile.
The major platform companies have different historical attitudes that haven’t changed much.
Microsoft: We told you what not to do, and you did it anyway, so we’ll put code in our OS specifically to keep your app running.
Apple: We didn’t tell you that was OK to do, and you did it, and our latest cool stuff broke your app. Over to you. Also, we didn’t mention this earlier, but no more 32-bit apps next year, sorry.
Android: We try to keep your app running, for a while, but TBH a lot of the platform comes from manufacturers who only care for about 18 months. Let’s all just try to survive.
K’nex had a roller coaster kit that came with Google Cardboard-style glasses and an app. The app was released when iOS 13 was current. iOS 14 broke whatever orientation alignment API the VR app used.
The app reviews are flooded with people complaining it’s broken. I absolutely have no hope it will ever get fixed.
This is the most accurate description of dealing with a hardware manufacturer I’ve ever read. I’ve never experienced getting for example, drivers from a hardware company where it wasn’t exactly as you described.
A lot of hardware companies also just tend to just outsource a lot of software development to other third parties. Once the software is delivered, sometimes these third parties just move on/go under and the bugs in the software never get fixed.
I've had a very good experience with DJI recently. On my DJI Mini 2 the IMU was malfunctioning and they repaired it for free (including shipping both ways), despite it being out of warranty.
I was able to buy DJI care after the repair which came in handy for my upcoming high risk flights ;-)
Might you be using an unusual configuration, like having changed an OS privacy setting where the weaker default is relied on by the app for a persistent session, or is this bug a consensus among all users?
In the past, you could use 3rd-party apps that extended features, and offered new ones. One popular app is Litchi https://flylitchi.com
However, DJI seems to have stopped updating their iOS API, so 3rd-party iOS apps won't work with any newer drones and Android stuff seems to be available only by side-loading.
Perhaps there's something in the newer APIs that neither Apple or Google like? Sending back too much data to DJI?
This seems to be assured. Another comment mentions the collection of the phone’s IMEI.
I’d love to see a proper security analysis of their packages, because I would be willing to bet cash money that every app they offer does multiple nefarious things to collect your personal and flight data.
Sadly, such revelations still would probably not be enough to damage their reputation and sales in a meaningful way.
Its no secret they save flight data (like everything you input, temperature, gps points...) in their cloud.
I think there are workarounds for this, a friend of mine never paired his drone with a smartphone connected to any network. Iam pretty sure this will not work for a long time.
Its very daunting if you ask me, the amount of data they gather. Not a small part of drones used in active wars, like ukraine right now, is by DJI. This is alot of power in the hands of a few.
their simulator for PC has been broken and not updated for quite some time too. It doesn't work with new controllers (anything from mavic 2 and up i think)
This is why I will only buy a drone that can be supported fully by an Open Source software stack. Yes, that will require far more work to set up and maintain, but it literally can last as long as I need it, without future restrictions, for as long as the hardware shall live.
Proprietary hardware will always be abandon by its manufacturers eventually. Always!! This is not the first drone to be dust-binned by software obsolescence. It will not be the last. What will it take for people to realize this fundamental truth?
Can you recommend a good drone with an open source stack? I would very much like to buy one but it is unclear which are comparable or better than something I would buy from DJI.
The PX4 stack would be where I would start if I were in the market to buy today. They have a list of compatible hardware and drones, including some relatively off-the-shelf drones. The list of drones provides a lot of detail about the various levels of support and functionality available.
But it depends on your budget/use case really (just to fly around with a camera like payload, drone racing, autonomous missions using gps). A lot of the drones out there use a lot of open source software for one thing or another.
Ardupilot, PX4, Betaflight, iNav etc.. are open source drone flight control software which run on drone flight controllers. flight controller = a little microcontroller + gyro/accelerometer + connections to some peripherals like radio receivers , GPS, sensors like sonar etc.
Blheli_S, AM32 etc.. are Open Source ESC firmware. ESC = Electronic Speed Controller. The component that is responsible to spin the motors as the flight controller wants it to.
Sik Radio, ExpressLRS, mLRS etc.. are Open Source RC control link software that let you send control messages from your ground station to your drone.
As for Video Transmission, you can use anything from OpenHD/wifibroadcast(doesn't use Wifi. just Wifi hardware in monitor mode.) to webrtc over 4g to transmit video from quad to your ground station. And optionally record it on the drone side too.
Mix and match these open source components to build your own drone as per your needs.
I mostly fly racing drones and every single component on my quads is open source to one extent or another.
That’s the page I went to that led me to some 404s
I appreciate all of the info you have supplied.
I would very much like to buy a complete multicopter to which I can add payloads and program routes/waypoints and otherwise customize. Do you or anyone else reading this have good experience with any vendors of open source drones?
If you're ordering this one, Dont forget to order a lipo battery or two and battery charger. That is not included in this kit.
Also a transmitter like Radiomaster pocket and a receiver would be very handy. Iirc you can use a regular joystick with QGroundControl but I prefer to have a separate strong control link that will let you recover the quad if the connection to ground station is lost.
There is nothing that comes close to DJI for a flying camera, and I don't say this as a fanboy but rather as someone who has been in this industry in various capacities for a long time.
Ardupilot and PX4 are great projects, but they're just a basic ingredient in making a drone with good autonomy. They handle the basics of stabilizing a multicopter or plane (with a lot of tuning required) and have some rudimentary range finding and optical flow support, but don't offer much in the way of state-of-the-art vision based autonomy for position hold, obstacle avoidance, or route planning. Even in the commercial space (where a lot of stuff is based on PX4, it's BSD licensed so products don't need to be source-available), nothing really gets close to DJI. On the other end of the hobby drone space, INAV and Betaflight are fun, but they're mostly for FPV which is a completely different ball game.
The gaps for full open source _and_ non-DJI commercial drones are numerous. Really they're pretty much end-to-end:
* Vision autonomy. There are a _ton_ of UAV vision autonomy projects on GitHub, mostly because it's a popular thesis project. Unfortunately, none of them have taken off as a practical, well-maintained thing you can integrate into normal drone hardware and use. In the commercial space, Skydio finally got a good win here, but they've given up on the consumer market. This isn't just a critical feature for whiz-bang inside-out pathing like Skydio do, it's an important fundamental for strong position hold (called visual odometry) as GPS is drift-prone and traditional low resolution optical flow struggles once a drone is at a higher altitude.
* Camera image sensor quality. This is the place where Skydio really fell behind DJI in the consumer market. This is a highly proprietary, closely guarded space. It's almost impossible to find a good image sensor plus the parameters to make it look good (ISP firmware / sensor parameterization) that's not locked under 100 levels of NDA. Add on the need for specialized optics and you're in for a really tall order. Even the Pi Foundation essentially gave up on this and ship a DRMed camera with proprietary ISP parameterization.
* Video downlink. This is a big one too, and one of the other big places where Skydio fell behind. DJI and Autel have access to modified mobile phone IP via China. Everyone else is using either analog video or WiFi and it just isn't good.
* Camera gimbal quality. Ardupilot did a GSoC project around this recently. This space is really underinvested too. Making a good gimbal is _hard_, and it goes hand-in-hand with the camera sensor issue in some ways because making a gimbal which is weight/balance-matched to a specific camera is a lot easier than a general purpose one. Also, most open source projects spent a long time focused on on bottom-facing survey / photogrammetry use cases because they were easier, so basic features like "aim/zoom to a tapped point on a video" aren't fully baked at all.
* Battery quality and parameters. Open source / hobby drones tend to use either polymer-electrolyte prismatic pouch packs with extremely high instantaneous discharge but comparatively low overall capacity (FPV drones) or round-cell lithium ion batteries with good overall capacity, but poor instantaneous discharge and poor packaging. The optimal battery for a small camera drone is right between these two extremes.
Even in the commercial space, I'd recommend DJI. Autel is basically one generation behind DJI at a higher price point. Skydio drones were cool but they exited the consumer market, and they were loud and had bad cameras and a weak video link compared to their contemporary DJI rivals. Parrot are interesting as a non-Chinese option, but they're about two generations behind DJI, also at an even higher price point.
If you want a camera drone today, buy a DJI drone with a standalone remote controller (the one with a screen). That way, you do...
Wow. Thanks for all of this. I am really interested in being able to remotely command the drone to navigate to waypoints sequentially and semi-autonomously. My understanding is that the low end of DJI drones do not support this. Do you have recommendations there for specific DJI models?
Yes, it is extremely annoying. Since there isn't a lot of competition left in the prosumer space, DJI are shifting their autonomy SDK features upmarket into their "Enterprise" series drones.
But! There are workarounds. You can backdoor upload waypoints in DJI WPML / KMZ format to the Air 3 and Mavic 3 consumer drone series. Here's the waypoint XML format: https://developer.dji.com/doc/cloud-api-tutorial/en/api-refe... . This is actually surprisingly effective and works really well.
https://www.litchiutilities.com/litchiToM3.php offers an interesting workflow for this, creating flight paths using the Litchi app that's generally used for controlling drones that _do_ support the SDK and then importing them. This page also has the best documentation I've seen for the backdoor upload method.
This is just how iOS works. Sometimes you have to update your app. If it takes you a month, maybe you get a pass. If it’s been 162 days and you don’t even have a definite answer for whether you’re ever going to fix it, then you just shouldn’t be making apps.
"Currently, existing apps (across mobile, Android Auto, Android TV) must target API level 31 or above by August 31, 2023 (target API 30 or up API level 33 for Wear OS). Otherwise, they will stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app’s target API level"
It is now a yearly requirement to target the latest API version.
You might have "working apps that target Android 6" but no one with a phone built after 2017 can find them. I often run into incompatibilities between API versions.
Thats only new listings.
And while old ones dont get listed for new installs.
They dont stop working if you installed them before the minimum requirements for new apps came into force, and you can still install them on new phones from the list of applications attached to your account.
But there have been changes in the Android API that have been non-backwards compatible and if your app is using those API's, they will break when run on newer versions. Same as for iOS.
Many simple apps targeting very old versions of their respective API/SDK will still work on both platforms.
Ultimately, keeping an app active and functional does require maintenance.
Obviously expect that boundary to ratchet up with time, plus the single point of failure if they ever decide to remove `--bypass-low-target-sdk-block` from the dev tools.
Thats 10 years ago, and only 5 years after the very first iPhone (2007)
6 was a milestone, because it was the first to actually feature restricted app access to contacts/microphone/camera.
facebook, twitter, linkedin and a load of others (especially facebook games) got where they are from stealing everyones contacts via that method and then spamming them with adverts. TF those days are behind us.
Justify your e-waste any way you want. I still use my old Kitkat phone offline for MP3+OBD in my car, and it still gets brand-new versions of the apps I like: https://krosbits.in/musicolet/
Breaking changes are part of the deal. It’s no secret that iOS has a new major version every year. If there’s blame here, it’s on DJI.
And usually the breaking changes only come after many years of advance notification from Apple, unless it’s an urgent change to address for example abusive developers doing egregious infringement of privacy.
Those developers tend to be hit harder. Maybe that’s the case here.
> problem started when apple upgraded iOS to 16.4+ version (27.3.2023 exactly 162 days ago)
Every single comment blames DJI, but shouldn't it be Apple's responsibility to not break existing apps with iOS "upgrades"?
Apple is free to decide they don't care one bit about retro compatibility, but it's just weird we would simply accept that and think of updates like a kind of act of God that just happens.
Same thought. I don't blame DJI for not playing this fast moving ballgame; stability matters. I suspect there are cultural issues at play between firmware and phone devs. I'd like to see conventional wisdom on regular updates being critical, ostensibly for security, going away.
It depends on what exactly happened. Sometimes documentation will say stuff like "order of execution of these methods can be random" which if ignored may lead to a bug after a perfectly compatible upgrade.
On the one hand, there are always going to be changes with upgrades that break things, even if not intended -- especially when apps inadvertently rely on undocumented API behavior.
But on the other hand, that's a well-known difference between Apple and Microsoft philosophies. Microsoft bends over backwards to support old software (e.g. hard-coding old buggy/undefined behavior for specific legacy apps), while Apple fully expects app developers to maintain their software and upgrade it as necessary with each new iOS release, using new versions of libraries etc.
I don't think either is "correct", they're just different philosophies. The Microsoft way leads to incredibly complicated OS behavior that must be hell on the Windows devs. But if you develop an iOS app, you should know this going into it, that you'll need to budget for a certain level of occasional maintenance or risk that the app breaks.
The that cultural difference causes some pretty important secondary differences too - for example, Microsoft's way enables software to be a product - written once, working approximately forever; Apple's way pretty much forces a subscription model.
The Microsoft way is absolutely better than the Apple way. Platform holders, Apple in particular, reap enormous profits. They have at least some basic responsibility here. It's hard? Tough shit, software is hard. Start putting in the work for your 400k TC.
This is also why Apple will never be a long-term gaming platform for anything other than gacha pull and otherwise exploitative games. I can still play the original Dark Souls with DSFix on modern Windows (or Linux via Proton for that matter). The game is timeless and should never be lost to lazy platform holders.
Microsoft is not shipping mobile phone software! I fault them for breaking older apps, yes, but this is not always the case. I have an app that is 7 years old and it hasn't been updated for any phone since the iphone 7. I see the black bars when I open it. It's a drink making app that since got taken off the app store, but I'll never delete it because it was a one time purchase and got me access to the easiest explanations for making drinks I have ever seen in my entire life. And every drink is there. Apple has never, I repeat *never*, broken it for me. It still opens.
Your mileage may vary. I think backwards compatibility is important, but we can't expect Apple to do a quality test on every last app on the app store for hours and hours making sure it opens on every phone on every software version.
Except that it's easy to make the exact opposite argument: that making apps is so tremendously easy and cheap compared to making hardware, or even writing and physically distributing software back in the 1980's and 1990's. It's never been so easy for a handful of developers to to make millions via app stores and cloud computing. So app makers have at least some basic responsibility here. It's hard? Tough shit, software is hard. Start putting in the minimal work to keep your apps up to date.
Apps are more interoperable than every before so the idea of something you write once and never touch again stops making any sense. Encryption standards progress, privacy entitlements become more granular, image formats get added, retina compatibility becomes expected, dark mode becomes expected, etc. etc. etc.
The problem is that all the legacy bits of Windows makes development (and usage) of Windows software harder. So it’s a trade off for developers - easier initial development but harder maintenance, or harder initial development and easier maintenance. I’d personally choose the former (what Apple provides), but either way is a reasonable choice to make.
I think you can frame it as a neutral tradeoff in the abstract, but Dark Souls is a monumental piece of cultural heritage and is clearly and unequivocally better than gacha games.
Apps rarely break on dot releases of iOS. If you’re using private API’s though when you’re explicitly told not to, shit happens. I’d bet my house on this being a DJI issue as opposed to Apple breaking a public API in a dot release.
Audio software tends to experience breakage even after minor iOS releases. For example, Apple have once changed the in-memory format of MIDI sysex messages passed to the app in a dot release. Segfaults ensued. The particular callback wasn't documented well and some OS behaviors had to be inferred. Apple still went through with the change, not noticing or maybe not caring about consequences.
I used to have a mavic mini, that is, up until it disconnected 500 ft from me, never to return again. I tried chasing it down to where I believed it was, but I was never able to reconnect. There is a return to home feature, where the drone is supposed to fly back to its launch spot, in case something like this happens, but that never happened.
Well I contacted DJI to see if they would replace it, due to clearly a software error on their side, and they basically told me to pound sand. I sent them a video recording of the drone’s final moments (it synced to my phone), and they wanted me to pay for their “free data analysis” because the drone was out of warranty; even though I had only flown it a handful of times. (This is data I know they can see, along with the rest of the flight data).
They ended up offering me a 40% coupon, which is just a joke, and I told them I will keep publicly shaming them unless they can offer a replacement. (So here I am). They also randomly called me at 11am on a workday, twice in a row, and didn’t leave a message; about a week after my emails with cs. Just a really weird experience. Highly don’t recommend DJI.
122 comments
[ 0.16 ms ] story [ 210 ms ] threadWhen I first purchased the robot it never required phone GPS. And that now if you disable it at any point it disconnects you from the robot. It sits gaining dust because I wish not to use an IOS app with GPS enabled for no reason.
Questioning support to why this is required they said "people are happy with GPS on" and that was that.
I look at it sadly because it runs Linux, has full root access and so much potential. But, I just don't like the fact that could be potentially tracking GPS coords back to HQ.
The one good experience I've had with customer support for a hardware+software company was for the Eufy cameras by Anker.
Opening the app would stop the audio stream that was playing. No reason to do that while showing me a list of cameras. The audio stream should have been interrupted only once one selects a camera to view and listen to.
I wrote customer support and after some explanation and friction, they understood and a fix was released about two months later.
https://gizmodo.com/eufy-local-security-camera-cloud-unencry...
(I mean, I probably could make Amcrest stuff work if I tried hard enough, but I am at the age where spare time is precious, so I was looking for something that I could order and install without hassle or tinkering with mains electricity.)
UniFi Protect only runs on their NVRs and "Dream" routers and only works with UniFi cameras. The wireless cameras only work with Protect because otherwise there's no way to get them on the network. Once a camera is paired to Protect, you cannot get a standard RTSP stream directly from it (but you can restream RTSP from Protect). They've got a Doorbell camera that doesn't send ring notifications or video to HomeKit / Alexa / Google Home.
There's hack-y stuff to make Protect work with standard RTSP cameras. And a HomeBridge plug-in to get HomeKit. But it's all subject to breakage and YMMV.
All that said, Protect is pretty great. I'm a (mostly) happy home user.
My educated guess is that the company Vincross sold their tech to the Chinese Military back in 2017 and China is being China.
It is a very nifty robot, the company still exists but feels as an empty shell.
Would be nice if users could give BLE permissions but _not_ GPS or wifi-based location permission to an app.
Not sure about iOS, but Android supports that for several years now (to the point where a given app only gets BLE access to one device it cares about which prevents data leakage).
The McDonald's app does some similar BS. You can't do anything in the app without granting the "precise GPS" permission, using a digital coupon in-store requires full GPS permission. If you use the "Ask me each time if I want to share" option, it will still reject you and tell you it needs to be always-on.
[1] https://www.bbc.com/news/technology-59703521
Alternatively it's probably a lot cheaper to offer an apk while for Apple there is no other option than the app store requiring all kinds of paperwork and lawyer fees.
Page visible only if you have installed the app in the past: https://play.google.com/store/apps/details?id=dji.mimo
The mimo app on the other hand is straight up garbage. The thing never works right if it even connects to the device at all. I regret buying that thing (it's the osmo mobile version 2 or 3). It's so bad I don't think I will ever buy a new dji device.
I love flying my spark but the battery life is trash and my Air 2 isn't fun to fly (it's more of a utility van than a fun little sports car). I'd love to get a replacement for my spark. It's probably better to just build my own at this point.
So, software is treated the same way. Engineers copy and paste whatever stuck-together yarn ball of code off Gitee they need to produce an artifact which passes QA, then ship it.
The problem comes in when there's software that needs to live for a long time in the real world - Virtual Flight, for example, was broken by some Apple update or another, and their Fly app has to support a broad range of drones so it creaks under the weight of everything being pasted together.
IMO, almost all "hardware" companies trying to make software are the same way. From industrial controls to mobile phone vendors. If anything, DJI have gotten better in recent years about after-sales updates, fixes, and support than they used to be.
Lol no, that's just a reddit opinion. Business judgment rule means businesses have a huge leeway on how to do business, outside of fraud or intentionally trying to cripple the company.
Axis has products that are over 10 years old that still receive frequent security only firmware updates. If they can do it across hundreds of different hardware products, then these companies can too. (in fact, Axis was doing it well before this became a main stream issue)
It's pretty clear the issue isn't "we can't", but rather "we can, but why would we want that".
Shouldn't they already factor in the cost of app support for the next X years when selling the product?
I assume the same principle applies when you purchase an iPhone. Though in this case, DJI may not see Virtual Flight as core software for their product.
I do think that in recent years DJI have gotten way better at budgeting for after-sales support on mainline products. The Mavic 3 series have gotten consistent and meaningful updates for quite some time now. This Virtual Flight app was always kind of a joke and I’m not really surprised it’s abandoned.
Depends what you mean by “should”. If you mean that they should because it would be the right thing to do, sure. If you mean it would be competitively advantageous, well I rather doubt it. Consumers have almost uniformly demonstrated that price trumps all.
--
[0] - Sadly, it's likely for better. The world after most people get an accurate feel for how much they can trust companies will be a very bad place to live in.
All this obsolence, just so that they can sell you the new Anafi drones (which will be similarly obsolesced).
Thank god for the Ardupilot community[2ŧŦ] stepping in to open up their drones for at least some semblance of autonomy, so that people can once again control the devices that they've purchased...
1: https://play.google.com/store/apps/details?id=com.parrot.fre...
2: https://discuss.ardupilot.org/t/controlling-parrot-drones-us...
ŧ: admittedly some ex-Parrot developers helped port some stuff over.
Ŧ: Andrew Tridgell (of "reason for chaging VC in Linux from BitKeeper to Git", and other true-coder fame) is pretty active here. It's a very talented community.
A caveat with the controller: it needs to have custom firmware[2] to get it communicating with ardupilot, and to get the firmware onto the controller you need telnet/adb into it via SkyController→usb→ethernet→usb→Laptop adaptor(s) setup.
For a ground control system (GCS), there's three to choose from: Mission Planner, APM Planner, and QGroundControl[3] (ignore the rest, use this one).
For configuring the drone, mission planner is pretty good... but you can also just use MavProxy[4] which is a fantastic commandline program that all the GCSes use in some way, and can even be installed in Termux/Android.
1: https://github.com/uavpal/disco4g/
2: https://github.com/ArduPilot/dema-rc/
3: https://github.com/mavlink/qgroundcontrol
4: https://github.com/ArduPilot/MAVProxy
Recent example: I patched in to my 3D printer's mainboard using a TTL to USB and opened up putty and guess what shows on the console?
> Linux version 3.4.39+ (zhanglei@ubuntu Revision:543)
* https://pastebin.com/CPB7RBdK
It would also do absolutely nothing in this situation where the product already comes from a foreign country.
Microsoft: We told you what not to do, and you did it anyway, so we’ll put code in our OS specifically to keep your app running.
Apple: We didn’t tell you that was OK to do, and you did it, and our latest cool stuff broke your app. Over to you. Also, we didn’t mention this earlier, but no more 32-bit apps next year, sorry.
Android: We try to keep your app running, for a while, but TBH a lot of the platform comes from manufacturers who only care for about 18 months. Let’s all just try to survive.
The app reviews are flooded with people complaining it’s broken. I absolutely have no hope it will ever get fixed.
I was able to buy DJI care after the repair which came in handy for my upcoming high risk flights ;-)
But if you ask them that doesn't exist, once you login you never need to login again... except, well, you do.
Their hardware is excellent. I wish their software was at least remotely on par with that.
In the past, you could use 3rd-party apps that extended features, and offered new ones. One popular app is Litchi https://flylitchi.com
However, DJI seems to have stopped updating their iOS API, so 3rd-party iOS apps won't work with any newer drones and Android stuff seems to be available only by side-loading.
Perhaps there's something in the newer APIs that neither Apple or Google like? Sending back too much data to DJI?
I’d love to see a proper security analysis of their packages, because I would be willing to bet cash money that every app they offer does multiple nefarious things to collect your personal and flight data.
Sadly, such revelations still would probably not be enough to damage their reputation and sales in a meaningful way.
Its no secret they save flight data (like everything you input, temperature, gps points...) in their cloud.
I think there are workarounds for this, a friend of mine never paired his drone with a smartphone connected to any network. Iam pretty sure this will not work for a long time.
Its very daunting if you ask me, the amount of data they gather. Not a small part of drones used in active wars, like ukraine right now, is by DJI. This is alot of power in the hands of a few.
Proprietary hardware will always be abandon by its manufacturers eventually. Always!! This is not the first drone to be dust-binned by software obsolescence. It will not be the last. What will it take for people to realize this fundamental truth?
But it depends on your budget/use case really (just to fly around with a camera like payload, drone racing, autonomous missions using gps). A lot of the drones out there use a lot of open source software for one thing or another.
Ardupilot, PX4, Betaflight, iNav etc.. are open source drone flight control software which run on drone flight controllers. flight controller = a little microcontroller + gyro/accelerometer + connections to some peripherals like radio receivers , GPS, sensors like sonar etc.
Blheli_S, AM32 etc.. are Open Source ESC firmware. ESC = Electronic Speed Controller. The component that is responsible to spin the motors as the flight controller wants it to.
Sik Radio, ExpressLRS, mLRS etc.. are Open Source RC control link software that let you send control messages from your ground station to your drone.
As for Video Transmission, you can use anything from OpenHD/wifibroadcast(doesn't use Wifi. just Wifi hardware in monitor mode.) to webrtc over 4g to transmit video from quad to your ground station. And optionally record it on the drone side too.
Mix and match these open source components to build your own drone as per your needs.
I mostly fly racing drones and every single component on my quads is open source to one extent or another.
I appreciate all of the info you have supplied.
I would very much like to buy a complete multicopter to which I can add payloads and program routes/waypoints and otherwise customize. Do you or anyone else reading this have good experience with any vendors of open source drones?
https://newbeedrone.com/products/holybro-px4-development-kit...
Review: https://www.youtube.com/watch?v=27rbxCeCq4Y
I have used some holybro products and they work well.
Seems like a lot of "ready to fly" kits/models have disappeared these days. I am guessing the new drone regulations have something to do with it.
If you are a little more adventurous (i.e dont mind soldering/assembling your own drone), you'd be able to build a quad for a LOT smaller/cheaper.
Also a transmitter like Radiomaster pocket and a receiver would be very handy. Iirc you can use a regular joystick with QGroundControl but I prefer to have a separate strong control link that will let you recover the quad if the connection to ground station is lost.
Ardupilot and PX4 are great projects, but they're just a basic ingredient in making a drone with good autonomy. They handle the basics of stabilizing a multicopter or plane (with a lot of tuning required) and have some rudimentary range finding and optical flow support, but don't offer much in the way of state-of-the-art vision based autonomy for position hold, obstacle avoidance, or route planning. Even in the commercial space (where a lot of stuff is based on PX4, it's BSD licensed so products don't need to be source-available), nothing really gets close to DJI. On the other end of the hobby drone space, INAV and Betaflight are fun, but they're mostly for FPV which is a completely different ball game.
The gaps for full open source _and_ non-DJI commercial drones are numerous. Really they're pretty much end-to-end:
* Vision autonomy. There are a _ton_ of UAV vision autonomy projects on GitHub, mostly because it's a popular thesis project. Unfortunately, none of them have taken off as a practical, well-maintained thing you can integrate into normal drone hardware and use. In the commercial space, Skydio finally got a good win here, but they've given up on the consumer market. This isn't just a critical feature for whiz-bang inside-out pathing like Skydio do, it's an important fundamental for strong position hold (called visual odometry) as GPS is drift-prone and traditional low resolution optical flow struggles once a drone is at a higher altitude.
* Camera image sensor quality. This is the place where Skydio really fell behind DJI in the consumer market. This is a highly proprietary, closely guarded space. It's almost impossible to find a good image sensor plus the parameters to make it look good (ISP firmware / sensor parameterization) that's not locked under 100 levels of NDA. Add on the need for specialized optics and you're in for a really tall order. Even the Pi Foundation essentially gave up on this and ship a DRMed camera with proprietary ISP parameterization.
* Video downlink. This is a big one too, and one of the other big places where Skydio fell behind. DJI and Autel have access to modified mobile phone IP via China. Everyone else is using either analog video or WiFi and it just isn't good.
* Camera gimbal quality. Ardupilot did a GSoC project around this recently. This space is really underinvested too. Making a good gimbal is _hard_, and it goes hand-in-hand with the camera sensor issue in some ways because making a gimbal which is weight/balance-matched to a specific camera is a lot easier than a general purpose one. Also, most open source projects spent a long time focused on on bottom-facing survey / photogrammetry use cases because they were easier, so basic features like "aim/zoom to a tapped point on a video" aren't fully baked at all.
* Battery quality and parameters. Open source / hobby drones tend to use either polymer-electrolyte prismatic pouch packs with extremely high instantaneous discharge but comparatively low overall capacity (FPV drones) or round-cell lithium ion batteries with good overall capacity, but poor instantaneous discharge and poor packaging. The optimal battery for a small camera drone is right between these two extremes.
Even in the commercial space, I'd recommend DJI. Autel is basically one generation behind DJI at a higher price point. Skydio drones were cool but they exited the consumer market, and they were loud and had bad cameras and a weak video link compared to their contemporary DJI rivals. Parrot are interesting as a non-Chinese option, but they're about two generations behind DJI, also at an even higher price point.
If you want a camera drone today, buy a DJI drone with a standalone remote controller (the one with a screen). That way, you do...
But! There are workarounds. You can backdoor upload waypoints in DJI WPML / KMZ format to the Air 3 and Mavic 3 consumer drone series. Here's the waypoint XML format: https://developer.dji.com/doc/cloud-api-tutorial/en/api-refe... . This is actually surprisingly effective and works really well.
https://www.litchiutilities.com/litchiToM3.php offers an interesting workflow for this, creating flight paths using the Litchi app that's generally used for controlling drones that _do_ support the SDK and then importing them. This page also has the best documentation I've seen for the backdoor upload method.
Apple has always made it clear and so DJI is absolutely to blame.
never had any such problem on android, I still have working apps that target android 6...
"Currently, existing apps (across mobile, Android Auto, Android TV) must target API level 31 or above by August 31, 2023 (target API 30 or up API level 33 for Wear OS). Otherwise, they will stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app’s target API level"
https://support.google.com/googleplay/android-developer/answ...
It is now a yearly requirement to target the latest API version.
You might have "working apps that target Android 6" but no one with a phone built after 2017 can find them. I often run into incompatibilities between API versions.
They dont stop working if you installed them before the minimum requirements for new apps came into force, and you can still install them on new phones from the list of applications attached to your account.
But there have been changes in the Android API that have been non-backwards compatible and if your app is using those API's, they will break when run on newer versions. Same as for iOS.
Many simple apps targeting very old versions of their respective API/SDK will still work on both platforms.
Ultimately, keeping an app active and functional does require maintenance.
Only for _acquiring_ new customers on _very new_ devices.
Old customers on new devices are just fine.
https://developer.android.com/topic/libraries/support-librar...
Goes all the way back to Android 4.
Sounds like they still work though. GP's Android 6 application won't stop working, would it?
Obviously expect that boundary to ratchet up with time, plus the single point of failure if they ever decide to remove `--bypass-low-target-sdk-block` from the dev tools.
Thats 10 years ago, and only 5 years after the very first iPhone (2007)
6 was a milestone, because it was the first to actually feature restricted app access to contacts/microphone/camera.
facebook, twitter, linkedin and a load of others (especially facebook games) got where they are from stealing everyones contacts via that method and then spamming them with adverts. TF those days are behind us.
And usually the breaking changes only come after many years of advance notification from Apple, unless it’s an urgent change to address for example abusive developers doing egregious infringement of privacy.
Those developers tend to be hit harder. Maybe that’s the case here.
Every single comment blames DJI, but shouldn't it be Apple's responsibility to not break existing apps with iOS "upgrades"?
Apple is free to decide they don't care one bit about retro compatibility, but it's just weird we would simply accept that and think of updates like a kind of act of God that just happens.
according to the comments in the thread it doesn’t work even on ios 15.7?
But on the other hand, that's a well-known difference between Apple and Microsoft philosophies. Microsoft bends over backwards to support old software (e.g. hard-coding old buggy/undefined behavior for specific legacy apps), while Apple fully expects app developers to maintain their software and upgrade it as necessary with each new iOS release, using new versions of libraries etc.
I don't think either is "correct", they're just different philosophies. The Microsoft way leads to incredibly complicated OS behavior that must be hell on the Windows devs. But if you develop an iOS app, you should know this going into it, that you'll need to budget for a certain level of occasional maintenance or risk that the app breaks.
This is also why Apple will never be a long-term gaming platform for anything other than gacha pull and otherwise exploitative games. I can still play the original Dark Souls with DSFix on modern Windows (or Linux via Proton for that matter). The game is timeless and should never be lost to lazy platform holders.
Your mileage may vary. I think backwards compatibility is important, but we can't expect Apple to do a quality test on every last app on the app store for hours and hours making sure it opens on every phone on every software version.
I believe it's Apple's policy to remove apps that are not upgraded, even if they're still working. Which is baffling and highly questionable IMHO.
Apps are more interoperable than every before so the idea of something you write once and never touch again stops making any sense. Encryption standards progress, privacy entitlements become more granular, image formats get added, retina compatibility becomes expected, dark mode becomes expected, etc. etc. etc.
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
starting at § "The Two Forces at Microsoft" where he describes the Raymond Chen Camp vs. the MSDN Magazine Camp.
[1] https://store.epicgames.com/p/fpvsim-2a20cb
Well I contacted DJI to see if they would replace it, due to clearly a software error on their side, and they basically told me to pound sand. I sent them a video recording of the drone’s final moments (it synced to my phone), and they wanted me to pay for their “free data analysis” because the drone was out of warranty; even though I had only flown it a handful of times. (This is data I know they can see, along with the rest of the flight data).
They ended up offering me a 40% coupon, which is just a joke, and I told them I will keep publicly shaming them unless they can offer a replacement. (So here I am). They also randomly called me at 11am on a workday, twice in a row, and didn’t leave a message; about a week after my emails with cs. Just a really weird experience. Highly don’t recommend DJI.