make common drake visualizer scripts available always?

[RussTedrake]

As it stands right now, only the most advanced users can figure out how to launch drake_visualizer with the magical invocation to see what we typically see. Is there any harm of promoting

cmd "0.drake_visualizer" {
    exec = "${DRAKE_WORKSPACE}/bazel-bin/tools/drake_visualizer \
        --script ${DRAKE_WORKSPACE}/multibody/rigid_body_plant/visualization/contact_viz.py \
        --script ${DRAKE_WORKSPACE}/multibody/rigid_body_plant/visualization/show_time.py \
        --script ${DRAKE_WORKSPACE}/multibody/rigid_body_plant/visualization/show_frames.py";
    host = "localhost";
}

so that it happens always? (should be a simple addition to drake_visualizer.py?)

@jwnimmer-tri ? @EricCousineau-TRI ? @sammy-tri ?

[EricCousineau-TRI]

I have soft preference to still make these modules / this functionality opt-in, rather than always-on. However, the way that we do that can change.

In Anzu, we expose all of the general functionality via ${PYTHONPATH}, so that any script can import them. We still refer to script paths, but we could potentially get to a point to where each application has its own initialization script in the same directory as the PMD, so that the launch would look like:

cmd "0.drake_visualizer" {
    exec = "${DRAKE_WORKSPACE}/bazel-bin/tools/drake_visualizer \
        --script ./drake_viz_custom_app.py";
    host = "localhost";
}

The contents of the script could be something like:

from drake.multibody.rigid_body_plant.visualization import contact_viz
from drake.multibody.rigid_body_plant.visualization import show_time
from drake.multibody.rigid_body_plant.visualization import show_frames

for m in [contact_viz, show_time, show_frames]:
    m.init()

That way you maintain explicit-ness, but there's less copy-pasta at the command-lin level.

[jwnimmer-tri]

I agree that these scripts should be easier to use out of the box. I think loading them by default within //tools:drake_visualizer is fine. There are already menu items the user can click to turn them on or off. When they are loaded but disabled, I don't think they induce any ill effects, either on performance, or by adding dependencies, etc.

I think the only question is whether they are on or off by default -- or perhaps if there should be a command-line option available for a user to set their default (without having to click in the menus every time they launch). I don't think I have a strong preference there. I guess if I had to vote I'd say show_time on by default, the other two off by default.

[RussTedrake]

The contact arrows will do nothing unless someone is actively publishing contact results. I would argue that if someone is publishing it, then it should be shown by default (eg on by default at the visualizer side).

[RussTedrake]

Also just became aware/reminded of

-script systems/sensors/visualization/show_images.py

Searching suggests that these four are all of the relevant in-tree scripts.