add a note instructing readers to grab the textbook repo …

Hey -TRI -- yes, later we will probably add something like this to something on the added $PYTHONPATH:

python
def findUnderactuatedResource(filename):
   return os.path.join(os.path.dirname(__file__), filename)

And then semantics could be:

python
from pydrake.all import *
from planar_rigid_body_visualizer import PlanarRigidBodyVisualizer

# Load the double pendulum from Universal Robot Description Format
tree = RigidBodyTree(findUnderactuatedResource("double_pendulum.urdf"), FloatingBaseType.kFixed)

But we decided to just have all code run in underactuated/src for now. Thanks!

I like something like that. Nice that it builds off of -tri and 's suggestions

Please don't recommend from foo import * to users. It's widely considered a bad habit in Python and it will cause bugs that can otherwise be avoided entirely (including the entire behavior of your program changing based on the order of your import statements).

PEP 8 (the Python style guide) says:

Wildcard imports (from import *) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools.

Hup, forgot to update the Drake docs in that regard. Will do that now.

Do you have a list of modules that you'd like review for for this upcoming week? (if it's not too late to hotfix some changes, that is) I can review them by later tonight.

Great. Looking into how to best do this for class workflow now ( heads up so don't do double work)

This works. (When the underactuated repo is cloned in the docker right below the mount point.)

python
from pydrake.all import *
import sys
sys.path.append("./underactuated/src")
from planar_rigid_body_visualizer import PlanarRigidBodyVisualizer

# Load the double pendulum from Universal Robot Description Format
tree = RigidBodyTree("./underactuated/src/double_pendulum.urdf", FloatingBaseType.kFixed)

We could choose to "hide" more of this if we'd like. For example we can definitely edit PYTHONPATH before opening the notebook and get rid of the sys.path.append. I actually haven't been able yet to get rid of specifying the full (relative) path for the double_pendulum.urdf but I'm sure there's a slicker way.

What do you guys think

i don't think that's any better. it now assumes that you are running it from the directory directly above underactuated, instead of inside underactuated/src.
The better solution would use FindResource('double_pendulum.urdf') if we want to go there.

Hi Russ, okay, looks like current implementation for FindResource demands that the path start with "drake/*", so another option could be:

1. clone underactuated into drake/ (the docker image can ship with this)
2. semantics would then be:

python
from pydrake.all import *
from planar_rigid_body_visualizer import PlanarRigidBodyVisualizer

# Load the double pendulum from Universal Robot Description Format
double_pendulum_urdf = FindResourceOrThrow("drake/underactuated/src/double_pendulum.urdf")
tree = RigidBodyTree(double_pendulum_urdf, FloatingBaseType.kFixed)

(I also got rid of the sys calls, since we can add to PYTHONPATH prior to opening notebook)

What do you think?

Edit: tested and can't find even with underactuated cloned into drake/... getting:

RuntimeError: could not find resource: drake/underactuated/src/double_pendulum.urdf

-TRI would appreciate pointer on what I am missing in setup?

Update: have a workable solution (not most clean though)

If we clone underactuated into this location (and docker container can ship like this):

/drake/share/drake

Then this code runs:

python
from pydrake.all import *
from planar_rigid_body_visualizer import PlanarRigidBodyVisualizer

# Load the double pendulum from Universal Robot Description Format
double_pendulum_urdf = FindResourceOrThrow("drake/underactuated/src/double_pendulum.urdf")
tree = RigidBodyTree(double_pendulum_urdf, FloatingBaseType.kFixed)

Looking over FindResource implementation in drake/common/find_resource.cc, I'm not sure what option could be better without changing find_resource.cc

But -TRI what do you think!

I can’t understand why it would force the resource to start with drake/.

+-TRI. I know there have been many discussions about findresource. Can you help explain or point to the existing explanation?

drake::FindResource(OrThrow) is only intended to find Drake resources; it is not intended for other projects to use to find their own resources.

For underactuated, if all code and models are in the same folder, a simpler solution might work?

python
double_pendulum_urdf = os.path.join(os.path.dirname(__file__), "double_pendulum.urdf")`

(Alternative, though I think jeremy's would work OK too, though it's not too pretty: set up underactuated as a ROS package and use PackageMap to find it. Same interface would be able to extend to anything that's a ROS package, including Drake's manipulation models and example models.)

Right. The ROS package path is a good answer when you want an infrastructure. It's widely used and supported (to greater or lesser extents) by Drake, Director, etc.

Thanks all for putting out different ideas!

The thing is that if all code and models are in the same folder, then even just this works:

python
double_pendulum_urdf = "double_pendulum.urdf"

I think Russ's hope was to not require all code and models in same folder.

Personally I would vote the solution of cloning underactuated into /drake/share/drake above a ROS package since this is just for simple examples for class rather than setting up a proper robot infrastructure.

Following up from the other email thread, can I ask what the drawback would be to require that underactuated be added to the PYTHONPATH before running this code?

Since the students already need to do this for drake, it seems like it might be a simple next step?

The ROS package path definitely sounds nice, but it'd be most convenient if you had a function that returned an already-constructed PackageMap instance. The easiest thing would be to have a helper function, and it'd be easiest to have that helper function be in the underactuated model - which at that point, you should already have it in the PYTHONPATH, and could use other path resolution methods (such as underactuated.FindResource).

Personally I would vote the solution of cloning underactuated into /drake/share/drake above...

Would this mean that they should put this code in /opt? It seems like it'd be a tad odd to require root access (or change permissions under /opt/...) to facilitate ease of finding resources. My preference would be to use PYTHONPATH and delegate to helpers, or think of an easy and compact way to construct a PackageMap.

Hey -TRI PYTHONPATH is solved easily yes by adding underactuated

The issue is finding the pesky .urdf :) or other non python files. PYTHONPATH doesn’t help there. And FindResource it seems has been decided to be only for drake internals.

I wouldn’t worry too much about it though. It’s just a question of how to specify paths to urdfs. I think we should just have people specify relative (or full!) paths to the underactuated repo for the urdfs

The issue is finding the pesky .urdf :) or other non python files. PYTHONPATH doesn’t help there. And FindResource it seems has been decided to be only for drake internals.

Yup, you could address that by having a helper function (discoverable since it's on the PYTHONPATH) which can figure out where the resources lay, using the module paths (since __file__ will work in this case). If you want to keep it simple, it could keep to locating underactuated resources. If you want to add some layers of indirection, you could have it also find Drake resources.