[Kadin]

This is all true, but just to set expectations: the open source ecosystem seems to be lagging the proprietary world pretty significantly, unless there's some corner where development is really chugging along that's not making it out to the rest of the hobbyist market.

Though there have been incremental improvements in flight control software, and video subsystems have moved (mostly) from analog to 2.4/5.8 GHz and digital, the overall architecture is pretty similar to what it was 5+ years ago. You have a hobby R/C transmitter and receiver driving PWM outputs (through the flight controller, typically an STM32) to hobby-type ESCs which control the motors. The ESCs are microcontroller-driven and can be reflashed, but painstakingly and annoyingly. Telemetry is typically separate from control, which is separate from video. Everything is very short-range and non-IP.

In comparison, a COTS quadcopter from DJI has a single backhaul from the airframe to the controller which does control, video, and and telemetry. And the video is impressively low-latency. (I'm pretty sure they use a WiFi-type chipset and just spew raw vendor frames, and the receiver picks up what it can, best effort. You could do this with an ESP32 in ESP-NOW mode, I suspect?) I've seen some efforts to reverse-engineer the DJI protocol but I'm not aware of a fully compatible implementation or equivalent in the OSS world.

And at the upper end of the commercial/proprietary space you have systems with out-of-the-box autonomy, multiple backhauls over IP -- so they can use LOS/BLOS radio, LTE, SATCOM, whatever you want -- integration with navigation beacon systems to reduce GPS dependence, hybrid motor/generators, redundant power systems, the whole shebang.

There's no real reason aside from developer interest that this situation exists, as far as I can see. The components are mostly all available. A Raspberry Pi running a decent RTOS would have orders of magnitude more processing capacity than an STM32 and could easily do the sort of multi-sensor fusion that the commercial systems do. LTE modems are cheap. A bigger hexacopter or fixed-wing could easily loft one of the small Starlink dishes, if someone wanted to. Stuff like "perching" (landing and recharging from solar panels) is entirely possible.

But from what I can tell, the cutting edge of open source drones is happening behind closed doors in Ukraine and Iran.

Happy to be corrected if there's new stuff that I'm not tracking, but the gap between the "art of the possible" and current practice seems large.

Lots of opportunity though, is the other way to view it.

[qazxcvbnmlp]

Everything here is possible, the gap in implementation is that it’s a) expensive and b) non trivial engineering work. There is vanishingly small overlap between the people whom have the capital for parts, the understanding of the engineering needed, free time to do it and desire to do it for free.

The people whom have the true multidisciplinary understanding to do robotics well can usually also consult (with little difficulty finding work) for $$$s per hour and get the same “problem solving satisfaction”.

Open source software shortcuts a couple of these limitations because you can work on it with little investment over than time.

[Aurornis]

> Everything here is possible, the gap in implementation is that it’s a) expensive and b) non trivial engineering work.

The real issue is that it's just not interesting or worth it.

Why would you want to put LTE or Starlink on a drone? Flight time is around 30 minutes with current battery technology and you're not legally allowed to fly past line of sight anyway. Strapping a bunch of extra gear to a drone would cut flight times and add basically nothing to the experience.

These things aren't popular because they're not interesting to the people who build and fly drones.

[nine_k]

Not interesting to the people who build amateur drones for fun.

I bet that stuff like different Linux kernel schedulers, or entirely new subsystems like io_uring are written by not entirely amateurs and not completely for fun. But the ecosystem is such that open-source licensing works for such efforts. For some reasons, the same is not true for the open-source firmware or hardware used in drones.

One could contemplate on the structure of incentives that could produce a viable pool of open technologies for advanced (including non-amateur) drones.

[nuker]

> Telemetry is typically separate from control, which is separate from video. Everything is very short-range and non-IP.

Check out ExpressLRS, very long range, everyone is using it today.

https://www.expresslrs.org/

[Aurornis]

It's possible to use a DJI air unit for control, but most people prefer ExpressLRS to have a separate, longer range backhaul.

You want your control backhaul to have more range than your video feed anyway. If you go so far that the video starts to drop out, you can fly up higher to regain signal or flip the switch to safely drop the drone. You can also get GPS coordinates back to go find it.

[the__alchemist]

That is consistent with my experience. My highlights:

- Current betaflight devevelopers and leaders are incompetent (They inherited the code base from others), and are slow, and varying degrees of willing, to add higher-level flight-control mechanics (semi-autonomous modes etc).

- The Ardupilot and PX4 configuration systems, and general experience, are user-hostile.

Note that the converses of these hold: Betaflight has a reasonably-good user experience, and Ardupilot and PX4 have extensive higher-level flight control mechanics. If only you could get the pros of both together!

Regarding hardware, frames generally accommodate flight controllers and ESCs elegantly, but other hardware like cameras, radios, and especially batteries, feel clumsy to assemble in a safe and consistent way.

[Fabricio20]

I think to be fair BetaFlight is not aimed at autonomous flight, when I got into this stuff a few years ago I was told "BetaFlight is for FPV (acro mode?)" and "iNAV is for Autonomous" and after giving both a try I can say that my experience on iNAV was much better for what I wanted (autonomous). BetaFlight worked wonders for flying around (very low input delay, etc..) but it was pretty clear it barely had anything related to auto control. Hells, it didn't even have a reasonable return-to-home!!! It would just drift diagonally in the "home" direction and try to land when it felt it was close enough.

