Fetch remote resources (at runtime, with caching)

[RussTedrake]

It would be nice to be able to have a method analogous to FindResourceOrThrow() that supports remote resources (e.g. grabbing sdf files from some hosted url in order to add new objects into a multibody simulation), and throw them in a local cache for future queries to make things efficient.

In yet another conversation w/ @jwnimmer-tri , he suggested that there are probably good tools out there that would accomplish this. Opening this issue to track the idea.

[RussTedrake]

My dev branch has a solution from @jwnimmer-tri that was partially working: https://github.com/RussTedrake/drake/tree/lab1

but it raised more complex questions about when these resources were available --- do they get installed, etc.

Will definitely want a solution to this going forward, but was able to get around it for the immediate need.

[RussTedrake]

@EricCousineau-TRI -- fyi, this is related to the ycb object discussion. please connect to (or even close) this issue if/when you make progress?

[EricCousineau-TRI]

Sounds good! This dovetails into the install story for #6124; for now, will keep this as-is, but establish the issue connection.

[jwnimmer-tri]

@RussTedrake any new reflections on this use case? For my part, I guess if I'm working with simulation assets, I always want it under source control anyway, so I end up committing it somewhere into git, even if its only a personal git repo. Is there a use case for directly fetching https URLs from, say, drake::multibody::Parser?

[EricCousineau-TRI]

FTR I agree with Jeremy. We can be creative on how we fetch from Git / Bazel (e.g. a simplified version of bazel_external_data). Runtime resource downloads sounds scary in terms of simple reproducibility.

[RussTedrake]

In my mind, I would like to reduce the overhead of pulling assets from e.g.:
https://bitbucket.org/osrf/gazebo_models
Or shapenet, or ai habitat, etc.

Having gone through the steps of putting a single model in RobotLocomotion/models, I can say that there is significant friction in that approach.

I appreciate the complexity... examples in drake might have to worry about licenses (especially if we install/redistribute) in addition to versions. But what if I’m writing the example in my external repo (like underactuated or manipulation)? Do we just say that each repo should provide their own functionality, or do we provide some support through the drake library for fetching those resources?

[jwnimmer-tri]

My sense is that the typical way to handle those things is in the build system and package paths, not through runtime fetching from simulation code. Perhaps we should ship (or document existing) CMake or Bazel or ROS-ish macros that pull external models into the workspace.

[RussTedrake]

Yes, that sounds very reasonable to me. I think the "runtime" thinking that found it's way in the title was perhaps inspired by the machine learning workflows (e.g. https://pytorch.org/tutorials/beginner/blitz/cifar10_tutorial.html#loading-and-normalizing-cifar10 ). I do think making it easy to bring in diverse resources can be a game changer.

[RussTedrake]

possibly relevant:

[RussTedrake]

@jwnimmer-tri -- i believe you've been working on this. Might you want to take ownership of the issue?

[jwnimmer-tri]

I have been thinking about it a bit, and in any case I'm happy to take it into my list.

The related ticket that I'm actually more actively working on is #15774 -- solving the distribution and fetch problem for Drake's model files (only), rather than a fully-general solution.

[jwnimmer-tri]

As it turns out, I did need to solve this as a step towards #15574.

For the WIP see PackageMap::AddRemotePackage from this branch. It's about 3 or 4 more PRs until it lands as a public API feature.

[jwnimmer-tri]

A few thoughts from f2f chat today:

• Consider adding an environment variable to turn off all of Drake's internet features. (The package map, render RPC, etc.) This might be useful for debugging, and for any teams that need to firewall Drake.
  • Environment variable to disable internet (or networking entirely) #19044
• Make it clear / easy (at minimum -- documented) how to preload the cache, especially when baking a container image. Something like batch simulation in the cloud should have models baked into the image, not repeatedly being fetched on every boot.

[jwnimmer-tri]

Make it clear / easy (at minimum -- documented) how to preload the cache, especially when baking a container image. Something like batch simulation in the cloud should have models baked into the image, not repeatedly being fetched on every boot.

Here's how we do it currently:

drake/tools/install/dockerhub/jammy/Dockerfile

Lines 14 to 16 in 03b2e61

	# Bake model data into the image up-front, instead of fetching on demand.
	&& PYTHONPATH=/opt/drake/lib/python3.10/site-packages python3 -c \
	'from pydrake.all import PackageMap; PackageMap().GetPath("drake_models")' \

If we find that that line is too complicated for users, we could imagine adding sugar for it like python3 -m pydrake._prefetch but for the moment I'll presume that it's sufficient already.

[jwnimmer-tri]

The only remaining question here is about tutorials and/or examples.

At the moment, we have only the PackageMap.AddRemote documentation.

We could imagine writing a tutorial that used AddRemote, but I think it's likely that we need more than just fetching to succeed. See #15024 for the wider discussion. So I'm going to conclude that this ticket is finished, and we'll use #15024 to track the end-to-end user story.