Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update remapping order of __ns and __node to not affect each other #299

Closed
wants to merge 5 commits into from
Closed

Update remapping order of __ns and __node to not affect each other #299

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
873ada9
Update with nodename prefix to support FQN and remapping order
Sep 22, 2020
93a1b51
update namespace and node name remapping to not affect each other
Oct 19, 2020
520d649
make the example description more clear
Oct 20, 2020
31ca246
update with better wording
Oct 21, 2020
33770a1
Add an example for mixed rules
Oct 24, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions articles/141_static_remapping.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -255,6 +255,7 @@ Example rules are:
- `foo:=bar`
- `/foo/bar:=fiz/buzz`
- `nodename:~/foo:=foo`
- `/ns1/nodename:foo:=bar`
- `**/foo:=\1/bar`

#### Match Part of a Rule
Expand All @@ -265,7 +266,7 @@ The match part of a rule uses these operators:
- `**` matches zero or more tokens delimited by slashes
- `rosservice://` prefixed to the match makes the rule apply to only services
- `rostopic://` prefixed to the match makes the rule apply to only topics
- `nodename:` prefixed to the match makes it apply only to a node with that name
- `nodename:` prefixed to the match makes it apply only to a node with that name, which could be a FQN

The operators `*` and `**` are similar to the globbing behavior in bash.
`**` behaves similar to its use in bash>=4.0 with the globstar option set.
Expand Down Expand Up @@ -324,8 +325,8 @@ The replacement must be a single token which will become the node's new name.

Remapping rules are applied in the following order:

1. Node name remapping
1. Namespace remapping
1. Node name remapping
ivanpauno marked this conversation as resolved.
Show resolved Hide resolved
1. All other rules

Within each category, the rules are applied in the order in which the user gave them.
Expand All @@ -339,8 +340,8 @@ Within each category, the rules are applied in the order in which the user gave
**Example of node/namespace remapping order:**

- A node has name `talker`
- A user gives the rules `talker:__ns:=/my_namespace` then `talker:__node:=foo`
- The final namespace is the default `/` because the node name remap is applied before the namespace remap
- A user gives the rules `talker:__ns:=/my_namespace` then `/talker:__node:=foo`
- The final node name is the default `talker` because the namespace remap is applied before the node name remap
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if user wants to remap talker into namespace A and B? I believe this is really common use case. I am not so convinced to change order. I think Node name -> Namespace would be understandable and usable for user.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your response. @fujitatomoya

what if user wants to remap talker into namespace A and B?

Sorry, I don't catch it. How can we remap one node talker into two different namespaces A and B?

Node name -> Namespace would be understandable

It has a limitation.
Imageing there are two nodes publisher_node and subscriber_node in an application.
/publisher_node
/subscriber_node

I want to remap these two nodes as following (ros2/rcl#806),
/publisher_node -----> '/ns1/aaa'
/subscriber_node -----> '/ns2/aaa'

Copy link
Contributor Author

@iuhilnehc-ynos iuhilnehc-ynos Sep 23, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this case is suited for the real world.
/left_camera -----> /left/camera
/right_camera -----> /right/camera

It seems we can not remap them with current remapping order.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can we remap one node talker into two different namespaces A and B?

bad example, ignore it... sorry😢

It seems we can not remap them with current remapping order.
/left_camera -----> /left/camera
/right_camera -----> /right/camera

I don't see this is because of remapping order, but implementation. I think we should have some kinda justification to change order to support two nodes with the same name but in different namespaces.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this is because of remapping order, but implementation.

That's right, users can set two nodes with Node("camera", "/left") and Node("camera", "/right") in implementation.
but we can't ask users to do this, if somebody just wants to use remapping, there is a limitation.

some kinda justification

Actually, the sample about the 'camera' above is the reason why I open this issue.

I found no discussion about why ros2 use this kind of remapping order(node name -> namespace), after checking ros2/rcl#217 and #181, it seems that ros2 follow the same implementation order to ros1. (If I remember correctly, ros1 doesn't have the remapping order for __name and __ns because it just use one node in an application. )


**Example of a default and node specific namespace remap:**

Expand Down