Add smoothing to Meshat realtime rate display

[jwnimmer-tri]

Is your feature request related to a problem? Please describe.

In #16981 we added a nice realtime rate ("RTR") chart to Meshcat. A simulation (or really anything with a sense of time) can post its timing information into Meshcat, and then the information is sent to the display to show in a nice animated chart.

However, the chart is often pretty difficult to read. For example when a Simulator has many systems inside, with different update rates, the computational cost will be larger at the "beats" where the updates are nearby, and seem to speed by quickly when no updates are happening. This is especially acute with very slow computations, e.g., simulated camera rendering. The chart also shows a "NN%" text readout, which flickers wildly with the beats, nearly impossible to read even the first sig fig.

Describe the solution you'd like

Somehow the information in the chart should be smoothed, so that it's easier to eyeball -- both in chart form and the "NN%" form.

Roughly the time constant we want to smooth across is on the order of 10 Hz. Most periodic systems in our simulations go at least as fast as 5 Hz, more typically 10 Hz, 16 Hz, 32 Hz, etc. We don't want smoothing 0.1 Hz -- that would not respond quickly enough. Consider for example when the robot grabs something, we want the user to see (somewhat quickly) how the RTR changes when the grasp moves from open to closed. Let's say with 0.25seconds the chart should reflect the new timing.

I don't know if we want a sliding window filter, or exponention, or whatever. We might need to experiment.

Describe alternatives you've considered

Have the caller do the smoothing, and pass the updates to Meshcat less frequently. This seems like it would be worse, because we would have multiple callers to fix.

Additional context

There is a TODO here: https://github.com/RobotLocomotion/drake/blob/ce2d4ae9bb82e953ac66c1f67dbe2356b6f4c2a2/geometry/meshcat.h#L554

[jwnimmer-tri]

From a quick code skim, it's also possible that by default we have three MeshcatVisualizer objects they are all fighting about the rate. We should be sure that when using AddDefaultVisualization, there's only 1 place that controls the rate display.

[SeanCurtis-TRI]

Quick design proposal after initially poking around:

Current API

We have the Meshcat::SetRealtimeRate() API. A user with access to Meshcat instance invokes it, passing its pre-computed rate value. Meshcat then packages it up into a websocket message that is caught and processed by some javascript in Drake's meshcat.html. The page's javascrpt writes the message value to a local value and continues updating the chart based on the cached value indefinitely. This means, when it is no longer connected to the server, the last reported rate fills up the chart.

Design constraints

1. We're talking about averaging rates, so simply taking a bunch of rate values and averaging them would be highly inappropriate. To average them, we'd have to be able to weigh them (the wall-clock time would serve as the weight).
2. Any piece of code with access to a Meshcat instance can redundantly call SetRealtimeRate(). Even if it provides appropriate weight values, multiple systems in a diagram could end up reporting the same rate at the same simulation time step. This would implicitly increase the weight for the rate value with duplicates.
3. We know that the wall clock time of a simulation step can vary widely (even if we're calling SetRealtimeRate() is called with uniform steps in simulation time).

Proposal

Replace SetRealtimeRate() with an alternate API, something like NoteTimeAdvancement(double time) (or some such thing), with the following semantics:

• If multiple invocations are made with the same time value, the duplicates are ignored.
• Invocation may lead to a realtime rate websocket message being dispatched.
  • MeshcatParams gets a new parameter indicating the realtime rate period (minimum time between realtime rate updates).
  • Actual realtime rate messages may take longer (e.g., if the time between NoteTimeAdvancement() calls is longer than the configured period such as when computation gets really bogged down).
• The first invocation will never produce a message.
  • The user should call NoteTimeAdvancement(0); during initialization or some such thing.
• The second invocation will always produce a message. (I.e., after initialization, a simulation that takes a single step -- calling NoteTimeAdvancement() -- and then stops will produce an RTR message for visualization).

As implemented, the function would do something of the following:

• It would save a pair consisting of the (non-duplicated) noted sim time and a corresponding wall time.
• It would accumulate the pair in some aggregator.
• If enough time has elapsed since the last message, the aggregator's current value will be dispatched in a message and the timer gets reset.

The aggregator would be akin to a moving average, except:

• The window is configured w.r.t. a wall clock time window.
• The window consists of (sim time, wall time) pairs.
• When a new pair is added, any previously queued time that is farther away from the new time than the configured time window is dropped (until there are two entries left).
• When a rate value is requested, it doesn't perform a weighted average, it simply computes the differences in sim time and wall time between the first and last entries and returns their ratio.

I'm currently favoring a simpler implementation that is more tailored to Meshcat's use:

• It is not configured with a wall clock time window.
• It stores two times, old and new.
• A time pair (sim, wall) passed to the aggregator always updates the new time (unless old hasn't been initialized yet, then both).
• Asking for the value computes the rate and moves the new time to the old time.
• It's not a sliding window so much as coarse sampling of the reported times frequency.
• Generally, we assume that the period for NoteTimeAdvancement() invocations is smaller than the period at which we broadcast realtime rate.