Propose ROS 2 launch front-end design hints. by hidmic · Pull Request #208 · ros2/design

hidmic · 2019-02-06T19:51:25Z

This is a proposal on how to go about implementing something like #207 in an extensible way. Approaches described in here are a combination of ideas I had and ideas that @wjwwood had and shared with me, thus the dual authorship.

I hope that by the time this gets merged we either have chosen one of these approaches or came up with a another one to actually implement.

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

wjwwood

Looks like a good start to me.

As for which implementation to use, the one I mostly closely identified with was FDM+, though perhaps this document is just not compelling enough. We might need to discuss off-line to hash out more detail.

Also, a big thing that is missing (but possibly orthogonal to these approaches) is substitutions and how they would be handled.

articles/160_roslaunch_frontend.md

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

hidmic · 2019-02-13T17:21:54Z

Also, a big thing that is missing (but possibly orthogonal to these approaches) is substitutions and how they would be handled.

And I think that's exactly why I skipped them in the first place. The document now covers a bit on how substitutions could be handled. PTAL! And thanks for reviewing it in the first place!

wjwwood · 2019-06-27T14:59:54Z

articles/160_roslaunch_frontend.md

+
+### Forward Description Mapping (FDM)
+
+In FDM, the parser relies on a schema and well-known rules to map an static description (markup) to implementation specific instances (objects).


Suggested change

In FDM, the parser relies on a schema and well-known rules to map an static description (markup) to implementation specific instances (objects).

In FDM, the parser relies on a schema and well-known rules to map a static description (markup) to implementation specific instances (objects).

wjwwood · 2019-06-27T15:05:25Z

articles/160_roslaunch_frontend.md

+
+*+* Straightforward to implement.
+
+*+* Launch implementations are completely unaware of the static description existence and its parsing process (to the extent that type agnostic instantiation mechanisms are available).


Suggested change

*+* Launch implementations are completely unaware of the static description existence and its parsing process (to the extent that type agnostic instantiation mechanisms are available).

*+* Launch implementations are completely unaware of the existence of the static description formats and their parsing processes (to the extent that type agnostic instantiation mechanisms are available).

jacobperron · 2019-07-01T20:32:55Z

articles/160_roslaunch_frontend.md

+
+*-* Launch system implementations are aware of the parsing process, being completely involved with it if sugars are to be provided.
+
+*+* Allows leveraging the strenghts of each markup language.


Suggested change

*+* Allows leveraging the strenghts of each markup language.

*+* Allows leveraging the strengths of each markup language.

jacobperron · 2019-07-01T20:33:34Z

articles/160_roslaunch_frontend.md

+
+*+* Allows leveraging the strenghts of each markup language.
+
+*-* Opens the door to big differences in the representation of launch entities across different front end, and even within a given one by allowing the users to introduce multiple custom representations for the same concepts (e.g. a list of numbers).


Suggested change

*-* Opens the door to big differences in the representation of launch entities across different front end, and even within a given one by allowing the users to introduce multiple custom representations for the same concepts (e.g. a list of numbers).

*-* Opens the door to big differences in the representation of launch entities across different front ends, and even within a given one by allowing the users to introduce multiple custom representations for the same concept (e.g. a list of numbers).

Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com>

ivanpauno · 2019-07-11T18:59:05Z

@hidmic I addressed the comments, and updated it to match better with the actual implementation (it was actually matching pretty well).

hidmic · 2019-07-12T14:19:39Z

articles/160_roslaunch_frontend.md


-*-* No markup language specific sugars are possible.
-    REVISIT(hidmic): IMHO explicitly disallowing this is a good thing, it makes for more homogeneus descriptions and avoids proliferation of multiple representation of the same concepts (e.g. a list of strings).
-


@ivanpauno this still applies.

hidmic · 2019-07-12T14:20:28Z

