0

I'm trying to visualize collisions and different events visually, and am searching for the best way to update color or visual element properties after registration with RegisterVisualGeometry.

I've found the GeometryInstance class, which seems like a promising point for changing mutable illustration properties, but have yet to find and example where an instance is called from the plant (from a GeometryId from something like GetVisualGeometriesForBody?) and its properties are changed.

As a basic example, I want to change the color of a box's visual geometry when two seconds have passed. I register the geometry pre-finalize with

// box         : Body added to plant
// X_WA        : Identity transform
// FLAGS_box_l : box side length
geometry::GeometryId box_visual_id = plant.RegisterVisualGeometry(
        box, X_WA,
        geometry::Box(FLAGS_box_l, FLAGS_box_l, FLAGS_box_l),
        "BoxVisualGeometry",
        Eigen::Vector4d(0.7, 0.5, 0, 1));

Then, I have a while loop to create a timed event at two seconds where I would like for the box to change it's color.

double current_time = 0.0;
const double time_delta = 0.008;
bool changed(false);

while( current_time < FLAGS_duration ){

    if (current_time > 2.0 && !changed) {
        std::cout << "Change color for id " << box_visual_id.get_value() << "\n";
        // Change color of box using its GeometryId
        changed = true;
    }
    simulator.StepTo(current_time + time_delta);
    current_time = simulator_context.get_time();
}

Eventually I'd like to call something like this with a more specific trigger like proximity to another object, or velocity, but for now I'm not sure how I would register a simple visual geometry change.

  • Can you elaborate on the lifespan of your geometries? When are the registered? At that time what roles are assigned, and what happens between then and when you want to change properties, and, finally, what are the nature of the changes? The answer will strongly depend on those details ranging from (oops...you can't yet to, just tweak your workflow this way and you're gold.) – Sean Curtis Jul 17 '19 at 22:06
  • Hi Sean, I've edited the question with a basic example. – Joaquin Giraldo-Laguna Jul 18 '19 at 14:09
  • For now changing color is fine, and would like to show it only temporarily (like briefly when in proximity to another body) I understand that visual geometries must be registered pre-finalize, and am looking to change geometries during simulation post-finalize. – Joaquin Giraldo-Laguna Jul 18 '19 at 14:15

1 Answers1

1

Thanks for the details. This is sufficient for me to provide a meaningful answer of the current state of affairs as well as the future (both near- and far-term plans).

Taking your question as a representative example, changing a visual geometry's color can mean one of two things:

  1. The color of the object changes in an "attached" visualizer (drake_visualizer being the prime example).
  2. The color of the object changes in a simulated rgb camera (what is currently dev::RgbdCamera, but imminently RgbdSensor).

Depending on what other properties you might want to change mid simulation, there might be additional subtleties/nuances. But using the springboard above, here are the details:

  • A. Up until recently (drake PR 11796), changing properties after registration wasn't possible at all.
  • B. PR 11796 was the first step in enabling that. However, it only enables it for changing ProximityProperties. (ProximityProperties are associated with the role geometry plays in proximity queries -- contact, signed distance, etc.)
  • C. Changing PerceptionProperties is a TODO in that PR and will follow in the next few months (single digit unless a more pressing need arises to bump it up in priority). (PerceptionProperties are associated with the properties geometry has in simulated sensors -- how they appear, etc.)
  • D. Changing IllustrationProperties is not supported and it is not clear what the best/right way to do so may be. (IllustrationProperties are what get fed to an external visualizer like drake_visualizer.) This is the trickiest, due to the way the LCM communication is currently articulated.

So, when we compare possible implications of changing an object's color (1 or 2, above) with the state of the art and near-term art (C & D, above), we draw the following conclusions:

  • In the near future, you should be able to change it in a synthesized RGB image.
  • No real plan for changing it in an external visualizer.

(Sorry, it seems the answer is more along the lines of "oops...you can't do that".)

Sean Curtis
  • 1,425
  • 7
  • 8