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.
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.
> 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.
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.
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.
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.
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.
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!
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.
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.
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?
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.
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.
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.
> 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.
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.
It doesn't seem that weird precisely because so many people here are in software, rather than hardware. My suspicion is that the median HN reader probably knows a few JS developers, but PCB designers are few and far between in software shops.
Some of the responses surprised me -- I would never have thought about using Fiverr, for instance. I've gone there for graphic design, HTML/CSS/JS, and even some full-stack work, but it never occurred to me to hire a PCB eng there. No reason, just not something I'd looked for before.
In many products, there are different firmware or software loads for the PRC market (specifically PRC -- until recently not the HK versions) and the rest of the world. In some devices it's possible to lock satellite positioning to only Chinese constellation (BeiDou), or introduce error, or just not include positioning by default.
Of course, some of those devices get through, or are carried in by tourists, or are enabled by enthusiasts who load the non-China firmware. This seems to be understood. The Chinese are smart enough, one presumes, to know that actual state-level competitors can get accurate (in the chosen geodetic system) location data without relying on tourists' geotagged Google Photos uploads.
But that does lead to the question, "why, then?" -- if your adversaries know your secret, it's probably not worth the effort of protecting, anymore. (And why, in the US, we know about stuff like VENONA now.) The Chinese seem focused on a different threat: they don't care if a few people have good location data, even if some of them work for the US NGA, they just don't want everyone to have that data.
Which is interesting, because it suggests that that they're less concerned about a foreign government with strategic intelligence, than they are their own domestic population.
This isn't about state secrets vs other states; it's about denying their own population a capability that they find valuable, and thus threatening.
It's the commie way of "fixing" things to deter "enemies of the state": eastern radio bands, inaccurate maps, neighbour spy networks, serveral people on a landline so somebody can always listen, listening rooms for secret police inside state companies, heavily wiretaping citizens, continous party propaganda etc. Most of it is bs and it doesn't work or it's easy to circumvent, but one can never be too careful.
That's only interesting to the extent that an organization has operations in China. Google was mostly ejected from the Chinese market years ago, I thought -- hence Baidu largely taking its place there.
It would be telling if despite that rejection, they were still open to taking direction from Beijing. Google at one point was fairly friendly with US DoD. Clearly the national loyalty of multinationals isn't guaranteed.
Google was not ejected from the Chinese market, they decided to remove most of their products after Gmail was hacked.
https://www.google.cn used to show censored search results, now it only has a link to https://www.google.com.hk , which is blocked because it lacks search result censorship. But Google could use the domain for something new in the future should they choose to.
In particular, Google Ads continue to be available: https://ads.google.cn They even offer WeChat customer service!
As long as they can keep the ad money flowing, Google will comply with all necessary laws and regulations.
Expanding the foreign ownership rule to include social media platform companies (and, frankly, any strategically-important technology company in general) seems like a no-brainer.
Other countries should logically do the same. If Burma/Myanmar doesn't like what Facebook is doing there, they have demonstrated the capability to shut it down on multiple occasions. Setting aside that their government is a basically-illegitimate military junta, if I was them, I sure as fuck wouldn't let a US tech company operate within my country without a significant local presence that I could exert influence on.
"Dictatorships are bad" is not the game-over argument that it once was, maybe 20 years ago.
The Chinese aren't just competing against the US for control of some islands and sea lanes here and there, they are putting their political system -- which is de facto a dictatorship selected periodically by a small ruling clique -- as an alternative model to democracy. One that can compete with and defeat democracy, in fact.
And to be blunt, it's not clear to me that they are losing. We in the US have put ourselves at a disadvantage w/r/t China over and over again, relying ostensibly on the magical power of democracy to always win the day. As far as I can tell, it's straight-up magical thinking.
If we do not take China seriously as a threat to democracy, not just internally to Asia but as an aspirational model of society and the basis for legitimate government, I think we risk losing.
Why we would allow a propaganda outlet of what is effectively an enemy state to operate in the US, and why we would allow technology transfers and other advantageous trade arrangements, is mind boggling to me. Sure, the 'marketplace of ideas' sounds great on paper, but not when the other people don't believe in the same things. That sort of treatment -- access to the US market, both economically and that of ideas -- should be reserved for polities that at least have signed-on to the basic concepts that the US is built on.
Back during the early Cold War, some Americans were concerned that the Soviet model would out compete democracy and free market capitalism. They might beat us without even fighting. Later we found out that it was all a facade. Their purported successes were all lies and failures. The entire society was rotten to the core and eventually the internal contradictions ripped it apart.
China is not to be taken lightly. They are a legitimate threat and strategic competitor. But they also face enormous problems due to unfavorable geography, lack of key natural resources, corruption, malinvestment, and demographic collapse. These problems are not getting better, and I won't be surprised if there's a violent civil war in 30 years (as has happened many times over millennia of Chinese history).
"But they also face enormous problems due to unfavorable geography, lack of key natural resources, corruption, malinvestment, and demographic collapse."
None of these things are true. Stop consuming intellectual droppings from the likes of Peter Zeihan.
China has a monopoly on rare earths and more importantly, processing technologies, which are the key resources for a technological society. It's rapidly transitioning its grid and transportation systems to run on renewable power. Over the next decade it will do in hydrogen what it did in solar and wind. That will give it total self sufficiency in critical inputs like ammonia and synthetic fuels.
Corruption was an issue before Xi's anti-corruption drive. Corruption was wonderful when it served American interests, when the CIA was paying out the bribes. Now that the CIA networks have been torn up and the corrupt officials put behind bars and executed, the US cries that China is "increasingly authoritarian." Well, the louder the US cries, the more I know China is on the right path.
Malinvestment? That's rich coming from an OnlyFans economy like America. You people can't even make enough artillery shells to send to Ukraine. You're being outbuilt by an order of magnitude by Russia, a country you mock as having an economy the size of Texas. Your GDP is entirely hot air and all you make is noise.
As for demography, that's the last thin reed you have to hang all your ill wishes toward China on. Unfortunately for you, that's changing for the better. The Chinese government has shifted from an anti-natal/neutral policy to a pro-natal one and will introduce a raft of policies to boost birth rates. Before you even think that that never works, it does work. It worked in Hungary and it will work far better in China, where the Chinese government can pull many more levers than the Hungarian government can.
Incidentally, the biggest block to Chinese people marrying and having children is the high cost of housing. Guess what the deflating housing bubble is going to do for that.
"These problems are not getting better, and I won't be surprised if there's a violent civil war in 30 years"
I've just demonstrated that they either don't exist or they are getting much better. If you want to look for violent civil wars, look to the US. You won't have to wait 30 years.
"as has happened many times over millennia of Chinese history"
China has millennia of history. Let's see the US make it to 300 years.
I believe your analysis conflates economic systems with political ones. The U.S. doesn’t have an entirely free market capitalism system (see: farm subsidies which fed into supermarket propaganda) and China doesn’t have an entirely planned economy.
As far as political systems go, the collapse of China seems to always be around the corner. But in reality, the U.S. seems to be much closer to civil war. No faction stormed the Capitol in Beijing when Xi was appointed. And even if our political system is not overthrown, it may die the death of 1000 cuts. How much can you honestly say Congress represents the People’s vs lobbyists (professional bribery) and PAC interests?
Context is very important here. Xi was appointed not elected by people. He got almost three thousand votes and one against. There is no election so it can't create friction. Like in eastern European nations where there was one party system and elections were virtually non existent. Friction there is not generated by politicians but usually from poverty or similar systematic issue. As long as Chinese population would perceive themself as improving and even rich system is safe. Democracies works very differently.
> One that can compete with and defeat democracy, in fact.
If it's better then why shouldn't it win? Frankly the lines are blurred. So called liberty is not so clearly championed by the west any longer, and on top of that robber barons and corporations are running rampant through our societies and governments. There's no apparent upside for ordinary people to a Western victory any longer, or at least it's not clear cut.
After all if we're going to be ruled by elites, and be under a system which can compete with capitalist "democracy," might as well be ruled by elites who are ideologically aligned with the people's well-being.
Better in what? This is really shallow relativization of someone mad at current system.
It is not better in any values valued in "western civilization".
> they are putting their political system -- which is de facto a dictatorship selected periodically by a small ruling clique -- as an alternative model to democracy.
Oh please. Just because you people in the west are stuck in the 20th century and have an unyielding urge to reformat other nations and instill a political system you're familiar with, doesn't mean anyone else cares for this kind of idiocy. Stop projecting.
You're just like USSR with its obsession with "global revolution" and counterproductive dichotomies. And just like it happened with USSR, everyone else is getting pretty pissed with all that zealous crap that doesn't amount to anything but guised political opportunism IRL.
It's not like your specific approach to governance looks any less shitty to other cultures. Grow up, embrace diversity, learn to play nice with others - yours is the last civilization that needs to take a long hard look at itself. Either naturally, or through some major political crisis, or, worst case scenario, everyone else will just gang up on you like Saudis, China, US, WEU and many others did on USSR, if god forbid all that global (outside NATO and its few aspirants) distaste for bullshit "holier than thou" attitude reaches a boiling point.
Srsly, grow up. Traveling and meeting new people is extremely helpful in that regard.
Your maps appear to support the premise put forward by aaomidi.
The USofA is labelled there as not very democratic, grouped as with "Flawed Democracies" and the premise put forward was that US Democracy was stripping rights (eg: abortion) and perhaps wasn't a great example of a good democracy.
Only if you really-really squint and look only at americas, while ignoring most of Eurasia and huge chunk of Africa where most of the world's population happens to live.
Try another? The abortion issue is clearly used by either side to drive division, they don't want to fix it. So it's less a stripping and more of a peasants stuck in the middle kind of thing.
I dunno, the whole point of a government based on natural rights theory is the government isn’t the giver of rights, so it can’t strip people of rights. If you’re thinking of privileges granted by a group of doctrinaires, that’s more like an ecclesiastical polity.
It is indeed not the game over argument any more, measured by the people. Both sides of the political spectrum in America have been ever more strongly advocating for authoritarian enforcement of their political goals and both sides have increasing admiration for foreign dictatorships and terrorists.
The extremes are closing in on the excluded middle which doesn’t have much of a voice at all as nonextremist views are attacked as supporting the other sides.
They are not always doing this in the same ways and in the same places, but there is a definite trend.
I’m not making excuses for one side by saying the other side is doing it, both threaten the republic and world peace.
That's only true if only a small percentage of users actually use that particular ad-blocking strategy. If a significant number of users did, then it would be a real concern.
Although I think YouTube et al see an increasing amount of revenue and viewership coming from apps... and if they could, I suspect they would kill their web sites in favor of apps where they have much more control.
I don't mind PiHole, but it doesn't do nearly as good a job of ad blocking as a "real" browser plugin does.
The amount of crap that still comes through when I turn off uBlock -- but am still using PiHole DNS, which is always active on my home network -- is a lot.
Honestly I don't think DNS-based adblocking is really viable, long-term. It's just too easy for advertisers and dirtbag website operators to get around it. There's just no substitute for controlling the retrieval of content elements and their presentation from the application where the user is doing the interaction.
This is why keeping browsers out of the hands of adtech corporations is pretty important; once they control that presentation layer it's largely game over. They can just tunnel all the traffic through a single connection to a relay server, if they want to, and there won't be shit a user can do about it once they've decided that's the only browser they can use.
I get that the WSJ needs to run these sort of pieces every so often to sell papers, but "No One Wants [Whatever]" think-pieces should be treated the same way as the overly-speculative question headlines that led to "Betteridge's Law" in the early 2000s.
Office culture, like the rest of culture, is cyclical. People are reactive, and tend to move in herds. Given an intense external stimulus like the pandemic, we should expect to see waves of behaviors propagating out through time for at least the next few years.
During the pandemic, nobody was in the office, so right after the pandemic, there was a boom in office socialization (in some quarters). Now, apparently according to WSJ, the pendulum is swinging back. This isn't indicative of very much, except that there was a big shock to the office-work social system and it's still not stabilized.
In particular, it's not especially suggestive of what the steady state will be, once these perturbations diminish.
I think we probably have several more back-and-forth cycles around everyone-works-from-home! vs. 40-hours-in-office-or-bust!, before the market works out what the relative value is (to the employer and the employee) of having people in the office and paying for a physical office for them, vs. the flexibility of working from home and of having a potentially international hiring pool. There are benefits and hazards for both parties in either arrangement.
My personal feeling, just based on how the job market has tended to stratify in the past, is that we'll see multiple approaches within each industry/sector, based on how fundamentally creative the work is.
The organizations in a particular sector who are really pushing the boundaries of that industry, who are actually advancing the state of the art, will likely be in-office cultures, because nobody has yet found a substitute for in-person communication particularly as it applies to creative problem solving. But those will represent a small tip of the workplace iceberg, sitting atop (and demanding higher rates than) a larger volume of companies whose work simply isn't that fundamentally creative or challenging, and have to compensate by offering flexible / WFH arrangements, and actively court the employees who are more interested in work-life balance than in working in their industry's version of the Manhattan Project.
That explains why the K8S defaults are bad, but why use K8S at all here?
Personally it seems like a lot of shade-tree server admins are way too eager to bust out much more tooling than is actually necessary for many tasks, just because it's the way that $BIGNAME company does it.
Realistically, most people running a personal or small community's IT system aren't going to need the sort of crazy scalability that container orchestration systems are designed to provide. And if you're not running them at significant scale, the containerization and orchestration-system overhead are often quite significant fractions of the overall resource footprint. Plus there's the unnecessary complexity due to all the levels of abstraction that just don't need to be there.
E.g. for a Mastodon instance, I wouldn't touch Kubernetes or complex orchestration unless I was out of other, more traditional options for scaling. The server side is already broken into a number of components (RoR app, PosgreSQL, Redis, Sidekiq, node.js) which you can separate out onto their own servers, and from there each component has preferred ways of scaling based on need. And while nothing is safe from failure, backing up a bog-standard PostgreSQL VPS is a lot more straightforward than K8S.
If you're doing deployments dozens of times a day, of course automation is desirable. But if you're doing it once, I suspect most people would be hard-pressed to make back the investment of time and additional testing required (well, should be required) of working through a complex container-management architecture.
You kind of explained it yourself. You need to run a number of components, keep track of all of them, be able to update them, scale them, make sure they're healthy and restarted when needed, etc. This is of course possible in a number of ways, but not trivial. You're basically describing an orchestrator such as Kubernetes or Nomad. Especially with an already existing Helm chart covering all the deployment logic (what needs to be deployed, how many instances, health checks, etc.): https://github.com/mastodon/chart it's quite an easy choice instead.
Well I guess I'll share my opinion too. K8s is not just for $BIGNAME companies. Personally I find k8s to be excellent for small shops because it has trivialized the install of large complex apps, opening doors for small groups to have a bigger impact. K8s is simply a package manager for complex deployments.
The learning curve for k8s may be a bit steep initially, but it covers all the areas you _should_ have some understanding of before tackling a large complex install of a web application and puts them in one place: manifests. The best Helm configs provide all the toggles you would need for complex deployments, but provide reasonable defaults (e.g. Mastodon [1]). Literally the application developers are also building the deployment _for_ you. It can't be overstated enough, because of what use is an app if you can't deploy it?
K8s and tools like ArgoCD also encourage some of the best modern practices with IaC. I don't need to hunt for every config file someone might have tinkered with to solve a problem on a server (and hopefully made a doc comment I can find to reproduce it). Every change is there in the manifests. There are OS variations, config variations, etc. and I just don't care about any of that! Just that k8s can run on it and use the resources. The infrastructure and git history is self documenting, allowing me to come into any small team and understand where they are at.
You said orchestration can take a lot of resources: meh. I trust something like k8s to use all of my compute resources more efficiently than a half dozen servers that are probably not sized correctly anyways for the individual components. Digital Ocean will run the control plane for free for example. What the orchestration overhead gives you is trivial reproduction anywhere. It really has nothing to do with "crazy scalability". It's the ability to tear down and bring up the whole cluster in one command. For example you can easily reproduce your full system locally for testing. Good luck doing that reliably with a bunch of servers without making it your full time job and making mistakes constantly.
Re pgsql backups: it's really not any more difficult on k8s. Maybe the problem is too many options: your storage class could do it for you with snapshots, you could have a script connect to the pod and run pg_dump, you could use a third party app like pgadmin4, or you could have sidecars do the work for you (assuming it is configured correctly too). In all cases you need to put the backup data somewhere. You could also use a managed postgres service and completely separate it from your cluster.
Back to the blog post: really the only problem the admin person had was not understanding the default settings of their storage class. Unfortunately that was also the most devastating. They could have also configured ArgoCD to not delete unknown manifests (opening up options to violate IaC). There is an information gap there, there is a gap in testing and backup strategy, and I hope others can learn and avoid getting bitten by it. But this blog post is not the reason to not use k8s. With some, honestly trivial, tweaks, they could still be supporting their community with these apps.
They said they used Vultr's k8s service, and they provide storage solutions also [2]. Did they contact Vultr to see if they implement some recovery safety for them? 30 day deletion policy, etc.? They probably knew about the problem in minutes, and data might have been or is recoverable in the backend.
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.
reply