articles/160_roslaunch_frontend.md

 *Python*
 ```python
-@launch.expose('some-action')  # Infers it's an Action
+@launch.frontend.expose_action('some-action')  # Infers it's an Action


@ivanpauno I think we should remove # Infers it's an Action.

hidmic · 2019-07-12T14:20:49Z

articles/160_roslaunch_frontend.md

        )

-@launch.expose('some-subst')  # Infers it's a Substitution
+@launch.frontend.expose_substitution('some-subst')  # Infers it's a Substitution


@ivanpauno I think we should remove # Infers it's a Substitution.

Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com>

ivanpauno · 2019-07-12T19:52:21Z

I think this PR is ready. We will deal with event_handlers in the next iteration, but I didn't delete reference to them as this is a design hints document.

* wip * more work in progress * more work done on the calling conventions section * added context section, still a WIP * updated event sections * event filters * fixup even handler subsection * typos * add subsections about the system description (language agnostic) * Proposal for launching dynamically composable nodes (#206) * Proposal for dynamically composed nodes * allow multiple extra_arguments * Allow node_name and namespace to be empty * Human readable error message * Update articles/150_roslaunch.md Co-Authored-By: sloretz <shane.loretz@gmail.com> * Assign nodes unique ids, but still forbid duplicates * Update articles/150_roslaunch.md Co-Authored-By: sloretz <shane.loretz@gmail.com> * Update articles/150_roslaunch.md Co-Authored-By: sloretz <shane.loretz@gmail.com> * Section to list * More generic wording about container processes * namespace -> node_namespace * _launch/ -> ~/_container/ Signed-off-by: Shane Loretz <sloretz@osrfoundation.org> * Propose ROS 2 launch front-end design hints. (#208) Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com> Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com> * Adds ROS 2 launch XML format design document (#207) Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com> Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com> * Update ROS launch documentation (frontend documents) (#247) Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com> * review fixup Signed-off-by: William Woodall <william@osrfoundation.org> * clarify lifecycle transition due to review comment Signed-off-by: William Woodall <william@osrfoundation.org> * provide rationale for shutdown procedure Signed-off-by: William Woodall <william@osrfoundation.org> * Add launch XML substitution for a packages share directory (#254) * Add launch XML substitution for a packages share directory Rename find-pkg to find-pkg-prefix. Add find-pkg-share substitution for the share directory. Signed-off-by: Jacob Perron <jacob@openrobotics.org> * remove some old rfc's and general cleanup for first merge Signed-off-by: William Woodall <william@osrfoundation.org>

Propose ROS 2 launch front-end design hints.

a805a3d

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

hidmic requested review from mjcarroll, sloretz and wjwwood February 6, 2019 19:51

tfoote added the in progress Actively being worked on (Kanban column) label Feb 6, 2019

hidmic added in review Waiting for review (Kanban column) and removed in progress Actively being worked on (Kanban column) labels Feb 6, 2019

cottsay assigned hidmic Feb 7, 2019

Correct ROS 2 launch frontend document style.

0347a5d

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

wjwwood reviewed Feb 13, 2019

View reviewed changes

articles/160_roslaunch_frontend.md Outdated Show resolved Hide resolved

articles/160_roslaunch_frontend.md Outdated Show resolved Hide resolved

articles/160_roslaunch_frontend.md Outdated Show resolved Hide resolved

articles/160_roslaunch_frontend.md Outdated Show resolved Hide resolved

Extend ROS 2 launch frontend document to cover substitutions.

bf503dd

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

hidmic mentioned this pull request Feb 18, 2019

XML/YAML Front-end ros2/launch#163

Closed

ivanpauno mentioned this pull request Apr 15, 2019

Add frontend module in launch, launch_xml and launch_yaml packages ros2/launch#226

Merged

wjwwood reviewed Jun 27, 2019

View reviewed changes

jacobperron reviewed Jul 1, 2019

View reviewed changes

ivanpauno added 2 commits July 11, 2019 15:16

Address review comments

0c0e73c

Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com>

Update, to match better with the actual implementation

1d721c9

Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com>

hidmic commented Jul 12, 2019

View reviewed changes

Address review comments

039726c

Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com>

ivanpauno requested review from jacobperron and wjwwood July 12, 2019 19:52

wjwwood approved these changes Jul 12, 2019

View reviewed changes

jacobperron approved these changes Jul 12, 2019

View reviewed changes

ivanpauno merged commit cc9b399 into roslaunch Jul 15, 2019

delete-merged-branch bot deleted the hidmic/roslaunch-frontends branch July 15, 2019 15:24

wjwwood mentioned this pull request Jul 23, 2019

ROS 2 Eloquent Elusor ros2/ros2#734

Closed

34 tasks


		### Forward Description Mapping (FDM)

		In FDM, the parser relies on a schema and well-known rules to map an static description (markup) to implementation specific instances (objects).


		+ Straightforward to implement.

		+ Launch implementations are completely unaware of the static description existence and its parsing process (to the extent that type agnostic instantiation mechanisms are available).


		- Launch system implementations are aware of the parsing process, being completely involved with it if sugars are to be provided.

		+ Allows leveraging the strenghts of each markup language.

	+ Allows leveraging the strenghts of each markup language.
	+ Allows leveraging the strengths of each markup language.


		+ Allows leveraging the strenghts of each markup language.

		- Opens the door to big differences in the representation of launch entities across different front end, and even within a given one by allowing the users to introduce multiple custom representations for the same concepts (e.g. a list of numbers).


		- No markup language specific sugars are possible.
		REVISIT(hidmic): IMHO explicitly disallowing this is a good thing, it makes for more homogeneus descriptions and avoids proliferation of multiple representation of the same concepts (e.g. a list of strings).

Conversation

hidmic commented Feb 6, 2019

Uh oh!

wjwwood left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hidmic commented Feb 13, 2019

Uh oh!

wjwwood Jun 27, 2019

Choose a reason for hiding this comment

Uh oh!

wjwwood Jun 27, 2019

Choose a reason for hiding this comment

Uh oh!

jacobperron Jul 1, 2019

Choose a reason for hiding this comment

Uh oh!

jacobperron Jul 1, 2019

Choose a reason for hiding this comment

Uh oh!

ivanpauno commented Jul 11, 2019

Uh oh!

hidmic Jul 12, 2019

Choose a reason for hiding this comment

Uh oh!

hidmic Jul 12, 2019

Choose a reason for hiding this comment

Uh oh!

hidmic Jul 12, 2019

Choose a reason for hiding this comment

Uh oh!

ivanpauno commented Jul 12, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants