Update 1: Bespoke solutions vs. building off of others' work.

Intro

As I was designing the hardware enclosures and general layout, I began to realize that the custom drones I would need to build to stick with my initial approach - a fleet of drones, each drone has hardware needed to run a classification model independent of other drones/a server & the networking equipment to report back results - would need to be capable of supporting a payload of around a kilo, alongside a very heavy battery to allow for a flight time that wasn't completely impractical.

Searching for alternatives.

Since coming to the realization that designing a sufficiently capable drone would take significantly longer than designing software (especially since I have far more experience at the latter, and it would take even longer seeing as this is currently a solo project), I looked to DJI, one of my favorite drone manufacturers for help. After a very long and stressful process of figuring out which drone would actually suit my needs - able to carry some weight (500-800g despite repeated manufacturer recommendations against doing so), support for the DJI SDKs (which is surprisingly limited across their products), decent flight time, and a good camera, I decided to use the Mavic 3 Enterprise & Mavic 3 Thermal (which is technically a M3E with thermal capability) since they (being enterprise drones) are compatible with the DJI SDKs, and more importantly their controllers support Android development & connection over wifi/usb to run Android apps from Android Studio.

Feasability and the impact on the project's core philosophy.

Recalling the initial idea that started this entire project - easily deployable, flexible, and accessible drone-based aerial security that would allow people to protect wildlife preserves against poachers - I began to realize that my original idea didn't really adhere to the idea of being accessible/cost effective. The new system is significantly more lightweight (on the hardware side of things), and as a result is simply a better fit for the project. Not to mention the fact that it now doesn't require users to build their own drones, which not only is fairly difficult, but could require resources that are difficult to obtain for some people/in certain areas.

Pros and cons of the new system.

The best way of thinking about the two systems is roughly as follows: the old is like a house with an alarm system, and inside of the house there's pets that'll bark at people that come in, and chase them around (or robot vaccuums that follow people, a slightly stranger, but better analogy). There's still cameras on the outside that'll alert people of things outside.
The new system works by cutting down on more or less useless redundancy - the only situation those pets or robot vaccuums are useful in is when there's numerous intruders such that the alarm and cameras are completely overwhelmed. It's great to know that the alarm is going off, but the alarm can't really tell you that another five people just broke in in another part of the house, hence the things inside tracking activity. The idea here is that when you need a quick, cost-effective option of securing a large environmental area, you're probably slightly less concerned about exactly where people are, so much so that people are there. My thought process is as follows:

1. With data from patrols, you have the opportunity to secure weak points/better entry points (though I understand this isn't always feasable.)
2. You're probably looking for a quick solution to fix a new problem, eg. poachers have gotten really bad in a specific area in the last month, so a system that doesn't really need a fixed setup is a much better fit.
2.5. Since you're looking to address a problem, you likely aren't looking for a permanent solution, but if you are (or you're satisfied with the system's performance), it'll still work really well.
3. The enterprise-focused approach is much better when you have some massive area to secure, and you want a solution that will work, regardless of the scale of the region. While the less enterprise-focused approach (the new approach) is still very scalable, it's less concrete per se - you don't need to go through extensive setup work, it just works, like plug-and-play devices.
4. The non-enterprise version is actually technically more advanced than the enterprise version, and it's a much better starting point for situations where you have a problem, you don't have that much information on the problem, you want to quickly put an end to it, but are also interested in a more long-term solution and are willing to spend time collecting data to inform that solution.

The short of it is, with this new version, you have a far more adaptive system. That isn't to say the enterprise one isn't adaptive, but rather that it needs to be tailored to each individual application, and as a result, it loses a bit of that accessibility piece. The new version uses DJI drones, which are some of the absolute best drones in the market (I'm not being paid to say that by the way, I honestly admire the engineers behind DJI and what they've accomplished.) Furthermore, DJI drones are really easy to fly, so they can even be used as a standalone tool. I point that out since not only will they work with my software, but they can also be used as a non-autonomous tool for all sorts of applications, such as mapping, search and rescue, etc. Drones are incredible tools, and one of the biggest benefits to the new approach is that you don't have an expensive custom-built drone that's mostly useless for other applications. Consider the DJI drone an investment, if you will.

What's happening to the original hardware/system setup?

The original individualized classification system with an entire fleet of drones as opposed to a single drone is still a good approach to drone based security, it's just not what most people need, nor does it adhere particularly well to the accessibility piece of the project. What I've decided to do instead is to move the primary codebase to an Android (uses Kotlin, for interface app)/Python/C++ open source software suite, and transition the old project setup to a semi-open-source project with greater focus on enterprise applications. The initial appeal in the individualized approach was the inherent independence each agent (a drone) had from the others, making the system as a whole this more complete, adaptive mesh-like thing that could focus on individual tasks while still maintaining the primary task of patrolling the area. However, this can be achieved with the new version by just adding on more drones. The reality of it is that for most people/organizations that would need a budget-friendly approach that could potentially rival employing several people, they probably wouldn't need everything the original setup is capable of. So, to summarize, it isn't going away, but most updates to it will remain closed-source for possible subscription or license-based enterprise applications.

Will this new version still be open source?

The open source nature of the project isn't going away any time soon, despite the transition to partial closed source with the original version. The biggest difference is that since the software side of things is a bit more advanced now, there's a few repositories to look to for the source code, and a bit more work is required to get everything going. I'll put a new tutorial up in the following weeks on setting up the project in its current state, along with what you'll need, limitations, etc. You'll still be able to find the source code for the original version in the original repository, though note that it will be significantly less up to date as I begin to explore the enterprise-focused options I previously mentioned.

Contact Us:

Update 1: Bespoke solutions vs. building off of others' work.