Thanks for re-organizing @gbiggs, unfortunately I won’t be able to make it today but will look through the notes if they become available
Thank you to those who joined the meeting. We had a good discussion and identified some concrete areas where we can take action. We also identified that our biggest roadblock is, as always, resources.
Here are my notes from the meeting.
- Alejandro Mosteo, author of the Ada client library. Working with drones, and don’t have a specific safety need but it is something that is of interest. Will continue maintaining the Ada client library and interested in SPARK.
- Brad Baillio, working on autonomous vehicles in off-road situations like mining and agriculture. Safety is an obvious need.
- Matt Droter, ROS Agriculture. Using ROS for farming so trying to figure out how to make it safe, what are the general best practices that can be applied.
- Nick Burek, AWS RoboMaker. Multiple groups at Amazon are doing robotics for warehouses, so the robots are safety-critical.
- Geoff Biggs, working on self-driving vehicles at Tier IV, where the importance of safety is obvious.
- Client libraries:
- The Ada client library is working with Bouncy version of
rcl, and feature complete for Bouncy. Alejandro is now going to update it to work with Dashing
- Alejandro plans to start working with SPARK in the near future.
- Rust is intriguing as a language that could be useful in safety, but it is not yet widely used in ROS. Working to classify Rust would be a huge job and probably beyond our capabilities.
- The Ada client library is working with Bouncy version of
- Tools in the work flow useful for safety-critical development with ROS.
- AWS work with TSAN and ASAN is now at the stage that reports are being generated in nightlies.
- The Automated Reasoning Group at Amazon uses a tool called C Bounded Model Checker (CBMC) that
allows you to write proofs against your code and allow you to check the whole valid range of inputs and outputs. It does C++ as well now, but is not great at multi-threaded logic. It is a good tool to find the last bugs in your code.
- The same group is also using many other tools. Nick Burek will provide a list of tools being used.
- ROS QA WG is working on integrating the High Assurance ROS tool into the build farm.
- There is interest in the work that Apex.AI is doing. Are we duplicating their work, or are we trying to make their work open source? Are we competing?
- No one is particularly interested in and/or has the necessary skills to do formal specifications of nodes.
- Classifying tools used in ROS would be particularly valuable.
- We could try to classify launch2 or colcon. Both would be valuable for the community.
- We may be able to try and get Apex.AI on board for classifying launch, in particular its input specification.
- Most of the things discussed so far are tools that support reliability. What could we do to help people make sure their designs using ROS are safe?
- One particularly good idea is to come up with sample structures in ROS for common architecture patterns used in safety-critical systems, such as a 2oo3 architecture, or how a safety monitor should be implemented.
- Document how callback groups and how the threading models work with different executors so that people have a guide for how not to deadlock themselves, for example.
- Provide sample safety cases for ROS-based systems. ROS Agriculture has a small lawn tractor application, which is well-defined and has clear safety concerns. This could be a good sample application to work with. https://github.com/ros-agriculture/ros_lawn_tractor
- Things to attempt:
- Document threading models used in ROS 2.
- Classify launch, especially its input specification, to find the things you should not do with it in a safety-critical system.
- Try CMBC and consider how it might be integrated into ament so it can be easily used in CI and the build farm.
- Develop some sample architectures for using ROS in a safety architecture, and document them.
- (Longer term) Produce a sample safety case for the ROS Agriculture small lawn tractor application.
- Possible effort contributions:
- Alejandro Mosteo can contribute some personal time, and if a student with interest comes along…
- Brad Baillio can contribute some personal time.
- Matt Droter can act as a conduit to the ROS QA WG to coordinate related efforts.
- Nick Burek will try and get some time on the next sprint at AWS for trying CMBC on at least one ROS package.
- Geoff Biggs can contribute work on sample architectures for safety-critical systems, will look into documenting the threading models, and over a longer term will work on the sample safety case with Matt.
Thanks for the detailed minutes, Geoff.
As for your last entry on threading models, you may find something of interest in the Ravenscar profile of Ada, which specifically targets multithreading in high-integrity contexts:
For those of you interested in formal proof of complete systems, above the source code part, this project has been making the rounds in the Ada community a time ago. I think they used Z for the user interface spec (link to github at the end):
Apologies for the spam if you were already aware.
Thanks for that information! I’m always happy to be introduced to new samples of using Z to learn from.
I’d like to set our next meeting in the first week of July. It’s a little way off, but we will start doing more frequent meetings when we start getting more active.
Here’s a poll for the meeting time.
After this meeting, I would like to set a regular meeting schedule. I will send out a poll for that later.
Thanks to those who provided their availability. I have chosen the time that the most people are available for, which is:
Wednesday, July 3, 2019 2:00 PM.
Sorry for the 7AM start for those on the west coast of the USA.
Here is the meeting participation information. If you want an invite, please send me a DM with your email address.
ROS 2 Safety WG
Please join my meeting from your computer, tablet or smartphone.
You can also dial in using your phone.
United States: +1 (571) 317-3116
Access Code: 485-233-997
More phone numbers
Australia: +61 2 9091 7603
Austria: +43 7 2081 5337
Belgium: +32 28 93 7002
Canada: +1 (647) 497-9373
Denmark: +45 32 72 03 69
Finland: +358 942 72 0972
France: +33 187 210 241
Germany: +49 693 8098 999
Ireland: +353 15 295 146
Italy: +39 0 230 57 81 80
Netherlands: +31 202 251 001
New Zealand: +64 9 913 2226
Norway: +47 21 93 37 37
Spain: +34 932 75 1230
Sweden: +46 775 757 471
Switzerland: +41 225 4599 60
United Kingdom: +44 20 3713 5011
New to GoToMeeting? Get the app now and be ready when your first meeting starts:
I’m truly sorry but recent developments will keep me out of touch during the Jul 2-3 period, so I will miss the meeting.
I’m afraid I will be on vacation from July 1st through the 5th and will be unable to attend this instance.
I am interested in contributing to this and will attend the next meeting.
We are making our systems safe and we are parsing the necessary standards to understand what we need to do for ROS. ROS safety is a very critical piece for our company.
A bit of background on my experience. I have taken surgical robots + surgical navigation through FDA certification (software, system and hardware) and have done similar analysis for modular industrial robot arms. Right now I am deep in this for self driving vehicles and its all the same once you have gone through the process.
Great to have you, @Shawn_Schaerer!
I know from my own experience that the medical domain and the automotive domain are not exactly the same, but it will be good to hear from someone who’s been heavily involved in both what the specific differences are and if they matter or not.
Here are the minutes for the meeting held on 2019/07/03.
- Geoffrey Biggs (Tier IV/The Autoware Foundation)
- Jacob Hassold (DCS)
- Lalit Begani (Intel)
- Matt Droter (ROS Agriculture)
- Shawn Schaerer (Northstar Robotics)
- Sohin Shah
- Victor Mayoral (Acrutronic Robotics)
- Reviewed ideas that have been thrown around so far
- Sohin gave a presentation on the small lawn tractor application from ROS Agriculture that we are considering for our reference application
- ros_lawn_tractor_safety.pdf (1.1 MB)
- A retrofitted lawn tractor, with a Rasperry Pi 3 providing the ROS master and an NVIDIA Jetson Nano for the AI-based perception.
- The use case is to cover an area while avoiding obstacles
- The response to (dynamic) obstacles is to just stop and wait for the operator to help
- Current safety features are:
- An estop; loss of power to this relay kills the engine
- A remote kill switch
- A tele-op deadman switch
- Ultrasonic range sensors are planned
- The navigation stack (in ROS 1) has disadvantages for safety, e.g.:
- The stop response for obstacles causes the local planners to enter recovery behaviours, which eventually leads to the goal being abandoned.
- Declaring an emergency doesn’t mean anything unless the nodes performing their actions are actually killed.
- They have designed three different levels of safety threats
- They have a lot of questions about how to do safety properly
- They lawn tractor is being used in an agriculture robot challenge (agBOT Challenge), which has quite well-defined environments and goals that could be useful to define a reference application
- Acutronic has a sample use case they have been using for their security work
- They are putting together a simple pick-and-place use case using a simple modular robot arm
- The use case is fairly detailed and an excellent starting point for doing safety work
- To be clear, we do not intend to produce a set of general safety documentation for using ROS in a safety-critical system, but provide safety documentation for the ROS-related parts of a specific application on a specific robot as an example of how
- There is an EU project for security and safety being proposed by Acutronic Robotics called RECLAIM
- If the project gets funded, then Acutronic Robotics believes they can bring in some experts in safety for robotics to contribute to the working group
- Funding result is expected to be known by the end of the year
Good meeting today. Should we get our own subcategory on discourse that is specific for the Safety-critical WG?
Is there yet a slack or discord channel where everyone talks (or IRC?)
I am very interested in this initiative towards safety, even though i have limited experience in the subject. I hope that, by getting involved, i can start building up some practical experience in safety for robotics and embedded software.
I have experience with:
- embedded software programming in general, with c, c++
- python programming
- hardware design, hw fault tolerance, hw verification
- limited experience with sw verification
- ROS and robotics
I also coordinate a robotics lab where we have autonomous boats and drones using APM/ROS. Perhaps, if you need more case studies for the safety methods, i could provide additional details.
Considering the 1st post of this thread, I believe I could contribute to:
- Use of tools to support the above
- Additional processes, tools and methods needed for building a safety-critical robot that are not currently covered by something in ROS but could be
- How to make the client libraries usable in a safety-critical system, and work on safety-focused client libraries (for example, a SPARK client library)
So, i am really interested in the subject. If someone with more experience wants to give me some hints about readings, papers, etc. Please, go on !! dont be shy !
Please, also fell free to suggest ‘homework’ , assignments , etc.
@droter thanks for the sugestion. It is a very didactic presentation. However, I am fairly familiar with the basic defitions in the area of Safety. What I am really expecting is some ‘hands on’ problem to start getting some actual design experience in Safety.
I believe I will start by studing this doc.
thanks again !
I’m happy to discover this group !!!
Railway industry will use more and more robots in the future : autonomous trains and also maintenance robots. I “campaign” for a ROS usage for all those applications. But the certification is a major issue for railways…
Some safety requirements for our industry in Europe are described in 3 norms : EN 50128, EN 50129 and EN 50126.
Those norms correspond with different levels (software - 128, system - 129, specification and demonstration of RAMS*)
Is it already possible to compare the content of those documents (or may be first the EN 50128) with the decisions made for ROS2 ?
RAMS : Relaibility, Availability, Maintainability, Safety
I was looking for the some good discussion forum for functional safety with ROS in robotic applications.
I believe I have landed on the right place.
I am currently involved in a development of a mobile robot with a safety goal of PLd. I would like to to participate in the discussion and I have decent understanding of functional safety.
EN 50128 is a standard based on EN 61508 and as far as I know, nothing in ROS 2 has been done to comply with 61508 or any other standard based off of it.
I haven’t had a chance to read it yet, but this white paper on “Safety first for automated driving” may have some relevant info.