Provide preliminary ROS1 and/or ROS2 support w/ catkin and/or ament, document recommended workflow

[RussTedrake]

Many people are using drake+ROS. We just need to clean up our recommendations / examples.
Related to #8711 .

---

Eric's edits:

Design (Google Doc): Drake Issue 9500 - ROS1 Support

See task tracking comment below: #9500 (comment)

[jamiesnape]

It is certainly something @EricCousineau-TRI and I have talked about. We would be happy to take it on, set up CI, and clean it up if you want to move it to RobotLocomotion.

[EricCousineau-TRI]

Per prior discussions, will assign myself to this.

[EricCousineau-TRI]

Updated title, starting to record use cases.

[jwnimmer-tri]

Maybe the brief list above is just meant to be placeholders for now, but to clearly communicate our intention for what should be possible, the use cases need to be written up as more than just ~10-word noun phrases. They should have verbs, or some narrative around which pieces are being assembled and how and to what end, or some pseudo-code, or etc. They should be some falsifiable milestone of "as a python user, I can do X and Y and Z and then see A and B and C happen", so that we can say with certainty whether we have met the use case.

[EricCousineau-TRI]

Posted a very rough design doc for this:
https://docs.google.com/document/d/1OyGQb7mxHenGgVTZQcrBnpp1a4igECbuxI7dc1squSY (will replace top-level issue summary with this)

Notes on the doc:

• Hosted on my personal account so that it can be shared publicly.
• The sections are probably not named succinctly, but it's a start.
• I've not decided to put a timeline on anything in the doc until we have an initial round of comments.
• The pre-RFC version has been tagged as Pre-RFC 20180103.

I'd like to make an information Request for Comments on the following bits:

• @RussTedrake, @tri-ltyyu - High-level goals, missing users (@stonier too if you have a chance!)
• @jwnimmer-tri - Use case description
• @jamiesnape - Proposed workflows for CMake, both Monorepo and Polyrepo approaches
• @calderpg-tri - Code examples for RViz
• @SeanCurtis-TRI - gut check on SceneGraph usage for RViz

If/when you have a chance to review it, please make brief comments via Google Drive on the bits that you feel are deficient, missing, or can be improved.
If you feel like you need to explain more, we can meet individually f2f or via GChat.
If there is general confusion at the high-level, we can coordinate a wider meeting.

I'll be placing this project on the back burner until Jan. 9 / 10, so no rush.

(For ROS2, I'll open up a separate issue.)

EDIT: Changed doc to be publicly viewable, but require explicit invitations to comment / suggest.

[EricCousineau-TRI]

Task Tracking Comment:

• Finalize motivation statement (Feb. 8) - determine if this will best serve external or internal (Anzu) users
• Do first pass on package map paving within Drake (Feb. 15)
• Add next step (Feb. 18)

[EricCousineau-TRI]

Late update: I'm testing out ROS2 on Anzu; will change the scope of this.

[tehbelinda]

@EricCousineau-TRI Potentially we'll also have HSR users for this, we've been talking to Akiyoshi about a collaboration - do you have any new updates/thoughts on how we could do this?

[RussTedrake]

+1 from me. A number of underactuated students have been asking about drake vs(?) ros -- and why not... since there is essentially no mention of it on our website. I recommend we provide at least a minimal mention / recommendation asap, even if more extensive documentation will take some time.

[EricCousineau-TRI]

If it's for ROS1, the approach would be the same as listed in the above doc; just would need a meaningful priority assigned, with a responsible internal interested party for pushing it forward - this wouldn't be me at the moment, as I'm more interested in testing out ROS2 for Anzu's usages. (Not a fan of ROS1's runtime and buildtime overhead.)

If it's for ROS2, we have started talking some about this support, but it probably would not start up until September of this year. (Not a fan of buildtime overhead, but more a fan of the runtime, just need to do some internal vetting.)

[...] A number of underactuated students have been asking about drake vs(?) ros -- and why not... since there is essentially no mention of it on our website. [...]

I could make a simple PR stating that we don't have TRI-supported ROS integration at the moment, and refer to other stuff (like Greg's stuff in Spartan), and mention that we've strived to make things runtime compatible.
Would that suffice in terms of a mention?

[huihuaTRI]

Thanks, Sherm!

The current HSR stack uses ROS1. For a proof of concept demo, it's ok to use the ways listed in the documentation. On the other hand, the HSR users are thinking to move to ROS2 also. It's likely that they will make the decision by the end of March 2020. Supporting ROS2 in the future does seem like a more appealing approach for me.

The question I originally had is whether Drake will officially support ROS1 or ROS2. My understanding now is 1) Drake could support ROS1, but need someone to push it forward. Most likely need to start with more clear design documentation. 2) ROS2 will be first experimented in Anzu. A decision will be made later (last quarter of 2020) whether it will be in Drake.

