To make it easier for users to find Ardupilot Service Bulletins, I think it would be worth setting up a dedicated forum section for them, much like how the CubePilot Forums do. The current practice of putting the bulletins in the General Blog section tends to have them drowned out by newer posts pretty quickly.
[On a side note, how are we tracking the status/resolution of service bulletins?]
I think we need to carefully define what we mean by Service Bulletin, and I don’t think the forum is the right place. I really think anything akin to a Service Bulletin needs to be subject to review and approval prior to release: GitHub (which includes the wiki) is a better mechanism for that than the forum.
This was discussed during the devcall this morning, with the general outcome that better visibility of Release Notes is a good place to start.
As for tracking service bulletin closure: @proficnc is best placed to answer that, as he’s the only person who’s issued one.
Quite right. I was inspired by this post by Randy: Copter-3.6.12 released! Critical Safety Update for those using 3.6.10 (or earlier) , which described it as a “Critical Safety Update”. So maybe that’s a better term to use.
That post is a great example of why this type of thing needs review: that specific issue isn’t general to all 3.6.10 or earlier - it’s only applicable to ChibiOS firmwares (.apj), and doesn’t effect NuttX firmwares (.px4). Many unaffected users now think they’re affected.
Having authored and reviewed Airworthiness Directives in a previous life, it is essential that this type of communique is clear, precise and accurate.
What service bulletins, and issued by who for what? There is presently no such thing as an ArduPilot service bulletin. To my knowledge, the only hardware manufacturer being proactive about the their products is Hex.
Is ArduPilot going to start issuing SBs? Will manufacturer specific SBs be posted here? What about literally every other manufacturer that does nothing proactively? I hope ArduPilot doesn’t try to do it for them.
Only for the Ardupilot software, issued by the Ardupilot developers. An example of this (the I2C storm issue) I linked in an above post.
Having been heavily involved in product issues over the years what I can say is no one method works for all, forums, emails or de notification, any solution needs to be a combination on all.
I2C Bug has largely gone under the radar In the wider community .
Imo there needs to be a way to get this info out and relaying on people reading release notes or Git is not enough.
There needs to be an approach that covered all aspects of the user base such as
• ArduPilot safety registration scheme, upon downloading with GS software or on website user prompted to register for critical updates to create dedicated list for notification of critical issues.
•Email to registered members of this group.
•Prominent forum/Social media posts like has been done already
• Software identification and notification on connection to Gs and warning.
•Cross posting on non owned/partnered forums
• Prominent Docs and release Norse’s on high lighting the issue in the Wiki and here. A release notes section perhaps.
Much of this can be and has to be driven by the community but also needs process framework in place for it to follow as each issues arises as it con not be relied open for people to go looking for issues.
I like the progress that is being made in this area. It’s probably not going to be instant. I recognize the effort that was made over the last dev call, and I see the new link at the top of the Release Notes — Plane documentation page.
I also created an issue for tracking on github, although the discussion could probably go in either place. Release Notes & Critical Safety Updates · Issue #2366 · ArduPilot/ardupilot_wiki · GitHub. A copy of my OP on github is below:
Having the link to the github page with the release notes is an excellent start for a uniform location for the release notes. To take this to the final step, I think a few options could be considered.
- Create or rename the “project-news” html to be “releases” or “release-notes” so that the page title and URL match and there is no confusion. Maybe even redirect to a simpler URL like ardupilot.org/plane/releases
- Advertise this page on the ardupilot.org homepage or somewhere higher in the left-hand menu/tree instead of at the bottom in the appendix section.
- Auto-generate the text and bullet points on the actual wiki page to avoid redirecting to the github format (that most non-code users are generally uncomfortable with). This doesn’t need to be physically copying and pasting the same information; leave the github page as the original source and the wiki page should reference it. This is done with the full parameter list, so I’m assuming it can be done with this page as well. It should only need to be updated once daily.
- Add button(s) to subscribe to mailing list(s) that will inform them of new stable, beta, or critical safety releases of firmware by email. I think people have been asking for this as the social media and forum posts can be buried quickly in just a few days’ time. If we wanted to go a step further, we could maintain a little database of users and what autopilots they want updates for. For example, if a critical safety bug was found on the Cube Orange, why does the everyone need to be spammed about the update? This could really help the communication between the developers and the end users. Just subscribe to the hardware you want updates for.
I also like the idea of a registration scheme for those who are interested in keeping up to date. These are great ideas, and we’ll see what the developers can implement.
A registration scheme isn’t something I’d want to manage: but I understand the basis for the suggestion. Where I see this progressing is getting the relevant info into formats for both human and machine accessibility, then having the wiki and GCS’s present it to the user base. I think the GCS’s should be able to filter based on detected board type which in my view would go a long way to avoiding a registration scheme. Thanks for pushing this along!
I like the idea of something machine accessible. Means we can add/modify user-facing endpoints rather easily. We’d have to define a common format/process for doing this. A good discussion topic for the Developer’s Conference in Canberra 
As a general thing though, note that not everyone uses Mission Planner or QGC. We’d definitely need a non-GCS notification for users.
I’d personally like a mailing list (not sure if this is what you mean by a “registration scheme”?) where users can just sign up if they want the Service Bulletins/Safety Notices in their inbox.
[Yes, I’m willing to put my hand up to help manage this]
Something like the manifest.json that the GCS’s use for firmware, or if the decision is to use the forum, an RSS feed, would be preferable to a mailing list in my mind. Most mail clients can subscribe to RSS.
I’m fairly hard over that the forum should not be where the primary document is drafted and housed though. That must be subject to review and a release process.
Regards,
James
The issue is with the GG based option alone is people who are not connecting don’t get warned.
Ok let’s be realistic most who use this do so as long as it prompts on connection then it will cover a lot.
Absolutely! The forum should just link to some official document, however it ends up getting done.
To further the discussion, here’s a few examples I’ve found from other projects. They are all security bulletins though, as I couldn’t find any good examples for flight/vehicle controllers.
They give some insight into what sort of information should be collected for a service bulletin.
Agree that we’d some backend repository with a review/release process. Then the various frontends (GCS, website, etc) can pull data from there.
Netflix: https://github.com/Netflix/security-bulletins
Amazon AWS: https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc
Istio: https://istio.io/news/security/
An idea relating to terminology… for the FAA in the US, “Service Bulletins” relate to optional actions that improve or fix something. They are not mandatory. “Airworthiness Directives” on the other hand are critical items that must be complied with to maintain “airworthiness.” I think ardupilot should adopt some form of severity index when issuing any sort of updates.
In both cases, these publications are very specifically targeted to make/model/SerialNoRange. Unfortunately we cannot track vehicles in the same way; however, most of the issues that I have encountered in the last few years have been for specific hardware or configuration settings that cause an issue.
The “Service Bulletin”/“Airworthiness Directive” terminology is fairly well global, but as ArduPilot is not a national airworthiness authority we should steer clear of nomenclature used by airworthiness authorities.
A severity scale makes sense though, and is consistent with how the latest releases have been communicated.