Really excited to see Rerun get fleshed out as time goes on. I've used it at $WORK in spare time to visualize multi-agent telemetry and event information for remote operated robotic systems.
To me the most useful feature was actually just the timeline view. Being able to see all of the events and telemetry updates from all agents and correlate them to some line plots was already a huge help. I think Rerun should actually make the timeline view just another "view" [0] so that I can have additional timeline views with specific filters. Seeing the discrete pips in the timeline for different events and channel updates is really helpful.
Also we already have infrastructure to log and for live telemetry streaming so we don't integrate with the SDK directly in the deployed software and instead just have an adaptation layer to take logs or live data and push it through the Rerun SDK. I generally feel it's better to separate the data generation and logging from the data visualization, though I could understand directly integrating the SDK as a fast solution if the infrastructure is not already there. I hope the use case as the data offload/logging for a system doesn't become a focus sink for the Rerun team.
That said, I do appreciate the simplicity of the Rerun SDK API design. At first I wanted to try Foxglove but it seems pretty tied to the supported formats (which we weren't outputting for heritage reasons) and my eyes glazed over when I saw how much work (I perceived) it would take to integrate with their custom websocket interface. This was all spare time exploration so I basically dropped it once I saw how much code there was in the example [1].
Thanks for sharing and that makes me really happy to hear. Keeping Rerun simple to use and easy to get started with has been a goal of ours from the beginning.
> I think Rerun should actually make the timeline view just another "view"
This is something we've talked about on and off internally and mostly all agree it's the right thing to do at some point. I also think there is a lot of things we could do to increase the usefulness of the timeline view even further so glad you're getting alot out of it already.
> Also we already have infrastructure to log and for live telemetry streaming so we don't integrate with the SDK directly in the deployed software and instead just have an adaptation layer to take logs or live data and push it through the Rerun SDK.
This is actually quite a common case and we don't have the ambition to make the Rerun SDK be the perfect logging library for all usecases. We're trying to do more instead to make it easier write efficient adapters that run elsewhere in your infra for cases where using the logging SDK isn't the best fit. The recent `rr.send_columns` API is in that direction but there will be more in the future
To me the most useful feature was actually just the timeline view. Being able to see all of the events and telemetry updates from all agents and correlate them to some line plots was already a huge help. I think Rerun should actually make the timeline view just another "view" [0] so that I can have additional timeline views with specific filters. Seeing the discrete pips in the timeline for different events and channel updates is really helpful.
Also we already have infrastructure to log and for live telemetry streaming so we don't integrate with the SDK directly in the deployed software and instead just have an adaptation layer to take logs or live data and push it through the Rerun SDK. I generally feel it's better to separate the data generation and logging from the data visualization, though I could understand directly integrating the SDK as a fast solution if the infrastructure is not already there. I hope the use case as the data offload/logging for a system doesn't become a focus sink for the Rerun team.
That said, I do appreciate the simplicity of the Rerun SDK API design. At first I wanted to try Foxglove but it seems pretty tied to the supported formats (which we weren't outputting for heritage reasons) and my eyes glazed over when I saw how much work (I perceived) it would take to integrate with their custom websocket interface. This was all spare time exploration so I basically dropped it once I saw how much code there was in the example [1].
[0]: https://rerun.io/docs/reference/types/views
[1]: https://github.com/foxglove/ws-protocol/tree/main/python/src...