[EricCousineau-TRI]

[...] Most likely need to start with more clear design documentation [...]

Just to check, does this doc help serve as a starting point?
https://docs.google.com/document/d/1OyGQb7mxHenGgVTZQcrBnpp1a4igECbuxI7dc1squSY/edit

If so, do you think you could add in some mentions for the HSR user-workflows for ROS1? (It is still useful, even if we go the ROS2 route.)

This issue (to me) seems to have conflicting comments about whether ROS 1 is going to ever be supported, and the issue name is not (even) mentioning ROS 2.

Sort of, but it ties in via ditching ROS1 in lieu of ROS2 wholesale.

Also mentions to Anzu are not going to offer a huge amount of help to someone wondering about possibilities of ROS 2 support (or wanting to contribute such).

I don't agree. To support either ROS1 or ROS2, it'd be best to have buy-in from a group here (at TRI).

[huihuaTRI]

The link you posted would work, which is also the plan for now.

I was trying to gather the correct narrative about the status of ROS1 or ROS2 support. I have enough information for now. After the HSR users make the decision about which ROS version to use, we may come back to this topic and decide the route.

[EricCousineau-TRI]

Aye, sounds good! It would still be good to know their present workflow for ROS1 (e.g. adding an entry in the "Known Users" section), if you have a chance to add that in.

[huihuaTRI]

I am the "HSR users" for now actually, surprise! I will send you documentation about what I am working on.

[jamiesnape]

Sort of, but it ties in via ditching ROS1 in lieu of ROS2 wholesale.

The issue is titles "Provide preliminary ROS1 support". The opposite of ditch.

I don't agree. To support either ROS1 or ROS2, it'd be best to have buy-in from a group here (at TRI).

Only mentions of Anzu, I should have said. I am sure you need buy in at TRI, but a summary here would be helpful for the rest of the world.

[jamiesnape]

Regardless, it would be nice to have an example of compiling/using drake (the library) with Catkin (it is just a simple wrapper project), say in drake-external-examples, to help answer #12773.

[EricCousineau-TRI]

Regardless, it would be nice to have an example of compiling/using drake (the library) with Catkin [...]

Per f2f, created: RobotLocomotion/drake-external-examples#163

[EricCousineau-TRI]

@mntan3 I've created a very simple, and hacky support for Rviz visualization with ROS1 Melodic + Python 3:
https://github.com/EricCousineau-TRI/repro/tree/master/ros/drake_ros1_hacks (branch), permalink

Please try it out when you have a chance and let me know if you have any questions.

It will ultimately need some more features (to be incorporated into #13160) to be more "feature complete" ish.

\cc @IanTheEngineer @sloretz @RussTedrake @calderpg-tri

[EricCousineau-TRI]

Updating to bring ROS 2 explicitly into scope.
Will be updating design doc to decide on path forward for polishing and publishing @sloretz's awesome work for library consumption.

[RussTedrake]

I think having a prominent link from the drake website for ROS users would be a good criteria for completion on this. I (still) get questions all the time, and don't have a single place to point people.

[IanTheEngineer]

That's a great point, Russ. I'll capture the website ROS link as completion criteria in the 9500 google doc, and seek input from others from where it should point. My hope is that it could be the new drake-ros repository, which should be a resource for both light API's and example / tutorials.

[jwnimmer-tri]

Just to get in on record -- there is an unsupported, work-in-progress "develop" branch for Drake-ROS integration here:

https://github.com/RobotLocomotion/drake-ros/tree/develop

[EricCousineau-TRI]

As assignee, I'd say that inclusion of drake-ros in Drake website (#17941), its usage in Anzu for dog-fooding, and merge to main (RobotLocomotion/drake-ros#136), we can close this issue

Woot! 🎊

(came across this while searching for other issue)