English | 简体中文
by @corenel (Yusu Pan) and OpenAI Deep Research
- Rerun and Foxglove: Emerging Data Visualization Platforms for Robotics
The demand for data visualization in robotics, autonomous driving, and digital twin fields has existed for a long time. From early simple logs and 2D charts to today's complex multi-sensor fusion, the development of visualization tools has accompanied the progress of the entire industry. Around 2007, Willow Garage released the Robot Operating System ROS, which included the classic 3D visualization tool RViz. RViz could display robot sensor data, status, and environment in real-time under the ROS ecosystem, including camera images, LiDAR point clouds, robotic arm joint states, etc. At that time, RViz greatly reduced the barrier to robot debugging and became an early standard visualization tool in the robotics field. Many beginners and R&D personnel used it to intuitively understand the world perceived by robots.
With the improvement of sensor accuracy and quantity, especially in the field of autonomous driving, the scale and complexity of data generated by robots have grown rapidly. Traditional RViz gradually exposed its limitations: for example, the lack of direct playback of long-duration logs, requiring external tools such as rosbag to play recorded data; limited functionality can only be extended through plugins, and plugin development requires C++ compilation, which has a high barrier. Faced with the surge in multi-modal data and team collaboration needs, the industry began to explore new solutions. Around 2018, Cruise, an autonomous driving company, developed Webviz, a browser-based ROS data visualization tool that supports directly loading ROS bag files and playing them back, and layouts (3D views, curves, image displays, etc.) can be customized through web pages. The emergence of Webviz marked the move of autonomous driving data visualization towards cloud and front-end technologies: developers only need to open a browser, drag and drop their ROS log files to obtain visual insights.
On the other hand, the concept of Digital Twin has emerged in the industrial and robotics fields. Digital twins require the real reproduction of the physical world in a virtual environment for simulation, testing, and monitoring. This has promoted the application of graphics technologies such as game engines in industry—"The real experts in virtual environments come from the gaming industry, such as Unity." Commercial engines like Unity, with their high-fidelity 3D rendering and physics simulation capabilities, are increasingly used in robot simulation and digital twin scenarios. For example, researchers can build city street scenes in Unity to simulate sensor inputs from autonomous vehicles, thereby training and validating algorithms in a digital twin environment.
Entering the 2020s, as robotics and autonomous driving technologies entered the stage of large-scale development, a new generation of open-source visualization tools began to emerge to meet the needs of multi-modality, big data, and team collaboration. Two of the most watched projects are Rerun and Foxglove. Foxglove was born in 2021, founded by the original team of Cruise Webviz. It inherited the concept of Webviz and quickly expanded its functions, aiming to provide a one-stop "observability" platform for robot development. Rerun was founded around 2022 by three entrepreneurs (including a CTO with a gaming industry background, focusing on building efficient tools), aiming to create a general-purpose multi-modal data logging and visualization tool for robotics and computer vision. These two new tools and traditional RViz and Unity have their own focuses, forming a new landscape in the field of robotics/autonomous driving visualization today.
Rerun is an open-source multi-modal data logging and visualization tool whose mission is to make powerful visualization debugging capabilities free and easily accessible. Rerun was co-founded by Niko (Nikolaus West), Emil Ernerfeldt, and Moritz; among them, Emil is the author of egui, a Rust immediate mode GUI engine, which makes Rerun very focused on performance and developer experience from the beginning. The core of Rerun consists of two parts: one is a simple and flexible logging SDK that supports embedding in languages such as C++, Python, and Rust; the other is a high-speed and embeddable data visualization viewer. Developers can use the SDK to record various data streams, including 2D/3D data, text, time series, tensors, etc. Rerun adopts a time-aware Entity-Component System (ECS) as its data model. Each recorded piece of data is organized as an entity and its attribute components, with a timeline for efficient representation of common time-series data in robotics. Around this model, the Rerun team developed a custom database query engine and rendering engine from scratch to ensure smooth and efficient interaction when processing complex robot data.
The usage process of Rerun is very suitable for robotics and computer vision development. Developers only need a few lines of code to initialize Rerun logging, embed it into existing projects, and send perception data streams to the Rerun viewer when the program is running. For example, camera images, LiDAR point clouds, object detection boxes, robot poses, control commands, etc. can be recorded every frame. The Rerun viewer supports local real-time streaming display, and can also load recorded files offline for "time-travel" style playback analysis. It is worth mentioning that Rerun's data logging does not require pre-defining strict message formats (schema) - developers can quickly put any debugging information into the logs, thereby reducing the initial barrier to use and making it very flexible in the debugging and experimentation phase. This is different from the traditional practice in the ROS ecosystem where message types must be defined before data can be published. The SDK provided by Rerun automatically converts common data into built-in component types (such as 3D point clouds, image frames, scalar curves, etc.). For unsupported custom data, it can also be recorded and queried in its original format. Its viewer provides an interactive interface that can pause, step, rewind time, and view the synchronized changes of states of different modules, which is equivalent to a visual debugger. As Rerun officially stated, it is used in fields that require processing a large number of sensor signals, including robotics, simulation, computer vision, and other scenarios rich in spatiotemporal data.
In terms of architectural design, Rerun chose the Rust language to implement an end-to-end system in pursuit of maximum performance optimization and portability. Rust's inherent memory safety and parallel performance enable the Rerun viewer to fully utilize local multi-threading and GPU-accelerated rendering. The Rerun viewer can be run as a standalone native application (supporting Windows, Linux, macOS), or it can be compiled into WebAssembly for execution in a browser. This design allows Rerun to be used for high-speed local rendering during development, and also to be easily embedded in web pages or notebook interfaces for remote data visualization and sharing. In addition, Rerun also provides interfaces for embedding the viewer into other applications, for example, it can be embedded in Rust or Web applications, and even integrated into machine learning model demonstrations through Gradio. In terms of data storage, the current version of Rerun stores log data in memory in exchange for speed, which requires that the scale of visualized data does not exceed memory capacity. For ultra-large-scale datasets (such as millions of point clouds), the Rerun team also recognizes that there are currently performance bottlenecks. They plan to introduce a disk-based storage backend to handle longer time series and larger volumes of logs. It is worth mentioning that Rerun is also developing a commercial version of the "hosted cloud data platform" for ingestion, storage, query, and visualization in large-scale robot datasets. This cloud platform will be deeply integrated with the open-source Rerun data model to provide a one-stop solution from robot log uploading, centralized retrieval and analysis to online visualization. This commercial service is currently being tested with specific partners, and is expected to provide enterprise-level users with capabilities similar to Foxglove's cloud services in the future.
In summary, Rerun's highlights are: multi-language and easy-to-integrate logging SDK, high-performance local + Web visualization engine, flexible and general-purpose ECS data model, and a vision for cloud expansion. Its emergence provides a new option for robotics and autonomous driving developers, allowing debugging and analysis to no longer be limited to ROS internal tools, but to have a more general and efficient platform.
Foxglove is another data visualization and analysis platform for robotics and autonomous systems that has emerged in recent years. Different from Rerun's emphasis on SDK integration, Foxglove emphasizes out-of-the-box application functions. It claims to be not only a visualization tool for multi-modal data, but also a comprehensive platform for robotics and embedded AI development. Foxglove was initially launched in 2021, and many members of its core team came from Cruise, an autonomous driving company—at Cruise, they created the famous Webviz tool. Foxglove can initially be seen as an open-source continuation and upgrade of Webviz: the official website acknowledges that Foxglove "started as a fork of the Cruise Webviz project," but after rewriting and expansion, today's Foxglove and Webviz have significant differences. Foxglove was founded by Adrian Macneil and others (Adrian himself later served as Foxglove CEO). In just a few years, it has developed a series of powerful functions and has been adopted by many industry-leading robotics companies (its official website lists customers including Wayve, NVIDIA, ANYbotics and other autonomous driving and robotics companies).
Foxglove's functional features can be divided into several levels. First, multi-data source and multi-format support: Foxglove can seamlessly connect to data from ROS 1 and ROS 2 systems. No matter which ROS version the project uses, it can be connected to visualize data from various topics in real time. By providing an official high-performance bridge node (Foxglove Bridge), users can run a C++ node in ROS to transmit ROS messages to the Foxglove application through WebSocket, thereby achieving near-lossless real-time data sharing. At the same time, Foxglove also directly supports opening and playing back ROS log files, including ROS 1's .bag, ROS 2's .db3, and the general .mcap format. Users only need to drag and drop files or open them through the menu to play historical data in Foxglove without having to start the rosbag tool separately like RViz. In addition to ROS native formats, Foxglove also supports other data sequence formats, such as custom messages defined by Protobuf or JSON logs. This wide compatibility makes Foxglove not only suitable for the ROS ecosystem, but also for data visualization of other robots, middleware, or sensor systems, as long as the data is converted into Foxglove-compatible channels (for example, through its WebSocket interface).
Secondly, rich and customizable visualization panels. Foxglove provides more than 20 built-in visualization "Panels". Commonly used ones include 3D view, image display, Plot curves, Diagnostic status, Transform tree, LiDAR point cloud, map, and state machine transitions, etc. These panels can be freely combined in a workspace, and support saving and switching layouts, and one-click loading of preset interface configurations. In contrast, traditional ROS tools need to switch and manually arrange between multiple windows such as RViz, rqt_plot, and rqt_console. Foxglove concentrates all the views required for debugging in the same interface, which greatly improves the convenience of debugging. Especially in terms of 3D visualization, Foxglove's 3D Panel not only has most of the functions of RViz (displaying robot models, coordinate axes, Marker markers, point clouds, etc.), but also can directly overlay camera images, and supports multiple video encoding formats (such as H.264, H.265, etc.) to improve efficiency. For example, users can simultaneously see the point cloud perceived by the robot, real-time video from the camera, and detected object boxes in a 3D panel, and interactively rotate the viewpoint to inspect. In addition to built-in panels, Foxglove emphasizes extensibility: it provides Extensions API, allowing developers to write custom panels using HTML/JavaScript and load them into Foxglove. This means that teams can develop visualization plugins specifically for their own projects without modifying the Foxglove core code. Compared to the cumbersome process of RViz requiring C++ compilation of plugins, writing and sharing extensions on Foxglove is easier. Foxglove even provides an extension registry library where developers can publish and share their custom panels for other users to download and use, thereby forming a community-driven plugin ecosystem.
Third, Foxglove is increasingly improving its team collaboration and data management functions, which makes it evolve from a pure tool to a platform. For team collaboration, Foxglove supports sharing layouts and cloud synchronization: users can save their configured visualization layouts as organization-wide templates, which can be accessed by team members. At the same time, Foxglove provides a central data warehouse function, where team members can upload log data to the cloud for centralized storage and indexing, which is convenient for everyone to jointly retrieve and analyze. To cooperate with this, Foxglove has developed components such as Foxglove Data Platform and Foxglove Server/Agent: Foxglove Agent can be deployed on robots or vehicles to automatically upload locally recorded data fragments to cloud storage. The cloud platform indexes massive asynchronous data (classified by device, time, topic and other metadata). Developers can query the time period or events they care about in the cloud interface or through API/CLI, and quickly extract relevant data fragments for visualization. These team-level functions indicate that Foxglove is trying to cover the entire process needs from data acquisition, storage management to collaborative analysis—not just a local debugging tool, but also an enterprise-level robot data management solution.
In terms of technical implementation, Foxglove was initially released as a cross-platform desktop application. It is written in TypeScript and runs on the Electron framework. In essence, Foxglove Studio (desktop version) is an application built with Web technologies, which extensively uses WebGL/Three.js for 3D rendering and UI presentation internally. This technology selection makes it very convenient to achieve cross-platform compatibility: in fact, Foxglove also provides a web version application. Users do not need to install software, as long as they open a browser to access its cloud App (app.foxglove.dev), they can get almost the same functions as the desktop version. The Electron version is suitable for scenarios that require offline use or processing of local files, and can be directly installed and run on Windows, macOS, and Linux without ROS environment dependencies. Foxglove pays great attention to using modern Web technologies to improve performance and experience. For example, in the new version of the 3D panel, they optimized the rendering pipeline and introduced Three.js to accelerate the drawing of complex scenes, making the rendering of large-scale point clouds and Markers smoother. For another example, through WebAssembly, Foxglove can efficiently parse binary formats such as .mcap logs in the browser, achieving processing speeds close to local speeds. Overall, Foxglove has achieved expansion from stand-alone debugging to cloud collaboration by combining front-end technology and back-end cloud services.
In the process of Foxglove's development, it has also experienced some strategic adjustments. Initially, Foxglove Studio was released as a completely open-source project on GitHub, attracting attention and contributions from the ROS community. However, in 2024, Foxglove announced the launch of "Foxglove 2.0", integrating the desktop Studio and cloud platform, and adjusted its open-source strategy—it no longer publicly discloses the source code of the latest version of Studio. This means that Foxglove has turned to a closed-source business model, but the official website promises to still provide free use for research and academic teams. This change has caused some discussions in the community, but from a product perspective, Foxglove is now more like a commercially supported professional software. Its basic functions are still free for individuals and open source, but the source code is no longer open. Even so, Foxglove has gained considerable recognition in the robotics industry so far. For example, the CTO of Simbe Robotics commented: "It fills a long-standing gap in the ROS ecosystem"; the product manager of Wayve praised Foxglove for allowing them to shorten the root cause analysis of problems from days to minutes. These feedbacks show that Foxglove does improve efficiency for teams in actual development. In general, Foxglove provides a ready-to-use, fully functional, and extensible robot data visualization debugging tool, which is very suitable for development teams that need to process a large number of logs and collaboratively debug complex problems.
Before analyzing Rerun and Foxglove, it is necessary to understand the characteristics and limitations of RViz and Unity as "traditional" solutions.
RViz (ROS Visualization) is the official 3D visualization tool of ROS, which has been provided with ROS distributions since the early versions of ROS. As open-source software, RViz provides ROS users with a convenient interface to observe the internal state and sensor output of robots. It supports loading robot models (URDF), displaying TF coordinate transformation trees, visualizing LiDAR and depth camera point clouds, displaying camera image streams, and using Marker markers to draw shapes, trajectories and other debugging information. Among ROS developers, RViz is widely used for real-time debugging of running robot systems: developers run ROS nodes to publish topics, and then add corresponding Display plugins in RViz to subscribe to the topics, and they can see the visualization effect of the data, such as the map formed by the point cloud scanned by the robot's LiDAR. The advantage of RViz is its deep integration with ROS, using the ROS communication mechanism to obtain data, with low latency and what you see is what you get. For personal development or prototype verification on a single machine, it is still an entry-level tool for many ROS beginners.
However, the limitations of RViz are also very obvious. First, it is basically limited to the ROS ecosystem. To use RViz, users must install and configure the ROS environment on their local machine (installing ROS on Ubuntu is a common practice, and using it on non-ROS supported platforms is quite troublesome, requiring the help of virtual machines, etc.). This makes cross-platform use difficult: although ROS2 theoretically supports Windows, on the whole, RViz mainly serves ROS development on Linux. Without the support of ROS publish-subscribe, RViz itself cannot independently load data files or connect to non-ROS data sources. Secondly, the functions of RViz are relatively simple: focusing on 3D scenes and sensor visualization. For time series charts, system status diagnosis, etc., ROS provides a series of independent tools such as rqt_plot, rqt_console, and rqt_graph, which need to be started and configured separately. This brings a fragmented user experience: when debugging complex problems, developers may have to open RViz to see sensors, open rqt_console to see logs, and use command lines to play rosbag, and cannot view them uniformly in one interface. For situations that require frequent analysis of long-term recorded data, RViz is even more inadequate—it does not have a built-in log playback function, and must rely on the command-line rosbag playback, and then RViz is used as a real-time data subscriber. This process is very unintuitive. Again, although the extensibility of RViz is achieved through a plugin mechanism, it is not easy to use. Writing RViz plugins usually requires C++, linking ROS libraries and following the RViz display interface, and then putting the compiled plugins in a specific path for use. For most developers, unless absolutely necessary, few people write custom RViz plugins. In most cases, they wait for the ROS community official or third parties to provide support for corresponding message types of Display (such as point clouds, Octomap, etc. are contributed by the community). This makes RViz respond slowly when facing new sensors or special data types. Finally, in terms of performance, RViz uses the older OGRE graphics engine, and the rendering effect and efficiency are different from modern engines. If you display ultra-large-scale point clouds or high-resolution images in RViz, there will be frame rate drops or even freezes, which is a common problem encountered by ROS users (for example, when displaying multiple high-definition camera images at the same time, the frame rate will drop to single digits). In short, RViz, as a classic tool, is suitable for ROS single-robot debugging and beginner practice, but in terms of data scale, function integration, and team collaboration, it can no longer meet the needs of higher-requirement applications.
Unity represents another idea of visualization tools. Unity is a leading commercial game engine in the industry. It was not originally designed for robot development, but due to its excellent real-time 3D rendering and physics simulation capabilities, it is widely used in robot simulation and digital twin scenarios. Different from RViz's focus on data visualization, Unity focuses more on building interactive virtual environments. Developers can use the editor provided by Unity to build realistic scenes (such as city blocks, factory workshops), physical models (rigid body dynamics, collision detection), and camera and lighting effects, thereby simulating realistic images and sensor data. For autonomous driving, engines such as Unity can be used to generate virtual sensor inputs, allowing AI algorithms to be trained and tested in a simulation environment, thereby reducing the risks and costs of real road testing. This is a typical case of digital twin application: a Unity scene serves as the "digital twin" of a vehicle, replicating the real world in a computer and generating various possible situations.
The advantage of Unity lies in its high degree of flexibility and realistic effects. Any 3D object, scene, or dynamic process can be implemented in Unity through programming. For visualization, this means that if needed, developers can create extremely customized robot visualization interfaces in Unity. For example, some teams connect Unity to ROS to realize Unity as the front-end to display robot status: through Unity's ROS bridge library (such as ROS# or Unity Robotics Hub), Unity can subscribe to ROS topic data, and then update the robot model and display sensor information in the virtual scene. The rendering effect of doing so is more gorgeous than RViz, and it is also more suitable for demonstrations and presentations. However, the limitation of Unity is that it is not an out-of-the-box debugging tool, but a general-purpose engine, which requires more development work. Using Unity for robot data visualization often means redeveloping a lot of logic: writing scripts to parse ROS messages or other data sources, managing network connections with robot systems, programming to draw the required UI and graphic elements, etc. This is equivalent to custom development of a dedicated software, which is costly for general development processes. Compared to Foxglove or Rerun, which can visualize data in a few lines of code, Unity's learning curve and development workload are not to be underestimated. In addition, Unity, as a professional engine, has high requirements for computing resources for its editor and runtime environment. Running Unity simulation and ROS programs on the same development PC may occupy a lot of CPU/GPU, and the debugging efficiency may not be higher than professional visualization tools. In terms of cross-platform compatibility, the Unity editor mainly runs on Windows/Mac (and also supports Linux editor in recent years), and the applications built can be deployed to multiple platforms. But this is more for the final delivered simulation applications. For daily developer collaboration and debugging, it is not as lightweight and convenient as Web applications.
In summary, RViz represents a local visualization tool in the traditional robot workflow that is tightly coupled with ROS, which is simple and reliable but functionally limited; Unity symbolizes a solution that uses game/simulation engines for high-fidelity simulation visualization, providing maximum flexibility and realism, but requires significant development investment and is not suitable as a daily debugging and analysis tool. Understanding the characteristics of these two helps us to better compare how the new generation tools Rerun and Foxglove learn from each other's strengths in terms of performance, extensibility, etc. in the following.
Based on understanding the background and characteristics of each tool, we conduct a comparative analysis of Rerun, Foxglove, and traditional RViz and Unity from multiple dimensions:
Real-time rendering and data processing performance are key indicators of visualization tools. Rerun, due to being written in Rust and executed end-to-end locally, has a very high performance ceiling. Rerun CTO emphasized that its viewer "runs entirely on the client side, implemented end-to-end in Rust for maximum speed and portability," which can run natively locally to fully utilize multi-threading and native rendering APIs, and can also be compiled into WebAssembly to run in a browser. This means that for massive point clouds, high-definition images and other data, Rerun can ideally achieve smooth display with the help of local GPUs and optimized algorithms. In addition, Rust's memory management efficiency and thread safety also ensure the stability of Rerun when processing concurrent data streams. In practical applications, Rerun is said to be one of the "fastest multi-modal data viewers in the industry" (this can be seen from its design concept). Of course, Rerun still has some areas to be optimized for extreme data volumes. For example, the official website points out that performance will drop significantly when displaying point clouds of millions of points at a time, and if there are too many entities (such as very complex objects in the scene), the viewer will also slow down. The Rerun team is already developing new data storage and rendering strategies to improve these problems. Overall, under regular-scale data (typical robot sensor frequency and range), Rerun's rendering frame rate and response speed are excellent, which can meet real-time debugging needs.
Foxglove's performance optimization mainly relies on modern Web technologies and reasonable front-end and back-end division of labor. As an Electron application, Foxglove has a built-in Chromium browser engine. Its UI rendering is handled by the browser, and 3D drawing calls the GPU through the WebGL interface. Foxglove pays great attention to using efficient JS libraries. For example, its new version of the 3D panel uses Three.js, which improves the frame rate and interaction smoothness of rendering a large amount of 3D data. Since Foxglove decouples ROS message transmission to a C++ bridge node (Foxglove Bridge), most of the data serialization and sending work is efficiently completed on the ROS side. After receiving the data, Foxglove directly renders it on the front-end, avoiding frequent cross-language calls. This architecture makes Foxglove have very little overhead when displaying real-time ROS topic data, which is enough to achieve near real-time visualization effects. At the same time, Foxglove also considers performance for situations such as log playback: using the MCAP format can more quickly randomly access fragments in large files, and Foxglove supports multi-file merged playback, which can synchronously play data from multiple sources without significantly slowing down the interface response. Of course, unlike Rerun's local native approach, Foxglove is limited by the Electron/browser environment, and JavaScript is not as efficient as native languages when performing heavy calculations. Therefore, in the case of extremely high-frequency data or ultra-large data volumes, Foxglove may reach performance bottlenecks faster. However, in actual robot applications, Foxglove's performance has been proven to be sufficient to cope with most development needs. For example, Foxglove can smoothly play high-frame-rate video topics (through hardware decoding of H.264 and other encodings), render point clouds of tens of thousands or even hundreds of thousands of points, and synchronize data from more than ten sensors while maintaining smooth interface interaction. This level of performance is more than enough for daily debugging and analysis. When it comes to larger-scale offline data, Foxglove can alleviate it through cloud indexing and on-demand loading (avoiding loading all data at once).
RViz is relatively simple in terms of performance. Due to its old architecture, mostly single-threaded execution, and rendering engine not as efficient as modern solutions, RViz often freezes when processing large amounts of data. There are many cases in the ROS community reflecting that, for example, when publishing a point cloud of 8 million points and displaying it in RViz, the refresh rate drops significantly, and it is even impossible to smoothly rotate the viewpoint. RViz also lacks special optimization for video frames, etc., and the frame rate will also decrease when displaying high-resolution camera streams. Nevertheless, for small and medium-scale data volumes (such as a point cloud of tens of thousands of points per frame for a typical indoor robot, or images from a monocular camera below 30Hz), RViz can still provide acceptable real-time display performance. After all, it is written in C++ and runs directly on the local CPU/GPU without the overhead of the browser layer. Some performance problems can also be alleviated by reducing the data frequency or sampling processing (developers often adjust the frame rate limit of point clouds or images in RViz to maintain smoothness). It should be pointed out that RViz does not support directly loading log files, which means that optimized reading cannot be performed for large logs; if the real-time ROS data frequency is too high, RViz may be overwhelmed, but developers can reduce the rate when playing rosbag. In short, RViz performance is acceptable but not for extreme data scenarios. Performance bottlenecks for complex tasks need to be overcome with other means.
Unity's performance is polarized: on the one hand, the Unity engine has been polished by the game industry, and the optimization of GPU rendering and physics calculation is very well done. It can easily draw realistic large-scale 3D scenes and run complex physics simulations at high frame rates. For rendering a large number of graphic elements (buildings, vehicles, pedestrians, etc.) and real-time lighting and shadow effects, Unity often does better than professional visualization tools. This makes the digital twin environment built by Unity achieve both simulation realism and real-time performance. But on the other hand, when using Unity for robot data visualization, performance depends on how developers implement data interfaces. If Unity is only used as a front-end to visualize ROS data, then the bottleneck is likely to appear in the communication between ROS and Unity (usually transmitted through network/IPC), or in the script processing efficiency. Unity's C# scripts run in the Mono/IL2CPP environment, which is slightly inferior to native C++, but with reasonable optimization, it can also achieve real-time processing of tens of thousands of data points per frame. In addition, the Unity engine itself is relatively resource-intensive: it needs to load the entire game environment, and the GUI and debugging overhead are also considerable. Running Unity simulation and robot algorithms on the same machine at the same time will significantly occupy CPU/GPU resources. Some developers have reported that when Gazebo simulation and RViz are running at the same time, computer resources are already very tight, and switching to complex Unity scenes may be even worse. Therefore, although Unity is powerful, if it is only for data visualization, its performance utilization rate may not be high (a considerable amount of resources are spent on graphic details, not on the data itself). In terms of real-time performance, Unity can adjust the simulation step size, which can be fast or slow; but when interacting with real robots, it is generally necessary to maintain real-time synchronization. Unity has no problem in this regard, but the intermediate bridge may introduce millisecond-level latency.
In summary, Rerun pursues ultimate local speed in performance and is good at handling synchronous display and high-speed query of multi-modal data; Foxglove uses modern Web technologies to achieve performance close to local performance, and the smoothness is sufficient under regular-scale data; RViz can meet basic real-time visualization needs, but it is struggling when facing big data; Unity has powerful performance, but whether it is efficiently utilized depends on the specific implementation. As a general-purpose engine, many of its overheads are not directly related to robot visualization. For tasks that require high frame rate processing of massive sensor data, new-generation tools (Rerun/Foxglove) are obviously more suitable than old ROS tools and cumbersome game engines.
Extensibility covers the tool's support for plugins, the degree of openness of APIs, and cross-platform capabilities, etc. Both Rerun and Foxglove attach great importance to usability in different environments and secondary development capabilities, but in different ways.
Rerun's extensibility is reflected in two levels: multi-language API support and embedded integration capabilities. Rerun provides a unified data model and SDK, but encapsulates the interfaces into mainstream development languages such as Python, C++, and Rust. This means that developers can call Rerun's logging functions in their familiar language environment and seamlessly integrate Rerun into existing projects. For example, in a ROS system, you can write a C++ or Python node, subscribe to all topics of interest and call the Rerun SDK to record, thereby realizing the bridge between ROS and Rerun. In fact, Rerun officially provides examples to demonstrate how to connect to ROS 2: forward common topic data to the Rerun viewer through a ROS 2 node. In addition to ROS, Rerun is also suitable for other frameworks. You only need to call its API in the code. Therefore, whether it is AirSim simulation, OpenCV programs, or custom sensor systems, they can be easily connected to Rerun. This flexible SDK makes Rerun have general data access extensibility. Second, the Rerun viewer can be embedded as a component into other applications. For example, developers can embed Rerun's rendering viewport in their own Rust GUI, or load the Rerun front-end through WebAssembly in Web applications, so that web pages have interactive 3D data viewing functions. Even in environments like Jupyter Notebook, Rerun can display visualization results in an inline manner. This embedded capability is very useful for building custom toolchains—large enterprises can develop internal visualization platforms based on Rerun and embed them into more complex systems. Since Rerun itself is open source, if more underlying customization is required, the development team can also fork the code for modification. However, Rerun has not yet provided a "plugin" interface to dynamically load custom rendering modules. It achieves extensibility more through open SDKs and open source code. However, Rerun's data model is a general-purpose ECS model. Users can record custom components (data with their own names and structures), and then use Rerun's query API to extract these data and align them with other modalities for analysis. This can be regarded as logical extensibility: it is not limited to predefined message types, but encourages users to record any information they need and utilize it.
Foxglove shows a high degree of plug-and-play characteristics in terms of extensibility. Foxglove Studio itself supports plugin-style Panel extensions. Developers can write new panels using web technologies (HTML/JS) and interact with the application through Foxglove's extension API. This design reduces the barrier to extension. There is no need to compile complex binaries, and you only need to write scripts. For example, if a team has special visualization needs, such as displaying a pie chart of the robot's battery status or a customized map overlay, they can write this logic in JavaScript, get the relevant topic data through the subscription mechanism provided by Foxglove, draw charts in custom Panels, and then register the Panel in Foxglove for use. Foxglove will load the installed extensions at startup, and users can add it like using built-in panels. This extension mechanism is similar to browser plugins or VSCode extensions, which is very friendly to the community: Foxglove officially maintains an extension library where people can share their ideas. In contrast, RViz extensions require C++ plugins and there is no centralized library, while Unity completely relies on developers to code and implement functions without a unified plugin system. Therefore, Foxglove has obvious advantages in terms of extensibility. In addition, Foxglove provides rich public interfaces. In addition to the graphical interface, many functions of Foxglove (such as data query, log management) can also be accessed through the command-line CLI or REST API. This means that users can write scripts to batch upload/download data, trigger specific visualization layouts, and even integrate Foxglove into CI pipelines (for example, automatically upload logs and generate visualization reports after each robot night test). Looking at cross-platform compatibility, Foxglove has almost achieved full coverage: because there is a Web version, it can be used on any device that can run a browser; the Electron desktop version also supports Windows/Linux/macOS. In contrast, RViz strictly relies on ROS (mainly Ubuntu). Foxglove hides complex dependencies inside the application (Electron comes with Chromium, and ROS is accessed through Foxglove Bridge), freeing users from a lot of environment configuration work. It can be said that Foxglove has brought the easy-to-use extensibility to the extreme: from stand-alone to cloud, from individuals to teams, corresponding mechanisms are provided for support.
The extensibility of RViz is quite limited as mentioned earlier. Although plugins can theoretically be developed, the barriers are high. Therefore, in practice, the functions of RViz basically remain within the scope supported by ROS officially. The ROS community will add Display types according to needs, but the frequency is low, and RViz plugins for ROS 1 and ROS 2 are not universal, requiring repeated development, which is a problem in its ecosystem. RViz itself does not provide external APIs, and the behavior of RViz cannot be remotely controlled by scripts (only manual clicks on the GUI are possible). In terms of cross-platform compatibility, ROS officially supports Ubuntu and Windows, but Windows configuration is complex and not many people use it. Using RViz on macOS requires compiling ROS by yourself, which has a high barrier. Therefore, RViz is usually regarded as a ROS-specific tool on Linux, rather than a general-purpose portable component. This is lagging behind in today's diverse development environment—for example, if team members use different operating systems, it is difficult for them to run RViz to see the same effect, while Foxglove can easily solve this problem.
Unity's extensibility is beyond doubt. From one perspective, it may be infinitely extensible: users can use C# and the engine API provided by Unity to build any required functions and interfaces, including visualization and background logic. For example, Unity can load 3D models and textures in various formats, support importing external data files (parsing CSV, JSON, etc. through C#), and can also increase capabilities through plugins (such as components on the Asset Store), such as VR support, UI frameworks, etc. Therefore, if Unity is regarded as a development platform, there is almost nothing it cannot do, only the issue of how much time is invested. However, this infinite extensibility is based on the fact that the tool itself does not provide specific functions—Unity gives a set of building blocks, but how to build a visualization application for robots depends entirely on the user's own design. This is actually closer to a framework rather than a ready-to-use tool positioning. Therefore, directly comparing the extensibility of Unity with the above-mentioned dedicated tools is not completely equivalent. But we can say that Unity's flexibility is very useful for special needs. For example, some companies may develop complete simulation + monitoring systems based on Unity, and their interfaces and functions are completely customized. From this perspective, Unity can meet unique requirements that Rerun or Foxglove cannot cover, but the cost is that it requires a professional software development process. Unity has strong cross-platform capabilities. Developers can easily publish applications to Windows/Linux, and even mobile devices or AR glasses, etc., which is very valuable for creating immersive digital twin experiences. But this is more for the final delivered simulation applications. For daily robot R&D and debugging, this cross-platform significance is not great, because engineers are more debugging and analyzing on PCs, and do not need to deploy debugging tools on mobile phones.
In summary, in the extensibility dimension: Foxglove provides an excellent experience of ready-to-use and extensible with its easy plugin extensions, rich integration interfaces, and excellent cross-platform support; Rerun gives developers the ability to integrate it into various environments through open SDKs and embedded design, and provides flexibility in the data model; RViz is relatively closed, only adapting to ROS's own extensions, and it is difficult to jump out of the original framework; Unity is extremely flexible but lacks ready-made integration, and usually requires a lot of work to extend for specific needs. For teams that want to quickly customize functions, Foxglove provides the lowest barrier, and for scenarios that want to deeply integrate into their own systems, Rerun's source code and SDK are also a solid foundation.
Data compatibility refers to the types of data formats supported by the tool, as well as the ability to integrate and exchange data with other systems. In the fields of robotics and autonomous driving, data formats are diverse, including various sensor raw data, algorithm outputs, log files, etc. Therefore, the compatibility of tools directly affects their practical scope.
Both Rerun and Foxglove are designed to target compatibility with multi-modal and multi-source data. Rerun adopts a custom rrd binary log format to store sequences of component data of any type. Through its SDK, developers can convert common data into Rerun's native types (for example, images will be encoded into frame data, point clouds as point lists, etc.) and then record them. For unsupported types, they can be attached in raw numpy array or binary format, which makes almost any data able to be "stuffed" into Rerun's logging system. Rerun focuses on data time synchronization and structured representation, rather than specific message definitions: it does not force a certain field to be present, but records what the developer provides. This brings great format flexibility. For example, a SLAM algorithm generates a list of keyframe poses, which is not a standard ROS message, but developers can record it as a custom list of 3D transformations in Rerun, and later it can still be displayed in the viewer through trajectory lines or coordinate systems. Rerun currently supports importing some mainstream formats: for example, the official website mentions that it can read ROS MCAP logs, some proprietary logs, and even incorporate tabular data (Apache Arrow, Lance formats). Most of these functions belong to the features being developed in its commercial version, but they reflect Rerun's idea—to absorb data from various sources through a unified data model. However, currently Rerun's direct support for ROS topics is not perfect, and users need to write bridge nodes themselves. Foxglove is obviously more mature in this regard. However, Rerun's advantage is that non-ROS users can also use it conveniently because it does not rely on ROS message formats. Any independent application (computer vision program, simulation environment) can directly use Rerun to record data without first converting it into ROS messages. This is very friendly to robot projects that do not use ROS architecture (such as some custom embedded systems or pure vision algorithms).
Foxglove's data compatibility is closer to the ROS ecosystem, but it is also expanding its scope. It naturally supports all built-in message types of ROS 1/ROS 2. Through Foxglove Bridge, any ROS custom message can also be automatically transmitted, because Bridge can obtain the structure and data of ROS messages and encapsulate them into a general format. Foxglove adopts an open WebSocket message protocol, which can transmit data packets containing type descriptions and binary payloads, making it possible to express ROS messages and also carry non-ROS data formats. For example, Foxglove officially mentioned support for Google Protobuf—developers can define Protobuf message structures, send them using Foxglove's client library, and Foxglove Studio can also parse and display them. Not to mention JSON and other formats, which can be viewed through Foxglove's Plot or Console panels as text data. Foxglove's compatibility with log file formats is particularly prominent: in addition to traditional ROS bag, it cooperated with the APT team to develop the MCAP format (a general-purpose multi-modal log container), which has now become the default log format of ROS 2. Foxglove can directly read MCAP files and visualize the data in them, which is also useful for users outside of ROS, because MCAP does not depend on ROS, it is just a container that can hold data of any schema. Many robotics companies choose not to use ROS for internal communication due to performance or multi-language considerations, but use self-developed solutions. These companies can still use MCAP to record data and then use Foxglove to view it. This reflects Foxglove's data universality strategy: to support commonly used or high-performance formats in the industry as much as possible, so as to become a "universal observation tool" between different systems. In terms of practical integration, Foxglove currently provides a seamless experience for ROS (that is, you can connect to ROS Master or ROS2 DDS with one click). For non-ROS data, users need to run a Foxglove WebSocket server to send data to Foxglove. Foxglove officially provides some bridge library examples to facilitate encapsulating custom data sources into Foxglove-readable formats. In general, Foxglove is closely related to ROS on the one hand (because this is the largest user group), and on the other hand, it also opens the door to welcome other formats. In the long run, it hopes to become a "Swiss Army knife" tool for various robot data.
RViz is strictly coupled with the ROS message system. It only recognizes ROS-defined message types out of the box (such as sensor_msgs/PointCloud2, nav_msgs/OccupancyGrid, etc.), and each corresponds to a Display plugin in RViz. If there is a new type of data, you must write an RViz plugin to tell it how to render it. Leaving ROS, RViz basically cannot work, because it relies on the ROS runtime (roscore) and message publish-subscribe mechanism. In a word, RViz is only compatible with ROS real-time data, and not compatible with any independent data formats or files. Although ROS bag recordings can be displayed in RViz, it is because the rosbag tool re-sends the original messages through ROS topics when replaying, and RViz itself does not know the file format. Therefore, in terms of data compatibility, RViz is very narrow. This is also why Foxglove is called "filling the gap in the ROS ecosystem"—because for a long time, ROS development lacked a powerful tool to easily browse historical data and non-ROS data.
Since Unity is not a dedicated visualization tool, there is no preset "supported/unsupported" data format. What it can be compatible with completely depends on what parsing capabilities developers add to it. For example, Unity can support CSV reading, PNG/JPG loading, and even PCL libraries to parse PCD point cloud files through C# code or plugins. Unity itself has a rich asset import pipeline, which can directly import common 3D model formats (FBX, OBJ, etc.), audio, video, etc. If these are also regarded as part of data compatibility, then Unity's support for multimedia formats far exceeds other tools (because it can directly drag models into the scene). However, for robot-specific data—such as ROS topics, LiDAR point clouds, inertial navigation trajectories, etc.—Unity natively does not know how to process them. Developers can use Unity's official ROS-TCP Connector, which can connect to the ROS network and convert ROS messages into Unity internal objects. This requires pre-defining mapping rules (similar to subscribing to a topic and converting its std_msgs/Float32 into a floating-point variable in Unity). Therefore, Unity can achieve data integration with any system through development, but there is no out-of-the-box support. This flexibility to some extent makes up for Unity's weakness that it does not belong to the robotics field. For example, some open-source projects provide code for Unity to read ROS Bag or execute SLAM algorithm results, so that Unity can reproduce ROS scenes. But these are scattered solutions, unlike Foxglove/Rerun, which directly provide unified support officially.
In terms of data integration, we can also talk about integration outside the ecosystem, such as docking with AI/big data pipelines. Rerun provides an interface to query log data as Apache Arrow tables, which is very convenient for subsequent data analysis in Pandas and NumPy. Foxglove's cloud platform allows downloading filtered log fragments through APIs for training models or offline analysis. These all indicate that new-generation tools have considered the connection with machine learning workflows. RViz and Unity do not have direct functions involved in this area—RViz is mainly for online debugging and does not involve data export; Unity can achieve data recording or reading through programming, but it is not its main focus.
Overall, both Foxglove and Rerun show the goal of "wide coverage" in data compatibility: Foxglove supports the full set of ROS and emerging MCAP and other formats, and Rerun covers multi-industry data in a general log format. RViz is limited to ROS's own formats and is not suitable as a general-purpose data viewer. Unity is theoretically unlimited, but manual implementation of parsing for each format is required. For developers who hope that one tool can handle all robot data, Foxglove is currently a more mature choice because it directly supports more formats and is more complete, while Rerun is catching up quickly. If the project does not use ROS at all, Rerun may be easier to get started with because of its SDK mode, just put the data in, while Foxglove may need to be packaged into a compatible format first. In any case, new tools have taken a big step forward in data compatibility compared to traditional solutions, reflecting the industry's demand for standardization and multi-source integration.
Ecosystem support refers to community activity, documentation and learning resources, developer support channels, and enterprise adoption, etc. This affects the sustainable development of a tool and the user's getting started experience.
Community and open source: Since Rerun was open-sourced in 2022, it has gradually established a developer community. It has more than 6000 stars on GitHub, showing good attention. The founding team actively appears in the community, such as discussing the differences with Foxglove with users on Hacker News. They also collect feedback and iterate quickly through blogs, Discord and other channels. Because Rerun is still in a stage of frequent updates, community feedback is crucial to its growth. From the user group, Rerun attracts not only ROS users, but also developers in computer vision, XR and other fields. This makes its community potentially more diverse. Rerun's documentation is relatively complete, including "Quick Start", "Examples" and API references. However, some users have also reported that Rerun's API changes frequently, which brings some difficulties to learning. In response, the official website also stated that it is working hard to become stable and is soliciting suggestions for improvement. As a young project, Rerun's ecosystem is still expanding, but a few points are worth noting: first, its openness means that the community can contribute code and plugins, which may bring about prosperous third-party extensions (similar to the growth of the ROS community in those years); second, its cross-field characteristics make the potential user group huge, and in the future, sub-communities sharing Rerun experience may appear in different industries.
Foxglove also gathered a group of loyal users in its early days (2021-2023) by using its open-source nature, especially in the ROS development circle. There are a lot of discussions on its official Discord and forum, and members of the development team (including CEO Adrian) also often directly answer user questions. From Medium blogs and ROS Discourse, it can be seen that the Foxglove team is constantly publishing tutorials and update instructions to guide ROS developers to migrate to Foxglove. They also organize online seminars, produce YouTube demos, etc. to keep the ecosystem active. Foxglove's documentation is very comprehensive, including how to connect to various data sources, use various panels, write extensions, and Troubleshooting guides. Since Foxglove Studio was once open source, the community has also contributed some extensions and feedback. However, the decision to close source in 2024 has had a certain impact on community enthusiasm, and some open-source enthusiasts have expressed disappointment. Nevertheless, Foxglove is still free for most users, but they cannot directly participate in source code development. This model is similar to some open-source to commercial development tools (such as MongoDB, etc.). The community may turn to more use rather than contribution. In terms of enterprise adoption, Foxglove is currently ahead of Rerun—many startups and research institutions have incorporated Foxglove into their daily toolchain. Some company cases (Wayve, Simbe, etc.) are promoted on the official website, further promoting Foxglove's influence in the industry. This positive cycle will attract more people to learn and use Foxglove. In terms of commercial support, Foxglove company provides enterprise versions and services. Important customers can get direct technical support and function customization, which also enhances ecosystem stickiness.
RViz, as part of the ROS system, its ecosystem is basically the ROS ecosystem itself. ROS has a huge developer community and rich tutorial resources, but there are limited special extensions for RViz. Usually, the use of RViz is covered in ROS tutorials (such as "how to display LiDAR in RViz"), and the independent community presence is not strong. Since RViz has simple functions, it does not require continuous community input—it is more of a compulsory course for ROS beginners, and then it becomes a basic tool. When developers encounter problems, they often ask for help in the ROS Answers Q&A forum or check the wiki documentation. The ROS official website will maintain RViz in each distribution, fix bugs and adapt to new ROS versions, but there are basically no revolutionary changes. In recent years, ROS has switched from ROS1 to ROS2, and RViz has also been updated accordingly (RViz2), but except for the underlying communication becoming ROS2, the interface and functions are almost the same. Therefore, for old users, the learning curve of RViz has long been flat, and no new ecosystem support is needed. Enterprise adoption is out of the question. RViz exists more in R&D scenarios. Commercial products will not directly use RViz for end users, but embed its ideas or develop their own visualization interfaces. Therefore, the ecosystem value of RViz is mainly in academic and open-source R&D circles, and its commercial value is far less than that of emerging tools.
Unity has a huge global community of game and simulation developers, and this also has some effect when it comes to robotics. Unity officially invested in robot and autonomous driving simulation in recent years (Unity Simulation, Unity Robotics and other projects), providing a lot of documentation, examples and asset packs to help robot developers use Unity. For example, Unity released the ROS-TCP-Connector component and supporting tutorials to make the connection between ROS and Unity simpler. There are also simulation platforms developed by Unity in cooperation with auto manufacturers (such as LGSVL, which was later merged into Microsoft, also based on Unity). Therefore, although Unity is not robot-specific, there is already a segment in its community discussing how to do robot digital twins and train AI. The Unity official website and learning platform even have "Digital Twin" special courses, indicating that Unity company intends to cultivate the ecosystem in this regard. However, relatively speaking, this is still a very small branch in the large Unity ecosystem. Most Unity developers do not care about ROS or sensors. For robot practitioners, if they are not familiar with Unity itself, then integrating into the Unity community requires learning game development related knowledge, which has a certain barrier. Unity's documentation quality is very high, but it is general-purpose. For specific robot applications, you need to explore and utilize it yourself. In terms of enterprise adoption, Unity has had many successful cases in the field of autonomous driving simulation (such as Bosch, Apple, etc. are rumored to use Unity for simulation), and Unity also has a market in manufacturing digital twins. However, these applications are often highly customized internal projects, which are different from the debugging tools we are discussing. Therefore, Unity's ecosystem status among robot developers is not as important as it is among game developers—it is more like a powerful external tool that is used by some resourceful teams to build their own ecosystems (for example, some open-source autonomous driving simulation projects are built on Unity, forming their own user groups).
In summary, Foxglove's ecosystem is currently the most prosperous and professional: there are active community discussions, detailed documentation, and endorsements from the actual industry. Rerun, as a rising star, has a growing community. Thanks to open source, it has great potential in the future, and documentation and support are also being gradually improved at this stage. RViz relies on the ROS community, and its ecosystem influence is mainly reflected in the popularization of ROS knowledge. As a tool itself, it has not formed an independent ecosystem. Unity has a huge community and resources, but the robotics field is only a corner of it, and targeted support is weak, requiring developers to explore and utilize it themselves. For enterprises, Foxglove's maturity and professional support make it easy to be adopted by decisions; if Rerun proves to be stable and reliable, it may also be gradually adopted, especially in open-source friendly organizations; RViz will generally not be used as an enterprise solution, but only as an auxiliary in R&D; Unity is more common in enterprise projects with simulation needs, rather than being used as a daily analysis tool. The choice of ecosystem often determines the life and growth of a tool. If new-generation tools can continue to grow their communities, they are expected to gradually replace old tools in developers' minds.
This dimension focuses on the difficulty for users with different backgrounds to get started, the user experience, and the suitability of tools in various application scenarios.
From the learning curve perspective, both Foxglove and Rerun strive to lower the barrier to entry, but target slightly different types of users. Foxglove is aimed at ROS developers and robotics practitioners, a considerable part of whom may prefer graphical interface operations rather than writing code. For these users, Foxglove's UI is very intuitive: open the software and you can see the panel library, and with a few clicks you can connect to the ROS master or load log files without writing any extra code. Its layout management and panel addition are all WYSIWYG operations, and it also has a large number of default configurations built-in (for example, commonly used topic types in ROS will automatically match suitable display methods). Therefore, for people who are familiar with ROS but use Foxglove for the first time, the getting started speed is very fast. It can be said that within a few minutes, they can build a scene similar to RViz, and then gradually explore advanced functions. Foxglove's documentation and tutorials also provide step-by-step guidance. For example, there is a comparison of "Foxglove vs RViz" on the official blog to help old ROS users quickly find corresponding functions. In addition, Foxglove's interface is more modern, and the interaction experience is more user-friendly than RViz—for example, dragging and dropping bag files to open directly, right-clicking menus to select data to display, etc. These details reduce cumbersome steps. The only challenge for new users may be that Foxglove provides a lot of functions, and panel configuration and extensions are relatively flexible, and they may not know where to start at first. However, users can gradually add the panels they need according to their tasks. Foxglove does not force complex settings. Once familiar, Foxglove becomes a Swiss Army knife for daily debugging. Almost all debugging needs can be completed in it without frequently switching tools, which greatly improves ease of use and efficiency. For data analysts without a ROS background, Foxglove is still friendly: for example, autonomous driving data scientists can use it to browse vehicle logs without having to learn ROS commands, thanks to its ability to directly load logs such as MCAP.
Rerun's positioning is slightly different. It is mainly aimed at developers, especially those who need to integrate debugging visualization into their workflow through programming. Rerun promotes "getting started in seconds"—after installing rerun-sdk through pip install rerun-sdk, a command can start the basic viewer. But when actually using it, you often need to add Rerun's log calls to the code. This is not difficult for people who are used to writing code, especially since Rerun provides very simple APIs to record data types such as images and point clouds. However, for people who do not want to touch code (such as product managers who want to directly open data to take a look), Rerun currently does not provide an independent GUI that allows you to directly drag logs in to view (although technically feasible, it is still under development and improvement). Therefore, the barrier to entry for Rerun lies in the need for some programming and integration work—for example, if ROS users want to use Rerun, they need to write a bridge node or use the official examples to run it themselves. This step is not complicated for developers, but it is not very friendly to people without a development background. The Rerun team is obviously aware of this, so on the one hand, it strives to simplify SDK calls (for example, a few lines in Python can record common data), and on the other hand, it also plans to enhance direct support for existing log formats. In the future, it may be possible to visualize rosbag by dragging and dropping like Foxglove. Judging from the learning materials, Rerun documentation is clear, covering everything from conceptual explanations of "What is Rerun" to specific code examples. They also provide tutorials for many common scenarios (such as how to combine ROS2, how to use it in SLAM, etc.). However, since Rerun's functions are iterating rapidly, sometimes documentation and version changes need to be followed up, and users need to pay attention to update logs. Rerun's UI is currently mainly a viewer window. Its interaction design is quite satisfactory, adopting pane layout and tree-like data browsing, which is easy to understand for people with programming experience—the data entities are listed on the left, and the view is displayed on the right. This simple UI is conducive to performance and embedding, but it is not as rich in coolness as Foxglove. In other words, Rerun is more like a development and debugging component that requires users to build their own "stage", while Foxglove is a ready-made "workbench". For ease of use, which one is better depends on the user's attributes: developers often find it natural to write a few lines of code, but clicking on the GUI is slow instead; while people who want to quickly visualize data tend to prefer ready-made tools. Rerun is currently in the stage of accumulating users. As community cases increase, its scope of application will be shown more clearly.
The ease of use of RViz is polarized: for people who are familiar with ROS, RViz has long been an old friend, and they are familiar with its use; but for newcomers, the overall learning curve of RViz plus ROS is relatively steep. Beginners not only have to learn ROS concepts (nodes, topics, message types, etc.), but also add Display and adjust parameters on the RViz interface to see the data they want. And the installation and configuration of ROS itself is not simple. If there is a problem with the environment, RViz cannot even start. Therefore, RViz itself is not difficult, but its premise (ROS) is difficult. Compared to Foxglove, which can run in a browser without complicated installation, RViz requires a series of dependencies, which is a disadvantage in terms of ease of use. In addition, RViz lacks guidance and templates. Newcomers are often confused about which Display to choose and which subscriptions are needed to present the correct picture. This needs to be solved by consulting ROS tutorials or others' experience. The interface of RViz is also in the style of ten years ago, not modern and friendly enough. However, once you master the basic usage, RViz is very handy when debugging simple problems. The advantage is that it is "simple enough": there are not many elements on the interface, and you can see at a glance what you can do (add display, adjust viewpoint). For ROS experts, using RViz is as natural as breathing, but for people outside the ROS field, it is basically impossible to use—it does not have the ease of use to be used independently from ROS.
Unity's learning difficulty is undoubtedly the highest, especially for those whose main background is robot software. Although Unity provides a lot of documentation and tutorials, they are aimed at game development and interaction design. If it is only for realizing robot data visualization, the content involved in learning Unity far exceeds the goal itself: from mastering the Unity editor interface, scene and prefab concepts, to learning C# programming, GameObject component system, and then understanding rendering and physics parameters, this is a complete new skill package. Many robot developers may not be familiar with these concepts, so they need to invest extra time. And Unity project projects themselves have a certain degree of complexity, and debugging the interaction between Unity scripts and ROS nodes also requires experience. If there are ready-made Unity experts in the team, it is okay to collaborate, but it is not low for people with a pure robot background to use Unity for visualization alone. Of course, once you master Unity, the return is also huge, and you can create very professional digital twin applications, which goes beyond the scope of simple debugging. Therefore, Unity is more suitable for teams with special simulation needs and corresponding talents. For general robot development teams, Unity will not be used as a daily debugging tool, but may outsource/cooperate to develop Unity simulation modules for specific purposes. Unity's documentation quality is beyond doubt. Everything API is explained, but you need to filter to find the part related to your needs. In recent years, Unity officials have launched some robot-oriented tutorials, such as how to build a digital twin of a robotic arm, which reduces some learning burden. However, in general, Unity's applicability is the most limited among the tools compared this time—it is only worth using when high-fidelity simulation or 3D display is required. Using it to replace RViz for routine sensor data viewing seems like overkill and troublesome.
From the perspective of application scenario suitability:
- Rerun is very suitable for embedded debugging during in-depth development. For example, when algorithm engineers are tuning parameters, adding a few lines of Rerun logs to the code can immediately see the changes in the internal state of the algorithm in the visualization window, so as to quickly locate problems. This is very valuable in computer vision, robot control and other R&D. In addition, Rerun's Python interface makes it easy to integrate into AI research workflows, such as recording model perception results during training and analyzing them afterwards. It is also friendly to non-ROS environments, so it is still applicable in systems such as drones and autonomous warehouse robots that may not run ROS.
- Foxglove is very suitable for robot system integration debugging and data playback analysis. When the team is testing on robots with real sensors, they can use Foxglove to monitor the status of multiple modules in real time and find anomalies; at the same time, after collecting a large amount of road test data, they can use Foxglove to centrally browse, collaboratively mark and discuss. This is especially important for teams in autonomous driving, logistics robots, etc. that need to frequently log data analysis. Foxglove's collaboration function also makes it suitable for remote teams to share problem analysis results.
- RViz is still suitable for real-time debugging in single-robot, laboratory environments, especially in the early stages of development or teaching scenarios. Some introductory courses will use RViz to allow students to intuitively feel robot perception. In this scenario, RViz is sufficient and simple.
- Unity is mainly suitable for simulation testing and display. For example, at product exhibitions, digital twins built with Unity can realistically demonstrate robot working scenarios; in R&D, Unity simulation can generate extreme situations that are difficult to reproduce in real environments for algorithm testing. So it is more like a bridge between R&D and products, used for verification and display rather than daily bug debugging.
To sum up, in terms of applicability and ease of use: Foxglove wins in ease of getting started and unified interface, which is very friendly to ROS users and can quickly improve team debugging efficiency; Rerun wins in integrating into the development process, high ease of use from a developer's perspective, and wide application scenarios, but requires a certain programming foundation; RViz is easy to use for ROS veterans, but its functions are limited, and it is not friendly enough to novices and non-ROS uses; Unity requires the largest learning investment. Unless its powerful capabilities are needed, it is not used as a daily tool. Which tool to choose depends on the team's background and needs: for those pursuing fast visualization analysis and team collaboration, Foxglove is an ideal choice; for those pursuing in-depth custom debugging and open-source flexibility, Rerun provides new possibilities; for small-scale development within the ROS system, RViz is still sufficient; and when high-fidelity simulation scenarios or digital twin projects are needed, engines such as Unity can play a role.
Through the above analysis, it can be seen that Rerun and Foxglove represent the new generation development direction of robot and autonomous driving visualization tools. They greatly surpass traditional tools such as RViz in terms of performance, function, and collaboration, and are also more in line with the needs of the field than the general-purpose engine Unity. Rerun is known for its developer-friendly SDK and high-performance local rendering, aiming to become a "one-stop multi-modal data stack", allowing researchers and engineers to easily record, view, and query robot data. Foxglove wins with its rich panels and platform-based thinking, positioning itself as a "versatile observation and operation and maintenance platform" in the robotics field, covering everything from real-time debugging to log management. In contrast, old tools like RViz have completed their historical mission and are inadequate in more complex scenarios; digital twin technologies such as Unity are still important, but they are more like the underlying support for simulation and display, rather than direct development and debugging tools.
It is foreseeable that robot/autonomous driving visualization will develop in the following trends in the next few years:
- Cloudification and Collaboration: With the expansion of robot teams and the increase of distributed collaboration, tools need to support cloud data synchronization and remote collaborative analysis. Foxglove has already taken this step, providing organizational layouts and cloud data warehouses. Rerun also plans to launch a cloud platform. In the future, we may see deep integration of visualization tools and cloud services. For example, team members only need to open a browser to jointly mark and discuss robot logs, and AI engineers can directly obtain visualized and filtered data for training.
- Standardized Data Formats: ROS 2 adopting MCAP as a general-purpose log format is a major progress. Unified formats make the tool ecosystem more prosperous because they can reduce format conversion costs. Foxglove supports MCAP. More standards may emerge in the future, such as cross-language data table formats based on Arrow. This will make collaboration between different tools smoother. Even Foxglove and Rerun can read data generated by each other, and users can freely combine them.
- Stronger Performance and Extensibility: When robot sensors enter the era of 10 billion pixels (such as high-resolution panoramic cameras, multi-LiDAR fusion), visualization tools need to process massive amounts of data without crashing. This may require the introduction of technologies such as streaming loading and distributed rendering. Rerun's planned disk backend and Foxglove's Agent diversion ideas are all to expand data scale processing capabilities. The utilization of GPUs will also be more fully utilized, such as using shaders to process point clouds more, using hardware to decode videos, and multi-threading parallel parsing of logs, etc., to maintain real-time interactivity.
- Cross-field Integration: Robot visualization will no longer be isolated in the ROS circle, but will be integrated into the wider fields of AI and digital twins. Rerun has mentioned that its tools are also useful in generative media, industrial processes, security monitoring and other scenarios. This shows that future visualization tools need to adapt to more types of data and workflows. For example, docking with deep learning training platforms to realize a closed loop from data recording -> annotation -> training -> re-visualization results; and for another example, combining AR/VR to project real-time visualization into the physical site to form true mixed reality debugging. These cross-field attempts will make visualization tools more versatile and create new application models.
- Intelligent Analysis Assistance: Current tools mainly passively "display" data, and analysis and judgment rely on people. But with the development of AI technology, future visualization tools may have some built-in intelligent assistance functions. For example, automatically detect abnormal patterns in logs and remind users, or infer possible causes of failure based on visualization results. This is similar to adding intelligent assistants in IDEs. Foxglove and Rerun actually have the conditions to do this because they have mastered rich multi-modal data. Once the model is powerful enough, it can completely discover associations in robot logs that are difficult for human eyes to detect at a glance, improving debugging efficiency. Of course, this is a more distant outlook.
In summary, the emergence of Rerun and Foxglove is in line with the needs of the robot and autonomous driving industry development: they allow developers to understand robots faster and see the stories behind the data. As Foxglove CEO said, the industry is growing rapidly, and the cake is big enough, and various innovative tools have their own stage. In the future, we may not only have one "all-in-one" visualization tool, but different powerful tools for different scenarios. But what is certain is that openness, high performance, collaboration, and intelligence will be the common directions pursued by these tools. For developers, this is the best era—there are so many excellent tools to choose from, allowing us to more calmly control the complexity of robot and autonomous driving systems, so as to put more energy into real innovation and applications.
- Foxglove - Visualization and observability for robotics developers.
- Foxglove vs. RViz.
- Foxglove vs. Webviz.
- Foxglove Studio vs. RViz - Medium
- Foxglove Studio vs. Webviz - Esther S. Weon - Medium
- Foxglove Studio - new open source robotics visualization and debugging tool : r/robotics
- Foxglove uses Three.js to optimize rendering performance for their 3D data visualizer - Showcase - three.js forum
- Foxglove 2.0 - integrated UI, new pricing, and open source changes - General - ROS Discourse
- Create custom panel - Foxglove Docs
- Announcing Live ROS 2 Support - Esther S. Weon - Medium
- Rerun
- What is Rerun? — Rerun
- GitHub - rerun-io/rerun: Visualize streams of multimodal data. Free, fast, easy to use, and simple to integrate. Built in Rust.
- Rerun: Visualize Multimodal Data over Time | Hacker News
- ReRun An Open Source Package For Beautiful Visualizations - Robohub
- rerun-io/cpp-example-ros-bridge - GitHub
- Use Rerun with ROS 2 — Rerun
- RViz
- Unity