I Reversed a Drone and Landed It with My PC
hardbreak.wiki
hardbreak.wiki
Those first generation consumer drones were so wack. Hard to fly, and very brittle software. I lost it when it randomly decided to "fly home" when I took off from a new location without storing a new gps location. I just had to watch it go straight north and out of view.
Why reverse it?
I wonder if the proprietary packet they decoded here is actually just a MAV_CMD_DO_SET_MODE setting the drone into a takeoff flight mode.
But anyway, for educational purposes it's interesting to reverse engineer anything you want!
Yeah I learned a lot doing it!
But I can’t seem to buy these directly from them? So only through third party resellers? Or is it discontinued?
Because even a 10k Anafi USA does actually compete with the Anzu Robotics alternative. So if it's good enough for surveyors, there is definitely a market in the US.
I just don't understand why Parrot doesn't do that.
Parrot were quite cool; they had one of the only fixed wing consumer drones (Disco) and always offered some of the most open APIs and best SDKs for their drones. Unfortunately their products don’t really hold a candle to modern DJI in terms of flight characteristics and especially wireless link.
https://www.timesunion.com/news/article/Stefanik-s-husband-K...
Would love to write some script to make my drones do predefined things depending on API calls - any clues?
Parrot had very good SDKs but they stopped making consumer drones. You could get one used but beware that the batteries are mostly aging out.
DJI have a Mobile SDK, although it has a quite confusing support matrix and is artificially hamstrung on consumer drones. I think the latest mobile SDK for Android still supports the Mini 3 Pro, so that might be a good starting point (but not the newer 4 Pro). They also have a Payload SDK for their enterprise drones.
Autel also have a mobile SDK although I would describe it as simply a mess.
You can always build your own drone with Ardupilot or PX4 but you’ll have to deep dive into DIY, reimplement or forego a ton of basic flight functions that commercial drones already handle, like visual odometry, and you don’t get a nice camera built in. It’s a viable option for a hobby use but you won’t get anything close to even the most basic commercial drone functionality.
If you don't mind paying a little more and want a ready to fly / kit versions: pick any of these. I remember the Holybro x500 kit used to be very popular (review: https://m.youtube.com/watch?v=cTVtFYONHiY )
https://ardupilot.org/copter/docs/common-rtf.html
You can control them using mavlink / mavsdk etc... the python libraries are good enough.
In both cases you can piggyback your control signals using standard radio or use serial port via dedicated wireless bridge.
That and lack of demand. Most people are nice, key management is PITA, losing expensive toy from a crypto library bug is going to be frustrating.
WPA2 should be still strong enough for most purposes too(threat_model != CIA).
Lack of OTA frames encryption, as far as I can tell, is mostly due to legacy reasons. In DYI FPV there are only couple of transmission standards, most of them using 2.4GHz FHSS or some CC2500 clone so you can mix-and-match transmitters and receivers as you wish. If you use custom TX/RX devices, you are pretty much locked in to that specific vendor. Also, designing a nice transmitter UX-wise requires quite a different skillset than designing nice transmitter RF-wise, so manufacturers tend to choose off-the-shelf RF modules.
Pretty much everyone in FPV is now using ExpressLRS, which is an open protocol. If you want an encrypted air link, then the best option I'm aware of is the proprietary TBS Crossfire protocol.
With the exception of low-cost consumer drones, most larger drones have at least a "Flight Controller" (embedded MCU handling guidance, navigation, and control) and a "Flight Computer" (Higher level *nix based computer running autonomy software), and the flight computer is IMO a more appropriate place to put this.
You could encrypt any Mavlink or proprietary protocol at the application layer if you're using an IP link, or you could also just rely on the telemetry radio to perform encryption between the drone and your ground station.
If you really want encryption, you can simply use a PiZero that talks CRSF to Betaflight and has an encrypted channel to your ground station over 4G LTE/Wifi/Wfb-ng/what not.
But if you're dealing with 4G and PiZero, might as well use Ardupilot + mavlink. Those tools already support this use case much better.
Betaflight is more of a proximity racing drone kind of use case. Only recently did it's GPS return to home functionality got some improvements.
If you want autonomous stuff with more advanced features ArduCopter is the way to go.
- What kind of vehicle do you want? A fixed wing? A multicopter? Something else?
- What kind of payload do you want? A stabilised camera (i.e. camera + gimbal)? Something else?
If there is a DJI drone that does what you want (i.e. a multicopter with a gimbal and a camera), then you can't beat DJI.
The Anafi drone uses regular wifi, with ESSID and password, and that's how the security is achieved. There is no need for additional encryption on protocol level.
It's really the best way - instead of making ad-hoc security mechanisms, rely on well-researched and well-tested wifi security.
(That first sentence, "Start by connecting your PC to the Parrot Anafi’s Wi-Fi network", really carries a lot of load... As Raymond Chen likes to say, "It rather involved being on the other side of this airtight hatchway")
So I assumed ever since that they have their unique opinions about security and architecture of a flying machine control software. Is that odd?
Is that a problem as long as the drone WiFi is protected?
A little bit, yeah. They used to make toys, and you assume that the threat model for the toys is probably the same they would use to build anything else, and then you criticise them based on that assumption.