some suggestions wrt timeseries logging

[tlpss]

I've been using rerun for logging timeseries whilst debugging and tuning a controller on a robot manipulator and I really like it so far. There are a few things I would love to see that would make it even better:

• being able to dynamically select which time series are displayed in a single panel instead of having to declare this upfront.

• saving hyperparameters/configuration parameters in the rerun log for later reference
  (these two are inspired on wat weights and biases/tensorboard/... offers for visualising time series during ML training)

• being able to see at what rate message are being logged for each 'topic' (cf what rqt has in ros)

I'm not sure if these fit into the use cases you have in mind with rerun of course, and I am very eager to experiment with logging images and pointclouds once my controller is finished as this is probably where rerun really shines, but I just wanted to make sure that these features are not yet available and give some feedback on my experiences so far.

Thanks for the efforts! This tool has the potential to save lots of time 👍

[nikolausWest]

Hey @tlpss! Thanks for this writeup and feedback, really appreciated! Also, apologies for the super slow response. We haven't gotten into a good triaging workflow yet, will fix that right away.

Regarding your suggestions, they all fit pretty square into our plans, even in the same order you wrote here. We're going to open the repository up to the public on February 15th and have a lot of cleanup to do before then so we most likely won't be able to address them until after that though.

being able to dynamically select which time series are displayed in a single panel instead of having to declare this upfront.

This use case is very much part of the core idea of our data model and design. We may not get there for the general case in the next two weeks but you can work around it for now by logging everything you want to be able to put in the same plot under the same root path ("root/sub1/series1", "root/sub1/series2" , "root/sub2/series1" etc). Then you can manually build your plots in the UI instead (this will get much easier / cleaner with #994.

saving hyperparameters/configuration parameters in the rerun log for later reference

Been missing this alot too and definitely see the need.

being able to see at what rate message are being logged for each 'topic' (cf what rqt has in ros)

Could you expand a bit here on what you are trying to achieve here?

[tlpss]

@nikolausWest

Hey @tlpss! Thanks for this writeup and feedback, really appreciated! Also, apologies for the super slow response. We haven't gotten into a good triaging workflow yet, will fix that right away.

no worries!

Glad to here that you are already working on my suggestions!

Could you expand a bit here on what you are trying to achieve here?

The basic idea for me is to get an effortless estimation of the rate at which something is running. Say you log an image every time you get a new one from the camera, it is nice to quickly see if the rate at which this happens approximately matches what you intented. Same goes for logging timeseries in a controller for a robot arm.
These will of course be estimates (the timestamp associated with the data is not exactly the time of publishing I guess) but if something logs at 15fps where you expect it to run at60fps, that would still be a sign to have a more thorough look.

And since you already have a timestamp associated to all data, I thought this would be a convenient addon.

We're going to open the repository up to the public on February 15th

Looking forward to this (and to binary releases)

[nikolausWest]

Looking forward to this (and to binary releases)

We'll actually have binary releases on every merge to master once #996 is merged. Would love help testing it out!

being able to see at what rate message are being logged for each 'topic' (cf what rqt has in ros)

I opened an issue for this one: #1052

[nikolausWest]

Closing now since I think we've captured everything