iNAV on the other hand REQUIRES a full gps suite for starters (which for me was REALLY expensive) but you can do full waypoint navigation with just that and a barometer.

Of course it's been at least 4 years but hey at least it was pretty good back then already on the iNAV side!

[aftbit]

I haven't touched this stuff in 5+ years, but I wonder how iNav stacks up on your list? I was about 50% of the way through a 7" FPV build with a GPS receiver based on iNav when COVID hit, and between the supply shortages and general life shift, I stopped working on it.

[83]

I fly iNav on a couple planes. I havent updated to the latest version in a couple years but i find it works great. The electronics like gps modules and sensors are insanely cheap now if you go straight from china (aliexpress) - you can get an hglrc m100 gps for about $12 shipped now.

[the__alchemist]

I'm curious too; of those it's the one I have the least experience with. It is currently not an option for me, as the aircraft I would use with it uses CAN perhipherals, which iNav doesn't support.

[bodhi_mind]

Fwiw, betaflight for acro flight is probably the best. Tuning is dead simple. Filtering is possibly the best.

That said, I don’t need much else because I just fly acro mode 100% of the time.

[elcapitan]

Interesting, I wanted to look into building a drone myself next year. Mostly to learn about tinkering with engineering and electronics. What are the issues with the codebases and their development?

[the__alchemist]

This is a tough question to answer in detail: I encourage you to browse yourself. (They are all on Github) but: The BF code base in itself isn't too bad. The AP one is very complicated, and difficult to navigate. The names and organization are confusing. Compiling is finicky and slow due to the tool system they use, and it requires Linux (Note: The compile target is embedded!). I PRed an update to the build instructions, but it was rejected.

For all of these code bases, there is minimal or no documention: Neither guides, nor code comments. The functions, structs, fields, etc have no descriptions of their purpose or use. The modules, where you would expect a description of their purpose and use, instead includes the same license text at the top.

[holoduke]

Sorry but the main dev of Inav is a very experienced dev with a lot of knowledge. He has many youtube videos about developing of drone software/hardware.

[stavros]

This is very inaccurate. The receiver doesn't output PWM, it communicates with the FC over UART. Control and telemetry are one link, open source, with a range of more than 100km on commodity hardware. Ardupilot enables advanced autonomy out of the box, DJI uses LTE for more than 20km range of HD video out of the box.

Sure, you don't have sensor fusion from a bunch of disparate exotic sensors, and the control software could be improved a lot, but it's not as bad as you describe it.

[Panzer04]

Depends on what you want. A lot of the interest in FPV is acro flight, not autonomous, so there isn't a lot of interest in improving that (at least for beta flight)

You act as if separate backhauls is a bad thong - I'm not sure that's self evident. Short range just seems wrong to me - RC transmitters outrage all of the current video tx systems, and in open air video tx is long enough that you run into problems with battery before anything else. The best video tx systems currently is proprietary (DJI).

Open source is good enough for what most people care about. An open source high quality video tx would be awesome, but obviously a significant engineering effort relative to everything else.

[Aurornis]

> In comparison, a COTS quadcopter from DJI has a single backhaul from the airframe to the controller which does control, video, and and telemetry. And the video is impressively low-latency.

Your information is very out of date.

DJI sells their camera and video unit as a standalone part that you can put in your hobby drone. They're on the 3rd generation right now with the 4th coming out soon https://www.dji.com/o3-air-unit

If you want the DJI video feed, you just buy this unit for under $200 and put it in your drone. You get the same video technology as the COTS DJI unit and it integrates with your open-source controller.

> A Raspberry Pi running a decent RTOS would have orders of magnitude more processing capacity than an STM32 and could easily do the sort of multi-sensor fusion that the commercial systems do.

The STM processors have more than enough power to operate the drone.

I think you're missing the point of hobby drones and their controllers. They don't need or even want LTE, Starlink, or any of the other complications you mention. They just need to get up in the air and fly cheaply. The current products work well for that.

People have tried to build drones around Raspberry Pi gear but there's no advantage and a lot of additional cost, size, and weight for something that doesn't help at all.

I don't think people realize how powerful the top STM microcontrollers are these days.

> Happy to be corrected if there's new stuff that I'm not tracking, but the gap between the "art of the possible" and current practice seems large.

Most of what you posted has been tried in open source. It's just not really beneficial or interesting. You can cobble together an LTE drone if you want, but you can't legally fly it past line of sight anyway, so what's the point?

For what it's worth, hobby drones are miles ahead of the COTS drones when it comes to fast flying and control. The gear from DJI is great if you want to safely fly a camera up and hover around, but if you want a fast and challenging drone you basically have to DIY.

[aftbit]

Back in the old days (Phantom 1), it was all IP. The "range extender" box that you could buy for the controller was literally a MIPS box running OpenWRT. I took one apart and used a debug interface to jailbreak it, then connected my own RPi to its network and used it for some degree of autonomous control. I assume things have advanced substantially since then.

I was very disappointed that my Mavic Mini 1 could not be controlled through the DJI SDK so I couldn't use any external apps to drive it. I assume that has also improved, but for a minute at least, the cheaper DJI drones were essentially unusable for my use cases.

To some extent, the availability of cheap commercial gimbal camera drones really set the OSS side of the hobby back. Eventually most of that energy moved to FPV acro drones, but definitely something was lost, as nobody really tries to build a DIY DJI competitor anymore. Of course, DJI drones are absurdly performance limited compared to what is possible with similar sized platforms.