ros2 / design

Design documentation for ROS 2.0 effort

ROS 2 design

This repository is a Jekyll website hosted on Github Pages at http://design.ros2.org/.

The repository/website is meant to be a point around which users can collaborate on the ROS 2 design efforts as well as capture those discussions for posterity.

The best place for discussing these topics is the Next Generation ROS category on the ROS Discourse.

Working Locally

You can run the site locally by running this command in this repository:

jekyll serve --watch --baseurl=''

And navgiating to your browser to:

http://localhost:4000/

Working Locally (Docker)

If you don't want to (or can't) install Ruby and other Jekyll dependencies directly on your machine, you can run the server via Docker. Navigate to the directory containing this repository, and start the server via

docker run -v $PWD:/srv/jekyll -p 4000:4000 jekyll/jekyll jekyll serve --watch --incremental

You can then navigate your browser to:

http://localhost:4000/

Site Setup

Site is a Jekyll website with design.ros2.org as the CNAME.

The site requires no static generation outside of github's static jekyll generation, which means that changes are published to the site as soon as they are pushed (can take up to 10 minutes for github to update the site).

The github login (for showing pull requests) also requires that https://github.com/prose/gatekeeper is setup in heroku, and the url for that is http://auth.design.ros2.org/authenticate/TEMP_TOKEN. Because of the free Heroku instance, the first time someone logins in after a period of time, there is a delay.

design's Issues

Request for information on the extensibility of ROS 2.0 messages

Originally from @andreasBihlmaier in #70:

Please add a short paragraph about "Binary compatibility of message revisions" in the current DDS implementation. For me the most relevant question is whether it will be possible to preserve backward compatibility if messages are extended, e.g. will addition of fields (or even constants) break compatibility as in ROS 1.0 (e.g. as between Indigo and Jade ros/common_msgs@7e11635)?

design how to support component node migration between containers

This was mentioned in #34 but needs it's own discussion. deferred here

State machine diagram / text mismatch - no 'fatal_error' state

