There are a variety of issues that are directly tied to old hardware that is no longer supported in master. Particular examples of this are issues related to the APM2.6 boards, or Flymaple. Support for these boards is deprecated and it is unlikely that anyone will ever step in to fix the remaining issues on master or the branch at this point, especially when the issues relate to support that ended over a year ago. I’d like to close out these issues, as they are just filling the issues list, and makes it a bit harder to search the 720+ open issues.
For some examples of the type of issue I’m refering to:
In all of the above cases these issues are worthy of fixing, however support for the hardware no longer properly exists, and these issues have just been sitting around with no developer traction as the hardware isn’t supported.
The counter agrument to just closing these, is that AntennaTracker and Rover still function on APM2 hardware, and we should leave these open as a reference for anyone who is still working with the hardware/their own branches.
An alternate proposal from @magicrub was to instead tag these topics as Legacy for now, so that if someone wants to step in and address them or revives support they can be around.
Any thoughts as to whether we should just close these or start to tag them as legacy?
I for one still have a lot of APM2.6 boards that give good service and it would be nice if any issues with the final version of firmware were at least held on record in the event some kind heated developer would address them.
I’m 100% sure that Tracker latest release doesn’t support APM2 hardware and I’m 99% sure that Rover doesn’t either.
I’m for closing unless we can get someone to really commit to maintain the AVR branch in the next week. I’ve read about people wanting to do it but I’ve seen zero action.
Regarding labels, we already have an AVR label that can be changed to Legacy and added to all of these issues. We also have a NotAccepted label that can be added so that it can be easy to track what was closed without fix.
hi @MagicRuB It would be an honor to maintain the APM 2.x branch, i have many improvement that want to push and continue contributting with the code and development. It will help in the unversities to learn and study APM API system too introducing in TD3 Workshop in Bolivia.
APM:URUS system will be the first autoconfigurable and scalable BRAIN MODULE and a CAPE IO for ROBOTICS and AUTOMATED Systems, thinking on industrial aplications.
We highlighted that an owner with APM 2.x board will can work with lastest Ardupilot releases version.
This system have two parts that their will work together:
URUS system will make APM 2.x boards in a BRAIN MODULE for ROBOTICS and AUTOMATIZATION Systems, maybe industrial (Like a PLC), you will can attach an APM: AUTO_CAPE to enhance the capabilities.
APM:AUTO_CAPE based on URUS system. That make and convert APM 2.x boards as an UNIVERSAL CAPE for ANY platform Boards system and make compatibilty for lastest APM FIRMWARE VEHICLES RELEASES from master branch to work together.
Right now this project are being introduced in Ardupilot by developer Hiroshi Takey.
This development are being voted to be maintain the development in the Ardupilot master-AVR branch, VOTE FOR THIS if you are interested on the listed links:
You will can follow the development at the Ardupilot master-AVR branch at:
