The support for boards based in PX4 hardware designs, like the Pixhawk, Pixracer and Pixhawk 2, hasn’t been and won’t be removed. We also support other boards and always welcome everyone who wants to port ArduPilot to their board.
3DR hasn’t been funding the project since almost the beginning of the year, an announcement was made at that time and led to the creation of this forum, as we parted our separate ways.
The future looks bright: in a few days we got 8 partners (http://www.ardupilot.com/partners) and we expect to get more in the coming weeks/months. Also we have been very active, see https://www.openhub.net/p/ardupilot for some statistics, including that we have an increasing year-on-year commit rate.
Wow! What a wild ride! Congrats to the team for sticking to their guns! I guess it’s time to move over here and support Ardupilot! That took a hell of a long time!
Let me know if there is anything I can do to help Ardupilot.
I feel much better supporting the project now and I have renewed enthusiasm to help out.
Yes it is time to move over here – I hope a new landing page can be developed that will encourage postings from other open source projects in the field of robotics . I think I will limit my contributions to DIYD henceforth. Going to up the monthly contributions as well.
I encourage Ardupilot.com to think about having a more sophisticated fundraising approach. Have different levels with rewards (Mugs, T Shirts, Gift Certficates to vendors, and maybe a Badge against people’s names on Ardupilot.com). I think this stuff does work – NPR has become very good at this. Just a suggestion. You really need the $10-20 a month recurring donations. Most people in this hobby or business can easily afford this.
Our intention with the new landing page is to have everyone contribute with news and I believe we won’t be limiting what can be added, as long as they are robotics related. We discussed a more general website but it would be another one to manage and developers’ time is already limited. Right now the page is simple and static because we didn’t have the time to do the background work before InterDrone but we will be working to make it better.
Regarding fundraising: there is a plan to make rewards but right now we only have the keychain. We also plan to put the donors names in our website and I think the idea of having a badge over here is a good one.
Thank you all for your support, we really appreciate it.
A question related to branding/trademarks.
Obviously the DroneCode website hasn’t been updated in some time, but I note that in most instances it uses the “APM” term and logo, rather than Ardupilot. Does the Ardupilot project control the APM branding, or has this been retained by DroneCode/3DR/Chris Anderson?
We want to refer ourselves as ArduPilot. APM is also the name of the old boards that we don’t support anymore and it is confusing for users. Also, APM is a trademark all over the world for lots of different uses.
Completely understand - I’m not suggesting that the project should use it.
It is just something to watch/address during the transition, as it might confuse users/consumers if DroneCode owns and continues to include “APM Multiplatform Autopilot” in their documentation and website.
@james_pattison it doesn’t look like APM is trademarked (for autopilots anyway). I understand your concern and we can watch out for it, but I don’t think DroneCode is likely to be making much use of the APM name in future.
As a relatively new user, I’d suggest maybe it’s time for a rebranding of the project. "ArduPilot’ is obviously derived from “Arduino”, which, to those just getting started, means it should run on hardware called an “ArduPilot Mega” (APM), but the current generation of software/hardware has evolved away from the Arduino, at least for multicopters. Something called ArduPilot (again, bringing to mind Arduino) is not the immediately obvious choice for a Pixhawk running an STM32F* CPU, and it’s odd to think that ArduPilot’s ArduCopter 3.3+ won’t run on an ArduPilot Mega, especially for a new user. I think something more along the lines of Baseflight/Cleanflight/Betaflight, which keeps the hardware ambiguous, would be more appropriate. Just my 2 cents.
I’d also like to suggest this thread be relocated to the General Discussion area, I don’t know about other folks but I’m getting emailed every few posts. Those interested could subscribe to a thread there, while not spamming the rest of the forum members
You should only receive e-mails if you subscribed to the thread I believe. At the end of the thread you should have a button where you can choose what notifications you receive.
Just my two cent: We would like to support the ArduPilot project with our hardware and may be bringing some rugged and high-level products to the ArduPilot community. I feel the community is great with a lots of high potential, but it is lacking in professional hardware (same for PX4). This is where we would like to fill the gap. For sure 90% of the community will not be interested in this kind of hardware, but 10% could be.
ArduPilot is not our core business, as the AdaRacer-FCS (and its ecosystem) has been specificaly made for the Ada/SPARK programming language and community, but I feel it could be a good complementary way of cooperation between AdaPilot and ArduPilot in sharing some professional hardware.
@tridge@MagicRuB: clearly what’s been happening here seems very crummy, but two thoughts came to mind:
Have you considered having an Apache style CLA on AP that would allow you to change the license if you decide it is the best course of action?
As I was discussing a week ago, as much as the GPLv3 is great for many uses, I am worried that any vendor of any piece of hardware that has enough potential to injure or kill others if it misbehaves, is not going to feel good about selling hardware that can be reflashed by the end user with firmware that they did not verify is safe, and for which they could be sued for millions if their hardware crashes and injures/kills others after the firmware was replaced/modified as allowed by GPLv3.
If a 50lbs drone to do crop dusting is modified by an end user, and crashes into a school, wiping out some kids in the playground, do you think the parents aren’t going to sue the drone company into oblivion, or care a single second that the firmware had been modified by the end user as required by GPLv3?
I personally think if you had GPLv2 instead, or Apache2, more such companies would be willing to be using the great ardupilot codebase.
I’m sure many such companies are not against open source at all, nor do they require a BSD license, but for the reason I just explained, GPLv3 requires too much from them liability-wise.
As much as GPLv3 would be great for my Tivo or my Chromebook, or my phone, I’d be more than happy enough with GPLv2 for ardupilot since it’s still just as free, and if some vendors ship ardupilot hardware that I can’t reflash, I don’t have to buy their hardware.
As things stand, it’s what they are going to do anyway, except they won’t even have to provide their source code at all, which is even worse.
@marcmerlin you’re talking to a couple of copyleft fanatics here (and I mean that as a neutral description, not anything else).
No. That’s not the way to do it. Any device should FORCE signing of code. What is should NOT do is force using the manufacturer’s keys - it should be easy to add your own keys, and sign your own code.
That way, code can be modified as per the GPL, but the mere existence of a user key on the device indicates that they (may) have tampered with the code. And it won’t need much more than a cursory glance to tell what code has been tampered with.
That’s (sort of) the way it’s always been, and that’s the way it should stay - as in - even with mechanical devices people have been able to tamper with settings, and what you need is the digital equivalent of a “warranty void if removed” sticker.
I have heard that from several sources, but I don’t think it makes any sense. Our world is full of large dangerous devices with user replaceable parts. You can buy a new steering wheel, engine, tyres or brakes for your car, and if those replaced parts fail and cause an accident then the original car manufacturer isn’t responsible. Car makers have not responded to this supposed risk by welding the wheels to the car.
The same thing happens in aviation. You can buy new parts for your full sized plane (including autopilots) and if those parts fail then you won’t have any luck suing the original plane manufacturer if the failure was due to the replaced part.
In fact, I think the opposite argument is much more plausible. Drone makers often abandon their products, leaving users stuck with DRM on those drones with no ability to update for new fixes (including safety fixes). Being able to put a new (fixed) firmware on the drone makes it safer and is what a responsible manufacturer should enable.
I know many companies do want to use DRM to prevent users from updating the software on drones, and this liability argument is used to justify that. I don’t believe for a minute that it is the true motivation. I think instead it is motivated by increased market control. Having DRM on a drone gives a company a few things:
they can control who can sell add-ons to the drone
they can stop supporting an old model and pressure users to buy a new model instead of upgrading software in the old model
Neither of those things are good for end users however, and they are most certainly not good for the DIY community.
I don’t mind at all if drone manufacturers include additional steps that are required to initially “unlock” a drone before you install a new firmware. This could include a screen with copious warnings on the dangers of modifying the software. Locking it down completely is not a good idea though and I don’t think can really be justified on liability grounds.
What would be nice (and I doubt it would happen) is that insurers should insist that the device (be it drone, car, whatever) has current, suitably patched and secured, code installed. And if it doesn’t, the premiums go through the roof.
One thinks of the flashy new keys that come with, say, BMWs, that are so secure that owners have gone back to using crooklocks to protect their vehicles from theft.
If the insurers would keep a “vulnerability register” and the owner has to show their gear has been protected against it, manufacturers might find it hard to fight against owners of brand new gear finding their insurance premiums are sky high … but - I won’t say the insurers and the industry are in cahoots - but I can’t see them as seeing it being especially in their interest to have safe code …
@tridge your points are well taken, I think there is no one true answer here, but just on the aviation side, you absolutely cannot change a random part on a certified plane without said part being certified and replaced by a certified mechanic.
You also cannot change the software on any piece of the plane with anything other than the one from the manufacturer.
Similarly, few cars allow you to change their firmware in a supported way (there are aftermarket solutions, piggyback CPUs and full CPU replacements which are tolerated for cars but absolutely illegal for planes unless it’s a non certified homebuilt airplane which you then are required to have built at least 50% of) .
So basically in the US (and I think most everywhere else), you cannot buy a plane and replace any software on it with your own.
I don’t speak for the FAA of course, but I’m guessing they’ll be doing the same for UAVs: if you built it, you can install your own firmware, if you didn’t build it, you will likely not be able to put your own firmware on it, before long.
I do not see that happening any time soon with UAV’s in the US that are under 55lb takeoff weight and have no Type Certification. It would be impossible to enforce. That does not mean that UAV manufacturers will not lock down their products to force obsolescence and keep sales going once the market is saturated. But I don’t see the FAA having anything to do with it because they have way bigger fish to catch.
The issue with full size aircraft is not the provider of the software, but the assurance/certification of it - it isn’t that you can’t change software, but that there arent any after-market options available to do so, and recertification is prohibitive.
@ChrisOlson you’re half correct actually. I already had to register my self built UAVs which included a full description, manufacturer and all (because the pilot registration thing is not acceptable to me due to its restrictions). The FAA reviews it and can give you a tail number, or not.
I believe (I could be wrong) that for commercial UAV applications, you have to go through a similar process.
Now, I think you’re right that the FAA does not currently enforce anything on locked down firmware for even commercial UAVs, but they do for full size aircraft, so I wouldn’t be surprised if one day they start doing this for heavier commercial UAVs (maybe 4kg to 20kg) since quite frankly they start getting in the somewhat lethal category.
As for bigger fish to catch, sadly, I’m not sure that will be lasting for much longer, I think heavy UAVs will become the bigger fish to catch before long. Admittedly they already started by threatening anyone flying even a foam airplane that weighs more than 250g with up to 3 years in jail if they don’t take the right registration steps. Needless to say that I think it’s way overboard, but they’ve already done it and now they’re just saying that they likely wouldn’t apply the full 3 years in jail for a small foam plane, but that does not fill me with any joy or reassurance
(and I mean that as a neutral description, not anything else).