In the state machine explanation for a node (http://design.ros2.org/articles/node_lifecycle.html), it says - "If an error that cannot be handled by the node/system occurs in this state, the transition to the fatal error state is taken."

There is no fatal_error state in the diagram, nor is it mentioned anywhere else in the document.

Remapping Names isn't apply to node name on ros2 bouncy

Remapping Names is apply to node name on ros1
example：

       rosrun turtlesim turtlesim_node __name:=A __ns:=/pp
       rostopic list 
                    /pp/turtle1/cmd_vel
                    /pp/turtle1/color_sensor
                    /pp/turtle1/pose
        rosnode list 
                     /pp/A

Remapping Names isn't apply to node name on ros2 bouncy
example 👍

         ros2 run demo_nodes_cpp talker __ns:=/tt __node:=JJ
         ros2 run topic list 
                  /tt/chatter
         ros2 run topic list 
                  JJ

My question is why not the action is not same between ros1 and ROS2 bouncy。

ROS Microservices

Hi, would it be possible to create Microservices (for not necessarily robotics applications) using ROS 2? If yes, it would be great if you could provide some packages/resources for that along the way so that those who are interested can grab just the core run-time of the framework that is needed for creating their business microservices without the robotics components of it. I think it would be a very valid use case to use ROS as the abstraction layer of DDS transports. Thanks!

Ideas for changes to the migration guide

So I have some ideas for changes which would be reflected in the migration guide and would make it easier to translate between ROS API's. I wanted to get feedback on them before opening a pull request for each:

---

• Provide a version of create_publisher (and others) which take queue_size instead of a QoS struct.

Internally this function would get the default QoS struct, change the queue_size, and then call the current methods.

Example of how the migration guide would then look:

//  ros::Publisher chatter_pub = n.advertise<std_msgs::String>("chatter", 1000);
//  ros::Rate loop_rate(10);
  auto chatter_pub = node->create_publisher<std_msgs::msg::String>("chatter", 1000);
  rclcpp::rate::Rate loop_rate(10);

• Done in ros2/rclcpp#125
• For subscriptions too: ros2/rclcpp#128 and ros2/system_tests#56

---

• Use advertise instead of create_publisher and subscribe instead of create_subscription.

I'm sort of agnostic about this, but it might help conceptually in the transition.

Example:

//  ros::Publisher chatter_pub = n.advertise<std_msgs::String>("chatter", 1000);
//  ros::Rate loop_rate(10);
  auto chatter_pub = node->advertise<std_msgs::msg::String>("chatter", 1000);
  rclcpp::rate::Rate loop_rate(10);

We could also provide an alias from one to the other, but then we make the API bigger, so maybe not.

A little rational for the new name is that in C we need a create/destroy pair, and create_publiser/destroy_publisher made more sense than advertise/destroy_publisher.
Using the same name in C++ was just for consistency.

---

• Provide versions of publish and signatures of callbacks which take const references rather than smart pointers.

This would be in addition to what's there, it would affect the guide as such:

//  std_msgs::String msg;
  std_msgs::msg::String msg;

//    msg.data = ss.str();
    msg.data = ss.str();

//    ROS_INFO("%s", msg.data.c_str());
    printf("%s\n", msg.data.c_str());

• Finished in ros2/rclcpp#127
• Tested in ros2/system_tests#55

Write documentation design document

AC:

• Whitepaper describing the documentation process
• Examples for how to write documentation with the different tools

Follow up ticket: implementing the toolchain.

rclcpp::init must be called before everything?

Recently, I find that we must call rclcpp::init (or rclpy::init in python) before everything. But in some cases, I wana just make a node and create some publishers and subscribers for later usage. For example, i would like put the node( with some publishers and subscribers) into a library. but the init make it hard todo that. In ros1 it easy to do that. Do i have some workaround to achieve it.

node with the same name

in ROS2's concept, can it has the node with the same name, expecially considering the builtin client service (eg. list_parameters, get_parameters, set_parameters ...), for this will make the two node fully connected by these services and clients.

Design By Contract

Is it planned to add "Design By Contract" functionality to ROS2?

On the node level the following considerations come into mind (impact of DbC on timing):

• node is topic publisher
  • (min./max. "guaranteed" topic publish rate)
  • min./max. "guaranteed" topic message type values
• node is topic subscriber
  • (min./max. expected topic reception rate)
  • min./max. expected topic message type values
• node is service server
  • min./max. service request message type values
  • (min. "guaranteed" service response time)
  • min./max. "guaranteed" service response message type values
• node is service client
  • min./max. service
• node is action server
  • (max. feedback transmission delay after goal request has been received)
  • (max. result transmission delay after goal request has been received)
  • min./max. "guaranteed" action goal message type values
  • min./max. "guaranteed" action feedback message type values
  • min./max. "guaranteed" action result message type values

Style review/clarifications

I am in the process of a style review of the design docs, to help myself get up to speed with ROS 2 design. I will use this issue thread for clarification questions and eventually submit a PR with some changes for style and brevity. Please let me know if I should submit small things like this in separate PRs, or if I should use this thread for overall style comments.

@wjwwood, can you clarify the sentence in discovery_and_negotation.md:

"The existence of a node, its host machine and host process are products of the graph's execution, which would be done by the user executing each in turn, or by a process management system."

so the graph's execution "is done by" the user executing each in turn? What are you referring to with "each"?

I would interpret the sentence as the following, please correct me if I'm wrong:

"The node's existence, its host machine, and its host process are side effects of the graph's execution. These details are determined by the user initiating execution of the graph, or by a process management system."

Remapping | Is ** greedy or lazy?

The remapping design doc does not state whether ** is greedy or lazy. This can change the outcome of some remap rules.

Example:

• rule /**/foo/**:=/\1/\2
• name /foo/bar/foo/bar

If ** is greedy the output name is /foo/bar.

If ** is lazy the output name is /bar/foo/bar

Arguments for Greedy

Name matching with wild cards is similar to regular expression matching.
In perl syntax the quantifiers *, +, ? are greedy by default.
Since so many regular expression libraries have been based off this syntax, a user might expect ** to be greedy too.

Arguments for lazy

A lazy operator can reduce the amount of backtracking an implementation has to do while matching.
If given rule /**/foo/bar/baz:=... and name /foo/bar/baz a greedy ** would backtrack after every token, while a lazy ** would result in no backtracking at all.

Proposal

** should be greedy by default. In most cases remapping will only happen at startup, so the performance does not matter.

If the performance of backtracking becomes an issue then the syntax could be amended to allow changing the greediness. Perl does this with ? where * is greedy while *? is lazy. Ex: ** could be greedy while **? is lazy.

Intra-Process Communications for all language clients

Description

This issue is a call for a design of zero-copy intra-process communications available to all ROS2 language clients.

The current implementation of this feature exists in rclcpp and therefore is not usable for Python (or less-supported languages C, Java, Rust, etc.)

Acceptance Criteria

To close this issue, we want a design document that proposes the architecture for

• Intra-process optimized communications
• zero copy
• Available to all ROS2 language clients (therefore exists at or below the level of rcl)

As a follow up, will attempt to collect existing thoughts from #239 and add as comments below.

Note

I do not consider myself personally an expert on this, however I'm very interested in collaborating towards a top down view of what this part of the ROS2 core should look like, and figuring out how the community can pull together towards a solution

Design proposal for diagnostics support in ros 2

Is there any proposal for how to support diagnostics inside ROS 2.0 ?

.NET Core for ROS2

Please evaluate .NET Core (open source) for ROS2: https://dotnet.github.io

Using .NET Core for ROS will have some great advantages, including:

• It is standards based
• It is cross-platform and can target each platform natively
• Makes async programming really easy which is very important in robotics development. You basically write asynchronous code the same way you write readable synchronous code and the compiler will take care of the plumbing for you.
• Supports C# and VB now and potentially adds many more languages later, including Phyton and Ruby. That would eliminate the need to create individual adapters to support each language.
• There is a forgotten Microsoft Robotics Studio community out there that will love this.

I think it would be strategically wise decision to use .NET Core or at least have a first class support for it in ROS vNext.

The approaches taken for .NET Core are very different than the proprietary Microsoft .NET product that you knew before. Please don't let your past experiences with MS discourage you about it.

Thanks!

top left nav link to homepage links too deep

It links to: http://ros2.github.io/ not http://ros2.github.io/design/

Partitions, topics, and ROS namespacing

I've been reading up on the topic and service mapping article, having seen that the partition PR landed back in March: https://github.com/ros2/design/blob/gh-pages/articles/140_topic_and_service_name_mapping.md

I wanted to feel out how "locked in" this design decision is, as we are building a product on top of RTI DDS with the hopes of running full blown ROS 2.0 once it gets out of beta. To that end, we are trying to make sure that we make decisions around partitioning and topic names that are forward thinking and in line with what you are doing. The concepts settled upon seem very sound to me and I can't find any red flags or deal breakers.

Any expectations of there being major changes to this part of the architecture beyond this point?

fix login by using new GitHub methods

GitHub deprecated the use of access_token for queries, which this site was using, see:

https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters

We were getting emails like this:

Hello there!

On February 7th, 2020 at 08:56 (UTC) your application (ROS2 Design Website) used an access token (with the User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0) as part of a query parameter to access an endpoint through the GitHub API.

https://api.github.com/repositories/14241623/pulls/269/files

Please use the Authorization HTTP header instead as using the `access_token` query parameter is deprecated.

Depending on your API usage, we'll be sending you this email reminder once every 3 days for each token and User-Agent used in API calls made on your behalf.
Just one URL that was accessed with a token and User-Agent combination will be listed in the email reminder, not all.

Visit https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters for more information.

Thanks,
The GitHub Team

I opened #270 to disable login, until we have time to implement a new login mechanism.

Compile error on Windows

Hi,

I need to get a Intel RealSense App talking to the rest of my ROS compoenents which run on Linux. Therefore, I was trying to compile Ros2 on Windows 8.1 with VS 2015 and Python 3.5 installed. I am stuck at the compilation "python src\ament\ament_tools\scripts\ament.py build" with 2 similare error as follows

9>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppComm
on.targets(170,5): error MSB6006: "cmd.exe" exited with code 1. [C:\dev
ros2\build\builtin_interfaces\builtin_interfaces__cpp.vcxproj]
9>Done Building Project "C:\dev\ros2\build\builtin_interfaces\builtin_inte
rfaces__cpp.vcxproj" (default targets) -- FAILED.
5>Done Building Project "C:\dev\ros2\build\builtin_interfaces\builtin_inte
rfaces__cpp.vcxproj.metaproj" (default targets) -- FAILED.
10>CustomBuild:
Traceback (most recent call last):
File "C:/dev/ros2/install/lib/rosidl_generator_c/rosidl_generator_c"
, line 45, in
sys.exit(main())
File "C:/dev/ros2/install/lib/rosidl_generator_c/rosidl_generator_c"
, line 40, in main
args.template_dir,
File "C:\dev\ros2\install\Lib\site-packages\rosidl_generator_c__ini
t__.py", line 50, in generate_c
interpreter = em.Interpreter(
AttributeError: module 'em' has no attribute 'Interpreter'
10>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppComm
on.targets(170,5): error MSB6006: "cmd.exe" exited with code 1. [C:\dev
ros2\build\builtin_interfaces\builtin_interfaces__c.vcxproj]

The EmPy modules exists and the doc show that Interpreter class exists.

Any help would be much appreciated.

Regards,

Suraj

Forward slash in DDS topic name in example

The Examples and Ideas for Communicating with Non-ROS Topics section in Topic and Service name mapping to DDS article presents an example where a DDS topic name containing a forward slash is discussed.

Although the article discusses an ambiguous specification of an "exact" topic name, I have the impresion that one of the two interpretations should not be legal in DDS. Specifically I'm referring to the mapping from rostopic+exact://camera_left/image to DDS topic camera_left/image and partition [].

Just bringing it up since it can lead to confusion. It probably makes little sense to combine rostopic+exact with a name containing forward slashes, right?

Multirobot support

Not sure if this is the best place to ask.
Has there been any design discussions on how to support multi-robot systems in ROS2?

I see that this topic is on the ros2 roadmap. We are at the point where this is an important feature for us and we would like to partition our systems such that individual robot topics are not discoverable across the system.

[C++ message initialization] ZEROS option clarification

Clarify C++ message initialization, in particular how ZEROS currently performs and what the expected behavior (not yet implemented) will be.

See ros2/rosidl#251 for more details

white paper: Method based Message API with Configurable Backend Storage

Summarize and then support with research the arguments for and against using method based accessors for the message API and for and against having configurable backend storage for the message API. Then prototype elements of the proposed design trade-offs where appropriate.

The method based interface is the alternative to a C-style member accessor method, but it is not mutually exclusive with this style of accessing attributes for messages.

Capture at least these cases and compare performance:

• member access
  • Provides direct member access to a plain struct backend storage
• mutable method access
  • Provides mutable references to a plain struct backend storage with methods
• immutable method access
  • Provides copies of attributes of a plain struct backend storage with methods
• mutable method access with configurable backend
  • Provides mutable references to a configurable backend storage with methods
  • Would exclude serializers which do not give mutable access to storage, e.g. protobuf.
• immutable method access with configurable backend
  • Provides copies of attributes of a configurable backend storage with methods

Another dimension to investigate is the cost of having the default backend storage configurable at run time versus compile time.

Add article about migration strategy

Per suggestions from discussion on the sig-ng-ros mailing list, create an article describing the ROS 1->ROS 2 migration strategy. Topics include renaming, build system changes, using the bridge, etc.

Changes between ROS 1 and ROS 2 design doc is out of date

I was going to share the Changes between ROS 1 and ROS 2 design doc to a few colleagues, as it's very condensed overview and conveniently links out to more detailed documentation as needed.

https://github.com/ros2/design/blob/gh-pages/articles/changes.md

However, after re-reading it recently, it seems like there are a number of outdated entries, many of which are marked with ⏳, such as:

• Actions
• roslaunch
• Topic namespaces (?)
• remapping

This would be a low hanging fruit ticket if anyone else has the time to write an informed update.

Define how actions will be transmitted across the ROS 1 bridge

In #193 there is no description of how actions would be transmitted across the ROS 1 bridge. This section should be written and included in the design document.

Some content was written, but then deleted after feedback found a lot of issues.

Deleted content for `Bridging between ROS 1 and ROS 2`

## Bridging between ROS 1 and ROS 2

### Detecting Action Servers and Clients

There will be an API for the bridge to get a list of all ROS 2 action servers and clients.

ROS 1 action servers and clients can be discovered by looking for topic ending in `/status` with message type `actionlib_msgs/GoalStatusArray`.
If a publisher exists then an action server exists.
If a subscriber exists then a client exists.

### Bridging ROS 1 Action Client and ROS 2 Action Server

If either a ROS 2 action server or a ROS 1 action client exists then the ROS 1 bridge will create the following:

1. a ROS 1 action server
2. a ROS 2 action client

#### Goal submission

When the ROS 1 action client submits a goal the bridge will check if a ROS 2 action server exists.
If no server exists then the goal is rejected, otherwise the bridge calls the ROS 2 goal submission service.
If the ROS 2 server accepts the goal then the bridge will call `setAccepted` on the ROS 1 bridge, otherwise it will call `setRejected`.

When a goal is accepted the bridge stores a map between the ROS 1 and ROS 2 goal IDs.
If a client submits a goal with the same ID then it will be rejected until the first goal is finished.

#### Goal Cancellation

When a ROS 1 client tries to cancel a goal the bridge must try to cancel it on the ROS 2 server.
First the bridge must look up the mapping of ROS 1 to ROS 2 goal IDs.
If a mapping exists then the bridge will call the cancellation service.

If the mapping does not exist because the server has not yet accepted or rejected the goal then the bridge will wait until the goal is accepted.
If it is rejected the bridge will call setRejected and ignore the cancellation request.
If it is accepted then it will call the cancellation service.

#### Feedback

The bridge will only publish feedback messages for goals that were sent through it.
Since the goal ID is generated by the server, the bridge can only know the mapping of ROS 1 to ROS 2 goal IDs if the bridge sent the goal.

#### Result

Once a goal has been accepted the bridge will wait for the result.
When it gets the result the bridge will call

If the bridge notices the ROS 2 action server disappears from the node graph then bridge will wait for the result indefinitely.
When the bridge reappears the bridge will try to get the result from the goal again.
If the ROS 2 server does not know of the goal, then the bridge will notify the ROS 1 client that the goal was canceled.

### Bridging ROS 1 Action Server and ROS 2 Action Client

If either a ROS 1 action server or a ROS 2 action client exist then the bridge will create:

1. a ROS 1 action client
2. a ROS 2 action server

#### Goal submission

When the ROS 2 action client submits a goal the bridge will check if a ROS 1 action server exists.
If it does not exist the bridge will reject the goal, otherwise it will submit the goal to the ROS 1 server.
The same goal ID is to be used for both ROS 1 and ROS 2.

Goals sent to the bridge from ROS 2 are always immediately accepted by the bridge.
The bridge will then submit the goal to the ROS 1 server.
The reason for instantly accepting the goal is that if the ROS 1 action server never responds to a goal request then the bridge cannot return a result.
Goals that are rejected by ROS 1 action servers will be reported as canceled to ROS 2 action clients.

#### Goal Cancellation

When a ROS 2 client tries to cancel a goal the bridge will immediately accept the cancellation request.
It will then try to cancel the request on the ROS 1 action server.
If the cancellation request is rejected by the ROS 1 server then the ROS 2 bridge will stay in the *CANCELING* state until the result of the goal is known.

#### Feedback

Since the goal ID is the same for both ROS 1 and ROS 2, the bridge will always publish feedback from ROS 1 servers to the ROS 2 feedback topic.

#### Result

When the ROS 1 action server publishes a result it will be set as the result on the ROS 1 bridge.
If the ROS 2 action client never calls the service to get the result then it is subject to the same timeout as if it were a normal ROS 2 action server.

One issue is it has the bridge always accepting goals from ROS 2 action clients before contacting the ROS 1 action server, but that hides what's happening on the ROS 1 action server from ROS 2 introspection tools. Another issue is it "detects" a ROS 1 action server or client using only a single topic, but servers or clients aren't actually functional until all topics are in use. Yet another issue is it always creates an action server if there is an action client on one side, which makes it seem like there is an action server available when there isn't.

Since the section was written goal ids where changed back to being generated by the client, so there may not be a reason to prevent feedback from ROS 2 goals being transmitted to ROS 2.

feature request: Introspection into "nodelet-like" intra-process communication.

Nodelets are mentioned in the DDL design page, and it was mentioned that a similar shared-pointer-like interface would be provided. I just wanted to mention the desire to have introspection into such intra-process communication. Currently with nodelets, there's no way to discern which topics are connected between which nodelet in a single nodelet manager, and as such, debugging can be frustrating and slow.

The previous discussion here ended with "let's get back to this when we're talking about ROS2" so I figured it was time to bring this back up: https://code.ros.org/trac/ros/ticket/3360 (cached)

rendering of C code samples

I'm not sure if this is just my browser, but the triple-backtick on this page (e.g., the "Memory Management" section) seems to not quite render the following C code correctly. Maybe it needs a triple-tilde instead? I don't know. (the content is awesome, btw... this is just about its rendering)

add design document for node name uniqueness

Currently many design documents and features implicitly rely on node names being unique, but we have never sorted out the issues with how to enforce node name uniqueness in a distributed system and therefore we've never officially declared that node names need to be unique. We need a design document that states node names need to be unique (or not) with rationale why and if unique then how to enforce it and if not unique how to deal with existing features that assume and rely on unique node names.

clarify policy on nesting substitutions in topic names doc

See: #97 (comment)

Write parameters design document

Create a design document for the parameter system.

Application trying to access public and private repos

Just thought I'd raise this issue if continuing with this style in the future. When clicking the 'login with Github' from the main design page it is requesting permission to access public and private repos. Probably don't want it to access people's private repos.

Modify authorization
ROS2 Design Website by @ros2 would like to modify its permission to access your account
 Added permissions
Repositories
Public and private
This application will be able to read and write all public and private repo data. This includes the following:

Code
Issues
Pull requests
Wikis
Settings
Webhooks and services
Deploy keys

namespace remapping isn't apply to node name ,Whether or not meet the design criteria

terminal input:
ros2 run demo_nodes_cpp talker __ns:=/tt __node:=JJ
expect:
node name: /tt/JJ
topic : /tt/chatter
test result:
node name JJ
topic : /tt/chatter

Temporarily update the CPP article to say that message field initialization is not done

In http://design.ros2.org/articles/generated_interfaces_cpp.html , the "Constructors" section says that all message fields in the generated C++ code are initialized to zero by default. While we do want this to be the case, and we have code to make this the case (ros2/ros2#396), that code is not going to make Beta3. Therefore, we should update the CPP article to represent the current state of the code and say that we are working towards making all of the fields initialized by default.

Support keyed instances for liveliness and deadline QoS

The current design for deadline and liveliness QoS settings do not support differentiating keyed instances of Topics. As a result, you are not able to determine which instance has violated the QoS policy if your subscription encompasses multiple instances. Supporting this would be useful for cases like when you have multiple robots publishing to a single topic but using a different instance identifier, such as a serial number for the robot. If one of your robots starts failing to publish data to the topic then you could get notified of the liveliness or deadline violation, but you wouldn't be able to tell which of them had caused it.

In order to support this use case, changes would be needed to the callback structure in order to include information about the key identifier for the instance that has violated the policy. This value would need to be optional based on if the message type used for the topic specifies a key or not. How this key is represented may also depend on how ROS 2 decides to represent instanced subscription for topics. It will probably require some code generated for a message in order to cast the key data to the proper type. The C++ api may be able to leverage templates to do this automatically for the user, but rclpy will need a way to do this for the C message types as well.

Middleware alternatives to DDS

Can you survey the alternatives that you considered to DDS?

Security | Event Logging for Auditing

This issue serves to track ideas for specifying the security event logging to be used in SROS2. Ideally this specification should be extensive enough to enable security monitoring and auditing frameworks. In particular this will be critical for auto generation of policies, or learning security profiles by demonstration. In anticipation that ROS2 will enable larger and more elaborate computation graphs; auditing and constructing complete policies manually for such networks at scale will not only be tedious for users and thus inhibit security adoption, but would be error prone as well due to the evolved human factors. Given that ROS2 is also decentralized, there is no longer an opportunity to monitor events from a central arbiter, as first approached in SROS1. This necessitates that SROS2 should define security logging mechanisms, either through dedicated topic channels or local disk storage, to provide the foundation enabling higher level automated security tooling.

Additionally, it would be advantageous if the standard translated easily to logging structured used by other secure middleware transports (i.e., DDS Secure's builtin plugins), but is not necessarily too ingrained to inhibit being a common format among transports vinders. Much of this issue may be also contingent upon the design decisions for application logging for in ROS2 in general.

Some ideal qualities for such a format may also include:

• human readable
  • format should be clear and concise
  • otherwise may prove difficult to audit or debug
• machine parsable
  • consumable for metafile auto generation
  • importing and exporting should preserve original structure
• expressive power
  • suitable for defining all SROS2 security exchanges
  • capable of extension for future security transport plugins

Additional, there are some aspects of the standard we may wish to decide on as well:

• file format
  • what file format encoding should be used (e.g., ASCII, Binary, other)
• logging level
  • supported logging levels and what would the denonte (e.g., ERROR, WARNING, DEBUG, etc.)
• templating
  • what template format should be followed for reliable parsing (e.g., CLF, syslog, ROS1, other)

[Parameters] document the yaml format used for parameters

Follow-up of ros2/rcl#235

This could either be done once the parser is fully implemented or done anytime before to reflect the current state and extend the design document when the parser evolves

Add support for fully qualified names in message defnitions

In the Foxy Message API Review it came up that it might make sense to add support for Fully Qualified Names in the msg format so that subfields could be referenced like they are now supported for command line tools with `<package_name>/msg/

It's not entirely clear if this is worth doing as only currently messages can be embedded in other messages. Services and Actions don't make sense in that context so the syntax is not ambiguous so adding the more verbosity might not be worth it, but it will reflect the namespaces better.

Write a design document about composite nodes in the component life cycle

This was cut from the component life cycle discussion in #34

Ticketing separately re: this comment

write a design document on how to support pause/resume semantics

This was brought up in the component life cycle discussion in #34 but deferred here

Improvements to rmw for deterministic execution

Background

In Casini et al, 2019, it is shown that execution of callbacks can happen in a different order than messages coming in. See this We also have an example for proof. This is usually not what is expected, and it happens only by accident, too.

Goal

We want to execute messages in importance order, which -- in the absence of other priorities -- is usually message arrival order.

Problem

To execute in message-arrival order, the executor needs ordering information. This is currently not possible in the rmw API, because the rmw_wait_set only has binary information: Either data is available on a topic or not. We don't know how old it is. Moreover, a topic may have more than one message waiting, where some or all may be older than a message for a different topic. These other messages will currently be skipped until the next invocation of rmw_wait.

Options

I see two general approaches to address this:

1. We ask the middleware for timestamps on all waiting messages and perform ordering on the executor level.
2. We ask the middleware "which object(s), of the ones in the wait_set, should we handle next?" where "next" is typically decided by "has the oldest data".

Q: Can anybody think of different options?

Discussion

Option 1) keeps the current rmw design, but adds more data. This appears more straightforward at first, but since there may be multiple messages waiting for each object, the data size is unpredictable. Also, it is not trivial to obtain this information from the middleware. The naive implementation has to deserialize all messages to get the SampleInfo. Alternatively, we could keep a listener attached at all times, and use it to determine arrival time. Or, we could modify the middleware to maintain this information for us without having to deserialize.

Option 2) either changes rmw_wait, or adds a new function with these new semantics. This will likely require more modifications in the rmw-implementations, but it would likely provide better options for the rmw-implementations to optimize obtaining this information. It would also limit the data-size, and could even make use of QoS information on the middleware layer.

Security | Access Control Policy Format

This issue serves to track ideas for specifying the policy format to be used for access control in SROS2. Ideally this specification should be extensible enough to convey all necessary permissions or access rights, say in a traditional access control matrix where the rows are subjects/users (i.e., nodes), the columns are objects/resources (i.e., topics, services, parameters). Additionally, it would be advantageous if the format translated easily to metafiles used by other secure middleware transports (i.e., DDS Secure's builtin plugins), but is not necessarily too confirmative to inhibit being a common format among transports vinders.

Some ideal qualities for such a format may also include:

• human readable
  • format should be clear and concise
  • otherwise may prove difficult to audit or debug
• machine parsable
  • consumable for metafile auto generation
  • importing and exporting should preserve original structure
• expressive power
  • suitable for defining all fundamental SROS2 governance
  • capable of extension for future security transport plugins

Additional, there are some aspects of the standard we may wish to decide on as well:

• file format
  • what text based structure should be used (e.g., JSON, XML, YAML, custom)
• regular expressions
  • how should alias or globbing be permitted (e.g., POSIX, Regex, AppArmor, other)
• templating
  • should the format support any arbitrary tempting (e.g., via empy, jinja)

finish EBNF for topic and service names

See: #90 (comment)

Remapping | differentiate *:=... from /*:=...

The remapping design doc states that /namespace/ is only prefixed to the match side of a rule if it does not begin with *, **, or /. This means the rules *:=foo and /*:=foo are the same.

If code uses a relative name bar and is put into namespace /ns then the rule bar:=foo will match while *:=foo does not. However, if code uses a fully qualified name /bar then both /bar:=foo and /*:=foo match. I think this difference in behavior when there is a leading / could be confusing.

Proposal

Change the behavior to say /namespace/ is prefixed to the match side when a rule begins with *, **, or a token.

Fix ROS 2 threat model style errors

See #228

@thomas-moulard This document doesn't follow the style guide for markdown (https://index.ros.org/doc/ros2/Contributing/Developer-Guide/#markdown-restructured-text-docblocks). Please update the doc to follow the one-sentence-per-line rule. See https://github.com/ros2/design/pull/236/files#diff-60aa2b3022e7728b236f31c650141eceL3544 for a case why the current state is not desired.

Create a "generated C interfaces" design doc

Now that C and C++ interface types diverged we should create a design doc defining how each IDL (msg) type is mapped to C. It should also be added to the summary type mapping table on the wiki

namespaces

were nested or deep namespaces for messages considered? For example myproject::navigation::pose, or myproject::mobility::WaypointCmd ?

Write ament design document

AC:

• Whitepaper describing build tool design
  • appendix describing changes from catkin

Consider Feedback from Vincent

From Vincent's French Robotics Conference:

Here you go:
- good stuff: docs/tutorials, easy to use/install, good for education
- bad: catkin (need was understood but the main complaint was that it is harder to teach student), lack of multicast, lack of pluggable message transport, contribution to the core were hard/rejected (a pluggable ros_comm was submitted to Dirk but that was a year ago, during the Willow/catki/GitHub move crisis),
- fear of perennity: if I switch to ROS now, will it work in a few years ?
- how does the industry react ? (Mentioned a few companies, ros industrial)
- good: .msg files are well defined and can be reused in other frameworks (e.g. Genom3 http://homepages.laas.fr/mallet/soft/architecture/genom3)
- bad: actionlib is clunky (not sure exactly why) so they reimplemented their own
- Python ROS comm is slower and not robust to packet loss.
- good: relatively plug and play. A student can get started in a few days. Many drivers
- bad: a lot of stuff on the wiki that needs to be deprecated removed
- no high level decision framework (smash but good basically) but that was just to show that it was not A solution to high level robotics. Just something complementary
- need of clarity/ roadmap to see how contributions can happen

So basically the usual :)