Hacker News Reader

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...

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.

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.

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

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.

Maybe a software-esque “right to repair”

Sounds pretty close to what the GPLv3 does, doesn't it?

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)

* https://pastebin.com/CPB7RBdK

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.

That would be a great way to guarantee that nobody builds hardware in your country.

It would also do absolutely nothing in this situation where the product already comes from a foreign country.

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.

A depressingly accurate summary...

not just 32bit. No more powerpc (and soon x86), no more system 7/8/9 apps, etc. It's now a long tradition.

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.

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.

People were saying this in 1923 after the radio became popular.

And they were correct then and they're correct now.

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.

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.

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.

I like this use of “artifact”

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

I think they’re saying every hardware company is this way, with rare exceptions.

Sounds like the world in which the platform keeps moving and breaking APIs is a pretty bad world!