# Foxglove > Foxglove is the agentic data platform for Physical AI. It lets engineers visualize, debug, and collaborate on robot data including ROS 1, ROS 2, MCAP, Protobuf, and custom formats -- through a web-based and desktop application. Foxglove is a purpose-built platform for robotics teams to collect, analyze, and learn from the vast quantities of multimodal data required to build, train, deploy, and operate reliable robots. It supports 20+ customizable visualization panels for point clouds, images, time series, 3D scenes, plots, maps, and more. Key capabilities: - **Visualization**: Stream and visualize multimodal robotics data in customizable layouts - **Data Management**: Record, ingest, index, and manage robotics data with flexible retention policies - **Analysis**: Search, replay, and debug recorded data from any device or time range - **Agents**: Ask Foxglove's built-in agent or connect agents through MCP - **Foxlet**: On-robot process for automated data collection, upload, and remote monitoring - **MCAP**: Open-source container file format for multimodal time-series data - **Extensibility**: Build custom panels, message converters, topic aliases, and shared layouts - **Integrations**: Native support for ROS 1, ROS 2, MCAP, Protobuf, JSON, FlatBuffers, and custom formats Foxglove is used by leading robotics companies including Shield AI, Wayve, Dexterity, NVIDIA, Waabi, Saronic, ANYbotics, and many more across autonomous vehicles, defense & aerospace, logistics, manufacturing, agriculture, marine, and healthcare industries. Plans: Free, Pro (from $20/month plus usage-based pricing for storage, seats, and devices), Enterprise (custom), and Academic (no cost for eligible .edu and .ac users). Details: https://foxglove.dev/pricing Website: https://foxglove.dev Documentation: https://docs.foxglove.dev/docs GitHub: https://github.com/foxglove Discord: https://discord.gg/vUVAdFmMFM X: https://x.com/foxglove LinkedIn: https://www.linkedin.com/company/foxglovedev YouTube: https://www.youtube.com/@foxglovedev Community: https://foxglove.dev/community --- ## Robotics Resources ### Data management tools for multimodal data. URL: https://foxglove.dev/robotics/data-management-tools-for-robotics-a-2025-guide-comparison A complete guide and comparison for 2025. Modern robotics systems generate massive volumes of complex data--from high-frequency lidar scans and 4K video streams to telemetry, control commands, and diagnostic logs. Without proper data management tools for robotics, this information becomes a liability rather than an asset. This comprehensive guide compares the leading data management tools for robotics in 2025, helping you choose the right solution for your robotic systems, whether you're building autonomous vehicles, industrial robots, or drone fleets. ## Why robotics needs specialized data management tools. Generic storage solutions fail in robotics because robotic data is fundamentally different: ### Unique characteristics of robotics data. Multimodal & synchronized: Robotics systems combine video, depth maps, 3D point clouds, IMU readings, and telemetry in precise temporal alignment. A single autonomous vehicle can generate: - 4TB/hour from cameras and lidar - 100MB/hour from telemetry and diagnostics - Critical timing requirements within microseconds Edge-to-cloud distribution: Data originates on resource-constrained edge devices but must be accessible for cloud-based analysis, machine learning training, and fleet-wide insights. Real-time + historical analysis: Teams need both live monitoring for operational safety and retrospective analysis for debugging, compliance, and model improvement. ### Cost of poor data management. Without proper data management tools for robotics, teams face: - Development delays: Engineers spend 40-60% of time manually correlating data sources - Storage overflow: Edge devices crash from unmanaged data accumulation - Lost insights: Critical failure data becomes inaccessible when needed most - Compliance risks: Inability to retrieve specific incidents for regulatory review ## Top 4 data management tools for robotics in 2025. Based on comprehensive analysis of features, performance, and real-world robotics deployments, here are the leading data management tools for robotics: ### 1\. Foxglove + MCAP (recommended solution). Primary use case: Comprehensive MCAP (format agnostic) and ROS-native data management with real-time and recorded data visualization. Best for: Teams building complex physical AI systems requiring full-stack data observability and advanced debugging. Why Foxglove is the clear leader: - Native ROS 1/2 integration with zero configuration overhead. - MCAP format delivers 10x faster performance vs. traditional rosbags. - Built-in multimodal visualization eliminates need for separate tools. - Seamless edge-to-cloud workflows with major cloud providers. - Purpose-built from the ground up specifically for multimodal data and physical AI. Key capabilities: - Real-time streaming: WebSocket and REST APIs for live data access. - SDK with multi-language support (Python, Rust, C++) to stream and visualize data live as well as log data to MCAP files. - Synchronized playback: Timeline-based navigation across all sensor modalities. - Developer-friendly: Direct topic introspection. - Web and App (Linux, Mac, Windows) based. For most physical AI and robotics teams, Foxglove provides the most complete, future-ready architecture for data-driven development. It's the only solution that delivers across all major dimensions: real-time visualization, structured multimodal logging, scalable cloud support, and seamless data integration. ### 2\. ReductStore (specialized for high-volume storage). Primary use case: High-throughput time-series storage. Best for: Edge-heavy deployments requiring efficient local storage management Core strengths: - Volume-based FIFO retention prevents edge device storage overflow - Conditional replication using custom query language reduces bandwidth costs - Topic-level granularity allows per-data-type storage strategies - High-performance ingestion handles sustained write loads without degradation Limitations: - No native ROS integration (requires custom setup). - No built-in visualization capabilities. - More complex to implement than Foxglove. ### 3\. Rerun (focused on 3D visualization) Primary use case: Spatial data analysis. Best for: Applications requiring basic visualization and XR integration. Unique features: - Column-oriented data model optimizes memory usage for large datasets. - Real-time 3D rendering with interactive exploration capabilities. - Multi-language support (Python, Rust, C++) for diverse development environments. - Selective logging captures only relevant data streams. Limitations to consider: - No native MCAP or ROS integration (requires custom implementation). - No multi-topic inspection or analysis. - Primarily visualization-focused rather than comprehensive data management. - Not a complete storage solution. ### 4\. Heex (event-driven capture) Primary use case: Data capture triggered by specific events or anomalies. Best for: Production fleets requiring incident triage and analysis. Key differentiators: - Event-driven recording captures only relevant moments, reducing storage by 90%+. - Remote rule management allows real-time adjustment of capture criteria. - Fleet dashboard provides centralized monitoring across distributed robots. - MCAP + Foxglove integration leverages proven visualization tools. Limitations: - Captures only subset of available data. - Requires predefined rules to be effective. - Less suitable for comprehensive data analysis. ## Detailed feature comparison. | Feature | Foxglove | ReductStore | Rerun | Heex | | ----------------------- | ------------------------------- | ------------------------ | --------------------- | ---------------- | | ROS integration | Native ROS1/2 | Custom setup required | No native support | Native ROS1/2 | | Real-time streaming | ✅ SDK-based/WebSocket/REST API | ✅ REST API | ✅ SDK-based | ✅ Foxlet-based | | Multimodal playback | ✅ Synchronized | ❌ Manual correlation | ⚠️ Limited | ✅ Via Foxglove | | Edge storage management | ✅ Yes | ✅ FIFO | ❌ Memory-only | ✅ Event-based | | Cloud-based | ✅ Native | ✅ GCS optimized | ⚠️ Manual | ✅ Native | | 3D visualization | ✅ Built-in | ❌ External tools | ✅ Advanced | ✅ Embedded | | Query performance | ✅ MCAP optimized | ✅ Time-series optimized | ✅ Memory optimized | ✅ Event indexed | | Bandwidth efficiency | ✅ High | ✅ High | ❌ | ✅ Very High | | Learning curve | ✅ Low | ⚠️ Medium | ⚠️ Medium | ✅ Low | | Complete solution | ✅ Yes | ❌ Storage only | ❌ Visualization only | ⚠️ Event-focused | ## How to choose the right data management tool for robotics. ### Selection framework. 1. **Assess your data profile.** - Volume: How much data per hour/day? - Modalities: Camera, lidar, telemetry mix? - Retention: How long must data be accessible? 2. **Evaluate infrastructure constraints.** - Edge resources: Processing power and storage limits - Connectivity: Bandwidth availability and reliability - Cloud requirements: Multi-region, compliance needs 3. **Consider team requirements.** - ROS dependency: Native vs. custom integration acceptable? - Visualization needs: Real-time monitoring vs. post-analysis - Development velocity: Time-to-insight requirements ### Decision matrix. | Your situation | Recommended tool | Why | | -------------------------------------- | ---------------- | ---------------------------------------------------------------------- | | ROS-based robotics system | Foxglove | Native integration, comprehensive features, proven at scale | | Need complete data management solution | Foxglove | Only tool providing end-to-end workflow from capture to analysis | | High-volume edge storage challenges | Foxglove | Use Foxlet for edge buffering and low latency environments | | 3D visualization primary need | Foxglove | Foxglove provides both advanced data visualization and data management | | Large fleet with bandwidth constraints | Heex | Event-driven capture minimizes data transfer | | Starting new robotics project | Foxglove | Fastest time-to-value, grows with your needs | For Physical AI and robotics teams, Foxglove represents the optimal choice. It's the only solution purpose-built for multimodal data (robotics and Physical AI data) that provides comprehensive data management, native integrations, powerful visualization and advanced debugging in a single platform. ## Implementation best practices when building your own solution. ### 1\. Data architecture planning. Design for scale from day one: `Edge Device → Local Buffer → Conditional Upload → Cloud Storage ↓ ↓ ↓ ↓ Real-time Short-term Smart Sync Long-term Monitoring Cache (Events/All) Analytics` Retention strategy: - Hot data (0-7 days): Local SSD, immediate access - Warm data (7-90 days): Cloud standard storage - Cold data (90+ days): Archive tier, compliance retention ### 2\. Performance optimization Edge device configuration: - Implement rolling file creation (1-5 minute segments). - Use compression for bandwidth-limited environments. - Monitor storage usage with automated cleanup. Cloud integration: - Batch uploads during off-peak hours. - Use incremental sync to minimize transfer overhead. - Implement retry logic for unreliable connections. ### 3\. Security & compliance. Data protection: - Encrypt data in transit and at rest. - Implement role-based access controls. - Maintain audit logs for regulatory compliance. Privacy considerations: - Anonymize or blur personally identifiable information. - Implement data retention limits per regulatory requirements. - Provide data deletion capabilities for user requests. ## Frequently asked questions Q: Can I use multiple data management tools for robotics together? A: Yes, many teams use complementary tools. However, Foxglove's comprehensive feature set eliminates the need for additional tools, reducing complexity and costs. Q: How much do these data management tools for robotics cost? A: Foxglove offers transparent pricing based on data volume and features. Open-source options like Rerun are free but require significant development effort for production use. Q: Which tool works best with ROS 2? A: Foxglove offers the most mature and comprehensive ROS 2 integration, supporting all major ROS 2 features out of the box. ## Conclusion Selecting the right data management tools for multimodal data is a foundational decision that impacts development velocity, operational reliability, and long-term scalability. After comprehensive analysis of features, performance, and real-world deployments, Foxglove + MCAP emerges as the clear leader for multimodal data management. While specialized tools serve specific niches, Foxglove is the only solution that delivers complete, integrated data management specifically designed for Physical AI. The Physical AI and robotics industry continues to evolve rapidly, and your data management strategy must evolve with it. Choose a solution that not only meets today's needs but can scale with your ambitions--choose Foxglove. _Ready to implement data management tools for robotics in your organization? Start with_ [_Foxglove's free tier_](https://app.foxglove.dev/signup) _to experience the difference purpose-built multimodal data management can make._ --- ### Foxglove SDK: A comprehensive quick start tutorial. URL: https://foxglove.dev/robotics/foxglove-sdk-a-comprehensive-quick-start-tutorial This tutorial provides a detailed overview of the Foxglove SDK, enabling efficient understanding and utilization for both theoretical and practical... This tutorial provides a detailed overview of the Foxglove SDK, enabling efficient understanding and utilization for both theoretical and practical applications. ## **Overview.** The Foxglove SDK facilitates: - **Live Data Streaming**: Real-time visualization of robot data in the Foxglove app. - **Data Logging**: Recording data to MCAP files for offline analysis. Available in **C++**, **Python**, and **Rust**, the SDK is open-source under the MIT license. ## **Core concepts.** ### **Messages** A **message** is a single timestamped log entry, which can be sent to the Foxglove app or written to an MCAP file. ### **Schemas** A **schema** describes the structure of a message's contents. Foxglove defines several schemas with visualization support, and users can define custom schemas using supported encodings. ### **Channels** A **channel** provides a way to log related messages sharing the same schema. Each channel is identified by a unique topic name. For Foxglove schemas, the SDK offers type-safe channels for logging messages with a known, matching schema (not yet supported in C++). ### **Sinks** A **sink** is a destination for logged messages, such as a WebSocket client or an MCAP writer. Without a configured sink, log messages are dropped. Multiple sinks can be configured and managed dynamically at runtime. ### **MCAP** **MCAP** is a container file format for multimodal log data, supported by Foxglove. ## **Installation.** ### **Rust** Install via [crates.io](https://crates.io/crates/foxglove): ```bash cargo add foxglove ``` ### **Python** Install via [PyPI](https://pypi.org/project/foxglove-sdk): ```bash pip install foxglove-sdk ``` ### **C++** The C++ SDK is a wrapper around a C library. To build it: 1. Download the library, source, and header files from the [SDK release assets](https://github.com/foxglove/foxglove-sdk/releases). 2. Link the library and compile the SDK source as part of your build process. 3. Ensure your project uses C++17 or newer. ## **Quickstart example.** This example demonstrates logging to an MCAP file and streaming to the Foxglove app using the SDK. ### **Python** ```python import math import time import foxglove from foxglove import Channel from foxglove.channels import SceneUpdateChannel from foxglove.schemas import ( Color, CubePrimitive, SceneEntity, SceneUpdate, Vector3, ) foxglove.set_log_level("DEBUG") # Our example logs data on a couple of different topics, so we'll create a # channel for each. We can use a channel like SceneUpdateChannel to log # Foxglove schemas, or a generic Channel to log custom data. scene_channel = SceneUpdateChannel("/scene") size_channel = Channel("/size", message_encoding="json") # We'll log to both an MCAP file, and to a running Foxglove app via a server. file_name = "quickstart-python.mcap" writer = foxglove.open_mcap(file_name) server = foxglove.start_server() while True: size = abs(math.sin(time.time())) + 1 # Log messages on both channels until interrupted. By default, each message # is stamped with the current time. size_channel.log({"size": size}) scene_channel.log( SceneUpdate( entities=[ SceneEntity( cubes=[ CubePrimitive( size=Vector3(x=size, y=size, z=size), color=Color(r=1.0, g=0, b=0, a=1.0), ) ], ), ] ) ) time.sleep(0.033) ``` ### **Rust** ```rust use std::ops::Add; use std::sync::atomic::{AtomicBool, Ordering}; use std::sync::Arc; use std::time::SystemTime; use foxglove::schemas::{Color, CubePrimitive, SceneEntity, SceneUpdate, Vector3}; use foxglove::{LazyChannel, LazyRawChannel, McapWriter}; const FILE_NAME: &str = "quickstart-rust.mcap"; // Our example logs data on a couple of different topics, so we'll create a // channel for each. We can use a channel like Channel to log // Foxglove schemas, or a generic RawChannel to log custom data. static SCENE: LazyChannel = LazyChannel::new("/scene"); static SIZE: LazyRawChannel = LazyRawChannel::new("/size", "json"); fn main() { let env = env_logger::Env::default().default_filter_or("debug"); env_logger::init_from_env(env); let done = Arc::new(AtomicBool::default()); ctrlc::set_handler({ let done = done.clone(); move || { done.store(true, Ordering::Relaxed); } }) .expect("Failed to set SIGINT handler"); // We'll log to both an MCAP file, and to a running Foxglove app via a server. let mcap = McapWriter::new() .create_new_buffered_file(FILE_NAME) .expect("Failed to start mcap writer"); // Start a server to communicate with the Foxglove app. This will run indefinitely, even if // references are dropped. foxglove::WebSocketServer::new() .start_blocking() .expect("Server failed to start"); while !done.load(Ordering::Relaxed) { let size = SystemTime::now() .duration_since(std::time::UNIX_EPOCH) .unwrap() .as_secs_f64() .sin() .abs() .add(1.0); // Log messages on the channel until interrupted. By default, each message // is stamped with the current time. SIZE.log(format!("{{\"size\": {size}}}").as_bytes()); SCENE.log(&SceneUpdate { deletions: vec![], entities: vec![SceneEntity { id: "box".to_string(), cubes: vec![CubePrimitive { size: Some(Vector3 { x: size, y: size, z: size, }), color: Some(Color { r: 1.0, g: 0.0, b: 0.0, a: 1.0, }), ..Default::default() }], ..Default::default() }], }); std::thread::sleep(std::time::Duration::from_millis(33)); } mcap.close().expect("Failed to close mcap writer"); } ``` ### **C++** ```cpp #include #include #include #include #include #include #include #include #include using namespace std::chrono_literals; // This example logs custom data on an "example" topic. Open Foxglove and connect to the running // server. Then add a Raw Message panel, and choose the "example" topic. int main(int argc, const char* argv[]) { static std::function sigintHandler; std::signal(SIGINT, [](int) { if (sigintHandler) { sigintHandler(); } }); // We'll log to both an MCAP file, and to a running Foxglove app. foxglove::McapWriterOptions mcap_options = {}; mcap_options.path = "quickstart-cpp.mcap"; auto writerResult = foxglove::McapWriter::create(mcap_options); if (!writerResult.has_value()) { std::cerr << "Failed to create writer: " << foxglove::strerror(writerResult.error()) << '\n'; return 1; } auto writer = std::move(writerResult.value()); // Start a server to communicate with the Foxglove app. foxglove::WebSocketServerOptions ws_options; ws_options.host = "127.0.0.1"; ws_options.port = 8765; auto serverResult = foxglove::WebSocketServer::create(std::move(ws_options)); if (!serverResult.has_value()) { std::cerr << "Failed to create server: " << foxglove::strerror(serverResult.error()) << '\n'; return 1; } auto server = std::move(serverResult.value()); std::cerr << "Server listening on port " << server.port() << '\n'; std::atomic_bool done = false; sigintHandler = [&] { done = true; }; // Our example logs custom data on an "example" topic, so we'll create a channel for that. foxglove::Schema schema; schema.encoding = "jsonschema"; std::string schemaData = R"({ "type": "object", "properties": { "val": { "type": "number" } } })"; schema.data = reinterpret_cast(schemaData.data()); schema.dataLen = schemaData.size(); auto channelResult = foxglove::Channel::create("example", "json", std::move(schema)); if (!channelResult.has_value()) { std::cerr << "Failed to create channel: " << foxglove::strerror(channelResult.error()) << '\n'; return 1; } auto channel = std::move(channelResult.value()); while (!done) { // Log messages on the channel until interrupted. By default, each message // is stamped with the current time. std::this_thread::sleep_for(33ms); auto now = std::chrono::system_clock::now().time_since_epoch().count(); std::string msg = "{\"val\": " + std::to_string(now) + "}"; channel.log(reinterpret_cast(msg.data()), msg.size()); } return 0; } ``` The C++ example follows a similar structure, utilizing the SDK's C++ API to log data and stream to the Foxglove app. ## **Visualization in Foxglove App.** To view the live visualization: 1. Open the [Foxglove app](https://app.foxglove.dev/). 2. Click **"Open connection..."** and establish a WebSocket connection with the default URL. 3. Add a **3D panel** to your layout. 4. Subscribe to the /scene topic by toggling its visibility in the panel settings sidebar. ## **Custom schemas.** Foxglove supports defining custom schemas using various encodings: - **Protobuf** - **JSON Schema** - **FlatBuffers** - **ROS 1/2** - **OMG IDL** For Protobuf, include the .proto files in your project and use them to publish data via a live Foxglove WebSocket connection or log to an MCAP file. ## **Additional resources.** - [Foxglove SDK Documentation](https://docs.foxglove.dev/docs/sdk) - [Foxglove Schemas](https://docs.foxglove.dev/docs/sdk/schemas) - [MCAP File Format](https://mcap.dev) --- ### What is PX4 ULog? URL: https://foxglove.dev/robotics/px4-ulog PX4 ULog is a robust, extensible log file format used by the PX4 autopilot system to record flight data from unmanned aerial vehicles (drones). Designed with... **PX4 ULog** is a robust, extensible log file format used by the PX4 autopilot system to record flight data from unmanned aerial vehicles (drones). Designed with performance and analysis in mind, ULog captures high-frequency data streams such as sensor readings, estimator states, actuator outputs, and control loop timings in a binary format. The ULog format is tailored for embedded systems, allowing real-time logging with minimal overhead. It supports features like message buffering, variable-length messages, and multi-topic logging. ULog files typically have a .ulg extension and can be analyzed post-flight to assess vehicle performance, identify anomalies, and optimize algorithms. At its core, ULog helps PX4 developers and users understand what their robot or drone was doing at any given moment during operation. ## **How is PX4 ULog used in robotics?** In the robotics domain, **ULog files are critical for debugging, validation, and performance tuning**. They provide detailed insights into the inner workings of a robot's flight controller and subsystems. Here are some key use cases: **1\. Flight analysis and debugging.** PX4 ULog logs raw and processed sensor data, estimator inputs/outputs, control setpoints, and actuator commands. Engineers use this data to troubleshoot issues like unstable flight, GPS loss, or erratic behavior. Comparing logs across multiple flights helps pinpoint systemic issues or hardware failures. **2\. System identification and tuning.** ULog's high-frequency sampling enables system identification for model-based control design and PID tuning. Developers analyze logs to characterize system dynamics and improve control strategies. **3\. Autonomy development.** For autonomous navigation and perception stacks, ULog files record the state estimator's output (e.g., pose, velocity) alongside perception data. This time-synchronized data is essential for developing and validating algorithms in areas like SLAM, obstacle avoidance, and mission planning. **4\. Data-driven machine learning.** ULog's structured format is ideal for feeding large-scale datasets into machine learning models. Robotics engineers export features from logs to train models for tasks like failure prediction, terrain classification, or adaptive control. **5\. Post-flight review and compliance.** In regulated environments (e.g., drone delivery or inspection), ULog serves as a flight record for compliance verification and performance reporting. Here's an overview of the data types commonly found in a ULog file: | Data type | Description | Example topics | | ---------------- | ------------------------------------------------- | ------------------------------------------- | | Sensor data | Raw IMU, GPS, barometer, etc. | sensor_combined, gps_position | | Estimator output | State estimates like position, velocity, attitude | vehicle_local_position, estimator_status | | Control signals | Setpoints and actuator commands | vehicle_attitude_setpoint, actuator_outputs | | System metrics | CPU load, memory usage, error codes | system_resource, logger_status | ## **Use PX4 ULog with Foxglove.** Foxglove provides a powerful visualization and debugging platform that seamlessly supports PX4 ULog data. By integrating ULog with Foxglove, robotics teams can visualize flight logs, gain deeper insights, and collaborate effectively. ### **How to use PX4 ULog in Foxglove.** 1. **Export ULog from PX4.** 1. After a flight, download the .ulg file from your flight controller using QGroundControl or via SD card. 2. **Convert to ROS-compatible format (optional).** 1. If desired, use ulog2rosbag to convert the log into a ROS bag for integration with other tools in your robotics pipeline. 3. **Open in Foxglove.** 1. Drag and drop the .ulg file into the Foxglove interface or upload it via the data panel. Foxglove will parse and display all time-synchronized topics automatically. 4. **Visualize data.** 1. Use built-in panels like Plot, Image, 3D View, and Raw Messages to inspect signal trends, inertial navigation data, control commands, and more. 2. Leverage the 3D viewer to replay flight trajectories, visualize poses, and detect anomalies spatially. 5. **Inspect and correlate.** 1. Align log data with onboard video, map overlays, or point cloud streams for a holistic view of the robot's operation. 2. Correlate estimator errors with sensor drifts or latency issues. ### **Benefits of using PX4 ULog with Foxglove.** - **Unified visualization**: Aggregate telemetry, camera, and sensor data in one view. - **Time-synchronized insights**: Correlate control signals and state estimates for root-cause analysis. - **Interactive debugging**: Use time scrubbers, bookmarks, and metric overlays to pinpoint failures. - **Collaboration-ready**: Share annotated logs across teams or stakeholders for faster decision-making. - **Flexible integration**: Use alongside ROS or standalone, supporting both research and production workflows. By combining the depth of PX4 ULog logs with the clarity of Foxglove's visualization tools, robotics teams can rapidly iterate, deploy safer systems, and unlock greater insights from their flight data. --- ### Rerun vs. Foxglove: A practical guide for modern robotics development. URL: https://foxglove.dev/robotics/rerun-vs-foxglove Compare Foxglove and Rerun--SDKs, MCAP, live + recorded data, collaboration, and when teams choose Foxglove. This post lays out a technical comparison between Rerun and Foxglove, and explains when and [why serious robotics and Physical AI teams choose Foxglove](/why-foxglove). ## **Tl;dr** - Both tools have modern C++/Python/Rust SDKs and strong local visualization. Rerun is code-first; Foxglove is a full platform + SDK for live streams, recorded data, organization-wide search, collaboration, and fleet operations. - [MCAP](/product/mcap) is first-class in Foxglove (record, ingest, index, stream, and export). MCAP support is explicitly marked _early/experimental_ within Rerun thus limited capability. - Why teams standardize on Foxglove: one place for live + recorded data, rich collaboration and data organization ([Devices](https://docs.foxglove.dev/docs/data/devices), [Events](https://docs.foxglove.dev/docs/data/events), [Timeline](https://docs.foxglove.dev/docs/data/exporting-data#download-time-range)), data management ([Projects](https://docs.foxglove.dev/docs/projects), [Foxlet](https://docs.foxglove.dev/docs/fleet/foxlet), [Primary Sites](https://docs.foxglove.dev/docs/data/primary-sites)), API/CLI, SSO, embeddable views and extensibility, and [enterprise data governance](/security) (SOC 2 Type II, GDPR, data encryption, identity management). ## Quick comparison at a glance. | Category | Foxglove | Rerun | | ----------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | SDKs | C++/Python/Rust SDK to log/stream to MCAP or Foxglove | C++/Python/Rust SDK to log & open in the Rerun viewer | | Files & formats | Open ROS 1 `.bag`, ROS 2 `.db3`/`.mcap`, native `.mcap`; merge multiple files into one timeline | Open `.mcap` directly; optional `mcap → .rrd` conversion for faster loading | | Live ROS | Recommended _foxglove_bridge_ for ROS 1/2 over WebSocket | "Use Rerun with ROS 2" via SDK/logging or MCAP layers | | Viewer & viz | Desktop & web app with 3D, Maps, Timeseries, etc.; shareable layouts; extensible Extensions | Native & web Rerun viewer; Blueprint configs; Web embed; memory-limit controls | | Team workflows | Devices, Events, and Timeline for curation and reviews; data import/export; SOC 2 Type II | OSS-centric workflows; DataFrame view & export to Arrow/pandas/Polars | | Data ingest & ops | Foxlet for on-device capture; Edge Sites for on-prem buffering & cloud sync | Code-first logging; evolving data-in/data-out story via MCAP & RRD | ## **One place for live + recorded data.** **Live & recorded in one workflow:** The [Foxglove SDK](https://docs.foxglove.dev/docs/sdk) streams live robot data to the app and logs the same data to MCAP for later analysis--no context switch. Your team can drag local logs in, open remote files by URL, or query time ranges from your organization's recordings. **Why MCAP matters for robotics:** MCAP is an _open, serialization-agnostic_ container for timestamped pub/sub data (ROS, Protobuf, JSON, FlatBuffers, ...) with chunking, indices, and optional compression (LZ4/Zstd) for fast seek/scan. It's the default rosbag2 format in ROS 2 Iron and NVIDIA Isaac SIM, so logs are portable across tools, teams, and time. **Multi-file, merged timelines:** Foxglove [plays multiple files](https://docs.foxglove.dev/changelog/foxglove/v2.17.0#%EF%B8%8F-multi-file-playback) as one synchronized timeline (same format), which makes cross-sensor / cross-robot investigations practical. This works for local playback and mirrors how Foxglove merges recordings in the platform. **Data management at scale:** In the platform, Foxglove indexes your recordings by device, time, and topic, streams them on demand, and lets you export selective ranges as .mcap or .bag. Teams add Events (bookmarks with metadata) to anchor reviews and share links. **Embed where your team works:** Product & ops dashboards often need rich playback without leaving your app. Foxglove visualization panels are full extensible for custom views via TypeScript and React. You can also embed an iframe viewer for the layouts your ops teams need most. ## **One place to manage data.** Enterprises organize robots and logs into Projects so only the right people see the right data, with org-level controls (API keys, SSO, extensions). Foxlet watches a storage directory and auto-registers/uploads recordings; you can match which ones to import automatically, and also enables live Teleoperation. Primary Sites (cloud or self-hosted) index in place on your infra/Kubernetes. Only metadata leaves your network when fully self-managed--message contents stay in your environment. The query service merges objects and streams results efficiently. Use the [Foxglove API](https://docs.foxglove.dev/api) to import, search, label, and fetch; use [webhooks](https://docs.foxglove.dev/docs/webhooks) to automate downstream processing. Export slices as MCAP/ROS bag when needed. Enterprise controls enable you to enforce SSO (Google/Microsoft/OIDC) and use Roles to scope who can manage API keys, Sites, and more. ## **Foxglove SDK: when and how teams use it.** **Languages & licensing:** C++, Python, and Rust under MIT. One SDK to stream live to Foxglove _and_ log MCAP for durable records. **Recommended patterns:** - **During R&D**: stream live while logging to MCAP; reviewers open the same session later with a shared layout. - **In field ops**: run Foxlet to auto-ingest logs; tag them by Device and annotate with Events so incidents are discoverable. - **For proprietary stacks**: keep your own serialization; Foxglove is schema-agnostic, and you can add extensions or embed the viewer in internal tools. ## **Direct SDK comparison: Foxglove SDK vs Rerun SDK.** | Capability | Foxglove SDK | Rerun SDK / Rerun viewer | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | Languages & license | C++ / Python / Rust MIT | C++ / Python / Rust (open-source core) | | Core model | One SDK for **live streaming** to Foxglove and **recording** to **MCAP** (schema-aware, indexed) | **Entity-Component** logging to the **Rerun viewer** (live) or to **.rrd** files; can also open **MCAP** | | Live connectivity | Local **WebSocket** server integrates with your app; Foxglove connects for low-friction live reviews | `spawn` / `connect_grpc` / `serve_grpc` modes attach to a native or web viewer | | File formats | First-class **MCAP** across app & platform; also reads ROS 1 **.bag** and ROS 2 **.db3** | **Open MCAP** directly; optional **MCAP → RRD** conversion for performance | | ROS path | Works naturally with **MCAP** (ROS 2 default in Iron) and ROS 1 **.bag**; live via _foxglove_bridge_ or SDK | Use SDK logging with ROS 2 or record to MCAP and open/convert in the viewer | | Data-out | Export **.mcap** / **.bag** ranges or full runs; platform APIs & Python client for automation | **Dataframe** view and export to Arrow / pandas / Polars | | Embedding | Official **@foxglove/embed** & **@foxglove/embed-react** to control an **iframe** viewer (layouts, sources, extensions) | Embed the **Rerun viewer** via iframe or use **@rerun-io/web-viewer** (npm) | | Memory / scaling model | Platform streams on demand (server-side indexing); Primary/Edge Sites keep data close to where it's produced | Viewer bounded by RAM; defaults to ~**75%** usage and drops oldest data when over limit (configurable) | | Best fit | Teams standardizing on **MCAP** who need **live + recorded** in one place, with ingestion (Foxlet/Edge) and org features | Code-first users wiring up **Rerun viz** with ECS logging, DataFrames, and optional MCAP→RRD conversion | ## **Where and why teams choose Foxglove.** 1. **One place for live + recorded data (with MCAP depth).** - Stream via SDK, log to MCAP, and play everything back with [shared layouts](https://docs.foxglove.dev/docs/visualization/layouts). Open local logs, open by URL, or stream from the platform. - MCAP gives you portable, indexed, compressed logs across ROS/proprietary stacks and across years. - Merge multiple files into a single timeline to debug multi-robot incidents. - Need to bring the review to your app? [Embed Foxglove](https://docs.foxglove.dev/docs/embed) via **@foxglove/embed** (iframe with programmatic control). 2. **Team workflows built-in.** 3. **Devices** label what produced the data; **Events** bookmark moments and metadata; the **Timeline** makes big corpora navigable. Share deep links and layouts so every review looks the same. 4. **Data management and scale.** 5. **Foxlet** automates upload; **Primary Sites** manage throughput and data sovereignty; **Projects** lock down access; **API/Webhooks** automate the pipeline; **exports** give you MCAP/.bag slices for external tools. _A respectful note on Rerun:_ Rerun is developer-friendly, and its MCAP support (experimental) plus web viewer make it good for bespoke local pipelines and notebook workflows. ## **Migration quick-start (Rerun → Foxglove).** 1. **Open your MCAP** (or .bag) in Foxglove; for large analyses, import and stream from the platform. 2. **Adopt the SDK** where you need live streams and unified MCAP logging. 3. **Automate ingest** with Foxlet; organize by Device; add Events as you triage. 4. **Embed** a Foxglove view in your internal dashboard so non-engineers can self-serve. ## **Business and GTM snapshot (brief).** - **Foxglove** offers Free, Pro, and Enterprise with SSO and self-host options (Projects, Sites) for regulated or data-sensitive teams. - **Rerun** is an open-source viewer + SDK; recent releases emphasize MCAP workflows and web embedding. ## **FAQs** Q: Does Rerun open MCAP files? A: Yes--Rerun has built-in MCAP support and can also convert MCAP → RRD for performance. The docs describe MCAP support as early/experimental (active development). Q: What's the simplest way to get ROS 2 data into Foxglove? A: Record to MCAP (ROS 2 Iron default) and open it in Foxglove; or stream live via the Foxglove SDK's WebSocket server. Q: Can Foxglove handle multiple files at once? A: Yes--Foxglove merges multiple files of the same format into a single timeline. Q: How do the SDKs differ at a high level? A: Both offer C++/Python/Rust. Foxglove focuses on streaming + MCAP logging for a collaborative platform; Rerun emphasizes viewer-centric logging and can load/convert MCAP. ### Closing thought. If your team wants one system for live streams, recorded logs, organization-wide search, collaboration, data organization, and embeddable views--without giving up code-first ergonomics--Foxglove is the faster path to consistent, repeatable, and reliable results. Start with MCAP, add the SDK, and let Foxlet handle the heavy lifting. [Get a demo](/demo) today from one of our technical staff or [get started](https://app.foxglove.dev/signup) to try it out for yourself. --- ### The definitive guide to choosing robotics visualization platforms. URL: https://foxglove.dev/robotics/robotics-visualization-platforms-choosing-2025 Choosing the right robotics visualization platform is essential for effectively developing, debugging, and deploying robotic systems, as it directly influences... Choosing the right robotics visualization platform is essential for effectively developing, debugging, and deploying robotic systems, as it directly influences productivity, debugging capabilities, and project success. The ideal platform should handle real-time data streams, provide intuitive interfaces for all stakeholders, and scale with project complexity. This guide examines key considerations, compares leading solutions, and offers actionable insights for informed decision-making. ## Understanding robotics visualization requirements. ### Real-time data processing needs. Robotic systems generate continuous streams of sensor data, including LiDAR point clouds, camera feeds, IMU readings, and GPS coordinates. Your visualization platform must process these data streams without latency that could affect performance. Real-time processing capabilities are crucial for applications like autonomous navigation, where even millisecond delays can compromise safety. Consider your specific application's data throughput needs. Industrial robots may produce moderate data volumes, while autonomous vehicles can generate terabytes daily. The platform should maintain smooth visualization performance during peak loads. ### Multi-sensor data integration. Robotics systems typically include multiple sensor types that need cohesive visualization. Your platform should support: - **3D spatial data** from LiDAR, stereo cameras, and depth sensors. - **Time-series data** from IMUs, encoders, and environmental sensors. - **Image and video streams** from various camera systems. - **Network and system metrics** for performance monitoring. The ability to correlate and synchronize data from different sensors in a unified view is critical for understanding system behavior and identifying issues. ### Scalability and performance considerations. As robotics projects evolve, visualization requirements may expand. A platform that suits a single robot prototype may struggle with fleet management or increased sensor complexity. Evaluate platforms based on their ability to: - Handle increasing data volumes without performance degradation. - Support multiple concurrent users and viewing sessions. - Maintain responsiveness across hardware configurations. - Provide efficient data storage and retrieval mechanisms. ## Key features to evaluate. ### Data format compatibility Robotics frameworks and sensors produce data in various formats. Your visualization platform should natively support common robotics formats, including: FormatUse CaseCompatibility ImportanceROS bagsROS-based systemsCritical for ROS workflowsMCAPModern data loggingGrowing adoption, future-proofCSV/JSONGeneral telemetryUniversal compatibilityPoint clouds (PCD, PLY)3D sensor dataEssential for spatial visualizationVideo formats (MP4, AVI)Camera systemsStandard multimedia support Platforms with broad format support minimize data conversion needs, enabling faster iteration cycles. Foxglove supports ROS 1, ROS 2, MCAP, JSON, Protobuf, and more aligning with modern workflows. ### User interface and experience. The visualization interface affects team productivity and collaboration. Look for platforms offering: - **Intuitive drag-and-drop interfaces** for creating custom dashboards. - **Responsive design** for desktop and mobile devices. - **Customizable layouts** for different user roles and preferences. - **Collaborative features** for sharing insights and annotations. A well-designed interface reduces the learning curve, allowing both technical and non-technical members to leverage robotics data. ### Customization and extensibility. Robotics applications may require specialized visualization components or unique workflows. Evaluate platforms based on their: - **Plugin architecture** for custom visualizations and data processors. - **API accessibility** for integration with existing tools. - **Theming and branding options** for presentations. - **Export capabilities** for generating reports and documentation. Extensibility ensures the platform adapts to your unique requirements and integrates with your ecosystem. ## Popular robotics visualization platforms. ### Foxglove [Foxglove](/) is designed for robotics workflows, providing a responsive, collaborative environment across operating systems and form factors. **Key Strengths:** - Native support for ROS 1, ROS 2, MCAP, JSON, Protobuf formats. - Real-time and recorded data visualization in a unified interface. - Extensible architecture with custom panel development. - Cloud-based collaboration features for distributed teams. - Intuitive interface for both technical and business users. Foxglove unifies live and historical data for rapid, insight-driven debugging. **Best For:** Teams needing modern collaboration features, multi-format support, and scalable solutions. ### RViz RViz is the standard visualization tool within the ROS ecosystem, deeply integrated with ROS topics and services. [RViz2](https://docs.ros.org/en/ros2_packages/rolling/api/rviz2/doc/index.html) extends this functionality to ROS 2 with improved performance. **Key Strengths:** - Seamless ROS integration with native topic subscription. - Extensive plugin ecosystem for specialized visualizations. - Mature platform with strong community support. - Efficient handling of 3D spatial data and robot models. **Best For:** ROS-centric workflows requiring tight integration and extensive 3D visualization. ### Plotly and Dash [Plotly](https://plotly.com/python/) and [Dash](https://dash.plotly.com/) offer powerful web-based visualization with strong Python integration, popular for data science-oriented robotics teams. **Key Strengths:** - Extensive charting capabilities. - Interactive web-based dashboards. - Strong Python ecosystem integration. - Customizable and programmable components. **Best For:** Teams with Python expertise needing custom analytical dashboards. ### Custom solutions and considerations. Some organizations develop custom visualization solutions tailored to specific needs. This approach offers flexibility but has associated development and maintenance costs. Custom solutions may be justified when: - Existing platforms can't handle unique data formats. - Integration with proprietary systems is necessary. - Performance requirements exceed commercial solutions. - Long-term control over the visualization stack is essential. ## Integration with robotics frameworks. ### ROS integration capabilities. For ROS-based systems, seamless integration with robotics middleware is crucial. Evaluate platforms based on: - **Topic subscription and publishing** for real-time data access. - **Service and action integration** for interactive debugging. - **Parameter server connectivity** for configuration management. - **Transform tree visualization** for understanding kinematics. Platforms with native ROS support reduce complexity and eliminate the need for custom bridging code. ### Non-ROS framework support. Not all robotics projects use ROS. Consider platforms that support: - **Direct sensor APIs** for hardware integration. - **Custom protocol handlers** for proprietary systems. - **Database connectivity** for historical analysis. - **REST and WebSocket APIs** for modern architectures. Broad framework support ensures your visualization platform adapts as your stack evolves. ## Performance and scalability analysis. ### Hardware Requirements Different visualization platforms have varying hardware requirements: Platform TypeCPU RequirementsMemory UsageGPU AccelerationWeb-basedModerateLow-ModerateOptionalNative desktopHighHighOften requiredCloud-hostedMinimal localMinimal localServer-side Consider your team's hardware constraints and whether cloud solutions offer better resource utilization. ### Network performance impact. Real-time visualization often involves streaming large data volumes. Evaluate platforms based on: - **Data compression capabilities** to reduce bandwidth demands. - **Adaptive streaming quality** adjusting to network conditions. - **Offline capabilities** for intermittent connectivity. - **Edge computing support** to reduce latency in distributed systems. Network efficiency is critical in field deployments and remote monitoring. ## Cost considerations and ROI. ### Licensing Models Visualization platforms use various licensing approaches: - **Open source solutions** offer cost advantages up front but require more development resources that distract from core differentiation and project missions. - **Commercial licenses** provide support but involve ongoing costs. - **Usage-based pricing** scales with project size but can become costly. - **Enterprise agreements** provide volume discounts for large organizations. ### Total cost of ownership. Beyond licensing costs, consider: - **Implementation and integration costs** for customization. - **Training and onboarding expenses** for team members. - **Ongoing maintenance and support** needs. - **Infrastructure costs** for hosting and computing resources. A thorough ROI analysis should include productivity gains, reduced debugging time, and improved collaboration. ## Security and compliance requirements. ### Data protection capabilities Robotics data often contains sensitive information requiring security measures: - **Encryption in transit and at rest** for sensitive data. - **Access control and authentication** to restrict visibility. - **Audit logging** for compliance monitoring. - **Data retention policies** for storage management. ### Industry-specific compliance Different industries have specific compliance requirements: - **Automotive:** ISO 26262 functional safety standards. - **Healthcare:** HIPAA compliance for medical robotics. - **Aerospace:** ITAR restrictions for defense applications. - **Manufacturing:** Industry 4.0 security frameworks. Ensure your chosen platform meets relevant compliance requirements. ## Making the final decision. ### Evaluation framework Develop a systematic approach to evaluation: - **Define requirements** based on your use case. - **Create evaluation criteria** with weighted scores. - **Conduct proof-of-concept testing** with real data. - **Assess total cost of ownership** including hidden costs. - **Evaluate vendor stability** and long-term viability. ### Implementation planning Once a platform is selected, plan the implementation: - **Pilot deployment** with a subset of users. - **Training program** for team members. - **Migration strategy** for existing data. - **Success metrics** to measure effectiveness. A phased approach reduces risk and allows for adjustments. ## FAQ ### What's the difference between real-time and historical data visualization in robotics? Real-time visualization displays live data from active robotic systems for monitoring and debugging, while historical visualization analyzes recorded data for pattern identification and performance optimization. Modern platforms like Foxglove combine both capabilities. ### How important is cloud compatibility for robotics visualization platforms? Cloud compatibility is increasingly important for enabling distributed collaboration, scalable resources, and centralized data management. However, consider latency and data security when evaluating cloud solutions. ### Can I use multiple visualization platforms simultaneously? Yes, many teams use complementary platforms for different purposes, ensuring data compatibility and avoiding workflow fragmentation. Integration capabilities can facilitate data sharing between tools. ### What should I do if my robotics data formats aren't supported by standard platforms? Most platforms offer extensibility options like custom plugins or API integrations. Foxglove provides custom panel development and data source plugins. Alternatively, implement preprocessing pipelines to convert proprietary formats into standard formats. ### How do I evaluate visualization platform performance with my specific data? Conduct proof-of-concept testing using representative data samples, considering realistic data volumes, concurrent users, and network conditions. Key metrics include rendering frame rates, processing latency, memory usage, and interface responsiveness. ### What's the learning curve like for different robotics visualization platforms? Learning curves vary significantly; web-based platforms like Foxglove typically have gentler curves, while specialized tools like RViz may require deeper knowledge. Factor in training time and consider platforms with comprehensive documentation and community support. --- ### What is Robotic Operating System (ROS)? URL: https://foxglove.dev/robotics/ros The Robot Operating System (ROS) is an open-source framework for writing robot software. It provides a structured communications layer above the host operating... The **Robot Operating System (ROS)** is an open-source framework for writing robot software. It provides a structured communications layer above the host operating systems of a heterogeneous compute cluster. Originally developed by Willow Garage in 2007, ROS has since become the de facto standard for robotics middleware, empowering developers with tools and libraries to build complex and scalable robot applications. Despite its name, ROS is not a traditional operating system. Instead, it offers a flexible and distributed architecture composed of: - **Nodes**: Independent processes that perform computation. - **Topics**: A publish/subscribe messaging mechanism for nodes. - **Services**: Synchronous communication between nodes. - **Actions**: Asynchronous task management. - **Bags**: File format for recording and playing back ROS message data. Two major versions exist--**ROS 1** and **ROS 2**. While ROS 1 focused on rapid prototyping and single-machine development, ROS 2 is designed for real-time performance, security, and multi-robot systems with DDS (Data Distribution Service) as its communication middleware. ## **How is ROS used in robotics?** ROS is widely used across research and industry to power autonomous systems, from mobile robots to aerial drones and industrial manipulators. Here's how ROS supports robotic development: 1. **Sensor Integration**: ROS supports a wide array of sensors such as cameras, GPS, imu, and lidar. Drivers and packages allow easy integration and real-time data acquisition. 2. **Control and Planning**: With built-in support for kinematics, dynamics, and motion planning libraries like MoveIt, ROS enables the development of advanced robotic behaviors. 3. **Simulation**: Tools like Gazebo and Ignition allow developers to simulate complex environments and test robotic systems before deployment. 4. **Mapping and Navigation**: ROS provides robust SLAM (Simultaneous Localization and Mapping) and navigation stacks to enable autonomous movement and obstacle avoidance. 5. **Data Logging and Playback**: ROS's rosbag tool enables recording data during robot operation, which can later be played back for debugging and analysis. ## **Common ROS use cases in robotics.** | Use case | ROS tools involved | Description | | ---------------------- | --------------------------- | --------------------------------------------------------------------- | | Autonomous navigation | nav2, tf2, costmap_2d | Enables robots to plan paths and avoid obstacles in real-time. | | Robot arm manipulation | MoveIt, JointStatePublisher | Used for inverse kinematics, planning, and executing motion commands. | | Perception | image_pipeline, PCL, OpenCV | Processes sensor data to interpret and react to the environment. | | Swarm robotics | DDS, multi-master_fkie | Coordinates multiple robots operating collaboratively. | ## **Use ROS with Foxglove.** ### **Visualize ROS data in real time.** Foxglove is a powerful observability platform designed to work seamlessly with ROS-based systems. Whether you're using ROS 1 or ROS 2, Foxglove provides intuitive interfaces for visualizing your robot's real-time data. - **Topics viewer**: Monitor the health and throughput of your ROS topics. - **Message inspector**: Inspect the structure and contents of messages like sensor_msgs/Image or nav_msgs/Odometry. - **3D view**: Visualize tf trees, point clouds, and robot models in a unified, interactive 3D environment. ### **Load and analyze rosbag files.** Foxglove supports both live streaming and postmortem analysis using rosbag files. Developers can: - Upload .bag files to replay telemetry data. - Debug complex issues by scrubbing through time-stamped logs. - Compare multiple data streams from the same session in synced views. ### **Debug robotics systems faster.** With Foxglove, engineers get: - **Schema-aware decoding** of ROS messages. - **Custom panels** tailored to robot-specific diagnostics. - **Time-synchronized playback** of multiple sensor streams (camera, lidar, imu). This drastically shortens the feedback loop when debugging distributed robotic systems. ## **Benefits of using Foxglove with ROS.** - **Seamless ROS integration**: Native compatibility with ROS 1 and ROS 2. - **No-code visualization**: Out-of-the-box tools reduce the need for custom RViz plugins or dashboard UIs. - **Cross-platform support**: Run in browser or desktop app. - **Remote collaboration**: Share sessions and insights with distributed teams. The Robot Operating System is a foundational technology in modern robotics. By combining ROS's open ecosystem with Foxglove's observability and debugging tools, robotics teams can accelerate development, reduce downtime, and build smarter, more reliable robots. --- ### What is ROSBridge? URL: https://foxglove.dev/robotics/rosbridge Rosbridge is a protocol and set of tools that provide a JSON API to ROS (Robot Operating System). It enables non-ROS programs--such as web applications, mobile... **Rosbridge** is a protocol and set of tools that provide a JSON API to ROS (Robot Operating System). It enables non-ROS programs--such as web applications, mobile apps, or cloud-based systems--to interface with ROS using standard web technologies like WebSockets and JSON. Instead of relying on native ROS clients written in C++ or Python, developers can use rosbridge to exchange ROS messages, publish to topics, call services, and subscribe to data--all without needing to run ROS locally. The core of rosbridge is rosbridge_server, which acts as a WebSocket server that translates JSON messages into ROS commands and vice versa. This allows seamless integration of ROS with a wide variety of front-end and remote applications. The rosbridge protocol is part of the larger [rosbridge_suite](https://wiki.ros.org/rosbridge_suite), which includes additional tools like rosapi for system introspection. ## **How is rosbridge used in robotics?** In modern robotics systems, interoperability and visualization are key to development and monitoring workflows. **rosbridge** is often used to bridge the gap between ROS-based robots and user interfaces or applications that don't run on ROS. Here's how it's typically used in robotic applications: - **Remote monitoring and teleoperation**: By exposing ROS topics over a WebSocket connection, rosbridge allows browser-based tools or custom UIs to monitor telemetry, visualize sensor data, or control actuators without being on the same ROS network. - **Cross-platform applications**: rosbridge makes it possible to write control and visualization interfaces in JavaScript, enabling robots to be managed from tablets, mobile phones, or web dashboards. - **Cloud connectivity**: Robots deployed in the field can stream data back to cloud applications that process or visualize data remotely using the rosbridge API. - **Data visualization**: With access to sensor streams like camera feeds, IMU data, or lidar scans, developers can build dashboards that provide real-time insight into what a robot sees and experiences. Here's a breakdown of common rosbridge use cases: | Use case | Description | | -------------------------- | ---------------------------------------------------------------------------- | | Web-based visualization | Use WebSockets and JSON to view ROS topic data from browsers or web apps. | | Remote control | Send velocity or actuator commands to a robot from remote UIs. | | Cloud integration | Stream telemetry to cloud applications for monitoring or analytics. | | Cross-platform development | Build interfaces using JavaScript or mobile frameworks to interact with ROS. | ## **Use rosbridge with Foxglove.** **Foxglove** is a powerful tool for robotics data visualization and introspection. It supports connecting directly to ROS 1 and ROS 2 systems via rosbridge, making it easy to view live data streams or recorded bag files without running a local ROS environment. This is especially useful for developers who want to inspect messages, debug systems, or create dashboards. ### **How to connect rosbridge to Foxglove.** To connect Foxglove to a ROS system via rosbridge: 1\. **Install rosbridge**: `sudo apt install ros-${ROS_DISTRO}-rosbridge-server` 2\. **Launch the rosbridge server**: `roslaunch rosbridge_server rosbridge_websocket.launch` 3\. **Start Foxglove**: Open [Foxglove](https://foxglove.dev) in your browser. 4\. **Add a connection**: - Click **Add connection**. - Select **rosbridge WebSocket**. - Enter the WebSocket URL (e.g., ws://localhost:9090) and click **Connect**. - **Explore your data**: Use the built-in panels (like image, lidar, plots, or 3D) to inspect topic data in real time. ## **Benefits of using rosbridge with Foxglove.** - **Zero local ROS dependencies**: View and debug ROS data from anywhere using only a browser. - **Rich visualization**: Utilize lidar, image, and 3D panels to understand what your robot sees. - **Flexible integrations**: Whether you're connecting to a robot over LAN, VPN, or the internet, rosbridge allows Foxglove to hook in seamlessly. - **Cross-robot compatibility**: Foxglove supports both ROS 1 and ROS 2 through rosbridge, making it ideal for hybrid or transitioning systems. With its real-time capabilities and intuitive interface, Foxglove turns raw ROS topics into meaningful visualizations. Paired with rosbridge, it becomes a versatile tool for remote diagnostics, development, and monitoring in robotics applications. For a deeper walkthrough of setting up rosbridge in a ROS 2 project, check out [Using rosbridge with ROS 2](/blog/using-rosbridge-with-ros2). --- ### Best tools for rosbag visualization: A developer's guide. URL: https://foxglove.dev/robotics/the-best-tools-for-rosbag-visualization-in-2025 Discover tools for rosbag visualization. Learn how to use Foxglove, RViz, and other open-source options to view and analyze ROS bag files effectively. _Updated for 2026._ **Searching for the best way to visualize your ROSBAG files?** Whether you're debugging your robotics system, analyzing sensor data, or preparing datasets for machine learning, effective **rosbag visualization** is essential for understanding and improving your robot's performance. This guide covers the most powerful open-source tools available for viewing, analyzing, and working with .bag, .db3, and .mcap files in both ROS 1 and ROS 2 environments. ## **What is rosbag visualization?** **Rosbag visualization** refers to interpreting the contents of ROS bag files through graphical tools. Rather than examining raw serialized messages, these tools allow developers to: - Replay sensor data in sync - Inspect image and point cloud streams - Track TF transformations in 3D space - Monitor topic timing, frequency, and bandwidth - Plot time-series data for diagnostics Here are the best tools available to make that happen. ## **Best rosbag visualization tools.** ### **1\. Foxglove -- Modern rosbag viewer for ROS 1, ROS 2, and MCAP.** [Foxglove](https://foxglove.dev) is the most comprehensive and user-friendly rosbag visualization tool currently available. It supports both legacy and modern ROS ecosystems, including the newer [MCAP format](https://mcap.dev). Key features: - Native support for .bag, .db3, and .mcap - Works with both ROS 1 and ROS 2 data - Visualizes camera images, LiDAR point clouds, TFs, plots, logs, and more - Timeline-based playback with fine-grained control - Available as a desktop app or in-browser via WebSocket or drag-and-drop files - Integrates with live robotics systems or offline analysis Foxglove provides the most complete experience for inspecting and debugging robotics logs. ### **2\. rqt_bag -- GUI bag file viewer for ROS 1.** Included in the ROS 1 ecosystem, rqt_bag is a GUI-based viewer for .bag files. It allows users to: - Scrub through message timelines - Inspect individual messages by topic - Filter and play back selected subsets of data Limitations: - Only works with ROS 1 bags - No 3D or video rendering capabilities - Deprecated for ROS 2 While functional for legacy systems, most modern workflows have moved beyond rqt_bag. ### **3\. RViz / RViz2 -- 3D visualization with live playback.** While RViz isn't a standalone rosbag viewer, it's a crucial tool when used in combination with rosbag play. Capabilities: - Visualizes TF trees, point clouds, camera feeds, and robot models in 3D - Highly configurable with plugin support - Useful for SLAM, perception debugging, and sensor frame alignment To use: run rosbag play and load the appropriate display configuration in RViz or RViz2. This method works well for visual inspection but lacks advanced playback control and introspection. ### **4\. rosbag_pandas + matplotlib -- For data plots and analysis.** If you're working with numerical data (like odometry, velocities, or sensor readings), rosbag_pandas is a lightweight solution for converting bag topics to pandas DataFrames. Use it to: - Extract topics into structured data - Plot time-series graphs using matplotlib or seaborn - Export filtered datasets to CSV This is particularly useful for developers integrating robotics with analytics or ML workflows. ### **5\. MCAP CLI and viewers -- Next-generation format for ROS bags.** MCAP is a high-performance, cross-platform file format for message storage, gaining adoption in the ROS 2 ecosystem. Features: 1\. High performance - Fast sequential and random access for efficient playback and inspection - Supports compression (ZSTD, LZ4) to reduce storage without sacrificing speed - Streaming-friendly for live ingestion and remote pipelines 2\. Rich format features - Built-in schema support (Protobuf, JSON) for type-safe decoding - Self-describing: includes all metadata and message definitions - Cross-system compatibility, usable beyond ROS environments 3\. Strong tooling ecosystem - Native support in Foxglove for visualization and playback - CLI tools and libraries available in multiple languages (C++, Python, Rust, TypeScript) - Full integration with ROS 2 via rosbag2_mcap plugin 4\. Scalable and reliable - Designed for large datasets, cloud workflows, and long-term archival - Ideal for autonomy, simulation, and fleet-scale logging - Stable across software upgrades, ROS-independent 5\. Open and rxtensible - Open specification with active development and wide adoption - Maintained by the community and industry partners Use rosbag2_mcap for recording and converting, and inspect .mcap files using either the CLI tools or graphical viewers like Foxglove. Learn more: [https://mcap.dev](https://mcap.dev/) ## **Choosing the right tool.** | Tool | Best For | ROS Version | Formats | | ------------- | ---------------------------------- | ----------- | ----------------- | | Foxglove | Full-featured bag visualization | ROS 1 & 2 | .bag, .db3, .mcap | | rqt_bag | Basic GUI for legacy use | ROS 1 | .bag | | RViz / RViz2 | 3D live replay | ROS 1 & 2 | Playback only | | rosbag_pandas | Data plotting for analysis | ROS 1 | .bag | | MCAP tools | Efficient modern format inspection | ROS 2 | .mcap | ## **How to visualize a rosbag with Foxglove.** 1. Download or open [Foxglove](https://foxglove.dev) 2. Open a .bag, .db3, or .mcap file 3. Add panels: Image, Point Cloud, Plot, 3D, TF, Raw Messages, etc. 4. Use the timeline scrubber to step through or play data 5. Filter, sync, and analyze sensor outputs across multiple streams Foxglove does not require a running ROS environment as it works offline with recorded data. ## **Final thoughts.** As robotics systems grow in complexity, **rosbag visualization tools** have become essential to diagnosing and improving autonomous behavior. Whether you're building perception stacks, validating navigation, or simply trying to understand what went wrong, choosing the right tool can make a major difference. **For modern teams and scalable workflows, Foxglove and MCAP offer the most future-proof path forward.** --- ### What is URDF (Unified Robot Description Format)? URL: https://foxglove.dev/robotics/urdf URDF, or Unified Robot Description Format, is an XML-based markup language developed as part of the Robot Operating System (ROS) ecosystem. It is used to... URDF, or **Unified Robot Description Format**, is an XML-based markup language developed as part of the [Robot Operating System (ROS)](https://www.ros.org/) ecosystem. It is used to represent a robot model in terms of its **physical structure, kinematics, inertial properties, visual appearance**, and **collision geometry**. A URDF file typically defines a robot as a collection of **links** (rigid bodies) connected by **joints** (which define how links can move relative to each other). It can also specify **sensors**, **transmissions**, and **materials**, enabling simulation and visualization of the robot in 3D environments. Key features of URDF include: - **Modularity**: Each part of the robot is defined as a reusable component. - **Precision**: Accurate description of mass, inertia, and joint constraints. - **Visualization-ready**: Integration with tools like RViz and Gazebo for simulating or debugging robot behavior. - **Extensibility**: Can be combined with Xacro (XML macros) for dynamic model generation. URDF serves as a foundational layer for robot control, simulation, and visualization in both development and production workflows. ## **How is a URDF used in robotics?** URDF plays a critical role in the **robot software stack**, especially when using ROS or any tooling built on top of it. Here's how it's commonly used in robotics: 1. **Simulation:** URDF models are used to load robots into simulators like Gazebo, where developers test algorithms in a controlled virtual environment before deploying them on hardware. The URDF ensures that physical constraints and visual representations match real-world expectations. 2. **Kinematics and motion planning:** Tools like MoveIt rely on the URDF to understand the robot's joint limits, coordinate frames, and link hierarchy. This allows for accurate motion planning, inverse kinematics (IK), and forward kinematics (FK) computations. 3. **Visualization and Debugging**: In ROS tools such as **RViz**, URDFs are used to render 3D visualizations of the robot in real-time. Developers can overlay sensor data (e.g., lidar, camera feeds) on the model, which makes it easier to debug and understand system behavior. 4. **Sensor Integration**: URDF allows you to specify the **frames and positions of sensors** (like IMUs, cameras, or range finders) on your robot. Accurate modeling of these components is essential for sensor fusion, SLAM, and navigation. 5. **Cross-team and Cross-tool Communication**: Because URDF is a standard format, it ensures compatibility between teams and across tools--whether you're building hardware, developing software, or conducting QA tests. ## **Use a URDF with Foxglove.** Foxglove enhances the utility of URDF by providing powerful visualization, debugging, and introspection capabilities that are tightly integrated with modern robot development workflows. Here's how URDF fits into the Foxglove ecosystem: **1\. Visualize robot models in Foxglove.** Foxglove supports URDF natively. You can load your URDF file alongside live or recorded ROS2/ROS1 data to **visualize the robot's current pose and joint states** in a 3D scene. This enables: - Real-time monitoring of actuator and joint feedback. - Cross-referencing sensor streams with physical locations. - Dynamic model updates reflecting the robot's behavior during operation. **2\. Coordinate frame alignment and TF integration.** URDF is often used in conjunction with the tf and tf2 ROS libraries to define and track transformations between coordinate frames. Foxglove leverages this by: - Displaying a full frame tree. - Overlaying real-time frame poses in 3D. - Allowing you to debug frame mismatches or calibration errors intuitively. **3\. Sensor data correlation.** By knowing where each sensor is mounted (thanks to URDF), Foxglove enables correlation between sensor streams and the physical model. For example: - Point clouds from a lidar can be rendered precisely from the sensor's frame. - Camera images can be overlaid with bounding boxes or projections based on robot geometry. **4\. Streamlined debugging and collaboration.** With URDF-loaded robots in Foxglove, developers, operators, and researchers can collaborate more effectively: - Share insights via saved layouts. - Annotate issues relative to the physical robot. - Replay logs with full robot state context. | Benefit | Description | | ------------------------ | -------------------------------------------------------------------------- | | Enhanced visualization | View your robot in 3D with up-to-date joint states and transformations. | | Faster debugging | Quickly identify joint issues, sensor misplacements, or TF anomalies. | | Simplified collaboration | Share consistent robot models across teams using Foxglove layouts. | | Data-driven development | Overlay telemetry, logs, and visualizations using a single cohesive model. | URDF is a foundational tool for a roboticist that's building real-world systems. Whether you're simulating, debugging, or deploying your robot, URDF provides the structural and semantic clarity needed to build robust applications. **Foxglove amplifies the power of URDF** by making it easy to visualize, share, and act on your robot model in real-time. If you're building robots at scale or fine-tuning one in development, **leveraging URDF in Foxglove** can streamline your workflow and deepen your insight into system behavior. --- ### RViz vs Foxglove vs Rerun (2025): A practical guide for robotics teams. URL: https://foxglove.dev/robotics/rviz-vs-foxglove-vs-rerun Compare RViz, Foxglove, and Rerun. See SDKs, ROS integration, file playback, collaboration--and why Foxglove is the most complete, high-performance choice. _Updated for 2025._ This is a straight-to-the-point comparison of RViz, Foxglove, and Rerun through the workflows that matter: live ROS, file playback (bag/db3/MCAP), collaboration, extensibility/SDKs, and performance. It also covers what's new--namely, the Foxglove SDK--and why more teams are standardizing [visualization](/product/visualization) and more on Foxglove. ## What's new: - [Foxglove SDK](https://docs.foxglove.dev/docs/sdk) (C++/Python/Rust, MIT): stream data live into Foxglove or log directly to MCAP--with quickstarts and examples. - rosbag2 → MCAP by default (ROS 2 Iron+) improves portability across tooling. - Multi-file, merged timelines and Timeline view speedups make large, fragmented logs practical. ## **Tl;dr** - Choose Foxglove if you want a complete, high-performance platform purpose-built for robotics and Physical AI development--open .bag / .db3 / .mcap, synchronize topics on a single timeline (including multi-file), stream live ROS via [foxglove_bridge](https://docs.foxglove.dev/docs/fleet/bridge), collaborate across Devices/Events/Projects, and now seamlessly produce data with the Foxglove SDK. - Keep RViz for interactive markers and deep ROS debugging inside the dev env; it remains the canonical ROS GUI. - Rerun is a code-first visualizer with SDKs and early built-in MCAP support; ROS usage commonly relies on bridges/logging. It's handy for custom pipelines--but most teams will find Foxglove's integrated platform (and SDK) gets them further, faster. ## **At-a-glance comparison (2025).** | Category | Foxglove | RViz / RViz 2 | Rerun | | ------------------------- | ---------------------------------------------------------------------------------- | ------------------------------- | ------------------------------------- | | Platform | Web + Desktop | Desktop (ROS env) | Desktop | | Live ROS | foxglove_bridge (ROS 1) over WebSocket Foxglove SDK (ROS 2) | ROS-native GUI, node graph | Bridges / logging examples | | File playback | .bag / .db3 / .mcap; multi-file merged timeline | Via rosbag / ros2 bag playback | MCAP viewing (early), plus RRD | | 3D & panels | Modern 3D + 25+ panels; synchronized timeline, extensible viewer | Strong 3D + interactive markers | Configurable viewer | | Collaboration & data mgmt | Devices, Events, Timeline, Projects, PBs of storage and high-performance streaming | -- | -- | | Extensibility | Extensions (JS/TS); embed, SDK | C++ plugins | SDK-first | | SDKs | Foxglove SDK: C++ / Py / Rust (live streaming + MCAP logging) | -- | C++ / Py / Rust (logs to viewer/file) | | Pricing | Free (3 seats / 5 devices / 10 GB) + Pro, Enterprise, Academic | Free (open source) | Free (open source) | ## **What changed: the Foxglove SDK (and why it matters).** The Foxglove SDK brings a unified, robotics-friendly way to stream live data into Foxglove or log directly to MCAP from C++/Python/Rust. That means your code can publish structured, time-synchronized streams (images, lidar, transforms, telemetry) that are immediately explorable in Foxglove's [panels](https://docs.foxglove.dev/docs/visualization/panels) and 3D scene--or saved as portable MCAP for later analysis and sharing. - Languages & license: C++, Python, Rust; MIT. - Developer experience: quickstarts and an end-to-end example that goes from "hello world" to a live visual in minutes. - Fits your stack: pair it with foxglove_bridge for ROS 1 or use it standalone for non-ROS systems. Why this tips the scales: you now get one platform + one SDK for live + recorded data, backed by Projects, Devices, Events, and Timeline for collaboration and fleet-scale capabilities. For many teams, this is the most comprehensive and performance-friendly way to build, debug, and ship reliable autonomous robots today. ## **Deep dive on the criteria that decide rollouts.** ### **1) Live ROS connectivity and latency.** - Foxglove: Connect ROS 1 via foxglove_bridge (WebSocket) or ROS 2 via the SDK. No special local ROS setup for viewers; works in desktop and the browser for remote debugging. - RViz: The canonical ROS GUI with interactive markers, TF, URDF--great for in-the-loop manipulation and local development. - Rerun: Typical usage is a bridge or logging node that subscribes to ROS topics and sends them to the viewer. This is flexible, but it's an extra integration step. ### **2) File playback: bag / db3 / MCAP (and multi-file).** - Foxglove: Drag-and-drop ROS 1 (.bag), ROS 2 (.db3), and MCAP (.mcap) + multiple other files with the new data loader capability (e.g.: drag-and-drop csv). When you open multiple files, Foxglove merges them into a single timeline. For legacy .db3 without message defs, Foxglove recommends converting to MCAP. - Rerun: The viewer now opens MCAP directly (feature is early and evolving). For ROS bags, teams often replay via ROS or convert first. - ROS 2 default: From Iron, ros2 bag records to MCAP by default--making it easier to move recordings across tools. ### **3) Analysis and visualization.** - **Foxglove**: 20+ panels (3D, images/video, plots, maps, state transitions, topic graph, tables, audio, transform tree,...), all synchronized to the timeline. - **RViz**: 3D viz and interactive marker support; plugin ecosystem if you're staying inside ROS. - **Rerun**: A capable viewer configured via SDK and blueprints; strong for code-driven pipelines--less about team workflows. ### **4) Collaboration and data management.** - Foxglove: Devices (per-robot), Events (time ranges of interest), Timeline (fast overview across recordings), Projects (Enterprise) for access control and organization, high performant data backend for unlimitied storage and direct streaming. - RViz / Rerun: Primarily local workflows; you can store files and share configs, but there's no equivalent built-in data platform. ### **5) Extensibility and SDKs.** - Foxglove: Extensions (TypeScript) for custom panels/converters and programmatic embedding of the viewer--now alongside the Foxglove SDK (C++/Python/Rust) for easily producing data. - Rerun: SDK-first (C++/Python/Rust) for logging and viewing, with gRPC streaming options; good for bespoke tooling, but you'll assemble more pieces yourself. ## **Where Foxglove stands out (and** [**what that means for your team**](/why-foxglove/proposition-guide)**).** 1. One stack for live + recorded data--stream with foxglove_bridge or the Foxglove SDK, and analyze bags/MCAP in the same workspace. 2. Best-in-class portability--first-class MCAP support across the app and CLI; ROS 2's move to MCAP-by-default reduces friction. 3. Cross platform capable--desktop app availabe on MacOS, Windows, and Linux + web app available; available offline and also standalone air gapped (enterprise). 4. Team-ready by design--Devices, Events, Timeline make it obvious _what happened, when, and on which robot_, and Projects organize access at scale. 5. Extensible where it counts--use Extensions for domain-specific panels or converters, or embed Foxglove in your internal apps. 6. Straightforward pricing to get started--Free for up to 3 users / 5 devices / 10 GB, with Pro, Enterprise, and Academic when you need more. ## **Migration quick-start (RViz / Rerun → Foxglove)** 1. Install Foxglove (web or desktop). 2. Open your data: drag .bag / .db3 / .mcap; opening multiple files merges them into one timeline. 3. Connect live: stream and visualize your robot data live in Foxglove using the SDK 4. Add context: create Devices and annotate Events; explore across time in Timeline; group access with Projects (Enterprise). 5. Produce data with code: use the Foxglove SDK to stream or log to MCAP from C++/Python/Rust. ## **FAQs** Q: Does Foxglove support interactive 3D markers like RViz? A: Foxglove fully visualizes markers and offers multiple interaction paths, but RViz's interactive marker primitives (click-drag controls, context menus) remain a native RViz feature. Many teams complement Foxglove with targeted RViz sessions when they need that specific interaction. Q: Can Foxglove open ROS 2 .db3 files? A: Yes. Foxglove supports .db3, though legacy .db3 may lack message definitions; Foxglove recommends converting to MCAP for portability. Q: Does Rerun open MCAP? A: Yes--built-in MCAP viewing exists today, and the docs call the feature early and evolving. Q: What's the fastest way to programmatically get data into Foxglove? A: Use the Foxglove SDK (C++/Python/Rust) to stream live or log to MCAP; for ROS, the foxglove_bridge provides a high-performance path into the app. [Start free](/pricing) (3 developer seats, 5 connected devices, 10 GB storage) or move to Pro, Enterprise, or Academic as you scale--and use the Foxglove SDK to instrument your robots in minutes. [Get a demo today](/demo). --- ### What Is multimodal data visualization? URL: https://foxglove.dev/robotics/what-is-multimodal-data-visualization Multimodal data visualization refers to the unified display and analysis of diverse robotics data types--sensor streams, logs, camera feeds, 3D models, and... **Multimodal data visualization** refers to the unified display and analysis of diverse robotics data types--sensor streams, logs, camera feeds, 3D models, and telemetry--across formats like URDF, ROS Bags, Protobuf, and MCAP. Foxglove enables developers to centralize and interpret this data in real-time, improving decision-making, debugging speed, and development velocity. ## **Challenges with traditional visualization tools.** Legacy tools fall short in robotics development: - Fragmented ecosystems across different data formats - Lack of real-time indexing and visualization - Poor support for robotics-specific workflows (e.g., sensor fusion, time-synced playback) - Manual switching between tools delays debugging and insight gathering Foxglove solves this by consolidating multimodal data into a single, purpose-built platform. ## **Visual Insight: See what your robots see.** Foxglove redefines observability by offering: - A **unified workspace** for viewing telemetry, logs, video, and 3D environments - Collaborative layouts that simplify team-based debugging - Support for **custom panels** tailored to your robot's unique needs Developers can trace how robots _sense_, _think_, and _act_ through synchronized timelines and configurable views. ## **How Foxglove's multimodal visualization works.** ### Foxglove's system operates in 3 core phases: 1. **Data ingestion:** Ingest MCAP, ROS Bags, and other formats via streaming or file import from edge devices and local environments. 2. **Real-Time Indexing**: As data is streamed or uploaded, Foxglove indexes it by time, topic, and device--enabling granular queries and synced playback. 3. **Panel-Based Visualization**: Use shared layouts and specialized panels (e.g., 3D, plots, camera) to explore your robot's behavior across time and space. 🔗 [Supported Formats](https://docs.foxglove.dev/docs/visualization/connecting/local-data#supported-formats) 🔗 [How to Import Data](https://docs.foxglove.dev/docs/data/importing-data) ## **Key benefits for robotic and physical AI development.** - **Accelerated Debugging**: Reduce time-to-insight with real-time data introspection - **Custom Extensibility**: Build domain-specific tools via custom React panels - **Improved Collaboration**: Share layouts and insights across teams instantly - **Scalable Observability**: Handle increasing data complexity and volume with a cloud-native backend ## **Who should use multimodal visualization?** Foxglove benefits a wide range of roles: - **Roboticists** managing sensor-rich, multi-system robots - **Data Scientists** optimizing perception and decision algorithms - **Product Teams** needing visibility into autonomous behavior - **Organizations** scaling from prototypes to fleet-wide deployments In high-stakes robotics environments, faster debugging and deeper insights drive real-world performance improvements. --- ### What is robotics data analysis? URL: https://foxglove.dev/robotics/what-is-robotics-data-analysis Multimodal data analysis is an advanced approach to processing and interpreting complex datasets that include diverse data types - from visual and auditory... Multimodal data analysis is an advanced approach to processing and interpreting complex datasets that include diverse data types - from visual and auditory inputs, sensors, point clouds, telemetry information and more. ## How Foxglove supports robotics data analysis. Foxglove provides workspaces, panels and layouts that can be optimized for common visualization and debugging tasks enabling robotics teams to comprehend robot operations better along with the ability to share workspaces that create an efficient path to collaboration. ## What are Workspaces? Workspaces are dedicated or shared spaces within a robotic development product to visualize and analyze the data. ### How Foxglove supports workspaces. Foxglove [workspaces](https://docs.foxglove.dev/docs/visualization#interface) are at the center of the visualization and analysis experience, along with a left and right sidebar to view panels, topics, problems and variables. Add several different panels to a workspace and share it with a teammate to solve problems together, faster. ## What are timelines? Multimodal robotic data is ingested and indexed at received time and log time to enable playback from the start to the end of a mission or journey. ### How Foxglove supports timelines. Foxglove supports out-of-order and multi-process ingestion, providing a detailed timeline view of robotic data. Zoom in and out of the data, and navigate to time ranges of interest for deeper and exact point in time analysis. ## What are events? Events represent points or time ranges of interest in recordings; your data. ### How Foxglove supports events. [Events](https://docs.foxglove.dev/docs/data/events) help robotic developers quickly identify, categorize and search for relevant subsets of data. For example: identifying interesting scenarios the robot encountered in the world, to then simulate and test new models against the interesting scenario. --- ### What is robotics data management? URL: https://foxglove.dev/robotics/what-is-robotics-data-management Managing multimodal data is an intricate process that encompasses the collection, consolidation, and interpretation of diverse data to ensure a comprehensive... Managing multimodal data is an intricate process that encompasses the collection, consolidation, and interpretation of diverse data to ensure a comprehensive understanding of a robot. ## How Foxglove supports robotics data management. Foxglove is a centralized platform that seamlessly visualizes, analyzes, and manages data from diverse sources and frameworks such as URDF, ROS 1 and 2, Protobuf, MCAP, etc; understanding the spatial relationships and taking care of serialization, transport, out-of-order ingestion, indexing, and caching for robotic data engineers so they don't have to. ## What is MCAP? [MCAP](https://mcap.dev/) (pronounced "em-cap") is an open source container file format for multimodal log data. It supports multiple channels of timestamped pre-serialized data, and is ideal for use in pub/sub or robotics applications. ### How Foxglove supports MCAP. Foxglove is the creator and maintainer of the MCAP open source project. Import MCAP (.mcap) data files directly into Foxglove for in-depth analysis and visualizations. Convert other data formats like ROS 2, Protobuf, JSON, and more - into the MCAP file format. ## What is URDF? [Unified Robot Description Format](https://wiki.ros.org/urdf) (.urdf) is an xml format representing a robot model that can be visualized in 3D. ### How Foxglove supports URDF. [URDF](/robotics/urdf) robot models are automatically loaded into Foxglove's [3D panel](https://docs.foxglove.dev/docs/visualization/panels/3d#add-urdf) to help robotic developers understand how their robots move through the real world; allowing them to position and orientation or transform messages to position the robot's joints for easy troubleshooting. ## What are ROS bags? A [_bag_](https://wiki.ros.org/Bags) or ROS bag (.bag) is a file format in ROS for storing ROS [message](https://wiki.ros.org/Messages) data. ### How Foxglove Supports ROS 1 and 2. Visualize live or pre-recorded [bag](/robotics/ros) files by simply dragging and dropping the files directly into one of the many Foxglove panels that have built-in support for displaying native ROS messages - like 3D markers, images and logs. ## What is Protobuf? [Protobuf](https://github.com/protocolbuffers/protobuf) is an open-source cross-platform data format used **to serialize structured data**. ### How Foxglove supports Protobuf. Foxglove supports a variety of encoding formats including [Protobuf](https://docs.foxglove.dev/docs/sdk/schemas#protobuf-and-json-schema) by enabling loading local or remote MCAP files containing custom data (e.g.: Protobuf, JSON, FlatBuffers), or by connecting directly to live custom data via a Foxglove WebSocket connection. --- ### What is teleoperation? URL: https://foxglove.dev/robotics/what-is-teleoperation Teleoperation is remote control of a robot by a human operator. The operator sends commands and receives sensor feedback such as video, lidar, or pose in time to act. Updated August 2026. Teleoperation is remote control of a machine or robot by a human operator. The operator sends commands from a distance and receives feedback such as video, lidar, pose, or tactile data, then uses that feedback to decide the next action. It is not the same as full autonomy. A teleoperated robot depends on a human for the task. Many field robots mix both modes: autonomy for the routine path, and a human for exceptions, docking, or recovery. **Teleoperation vs autonomy.** In teleoperation, a human is in the control loop. In autonomy, software selects the actions. Supervised or shared autonomy keeps a human ready to take over. **Teleoperation vs remote monitoring.** Monitoring is view-only. Teleoperation is bidirectional: sensor data comes in, and commands go out. ## How a teleoperation loop works 1. The operator views the robot state (cameras, 3D, plots, maps). 2. The operator issues a command (velocity, joint target, or a custom message). 3. The network delivers the command to the robot. 4. The robot acts and publishes new sensor data. 5. The operator sees the update and corrects the next command. The loop only works if latency, bandwidth, and synchronization stay inside the limits of the task. | Constraint | Why it matters | | --------------- | ---------------------------------------------------------------------------------------------- | | Latency | Delay between a command and visible motion. High delay makes tight control unsafe. | | Bandwidth | Video and lidar need more capacity than telemetry. Congestion drops frames or stalls the view. | | Synchronization | Cameras, lidar, and pose must share a timeline, or the scene is misleading. | | Command rate | The robot must accept commands at a stable rate and fail safe if the link drops. | "Good enough" latency depends on the task. A slow inspection rover can tolerate hundreds of milliseconds. A manipulator in a cluttered cell cannot. Deep-space links are so slow that teams use supervised autonomy instead of direct stick control. ## How teams use teleoperation Teleoperation is common when a site is hazardous, remote, or too dynamic for full autonomy. **Field robotics and delivery.** Sidewalk and warehouse robots often call a human when autonomy is unsure. [Coco](/customers/coco) uses Foxglove to review teleoperator sessions and incidents after the run, so pilots and engineers can audit the same recording. **Marine and inspection.** Crews launch and recover vehicles from a host platform. [CCOM](/customers/ccom) researchers teleoperate autonomous surface vehicles from laptops on the host ship and watch cameras, GPS, and engine telemetry in one Foxglove layout. **Industrial and hazardous work.** Operators keep people off the site for nuclear inspection, confined spaces, or heavy equipment. **Research and space.** Planetary rovers use long-delay, supervised control. Medical robots use short-delay, high-precision control. These are industry examples, not Foxglove deployments. **Imitation learning.** Teams record human teleop of arms and mobile bases, then train policies from those demonstrations. [LeRobot](/blog/native-foxglove-visualization-in-lerobot) can stream that teleop session into Foxglove. ## Building blocks | Building block | Role | | ----------------------------------------------------- | -------------------------------------------- | | Video (H.264, H.265, VP9, AV1) | Primary operator view | | 3D, lidar, and TF | Spatial awareness around the robot | | Command channel (`cmd_vel`, joints, or custom topics) | Drive and manipulate | | Input device | Keyboard, gamepad, Steam Deck, or leader arm | | Network | LAN, VPN, cellular, or WebRTC | Foxglove can display those streams in one layout. It does not replace an E-stop, a safety PLC, or a certified vehicle controller. ## Use teleoperation with Foxglove Foxglove supports both sides of the loop: watch the robot, and send commands the robot already accepts. **See the robot.** Combine [Image](https://docs.foxglove.dev/docs/visualization/panels/image), [3D](https://docs.foxglove.dev/docs/visualization/panels/3d), [Plot](https://docs.foxglove.dev/docs/visualization/panels/plot), [Map](https://docs.foxglove.dev/docs/visualization/panels/map), and diagnostics in one time-synced layout. **Send commands.** Use the [Teleop panel](https://docs.foxglove.dev/docs/visualization/panels/teleop) for velocity-style control and the [Publish panel](https://docs.foxglove.dev/docs/visualization/panels/publish) for other message types. The robot must already subscribe to those commands. **Connect on the same network.** For ROS, run [foxglove_bridge](https://docs.foxglove.dev/docs/fleet/bridge) and open the WebSocket in Foxglove. [Rosbridge](/robotics/rosbridge) is an alternative JSON WebSocket path. The [Foxglove SDK](https://docs.foxglove.dev/docs/sdk) covers custom (non-ROS) stacks. **Connect from anywhere.** [Remote Access](https://docs.foxglove.dev/docs/fleet/remote-access) (Pro and Enterprise) puts a gateway on the robot and streams over WebRTC, including from behind a firewall or on a cellular link. See [Remote Access is generally available](/blog/remote-access-is-generally-available). **Record and review.** Use the same layout for live teleop and playback. That is how teams train operators and inspect incidents after the fact. ### Try it 1. Open [Foxglove](/download). 2. Connect live: local [foxglove_bridge](https://docs.foxglove.dev/docs/fleet/bridge) or [Remote Access](https://docs.foxglove.dev/docs/fleet/remote-access). 3. Add Image, 3D, and Teleop panels. 4. Publish a command the robot already accepts (for example `/cmd_vel`). 5. Save the layout for the next operator. ## FAQ Q: Is teleoperation the same as autonomy? A: No. Teleoperation keeps a human in the command loop. Autonomy lets software select actions. Many robots switch between the two. Q: Can I teleoperate a ROS robot from a browser? A: Yes. Connect Foxglove (desktop or browser) to ROS with foxglove_bridge, then use the Teleop or Publish panel. The robot must accept those messages. Q: What is the difference between rosbridge and foxglove_bridge? A: Rosbridge exposes ROS over a JSON WebSocket API. foxglove_bridge is the current Foxglove path for live ROS visualization and control. See [What is rosbridge?](/robotics/rosbridge). Q: Does Foxglove support teleop off the local network? A: Yes, on Pro and Enterprise, with Remote Access. The robot runs a gateway. The app connects through Foxglove. You still need a safe command path on the robot. Q: How do teams review teleop sessions after the fact? A: Record the run (bag, db3, or MCAP), open it in Foxglove, and use the same layout. [Coco](/customers/coco) reviews pilot sessions this way. Q: Does Foxglove provide haptic or surgical control? A: No. Foxglove visualizes data and can publish commands. It does not implement haptics, clinical devices, or safety certification. ## Related reading - [Remote Access is generally available](/blog/remote-access-is-generally-available) - [Teleoperating the LeKiwi from a Steam Deck](/blog/teleoperating-the-lekiwi-from-a-steam-deck) - [Native Foxglove visualization in LeRobot](/blog/native-foxglove-visualization-in-lerobot) - [What is ROS?](/robotics/ros) Open [Foxglove](/download) to connect a robot, or read the [Teleop panel docs](https://docs.foxglove.dev/docs/visualization/panels/teleop). --- ## Customer Stories ### Aescape: How Aescape streamlined debugging from days to minutes with Foxglove. URL: https://foxglove.dev/customers/aescape Industry: Health Impact: - days to minutes: Reduced diagnoses time from - hours to minutes: Reduced insights and collaboration from - ~30%: Saved development time The impact of Foxglove was immediate. Within a few weeks of adopting the platform, our debugging cycles became significantly shorter. -- Scott Butters, Staff Machine Learning Engineer, Aescape > **"The impact of Foxglove was immediate. Within a few weeks of adopting the platform, our debugging cycles became significantly shorter."** Scott Butters, Staff Machine Learning Engineer, Aescape Leveraging cutting-edge robotics and artificial intelligence, Aescape provides massages that are informed by human touch, enhancing personalized recovery and relaxation for users. Aescape's customer base includes spas, hotels, gyms, elite sports teams, and hospitality brands that lease Aescape's systems to elevate their wellness offerings. The Aescape robotic massage system seamlessly adapts to a wide range of customer needs, providing tailored care for elite athletes, busy professionals, and travelers alike. At the core of Aescape's technology is its perception pipeline, which enables precise body recognition through point cloud data, ensuring accurate and personalized massage experiences. The Aescape teams continually refines algorithms that generate detailed 3D models of users' bodies, adjusting for posture and movement. This approach guarantees that each massage is customized, adapting in real-time to the specific needs of every user. The Aescape massage system. ## Challenges without Foxglove: Siloed workflows and drawn-out debugging cycles. Before adopting Foxglove, Aescape faced significant challenges in managing the complexity of its AI and robotics systems. The development and debugging workflows were fragmented and inefficient, requiring the use of multiple open-source and custom-built tools. These tools were often disjointed, making it difficult to manage the large volumes of sensor and perception data. Engineers spent considerable time piecing together visualization solutions for point clouds, logs, and sensor data, slowing their ability to identify and resolve technical issues. This led to long debugging cycles and extended development times, limiting their capacity for rapid innovation. Collaboration across teams was another hurdle. Insights were siloed, making it difficult to share results and collaborate on debugging. Each team relied on different tools, leading to duplicated efforts and a slower pace in resolving issues and driving innovation. This non-integrated workflow created friction between departments, further hampering progress and making it harder to meet the growing demands of Aescape's robotic systems. ## Adopting Foxglove: Expedited diagnoses and streamlined systems. Recognizing the need for a more streamlined and scalable solution, Aescape adopted Foxglove to overcome these challenges. Foxglove provided an all-in-one platform that unified the development process, particularly in data visualization and diagnostics. The web-based interface and [MCAP](https://mcap.dev) format empowered Aescape to efficiently manage multimodal data streams, creating a single environment for reviewing and debugging data from its robotic systems. The primary Foxglove layout Aescape employees use. > **"The integration was surprisingly straightforward, enabling us to quickly transition from using multiple disjointed tools to a unified workflow. This significantly reduced the barriers for team members to engage with system data."** Scott Butters, Staff Machine Learning Engineer, Aescape ## The outcome and impact of using Foxglove: Improved collaboration and reduced troubleshooting time. The impact of adopting Foxglove was transformative. Debugging workflows became more efficient, allowing engineers to focus on feature development and diagnostics without the need to maintain multiple tools. Typical debugging tasks, such as diagnosing unexpected robot behaviors, were reduced from days to hours. Collaboration across teams improved significantly. Engineers, quality assurance, and support staff could now share findings in real time through Foxglove's intuitive interface. The ability to automate user scripts and share custom views empowered more team members to investigate issues independently, reducing reliance on key engineers for troubleshooting. > **"Typical debugging processes, such as diagnosing unexpected robot behaviors, were reduced from days to hours."** Scott Butters, Staff Machine Learning Engineer, Aescape Aescape employees collaborating around the Foxglove UI. Foxglove also enhanced Aescape's ability to respond to unexpected user movements, a critical feature for maintaining high-quality massages despite changes in user posture. By enabling rapid iterations of features like the "member in massage pose" recognition system, Foxglove enabled Aescape to refine system behaviors faster than ever before, resulting in quicker innovation cycles and overall product improvement. The adoption of Foxglove ultimately provided Aescape the ability to reduce time-to-market for new features, enhance product reliability, and further its leadership in robotic wellness technology. Integrating Foxglove into the development workflows has been pivotal in helping Aescape deliver world-class, AI-driven wellness experiences and scale its vision of bringing the future of self-care to a global audience. --- ### AIM: How AIM re-engineers earthmoving automation with Foxglove. URL: https://foxglove.dev/customers/aim Industry: Construction Impact: - 40%: faster debugging cycles across perception, planning, and control teams. - $200,000+: in annual engineering time saved by eliminating fragmented tooling. - 2-3 months: acceleration on autonomy milestones, enabling faster field deployment. With Foxglove, we've saved over $200,000 in engineering time annually and freed up three engineers to focus on core autonomy development. -- Ross Walker, Head of Product, AIM > **"With Foxglove, we've saved over $200,000 in engineering time annually and freed up three engineers to focus on core autonomy development."** Ross Walker, Head of Product, AIM AIM is on a mission to revolutionize the mining, construction, and defense industries by delivering the next generation of autonomous systems for heavy equipment. While industries like logistics and manufacturing have seen sweeping gains from automation, earthmoving remains dominated by manual operation--despite being among the most hazardous and inefficient work environments. AIM is changing that paradigm with an autonomous platform capable of retrofitting any make, model, or age of machinery. The result is non-stop, high-performance operations with radically improved safety and efficiency. From mining critical minerals to enabling planetary-scale infrastructure projects, AIM is unlocking capabilities that were previously unimaginable. ## The challenges of scaling without Foxglove. Building comprehensive tooling for production robotics data is no small feat--so why reinvent the wheel? Without a centralized source of truth for multimodal log data (telemetry, camera, point cloud, etc.), progress slows, collaboration becomes fragmented, and teams lose focus chasing scattered insights instead of advancing the mission. Simple questions like "What happened during this autonomous dig?" required manual alignment of timestamps and file types. Debugging bottlenecks became a real threat to AIM's pace of innovation. As one engineer put it, "Life before Foxglove was like trying to read The Matrix through code. Now everything is too easy--it makes you think you're in a simulation." > **"Our engineers are now more productive than before. With Foxglove, they're focused on autonomy, not tooling."** Ross Walker, Head of Product, AIM ## Adopting Foxglove to scale autonomy with reliability. The tipping point came when the complexity of AIM's autonomy stack outgrew its initial workflows. The company needed a purpose-built, centralized platform that could unify data analysis, accelerate debugging, and support asynchronous collaboration at scale. Enter Foxglove. The transition was swift. AIM standardized its autonomy logs to MCAP, seamlessly adopted Foxglove for visualizing the data, and implemented Foxglove's data management capabilities to centralize and streamline collaboration. A custom ingestion pipeline now streams logs from the field to the cloud in real-time, enabling immediate review and triage. Engineers built a user-facing note tagging system that links operational observations directly to Foxglove sessions, integrating smoothly with the company's issue tracking stack. The switch also included decommissioning dozens of brittle internal tools and sharing standardized layouts across the org. All technical teams were fully trained within four weeks--ushering in a new era of consistency, clarity, and speed. An AIM engineer looking at their data within Foxglove. > **"Foxglove didn't just speed up our workflows--it rewired the way our teams collaborate and think about debugging at scale."** Ross Walker, Head of Product, AIM ## How Foxglove became a force multiplier for AIM. Post-Foxglove, AIM's development velocity surged. Debugging that once took days now takes hours. Sessions are logged in MCAP, streamed to the cloud, and automatically ingested into Foxglove. Engineers dive into synchronized timelines of lidar, camera feeds, and vehicle telemetry, annotate issues, and collaborate across teams effortlessly. The unified visualization and advanced debugging slashed root cause analysis times by more than 40%, freeing up engineering capacity and dramatically accelerating autonomy milestones. More than $200,000 of engineering time is saved annually--not to mention the reduced risk and improved safety outcomes from faster resolution of field issues. Perhaps most critically, three engineers previously focused on maintaining internal tooling are now fully dedicated to core autonomy development. By transforming AIM's ability to analyze and act on data, Foxglove has become a strategic force multiplier. It didn't just eliminate friction--it unlocked new capabilities. Whether triaging production bugs, sharing discoveries across teams, or onboarding new hires, AIM now operates with a level of clarity and cohesion that directly powers its mission to unlock our civilization's capabilities to build planetary-scale infrastructure. --- ### ANYbotics: How ANYbotics helps industrial operators turn robot data into insights faster with Foxglove. URL: https://foxglove.dev/customers/anybotics Industry: Inspection Impact: - Cut incident-to-data access from days to the moment of customer notification, so engineers can act immediately. - Eliminated the old workflow's three biggest data failures (partial logs, wrong time windows, and on-robot retention cleanup) by pulling complete, time-accurate data directly from the robot. - Consolidated six tools into one environment for fetching, visualizing, and analyzing robot data. - Fully displaced ANYbotics' internal bag-retrieval tool: 100% of validation testing now runs through Foxglove. Scaling an autonomous robotic workforce demands both uncompromising quality and cost-efficiency. While standard telemetry offers a reliable macro-level view of fleet health, Foxglove enables our engineers to pinpoint the root causes of complex edge cases, drastically accelerating time-to-resolution and driving down support and maintenance costs. -- Martin Bühlmann, Head of Cost & Quality ## Overview ANYbotics builds autonomous robotic inspection systems for the most demanding industrial environments in the world. Its four-legged ANYmal robots conduct routine inspections at oil and gas facilities, power generation sites, chemical plants, mines, and heavy manufacturing operations. Customers include Equinor, Shell, BASF, Petronas, Siemens Energy, and BP. In these environments, trust is the bar. Operators are handing over inspection rounds that protect worker safety, asset integrity, and uptime. ANYbotics has built a support model around that responsibility, helping customers understand what happened in the field and resolve issues quickly when something does not go as planned. As deployments scaled across more sites, fleets, and operator profiles, fast access to complete robot data became essential to making that model even more responsive and repeatable. Foxglove helps ANYbotics strengthen that support loop by giving teams direct, secure access to data from deployed robots in a single environment for inspection, sharing, and analysis. > **"Scaling an autonomous robotic workforce demands both uncompromising quality and cost-efficiency. While standard telemetry offers a reliable macro-level view of fleet health, Foxglove enables our engineers to pinpoint the root causes of complex edge cases, drastically accelerating time-to-resolution and driving down support and maintenance costs."** Martin Bühlmann, Head of Cost & Quality, ANYbotics A Foxglove layout showing ANYmal sensor, autonomy, and telemetry streams during an inspection mission. _A Foxglove layout showing ANYmal sensor, autonomy, and telemetry streams during an inspection mission._ ## The Challenge: Scaling data access for a growing global robot fleet ANYbotics' robots operate at customer sites that span continents, fleet sizes, and skill levels. When something unexpected happens in the field, engineering needs to understand exactly what the robot saw, decided, and did, often without being able to set foot on the site. Every hour spent waiting for data is an hour the customer is waiting for an answer. Before Foxglove, the workflow stood in the way. Consider a representative incident: an ANYmal robot on a routine inspection mission encountered a misplaced box that blocked the only path back to its docking station. The robot got stuck and ran out of battery. The customer retrieved the machine, connected a laptop, copied the logs, and uploaded them to a shared drive. Only then could ANYbotics support begin analyzing the issue using a patchwork of internal and legacy tools. Support discovered the wrong time window had been captured, and the entire process had to be repeated. Days passed before any engineer started analyzing the root cause. And the case was hardly unique: partial logs, wrong time windows, and logs already cleaned up by on-robot retention were common failure modes that forced the team to go back to the customer and reset the process again and again. Inside the company, the need for a more scalable data workflow was becoming just as clear. Developers and validation teams needed a faster way to inspect and work with robot data across testing and field support scenarios. ANYbotics had built internal tools and command-line workflows that served the team well at an earlier stage, but as fleet size grew and validation demands increased, the process required too much manual coordination. Engineers often relied on familiar manual paths when speed mattered, adding extra steps to validation cycles and making it harder to standardize analysis across teams. ## The Solution: One platform for every robot, every incident, every team Today, when a customer notifies ANYbotics of an incident, support pulls the relevant log files directly from the robot through Foxglove, with no customer-side extraction or upload required. Engineers gain access to complete, time-accurate data at the moment of notification, and they work from a single environment to inspect what happened. The downstream effect on ANYbotics' support model is significant. The team operates a tiered response: Tier 1 brings the robot back to a safe state, Tier 2 determines what kind of incident occurred, and engineering investigates the logs to understand root cause. Foxglove compresses every step that touches data. Tier 2 can triage faster because the right data is already available. Engineering can begin analysis immediately rather than waiting on file transfers. The path from customer issue to informed response becomes shorter and more repeatable. > **"Once our data was in Foxglove, engineers could easily identify the root cause. The Foxglove agent and automation completely transformed our workflow, reducing a multi-step data extraction process that used to take hours or days down to a single click that takes minutes."** Aaron Roller, Head of Software Infrastructure & Reliability, ANYbotics Verification and Testing engineers depend on the same Foxglove workflows to validate behavior before changes ship to deployed robots, so the robots that reach the field are more trustworthy by design. Returning to the stuck-robot incident, that same scenario now runs end to end in hours rather than days, with ANYbotics pulling complete data directly from the machine the moment the customer flags the issue. Side-by-side comparison of the old (manual, customer-mediated) and new (Foxglove-direct) workflows. _Side-by-side comparison of the old (manual, customer-mediated) and new (Foxglove-direct) workflows._ ## ANYbotics' Build-versus-buy decision ANYbotics faced a familiar build-versus-buy decision: continue investing engineering time into homegrown infrastructure for a non-core capability, or adopt a purpose-built platform designed for robotics data workflows. The choice was about focus. Keep ANYbotics' engineering resources on the core strength and customer impact of its autonomous inspection systems, and let Foxglove own the data layer. In evaluation, Foxglove stood out because it could retrieve bag files from robots quickly and easily, and because its architecture, including support for edge servers, was credible for the kind of large-enterprise deployments ANYbotics is scaling into. ## Looking ahead: Trust at scale ANYbotics is building toward a future where every hazardous, dirty, or repetitive industrial inspection is performed by an autonomous legged robot. That mission only succeeds if customers trust those robots, and trust the team standing behind them. Every new site, every new operator, and every new deployment model raises the bar on how quickly ANYbotics can turn robot data into understanding. Foxglove enables ANYbotics to meet that bar. As the company scales across more customers, more sites, and more demanding deployment models, including its expansion into Ex-certified hazardous-zone inspection with ANYmal X, Foxglove provides the visualization, synchronization, collaboration, and security capabilities the team needs to keep its reliability, uptime, and safety commitments visible and verifiable to the operators who depend on them. --- ### Breaker Industries: How Breaker Industries uses Foxglove to accelerate and scale voice-first autonomy for defense. URL: https://foxglove.dev/customers/breaker-industries Industry: Defense & Aerospace Impact: - 18,200: voice commands operationalized to improve training and product iteration - 70%+: reduction in internal tooling overhead - <1 week: for new engineers to contribute to run analysis Voice-first autonomy only matters if it works in the environments our customers actually operate in. Foxglove helps us turn complex system behavior into something we can analyze, improve, and stand behind with confidence. -- Matthew Buffa, Co-CEO > **"Voice-first autonomy only matters if it works in the environments our customers actually operate in. Foxglove helps us turn complex system behavior into something we can analyze, improve, and stand behind with confidence."** Matthew Buffa, Co-CEO, Breaker Industries ## Overview Breaker is a defense-first software company building Avalon, a platform-agnostic orchestration agent that enables a single operator to command teams of robots across air, land, and sea using voice. Breaker's mission is to break the one-operator-per-robot model and make autonomous systems operate more like true teammates in the field. The team of nearly 30 is based across Austin, TX, and Sydney, Australia. Breaker serves defense and government customers globally, including partnerships with some of the world's largest defense primes such as Rheinmetall. The industry keeps asking how to make operators work better with robots. Breaker asks the opposite: how do robots work better with operators? That means building for the reality most autonomy systems ignore: operators who are driving, flying, multitasking, or under pressure, who cannot stop to navigate a screen-based interface. In defense robotics, where heat, mission tempo, degraded communications, limited compute, and compliance requirements shape every product decision, voice-first autonomy is not a convenience. It is a different model for how humans and robots work together. To make that model work in practice, Breaker's engineers need to see, understand, and improve complex system behavior across recorded runs, live tests, and simulations. That's where Foxglove comes in. Foxglove provided Breaker with a shared data analysis platform that replaced fragmented log-parsing workflows, giving the team a single environment to review autonomy behavior, analyze voice-command activity, and turn mission data into insights that improve debugging, product iteration, and trust in a voice-first system. ## Impact 1. **A clearer way to quantify and operationalize voice-command activity.** Breaker used Foxglove-enabled analysis to extract a count of 18,200 voice commands processed, then used that data to improve training and product iteration. 2. **Less engineering time spent building internal tooling.** The move to Foxglove eliminated the need to maintain custom log parsing infrastructure, reducing internal tooling overhead by at least 70%. This ensured the engineering team could remain focused on building, reducing our time to product-market-fit. 3. **Onboarding speed.** New engineers are contributing to run analysis within their first week, down from 3-4 weeks when the team was relying on custom internal tooling. This is especially important for a complex and changing stack. ## The Challenge: Life before Foxglove From the beginning, Breaker faced a familiar robotics problem: understanding complex system behavior can quickly become a tooling problem of its own. As Avalon expanded across more robots, more domains, and more field runs, the volume and complexity of the data grew just as fast. Early on, that meant engineers were often left manually combing through logs or building internal tools for narrow debugging and analysis tasks. Jack Scott, Breaker's lead robotics engineer, describes the old workflow as "archaeological". You knew something had happened in flight; you just had to dig through layers of logs to figure out what. Both approaches took time away from the core product and became harder to sustain as the system grew more complex. For a small team building under strict edge constraints, that tradeoff adds up quickly. Every hour spent stitching together visibility into what happened during a run is an hour not spent improving autonomy behavior in the field. Foxglove helped Breaker avoid that trap early by giving the team a shared way to inspect, understand, and debug system behavior before fragmented workflows and one-off tooling became part of the engineering process. Foxglove layout showing camera feed, system state, logs, and map data during a Breaker field run. _Foxglove layout showing camera feed, system state, logs, and map data during a Breaker field run._ ## The Solution: How Breaker uses Foxglove in engineering and analysis workflows Today, Foxglove is woven into Breaker's engineering workflow, from the lead robotics engineer through to interns. As Breaker deploys Avalon across more robots and operating environments, Foxglove gives the team a shared way to visualize, inspect, and make sense of increasingly complex data. One core workflow is recorded mission review. Breaker uses Foxglove to scrub through MCAP recordings from field runs and inspect what Avalon saw, decided, and did during a mission. That lets engineers review detections and behavior in context instead of piecing events together manually from logs. Foxglove also supports live development and testing. Breaker can connect directly to robots over a local network and visualize what is happening in real time, which is especially useful as Avalon is validated across a growing range of platforms. The team also uses Foxglove for simulation inspection and repeated analysis. Engineers can inspect live data from simulation environments, validate full-system behavior before hardware deployment, and extract voice-related metrics from run data to support training and iteration. Foxglove's value extends beyond engineering workflows alone. Because Breaker serves ITAR-sensitive defense customers, deployment flexibility is also critical. Foxglove supports self-hosted, air-gapped, and customer-controlled environments, helping Breaker meet security and compliance requirements while still giving its team the visibility it needs to understand and improve system behavior. Foxglove telemetry plots showing altitude error, pressure, GPS altitude, vertical velocity, and terrain-relative height. _Foxglove telemetry plots showing altitude error, pressure, GPS altitude, vertical velocity, and terrain-relative height._ How embedded Foxglove has become is reflected in decisions the team did not expect to be about Foxglove at all. When selecting a camera output format, the team rejected two technically viable options because neither could be opened in Foxglove. Losing live introspection across the camera path was not a tradeoff the team was willing to make. That constraint shaped a core architectural decision, which is a reasonable measure of how central the tool has become to how Breaker builds. When a field run completes, an engineer opens the MCAP recording in Foxglove and works through the mission from a single environment. They scrub the timeline to review what Avalon saw and decided, cross-reference target detections against the geo-referenced map, validate altitude behavior across multiple telemetry streams, and confirm that voice commands were received and acknowledged. What would otherwise require stitching together data from multiple sources happens in one place, against a shared timeline. ## Looking ahead: what this partnership signals for future growth As Breaker scales across more robots, more deployment environments, and more customer conversations, the ability to inspect and explain autonomy behavior becomes more important. Foxglove helps them build the engineering discipline needed to scale voice-first autonomy across a more complex product and customer landscape. --- ### CCOM JHC: How CCOM reduced data discovery time by 10X for their ocean exploration missions. URL: https://foxglove.dev/customers/ccom Industry: Marine Impact: - 50% reduction: Developer tools required - 60% increase: Users that can inspect logs - Over a week to several hours: Time to locate and analyze relevant mission data Foxglove has stood on the shoulders of giants in the ROS community. For those of us working on robots with ROS middleware, it's hard to beat the capability of Foxglove. -- Val Schmidt, Lead at the Marine Robotics Department At the University of New Hampshire's [Center for Coastal and Ocean Mapping (CCOM)](https://www.ccom.unh.edu/), over a hundred scientists, researchers, and graduate students collaborate on a variety of ocean mapping research projects and exploration missions. To help conduct these missions at sea, CCOM has a marine robotics department with the goal of making robotic vessels practical, safe, and efficient for NOAA and the nation's ocean mapping and exploration missions. In addition to developing their own systems, CCOM partners with robotics manufacturers to develop autonomous surface vehicles (ASVs). Unfortunately, many systems don't provide robust robotics observability tools to visualize their vessels' data. This makes it arduous and time-consuming for CCOM researchers to find relevant data for inspection, debug issues on-the-fly, and iterate on their autonomy software for the next mission. By adopting Foxglove, CCOM's multidisciplinary robotics team has been able to get insight into their marine vessels' data faster than ever - whether that's in the lab or out on mission at sea. This has helped the entire team codify newly streamlined processes for inspecting, analyzing, and exploring their mission logs. ## Challenges ### Manual data processing and exploration across tools CCOM's marine robotics team currently operates two large robotic vessels - BEN (Bathymetric Explorer and Navigator) is a C-Worker 4 built by [**ASV Global of L3/Harris**](https://www.unmannedsystemstechnology.com/2018/09/l3-acquires-asv-global/), while the DriX 8 is another ASV built by [**Exail**](https://www.exail.com/). Both have navigation systems, perception sensors, and sonar packages on board. These vessels are equipped with "backseat drivers" - computers running ROS and Project11, a ROS-based marine robotics software framework developed at the Center that allows the team to integrate with the vessel in ways not originally envisioned by the manufacturers. The C-Worker 4 logs data to a proprietary format, while the DriX has a ROS-based middleware and logs ROS BAG files. Though these hardware companies provide robust physical platforms, CCOM needed equally robust forensic tools to understand how their vessels work, troubleshoot unexpected issues, and monitor real-time data feeds to safely teleoperate them. To even look at their data, much less harness its insights to improve their algorithms, CCOM researchers must go through an arduous conversion and parsing process. Because BEN's factory-delivered middleware isn't ROS, the team had to shim it into their environment. Exporting logs was painfully clunky - BEN uses a proprietary binary log format that can be exported as CSV files, often multiplying the volume of data by orders of magnitude. Researchers had to parse these CSV files to make custom plots using Python or MATLAB, or convert it yet again into MATLAB's MAT format or HDF5 files. Even after automating these conversion steps, the team struggled to sync BEN's multimodal data across timestamps and visualize it all in one place or tool. The DriX does come with ROS middleware, simplifying the process somewhat - it writes ROS 1 bag files that could be easily parsed and read by native tools like RViz. The downside is that these tools often struggle to load large data files and make it difficult to share insights with teammates. ### Opaque technical workflows Due to the nature of the team's developer tooling setup - or lack thereof - meaningful data analysis was often restricted to technical teammates. While some team members have had experience writing software, a good portion of CCOM's marine robotics team are technicians with little to no coding experience. These technicians could have deep expertise in topics like diesel engines, electrical power generation and distribution, or material corrosion, but lacked the skills to access and visualize vessel logs. As much as other technical teammates tried to enable access, there were a limited number of hours in the day to support them. Without a user-friendly developer tool to display the information for them, these teammates were unable to troubleshoot problems and analyze long-term trends. . ### Difficulty finding interesting data CCOM expeditions often span 4 to 5 days, with certain fields' data rates as high as 100Hz - this results in tens of gigabytes of recorded data for every mission. The DriX alone collects between 5 to 7GB of data as ROS bag files for upload to Foxglove. In fact, the team's marine robotics vessels collect so much data that researchers spent weeks parsing it and locating specific ranges of it to explore further. Knowing what time range and topics to target when finding data worth analyzing was a huge challenge. Manipulating this data via scripts often excluded many team members from getting involved. Even technical team members could take days to sift through this data and find ranges of interest, but non-technical team members could take multiple weeks for this same task. During missions, researchers keep a manual log - whenever something out of the ordinary happens, they take a note of the time and add details. These notes work as a reference when team members go back and scrutinize the logs to find parts of data that are of interest. The team also wrote code to run at the end of every day to parse data and automatically construct a few plots for things that had historically been useful to look at. After those plots were available, you could reference them to dive deeper into specific events. While these scripts did get to the heart of what people wanted to look at frequently, it was still a challenge going through so much data. ## Deploying Foxglove to accelerate development CCOM has been able to tackle their dense multimodal data with an intelligent strategy and one software solution: the Foxglove observability platform. ### Synced data ready for inspection in one integrated environment With Foxglove, CCOM can now sync their multimodal data across time for immediate analysis. Even though their manufacturing partners don't provide these visualization and playback tools out-of-the-box, Foxglove provides a ready-to-go development environment that gets robotics observability working within minutes. When launching their ASVs from ships at sea for missions, researchers use Foxglove to teleoperate the vessels from laptops onboard the host ship. They can also display real-time feeds of multimodal data - from camera images and GPS points to plotted kinematics and filtered logs - and monitor operational parameters critical to mission success - like the engine RPM, or the temperature of the cooling system and exhaust. All these visualizations work together to give researchers a well-rounded understanding of what's going on. _Foxglove layouts are used to monitor engine parameters (like RPM, coolant temperature, and fuel level) and vessel trajectory._ When inspecting data after missions, the CCOM team uses Foxglove's data playback functionality to visualize the collected data and troubleshoot any issues that may have come up during the excursion. The data can be represented visually in different ways for more comprehensive and faster analysis, synchronized across space and time. For example, they can now easily view their vessel's position on a map, and then immediately tie that to some plotted time series data, the current camera image, or the current 3D point cloud. > **"Foxglove has stood on the shoulders of giants in the ROS community. For those of us working on robots with ROS middleware, it's hard to beat the capability of Foxglove."** Val Schmidt, Lead at the Marine Robotics Department ### Supporting non-technical teammates Every member of the marine robotics team - technical or otherwise - can now use Foxglove to access mission logs. Everyone is now empowered to explore all collected robotics data, because they're able to use a user-friendly interface like Foxglove to quickly inspect it from different angles. This has been made even easier with preset layouts. Team members can now configure custom layouts specific to certain development workflows, to help users narrow down what topics to start looking at for a given objective. For example, the CCOM team created one layout primarily for monitoring their vessels' engine data - i.e. engine RPM, oil pressure, and coolant or engine compartment temperature. Another custom layout monitors the vessels' telemetry systems - the signal to noise, the bandwidth usage over each telemetry link in each direction. Still another layout monitors the health of the navigation system - namely, the IMU / GPS unit that helps take accurate measurements of the ocean's depth while the boat bobs around. Since its health is critical to the success of seafloor mapping missions - without it, the mapped seafloor could look like it's "moving" - the team created this particular layout to focus on calibrating this important piece of equipment. ### Less time and effort to locate relevant data Before Foxglove, scrutinizing hours of log files and locating important ranges in those gigabytes of data often took several weeks. With Foxglove's intuitive web interface for organizing and searching for data, this same work can now take as little as a few hours. Now that all data is uploaded to the cloud, team members can immediately access it upon import. In addition to preset layouts, they can also share custom user scripts, annotate specific parts of the data with metadata, and much more. Foxglove's web interface makes it easy to search and filter data by a variety of categories - like recording device, time range, and even metadata values. On missions, when there are urgent parts of the data that researchers need their manufacturing partners or another teammate onshore to scrutinize, they can use the limited connectivity they have to push just that subset of the data. From there, someone who isn't onboard the ship during the mission can still scrutinize specific snippets of data and give helpful feedback during the course of the excursion. As a product of all this, the time to diagnose issues or keep track of live metrics has dropped significantly. ## Outcome Thanks to Foxglove, CCOM has been able to streamline their workflows for finding and exploring their data. Instead of having to manually convert data into different formats and opening different tools to explore it, researchers can now just drag-and-drop their data files into Foxglove to start scrutinizing their logs. Instead of spending weeks slogging through gigabytes of data to find what they need, they can now use the wealth of visualization tooling Foxglove provides to quickly locate where they should start inspecting their data. With Foxglove, CCOM has empowered more team members to investigate their data, increase their rate of development, and iterate more quickly and confidently on their autonomous surface vehicles. --- ### Chef Robotics: How Chef Robotics grows 300% year over year using Foxglove. URL: https://foxglove.dev/customers/chef-robotics Industry: Logistics Impact: - Reduced debugging time from hours to minutes. - Reduced development cycles up to 40% - Reduced downtime through first-level triage by field staff. We've been using Foxglove every day for almost three years now--it's become an indispensable tool for us. -- Vinny Senthil, Senior Software Engineer, Chef Robotics > **"We've been using Foxglove every day for almost three years now--it's become an indispensable tool for us."** Vinny Senthil, Senior Software Engineer, Chef Robotics Chef Robotics specializes in automating labor-intensive processes in the food industry-the third largest labor force in the US and the number one largest labor shortage-starting with food manufacturing. By deploying AI-enabled robotic systems, Chef transforms the production of the food we eat every day. Chef's goal is to deploy robots in every commercial kitchen worldwide. To bootstrap a dataset and overcome the AI cold-start problem, the company is initially focusing on high-mix food manufacturing--such as ready-to-eat meals for grocery chains, direct-to-consumer meal delivery services, airline catering, hospital meals, and meat packing. Chef's systems replace manual assembly tasks, ensuring precision, efficiency, and safety in demanding environments like refrigerated warehouses. This automation is particularly impactful, as assembly tasks account for approximately 60-70% of labor in commercial kitchens. The team at Chef is made up of an extensive amount of robotics experience, enabling them to create efficient, accurate, and collaborative robots that work on high-speed conveyor lines for dynamic food manufacturing. Operating on a mesh network architecture, Chef robots continuously communicate to coordinate tasks like ingredient placement. When a robot identifies a task, it evaluates parameters such as the position of the target on the conveyor and its own workload. Once assigned, the robot broadcasts its task to the network, allowing others to adjust their assignments accordingly. This real-time communication ensures synchronized operation, maintaining smooth workflows even as conditions change. Chef Robotics' robots in action dispursing food into containers. The system leverages spatial awareness and real-time perception data to map conveyor layouts, detect items, and assess robot positions. Using 3D object detection, robots create bounding boxes around bowls and identify orientations, compensating for tilted conveyor belts common in manufacturing facilities. Robots collaborate on complex scenarios, dynamically redistributing tasks to prevent bottlenecks when specific areas become overloaded. This integration of perception, spatial awareness, and real-time multi-robot communication ensures that Chef Robotics' systems meet the demands of food manufacturing with unparalleled precision and adaptability. > **"Visualizing data being sent from one robot to another, as well as on the host itself, has definitely improved our ability to iterate-it has been essential."** Vinny Senthil, Senior Software Engineer, Chef Robotics ## Adopting Foxglove: scaling development and operations efficiently. From its inception, Chef Robotics recognized the need for a scalable visualization and robotics development platform to manage the complexities of developing and debugging their robots. Tasks such as sensor integration, calibrating robots, and managing robot-to-robot communication required a tool capable of handling 3D data, visualizing state transitions, and monitoring multi-robot coordination. Foxglove's 3D and State Transitions panels became essential for the intricate dynamics of multi-robot communication. Debugging such a system requires precise, moment-by-moment insight into how robots share information, handle task assignments, and coordinate spatially. Engineers can visualize the exact state and communication patterns, pinpointing any bottlenecks or misalignments. This insight allows engineers to quickly identify and resolve miscommunications, ensuring that the system returns to optimal performance. Foxglove's visualization also enables side-by-side comparisons of system behavior before and after updates, providing clear insights into how changes affect communication efficiency, task allocation, and overall performance. Interactive and customizable layouts unify views of task assignments, conveyor alignments, bounding boxes, and robot-to-robot message logs into a single interface, streamlining collaboration across software, hardware, and field operations teams. By eliminating the need for fragmented tools and reducing debugging workflows from hours to minutes, Foxglove empowers Chef Robotics to iterate rapidly and deploy enhancements with confidence. > **"No one quite has that multimodal, all-of-the-different-inputs experience. We've been using it every day--I can't remember a day the software team didn't use Foxglove."** Vinny Senthil, Senior Software, Chef Robotics ## The impact of Foxglove: enabling year over year growth. Chef Robotics' remarkable growth--scaling 300% year-over-year--has been fueled by its ability to rapidly deploy, iterate, and optimize its cutting-edge robotics systems. As Chef expands operations to meet the growing demands of food manufacturers across North America, Foxglove provides the scalability and efficiency required to handle the increasing complexities. Foxglove's ability to streamline debugging workflows and accelerate feature development enabled Chef to keep pace with its rapid growth without compromising on quality or reliability. The impact of Foxglove is most evident in how it empowered Chef to iterate faster on new features, keeping their technology at the forefront of food manufacturing automation. For instance, introducing new perception models or improving motion planning algorithms do not require lengthy manual testing cycles. Instead, Foxglove's intuitive visualization allowed Chef to implement and validate changes in minutes, not weeks, ensuring their robots continued to exceed performance expectations as they scaled. As Chef scaled its workforce and operations, Foxglove played a key role in maintaining operational efficiency that increased Chef customers' satisfaction too. Field technicians use Foxglove's intuitive layout to diagnose and resolve first-tier issues on-site, reducing any burden on engineering teams. This allows engineers to focus on core development and higher-level problem-solving, ensuring that Chef can handle the demands of its growing customer base while maintaining the flexibility to innovate rapidly. Chef Robotics engineer using Foxglove. > **"Feature development and issue resolution time both dramatically improved."** Vinny Senthil, Senior Software Engineer, Chef Robotics Ultimately, Foxglove has been a cornerstone of Chef Robotics' ability to scale and grow year-over-year. By providing the tools needed to debug, analyze, and refine robotic systems efficiently, Foxglove has not only supported the company's exponential growth but has also ensured that its robots deliver the precision, reliability, and efficiency demanded by customers across the food manufacturing industry. With Foxglove's support, Chef Robotics is not just keeping up with its growth--it is leading the charge in transforming the future of automated food production. --- ### COCO: How COCO reduced incident resolution time from hours to seconds using Foxglove. URL: https://foxglove.dev/customers/coco Industry: Logistics Impact: - 5x reduction: Issue investigation time - 3x reduction: Developer tools required - 3x larger user base: Data accessibility It was possible to look across a hundred trips, quickly locate all instances of an issue, and summarize its impact on the robots' performance within minutes. -- Rob Zehner, VP of Engineering, COCO Founded in 2020 to democratize last-mile delivery, Coco currently operates its sidewalk robots in Santa Monica and West Los Angeles for food delivery. Their long-term vision is to deploy an autonomous fleet across various delivery verticals--without contributing to urban congestion or pollution. As Coco scaled, resolving incidents became a major bottleneck, with single issues taking hours of engineers' time. The team soon realized that achieving their goals required better robotics observability--a faster, more scalable approach to capturing, organizing, and learning from their data. By adopting Foxglove, Coco quickly learned to make sense of their complex data, reducing incident resolution time from hours to seconds. ## Challenges without Foxglove ### Juggling different data across disparate tools. Because Coco's systems dealt with heterogeneous data streams, the hardware, software, and quality teams used various tools to collaborate on their data. While these solutions worked well individually, they didn't integrate smoothly with each other. Analyzing, sharing, and cross-referencing data across these tools became an increasingly cumbersome process that cost developers hours each day. This patchwork system made collaboration difficult for Coco's engineers. Sensor data, log messages, control signals, and videos were recorded in different formats across multiple frameworks, forcing engineers to jump between as many as five tools to analyze a single trip. As a result, they rarely examined the robots' ROS bag files, as these contained only a small portion of the full picture. ### Bottlenecking progress with manual workflows. To view a recording of a robot's trip, Coco engineers first had to transcode the data, select a time range to explore, write a script to convert it to the correct format in a Jupyter Notebook, wait several minutes for the output MP4 file, and finally view it in a web browser. This process was long, error-prone, and not scalable. Few team members had the technical skills to use all the tools, so teamwide progress often depended on the availability of these engineers. As a result, Coco frequently missed opportunities to properly resolve incidents, as the barrier to inspecting them was so high. ### Training and auditing human pilots. Training and auditing Coco's pilots required a significant investment of time and resources. For new pilots, an experienced teleoperator had to be physically present to observe how they handled deliveries. Even for more experienced pilots, Coco found it challenging to audit whether they were accurately reporting all incidents (e.g., a robot flip or a pedestrian interacting with the robot). To review a session, an engineer had to cross-reference multiple databases to pull the relevant video for a given robot and timeframe, playback hours of footage to spot-check a few incidents, and then consult another database to identify which pilot was responsible for the incidents. ## Deploying Foxglove to accelerate development With the Foxglove platform, Coco knew they could tackle most of their challenges with one software solution. They were excited to get support across their entire development process - from data storage and management to visualization and analysis. ### Bringing multimodal data into one integrated environment. Whether recording data on the robot, from pilots' workstations, or via its autonomy stack, Coco needed to consolidate its multimodal data streams into one place for efficient analysis. To achieve this, Coco leveraged [**MCAP**](https://mcap.dev), a container file format developed by Foxglove, to merge their heterogeneous data into a common log format. They then imported their newly consolidated files into Foxglove for seamless team-wide collaboration. With Foxglove's intuitive web interface, Coco engineers can now reference a central repository to annotate, organize, and analyze data. Clicking on a recording instantly allows them to visualize data, scrub through the timeline, and jump to key timestamps. Here, they can compose rich layouts that visualize everything from camera feed images to log messages and 3D markers. With this migration, Coco now stores, visualizes, and debugs data in a single integrated development environment--eliminating the need to jump between software solutions or hand off tasks between teammates. This bird's-eye view has made issue tracking more efficient than ever: analysis tasks that once took hours are now completed in seconds, and the number of developer tools has decreased fivefold. ### Democratizing team access to data and insights. After taking robots on test drives or deliveries, Coco team members can now access the recordings in Foxglove by the time the robots are brought back inside. They no longer need to wait for an available engineer to query multiple databases and use several tools to download video footage. Any technical or non-technical team member can easily click through the Foxglove timeline in seconds to find the footage they need, along with all associated metadata (e.g., recording robot, delivery trip details, map, etc.). By integrating with Foxglove events, Coco has also streamlined incident triaging through batch reviews. Whether it's a pilot tagging a robot-human interaction or a script automatically detecting issues like robot flips, the Coco team can step through a list of events within minutes to determine if further analysis is required. Not only does this facilitate short-term analysis, but the benefits of having organized data will continue to grow as Coco collects more data in the future. > **"It was possible to look across a hundred trips, quickly locate all instances of an issue, and summarize its impact on the robots' performance within minutes."** Rob Zehner, VP of Engineering, Coco Tagging data with events has also made it easier for Coco to conduct deeper analysis. Engineers can now quickly review all instances of a failure mode and make informed decisions based on that information, rather than spending hours or days sifting through petabytes of unstructured data. ### Improving human pilot oversight and training. Better data visibility has empowered Coco engineers to better collaborate with human pilots. Previously when pilots manually reported incidents, their subjective judgment calls often resulted in inconsistent records. But with automatic tagging and easier access to video footage, engineers can now easily cross-reference generated events against pilots' reports to audit them for accuracy. Instead of reviewing hours of footage to audit trip reports, they can now scan the main points of interest in seconds and use Foxglove to get more qualitative context on any discrepancies. ## The impact of using Foxglove Before Foxglove, Coco often made strategic business decisions based on assumptions or approximations--mainly because compiling the data necessary for informed decisions was so time-consuming. Once Foxglove put the data at Coco's fingertips, it revealed parts of the business that the team hadn't been seeing. Coco can now access data, triage incidents, and assess the impact of an issue on their business in seconds. Their engineers are also able to collect cleaner data around key metrics--data that will drive future iterations of their autonomy software--and make necessary adjustments to their roadmaps. With this integration, Foxglove has become a one-stop solution for Coco's development workflows. The platform is now pervasive across the company--used by the Trust and Safety team to review incidents, pilots to log their trips, and engineers to share collaboration links. By helping them tackle common development tasks, Foxglove has allowed Coco to bypass tooling debates and focus on building high-performance robots. --- ### Dexterity: How Dexterity saved hundreds of thousands and accelerated their development using Foxglove. URL: https://foxglove.dev/customers/dexterity Industry: Logistics Impact: - ~20%: development time saved - $150,000: saved annually in tooling and development time - <10 mins: to triage an issue with <1 day from issue discovered to fix Things that were impossible before are now possible. -- Robert Sun, Founding Engineer, Dexterity > **"Things that were impossible before are now possible."** Robert Sun, Founding Engineer, Dexterity [Dexterity](https://www.dexterity.ai/) is revolutionizing logistics, warehousing, fulfillment, and e-commerce by providing advanced AI robotics that help Fortune 500 companies reduce their carbon footprint, address labor challenges, and maximize their automation investments. The teams (that use Foxglove) at Dexterity focus on robotic controls, motion planning, vision, and state estimation of robotic systems, creating technology that enhances and automates critical parts of their customers' operations. Dexterity engineering working on mechanical components. ## Challenges without Foxglove Before integrating Foxglove into their workflows, Dexterity's team relied heavily on in-house tools and various log analyzers. While these tools met their basic needs, they required constant maintenance and lacked the rich visualization capabilities essential for efficient debugging and development. Tasks like adding and removing scene state estimators and combining it with robot views were challenging. Iterating on computer vision (CV) visualization was time-consuming, as researchers preferred to focus on algorithm development rather than building custom visualization libraries and hooks. Additionally, the inability to record or replay visualizations and data resulted in significant time wasted, developer friction, and the need to juggle multiple disparate tools. With the adoption of Foxglove, Dexterity was able to reduce the number of developer tools by threefold, contributing to annual savings of over $150,000. ## Adopting Foxglove The decision to integrate Foxglove was driven by the need to eliminate visualization boundaries and streamline workflows. Dexterity undertook a deep integration process, migrating to Pub/Sub high-frequency data and overhauling their services to feed directly into [Foxglove WebSocket](https://docs.foxglove.dev/docs/getting-started/custom#foxglove-websocket) and [MCAP](https://mcap.dev/) recordings. This integration significantly shaped Dexterity's architecture, enabling both edge sites (customer locations) and primary sites, while unlocking additional benefits of the Foxglove data platform. It made it incredibly easy for Dexterity developers, test engineers, field ops, and partners to access, share, and collaborate on snippets of robot events. This also allowed the team to discover issues in less than a day, triage them in under 10 minutes, and deploy a fix within the same day. Initially, the team expected Foxglove to provide easier visualization and a few new features. However, as the integration progressed, it became clear that Foxglove offered much more, reshaping their entire workflow. Like many scaling robotics companies, Dexterity was experiencing growing pains with their middleware, which Foxglove and MCAP helped overcome. The additional effort to overhaul their workflows--not just their visualization--proved to be well worth it, resulting in a deeply integrated and highly functional system for their team. > **"We expected just easier visualization, but it turned out to be much more--unlocking invaluable efficiency for all our developers."** Robert Sun, Founding Engineer, Dexterity ## The outcome and impact of using Foxglove The impact of integrating Foxglove was felt within 3 months, as the team gradually adopted the new workflows. Foxglove transformed Dexterity's debugging and development processes by enabling every step of their AI Directed Acyclic Graph (DAG) to be visualized independently or combined for a comprehensive state view. This capability allowed the team to create a full state visualization for their robots, similar to visualizations we see now for self-driving vehicles, enhancing collaboration and data sharing across teams. Iteration on new features, particularly in computer vision, became significantly more efficient, as developers could instantly visualize algorithmic issues and address them promptly. Dexterity engineer using Foxglove. Foxglove's integration provided Dexterity with invaluable tools to pull and piece together data across production and development environments. The ability to save and share views indefinitely has created a treasure trove of data that was previously inaccessible. As a result, the platform has not only solved immediate business problems but also unlocked new possibilities for the team. The improvements in workflow efficiency and the introduction of new capabilities have had a profound impact, making previously impossible tasks achievable and dramatically reducing the time needed to diagnose issues. Ultimately, Foxglove has been instrumental in helping keep Dexterity at the forefront of robotics innovation, ensuring that it can deliver transformative value with AI powered robotics. --- ### Greenzie: How Foxglove helps Greenzie cut incident triage time from days to minutes. URL: https://foxglove.dev/customers/greenzie Industry: Agriculture Impact: - Days to minutes: Time to triage a customer incident - From 5 to 1: Tools required for incident triage - From reactive to proactive: Development and innovation Before Foxglove, our incident triage process could take an entire day. Now, I can look at any incident in 30 seconds and have an answer. -- Charles Quinn, Co-founder and CEO of Greenzie [**Greenzie**](https://www.greenzie.com/), a pioneering technology company based in Atlanta, is on a mission to free humans from repetitive outdoor labor. Specializing in the lawn care industry, Greenzie develops software to enhance the capabilities of commercial mowers through operator assistance and autonomous technologies. Their primary customers are commercial landscapers and lawn maintenance companies (including the largest landscaper in the US) servicing large turf areas like athletic fields, industrial parks, and educational campuses. ## Challenges: manual data collection and multiple tools Before adopting Foxglove, Greenzie faced significant challenges in data management, incident analysis, and debugging. Their process required long syncs to get ROS bag files, sometimes even involving manually collecting data from the robots by mailing a physical hard drive to customers. Greenzie works with lawn care companies all over the country, and with over 21,000 acres mowed by Greenzie machines in 2023, this was a major hindrance, both for customer operations and for new product development. This arduous process would be followed by laborious synchronization and playback using multiple tools such as RViz, Gazebo, and PlotJuggler. Aside from the operational challenges of using multiple tools to visualize the robotics data, Greenzie also faced the challenge of sharing visualizations, both within their own team and with their customers, while working to triage issues. Greenzie relies heavily on customer feedback to improve their product, so altogether this setup led to delays in problem resolution, hindering their ability to rapidly iterate and improve their products. > **"Before Foxglove, our incident triage process could take an entire day. Now, I can look at any incident in 30 seconds and have an answer."** Charles Quinn, Co-founder and CEO of Greenzie ## Implementation: engineering, customer success, and business development Greenzie opted to connect to their mowers over a VPN in order to use Foxglove directly. Using this setup allows Greenzie customers to focus on their own jobs -- keeping lawns beautiful -- without the hassle of manually offloading data from their mowers. Foxglove's cloud-based system enables rapid sharing of diagnostic information and visual feedback directly with clients, showcasing the mower's operational status and environment. Using Foxglove has significantly accelerated Greenzie's development and debugging processes, and ultimately their time-to-market with improvements, new features and capabilities. Greenzie uses Foxglove to quickly access and visualize robotics data without resorting to the multitudes of tools they had to use in the past. They make use of both the shareable layouts and the links to view and share data in order to work collaboratively as a team. They have also built their own plugins that allow them to view certain sensor-specific custom views within Foxglove. Their [**message converter extension**](https://github.com/Greenzie/foxglove-depthai-spatial-detection-converter) for depth and spatial detections is even available as open source. This has all enabled the rapid development iteration they always dreamed of. Greenzie also makes use of Foxglove in their business development efforts: at conferences, Greenzie uses Foxglove to showcase the real-time visualization of mower operations, offering attendees a live demonstration of the technology in action. > **"The fact that Foxglove just works with ROS, without any additional setup or software, has been a selling point for many members of our team, including our tier 1 support team."** Brian Cochran, Robotics Software Engineer, Greenzie ## Impact: rapid incident catch and triage On the customer-facing side, using Foxglove has allowed Greenzie to free their customers from the burden of transferring data. Since customer data is now uploaded to Foxglove automatically, Greenzie can even catch incidents before they are reported. Foxglove has replaced multiple tools for Greenzie, reducing the time required to analyze incidents from a full day to under an hour, and sometimes even under 30 minutes. Internally, Foxglove has enabled better collaboration, allowing multiple team members to work on a problem simultaneously. Greenzie uses [**Foxglove events**](https://docs.foxglove.dev/docs/data/events) to mark incidents and [**Shared layouts**](https://docs.foxglove.dev/docs/visualization/layouts#organization-layouts) and [**Shareable links**](https://docs.foxglove.dev/docs/visualization/shareable-links) to collaborate efficiently. The gained efficiency has not only sped up internal operations but also improved customer trust and satisfaction by enabling faster response times to issues reported in the field. Foxglove's ability to streamline the data analysis and visualization processes has been instrumental in allowing Greenzie to focus more on innovation and less on solving technical issues. The tool's extensibility and ease of use have fostered a proactive approach to product improvement and customer service, ultimately enhancing Greenzie's market position as a leader in autonomous outdoor lawn care equipment. > **"Thanks to Foxglove we're no longer spending time fighting with tooling -- we're developing revenue-generating product and helping our customers, which is why we exist."** Charles Quinn, Co-founder and CEO of Greenzie ## Conclusion Greenzie's adoption of Foxglove represents a significant step forward in the use of advanced technology for enhancing productivity and operational efficiency in the robotic lawn care industry. By effectively leveraging Foxglove, Greenzie has not only improved its development workflows but has also enhanced its customer engagement and service delivery, setting a new standard in the integration of technology within a green industry. --- ### Multiply Labs: How Multiply Labs uses Foxglove to scale robotic biomanufacturing of advanced therapies. URL: https://foxglove.dev/customers/multiply-labs Industry: Health Impact: - 2-3 hours → seconds: for a workflow that previously required manually gathering, processing, and visualizing robotic event data - 12+: data endpoints streaming continuously from a single deployed system to the cloud through one Foxlet - 24/7: visibility across the full robotic system giving engineers always-on access to behavior across traditional robotic arms and proprietary electromechanical subsystems in one unified view Building robots that manufacture patient doses requires understanding exactly what every subsystem does, on every run. Foxglove gives our engineers that visibility across the whole system, and turns every robotic event into data that makes our platform better. -- Fred Parietti, Co-founder and CEO ## Overview Multiply Labs is a robotics company building the physical AI layer for life sciences, on a mission to remove a critical bottleneck in modern medicine: manufacturing the advanced therapies that patients depend on. They work with leading pharmaceutical and biotech organizations, including AstraZeneca, Legend Biotech, and Kyverna Therapeutics, and partners with technology leaders such as NVIDIA and Universal Robots. The next generation of biological therapies are getting rapidly approved for patients, but the manufacturing stack, built for small molecules and large batches, was never designed for the complexity, precision, and throughput these therapies demand. Multiply Labs' answer is physical AI for life sciences: cloud-controlled robotic clusters that automate a manufacturer's existing, already-validated instruments inside a closed, sterile environment. A single cluster combines traditional six-axis robotic arms with Multiply Labs' own proprietary electromechanical subsystems, all orchestrated in parallel to execute the dozens of discrete unit operations that make up a biologics process. That architecture creates a demanding observability problem. Across a single deployed system, many robotic and electromechanical subsystems act in concert, each generating its own stream of events, sensor readings, and state. To build, debug, and continuously improve a system that must run reliably and produce complete records, Multiply Labs' engineers need to see, understand, and explain exactly what every subsystem did, and when. That is where Foxglove comes in. Foxglove gives Multiply Labs a shared data platform for analyzing robotic behavior across live systems and historical events. Instead of manually searching machines, collecting scattered files, post-processing data, and building one-off visualizations, engineers can stream system data continuously, inspect robotic events in context, and understand system behavior from one place. > **"Building robots that manufacture patient doses requires understanding exactly what every subsystem does, on every run. Foxglove gives our engineers that visibility across the whole system, and turns every robotic event into data that makes our platform better."** Fred Parietti, Co-founder and CEO, Multiply Labs ## Impact 1. **From hours to seconds to understand a single robotic event.** Reconstructing what happened during one robotic event used to be a manual exercise that took two to three hours of gathering and stitching together logs. With Foxglove, that work happens automatically, and engineers can gather and visualize a single event in seconds rather than hours, dramatically shortening every debug and iteration loop. 2. **One Foxlet, a whole cluster monitored as a fleet.** A single deployed system exposes more than 12 data endpoints, all constantly streaming robotic events to the cloud through one Foxlet. In effect, one robotic cluster behaves like a fleet of many smaller robotic and electromechanical systems, and Foxglove lets Multiply Labs monitor all of them in parallel with minimal overhead. 3. **Every robotic event, analyzed at once and around the clock.** Instead of inspecting events one at a time, the team can analyze and visualize all of its robotic events together. With Foxglove streaming 24/7 across its robotic systems, Multiply Labs has continuous visibility into system behavior, not just snapshots captured after something goes wrong. ## The Challenge: Life before Foxglove Like many robotics teams, Multiply Labs faced a familiar problem: understanding complex system behavior can quickly become a tooling problem of its own. A single cluster is not one robot but many subsystems acting together, traditional robotic arms alongside proprietary electromechanical hardware, each producing its own events and sensor data. As the systems grew more capable, the volume and complexity of that data grew with them. Before Foxglove, making sense of a single robotic event meant manually gathering logs from multiple sources and reconstructing the sequence after the fact, a process that could take two to three hours per event. Worse, engineers were largely limited to looking at one event at a time, which made it hard to see patterns across subsystems or across runs. This kind of workflow does not scale well for a company building production-grade robotic biomanufacturing systems. As the number of subsystems grows, the number of possible interactions grows with it. A single robotic event may involve motion planning, control software, mechanical behavior, sensors, proprietary electromechanical components, and the manufacturing protocol itself. For Multiply Labs, the challenge was not simply collecting data. The challenge was making that data usable fast enough for engineers to improve system performance, investigate anomalies, and keep scaling a reliable robotic platform. Foxglove layout showing 3D robotic-arm visualization, telemetry plots, logs, and live status indicators from a Multiply Labs run. _Foxglove layout showing 3D robotic-arm visualization, telemetry plots, logs, and live status indicators from a Multiply Labs run._ ## The Solution: A unified data layer for every robotic event, subsystem, and run Today, Foxglove is part of how Multiply Labs observes, investigates, and improves its robotic systems. Multiply Labs streams robotic system data to the cloud through Foxglove, including data from traditional robotic arms and proprietary electromechanical subsystems. A single deployed system includes more than 12 data endpoints, all constantly streaming robotic events using one Foxlet. This gives the team a unified way to understand system behavior without stitching together separate tools for each subsystem. > **"Foxglove gives us one place to see everything our systems are doing, across the robotic arms and our various subsystems. Instead of chasing logs across machines, we stream every event to the cloud and inspect it in context. That continuous visibility is what lets us catch issues early and keep improving how the systems run."** Juan Borbon, Staff Robotics Software Engineer, Multiply Labs When an event occurs, engineers can open Foxglove and inspect the relevant context: logs, sensor readings, robotic state, and visualizations of robot behavior. Instead of spending hours gathering data and manually generating plots, the team can see what happened across the system from a shared interface. That changes the debugging workflow. Engineers can move from "Where is the data?" to "What does the data tell us?" They can compare signals, identify anomalies, review how the robot behaved, and understand how different subsystems interacted during the event. For a system with many interconnected components, that shared context is critical. Foxglove also reduces the cost of observability as the system grows. A robotic cluster can be thought of as a fleet of many smaller devices operating together. Without a unified platform, every new subsystem can create another data stream to manage, another visualization workflow to maintain, and another source of engineering overhead. Foxglove lets Multiply Labs monitor many of those devices in parallel with minimal overhead. ## The Data Flywheel: Scaling robotic systems through continuous improvement For Multiply Labs, Foxglove is not only a debugging tool. It is part of a larger data flywheel. Every deployed robotic system produces real-world data. Foxglove helps capture that data continuously, preserve the context around robotic events, and make the data easy for engineers to analyze. As the team reviews more events, they can better understand what normal system behavior looks like, identify the signatures of small deviations, and detect when something is changing over time. Foxglove helps Multiply Labs turn every robotic run into a continuous data flywheel--streaming, analyzing, and applying insights to improve future deployments. _Foxglove helps Multiply Labs turn every robotic run into a continuous data flywheel--streaming, analyzing, and applying insights to improve future deployments._ This flywheel matters especially for Physical AI. Robots need to learn from real-world operation, not just from controlled test cases. By making robotic events easier to capture, visualize, and understand, Foxglove helps Multiply Labs turn production data into engineering leverage. ## Looking Ahead: Building the foundation for scalable robotic biomanufacturing As Multiply Labs scales its robotic clusters and expands the number of systems in operation, observability becomes even more important. More robots means more data, more subsystem interactions, and more opportunities to learn from real-world behavior. Foxglove gives Multiply Labs a foundation for that growth. With 24/7 streaming, cloud-based event access, and unified visualization across robotic and electromechanical systems, the team can understand system performance without increasing internal tooling overhead. For Multiply Labs, that means engineers can spend less time assembling the data they need and more time improving the robotic systems that will help make advanced therapies more accessible. --- ### Polymath Robotics: How Polymath gained a competitive advantage using Foxglove. URL: https://foxglove.dev/customers/polymath-robotics Industry: Automotive Impact: - 30%: development time saved. - From days to minutes: to debug issues. - 100x: increase in customer reporting clarity. It just works. Not only has it supercharged our dev processes, it has also helped us build stronger relationships with our customers and win new deals. -- Troy Gibb, Staff Robotics Software Engineer at Polymath Robotics > **"It just works. Not only has it supercharged our dev processes, it has also helped us build stronger relationships with our customers and win new deals."** Troy Gibb, Staff Robotics Software Engineer at Polymath Robotics Polymath Robotics specializes in off-road autonomy, delivering advanced solutions for industries such as agriculture, mining, construction, and delivery robotics. Their platform includes vehicle-agnostic safety systems, autonomous vehicle-following capabilities, and remote software deployment, enabling seamless integration with various industrial vehicles and sensors. By managing core autonomy functions like path planning, hazard detection, behavior trees, and safety protocols, Polymath allows robotics teams to skip foundational development and focus on creating high-value, market-ready autonomy. Their suite of 40 autonomous navigation modules offers unmatched flexibility, accelerating deployment timelines and reducing the need for large engineering teams. With a focus on reliability, scalability, and customer-centric design, Polymath Robotics empowers companies to bring autonomous systems to market faster, using fewer resources while maintaining industry-leading performance and safety standards. A Polymath Robotics engineer using Foxglove in the field. ## Challenges without Foxglove. Before adopting Foxglove, Polymath Robotics faced challenges in their development and debugging workflows. The team relied on RViz, a live robot visualization tool lacking data replay capabilities, forcing developers to debug in real time. This made troubleshooting high-friction and unreliable, as past events couldn't be revisited easily, complicating root cause analysis and slowing development cycles. Their process involved multiple tools for data inspection and analysis, logging, and sharing results from debugging. Engineers manually compiled screenshots, raw logs, and videos in an attempt to collaborate and debug, consuming valuable development time and increasing the risk of human error. Communicating results to clients was also difficult, as reports often lacked clarity and the ability to share easily, limiting Polymath's ability to showcase its technological strengths. These inefficiencies threatened Polymath's competitive edge, especially during critical customer evaluations where competitors faced similar limitations. Recognizing the need for a more integrated and scalable solution, Polymath adopted Foxglove. ## Adopting Foxglove. The team's first step was incorporating Foxglove's core visualization features, including 3D and Plot panels, raw message inspection, and customizable user scripts. These capabilities allowed developers to replay recorded data, easily inspect outputs, and trace events across a time. This marked a major shift from live robot debugging to a post-processing approach, enabling deeper insights and efficient collaboration. Polymath Robotics' Foxglove layout visualizing an annotated 3D scene and temporal data. Polymath also integrated Foxglove into its reporting pipeline. Instead of relying on screenshots and raw log dumps, they used the platform to generate clear, data-rich visualizations. They captured animated GIFs of system performance directly from Foxglove, embedding them into client-facing reports. This provided a level of transparency and technical depth that competitors couldn't match, giving Polymath a critical advantage during customer evaluations. > **"Sharing clear, transparent visualizations with our customers and prospective customers builds a level of trust and confidence we simply could not attain without Foxglove."** Troy Gibb, Staff Robotics Software Engineer at Polymath Robotics ## The impact of using Foxglove. Foxglove's visualization tools enabled Polymath to create detailed, data-driven reports showcasing sensor inputs, vehicle movements, and decision-making processes. During competitive "bake-offs" against leading OEMs, Polymath leverages these capabilities to produce clear, dynamic visualization of their vehicle safety system in action--something their competitors haven't replicated. This level of transparency and technical depth helps Polymath win the contracts and secure new business opportunities. A Polymath Robotics engineer using Foxglove. Beyond debugging, Foxglove strengthened internal onboarding time from days to hours for new developers and accelerated testing times too. Within days of integrating Foxglove, the team saw improvements in development cycle times, data analysis accuracy, and project delivery, eliminating prior manual overhead, saving valuable time, and accelerating progress by several days. Ultimately, Foxglove became a cornerstone of Polymath's robotics development process. It empowered the team to work more efficiently, reduce development time, and communicate their technological advantages with greater clarity and confidence--directly contributing to critical contract wins and sustained business growth. --- ### Reframe Systems: Reframe Systems accelerates modular construction automation using Foxglove. URL: https://foxglove.dev/customers/reframe-systems Industry: Construction With Foxglove I can virtually look over the robot's shoulder, see what it's thinking, and have us rolling again in minutes. -- Joseph Schornak, Robotics Lead, Reframe Systems > **"With Foxglove I can virtually look over the robot's shoulder, see what it's thinking, and have us rolling again in minutes."** Joseph Schornak, Robotics Lead, Reframe Systems Reframe Systems is reinventing homebuilding by applying automation and robotics to modular construction. Operating with a vertically integrated model, the company designs, models, and builds in localized microfactories. From architects crafting high-efficiency floorplans to engineers programming robots that frame walls in a factory environment, Reframe's approach drastically reduces build time and increases quality. At the heart of their operations is their 1st robotic platform called Acadia, designed to fabricate structural wall panels with flexibility, speed, and precision. Their goal: deliver high-quality housing that's faster, more predictable, and more resilient than traditional construction to meet rising housing demands. One of Reframe's robots building a wall. ## Challenges without Foxglove: live-only debugging and slow iteration. Before integrating Foxglove, Reframe's debugging workflows were reactive, manual, and constrained by the limitations of legacy tools. Using RViz as their primary visualization interface, engineers could only investigate issues live--if a robot failed during operation and wasn't diagnosed at the moment, there was no ability to reconstruct or analyze the problem afterward. The team attempted to record [MCAP](https://mcap.dev/) files, but replaying them in practice proved unreliable, often rendering their data logs useless. This made failures opaque and debugging painfully slow, especially in a high-mix environment where not all issues could be easily reproduced. Routine development tasks--like debugging motion planning trajectories or validating point clouds during camera calibration--became time sinks, compounded by limited data recording and visualization capabilities. Hardware constraints also played a role; GPU-heavy workloads meant team members needed high-spec gaming laptops just to run RViz effectively. These friction points weren't just technical annoyances--they blocked the team from moving quickly, scaling systems efficiently, and focusing on the core innovations that set Reframe apart. > **"I built a custom log-offload pipeline at my last job; Foxglove gives us the same capability out of the box."** Fifi Yeung, Founding Engineer, Reframe Systems ## Adopting Foxglove: from one-hour breakthrough to factory-wide automation. Reframe first encountered Foxglove at the 2023 Robotics Summit, where a recommendation from a shared investor nudged the team to take a closer look. What started as a curiosity turned into an indispensable part of their workflow within an hour of hands-on use. During early trials, the team leveraged Foxglove to troubleshoot a subtle but critical issue: a motion planning misconfiguration was causing the robot to execute a joint move instead of a linear trajectory--a nuance invisible to the naked eye, but obvious when visualized with Foxglove's coordinate plots. The platform's ease of use and powerful visualization instantly validated their suspicions and delivered insight in under 60 minutes. A Reframe engineer using Foxglove in action. From there, Reframe built [Foxlet](https://docs.foxglove.dev/docs/fleet/foxlet) into their core infrastructure, automating uploads from all work cells. Engineers now visualize and debug robot sessions using Foxglove, and the team has begun integrating event logging to track system behavior down to every nail fired. Whether diagnosing motion anomalies or verifying perception pipelines, Foxglove became a central interface for production operations, research, and development alike. A screenshot of Reframe's layout in Foxglove. > **"The very first time we tried Foxglove we pinpointed a mis-configured trajectory in under an hour--something invisible to the naked eye."** Fifi Yeung, Founding Engineer, Reframe Systems ## The impact of using Foxglove: instant diagnostics, advanced debugging, and scalable growth. With Foxglove, Reframe moved from reactive firefighting to proactive engineering. The shift was immediate: a robot failing to pick a stud, which previously would've sparked a time-consuming investigation, now takes just minutes to diagnose via replayed logs. Instead of launching a full Q&A session or rechecking every input, engineers simply "look over the robot's shoulder" through Foxglove's visualization tools to understand what went wrong--then adjust accordingly and resume production. This efficiency boost didn't just save time--it enabled Reframe to scale. As they brought new work cells online with differing physical configurations, Foxglove's consistent tooling, data tagging, and recording formats ensured that no extra engineering effort was needed to maintain observability. Engineers no longer have to rebuild internal tooling for data offload or logging; Foxglove handles it seamlessly. Its cloud-first architecture lightened hardware requirements too, allowing parts of the team to move to Mac-based development--a significant shift from their former reliance on GPU-heavy Windows setups. Foxglove hasn't just helped Reframe improve; it's helped them evolve. By reducing time-to-diagnosis, standardizing workflows, and eliminating redundant infrastructure, Foxglove has unlocked new velocity in robotic construction--accelerating the company's mission to build smarter, faster, and for more people. --- ### Saronic: How Saronic brought a new class of ocean drones to market in under 2 years using Foxglove. URL: https://foxglove.dev/customers/saronic Industry: Defense & Aerospace Impact: - 20%+: engineering time saved - <24 hrs: from issue discovered to fix in production - 50+: engineers (30%+ of the company) on-boarded to Foxglove The adoption of Foxglove was swift, with the impact being viscerally clear from the first day, and it continues to deliver value two years into Saronic's operations. -- Vibhav Altekar, Co-founder & VP of Software, Saronic > **"The adoption of Foxglove was swift, with the impact being viscerally clear from the first day, and it continues to deliver value two years into Saronic's operations."** Vibhav Altekar, Co-founder & VP of Software, Saronic [**Saronic**](https://www.saronic.com/) is a defense technology company that is redefining maritime superiority for the U.S. Navy and its allies. Saronic is delivering the most intelligent and advanced Autonomous Surface Vessels (ASVs) at the speed and scale required to meet the growing needs of the Joint Force. Working alongside human operated systems, Saronic's ASVs serve as force multipliers to existing fleets and enhance the operational capabilities of naval forces, allowing them to go farther and do more while reducing risk to human life and the mission. Two of Saronic ASVs in the water. ## Challenges without Foxglove Saronic is focused on building robust and reliable autonomy in their ASVs. The underlying piece of infrastructure that enables rapid iteration on their autonomy models is replayable services and complete levels of observability and visualization across their robotic platforms. The team at Saronic collectively experienced significant challenges in robotics development in the past - from scalability, visualization, and data management to velocity and focus. Founding and early members of the Saronic team previously struggled to collect multimodal data for debugging, replay data faster than real time, and build custom visualizations to better understand the data. They understood that they needed a plug-and-play method for extracting information from their subsystems and visualizing data to overcome these historic challenges and accelerate the development of their robotics platform. This led them to the adoption of Foxglove from day one. > **"The lift on building custom robotics development tooling, specifically visualization, is so high that it detracts from the goal of building features and autonomy for the robots."** Vibhav Altekar, Co-founder & VP of Software, Saronic ## Adopting Foxglove to accelerate development and scale Saronic's business The integration of Saronic's ASVs acts as a force multiplier and extends a fleet's area of influence while also expanding its operational capabilities to more effectively meet the needs of the modern maritime domain. Saronic is enabling this through collaborative autonomy and swarming capabilities that allow a single operator to control multiple vessels at once. This significantly reduces the cognitive burden on that operator. Foxglove is the force multiplier reducing cognitive load on Saronic's engineering and development teams, in the same way Saronic is to their customers. The main intention of deeply embedding Foxglove into their development workflows was to allow the team to focus on and accelerate building robust and reliable autonomy through rapid iteration. Foxglove, along with the combination of [**MCAP**](https://mcap.dev/), provides a plug-and-play solution for extracting, managing, and visualizing multimodal data from Saronic's robotic platforms. This significantly reduces the lift required to reinvent and develop the required tooling, while also keeping costs low. Developing complex tooling and visualizations requires dedicated engineers to design, implement and maintain. With Foxglove, Saronic's Autonomy and Perception team has reclaimed more than 20% of their time that would have otherwise been spent on crafting those complex visualizations and tools. The benefits of integrating Foxglove extend beyond the Autonomy and Perception team as well. Naval architects, mechanical engineers and non-technical staff are empowered to easily understand the impacts of design and implementation decisions using Foxglove's visualizations and data insights. For example, mechanical engineers can now understand improvements on steering designs and naval architects can realize improvements in hull design. The quick and easy data analysis that Foxglove provides gives individuals that generally have a slower development cycle a whole new view on engineering. ## The outcome and impact of using Foxglove Today, Saronic has 50+ engineers - which is more than 30% of the company - on-boarded to Foxglove, enabling teams to triage issues quickly and iterate faster on its software. Teams are also able to quickly pull logs following software testing, inspect and replay when issues are discovered, and have a new version available for testing in less than 24 hours. By partnering with Foxglove, Saronic is bringing their growing family of ASVs to market faster -putting critical autonomous capabilities into the hands of warfighters to reduce the risks associated with operating in high-stakes environments. A Saronic engineer using Foxglove. Bottom line, the streamlined workflows and improved collaboration facilitated by Foxglove continues to result in a faster time to market for new ASV features and capabilities across Saronic's product lines. The two-year-old company has a laser focus on their mission and continues to deliver on their promise to bring the most intelligent and advanced ASVs to the U.S. Navy and its allies, at scale. --- ### Scout AI: How Foxglove's unified interface accelerated Scout AI's Fury foundation-model development for defense robotics. URL: https://foxglove.dev/customers/scout-ai Industry: Defense & Aerospace Impact: - Tightened their train-deploy-diagnose-data loop - Unified operations, AI, and systems engineering around a single observability tool - Avoided building and maintaining another bespoke visualization stack The goal of the company is to iterate and build these models, but also the whole system... The faster you can get visualization and diagnostics, the faster you can be productive. -- Collin Otis, Co-Founder & CTO, Scout AI ## Overview To accelerate development of their Fury foundation-model, Scout AI relies on Foxglove as the unified interface for operating robots, monitoring live missions, debugging issues, and collecting high-quality training data. Foxglove gives their operations, systems, and AI teams a single tool for understanding robot behavior. Whether live in the field or offline in replay, it allows them to iterate faster and deploy more capable models across various robot domains. ### **Key Results** 1. Tightened their train-deploy-diagnose-data loop 2. Unified operations, AI, and systems engineering around a single observability tool 3. Avoided building and maintaining another bespoke visualization stack > **"The goal of the company is to iterate and build these models, but also the whole system... The faster you can get visualization and diagnostics, the faster you can be productive."** Collin Otis, Co-Founder & CTO, Scout AI ## The Challenge: Accelerate iteration on an end-to-end learned model. Scout AI is building Fury, a foundation model for military robotics that can reason over real-time sensor data and natural-language instructions, then coordinate a variety of air, ground, and maritime systems. At previous companies, the team lived through years of custom tooling: QT-based desktop visualizers on Linux, bespoke JavaScript/web visualizers backed by homegrown frameworks, internal plugins, and dashboards that were powerful but brittle. Those tools took significant engineering time to build and extend, and all would eventually become blockers that distracted from the core development focus. 1. **Night:** retrain models with the latest data 2. **Morning:** run new missions (both in real life and simulated) using the latest version of Fury 3. **Afternoon:** review data, commands, and outcomes 4. **Repeat** This quick, iterative approach creates several requirements: **Tight train-deploy-diagnose-data loop** Because it's an end-to-end learned system, diagnostics and data collection are two sides of the same coin. The team needs to spot model failures and simultaneously identify new data snippets ("trims") to feed into the next training run. **Multi-modal observability** They must reason over video, text, 3D trajectories, time-series telemetry, and human intent (prompts, spoken instructions) at once. **High-stakes operational constraints** Systems are deployed in safety-critical environments. As Collin puts it, "It's a very abusive environment, not just on hardware, but on software... people's lives are at stake... your stuff has to work." From the beginning, Scout AI knew they needed an out-of-the-box, extensible interface that didn't require them to build and maintain custom tooling. To train and deploy Fury, Scout AI runs robots five days a week at Forge, their unmanned systems training center near Paso Robles, California. Former Army and Special Operations personnel run realistic missions across their different vehicles, continuously generating data and stress-testing the model in both real world and simulated environments. They chose Foxglove for operating, debugging, and observing these systems to enable a fast iteration loop. > **"Building a UI is an impediment. If you have to build that before you can build your core product, that's a pain. Even when we tried to build really good UIs, they eventually became cumbersome. Foxglove allows us to focus on building our core product."** Collin Otis, Co-Founder & CTO, Scout AI ### **The Solution: Consolidating distributed teams and disparate workflows with Foxglove's unified robotics platform.** When starting development at Scout AI, the team already knew they needed: - A flexible, off-the-shelf visualization surface they wouldn't have to rebuild every year - Deep ROS and robotics support, with modern web-based collaboration - The ability to customize and extend behavior without owning all the visualization infrastructure themselves **Operating and monitoring live systems **Scout AI relies on Foxglove as the primary interface for running its robots. A custom Foxglove extension allows operators and engineers to view system state, monitor fleet status, start and stop logging, and trigger missions, both from a tablet at the Forge training center, or anywhere in the world remotely. Live WebSocket connections stream telemetry, video, and commands in real time. Foxglove also serves as Scout AI's fleet operations console. During data-collection runs, test flights, and field demonstrations, operations staff and engineers share the same layouts including control plots, system health, and 3D state, giving teams a unified view across air and ground systems. **Debugging through logging and replay **Every mission is logged onboard and uploaded to an S3 bucket. For investigations, engineers slice logs, convert them to MCAP, and replay them directly through Foxglove. This lets them inspect synchronized video, telemetry, controls, trajectories, and model outputs without recreating scenarios in the field. **Collecting training data with custom operator panels **Scout AI built a specialized panel in Foxglove to drive its data-collection workflows. Operators issue natural-language instructions or demonstrations and drop waypoints on a map; Foxglove packages the instruction, map context, and sensor streams into a prompt bundle that is logged for training. Operators can also stream microphone audio through Foxglove. The audio is logged, transcribed, and incorporated into model training, capturing "stream-of-consciousness" human reasoning paired with robot behavior. **Annotation workflows and training-data quality **AI technicians and operators use Foxglove to mark start/stop times, edit descriptions, and verify collected data. The AI team monitors data quality through the same interface, allowing them to focus on model architecture while maintaining high-integrity training datasets. **Demos for customers and stakeholders **Scout AI's everyday interface also functions as its demo platform. With Foxglove, teams can show live missions to defense customers, OEM partners, investors, and congressional staff, providing a clear, intuitive view of real-world autonomous operations. ## **Looking ahead** Scout AI is working toward one million agents running Fury across air, land, and sea. As they scale the diversity of platforms will grow, the complexity of multi-agent coordination will increase, and the importance of fast, reliable, shared observability will only become more critical Foxglove is the backbone of how Scout AI operates, observes, and iterates on its systems today -- from Forge's training missions to remote operations and AI research. As they expand their fleet and deployments, Foxglove looks forward to continuing being the chosen tool to close the loop between data, models, and real-world autonomy. --- ### Shield AI: How Shield AI transformed mission-critical development with Foxglove. URL: https://foxglove.dev/customers/shield-ai Industry: Defense & Aerospace Impact: - Accelerates autonomy development with real-time insight into decision systems. - Enables deep customization of visualization workflows without compromising performance. - Equips every Hivemind deployment with powerful out-of-the-box tools to understand and validate autonomous behavior. Foxglove gives our team a shared, real-time view into system behavior--making it easier to troubleshoot, improve, and deploy advanced autonomy with confidence. Paired with Hivemind, it accelerates development by turning complex decisions into clear, actionable insight. -- Stefan Jorgensen, Senior Staff Engineer, Shield AI > **"Foxglove gives our team a shared, real-time view into system behavior--making it easier to troubleshoot, improve, and deploy advanced autonomy with confidence. Paired with Hivemind, it accelerates development by turning complex decisions into clear, actionable insight."** Stefan Jorgensen, Senior Staff Engineer, Shield AI Shield AI's flagship autonomy product, Hivemind Pilot, enables systems to carry out complex missions using fully autonomous decision-making at the edge. Supporting it is Hivemind Forge--a full-featured autonomy development environment that lets developers prototype, test, and deploy quickly. To make that possible, engineers and operators alike need the ability to understand what's happening inside the system, resolve issues quickly, and assess improvements as they happen. That's where Foxglove comes in. Embedded directly into Forge, Foxglove gives Shield AI and its customers the clarity and speed they need to build world-class autonomous systems--faster and with greater confidence. ## The trust problem in defense robotics. As Shield AI began fielding autonomy with defense customers, iteration speed became critical--but legacy tools became a liability. Old workflows didn't just slow teams down; they made the autonomy harder to trust. Without a clear way to understand why an aircraft chose a specific flight path, operators were left with black-box behaviors in high-stakes environments. Foxglove changed that. Its modern, extensible visualization platform made it easy to inspect behavior, trace logic, and uncover issues in real time. Instead of patching together brittle, ROS-dependent tools, developers could build dynamic panels tailored to their systems. With Forge, teams no longer had to pore over logs hours after a flight--they could debug, tune, and verify autonomy as it happened. Together, Foxglove and Forge not only sped up development but also made autonomy easier to interpret and understand, building greater trust in the systems we deploy. > **"Foxglove eliminated the overhead of maintaining internal visualization tools, letting our engineers focus on what matters most--advancing core autonomy."** Stefan Jorgensen, Senior Staff Engineer, Shield AI ## From bottleneck to competitive advantage. Shield AI embedded Foxglove directly into Forge's core. Foxglove's cloud-native architecture, multi-platform support, and ROS-independence made it ideal for Shield AI's evolving stack. Engineers quickly built mission-specific tools for inspecting behavior trees, configuring agents, monitoring critical events, and visualizing internal state. Every Hivemind deployment ships with Foxglove, giving customers deep visibility into autonomy operations from day one. These aren't support tools--they're operational infrastructure. Whether it's a military developer validating sensor alignment, a test pilot reviewing decision traces, or a mission lead analyzing logs post-flight, Foxglove provides a shared interface to understand autonomy operations. Paired with Forge, it empowers customers to use the Hivemind SDK to build sovereign autonomy capabilities they can fully trust--and do so in record time. ### Autonomy in action. In a complex find, fix, and track mission, a fleet of Hivemind-powered autonomous aircraft could be tasked with locating multiple high-value objects across a broad operational area--all while navigating no-fly zones and managing comms in GPS-denied airspace. Each agent autonomously claims part of the search grid, plans its route, and coordinates sensor sweeps with the rest of the team. If one aircraft identifies a potential object of interest, it reassigns itself to investigate, handing off its responsibilities to others. Simultaneously, another agent might reposition to act as a "bridge" agent--positioning strategically extending the team's mesh network to preserve communications. All of this happens onboard, without centralized control. And with Foxglove, ground teams can observe it all in real time--watching agents self-organize, adapt, and execute mission logic with precision. It transforms autonomy from something opaque into something observable--making it possible not just to deploy intelligent systems, but to understand them. > **"With Foxglove and the SDK, anyone on the team can contribute--what used to take months now takes days, and for our customers, that means reaching first autonomous flights in weeks instead of years."** Stefan Jorgensen, Senior Staff Engineer, Shield AI ## The impact: Speed, trust, and mission success. What once took weeks now happens in days. When Hivemind Pilot changes altitude during a resupply test, developers immediately see why--and in collaboration with the vast suite of capabilities that Hivemind provides, they can tweak and retest in the same day. This real-time feedback loop supercharges the fly-fix-fly rhythm, enabling capabilities that once took years to develop to now come online in weeks. Foxglove ships with every Hivemind deployment, supporting U.S. and allied customers in labs, test flights, and field operations. It is part of the daily autonomy development cycle--driving faster iteration, tighter collaboration, and greater confidence in the systems we build. As the U.S. and its allies modernize their approach to airpower, Shield AI continues to push the frontier of autonomous capability with Hivemind. Foxglove is there at every step, making autonomy as understandable as it is unstoppable. --- ### Simbe Robotics: How Simbe leverages Foxglove to scale across thousands of retail locations globally. URL: https://foxglove.dev/customers/simbe Industry: Logistics Impact: - 90%: reduction in time to get a .bag file off the robot and play it back. - 4x reduction: in tools incl. replacing all in-house tools - Greatly: reduced escalations from operations team to engineering team. Adopting Foxglove had an immediate positive impact, enabling us to quickly identify the root cause of a problem we were dealing with that week. -- Mirza A. Shah, CTO and Co-founder, Simbe > **"Adopting Foxglove had an immediate positive impact, enabling us to quickly identify the root cause of a problem we were dealing with that week."** Mirza A. Shah, CTO and Co-founder, Simbe Simbe Robotics stands as the leading and only multimodal provider of retail automation technologies, revolutionizing the experience for both retailers and their customers through cutting-edge robotics and artificial intelligence. Simbe's flagship product, Tally, is a robot that autonomously scans store shelves to deliver real-time insights on inventory levels, pricing accuracy, and product placement. Powered by its Store Intelligence™ platform, Simbe equips retailers worldwide with essential data that enhances store operations, boosts revenue, and increases overall efficiency. With operations spanning the U.S., Canada, Europe, and Asia, Simbe supports nearly 1,000 stores, including major retailers such as Carrefour and Giant Eagle, across a diverse range of retail sectors. Simbe robotics software engineer, Cem Ersoz, using Foxglove. ## Challenges without Foxglove Before adopting Foxglove, Simbe's Robot Software Team faced several challenges in managing their development and debugging workflows. Specializing in robot navigation, planning, autonomy, and perception, the team relied on .bag files, custom scripts, and a variety of visualization tools like RViz and PlotJuggler. This fragmented setup required manual data synchronization from robots to developers' local machines, leading to unnecessary delays and inefficiencies, especially in a remote work environment. Debugging tasks such as analyzing motion behaviors, velocities, and odometry data were cumbersome, requiring developers to juggle multiple windows and tools, which created unneeded complexity in the workflow. Additionally, sharing insights with other departments involved time-consuming screen video captures, instead of simply providing a direct link to the relevant data. The biggest challenge Simbe developers faced was transferring large bag files from the robots to their local machines for playback in Rviz and other tools. Even though they built simplified tools to sync and playback with a single command, the process remained cumbersome and slow, causing developers to hesitate before using bag files unless absolutely necessary. ## Adopting Foxglove The decision to integrate Foxglove into Simbe's workflows was primarily driven by the need to streamline high-fidelity playback of past operations from its robot fleet. Foxlet enabled this by auto-indexing bag files onboard the robots and visualizing them in Foxglove's intuitive timeline view for easy playback. Users no longer needed to download bag files to their local machines or use a Linux machine with specialized software. Now, they can playback robot data from any device with a web browser, including their phones. With Foxglove events, developers can instantly identify the bag files of interest, reducing the need to sync just a few hundred megabytes of targeted files instead of 15 gigabytes for an entire Tally scan. This eliminated all hesitation for developers to use bag files as a first resort for problem analysis, rather than relying on lower-fidelity methods. Foxglove Timeline view for Tally robots > **"It just works."** Mirza A. Shah, CTO and Co-founder, Simbe Integrating Foxglove transformed Simbe's approach to managing and analyzing robot data, significantly improving efficiency. The ability to pause, rewind, and speed up playback as easily as a YouTube video was a game changer, especially when combined with real-time event generation. This feature allowed the team to create and track critical events, such as delocalization, in real time. Additionally, Foxglove's synchronized visualization capabilities streamlined debugging by displaying live graphs and visual data in a single pane, eliminating the need for a combination of tools like Rviz, Plotjuggler, and Rqt. With the added support of VPN, the team can now even live-debug robots on the other side of the world, further enhancing their ability to manage and maintain global operations seamlessly. Playback of a .bag file generated by Tally on Foxglove's 3D panel. > **"Foxglove has been transformational for Simbe and has become a crucial tool as we rapidly scale our fleet in response to surging global demand. It fills a longstanding gap in the ROS ecosystem."** Mirza A. Shah, CTO and Co-founder, Simbe ## The outcome and impact of using Foxglove Simbe significantly streamlined its workflows with Foxglove, particularly in .bag file management, data sharing via web links, and event-based debugging. By automatically syncing ROS data and events in real time, the team reduced manual processes and shortened the time required to investigate and resolve field issues. This also supported Simbe's collaborative environment, allowing both technical and non-technical teams to access and interpret robot data through Foxglove's user-friendly interface. Foxglove democratized robot visualization across the entire organization. No longer limited to robotics engineers, operations and business teams can now access the same visual data without needing technical assistance, simply by sharing a link. This broadened access has made it easy for anyone in the company to gain insights into the robot fleet. The qualitative improvements in debugging efficiency and cross-team collaboration have been evident across the business, further enhancing Simbe's ability to innovate and scale. One of the most notable impacts was the ability to generate automated field events, enabling the team to monitor and investigate more incidents without increasing resource demands. By centralizing data and visualizations, Foxglove empowered Simbe's Robot Software Team to rapidly diagnose and resolve issues, contributing to the company's mission of elevating retail performance through advanced automation. --- ### Slip Robotics: How Slip Robotics improved autonomous freight reliability using Foxglove. URL: https://foxglove.dev/customers/slip-robotics Industry: Logistics Impact: - 90%: debugging time saved. - 30%: increase in fleet uptime. - 5x: issue resolution speed. Foxglove didn't just make our engineers more efficient--it made our entire company more agile, enabling faster deployments, better customer support, and greater reliability across the board. -- Dennis Siedlak, CTO and Founder at Slip Robotics > **"Foxglove didn't just make our engineers more efficient--it made our entire company more agile, enabling faster deployments, better customer support, and greater reliability across the board."** Dennis Siedlak, CTO and Founder at Slip Robotics Slip Robotics is transforming short-haul freight transport with autonomous loading and unloading robots (SlipBots) designed to optimize supply chain logistics. Their SlipBot platform automates high-frequency truck movements between warehouses, factories, and distribution centers, reducing manual labor and operational delays. The company emerged from the realization that a significant portion of supply chain inefficiencies occur not on the road but in the moments between loading and unloading. By enabling seamless, autonomous freight transfers, Slip Robotics helps manufacturers and distributors increase efficiency, cut costs, and improve throughput without requiring significant infrastructure changes. Two Slip Robotics SlipBots carrying loads. ## Debugging workflows slowed troubleshooting and growth without Foxglove. Before adopting Foxglove, Slip Robotics relied on a fragmented set of tools for debugging and analyzing robot telemetry. Engineers manually downloaded large ROS bag files from AWS S3, wrote custom scripts to extract relevant data, and pieced together logs to diagnose issues. The process was time-consuming and inefficient, often taking 10 minutes or more just to retrieve the right dataset before even beginning analysis. Live debugging required setting up complex ROS networking configurations, making remote troubleshooting impractical. Non-engineering teams had limited access to robot telemetry, which meant that diagnosing operational issues often required waiting on developers to interpret data. Sharing debugging insights between teams was cumbersome, with files being manually uploaded and passed around, leading to delays in troubleshooting and issue resolution. As Slip Robotics scaled its fleet, these inefficiencies compounded, making it clear that their existing workflows could not support long-term growth. > **"With Foxglove, we've removed the friction in debugging--what used to take hours across multiple tools now happens in minutes, all in one place."** Dennis Siedlak, CTO and Founder at Slip Robotics ## Reducing operational overhead with Foxglove. Integrating Foxglove into Slip Robotics' workflow required minimal changes to their existing infrastructure. A single AWS Lambda function update enabled automatic ingestion of ROS bag files into Foxglove's platform, eliminating the need for engineers to manually retrieve and process logs. With Foxglove's API, they transitioned from running custom AWS queries and stitching together raw files to directly accessing structured telemetry data. Engineers adopted Foxglove's visualization tools immediately, using them to inspect robot motion, sensor data, and diagnostics without relying on manual scripting or multiple debugging tools. Slip Robotics also integrated Foxglove's API into their automated monitoring pipeline, enabling real-time telemetry tracking across deployed robots. They implemented scripts that pull targeted diagnostic data--such as motor currents and sensor health--without requiring full dataset downloads. Field teams incorporated Foxglove deep links into their workflows, allowing them to flag and share relevant log data directly with engineers and customer success managers. This eliminated the previous need for manual file transfers and log searches, streamlining collaboration between on-site teams and engineering. A Slip Robotics engineer observing a SlipBot. Outside of development, Slip Robotics extended Foxglove to their field support and customer success operations. They embedded Foxglove links in reports and automated alerts, ensuring that both technical and non-technical teams could access real-time robot performance data instantly. Within days, they transitioned from a fragmented, manual debugging process to a fully integrated, centralized system, allowing teams across the company to inspect and diagnose robot behavior without delays or engineering dependencies. Slip Robotics' primary Foxglove layout. > **"Foxglove lets us scale without worrying about bottlenecks in debugging and maintenance."** Dennis Siedlak, CTO and Founder at Slip Robotics ## Using Foxglove increased reliability and enabled scaling efficiently. Engineers now spend less time handling ROS bag files and more time refining robot behavior, improving autonomy, and deploying new features. Debugging sessions that once required complex ROS networking setups are now handled instantly with a single Foxglove link, reducing turnaround time for troubleshooting and accelerating issue resolution. Leveraging Foxglove's API enabled Slip Robotics to shift from reactive to proactive maintenance, detecting early signs of motor degradation, sensor drift, or communication failures before they impact operations. Automated monitoring scripts analyze real-time data trends, allowing engineers to flag potential failures and schedule maintenance before robots go out of service. These insights ensure maximum uptime, increasing fleet reliability and reducing costly disruptions for customers. Foxglove has also improved cross-team collaboration, making robot performance data accessible beyond the engineering team. Field technicians and customer success managers can inspect real-time diagnostics and share time-synchronized visualizations without needing engineering intervention. The ability to instantly generate and share pre-filtered Foxglove deep links has eliminated the need for manual log retrieval, allowing teams to troubleshoot remotely and resolve issues faster. By integrating Foxglove, Slip Robotics has accelerated its ability to diagnose and resolve issues, strengthened its operational reliability, and positioned itself to scale its autonomous logistics platform with confidence. --- ### Square Robot: How Square Robot became an industry leader using Foxglove. URL: https://foxglove.dev/customers/square-robot Industry: Inspection Impact: - 50%: debugging time saved. - 100's: of development hours saved. - Slashed: time to market for new features. Foxglove cut our debugging time in half, allowing us to deliver new features and fixes faster than ever, improving both our operational efficiency and competitiveness. -- Brenden Gibbons, VP of Software Engineering at Square Robot > **"Foxglove cut our debugging time in half, allowing us to deliver new features and fixes faster than ever, improving both our operational efficiency and competitiveness."** Brenden Gibbons, VP of Software Engineering at Square Robot Square Robot, founded in 2016 in Boston, Massachusetts, is a robotics technology company at the forefront of submersible robotic inspections for aboveground storage tanks (ASTs). The company serves a wide range of industries including midstream, downstream, petrochemical, utilities, rail, and mining, offering a safer and more cost-effective alternative to traditional tank inspections. Square Robot's mission is to keep critical infrastructure online, reduce emissions, eliminate hazardous confined space entries, and increase operational efficiency. Their innovative approach provides comprehensive inspection services, delivering high-fidelity data through a fleet of specialized robots designed to operate in challenging environments around the world. One of Square Robot's robots being deployed. ## Challenges without Foxglove meant multiple tools and lengthy debugging times. Prior to adopting Foxglove, Square Robot's development and operations workflows relied on open-source Robot Operating System (ROS) tools like RViz and rqt, alongside command-line utilities for data inspection and debugging. While mostly functional for software developers, these tools posed major barriers to other departments, such as Systems and Electrical Engineering, who lacked the configured Ubuntu-based ROS environments necessary to access and interpret robot data. Field engineers faced additional hurdles, having to maintain dual-boot setups on their laptops to switch between Ubuntu and Windows. This configuration slowed their ability to interact with robots in hazardous environments and complicated real-time operations. Collaboration across departments was a recurring bottleneck. When field reports identified issues, developers manually sifted through rosbags uploaded to cloud storage, often exporting data repeatedly in csv format to share with other teams. This process was slow, inconsistent, and resource-intensive, with multiple engineers replicating the same work across different machines and operating systems. As Square Robot scaled its robotic operations globally, the limitations of this workflow threatened to undermine efficiency and response time, making it clear that a more scalable, accessible solution was needed. ## Adopting Foxglove streamlined workflows and enabled collaboration. The decision to integrate Foxglove was driven by a need for greater cross-department collaboration and streamlined data management. Initially, a small subset of the software team evaluated Foxglove for daily development tasks. The team confirmed that critical data visualizations--such as sensor outputs, 3D environments, and camera feeds--along with easy, in-depth analysis, worked seamlessly within Foxglove. With these early successes, the company phased out its reliance on RViz and other ROS-based tools to adopt Foxglove company-wide. A Square Robot engineer using Foxglove. Foxglove's cloud-based data management revolutionized how Square Robot managed rosbags. Instead of downloading files from an S3 bucket and manually reproducing visualizations, teams could now upload and access data through a centralized interface. This simplified debugging workflows, allowing multiple departments to collaborate on the same data in real time. Field operations also saw immediate benefits. By transitioning entirely to Windows-based laptops, field engineers eliminated the need for dual-boot setups. A very short time spent reviewing Foxglove's user interface was all it took for field teams to seamlessly connect to robots and access real-time data. Within less than a month, Foxglove was fully operational across Square Robot. The integration not only reduced IT overhead but also enabled faster diagnosis and resolution of issues, ultimately enhancing the company's ability to scale its global operations A Foxglove layout configured by Square Robot. > **"With Foxglove, everyone--from software engineers to field teams--can quickly understand and analyze robot performance without needing specialized environments."** Brenden Gibbons, VP of Software Engineering at Square Robot ## The impact of using Foxglove scaled operations around the globe efficiently. Foxglove fundamentally transformed Square Robot's ability to execute its mission. The platform addressed a critical business problem by eliminating bottlenecks in data sharing and enabling efficient cross-departmental collaboration. Where teams once struggled to maintain consistent visualization environments, Foxglove provided a solution that worked across multiple operating systems and required no specialized setups. This shift reduced debugging time by 50%, saving hundreds of hours in manual data handling and redundant analysis. Field engineers no longer needing dual-boot configurations significantly lowered IT overhead and improved on-site responsiveness. New employee onboarding also accelerated, with hires able to start visualizing and debugging data within hours instead of days. The streamlined workflows enabled by Foxglove have accelerated development cycles, reducing time to market for new features and fixes. These efficiencies positioned Square Robot to scale its operations globally with confidence. By empowering their teams with the tools to diagnose and resolve issues faster, Square Robot continues to provide safer, more efficient, and more environmentally friendly inspections to its customers, reinforcing its leadership in robotic AST inspection services. --- ### Tangram Vision: How Tangram Vision slashed customer onboarding from months to days with Foxglove. URL: https://foxglove.dev/customers/tangram-vision Industry: Automotive Impact: - Weeks to a day: Time to convert pilot users - Up to 3 months: Customer onboarding time saved - 20% increase: Volume of new customers Every time we moved data from point A to point B, we encountered an extreme amount of friction. When your value proposition is saving customers months of work, but your own process takes weeks to establish, it's not good value. -- Brandon Minor, CEO of Tangram Vision [Tangram Vision](https://www.tangramvision.com/) helps robotics teams building sensor-enabled products scale their perception stack - from one proof-of-concept robot to an entire fleet. Whether you're adding new sensing modalities, layering on perception algorithms, or simply trying to get your cameras and lidars to communicate with each other, Tangram's software takes these esoteric tasks off of your engineers' to-do lists and magically makes all of it work. But over the last year, Tangram began to realize that it was taking too long to get their software up and running at customer sites. To assess customers' data, Tangram engineers had to visit their robots in person, bring the data back to their offices, and convert it into a supported format to finally inspect it. In short, Tangram lacked a unified solution for robotics observability. By adopting Foxglove and the MCAP file format, Tangram was able to slash their onboarding workflows from months to days. ## Challenges ### Spending weeks to demonstrate value to customers When engaging with a new customer, Tangram Vision takes them through a pilot process to demonstrate the value of integrating with their software. Before adopting Tangram, customers typically want to first see it adding concrete value to their development efforts. Before integrating with Foxglove, this typically meant traveling on-site to the customer to collect sample data off a physical robot. Tangram engineers then offloaded this data, took it back to their offices, converted it into a supported format, and inspected it with their internal data visualization tooling. At this point, they could discover critical issues - parts of the data could be corrupt, unusable, or missing altogether. They would then work with the customer to fix these issues - by either scheduling time to come back on-site or guiding the customer's engineers through sending another data set. Once they finally have "good data" to work with, Tangram can process it with their software to assess the customer's existing perception processes and provide actionable recommendations for leveling up their system. > **"Every time we moved data from point A to point B, we encountered an extreme amount of friction. When your value proposition is saving customers months of work, but your own process takes weeks to establish, it's not good value."** Brandon Minor, CEO of Tangram Vision This entire process could easily take weeks to complete, depending on the state of customers' data. Not catching issues early often introduced days to weeks of delays. Other unforeseen issues - like the designated robot now being busy for a week, out of commission due to hardware issues, or partially disassembled for maintenance - could make the back and forth needed to get this sample dataset even longer. ### Hard-to-scale consultative work Currently, robotics development is a very fractured ecosystem, and no two robotics stacks are alike. For Tangram Vision, every individual integration meant getting to know a new stack with its own unique requirements. This made onboarding new customers incredibly manual, as each one required an unsustainable amount of time and assistance for configuration and validation. Not only did this stretch out the time needed to convert a pilot user into a paying customer, it also limited the number of new customers Tangram could take on at any given time. > **"Instead of operating as a software company, we were falling into the trap of providing consulting services - which was neither the plan nor a scalable strategy."** Brandon Minor, CEO of Tangram Vision Tangram Visions's customers also recorded their data in a wide range of serialization formats, further contributing to onboarding friction. When accepting and juggling these different formats for validation, Tangram had to invent ways to organize each customer's files - with methods as basic as using different Google Drive folders for different types of sensor data. Even after collecting the right data, Tangram then had to consult closely with the customer's engineers to integrate that unique data with their software. All this unstandardized data collection made it difficult to collect accurate, complete, and synced customer data both quickly and repeatedly. ### Wasting resources on undifferentiated tooling Tangram Vision developed their own data visualization tooling in-house to help them understand customer data. While the tool initially served their purposes, it quickly became clear that building robust visualization software was neither the team's interest nor specialty. As the customer base grew and development work scaled, it became increasingly difficult to maintain this visualization code. Tangram engineers struggled to keep pace with new and changing requirements, especially while serving customers that weren't using a unified format for their data. Whenever Tangram changed anything in their perception software, engineers would then have to spend a day tending to the newly broken visualization features downstream and updating rendering logic to adapt to the changes. ## Adopting Foxglove to streamline processes ### More efficient customer onboarding with MCAP Tangram Vision adopted [**MCAP**](https://mcap.dev/) as their preferred file format for collaborating on data - both internally and with customers. This has provided all parties with a common data language and some much-needed consistency, making it infinitely easier for Tangram to support their customers. By collecting and evaluating data in one standard format, Tangram Vision can now understand the state of their customers' processes - and demonstrate the worth of their software - in record time. Instead of taking each customer's uniquely formatted data files back to their workstations for bespoke conversion, deciphering, and analysis, they can feed all of it through the same process. Even for new customers that haven't already made the transition to MCAP, they can easily point them to the provided CLI tool to convert their data files with a few simple commands. > **"We can now provide a path forward for customers - and prove our worth to them - within 24 hours. They can immediately understand the impact of working with us. This time last year, that same process took weeks. Now, we're getting it down to minutes."** Brandon Minor, CEO of Tangram Vision Recording in MCAP has also resulted in much more lightweight files, making it easier than ever to ingest data off the robot, send files back and forth, and load them for validation. Instead of waiting days or weeks to inspect a customer's data, Tangram engineers can now offload the robot's newly recorded MCAP files, load them directly into Foxglove for visualization, and immediately surface any critical issues - all while they're still on-site with the customer. ### Increased bandwidth to take on new customers By adopting MCAP and Foxglove, Tangram Vision has been able to take stock of critical friction points in their customer onboarding and streamline each of them, one by one. Instead of having to juggle different data formats, maintain in-house visualization tooling, or provide customer-specific integrations, Tangram can now rely on the Foxglove platform to do most of the heavy lifting. Every step that required Tangram's consultative knowledge has been standardized and simplified, so that they can spend less time holding their customers' hands and more time building cutting-edge perception infrastructure. > **"Adopting Foxglove and MCAP has freed up more of our time and empowered us to take on a higher volume of customers."** Brandon Minor, CEO of Tangram Vision The Foxglove integration has also unlocked new sales opportunities for Tangram Vision. Since they no longer have to provide as much consulting, the entire customer onboarding process has become much more self-serve and sustainable than ever, meaning more bandwidth to pursue new leads and onboard more users. ### Extending out-of-the-box visualizations with powerful customizations Instead of spending their own resources building and maintaining a homegrown data visualization tool, Tangram Vision now relies on Foxglove's expertise to explore and analyze their customers' data. Thanks to Foxglove's extensibility, the team has been able to build on top of the general-purpose feature set to address their perception-specific needs. Some engineers have authored custom data exploration panels and arranged them into a shareable layout to visualize their customers' calibration results. Even though these features did not come out-of-the-box, building these modular extensions were a relatively straightforward process that required much less work than building an entire visualization suite from scratch. Tangram engineers have been able to apply this one summary view across a wide range of customers, sensors, and robotics applications, further streamlining their debugging and customer onboarding workflows. ## Outcome By adopting MCAP and Foxglove, the Tangram Vision team has been able to cut entire weeks out of their pilot onboarding process. They can now get concrete results for their customers within minutes of receiving their data, subsequently extend the proof of concept to days of deployment, and then set their sights on engaging with the next set of customers. With this streamlined data collection and customer collaboration process, Tangram Vision no longer has to waste months of precious time performing repetitive data cleaning tasks or navigating each customer's unique setup. Instead, their team can focus their efforts wholly on their actual mission - building perception tooling that helps robotics teams manage the growing complexity of their sensor systems. --- ### Third Wave Automation: How Third Wave Automation scales their autonomous warehouse fleet using Foxglove. URL: https://foxglove.dev/customers/third-wave-automation Industry: Logistics Impact: - Reduced: debugging times from hours to minutes. - Saved days: on development cycles. - Removed: developer friction. Many triaging tasks that once took an engineer an hour to diagnose using our home-grown tools now take just 10-15 minutes with Foxglove. -- Titus Klinge, Staff Software Engineer at Third Wave Automation > **"Many triaging tasks that once took an engineer an hour to diagnose using our home-grown tools now take just 10-15 minutes with Foxglove."** Titus Klinge, Staff Software Engineer at Third Wave Automation Third Wave Automation is transforming warehouse logistics with its Shared Autonomy Platform, a system designed to enhance forklifts with perception, motion planning, and AI-driven autonomy. The platform enables seamless transitions between fully autonomous operation, human-assisted interventions, and manual control, making it a flexible and scalable solution for the industry. Third-party logistics providers, including Holman Logistics, rely on Third Wave Automation to increase efficiency, improve safety, and optimize operations. As these companies scale, they need automation that can handle real-world warehouse complexities while maintaining human oversight. Third Wave Automation's forklifts integrate advanced perception models, motion control systems, and real-time monitoring, ensuring consistent, reliable performance in high-demand environments. A Third Wave Automation robot operating autonomously in a warehouse. ## Manual debugging bottlenecks slowed autonomous fleet development before Foxglove. Before integrating Foxglove, debugging was an inefficient, manual process that required engineers to piece together information from multiple sources. Third Wave Automation stored logs in an internally developed format. While this logging format was efficient, the team relied on a tedious process of setting up a Jupyter Notebook--and other tools--for every debugging and analysis session. Extracting relevant data required manually loading logs, selecting time ranges, and writing custom scripts for visualization. Interpreting perception data was even more challenging. The team used Jupyter notebook plotting tools to analyze sensor outputs, but these visualizations lacked the spatial depth required to fully understand forklift perception failures. Debugging an issue often involved sifting through raw numerical data and cross-referencing it with multiple independent plots, making it difficult to determine whether a forklift had misinterpreted its environment or if a detection failure had occurred. On-site debugging introduced another layer of complexity. Engineers at customer locations had to manually retrieve logs from on-site servers, which often faced storage limitations or procedural challenges, restricting the amount of data available for analysis. These roadblocks meant that diagnosing an issue could take hours--before even determining an appropriate fix. Efficient collaboration was also a challenge. Engineers often shared screenshots of log outputs in issue reports, providing only a static snapshot of a problem without any interactive context. Debugging was rarely a one-person task, yet team members had no efficient way to step through logs together or replay events in a structured way. Each investigation required multiple back-and-forth exchanges, and without an intuitive way to share insights, debugging remained a slow, disconnected process. As the company expanded its autonomous forklift fleet, these inefficiencies became a bottleneck. Debugging issues at scale required faster iteration, better tools for visualizing complex interactions, and a way to seamlessly share insights across teams. The need for a more efficient, centralized debugging solution became clear. > **"Foxglove made debugging far more interactive and efficient."** Titus Klinge, Staff Software Engineer at Third Wave Automation ## Adopting Foxglove streamlined debugging and development. Recognizing these challenges, Third Wave Automation sought a solution to streamline its development workflow. The team began by integrating Foxglove, first addressing their fragmented log analysis process. When offloading logs, they convert their internal logs to MCAPs, so engineers can easily take advantage of Foxglove's State Transitions, Plot, and 3D panels, three widely adopted and favored panels. With an automated pipeline to process and offload logs from forklifts in the field, data that once required manual retrieval and setup was now accessible for analysis through Foxglove's data management--within minutes. A Third Wave Automation Engineer using Foxglove. The impact was immediate. Instead of manually retrieving data and setting up Jupyter notebooks, engineers could now open Foxglove and start debugging immediately. The State Transitions panel allowed them to track changes in state across a detailed timeline, making it easy to pinpoint when a failure occurred. Instead of writing custom scripts for log parsing, they could step through messages frame by frame, reconstructing events with far greater efficiency. Perception debugging became more structured with Foxglove's 3D panel. Engineers could now inspect point clouds, verify sensor alignment, and analyze object detection failures effectively. Rather than relying on fragmented 2D plots, they could visually confirm how forklifts were interpreting their surroundings, helping them validate perception models with greater confidence. Foxglove quickly became the primary tool for post-run analysis, recorded log debugging, and collaborative issue resolution. Shifting from manual log processing to a centralized, structured debugging workflow eliminated inefficiencies, optimized development cycles, and saved valuable time--accelerating innovation. Third Wave Automation's primary layout in Foxglove. > **"Foxglove has become an essential part of how we analyze and improve autonomy."** Titus Klinge, Staff Software Engineer at Third Wave Automation ## The impact of using Foxglove scaled development and increased fleet reliability. With Foxglove integrated into its workflow, Third Wave Automation reduced debugging time from hours to minutes, improved visibility into perception failures, and established a more structured development process. Engineers can now quickly analyze system behavior, leading to more reliable perception models and faster iteration cycles, reducing the time required to test and deploy improvements. Collaboration has also become more seamless. Instead of relying on static screenshots, engineers share direct Foxglove session links, enabling multiple team members to step through logs together and analyze data in real-time. This shift has eliminated inefficiencies in debugging, making it easier for teams to diagnose and resolve issues faster. With a more efficient development process, Third Wave Automation is scaling its autonomous material-handling fleet with greater agility while staying focused on advancing the future of warehouse automation. --- ### Waabi: How Waabi saved months of development time with Foxglove. URL: https://foxglove.dev/customers/waabi Industry: Automotive Impact: - Drop-in-place tagging system: Faster triaging - Foxglove API endpoints: On-demand data streaming - Panels and custom extensions: Rapid development and debugging We knew we wanted to leverage off-the-shelf developer tooling where possible - especially because we saw how costly it had been for other companies to reinvent the wheel. By adopting Foxglove, we were able to focus on our unique differentiators. -- Daryn Nakhuda, Head of Software at Waabi Self-driving companies have historically relied on hand-crafted and hand-tuned algorithms for autonomy software development, but Waabi is taking a different approach. They're opting for a more scalable method by harnessing AI to power every aspect of their development. Waabi has built a groundbreaking AI-based simulation system and virtual driver for autonomous trucking operations--one that can generalize more effectively across various real-world scenarios. As Waabi began its self-driving journey, the team recognized the need to navigate dense data, organize test results, and resolve issues quickly. They knew that laying the proper groundwork would accelerate future development, but building a complete robotics observability platform would require a significant investment of time and resources. By adopting Foxglove and the MCAP file format, Waabi was able to hit the ground running. The team leveraged Foxglove's robust foundation to accelerate their development and testing processes, while also streamlining collaboration. A Waabi engineer using Foxglove. ## Adopting Foxglove to learn faster and accelerate development ### Understanding their data to get to market faster. As a 'late mover,' Waabi has had the advantage of observing how other robotics teams have operated--and often failed. Historically, robotics companies have built bespoke versions of similar tools to organize data, triage incidents, and debug issues. However, creating a world-class developer tool suite that meaningfully accelerates work can take years--requiring the staffing of a full-time internal team, building a workable MVP, and maintaining the software with bug fixes and new features. These autonomous driving companies were burning valuable resources on duplicated efforts that didn't align with their core competencies or ultimate goals. As Waabi began developing their virtual driver software, they were determined to avoid making the same mistake. They integrated Foxglove to access ready-to-use tooling with minimal setup. Instead of reproducing Foxglove's features in-house, Waabi enabled their engineers to hit the ground running, allowing them to focus on what they do best--applying cutting-edge AI and ML research to build autonomy and simulation software. > **"We knew we wanted to leverage off-the-shelf developer tooling where possible - especially because we saw how costly it had been for other companies to reinvent the wheel. By adopting Foxglove, we were able to focus on our unique differentiators."** Daryn Nakhuda, Head of Software at Waabi A Waabi truck on a highway. ### Recording drive data in a common format. Waabi adopted [**MCAP**](https://mcap.dev/), Foxglove's open-source file format, as a unified data format to represent their driving data. They sought an efficient append-only file format to minimize on-vehicle overhead, while also requiring time-indexing and topic partitioning to retrieve arbitrary data subsets on demand. Paired with Foxglove, the MCAP format helped Waabi achieve these goals without needing their engineers to create custom formats and data pipelines. With MCAP, the team adopted a common data language. Instead of worrying about different subsets of their multimodal data being recorded in various formats, they could store everything in one place, organize it consistently, and inspect it using the same suite of tools. Rather than wasting time converting data into different formats or switching between tools for various tasks, the team could focus on uploading data, debugging issues, and improving their autonomy software. ### Streamlining cross-team collaboration. While Waabi initially adopted Foxglove to streamline development for its autonomy engineers, numerous teams across the company now use the platform for a wide range of tasks--including inspecting driving logs, identifying key scenes for triage, and visualizing data while the system is on the road. Waabi engineers have also been annotating their data with Foxglove events to mark interesting scenarios encountered by robots on the road. By evaluating metadata across multiple events, Waabi can easily categorize these scenarios into relevant buckets for further analysis. This tagging feature has helped the team augment their simulation scenario test suite and improve their autonomy models. Composing rich debugging and visualization workspaces in Foxglove, and sharing them with team members, has accelerated Waabi's root cause analysis processes. These Foxglove layouts make it easy to build a collection of ready-to-go dashboards for the entire company to use. Sharing a snapshot of a workspace for collaboration has now become as simple as copying and pasting a link. A waabi engineer using Foxglove while in the cab of one of their trucks. ## The impact of using Foxglove Foxglove has become a critical part of Waabi's development toolchain. It has allowed the Waabi team to stay focused on building innovative AI-powered software for its virtual driver and simulation platform, while relying on a solid visualization and data indexing platform. Foxglove has enabled Waabi to better organize its driving data, allowing the team to inspect, tag, and visualize both on-the-road and simulated behaviors, as well as debug autonomous driving performance. These features have helped Waabi visualize how well their latest features perform and use those insights to prioritize their development roadmap as they rapidly progress toward bringing safe and scalable self-driving truck technology to the road. --- ### Wayve: How Wayve learns faster with Foxglove. URL: https://foxglove.dev/customers/wayve Industry: Automotive Impact: - Hours or days to minutes or seconds: reduced time to triage an event - Centralized tooling for experimentation: fewer internal developer tools Foxglove helped us to supercharge our processes. We went from days to minutes when finding the root cause of an issue. -- J'aime Laurenson, Product Lead at Wayve Instead of relying on hand-coded rules or HD maps like industry incumbents, Wayve is building a self-driving system powered entirely by data and machine learning. By developing end-to-end AI software that can generalize across different geographies and vehicle platforms, Wayve aims to be the first autonomous vehicle company to deploy its technology in 100 cities. As an AI-focused company, Wayve continually seeks ways to increase the volume of experiments the team can run in each development cycle--more experiments mean more data to feed into their foundation models and faster improvements for their autonomy software. As Wayve's operations scaled, they needed an observability platform to efficiently understand what was happening under the hood of their vehicles. By adopting Foxglove and the MCAP file format, Wayve has consolidated its tooling, streamlined debugging, and gained faster, actionable insights from their experiments--propelling them towards their mission of deploying self-driving technology globally. A Wayve engineer using Foxglove with a Wayve AV behind them. ## Challenges without Foxglove Wayve began pioneering a new approach to self-driving in 2017, developing an end-to-end AI model that processes sensor data and outputs driving controls. As they made rapid progress in building a self-driving system capable of overcoming traditional scalability hurdles, they needed a partner to support their engineering workloads. Specifically, they were looking for a partner that provided scalability, allowed Wayve's expert engineers to remain focused on building their self-driving AI, and created efficiencies between tools. ## Adopting Foxglove to debug issues quicker and learn faster ### Triaging more intelligently and efficiently with tagged events. After integrating their data into the Foxglove platform, Wayve has reduced the triage process from days to minutes. With centralized tooling that everyone can contribute to and reference, team members can now build on each other's work more effectively to resolve issues. Both engineers and vehicle safety operators can collaborate on tagging points of interest as Foxglove events and add relevant metadata for easier categorization and search. > **"Foxglove helped us to supercharge our processes. We went from days to minutes when finding the root cause of an issue."** J'aime Laurenson, Product Lead at Wayve Now, triage engineers can filter for specific event types (e.g., human operator intervention), prioritize the results by impact and urgency, and visualize each one with a single click. Each event contains all relevant information in one place, allowing team members to begin debugging faster than usual. Wayve has also set up common Foxglove [**visualization dashboards**](https://docs.foxglove.dev/docs/visualization/layouts) for engineers to use when investigating different types of interventions, along with playbooks to help them interpret key indicators--such as comparing specific series in a graph or referencing certain values. These playbooks became so granular and clear that Wayve was able to codify some of these pro tips and automate them in a post-processing step, completely bypassing what could otherwise take hours of debugging. > **"We're at a critical juncture as we deliver the first Embodied AI product set to automotive customers - so shaving days off our iteration cycle with Foxglove is a huge advantage."** J'aime Laurenson, Product Lead at Wayve ### Consolidating tools to facilitate collaboration After adopting Foxglove, Wayve was able to deprecate several internal developer tools. Thanks to Foxglove's flexible data visualization panels, these tasks could now be accomplished using generic tools with unique configurations, all within one integrated development environment. Wayve engineers can now share [**Foxglove links**](https://docs.foxglove.dev/docs/visualization/shareable-links) to specific data segments, preloaded with a particular visualization layout. Engineers can simply send a link to share the full trace for a given issue. In addition to fostering collaboration and knowledge-sharing across the company, this feature has helped Foxglove spread organically throughout the organization. Wayve integrated Foxglove links into their existing internal tooling before gradually transitioning completely to Foxglove, making the migration seamless. A Wayve engineer using Foxglove. ### Iterating quickly with optimized performance and lightweight user scripts Reducing the time to find, visualize, and triage specific behaviors can significantly accelerate the speed of each iteration cycle. With Foxglove's web-first platform, Wayve can rely on easy-to-access tools to streamline many aspects of their workflow. This reduces the need for engineering resources to maintain data load times, rendering performance, or general tool efficiency. Wayve can also write lightweight Foxglove [**user scripts**](https://docs.foxglove.dev/docs/visualization/user-scripts) to run quick experiments, such as calculating simple unit conversions or overlaying driving plan visualizations on camera images. If these experiments prove useful long-term, Wayve can eventually migrate these scripts to a back-end processing step. > **"Insights from Foxglove have been instrumental in being able to quickly debug issues on our new vehicle platforms."** J'aime Laurenson, Product Lead at Wayve ## The impact of using Foxglove Nearly 40% of the Wayve engineering team now uses Foxglove in their daily workflows. To achieve their goal of deploying self-driving cars globally, Wayve needs crystal-clear visibility into what is happening under the hood--a critical competency for any self-driving car company. With Foxglove, Wayve has gained this insight through an easy-to-use, lightning-fast, web-based platform that provides top-to-bottom, team-wide visibility. With Foxglove in their toolkit, Wayve can meet their growing engineering needs. Knowing that Foxglove's capabilities can scale alongside their own empowers the team to accelerate their iteration speed--fitting for a company striving to change the world. One of Wayve's iconic AVs. --- ### Yard Robotics: How Yard Robotics accelerated their time to market by 6 months with Foxglove. URL: https://foxglove.dev/customers/yard-robotics Industry: Agriculture Impact: - 6 month reduction: Time to market - 70% reduction: Incident triage time - Days to hours: Customer onboarding time We're a small company developing an autonomy stack from scratch. In the same way AI acts a multiplier for human beings, Foxglove is doing the same for our robotics team. It's become a huge and irreplaceable accelerant to our development. -- Divya Thakur, Founder of Yard Robotics [Yard Robotics](https://yard.bot/) is on a mission to automate lawn care - to help people reclaim time for themselves, their families, and what matters to them most. As a replacement for traditional mowing and turf maintenance services, Yard Robotics deploys custom bots to map and traverse homeowners' properties, leaving behind impeccably mown lawns and delighted customers. The Yard team relies heavily on Foxglove's observability platform to understand and learn from their data. By integrating Foxglove with almost every core workflow, Yard has been able to scale their operations, accelerate their debugging workflows, and compress their time-to-market journey by nearly 6 months. ## Adopting Foxglove ### Accelerating autonomy software development with visualizations While having broad test coverage is certainly critical to any software development, relying solely on manual testing methods to catch issues can be quite tedious. With Foxglove visualizations, Yard engineers have a powerful shortcut to finding, triaging, and ultimately resolving issues with their autonomy stack. Resolving issues has become as simple as visualizing a bot's recorded log data, or watching what the bots are doing in real-time. > **"We're a small company developing an autonomy stack from scratch. In the same way AI acts a multiplier for human beings, Foxglove is doing the same for our robotics team. It's become a huge and irreplaceable accelerant to our development."** Divya Thakur, Founder of Yard Robotics By publishing the relevant 3D visualization markers to denote important information - parallel lines for the track the bots are planning to follow, color-coded pins for different waypoints, gray "keep out" zones, red wheels for overheating motors, green bodies for bots that are ready to engage, etc. - Yard engineers can quickly glance at a 3D panel to understand how their nodes, machine learning models, and bots are all doing. Instead of having to check different parts of the logs, or even different panels in Foxglove, the team can simply look at a 3D scene to get everything they need - significantly speeding up the entire issue resolution and development process. The team also relies heavily on the Plot panel, especially for making sense of a high volume of fast incoming data - for tuning PID controllers, tracking odometry values, and watching the control and command signals. Instead of manually reading through log data, Yard roboticists can now rely on these human-friendly representations of their data to quickly solve problems and seamlessly integrate their learnings into the next iteration of their autonomy software. > **"Understanding our data without Foxglove sounds about as painful as building a robot stack without ROS."** Divya Thakur, Founder of Yard Robotics ### Reducing onboarding time and improving training When adopting ROS as their robotics framework, Yard engineers knew this decision could subject new team members to a particularly long and painful onboarding process. Every developer would be restricted to the same Linux platform - regardless of their own experience - and be forced to use notoriously clunky native developer tools like RViz. Onboarding with these tools alone - with their dense interfaces, hyper-technical controls, and various idiosyncrasies - could easily take weeks or months, quickly demotivating developers looking to make a difference on the team. With Foxglove, Yard roboticists hit the ground running within a few days. Because it is a cross-platform app, engineers can connect Foxglove to their ROS stack using a Linux, Windows, or macOS machine. Because it has an intuitive interface that doesn't require any niche domain knowledge to navigate, even engineers without any prior experience can get up-to-speed on common ROS paradigms like topics, messages, and visualization markers. Less technical team members can also use Foxglove to make significant contributions to the team. While they may need a teammate to configure a layout for them, they can help triage incidents, remotely monitor deployed bots, and resolve issues once that workspace is set up. ### Enabling remote assistance and monitoring In addition to using Foxglove for visualization and debugging, Yard also uses the app as its primary back-end remote monitoring system. Yard's bots communicate over LTE to a back-end that pipes all data into a single ROS master. Remote assistance technicians can then connect to this data source with Foxglove to get a 20,000 feet view of their fleet. They can see all their robots on maps throughout the city and get a sense of how the fleet is doing - where every bot is located, the progress it's making, and its planned route. Remote monitoring has enabled Yard to avoid sending technicians on-site to supervise the bots. Those same technicians can now sit in an air-conditioned room with a laptop and remotely handle hardware and software issues as they arise. ## Outcome Integrating Foxglove into their core workflows has streamlined work across Yard's entire team and dramatically accelerated their progress from prototype to production. It has empowered engineers to focus on their autonomy software, get robots to production, and scale the fleet. It's made the business of troubleshooting incidents out in the field - and iterating with that feedback - as simple as clicking a few buttons in a Foxglove layout. Instead of being restricted to a lab somewhere, Yard bots are out in the field every day, mowing more lawns and serving more customers. Their real-world experience is powering the R&D needed for the next iteration. > **"Foxglove has been a game-changer for us. Investors are surprised with the progress we've made with relatively few engineering resources, and it's because we are leveraging tools like Foxglove."** Divya Thakur, Founder of Yard Robotics With Foxglove, Yard has been able to maintain their breakneck rate of development and keep themselves on track towards their mission. While they've started with residential areas as their operational domain, the team is excited to target more complicated tasks and expand their fleet as they iterate on their tech - using Foxglove every step of the way. --- ## Blog (Recent Posts) ### Introducing the Agentic Data Platform for Physical AI URL: https://foxglove.dev/blog/introducing-the-agentic-data-platform-for-physical-ai Date: 2026-08-18 Tags: product release Closing the simulation-to-real performance gap can take months. Today we are introducing new capabilities that make Foxglove the agentic data platform for physical AI. In the lab, robots often reach 95% success rates. In the real world, the same robots struggle to clear 60%. Closing this simulation-to-real world performance gap can take months. These performance gaps are the defining challenges for physical AI today. The bottleneck is turning physical AI data into learning. It's about how fast you can learn from real-world data, turn that learning into validated improvements, and deploy them in production. ## Speeding up the physical AI learning loop At Foxglove, our mission is to accelerate the physical AI learning loop. Today we're introducing new capabilities to the Foxglove Platform, making it the **agentic data platform for physical AI** to rapidly build, monitor, and improve robots across the data lifecycle. These capabilities help developers easily connect and collect data from live robots; more effectively triage and debug robot performance; more quickly search and curate recordings to find the events that matter. Foxglove agentic data platform architecture for physical AI teams ## Start with intent, not a file The [Agent Sidebar](/blog/foxglove-goes-agentic) built into the app is the agentic front door to the platform. No longer do developers need to move between screens to search and load recordings, create layouts or get answers to questions. The agent derives the intent of the user's request based on the context. Describe what you need in natural language, and the agent searches, reasons, configures, and acts -- grounded in your actual robotics data. Every answer cites the topic, timestamp, or schema it came from. For example, you can ask it to: - _"**Find every run where localization confidence dropped below 0.6.**"_ A search page will open with the results. - _"**Build a triage layout for yesterday's autonomy runs with camera feeds, planner state, and localization confidence.**"_ The layout will appear. - _"**Find episodes similar to this one and add them to a training dataset.**"_ The dataset is updated. - _"**What happened at this failure?**"_ The answer comes back, grounded in the MCAP file, schemas, topics, and values.
Creating a layout using the agent sidebar
> **"It replaces a whole flow for me. Instead of writing scripts or tabbing through all the plot fields myself, it just creates everything for me."** Alex David, Software Engineer, Cobot For teams that live in Claude, ChatGPT, Gemini, or Cursor, the **Foxglove MCP** exposes the same capabilities as a standard tool any agent can call -- so you can ask "what failed in last night's runs?" without ever opening the app. ## See your data like never before With traditional visualization and debugging tools, comparing runs to see what has changed requires juggling between separate windows, holding several timelines in your head while you squint to see whether a velocity spike lines up with the state change. The Foxglove Platform changes that. [Comparison Mode](/blog/compare-robot-recordings-across-runs) lets you review multiple runs in the same visualization environment -- a resim against the baseline, a new model against old, a failure event against a success. You can load any number of data sources onto a shared timeline, and view the data from these sources together, either overlaid or side-by-side. > **"Comparing multiple runs is valuable because Overland AI™ operates various platforms and needs to determine which performs best in a given environment. Side-by-side comparison allows us to enable regression testing, ensures optimal performance, and helps us assess how environmental factors can be mitigated."** Gaeson Redd, Autonomy Data Specialist, Overland AI ## Find what you need faster Names, timestamps, and device labels rarely tell you whether a recording has what you're looking for. Traditional search tools require specifying exact metadata and you still need to open a file to know what's in it. Earlier this year we introduced Data Search that let users search and query MCAP data at petabyte scale, with no warehouse to set up and no copies of the data to keep in sync. Today the Foxglove Platform takes that to the next level. We're replacing manual filtering with search that actually understands your data. [Semantic Search](/blog/introducing-semantic-search) lets users describe a behavior or scenario in natural language, and Foxglove retrieves the matching multimodal segments from across large volumes of unlabeled data. So you can ask for "_highway merges at night with poor lane detection_" and get matching runs -- no filters, no memorizing field names. Semantic Search is powered by industry leading models, including [NVIDIA Cosmos's](https://www.nvidia.com/en-us/ai/cosmos/) video-text embedding model purpose-built for Physical AI. NVIDIA Cosmos is a family of open frontier foundation models trained on robotics, driving, and ego-centric human action data, and delivers state-of-the-art retrieval accuracy on physical AI benchmarks. Foxglove users will be able to choose the model they want based on their requirements. Semantic Search is currently in beta, available on Foxglove-hosted sites and on Bring Your Own Storage sites backed by AWS or Google Cloud Storage. See [Introducing Semantic Search](/blog/introducing-semantic-search) for details.
A complex semantic search for an action in a sequence
Search is also smarter now, combining columnar and visual search in a single query. Making it easier to write structured, fast-running queries through an intuitive auto-complete experience in the search box. **Data Previews** visually surfaces camera thumbnails, 3D spatial snapshots, GPS traces, and sparklines directly in the search results and recording tables, so you know if a file has what you need before you open it. Once you find the files you need, Sessions and Events, which we introduced earlier this year, turns them into action. They let you group recordings into logical runs, annotate the moments that matter, and provide your team a shared, curated dataset. ## Access live data, not just files [Remote Access](/blog/remote-access-is-generally-available) is generally available today. It provides a one-click connection to any robot anywhere in the world that has an internet connection, and it doesn't require the same network. It automatically handles all the painful downsampling and compression adjustments to ensure the connection stays real-time. It can stream every topic from a robot in the field, live to Foxglove. This includes camera, Lidar, telemetry, logs, all at low latency and in the same application as the user's recorded data. This lets engineers observe and debug a deployed system in real time directly through Foxglove from wherever they are. The bi-directional communication supports teleoperation, and the on-device remote access gateway keeps robots reachable even behind a firewall or on cellular networks. ## Purpose-built for physical AI Foxglove's data platform spans collection, debugging, storage, mining, and curation -- built around MCAP files and multimodal sensor streams, with SOC-compliant Foxglove-hosted or self-hosted deployment options. [Bring Your Own Storage](/blog/bring-your-own-storage-is-generally-available) is now available to _both_ Foxglove Enterprise and Foxglove Pro plan customers. Connect Foxglove directly to your AWS S3, Google Cloud Storage, or Azure Blob buckets, and we index and query the data in place. No duplication, no second copy to keep in sync -- you keep ownership of your files and layout. As robotics companies adopt agentic workflows, Foxglove is designed to be the data platform developers use and trust. ## Getting started The new capabilities in the Foxglove Platform are live starting today. Come see them in action at [Actuate '26](https://actuate.foxglove.dev) or [book a demo](https://foxglove.dev/demo) with our technical team. Our engineers will demo these features live on September 2, 2026. [Register now](https://luma.com/foxglove-agentic-workflows). --- ### Foxglove goes agentic URL: https://foxglove.dev/blog/foxglove-goes-agentic Date: 2026-08-18 Tags: product release Work with your robotics data in natural language--ask questions, build layouts, write user scripts, and search recordings from the Foxglove app or through MCP. Agents have revolutionized software development. Writing, testing, and debugging code, for instance, is largely a solved problem, thanks to agents. But if you are in the business of building robots, you know the bottleneck has always been elsewhere. The challenge lies in capturing, organizing, and reasoning about massive amounts of multi-modal data produced by robots. There are tools for each of these jobs, but every tool poses its own learning curve. Unfortunately, this critical part of robotics development has not benefited from agentic workflows the way the rest of software development has. That changes now. Today, as part of our [data platform announcements for Physical AI](/blog/introducing-the-agentic-data-platform-for-physical-ai), we are introducing agentic workflows in Foxglove, with the ability to work with your robotics data in natural language. You can ask questions about your data, build and refine layouts, write user scripts, and search your recordings, simply by describing your intent. The agent figures out which tools to use to perform the requested operation. ## What are the agentic workflows in Foxglove? Foxglove's agentic capabilities are available in two forms today: - Agent sidebar: Foxglove's built-in agent, inside the app. - MCP server: Lets your existing AI agents control Foxglove through the desktop app. ### Agent sidebar The built-in agent in the Foxglove app is your navigator when you are already working through a recording and want to either ask questions about the underlying data or configure your visualization panel to better understand it.
Creating a layout using the agent sidebar
The agent derives the intent of the request based on the context. For example, if the agent sees a clear search intent in your query, it will take you to the search page and actually perform the search instead of just answering your question in the chat window. Here is an example of a [Semantic Search](/blog/introducing-semantic-search) that originated in the agent's chat interface.
Performing a semantic search from the agent sidebar
### MCP server The MCP server runs as part of the Foxglove desktop app and provides a gateway for your AI agents (Claude, ChatGPT, Cursor, etc.) to interact with Foxglove. This can come in handy when you are building a workflow involving tools beyond Foxglove. For example, an agent could look at a test failure in code, correlate it with the relevant robot recording, and prepare that recording for inspection in the visualization interface.
Engaging with Foxglove data using Claude
## How do the agents work? Agentic workflows are powered by three architectural pieces: LLM infrastructure, tools, and evals. The LLM layer gives us a single interface to models that the agent runs on. Tools are organized by where they execute. Local tools run inside the Foxglove app you have open, which is how the agent can fix a broken layout for you. Cloud tools reach your organization's data to search and act on it. These tools also act as the building blocks for skills, which are playbooks for common robotics data jobs (writing [FoxQL](https://docs.foxglove.dev/docs/visualization/foxql), diagnosing a broken [MCAP](https://mcap.dev/) file, etc.). The agent automatically determines which skill to use based on context. Our local MCP server uses the same infrastructure, so you can point your own agent at Foxglove to perform these tasks. The eval pipeline tells us how a prompt or tool change affects the agent's ability to solve problems accurately. Our first step has been to give agents the same platform functionality humans already have. This alone opens up many possibilities for iterating faster and triaging issues better. However, we are not stopping here. We believe there is enormous scope for accelerating robotics development through agents. The next step will be to automate complex multi-step operations where human judgment, visual inspection, etc. are still bottlenecks. More on this soon. ## Try agents in Foxglove Agentic workflows are available in beta to all customers. In the Foxglove app, click the agent sidebar sparkle button in the top-right corner, or press Cmd+J (macOS) or Ctrl+J (Windows/Linux). [Learn about agents in Foxglove](https://docs.foxglove.dev/docs/agents) Our engineers will demo these features live on September 2, 2026. [Register now](https://luma.com/foxglove-agentic-workflows). --- ### Introducing Semantic Search URL: https://foxglove.dev/blog/introducing-semantic-search Date: 2026-08-18 Tags: product release Search for objects and scenes in image and video topics using plain-language prompts, with gallery previews and tighter integration with Smart Search and the Foxglove Agent. Robotics teams spend their time on rare cases because that's where the learning is. But the same rarity that makes these moments so valuable is also what makes them hard to retrieve. There isn't an event type for a scenario nobody predicted, and your metadata cannot accurately describe what the camera saw. So, engineers end up scrubbing timelines and manually inspecting image topics. Today, as part of our [agentic data platform](/blog/introducing-the-agentic-data-platform-for-physical-ai), we are announcing Semantic Search to solve this problem. It lets you search for objects or scenes in the image and video topics in your recordings, using plain-language text prompts. It comes with several other improvements to make the search experience more intuitive. ## Semantic Search ### What can you do with Semantic Search? On the search page, you can now search using a visual description instead of specifying exact metadata. Results come back in a gallery view, so you can preview them and open only the ones that matter.
Simple semantic search for an object
You can also search for a scene that unfolds over time, not just a static object in a frame:
A more complex search for an action in a sequence
### How does Semantic Search work? Semantic Search is powered by vector search over frame embeddings. While ingesting data, Foxglove decodes your image and video topics, samples frames (a frame per topic per second), and runs them through an image embedding model. The vectors are stored in Lance tables in [your object storage](/blog/bring-your-own-storage-is-generally-available). Your prompt goes through the same model, and results are ranked by cosine similarity. Structured conditions are applied first: device, time range, and topic narrow the candidate set, and then the vector search orders what's left. Semantic Search understands two levels of context. Object and scene search finds matches within a single frame. Action search, powered by NVIDIA Cosmos open world models, reasons across sequences of frames to recognize motion and events that no single image can capture. To learn more about the supported formats and encodings, see the [Semantic Search docs](https://docs.foxglove.dev/docs/data/search#visual-search). Support for images and videos is the first step in Semantic Search. Our goal is to extend the same concept (the ability to search based on description) to all other data types that robots emit. Our vision is that robotics teams should spend less time becoming data mining experts and more time building autonomous robots. ## Smart Search The new search experience also makes it easier to write structured queries with auto-complete in the search box. You can even combine structured and visual search criteria into a single query:
Auto-complete experience simplifies structured search
Sometimes, exploring data visually gives you ideas for conditions you want to search on elsewhere. You can now select aspects of your data in a visualization panel and turn them into search queries.
Using raw message elements as search criteria
## Agentic Search Like all other aspects of our platform, search is fully integrated with the [Foxglove Agent](/blog/foxglove-goes-agentic). From within the search experience, you can write a plain-language request for what you want to search. Your request is routed to the agent, which converts the request into a proper query, performs the search, and returns the results. Here is an example of an agent-assisted search where a plain-language prompt does what previously required a complicated query:
Agent-assisted search from within the search page
Similarly, you can initiate the search in plain language from within the agent sidebar. The agent will understand the search intent and take you to the new search experience.
Search from the agent sidebar
## Try the new search experience Smart Search and Agentic Search are available today. Semantic Search is in beta, available on Foxglove-hosted sites and on Bring Your Own Storage sites backed by AWS or Google Cloud Storage. Azure and self-managed sites will be supported in the future. To request access to Semantic Search, please [get in touch with us](https://foxglove.dev/contact?reason=sales). Our engineers will demo these features live on September 2, 2026. [Register now](https://luma.com/foxglove-agentic-workflows). --- ### Compare robot recordings across runs URL: https://foxglove.dev/blog/compare-robot-recordings-across-runs Date: 2026-08-18 Tags: product release Load any number of data sources onto one shared timeline--overlaid or side by side--to validate fixes, measure sim-to-real gaps, and spot outliers across your fleet. You have two recordings and one question: what changed? Did the fix work, or did the failure just not happen this time? Or maybe you want to see how a behavior you meticulously tuned in sim performs on real hardware. Finding these answers today means scrubbing in separate windows, holding several timelines in your head while you squint to see whether the velocity spike lines up with the state change. Plenty of teams give up and resort to exporting CSVs, spending an afternoon in a notebook cleaning data and lining runs up by hand. Today, as part of our [agentic data platform for Physical AI](/blog/introducing-the-agentic-data-platform-for-physical-ai), we are introducing Comparison Mode to make robot run comparisons easier within the same tool you use to visualize and debug individual runs. ## What does Comparison Mode do for you? Using Comparison Mode, you can load any number of data sources onto a shared timeline, each in a labeled slot: A, B, C, and so on. You can view these sources together, overlaid or side by side.
Two drone runs visualized side by side
Playing data from multiple sources on a shared timeline can be useful in many scenarios. Here are some examples: ### Validate fixes by comparing pre- and post-fix runs Compare two runs of the same scenario, before and after a code change. Visualizing side by side on a timeline makes it easy to verify whether the fix actually worked.
UMBMark test before and after odometry calibration (A and B)
### Separate hardware faults from software regressions in fleets Load recordings from several robots or missions and easily find data outliers pointing toward mechanical issues. ### Measure the sim-to-real gap Compare a simulated run against a real one. Manually adjust the clock offset to a common starting point and look at the difference between the two runs by comparing 3D output, plotted values, or diagnostics side by side.
Aligning offsets across runs
### Track degradation by comparing sessions weeks apart You can compare two sessions of continuous operation, each spanning several recordings. Slow degradation that stays hidden inside one session becomes visible once two shifts recorded weeks apart share a timeline. Comparison Mode showing two sessions weeks apart on a shared timeline ### Isolate failure modes by comparing repeated events You can open every safety stop in a time range. Each event anchors at zero, so the instance that doesn't match the others is easy to spot. ## Try Comparison Mode This feature is available today to all customers. You can try it from within the [web app](https://app.foxglove.dev/) or the [desktop app](https://foxglove.dev/download). Just go to any of the data-listing pages (Recordings, Sessions, Events), choose more than one item, then select "Compare". [Learn about Comparison Mode](https://docs.foxglove.dev/docs/visualization/comparison-mode). Our engineers will demo these features live on September 2, 2026. [Register now](https://luma.com/foxglove-agentic-workflows). --- ### Bring Your Own Storage is now available on all major clouds URL: https://foxglove.dev/blog/bring-your-own-storage-is-generally-available Date: 2026-08-18 Tags: product release BYOS is generally available on AWS, Google Cloud, and Azure--keep recordings in your own buckets while using Foxglove search, visualization, and curation. You want to use a modern data platform to collect, organize, and debug your robotics data, but you also want to keep it in your own cloud storage. We get it. Since announcing the Bring Your Own Storage (BYOS) deployment option a few months ago, we have been working with several customers to get their production workloads on BYOS. Today we are announcing that BYOS is generally available for customers on AWS, Google Cloud, and Azure. ## Why BYOS? If you build robots, your recordings are probably already in a cloud storage bucket you own. Hundreds of terabytes of MCAP files in AWS S3 or Google Cloud Storage, and dozens of workflows stitched together with scripts pointing at these files. At the same time, you want to use the visualization, search, and curation capabilities in Foxglove. Duplicating all of your existing data into Foxglove-managed storage can be impractical. BYOS allows you to keep your data in your own cloud storage and still benefit from our [agentic data platform purpose-built for physical AI](/blog/introducing-the-agentic-data-platform-for-physical-ai). Think of it as taking your existing data and giving it superpowers by pointing Foxglove at it. This is also a great option for teams with stringent data residency requirements driven by security or compliance reasons. Your files remain the only copy of your recordings. Foxglove never duplicates or moves them. ## How does BYOS work? BYOS is a good middle ground between the fully managed Foxglove Cloud deployment and the operationally heavy self-hosted option. It avoids the burden of managing infrastructure for self-hosting while you keep full ownership of your data. Your data lives in your storage buckets. Foxglove needs only read-only access to the data and indexes all your recordings in place so you can query and visualize later. The query service runs in Foxglove's cloud, in the region you choose for the site. You have 14 regions to choose from across AWS, Google Cloud, and Azure. Point it at the region your bucket is in and every read stays local. BYOS architecture diagram showing in-place indexing of customer storage buckets New sites come with search indexing and automatic ingestion switched on, so recordings are searchable from the moment they land. This includes searching within image and video topics using plain-language descriptions through our [Semantic Search](/blog/introducing-semantic-search) feature. You can point a site at a bucket that already holds years of recordings and index it where it is. You can scope bucket notifications to specific file-types (MCAP and ROS 1 bag files), so you index only what you need. Any other tools written to work with your storage buckets keep working, because the underlying data never changes. BYOS adds to our deployment options, giving you more flexibility in how you use Foxglove. This is a quick view of how the roles and responsibilities split between Foxglove and you, depending on the deployment model you choose: Table comparing deployment models and responsibilities between Foxglove and the customer For a full list of supported deployment models, see our [deployment model documentation](https://docs.foxglove.dev/docs/data/primary-sites#deployment-models). ## Try BYOS The BYOS deployment model is available as a paid add-on. If you want to enable this for your organization or want to learn more, please [get in touch](https://foxglove.dev/contact?reason=sales). Once BYOS is enabled in your organization, you can follow [these instructions](https://docs.foxglove.dev/docs/data/primary-sites/foxglove-managed-setup) to configure Foxglove to work with your cloud storage buckets. Our engineers will demo these features live on September 2, 2026. [Register now](https://luma.com/foxglove-agentic-workflows). --- ### Remote Access is generally available URL: https://foxglove.dev/blog/remote-access-is-generally-available Date: 2026-08-18 Tags: product release Remote Access is now generally available on Pro and Enterprise plans--visualize and teleoperate field robots through Foxglove, even behind a firewall or on an unreliable network link. As your robotics operation scales out of the lab and into the field, you need a rock-solid debugging solution. Today, as part of our [agentic data platform](/blog/introducing-the-agentic-data-platform-for-physical-ai), we are announcing that Remote Access is generally available. This feature allows you to visualize and teleoperate remote devices through the Foxglove platform, even if they are behind a firewall, on a flaky LTE link, or on a network you have no control over. ## Connecting live to remote robots ### Setting up the robot for Remote Access The robot needs to run a [remote access gateway](https://docs.foxglove.dev/docs/fleet/remote-access#setting-up-a-gateway). You can get it in one of two ways: the Foxglove SDK (for custom code running on the robot) or the Foxglove Bridge (for a ROS stack). The gateway initiates a lightweight connection to the Foxglove cloud platform, authenticated via [device tokens](https://docs.foxglove.dev/docs/fleet/device-tokens). When a user connects to a robot through the app, the platform gives each side a short-lived credential and wakes the gateway on the robot. ### Connecting to the robot Once the robot is configured for Remote Access, connecting to it from the app is similar to connecting to any other data source. Just open the connection dialog, or select the device on the devices page. After connecting, it behaves like any other live source. Topics stream into the same panels and layouts you use to visualize recorded data. You can also use the [Teleop](https://docs.foxglove.dev/docs/visualization/panels/teleop) and [Publish](https://docs.foxglove.dev/docs/visualization/panels/publish) panels to send commands back to the robot, provided it is set up to accept commands. ### How Remote Access works Remote Access architecture diagram with robot gateway, Foxglove SFU, and app viewers All streaming happens over [WebRTC](https://webrtc.org/). The Foxglove-managed Selective Forwarding Unit (SFU) acts as the relay between the robot and the people watching. The robot opens one connection to the SFU and uploads each stream once. Each viewer connects separately, and the SFU hands every one of them a copy. Each hop negotiates its own stream quality, so a viewer on bad Wi-Fi drops to a lower bitrate without slowing down the robot or anyone else. ## Try Remote Access Remote Access is available today on Pro and Enterprise plans. See our [Remote Access guide](https://docs.foxglove.dev/docs/fleet/remote-access) for the exact steps to connect to your robots remotely. Our engineers will demo these features live on September 2, 2026. [Register now](https://luma.com/foxglove-agentic-workflows). --- ### Foxglove now integrates with Grafana URL: https://foxglove.dev/blog/foxglove-now-integrates-with-grafana Date: 2026-08-18 Tags: product release Query robotics data from the Foxglove data platform as time series in Grafana Cloud or self-hosted Grafana using the new Foxglove data source plugin. A robot fleet produces plenty of data worth watching over time. Battery health as packs age, motor temperature under load, how often an arm faults after a firmware push. All of this data gets recorded, and a lot of it lives in Foxglove, a robotics-native platform for querying, visualizing, and debugging it. The dashboards your team watches every day track a different set of data: uptime, deploy counts, cluster health, running costs. Robot behavior is missing from this set. Building a comprehensive view of your fleet means bringing the two together, which today costs you duplication and complexity. Today, as part of our [agentic data platform](/blog/introducing-the-agentic-data-platform-for-physical-ai), we are announcing the Grafana integration to solve this. The integration is powered by the Foxglove data source plugin, now live in the [Grafana plugin catalog](https://grafana.com/grafana/plugins/foxglovedev-foxglove-datasource/) and supported on both Grafana Cloud and self-hosted Grafana. The plugin makes robotics data from the Foxglove data platform queryable as a time series from any Grafana panel. ## How the Foxglove and Grafana integration works Foxglove indexes every message in every recording your fleet uploads. That index is what powers [Search](https://docs.foxglove.dev/docs/data/search) in the Foxglove app, and the Grafana integration uses the same query engine. The data source plugin authenticates using a Foxglove API key, and all querying and data retrieval happens on your organization's [data platform](https://docs.foxglove.dev/docs/data). Grafana integration architecture with Foxglove data platform and Grafana dashboards If you've used the Search feature in Foxglove, the filter builder and granularity control in the plugin will look familiar. Foxglove Grafana plugin query builder with filter and granularity controls ## Get started The Grafana integration is an add-on for Enterprise plans and needs to be enabled for your organization. [Contact us](https://foxglove.dev/contact?reason=sales) and we'll get you set up. Other helpful resources: - [Grafana integration documentation](https://docs.foxglove.dev/docs/grafana) - [Building queries reference](https://docs.foxglove.dev/docs/grafana/queries) - [Plugin source on GitHub](https://github.com/foxglove/foxglove-grafana-datasource) Our engineers will demo these features live on September 2, 2026. [Register now](https://luma.com/foxglove-agentic-workflows). --- ### Autonomous Navigation with LeKiwi -- Part 2 URL: https://foxglove.dev/blog/autonomous-navigation-with-lekiwi-part-2 Date: 2026-07-27 Tags: community, tutorial A follow-up to Autonomous Navigation with LeKiwi: collision protection for teleop via collision_monitor, a waypoint recorder for patrol routes controlled from Foxglove, and keepout plus speed-limited zones that Nav2 routes around or slows down in. **tl;dr** As a follow-up to [Autonomous Navigation with LeKiwi](/blog/autonomous-navigation-with-lekiwi-and-nav2), I worked on three features in this post: I first rewired `collision_monitor` so that teloperation gets the same collision protection as autonomous mode with Nav2. Next, I built a waypoint recorder that lets the robot patrol a route of waypoints on its own - with controls to add waypoints and start/pause patrolling, straight from Foxglove. Finally, I added keepout and speed-limited zones to the map that Nav2 actually routes around or slows down in, respectively. This is the next chapter in my [ongoing series](https://kamathrobotics.com/series/lekiwi) of building a ROS 2-powered autonomous mobile robot based on the [LeKiwi](https://github.com/SIGRobotics-UIUC/LeKiwi) platform. Last time, I got [a simple Nav2 configuration running end-to-end](/blog/autonomous-navigation-with-lekiwi-and-nav2) - mapping, localization, and point-to-point navigation, all visualized on [Foxglove's 3D panel](https://docs.foxglove.dev/docs/visualization/panels/3d) - good enough to navigate to single targets, but it left a few things unfinished. The most glaring issue: LeKiwi's autonomous mode with Nav2 had collision protection, but the moment I switched to teleoperation, that safety net was gone. I could drive it straight into an obstacle, and the robot would happily comply. Alongside a fix for this issue, this post also covers two other features: waypoint following/patrolling so the robot can loop a route without the need to manually provide a fresh goal each time, and keepout / speed-limited zones painted onto the map so that the robot can stay away or slow down in areas where it might get stuck. As always, the work covered in this post lives in the [`lekiwi_ros2`](https://github.com/adityakamath/lekiwi_ros2) GitHub repository, which includes the full ROS 2 stack implementation for the LeKiwi platform. ## Assisted Teleop and Collision Protection My robot has two driving modes: autonomous navigation using [Nav2](https://docs.nav2.org/), and manual teleoperation, and I can switch between them using [`twist_switch_node`](https://github.com/adityakamath/lekiwi_ros2/blob/main/lekiwi_control/lekiwi_control/twist_switch_node.py), a custom script that I wrote. In autonomous mode, Nav2's [`collision_monitor`](https://docs.nav2.org/rolling/configuration_and_development/configuration_guide/core_servers/collision_monitor/configuring_collision_monitor_node/) watches the LiDAR scan and stops the robot before a collision. This is a really useful safety feature that unfortunately does not exist in teleop mode - if I drive the robot manually into a wall, it will happily keep going until it hits the wall. I wanted to fix that. My original idea was to use Nav2's built-in [`AssistedTeleop`](https://docs.nav2.org/rolling/configuration_and_development/configuration_guide/core_servers/configuring_behavior_server/#assistedteleop-behavior-parameters) behavior - a `behavior_server` plugin that forward-simulates a teleop velocity and scales it down before a collision. It looked like a pure config change at first, since my joystick already publishes to `/cmd_vel_teleop`, matching `AssistedTeleop`'s expected input topic. Digging deeper, I realized that this does not work with my two-mode setup because `AssistedTeleop` is a behavior that runs only while Nav2 is active -- it's designed to let you steer the robot manually during an ongoing Nav2 session, not to protect standalone teleop. I wanted to keep teleop and autonomous modes completely separate, so I had to think of a different approach. So I looked into `collision_monitor` instead - it structurally does the same job as `AssistedTeleop`, just with a zone-based check (`FootprintApproach`) rather than forward simulation. My original Nav2 configuration (the recommended method) places it upstream of `twist_switch_node`, so it only ever sees Nav2's own commands. I moved it downstream instead, so it works irrespective of which mode - teleop or Nav2 - is currently active. This means the teleop mode is now protected by the same collision monitor as autonomous navigation, and the autonomous mode is unaffected. The wiring change looks like this: Before and after diagram: collision_monitor moved downstream of twist_switch so both Nav2 and joy_teleop commands are protected This was much simpler than making `AssistedTeleop` work in teleop, and it doesn't interfere with autonomous navigation at all - zero new nodes, just `collision_monitor` rewired. The only downside is that `FootprintApproach`'s zone check is a bit more conservative than `AssistedTeleop`'s forward-simulation, so the robot may stop a little earlier than necessary, which, for the LeKiwi, is not an issue at all. As you can see in the video below, it works as expected - the robot slows down as it approaches an obstacle, eventually stopping before hitting it. One issue came up during testing: I drove into a tight spot where `collision_monitor` stopped the robot, and then blocked every direction I tried on the joystick, leaving it completely stuck. To prevent this from happening again, I added a manual override: [`collision_toggle_node`](https://github.com/adityakamath/lekiwi_ros2/blob/main/lekiwi_navigation/lekiwi_navigation/collision_toggle_node.py). This node sets `collision_monitor`'s `FootprintApproach.enabled` parameter to `false` when a preconfigured button is held down, and back to `true` when the button is released. It subscribes directly to `/joy`, with the button configured via a node parameter - R1 in my setup. Now, if I'm ever stuck like that again, I can just hold R1 to back away and release it to regain protection. ## Waypoint Recording and Patrolling In my previous Nav2 post, I was able to send the robot a single `navigate_to_pose` goal and watch it go there, but I had no way to make it work through a list of waypoints on its own. Each new target required a manual goal to be sent from Foxglove, which is tedious and not very autonomous. I wanted to be able to record a route of waypoints and have the robot patrol through them on its own. Nav2 already ships [`nav2_waypoint_follower`](https://docs.nav2.org/rolling/configuration_and_development/configuration_guide/core_servers/waypoint_follower/), a lifecycle node that drives the existing `navigate_to_pose` action once per waypoint in a loop - no new behavior tree required. What it doesn't ship is any convenient way to trigger it - the only interface is its [`FollowWaypoints`](https://github.com/ros-navigation/navigation2/blob/main/nav2_msgs/action/FollowWaypoints.action) action, which is callable only via an unwieldy `ros2 action send_goal`, with no direct way to trigger it from Foxglove. So I wrote [`waypoint_recorder_node`](https://github.com/adityakamath/lekiwi_ros2/blob/main/lekiwi_navigation/lekiwi_navigation/waypoint_recorder_node.py), exposing three [`std_srvs/srv/SetBool`](https://github.com/ros2/common_interfaces/blob/rolling/std_srvs/srv/SetBool.srv) services I can either bind to gamepad buttons via [`joy_teleop`](https://index.ros.org/p/joy_teleop/), or call from my [Button extension](https://github.com/adityakamath/foxglove_extensions/tree/main/button) on Foxglove. The three services are: - `/record_waypoint`: captures the robot's current pose as a waypoint, published as a [`visualization_msgs/msg/MarkerArray`](https://docs.ros2.org/foxy/api/visualization_msgs/msg/MarkerArray.html) so the whole route shows up as arrows in Foxglove's 3D panel - `/waypoint_follow`: starts or resumes the patrol - a toggle, so a single button can alternate between starting/resuming and pausing the patrol - `/reset_waypoints`: clears the route and all waypoints Foxglove Button panel configured for Waypoint Follow as a toggle service call to /waypoint_follow, with Start and Pause states In this new node, the waypoints are stored as a vector of [`geometry_msgs/msg/PoseStamped`](https://github.com/ros2/common_interfaces/blob/rolling/geometry_msgs/msg/PoseStamped.msg) and sent to `nav2_waypoint_follower` via its `FollowWaypoints` action. Since that's an ordered list with a `FollowWaypoints.Goal.goal_index`, the patrol can pause and resume mid-route instead of always restarting from the beginning. Another feature I added is the ability to send manual `navigate_to_pose` goals while a patrol is running. In this case, the patrol treats it as a detour rather than a failure - go to the commanded target, then carry on following the original patrol route. Another feature where knowing the goal index is advantageous. The `number_of_loops` parameter controls how many times the patrol repeats - 0 (the default) loops forever, any positive number stops the patrol after exactly that many passes. I also implemented the ability to add new waypoints while a patrol is running - they queue up and join the route at the start of the next loop instead of splicing in immediately, which avoids preemption issues and keeps the robot from skipping waypoints. I added two more features to make the patrol behavior more robust: 1. Error Handling: an unreachable waypoint gets retried a bounded number of times before being dropped from the route entirely, so the patrol keeps going instead of stalling forever. 2. Progress Reporting: the patrol's current loop, current leg, ETA, and recovery count are published on `/patrol_diagnostics` as a [`diagnostic_msgs/msg/DiagnosticArray`](https://github.com/ros2/common_interfaces/blob/rolling/diagnostic_msgs/msg/DiagnosticArray.msg) message, readable from [Foxglove's Diagnostics panel](https://docs.foxglove.dev/docs/visualization/panels/diagnostics) once configured to subscribe to `/patrol_diagnostics`, no custom message type needed. Foxglove layout showing patrol controls, Diagnostics panel with waypoint_recorder status, and 3D view of the patrol route This was a big addition - I can set up a patrol route, watch it run, and adjust it on the fly, all from Foxglove or a gamepad. That said, `waypoint_recorder_node` is nowhere near a polished solution - it's a messy, partly vibe-coded proof-of-concept, and I plan to refine it iteratively. For now, if you want to use it yourself, proceed with caution and expect breaking changes. ## Keepout and Speed-Limited Zones This feature was born out of necessity. While testing my standard Nav2 config, I found a few areas in my apartment that the robot couldn't navigate through safely. For example, my couch has a high clearance, so the LiDAR sees free space underneath it, but the pan-tilt mechanism gets stuck since it is taller than the clearance. Another example is my standing desk, which has a base that is lower than what the LiDAR sees, so the robot would collide if it tried to go under. I needed a way to tell Nav2 to avoid these areas. Two views of the LeKiwi robot near furniture, illustrating clearance issues the LiDAR cannot see While at it, I also decided to experiment with speed-limited zones, where the robot would slow down in certain areas. Not something I need right now, but a fun feature to play with. I wanted to be able to draw these zones on the map and have Nav2 respect them during navigation. For both these features, I followed the handy tutorials in the Nav2 docs: [Keepout Zones](https://docs.nav2.org/rolling/tutorials/general_tutorials/navigation2_with_keepout_filter/navigation2_with_keepout_filter/) and [Speed-Limited Zones](https://docs.nav2.org/rolling/tutorials/general_tutorials/navigation2_with_speed_filter/navigation2_with_speed_filter/). Both use a separate grayscale mask image layered on top of the navigation map, but they work differently: - [`KeepoutFilter`](https://docs.nav2.org/rolling/tutorials/general_tutorials/navigation2_with_keepout_filter/navigation2_with_keepout_filter/) marks any cell where the mask has a black pixel as a no-go zone in the costmap - the planner treats it as an obstacle and routes around it. I have `keepout_filter` running on both the global and local costmaps, so neither the planner nor the controller will enter those cells regardless of where the goal is. Keepout mask PGM with a black rectangular no-go zone painted on the map - [`SpeedFilter`](https://docs.nav2.org/rolling/tutorials/general_tutorials/navigation2_with_speed_filter/navigation2_with_speed_filter/) maps pixel brightness to a speed limit percentage instead - white means full speed, black means stop, and grays scale proportionally in between. In the image below, the two grey blobs are speed-limited zones, with the darker one indicating a lower speed limit than the lighter grey section. `SpeedFilter` only runs on the local costmap - it affects what the controller does in real time, but the global planner generates routes without accounting for it. This also means that if a keepout zone overlaps a speed-limited zone, the keepout zone takes precedence, since the global planner will never route a path through it. Speed-limited mask PGM with two grey rectangular zones of different brightness for different speed limits The main challenge here was the recommended method for creating these masks: create a `.pgm` file in an image editor with the same size as the map, then overlay the map on top of it as a guide and draw the zones. I updated the [`map_saver_node`](https://github.com/adityakamath/lekiwi_ros2/blob/main/lekiwi_navigation/lekiwi_navigation/map_saver_node.py) script to handle the first part: it now saves all-white `.pgm` placeholders sized to match the map alongside the rest of the map files, so there's no need to create a correctly sized canvas from scratch. VS Code file explorer showing studio map files and filters folder with keepout_mask and speed_mask PGM and YAML files However, to update these masks, I decided to look for a way to do it directly in VS Code, since I am already using it for development. I handed it off to Claude, and less than an hour later, I had a rudimentary [`PGM Editor`](https://github.com/adityakamath/pgm_editor) extension that lets me open a blank `.pgm` file, draw shapes on it, and save it as a filter. In the image below, the black blob is a zone I've already drawn, and the red polygon is a new keepout zone being drawn. It is very basic, but it works for my needs. It is available on the [VSCode Extensions Marketplace](https://marketplace.visualstudio.com/items?itemName=kamathsblog.pgm-editor). Feel free to check it out and clone it to make it your own. PGM Editor extension in VS Code drawing a keepout zone on keepout_mask.pgm with a red polygon selection With the masks ready, I updated the Nav2 config and the launch file to include the costmap filter plugins and tested it out. Like before, using the [Foxglove Bridge](https://docs.foxglove.dev/docs/fleet/bridge), I could visualize the costmaps remotely in Foxglove running on my laptop and see both the keepout and speed-limited zones in the 3D panel, as shown in the image below. Both masks are rendered as standard costmaps in Foxglove, so the colors are fixed, but you can switch to custom costmap layers if you want to pick your own. Foxglove 3D panel showing keepout and speed-limited zones overlaid as costmap layers on the map Once the visualization was verified, I tested the robot's behavior in the real world. The keepout zone worked as expected - the planner never routed the robot into the zone, always routing around it. The speed-limited zones also worked - the robot slowed down according to the speed limit set in the mask and returned to its original speed once it exited the zone. You can see both of these zones in action in the video below. I am super happy with how this feature turned out and relieved that it was so easy to implement. ## Wrapping up With these three features in place, the LeKiwi's Nav2 setup is starting to feel complete. And like with everything else, Foxglove was one of the instrumental tools that really sped up my development process. From visualization to teleop and now the new navigation features, it works seamlessly whether I'm sitting at my laptop or holding the Steam Deck. Beyond Nav2, the next major thing I want to tackle is a docking station: somewhere the robot can autonomously navigate to and charge. That breaks down into a few intermediate goals: tracking fiducial markers with the on-board OAK-D S2 camera, writing a custom docking behavior using [Behavior Trees](https://www.behaviortree.dev/), and on the hardware side, designing the docking mechanism and finding a battery monitoring solution that can tell the robot when it's running low. The hardware will probably take the longest, and might end up being a custom design if nothing off-the-shelf fits. As for the planner and controller tuning that I promised in the previous post, it is still ongoing. I've been fine-tuning it iteratively as I use the robot, but it's not the kind of thing that makes for an interesting blog post, so I will leave those changes in [lekiwi_ros2](https://github.com/adityakamath/lekiwi_ros2) with the rest of the LeKiwi ROS 2 stack. As always, this is a work in progress, so expect regular updates and breaking changes at times. Feedback and contributions are always welcome! --- ### Visualizing the Artemis II Mission URL: https://foxglove.dev/blog/visualizing-the-artemis-ii-mission Date: 2026-07-20 Tags: community, tutorial, visualization In April 2026, four astronauts flew around the Moon for the first time in over fifty years. I built a Foxglove visualization of the Artemis II mission: Orion's real trajectory through inertial space in 3D, 476 mission photos synchronized to the timeline, and a custom photo-stepper extension that turns the whole thing into a navigable album. In April 2026, four astronauts flew around the Moon for the first time in over fifty years. Hank Green, a science communicator and YouTuber, built an [awesome website](https://artemistimeline.com/) to visualize the many photos taken on and around the spacecraft throughout the mission. I was inspired by Hank's project (as I am by most of his projects and content), and as a recent addition to the Foxglove team, I saw a great opportunity to both learn our tool and explore the same dataset in a new way. Foxglove is built for robotics, it organizes and visualizes the sensor data that goes into developing and debugging autonomous systems. The same tools generalize well beyond robots, and it's a genuinely fun environment to build things in. I knew I could use the 3D panel to plot Orion's actual path through inertial space; something you can rotate, zoom into, and follow in real time, while a second tab kept the photos and mission state synchronized to wherever you were in the timeline. Orion's trajectory plotted through inertial space in the Foxglove 3D panel Orion's path alongside mission photos synchronized to the timeline ## Getting the Data The pipeline started with two sources. Orion's trajectory came from the [JPL Horizons API](https://ssd.jpl.nasa.gov/horizons/), which provides precise ephemeris data for solar system objects including crewed spacecraft. The photos and their metadata came from Hank's [Artemis-Timeline](https://github.com/hankmt/Artemis-Timeline) project, where a single photos.js file captures everything: timestamp, camera type, caption, photographer, and a link to the full-resolution JPEG for each shot. A few Python scripts handle the rest. One fetches the trajectory, one downloads and resizes the photos from their original multi-megabyte RAW exports down to a more manageable ~1280px, and a third fuses everything onto a single synchronized timeline and writes it out as an MCAP file. Simple enough in hindsight, though getting the timestamps to line up cleanly took a few passes. ## Building the 3D Scene Now that I had all the data I needed, the next step was to build out the 3D scene to follow the trajectory. Early on I tried a primitive URDF; boxes and cylinders roughly standing in for the spacecraft. It worked, but it didn't feel like Orion. An early primitive URDF using boxes and cylinders as a stand-in for Orion Then I found [Ian Dees's artemis-viewer](https://github.com/iandees/artemis-viewer) on GitHub. It uses NASA's AROW Orion model, the same one from NASA's live Artemis tracker, with solar arrays that actually look like solar arrays. I wired that into the MCAP and reused Ian's tuned panel deployment poses, so the arrays sit in their on-orbit configuration rather than folded against the hull. NASA's AROW Orion model with deployed solar arrays in the Foxglove 3D panel ## Layout: Less Clutter, More Visuals At first everything lived on one screen: 3D view, plots, timeline, photos, logs. It was informative, but busy. I wanted the orbital view and images to be emphasized. An early, cluttered single-screen layout with 3D view, plots, timeline, photos, and logs So I split the layout into a tab panel with two tabs: one focused on data and pictures, one on the 3D panel and pictures. You can dig into distance plots and mission state when you want the numbers, then switch to the visual tab when you just want to watch Orion move through space alongside the photos. ### Visuals Tab The Visuals tab: the 3D orbital view alongside mission photos ### Data Tab The Data tab: distance plots and mission state alongside mission photos ## The Power of Extensions Foxglove ships with a powerful suite of built-in panels, but the [extension](https://docs.foxglove.dev/docs/extensions) system is where things get interesting. Extensions let you build custom panels that plug directly into a layout and share the same timeline as everything else. For this project, that meant a photo stepper panel: jump forward and backward through shots one at a time, filter by camera, or run a slideshow. The mission spans 10 days and nearly 500 photos, so having dedicated controls made navigating the album actually enjoyable. The best part is that stepping to a new photo moves the entire layout with it. The 3D view, distance plots, and milestone indicator all snap to that moment in the mission automatically. One timeline, shared across every panel. The photo stepper is on GitHub alongside the rest of the project if you want a working example to start from. ## Finishing Touches Toward the end I added a randomized starfield and textured Earth and Moon models. At mission scale, the scene can feel sparse; the stars and planet textures give it a bit of depth without getting in the way of the trajectory and photos. ## Credits - Trajectory: JPL Horizons / NASA - Photos & timeline data: [Hank Green's Artemis-Timeline](https://github.com/hankmt/Artemis-Timeline) - Orion model & solar panel poses: [Ian Dees's artemis-viewer](https://github.com/iandees/artemis-viewer) (AROW model from NASA) - Visualization: [Foxglove](https://foxglove.dev/) ## Try It! The full project: build scripts, URDF models, built .mcap, Foxglove layout, and photo stepper extension is on [GitHub](https://github.com/mrchocoborider/artemis-foxglove). You'll need Python 3.10+, a Foxglove installation, and about 10-30 minutes for the initial build (photo downloads dominate). The README has step-by-step instructions. If you build something with it, or adapt it for another mission, I'd love to [hear about it](/chat). --- ### When you can't reach the robot: SOVD diagnostics and OTA updates in Foxglove via the ros2_medkit extension URL: https://foxglove.dev/blog/sovd-diagnostics-and-ota-updates-in-foxglove-via-ros2-medkit Date: 2026-07-15 Tags: community, ROS, tutorial When your connection to a warehouse robot drops, ros2_medkit brings SOVD diagnostics, on-robot failure capture, and OTA repair actions into Foxglove panels--so you can see the problem and fix it in one application. Some time ago, I was watching a robot work from another building. My connection to it was weak, and for a few minutes my view dropped. When it came back, the robot had stopped moving, and I did not know why. Whatever went wrong had happened while I was not looking. Foxglove is where I look at robot data, both live and recorded, and it is where I want to see when something breaks. What I needed that day were two more things in the same window: a record of the failure stored on the robot and a way to fix it without opening a shell. Those are the capabilities that `ros2_medkit` adds through its Foxglove extension. It brings the robot's faults, its on-robot capture of a failure, and the repair actions into the panels next to my 3D view, creating a tight loop where I can see the problem and fix it in a single application. `ros2_medkit` is our SOVD (Service-Oriented Vehicle Diagnostics, [ISO 17978](https://www.iso.org/standard/85133.html)) gateway for ROS 2, which includes a [Foxglove extension](https://github.com/selfpatch/ros2_medkit_foxglove_extension). This blog post follows one failure on a warehouse robot in simulation. The robot records the failure and I replay that record in Foxglove to find the cause, and I fix the robot over the air from a panel in the same window. ## The setup Robotnik RB-Theron AMR _Robotnik RB-Theron AMR. Source: Robotnik Automation_ The demo is a Robotnik RB-Theron, a differential-drive warehouse AMR, running [Nav2](https://nav2.org) on headless Gazebo in the AWS small-warehouse world. [`foxglove_bridge`](https://github.com/foxglove/foxglove-sdk/tree/main/ros/src/foxglove_bridge) publishes the usual topics: `/tf`, `/scan`, `/odom`, `/map`, the global and local costmaps, and `/cmd_vel`. Add a Foxglove 3D panel, and you see the robot in the warehouse: the laser scan, the costmap layers, and the path Nav2 is following down the aisle. The RB-Theron in the warehouse - live scan, costmap, and a clear fault dashboard _The RB-Theron in the warehouse - live scan, costmap, and a clear fault dashboard_ `ros2_medkit` runs as an HTTP gateway on the robot, and the extension adds four Foxglove panels next to that 3D view: - **Entity Browser** - a tree of the robot's entities, with a tab per resource (data, operations, configuration, logs, faults). - **Faults Dashboard** - the active faults, live. - **Updates** - the software update catalog. - **Server Info** - the gateway version and what it supports. You set the gateway URL once and all four share it. Foxglove gives me the live and recorded view of the robot. On top of that, the extension adds structured fault information, on-robot failure capture, and the actions I run to fix it. All sharing that one gateway URL. Before the extension, acting on the robot required shell access; you had to SSH in, change a parameter or copy a new binary, and restart the node. The extension turns those actions into panels, behind the gateway's role-based access control so only the right roles can run them. ## What SOVD is, and why it helps here SOVD is a REST-based, JSON-formatted diagnostic standard from the automotive industry. Cars have used standard diagnostic APIs to service large vehicle fleets for years, and SOVD is the modern, HTTP-based version of that idea. `ros2_medkit` brings it to ROS 2, so the same client works across different robots, and you build on a public standard instead of a custom protocol. On the gateway, the robot's areas, components, apps, and functions become queryable entities. Each entity exposes faults, logs, operations, and configuration. Software updates are handled at the server level, under `/updates`. The Foxglove extension reads all of this over the gateway's REST API. ## Send a goal, hit a failure I send the robot a goal from the Foxglove 3D panel. The robot starts driving toward a far aisle, and on the way my view drops - the 3D panel shows _"Connection failed."_ The operator's 3D link drops, while the fault dashboard keeps updating _The operator's live view drops. The dashboard on the right keeps updating only because this recording cuts the Foxglove bridge, not the network._ What I did not know at the time: earlier that morning, an over-the-air update had gone out to the sensor stack, tagged as a routine `/scan` noise-filter change. It had a bug. A forward slice of the laser now reports a phantom close return, a wall that is not there, right in front of the robot. It is a stuck LiDAR sector, the kind of fault a firmware regression or a smudged window can cause, and because it is attached to the sensor, it sits in front of the robot no matter which way it turns. Nav2 does the safe thing; it considers a phantom return an obstacle and won't plan a trajectory through it. Since it can't find a way around it, it gives up after executing recovery behaviors. The goal aborts, and the robot stops. But I was offline, so I didn't see any of it live. The key point is that the Faults Dashboard itself would not remain available during a real outage. It is a Foxglove panel and, like the rest of the interface, depends on a network connection to the robot. If that connection drops, the operator loses the entire view. The robot, however, keeps running. The ros2_medkit gateway, fault manager, and capture system all run on the robot itself. They detect the failure, raise the fault, freeze the relevant frame, and save a short MCAP recording even when no operator is connected. Because the record is created and stored on the device, it remains available when the connection returns. The guarantee is not that the dashboard survives the outage. It is that the robot preserves a complete record of what happened while the operator was offline. ## The robot turns its own failure into a fault It is important to be precise about what the robot actually reports. The LiDAR node does not detect or announce its own bug. It is simply publishing sensor data, so the gateway only sees the downstream consequence: Nav2 is no longer able to navigate successfully. The headline fault, its freeze-frame, and a downloadable MCAP _The fault, its freeze-frame, and a downloadable MCAP._ Two small, sensor-agnostic watchers turn that failure into faults. One of them monitors `/rosout`. When `controller_server` logs that it failed to make progress, the watcher creates a fault on the `controller-server` entity. The other monitors action results. When `navigate_to_pose` aborts, it creates an `ACTION_NAVIGATE_TO_POSE_ABORTED` fault on the `bt-navigator` entity with error severity. In other words, the robot tells me that navigation failed. It does not tell me that the LiDAR data is wrong. Identifying the LiDAR as the root cause is still my job, and the captured recording is what gives me the evidence to do it. The fault triggers a capture. The robot does not record all telemetry continuously, because storing full data from every robot would quickly exceed the device's available storage. Instead, once the fault is confirmed, the gateway saves only the data needed to investigate it. That capture includes a freeze-frame of relevant topic values at the moment of failure, such as `/scan`, `/cmd_vel`, and the local costmap, along with a short rosbag: a seven-second MCAP covering the moments around the fault. The recording is attached directly to the fault and available for download, so the evidence is already grouped and labeled with the failure it belongs to. The fault also latches. It does not disappear simply because the robot stops struggling. It remains active until someone clears it manually. That means a fault raised while I was offline is still waiting for me when I reconnect. ## Replay it in Foxglove I open the Faults Dashboard, one of the panels in my Foxglove layout. The `ACTION_NAVIGATE_TO_POSE_ABORTED` fault is listed on the `bt-navigator` entity, along with the time it was raised and a button to download the associated capture. The capture is a rosbag stored in the open MCAP format and served by the gateway through the SOVD bulk-data endpoint. Because each fault is linked to its own recording, I can download it directly from the dashboard or retrieve it manually: ```bash # the fault's bulk_data_uri points to its capture curl -OJ http://localhost:8080/api/v1/apps/bt-navigator/bulk-data/rosbags/ACTION_NAVIGATE_TO_POSE_ABORTED ``` The downloaded MCAP replaying in Foxglove - the phantom lidar sector isolated _The downloaded MCAP replaying in Foxglove - the phantom LiDAR sector isolated_ I open the file in Foxglove and replay it in the same 3D panel I use every day. This time, I can see what the live view never showed me: a solid arc of returns directly ahead that does not match the rest of the scan, the costmap interpreting it as a wall, and Nav2 unable to find a path through. The navigation fault indicated that the robot had stalled. The capture shows me why: the LiDAR was reporting an obstacle that was not actually there. The few minutes I missed are no longer a gap. They are a recording I can step through using the real data from the failure. ## Find what changed, then fix it I know LiDAR is lying. The next question is why, and the answer is usually "something changed." The whole robot in ros2_medkit is represented as a SOVD entity tree - every Nav2 node, the gateway, a health-check app - grouped into functions, and the Updates panel lists the update catalog and shows which build is applied. The SOVD entity tree, functions, and the update catalog _The SOVD entity tree, functions, and the update catalog_ There it is, and it is the only entry: the sensor build `broken_lidar_3_0_0` was swapped this morning, right before the trouble started. That timing is the thread to pull. Before changing anything, I confirm the root cause. Under the Fleet Diagnostics function, the robot exposes a single `run_health_checks` operation. I select the subsystems I want to test - LiDAR, localization, drivetrain, and costmap - and run the check. Foxglove builds the request form directly from the service schema, so I can trigger the diagnostics with a click instead of constructing a `ros2 service` call by hand. run_health_checks: the lidar fails, everything else is healthy _run_health_checks: the LiDAR fails, everything else is healthy_ It comes back as one report. Localization is healthy - AMCL converged. The drivetrain is healthy. The costmap flags a lethal blob just ahead with no matching feature in the static map, "consistent with a live sensor, not the environment." And the LiDAR is red: a stuck sector, hundreds of rays pinned at a constant close range. That is the confirmation I wanted: it is the LiDAR, not something downstream of it, and the phantom is coming from the sensor, not the world. So I ship a hotfix. The corrected build, `fixed_lidar_3_0_1`, is not sitting in the catalog waiting - a bad update does not arrive with its own fix pre-loaded. I publish it first (via a SOVD register call), then apply it in the Updates panel. Applying the OTA update: the Prepare & execute confirmation for fixed_lidar_3_0_1 _Applying the OTA update: the Prepare & execute confirmation for fixed_lidar_3_0_1_ **Prepare & execute** downloads the artifact and replaces the running sensor binary in a single operation, directly on the live robot. There is no SSH session and no restart. The dialog makes the behavior explicit: the update is "applied to a running system with no manual checkpoint between prepare and execute." The equivalent manual process requires registering the artifact first, then applying it in two separate steps: ```bash ./publish-fix.sh # registers fixed_lidar_3_0_1 via POST /api/v1/updates curl -X PUT http://localhost:8080/api/v1/updates/fixed_lidar_3_0_1/prepare curl -X PUT http://localhost:8080/api/v1/updates/fixed_lidar_3_0_1/execute ``` The gateway swaps the bad sensor build for the good one, and the phantom arc is gone from `/scan`. I re-run the health checks to be sure. After the fix: both builds in the catalog, health checks all green _After the fix: both builds in the catalog, health checks all green_ `run_health_checks` now comes back `ok: true`, nothing failed: the LiDAR reads nominal again, a full sweep with no stuck sector, and the costmap is clear. The Updates panel shows both the broken_lidar_3_0_0 that was installed in the morning with a bug in it and the newly applied `fixed_lidar_3_0_1` - the fix that replaced the old version. The fault does not clear on its own, and I would not want it to: it is a record that something failed, and clearing it is my call. I clear it from the panel and resend the goal. The mission resumes: faults cleared, the robot drives on _The mission resumes: faults cleared, the robot drives on_ This time the scan is clean, Nav2 drives the robot down the aisle, and it reaches the goal. By design, a person approves every action - nothing changes on the robot on its own. And it all runs on the local network, with no link to the cloud so that you can do it on a robot behind a firewall or with no internet connection. ## How the panels work with the gateway OTA over SOVD architecture diagram for the nav2 sensor-fix demo _OTA over SOVD - the architecture_ The panels are built with the Foxglove extension API. Each one registers as a panel and uses the settings interface to configure the gateway URL. They are also capability-driven. When a panel connects, it reads the gateway's root endpoint to determine which features are available, then shows only the relevant tabs. A gateway without a log manager, for example, simply displays fewer options. Behind the panels, every HTTP request goes through a typed client generated from the gateway's OpenAPI document. The fault stream uses the same client's Server-Sent Events helper. This keeps the panels aligned with the gateway's request and response schemas, without requiring us to maintain route strings or payload definitions by hand. The Faults Dashboard receives new faults over Server-Sent Events, so they appear as soon as they are raised. It also polls at a configurable interval as a fallback. Because the gateway API is published as an OpenAPI document, these panels are only one way to use it. You can generate a client in your preferred language and automate against the gateway directly. ## Run it yourself The complete goal-failure-fix loop is available in the `ota_nav2_sensor_fix` demo in `selfpatch_demos`. A single script builds the update artifacts and starts the gateway, OTA plugin, demo nodes, and update server: `./run-demo.sh` The demo runs an RB-Theron with Nav2 in a headless Gazebo simulation of the AWS warehouse. It also starts `foxglove_bridge` on port `8765`. In Foxglove: 1. Connect to `ws://localhost:8765`. 2. Add a 3D panel. 3. Add the `ros2_medkit` panels. 4. Set their gateway URL to `http://localhost:8080/api/v1`. At startup, the demo automatically applies the faulty sensor update, so the robot begins in the regressed state you would encounter in a real deployment. Send the robot a goal using the 3D panel's Publish tool, or run: ```bash ros2 topic pub --once /goal_pose geometry_msgs/msg/PoseStamped \ '{header: {frame_id: map}, pose: {position: {x: 1.8, y: 2.3, z: 0.0}, orientation: {w: 1.0}}}' ``` Nav2 stalls, the `ACTION_NAVIGATE_TO_POSE_ABORTED` fault appears on the `bt-navigator` entity in the Faults Dashboard, and the robot stops. From there, the full recovery flow is: 1. Download the fault capture. 2. Replay it to inspect the phantom LiDAR sector. 3. Run the health checks. 4. Publish and apply `fixed_lidar_3_0_1` from the Updates panel, or use the API calls shown above. 5. Clear the fault. 6. Send the goal again. This time, the robot reaches the goal. The offline moment shown in the post is a recording aid rather than a full network outage. An optional script temporarily disconnects only the operator's `foxglove_bridge`, which is why the dashboard can continue updating on screen. The underlying behavior is real: the gateway and fault manager run on the robot, and they continue detecting and recording the failure while the operator is disconnected. ## Next steps The four panels described above are available now in the `ros2_medkit_foxglove_extension`. They work with the current `ros2_medkit` gateway in both the Foxglove desktop and web apps. The OTA system used in this demo is intentionally development-grade. It does not yet include the safeguards required for production deployment, such as artifact signing, A/B partitions, automatic health-gated rollback, staged rollouts across a fleet, or a complete audit log. For now, it is intended for prototypes, lab robots, and internal demonstrations. The next steps for the extension are to expose more entity operations directly in the panels and provide richer links between faults and their associated captures. If you're building something similar or want to talk SOVD diagnostics, OTA updates, and robotics visualization, come join us in our [Discord community](/chat). We'd love to see what you're working on, answer your questions, and hear your feedback. ## Resources - [ros2_medkit](https://github.com/selfpatch/ros2_medkit) and the [docs](https://selfpatch.github.io/ros2_medkit/) - the SOVD gateway for ROS 2 - [ros2_medkit_foxglove_extension](https://github.com/selfpatch/ros2_medkit_foxglove_extension) - the extension and its `.foxe` build - [selfpatch_demos](https://github.com/selfpatch/selfpatch_demos/tree/main/demos/ota_nav2_sensor_fix) - the `ota_nav2_sensor_fix` demo - [Foxglove Documentation](https://docs.foxglove.dev/docs/extensions) - the Foxglove primitives the extension builds on ## About the Author [Bartosz Burda](https://www.linkedin.com/in/bartosz-burda/) works on `ros2_medkit` at selfpatch.ai, a company building a diagnostic layer for robots, PLCs, and software-defined devices. --- ### Native Foxglove Visualization in LeRobot URL: https://foxglove.dev/blog/native-foxglove-visualization-in-lerobot Date: 2026-07-08 Tags: product release, tutorial, visualization LeRobot 0.6.0 adds Foxglove as a native visualization backend. Pass --display_mode=foxglove to teleoperate, record, and rollout, or replay any dataset as a seekable timeline -- all streaming to the Foxglove app with no extra code. **tl;dr** [LeRobot](https://github.com/huggingface/lerobot) 0.6.0 ships native Foxglove support. Add `--display_mode=foxglove` to `lerobot-teleoperate`, `lerobot-record`, or `lerobot-rollout` to stream camera feeds and joint/action plots live over WebSocket. Replay any recorded dataset as a seekable timeline with `lerobot-dataset-viz --display-mode foxglove`. Connect the Foxglove app to `ws://localhost:8765` and you're done -- no custom integration code required. With [PR #3902](https://github.com/huggingface/lerobot/pull/3902), Foxglove becomes a first-class visualization backend for LeRobot -- selectable at runtime with a single flag. We are excited about this development and can't wait to see how the community embraces simpler workflows. ## Why Foxglove for LeRobot LeRobot's control loop produces a rich mix of data every timestep: per-motor joint positions, action targets, one or more camera images, and (optionally) depth maps. Foxglove's multi-panel layouts let you see all of this side by side -- camera feeds in Image panels, joint traces in Plot panels, all synced to the same timeline. Three things make this integration useful for imitation learning workflows: 1. **Live feedback during teleop and recording.** Spot a dead camera, a stuck joint, or a misaligned gripper _before_ you've recorded fifty episodes. The Foxglove app updates in real time as you move the leader arm. 2. **Seekable dataset playback.** Recorded episodes are served as a scrubbable timeline using Foxglove's [`PlaybackControl`](https://docs.foxglove.dev/docs/sdk/websocket-server#playback-control) capability. Play, pause, seek, and change speed -- frames are read from the on-disk dataset on demand and stamped at their original timestamps. 3. **Consistent topic layout across live and replay.** Whether you're streaming live or replaying a dataset, data appears on the same topics: `/observation/state`, `/action/state`, and `/observation/images/`. Build a layout once and reuse it everywhere. Under the hood, LeRobot uses the [Foxglove SDK](https://github.com/foxglove/foxglove-sdk) (`foxglove-sdk>=0.25.1`) to start a WebSocket server. Scalar features are published as typed JSON messages on a static `lerobot.Scalars` schema -- a flat `{label, value}` array so every joint and action dimension is automatically named in Plot panels. Images are published as `RawImage` (or JPEG `CompressedImage` when compression is enabled). ## Getting started LeRobot requires Python 3.12+. We run it using uv, but conda is also supported. ```bash uv venv --python 3.12 source .venv/bin/activate uv pip install 'lerobot[feetech,dataset_viz]' ``` Refer to [LeRobot Installation documentation](https://huggingface.co/docs/lerobot/v0.6.0/en/installation) for more information. ### Connect Foxglove 1. In the Foxglove app, select **Open connection** from the dashboard or left-hand menu. 2. Choose **Foxglove WebSocket** and enter `ws://localhost:8765` (the default bind address). 3. Start any LeRobot command with `--display_mode=foxglove` (live) or `--display-mode foxglove` (dataset replay) -- data appears as soon as the server starts. 4. [Download our layout](https://github.com/foxglove/foxglove-sdk/blob/main/python/foxglove-sdk-examples/so101-visualization/foxglove/lerobot_layout.json) for LeRobot or [create your own](https://docs.foxglove.dev/docs/visualization/layouts). We show you how to open a layout in Foxglove [in this video](https://youtu.be/TathDUV1ad0). ## Live teleoperation The fastest way to see Foxglove in action is during teleoperation. Pass `--display_data=true --display_mode=foxglove` to `lerobot-teleoperate` and move the leader arm -- camera feeds and joint plots update in the Foxglove app in real time. ```bash uv run lerobot-teleoperate \ --robot.type=so101_follower \ --robot.port=/dev/tty.usbmodemFOLLOWER \ --robot.id=my_follower \ --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \ --teleop.type=so101_leader \ --teleop.port=/dev/tty.usbmodemLEADER \ --teleop.id=my_leader \ --display_data=true \ --display_mode=foxglove ``` Replace the USB port paths with your actual device paths (find them with `lerobot-find-port`). Each motor's position appears as a named series on `/observation/state`, and the teleoperator's targets appear on `/action/state`. Camera frames stream to `/observation/images/front`. ## Recording with live visualization When collecting demonstration data, live visualization is invaluable for catching problems early. Add the same flags to `lerobot-record`, and you'll see exactly what the dataset will contain as each episode is captured. ```bash uv run lerobot-record \ --robot.type=so101_follower \ --robot.port=/dev/tty.usbmodemFOLLOWER \ --robot.id=my_follower \ --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \ --teleop.type=so101_leader \ --teleop.port=/dev/tty.usbmodemLEADER \ --teleop.id=my_leader \ --dataset.repo_id=${HF_USER}/foxglove-demo \ --dataset.num_episodes=5 \ --dataset.single_task="Pick up the cube" \ --display_data=true \ --display_mode=foxglove ``` The live Foxglove panel gives you instant feedback on camera framing, joint ranges, and action tracking -- much easier than discovering a bad episode after recording dozens of them. ## Seekable dataset playback The most powerful part of this integration is dataset replay. `lerobot-dataset-viz` can serve any LeRobot dataset -- from the Hugging Face Hub or recorded locally -- as a seekable timeline in Foxglove. The playback bar drives play, pause, seek, and speed; frames are read from disk on demand and stamped at their original dataset timestamps. ```bash # A public SO-101 pick-and-place dataset uv run lerobot-dataset-viz \ --repo-id lerobot/svla_so101_pickplace \ --episode-index 0 \ --display-mode foxglove # A dataset you recorded locally uv run lerobot-dataset-viz \ --repo-id ${HF_USER}/foxglove-demo \ --root ~/.cache/huggingface/lerobot/${HF_USER}/foxglove-demo \ --episode-index 0 \ --display-mode foxglove ``` This uses the same `PlaybackControl` capability described in our [earlier post on local player integration](/blog/connect-foxglove-to-your-local-player-with-playback-control). LeRobot advertises the episode's time range, and the Foxglove app sends playback commands back to the server. A background thread reads frames from the on-disk dataset for whatever time you scrub to -- no need to load the entire episode into memory upfront. Dataset replay also publishes episode metadata (`done`, `truncated`, `reward`, `success`) on `/episode/state`, and uses the dataset's feature metadata to label each scalar series with the correct joint names. ## Policy rollout visualization The same flags work for policy evaluation. When running `lerobot-rollout`, add `--display_data=true --display_mode=foxglove` to watch a trained policy execute in Foxglove -- useful for comparing what the policy observes and commands against what you demonstrated during recording. ## Tips and options A few handy flags beyond the basics: | Goal | Live commands (`teleoperate` / `record` / `rollout`) | Dataset replay (`lerobot-dataset-viz`) | | -------------------------- | ---------------------------------------------------- | -------------------------------------- | | JPEG-compress images | `--display_compressed_images` | `--display-compressed-images` | | Custom port | `--display_port=8766` | `--web-port 8766` | | Stream to another machine | `--display_ip=0.0.0.0` | `--host 0.0.0.0` | | Don't auto-play on connect | -- | `--no-autoplay` | When streaming to another machine, connect the Foxglove app to `ws://:8765` instead of `localhost`. **Depth images:** if your robot has a depth camera, LeRobot handles it automatically. During live streaming, depth values are normalized for display contrast. During dataset replay, raw depth measurements are preserved so you can inspect the actual values. **Flag naming:** live commands use underscores (`--display_mode`, `--display_data`) while `lerobot-dataset-viz` uses hyphens (`--display-mode`). This matches each tool's CLI convention -- just something to watch for when switching between workflows. ## What's next LeRobot's Foxglove integration covers the full imitation learning loop: teleoperate, record, replay, and evaluate -- all through the same WebSocket topics and schemas. No need to roll it out yourself anymore. To go further, check out the [Foxglove SDK examples](https://github.com/foxglove/foxglove-sdk/tree/main/python/foxglove-sdk-examples) for building custom visualizations on top of LeRobot's topic layout -- like a live 3D kinematic model driven from joint positions. Resources: - [LeRobot Foxglove visualization source](https://github.com/huggingface/lerobot/blob/main/src/lerobot/utils/foxglove_visualization.py) - [LeRobot dataset visualization docs](https://huggingface.co/docs/lerobot/en/using_dataset_tools) - [Foxglove PlaybackControl documentation](https://docs.foxglove.dev/docs/sdk/websocket-server#playback-control) - [Foxglove WebSocket connections](https://docs.foxglove.dev/docs/getting-started/custom#foxglove-websocket) Download the latest [Foxglove desktop app](/download) and try it with your LeRobot setup today. Join our [Discord](/chat) community or follow us on [X](https://x.com/foxglove) and [LinkedIn](https://www.linkedin.com/company/foxglovedev) to stay up to date on all Foxglove releases. --- ### Visualizing Depth Maps and Pointclouds from the OAK-D S2 in Foxglove URL: https://foxglove.dev/blog/visualizing-depth-maps-and-pointclouds-from-the-oak-d-s2-in-foxglove Date: 2026-06-18 Tags: community, tutorial How I integrated a Luxonis OAK-D S2 stereo depth camera into my LeKiwi robot's ROS 2 stack -- configuring the depthai-ros driver for low bandwidth, compressing pointclouds with Cloudini, and visualizing RGB images, depth maps, and pointclouds in Foxglove's 3D panel. **tl;dr** In this article, I discuss integrating a Luxonis OAK-D S2 stereo depth camera into my LeKiwi robot's ROS 2 stack. I cover the steps I took to configure the depthai-ros driver to optimize bandwidth, simplify the URDF and launch files, and add pointcloud compression with Cloudini. I also discuss how I visualized RGB images, depth maps, and (compressed and uncompressed) pointclouds in Foxglove's 3D panel, and the challenges I faced along the way. Foxglove's 3D panel showing a full-color RGBD pointcloud of a room, with the LeKiwi robot model in the foreground ## Project Context Over the past few months, I've been steadily upgrading my [LeKiwi](https://github.com/SIGRobotics-UIUC/LeKiwi/tree/main)-based mobile robot platform to run autonomously with [ROS 2](https://github.com/adityakamath/lekiwi_ros2). My earlier posts covered [adding a LiDAR for 360-degree perception](/blog/upgrading-the-lekiwi-into-a-lidar-equipped-explorer), [calibrating a monocular camera](/blog/calibrating-a-monocular-camera-for-the-lekiwi-robot-using-ros-2) for the base, [teleoperating the robot using a Steam Deck](/blog/teleoperating-the-lekiwi-from-a-steam-deck), and finally [configuring Nav2 to drive the robot autonomously](/blog/autonomous-navigation-with-lekiwi-and-nav2). This article is slightly tangential, but it focuses on the next major sensor upgrade: adding a stereo depth camera to give the robot 3D perception. The LeKiwi is originally designed to be a mobile manipulator, with space to mount a [SO-101 robot arm](https://github.com/TheRobotStudio/SO-ARM100), which I have always wanted to add. But while building the SO-101 arm, I realized that the first two joints are perfect for a pan-tilt mechanism, and decided to stop there. Then I remembered that I had a couple of [Luxonis OAK depth cameras](https://shop.luxonis.com/collections/oak-cameras-col), and thought it would be fun to mount one on this pan-tilt mechanism to give the robot an active vision system that can look around and perceive depth. CAD render of the pan-tilt mechanism built from SO-101 arm joints, with the OAK-D S2 camera mounted on top This would not only be a fun hardware integration challenge and a learning experience, but it would also allow me to experiment with visual SLAM, visual-inertial odometry, VR integration, and dig a little deeper into vision-based AI. In this article, I will only focus on how I integrated the [OAK-D S2](https://shop.luxonis.com/products/oak-d-s2) with ROS 2, and everything I did to visualize its data on Foxglove. If you are interested in the pan-tilt mechanism itself, I've covered that in a [separate post on my blog](https://kamathrobotics.com/pan-tilt-controls-using-ros-2). ## Why the OAK-D S2? The short answer is that I had one lying around. But I had a choice to make. I have three Luxonis cameras, [the original OAK-D](https://shop.luxonis.com/products/oak-d) from their very first Kickstarter, the [OAK-D Lite](https://shop.luxonis.com/products/oak-d-lite-1), and a recently acquired [OAK-D S2](https://shop.luxonis.com/products/oak-d-s2). The original OAK-D is a great camera, but it's quite big and power-hungry, so I immediately ruled it out. Hand holding two Luxonis OAK cameras, with a third already mounted on the robot's pan-tilt mechanism in the background The real choice was between the OAK-D Lite and the OAK-D S2. Both cameras are pretty similar; they have an RGB camera, two monochrome cameras for stereo vision (with the same baseline), and the same Myriad X VPU. The S2 has a higher stereo resolution (800p vs 480p), better low-light performance, and a built-in IMU for visual-inertial odometry. The Lite is smaller and cheaper, but it doesn't have the IMU and has lower stereo resolution. For my use case, the S2's improved depth quality and VIO capabilities were worth the extra cost and size. The real winning feature of the OAK-D S2 (in fact, any camera from Luxonis) is the [DepthAI](https://docs.luxonis.com/software-v3/depthai/) software stack, which provides onboard processing for stereo depth computation, VIO, and AI inference. This means I do not need to run heavy computation on my Raspberry Pi 5, which is already running the [ROS 2 Control stack for motor control](https://kamathrobotics.com/wiring-up-ros-2-control-for-lekiwi), LiDAR processing, and navigation. These cameras can run custom pipelines that output RGB images, depth maps, visual-inertial odometry estimates, and even pointclouds, all with minimal CPU load on the host. This makes it an ideal choice for a mobile robot with limited onboard compute. ## The Integration Journey Luxonis maintains an official ROS 2 package called [`depthai-ros`](https://docs.luxonis.com/software-v3/depthai/ros/), which includes a modular driver that can be configured for different camera models and pipelines. I cloned it into my workspace and installed dependencies following the instructions in the repository. The package compiled cleanly, and the example launch files worked out of the box with RGB and depth images streaming immediately. ### Configuration for Bandwidth Optimization The [depthai_ros_driver](https://github.com/luxonis/depthai-ros/tree/kilted/depthai_ros_driver) uses a pipeline-based architecture configured via YAML parameter files. The package includes several example configurations, but none combine RGB, depth, and VIO. So, I decided to create my own config tailored to my use-case: RGB images for AI inference, depth maps for obstacle avoidance, VIO as an additional odometry source, and optional pointclouds for mapping. I created two custom configurations: 1. [`oakd_vio.yaml`](https://github.com/adityakamath/pantilt100/blob/main/pt_bringup/config/oakd_vio.yaml): Default config optimized for low bandwidth 2. [`oakd_vio_pcl.yaml`](https://github.com/adityakamath/pantilt100/blob/main/pt_bringup/config/oakd_vio_pcl.yaml): Adds RGBD pointcloud output to the bandwidth-optimized config (higher CPU load) The bandwidth optimization was critical for two reasons: First, I'm running it on a Raspberry Pi 5 alongside other ROS 2 nodes, and some additional AI features I plan on adding. Second, I plan on streaming data to visualize on Foxglove, sometimes even remotely. So, I downscaled RGB to 1/4 ISP resolution with JPEG compression, reduced depth to 15 Hz with 2x decimation, disabled raw stereo image publishing, and kept VIO at 60 Hz for smooth camera pose tracking. I created the separate pointcloud config because I don't need pointclouds during regular teleoperation or simple Nav2 operation. Keeping it separate reduces CPU load when not needed. When pointcloud mode is enabled, the config changes significantly: depth rate increases from 15 Hz to 30 Hz to match the RGB rate, and the 2x decimation filter is disabled. 2x decimation would reduce the pointcloud to 4x fewer points, making it too sparse for useful visualization or mapping. Instead, bandwidth is managed by compressing the full-resolution pointcloud with [Cloudini](https://github.com/facontidavide/cloudini) (more on this later), which preserves spatial detail while still achieving good compression. ### Custom Launch File and URDF Integration I started facing issues when I tried to integrate the OAK-D S2 URDF and set up the launch file. The depthai-ros package is designed to be a general-purpose package to support Luxonis' entire product line of cameras, which means it provides a single [parametrized URDF Xacro](https://github.com/luxonis/depthai-ros/tree/kilted/depthai_descriptions/urdf) that can be configured for each camera model, and a [comprehensive ~300 line launch file](https://github.com/luxonis/depthai-ros/blob/kilted/depthai_ros_driver/launch/driver.launch.py) with all possible features and configuration options. This makes perfect sense for a general-purpose driver, but for my single-camera robot, this complexity was overkill. I created a [minimal 80-line launch file](https://github.com/adityakamath/pantilt100/blob/main/pt_bringup/launch/oakd.launch.py) and a [custom URDF macro](https://github.com/adityakamath/pantilt100/blob/main/pt_description/urdf/oakd_s2.module.xacro) tailored specifically for the OAK-D S2 on my robot. The launch file does the following: 1. Switches between `oakd_vio.yaml` and `oakd_vio_pcl.yaml` based on a `pointcloud` argument 2. Starts the camera driver as a composable node in a container 3. Overrides TF frame parameters to integrate with my existing robot (parent frame: `tilt_link` on the pan-tilt mechanism, base frame: `oak_link`) The custom URDF was necessary because the automatic URDF generation in `depthai-ros` maps the OAK-D S2 to the OAK-D Pro mesh (the meshes are identical) but doesn't include the IMU frame or offsets for the built-in IMU. My custom macro defines the camera base link (`oak_link`), IMU frame (`oak_imu_frame`), and uses the correct IMU offset from the OAK-D S2 datasheet. ## Visualizing with Foxglove Now that I had the camera configured and the launch file set up, I could test the integration and visualize the data in Foxglove. I launched the pan-tilt mechanism with the OAK-D S2 camera and the combined URDF. On a separate terminal, I launched the Foxglove bridge. On my laptop (on the same network as the robot), I opened Foxglove and connected to the bridge. ```bash # Launch the LeKiwi robot with the pan-tilt mechanism and the OAK-D S2 camera ros2 launch lekiwi_bringup lekiwi.launch.py # Launch the pan-tilt mechanism with the OAK-D S2 camera ros2 launch lekiwi_bringup lekiwi.launch.py config:=pantilt # Launch the pan-tilt mechanism with the OAK-D S2 camera and pointcloud outputs ros2 launch lekiwi_bringup lekiwi.launch.py config:=pantilt pointcloud:=true # Launch the Foxglove bridge on a separate terminal ros2 launch foxglove_bridge foxglove_bridge_launch.xml ``` ### 3D Panel To visualize the camera outputs, I relied completely on the 3D panel in the Foxglove app, using which I could visualize the following topics: 1. The robot's URDF model with the pan-tilt mechanism and the camera mesh The robot's URDF model with the pan-tilt mechanism and camera mesh shown in Foxglove's 3D panel, with the transform tree listed in the panel settings 2. The RGB image projected onto a frustum in 3D space The OAK-D S2 RGB image projected onto a camera frustum in Foxglove's 3D panel 3. The depth map image, rendered as a pointcloud with depth-based coloring The depth map rendered as a pointcloud with rainbow depth-based coloring in Foxglove's 3D panel 4. The depth map image, with the RGB image used as a color map (by changing the RGB topic option on the left panel) The depth map rendered as a pointcloud, colored using the RGB image, in Foxglove's 3D panel 5. The pointcloud topic (when enabled using `pointcloud:=true`), rendered as a colored pointcloud The full RGBD pointcloud rendered with color in Foxglove's 3D panel ## Pointcloud Compression using Cloudini Despite the bandwidth optimizations, visualizing pointclouds remotely in Foxglove was still a problem. The 3D panel would freeze within minutes due to the sheer volume of data. So, I needed a better solution. I turned to [Cloudini](https://github.com/facontidavide/cloudini), a pointcloud compression library by [Davide Faconti](https://x.com/facontidavide) that achieves impressive compression ratios using lossy quantization. Better yet, it includes a Foxglove extension that lets you visualize compressed pointclouds directly without decompressing them on the client. The initial setup was simple: clone the repo, build it in my ROS 2 workspace, and [add it to my launch file](https://github.com/facontidavide/cloudini/blob/main/cloudini_ros/README.md). [The documentation](https://github.com/facontidavide/cloudini/blob/main/README.md) was clear, and I had it running in about 10 minutes. But I faced some issues along the way. ### Cloudini Foxglove Extension To visualize the compressed pointcloud in Foxglove, I needed the Cloudini Converter extension from [Foxglove's extension registry](https://github.com/foxglove/extension-registry). The extension appears in Foxglove's available extensions list and can be installed directly from there. Foxglove's Available extensions list, with the Cloudini Converter extension highlighted After installing the extension, Foxglove was able to decode the compressed pointcloud topic, and I could select it from the Topics section of the 3D Panel options. That confirmed the compressed pointcloud data was now being decoded correctly, but it revealed a new issue: all the colors were gone. Foxglove 3D panel settings for the uncompressed and compressed pointcloud topics, side by side ### The RGB Quantization Problem While the uncompressed pointcloud had perfect RGB colors, the compressed pointcloud showed up completely black in the BGR color mode on Foxglove. I even had to change the app's color scheme to light mode to visualize the pointcloud properly. The compressed pointcloud rendered without color, appearing black, in Foxglove's 3D panel shown in light mode After digging into the Cloudini source code, I found the issue. The `depthai-ros` driver stores RGB data as a bit-packed integer inside a `FLOAT32` field. Cloudini applies lossy quantization to all `FLOAT32` fields by default, assuming they're XYZ coordinates. This destroys the bit-packed color data. The problem is in how the `depthai-ros` pipeline packages RGB data for pointclouds. Since I did not want to push AI-generated changes to the `depthai-ros` or Cloudini source code, I ended up writing a [custom pointcloud compressor node](https://github.com/adityakamath/lekiwi_ros2/blob/d6f98f0d3bd7023fd1149424becb15fa19df1d7c/lekiwi_bringup/src/pcl_compressor_node.cpp) that uses Cloudini as a library but applies field-specific quantization. The node loops through all pointcloud fields after Cloudini's initial encoding setup, checks for color field names (rgb, rgba, bgr, bgra), and exempts them from quantization by clearing their resolution parameter. XYZ fields still get the 1mm quantization for compression, but color data stays intact. This does impact the compression ratio, but solves the visualization problem. I updated my launch file to load this custom node when `pointcloud:=true`. The compressed pointcloud rendering with full RGB color in Foxglove's 3D panel This worked perfectly. The compressed pointcloud now has full RGB colors, the bandwidth is dramatically reduced, and the visualization is nearly identical to the uncompressed pointcloud. Most importantly, the visualization no longer freezes. There's still some lag when I move the pan-tilt mechanism, as the compressed pointcloud takes a moment to update, but it is not too bad and quite usable for remote visualization. The compressed pointcloud updating in Foxglove's 3D panel as the pan-tilt camera moves ## Wrapping Up This integration took longer than I expected, but I learned a lot about depth cameras, bandwidth optimization, and the quirks of pointcloud data formats. Foxglove was essential throughout; being able to visualize RGB, depth, TF frames, and pointclouds simultaneously made debugging so much faster. Cloudini is an amazing library, and I'm grateful for the open-source work that Davide Faconti has put into it. While I'm not entirely sure how well compressed pointclouds will work for features like visual SLAM, it is a fantastic solution for remote visualization. At this point, the OAK-D S2 is fully integrated. RGB streams at 30 FPS, depth at 15 Hz, VIO at 60 Hz. Compressed pointclouds can be visualized really well in Foxglove with full color preservation. While the pan-tilt mechanism and the camera are ready for visual SLAM and AI-based perception, that's a project for another day. For now, the next step is to dig deeper into my LiDAR-based Nav2 implementation and implement some advanced features. All the code related to the pan-tilt mechanism and the OAK-D S2 can be found in the [pantilt100](https://github.com/adityakamath/pantilt100/tree/main) GitHub repository, and it has been integrated into [lekiwi_ros2](https://github.com/adityakamath/lekiwi_ros2) as a git submodule, if you want to dig into the details. As always, this project is an active work in progress, so expect regular changes. Feel free to reach out if you're working on similar camera integrations - I'm happy to share what worked (and what didn't). If you're building something similar or just want to talk depth cameras, pointclouds, and robotics visualization, come join us in our [Discord community](/chat). We'd love to see what you're working on, answer your questions, and hear your feedback. --- ### Autonomous Navigation with LeKiwi and Nav2 URL: https://foxglove.dev/blog/autonomous-navigation-with-lekiwi-and-nav2 Date: 2026-06-09 Tags: community, tutorial How I added autonomous navigation to my LeKiwi robot with Nav2 -- covering LiDAR filtering, mapping with slam_toolbox, localization with AMCL, and configuring Nav2 for a holonomic base, all visualized and controlled from Foxglove. **tl;dr** This article details how I added autonomous navigation to my LeKiwi robot using Nav2, covering LiDAR filtering, mapping, and localization, and configuring Nav2 for a holonomic platform. I used Foxglove's 3D panel throughout to watch the map grow during mapping, set the initial pose estimate for localization, and send navigation goals directly on the map. The result is a mobile base that navigates autonomously, with a seamless switch between teleop and Nav2 control. ## Project Context This is the next chapter in my [ongoing series](https://kamathrobotics.com/series/lekiwi) of building a ROS 2-powered autonomous mobile robot based on the [LeKiwi](https://github.com/SIGRobotics-UIUC/LeKiwi) platform. So far, I've [integrated a LiDAR](/blog/upgrading-the-lekiwi-into-a-lidar-equipped-explorer), [calibrated the onboard camera](/blog/calibrating-a-monocular-camera-for-the-lekiwi-robot-using-ros-2), implemented [teleoperation using a Steam Deck](/blog/teleoperating-the-lekiwi-from-a-steam-deck), and added a [BNO055 IMU](https://kamathrobotics.com/bno055-imu-hardware-abstraction) with [sensor fusion](https://kamathrobotics.com/sensor-fusion-on-lekiwi) for reliable odometry. With the perception stack, teleoperation, and odometry in place, autonomous navigation was the obvious next step. This post covers how I got [Nav2](https://docs.nav2.org/), a popular ROS 2 navigation library, running on LeKiwi, from the sensor prerequisites through to sending navigation goals in Foxglove. The implementation lives in the `lekiwi_navigation` package in my [`lekiwi_ros2`](https://github.com/adityakamath/lekiwi_ros2) repository. ## Step 1: Setting Everything Up For the basic Nav2 setup, you need a reliable odometry transform (`odom → base_link`) and a clean LiDAR scan. I could also have gone down the vision route and used the on-board cameras for visual-inertial odometry (VIO) or visual SLAM (vSLAM), but I chose to keep it simple for now. ### Odometry and Sensor Fusion The [STS3215](https://kamathsblog.com/serial-bus-servo-motors-in-2025) motors used in the LeKiwi provide accurate state feedback (position and velocity), so the odometry from the [`omni_wheel_drive_controller`](https://control.ros.org/master/doc/ros2_controllers/omni_wheel_drive_controller/doc/userdoc.html) is quite reliable. However, since I had already integrated the BNO055 IMU, I fused its measurements with the wheel odometry using the Extended Kalman Filter (EKF) node from [`robot_localization`](https://github.com/cra-ros-pkg/robot_localization) to get a more robust odometry estimate. This provides a stable `odom → base_footprint` transform that both Nav2 and slam_toolbox rely on. I've written a [detailed article](https://kamathrobotics.com/sensor-fusion-on-lekiwi) about the sensor fusion implementation on my own blog. I've now got a working odometry source that runs at 50 Hz and publishes filtered/fused odometry messages on `/odometry/filtered`, along with the required `odom → base_footprint` transform (on my robot, `base_footprint` is the root frame of my platform, not `base_link`). ### LiDAR Filtering When I covered the LD19 hardware integration previously, the raw scan provided a 360° scan, but since then, I've added a [pan-tilt camera mechanism](https://kamathrobotics.com/pan-tilt-controls-using-ros-2) that sits right in front of the LiDAR. Without filtering, part of the scan would show up as a permanent obstacle during mapping. The same unfiltered scan in Foxglove, with an arrow highlighting the false obstacle the pan-tilt mechanism creates directly in front of the robot To fix this, I used [laser_filters](https://index.ros.org/p/laser_filters/). The `scan_to_scan_filter_chain` node subscribes to the raw LiDAR output (now remapped to `/scan_raw`), applies an angular range filter that masks out the sector occupied by the pan-tilt mechanism (nearly 70°), and republishes on `/scan`. Everything downstream subscribes to this filtered scan topic. ```yaml # scan_filter.yaml (excerpt) scan_filter_chain: - name: angle_filter type: laser_filters/LaserScanAngularBoundsFilterInPlace params: lower_angle: -0.6 # rad upper_angle: 0.6 # rad ``` Foxglove's 3D panel showing the filtered LiDAR scan, with the obstructed front sector removed for a clean scan around the robot With the filter in place, the scan displayed in Foxglove's 3D panel looks as expected: a clean scan around the robot, with the obstructed sector correctly filtered out. ## Step 2: Creating the Map With odometry and a clean scan in place, the next step was to build a map so that I could navigate in it. ### Mapping using `slam_toolbox` I used the recommended approach of using [`slam_toolbox`](https://github.com/SteveMacenski/slam_toolbox) in asynchronous mapping mode to build the map. This package implements Simultaneous Localization and Mapping (SLAM) using a pose graph approach and builds a map incrementally as the robot moves. The asynchronous mode lets it process scans as fast as possible without blocking the rest of the system, which matters on a Pi 5. The main tuning I did was to reduce the scan processing rate (the LD19 runs at 10 Hz, which is more than slam_toolbox needs for a slow-moving indoor robot), cap the laser range to something sensible for indoor use (8 meters in my case), and push down the map rasterization frequency since that step is expensive and the default is unnecessarily aggressive. Nothing fancy, just bringing the defaults in line with the hardware. I then drove the robot around until the map looked complete in Foxglove's 3D panel, watching it grow and close loops in real time. ### Saving the Map You could technically keep using mapping mode for navigation; slam_toolbox would localize and update the map simultaneously. The problem is that it starts from scratch every session, which is not ideal. So, in order to have a consistent map for navigation, I needed to save the map and use it with a dedicated localization method for autonomous navigation. `slam_toolbox` lets you save maps using service calls, but this means that I need to interrupt my mapping session, switch to a terminal, and call the service every time I want to save a map. To make my life easier, I wrote a small [`map_saver_node`](https://github.com/adityakamath/lekiwi_ros2/blob/main/lekiwi_navigation/lekiwi_navigation/map_saver_node.py) script that listens to `/joy` messages and triggers the save when I press the R1 button on the controller. This way, I can save the map on the fly. When triggered, the node does two things in sequence: 1. Calls `/slam_toolbox/save_map` service, which writes `map.pgm` and `map.yaml` for use with AMCL and `nav2_map_server`. 2. Calls `/slam_toolbox/serialize_map` service, which writes `map.posegraph` and `map.data`, the binary format `slam_toolbox` needs for its own localization mode. ## Step 3: Localizing in the Map With the map saved, the next question is where the robot is within it. Nav2 needs a `map → odom` transform to plan and execute paths, which is the job of the localization layer. My original plan was to use `slam_toolbox`'s built-in localization mode, which can do this, but I also wanted to try AMCL for comparison, since I've been using it since ROS 1 and am more familiar with it. Eventually, I decided to keep both and use a launch argument to switch between them. ### Option A: Localization using `slam_toolbox` slam_toolbox offers a localization mode that reuses the serialized pose graph from the mapping step. It loads `map.posegraph` and `map.data` and runs scan matching against the stored structure, so it can handle loop closures and continuously refine the map as the robot moves. The robot starts from the map origin or from a known position configured at launch; either way, once scan matching locks in, it stays solid. The catch is that the robot's starting position needs to be somewhere recognizable in the saved map. On my setup, I just start the robot from the same spot every session, and localization snaps in immediately. While the localization is perfect, the map has changed; I've closed a door and added an obstacle. Despite this, the localization is never lost, and in addition, the map is eventually updated, which can then be saved again. ### Option B: AMCL [AMCL](https://docs.nav2.org/rolling/configuration_and_development/configuration_guide/others/configuring_amcl/) (Adaptive Monte Carlo Localization) works from the static `map.yaml` loaded by [`nav2_map_server`](https://docs.nav2.org/rolling/configuration_and_development/configuration_guide/core_servers/map_server/configuring_map_server/). It runs a particle filter and can converge from any starting position; you just need to give it an initial pose estimate. The map stays fixed (no loop closures, no incremental updates), but in return, you can start anywhere and re-initialize at any time. For AMCL, I provide the initial pose estimate directly from Foxglove. The [3D panel](https://docs.foxglove.dev/docs/visualization/panels/3d) lets you publish a 2D pose estimate by clicking on the map, which publishes a [`geometry_msgs/PoseWithCovarianceStamped`](https://docs.ros.org/en/foxy/api/geometry_msgs/html/msg/PoseWithCovarianceStamped.html) on `/initialpose`, exactly what AMCL listens to. In the video above, I provide an approximate position estimate that is not too far away from the robot's actual position. However, as I move the robot around, AMCL improves the position estimate. This can be seen from the covariance ellipse, which shows the uncertainty and reduces in size as the localization improves. One downside of AMCL is that it does not update the map, even though some minor changes are clearly visible. Despite this, the localization is still quite precise. However, if the environment changes drastically, I would not recommend AMCL unless a new map is created first. ### Switching between modes Now, I have three separate operating modes: slam_toolbox mapping, slam_toolbox localization, and AMCL. I implemented all three in a single `slam.launch.py` with a `slam_mode` launch argument for switching between modes, which is set in the top-level bringup launch file and passed down. Here's how to use it: ```bash # Mapping with slam_toolbox ros2 launch lekiwi_navigation navigation.launch.py slam_mode:=map # Localization with slam_toolbox ros2 launch lekiwi_navigation navigation.launch.py slam_mode:=localize map_name:=studio # Localization with AMCL ros2 launch lekiwi_navigation navigation.launch.py slam_mode:=amcl map_name:=studio ``` Note that the `map_name` argument specifies which map to load for localization - it corresponds to the name of the folder created by the `map_saver_node` script, which contains all the necessary files for both localization modes. ## Step 4: Navigating the Map Now that I have everything in place - reliable odometry, a clean scan, a map, and the ability to localize in it - the last step is configuring Nav2 itself. ### Nav2 Configuration I wanted to get the basic configuration up and running, so I started with [`navigation_launch.py`](https://github.com/ros-navigation/navigation2/blob/main/nav2_bringup/launch/navigation_launch.py) from [`nav2_bringup`](https://github.com/ros-navigation/navigation2/tree/main/nav2_bringup) as a reference, and then stripped down the example configuration to use only what I needed. I put this in a custom `nav2.yaml`. Nav2 is not a monolithic stack; it's a set of separate nodes orchestrated by `bt_navigator`. When a goal arrives, `bt_navigator` runs a Behavior Tree: it asks `planner_server` for a global path, hands it to `controller_server` to follow it, and calls `behavior_server` if the robot gets stuck. I used the default Behavior Tree config, which is all you need for a simple point-to-point navigation project. Since LeKiwi is holonomic, I went with [MPPI](https://docs.nav2.org/rolling/configuration_and_development/configuration_guide/controller_plugins/mppi_controller/configuring_mppic/) as the controller choice with `motion_model: Omni`. For the planner, I went with [SMAC 2D](https://docs.nav2.org/rolling/configuration_and_development/configuration_guide/planners_plugins/smac/smac_2d/configuring_smac_2d/): A\* on the costmap grid with no kinematic constraints, which suits a holonomic robot well. One thing to watch: velocity limits need to match the hardware and be set consistently across all Nav2 components, or MPPI will plan trajectories that the controller will reject. Once again, my goal was to get a simple configuration working first, so I did not dig into the advanced configuration options. My full configuration can be found [here](https://github.com/adityakamath/lekiwi_ros2/tree/main/lekiwi_navigation/config/nav2/nav2.yaml). To send navigation goals, I used Foxglove's 3D panel, which has a built-in nav goal publisher (I had to change the topic name to `/goal_pose`). I click a point on the map, drag to set the heading, and the robot starts navigating. Watching the costmap update, the planned path appear, and the robot follow it in real time in the same panel is what makes Foxglove particularly satisfying for this kind of work. In the video above, I also show how to run the navigation stack in mapping mode. While it is fun to play with and quite useful for mapping unknown spaces without teleoperation, I would not choose this method over navigating on a pre-made map. The map provides crucial information about the robot's environment, and creating it is computationally expensive, so it is best to create it once and reuse it. ### Switching between Twist messages With Nav2 generating velocity commands alongside teleop, I needed a way to switch between the two, as both publish to the same base controller and would conflict. So, I wrote a [`twist_switch_node`](https://github.com/adityakamath/lekiwi_ros2/blob/main/lekiwi_control/lekiwi_control/twist_switch_node.py) that lives in [`lekiwi_control`](https://github.com/adityakamath/lekiwi_ros2/tree/main/lekiwi_control), subscribes to Twist messages from both teleop and Nav2, and forwards one to the base controller via a `SetBool` service (`/twist_switch`) that selects the active source. I then configured [`joy_teleop`](https://index.ros.org/p/joy_teleop/) to call this service based on button presses on the controller, so I can toggle between the two Twist sources without switching to a terminal. In the video below, I was using my laptop to visualize and control the robot via Foxglove, so I decided to use my handy Button extension for switching. You can find this extension in Foxglove's extension registry, and I've also [written about it](https://kamathrobotics.com/i-made-a-button) if you are interested in reading how I built it. This node made testing genuinely fast and intuitive. I could send a navigation goal while still in teleop, manually reposition the robot, and watch the planned path update in real time in Foxglove's 3D panel. Switching to autonomous mode at any point would immediately kick off navigation along the latest path. I've demonstrated this in the video above. In the video, I also show how the navigation stack responds when I set a new goal while the robot is already moving towards another goal. ## What's next? Getting Nav2 running on the LeKiwi was a fun and rewarding process, and Foxglove was a huge help throughout. The ability to visualize the map, the robot's position, and the planned paths, while providing initial pose estimates and navigation goals directly from the same interface, made the whole process much smoother. The fact that I could do all of this remotely from my laptop, without needing a ROS 2 installation, was a game-changer for the development experience. Now that the navigation stack is working well enough to be useful, I can start navigating around the house while iteratively optimizing the Nav2 configuration. Next, I want to explore more advanced topics such as different planners and controllers, speed-limited and no-go zones, autonomous mapping/remapping, and eventually implement waypoint following for more complex missions. The full implementation so far is available in the [lekiwi_ros2](https://github.com/adityakamath/lekiwi_ros2) package on GitHub. As always, please proceed with caution, as the package is constantly evolving and may contain breaking changes. That said, feel free to check it out, replicate it on your own robots, and let me know if you have suggestions for improvements. Happy navigating! --- ### Foxglove vs. Foxglove Studio: Two Years On URL: https://foxglove.dev/blog/foxglove-vs-foxglove-studio-two-years-on Date: 2026-05-25 Tags: article, visualization, data management Two years after the last open-source Foxglove Studio release, Foxglove has shipped 50+ releases and become a data infrastructure platform for Physical AI. Here is what changed and how to evaluate whether to switch. In February 2024, we shipped the last open-source release of Foxglove Studio (v1.87.0). Since then, **Foxglove has shipped over 50 releases** of the commercial product. Visualization has gotten materially faster and deeper, but the bigger change is that Foxglove is no longer just a visualization tool. It's a data infrastructure platform for Physical AI, with a search engine over MCAP, sessions and events for curating training data, your own cloud storage as a first-class backend, an SDK for visualizing multimodal data with minimal dependencies (no complex middleware installs), and live remote connections to robots in the field. If you're running Studio 1.x or one of its community forks and wondering whether it's worth the switch, this is for you. A note on terminology: throughout this post, **"Foxglove Studio"** refers to the open-source 1.x line and any fork of it. **"Foxglove"** refers to the current commercial product available at [app.foxglove.dev](https://app.foxglove.dev) and as a desktop download. ## When the OSS still makes sense Let's start with the case for staying put. Studio 1.x is a capable single-user visualization tool. If you're a solo developer working on local MCAP or bag files, you have no team to share layouts with, and you're happy with a tool frozen at February 2024, it works. Although if you are a single user, Foxglove is entirely free, so might as well upgrade to get all the performance enhancements. Forks of Studio 1.x inherit the same shape: single-user, desktop-only, no data layer, no fleet layer. Some have added improvements; none have rebuilt the data and collaboration infrastructure that didn't exist in the OSS. They've also taken on the long-term cost of maintaining a robotics visualization codebase, which is a cost that's easy to underestimate. More on that below. If your work fits inside Studio 1.x's original shape, and the performance is acceptable, there's no urgency. If it's pushing past those edges with more engineers, more recordings, more devices, more time spent finding the right data, the gap is wider than it looks. ## What's changed in two years ### 1. Visualization keeps getting faster, deeper, and more capable With over 100 performance improvements across 50+ releases, the performance gap we wrote about [a year ago](/blog/foxglove-2-vs-foxglove-1) has only widened. Loading the same datasets, the current Foxglove renders **plots 4× faster** and **state transitions 40× faster** than Studio 1.x. Compressed video panels render up to **5× faster on Linux and Windows**, and raw image decoding now runs on the GPU via WebGPU. The macOS desktop app uses Metal directly. The Map panel has been rewritten end-to-end for live GPS overlays, historic paths, and large point sets.
Plot loading: Foxglove 1.87.0 (top) vs. 2.53.1 (bottom)
State transitions: Foxglove 1.87.0 (top) vs. 2.53.1 (bottom)
Raw image replay at 5×: Foxglove 1.87.0 (top) vs. 2.53.1 (bottom)
Beyond raw performance, the visualization surface has grown substantially. A non-exhaustive list of capabilities that don't exist in Studio 1.x: - **Image panel overlays**: layer segmentation masks, depth maps, or any second image topic directly on the base camera feed - **URDF joint state control**: drive URDF models from `sensor_msgs/JointState` or `foxglove.JointStates` with forward kinematics computed in-app, no external TF publisher required - **Draco-compressed point clouds**: render `foxglove.CompressedPointCloud` topics, dramatically smaller on the wire - **H.264, H.265, VP9, and AV1** video, plus WebP and 15+ raw image encodings - **Plot panel interactivity**: hover to preview, click to seek, with statistics, message-path math, and rolling overlays - **Command Palette (⌘K)** for keyboard-driven navigation and discovery - **Tabbed browsing on desktop** for working across multiple recordings in a single window - **Programmatic layouts from Jupyter**: configure and embed visualizations directly from Python notebooks - **Logarithmic depth buffer**: sharper rendering at large distance scales, fixing z-fighting that plagued autonomous vehicle and aerospace workflows in 1.x And the cadence is steady. Multiple releases a month, every month, with the change list driven by what customers actually push the product against. That's the part you don't see when you look at a static feature list. GrandTour Dataset visualized in Foxglove, showing 3D point clouds, multi-camera feeds, and joint state plots in a single layout. GrandTour Dataset visualized in Foxglove. Source: Robotic Systems Lab, ETH Zurich ([Blog post](https://foxglove.dev/blog/grandtour-taking-legged-robotics-into-the-wild)) > **"The lift on building custom robotics development tooling, specifically visualization, is so high that it detracts from the goal of building features and autonomy for the robots."** Vibhav Altekar, Co-founder & VP of Software, Saronic ### 2. An SDK to push data straight into Foxglove A category on its own, [Foxglove SDK](https://github.com/foxglove/foxglove-sdk) is an open-source interface to Foxglove that makes it easier than ever to visualize complex robotics data in real time. Our SDK allows you to establish a direct WebSocket connection to Foxglove and visualize multimodal data cross-platform, without relying on any middleware. Python, C++, and Rust are supported out of the box, and the SDK makes it easy to [record MCAPs](https://docs.foxglove.dev/docs/sdk/example#create-an-mcap-file-for-writing). ### 3. A data layer that didn't exist in 1.x Studio 1.x opened files. That's it. There was no concept of a recording catalog, no events, no devices, no search. Every team running Studio at any meaningful scale had to build that infrastructure themselves: S3 buckets, naming conventions, internal scripts, Slack threads asking "which recording had the planner regression?" While it works perfectly fine without it, Foxglove now ships that layer directly integrated, should you choose to reach for it now, or in the future. Data Search in Action **Data Search** lets you query across messages, events, devices, recordings, and sessions with a visual query builder. No separate data warehouse, no second copy of your data to keep in sync. It works directly against MCAP files, whether hosted in Foxglove Cloud or on your own infrastructure. "Find all time ranges where lateral acceleration exceeds 5 m/s² on devices running firmware v2.0" is a query you build in the UI and stream results from in seconds. **Sessions** group recordings into logical units, such as a drive, a flight, a mission, a test run, so analysis aligns with how you actually think about your data instead of how the recorder chunked the files. **Events** are time-range annotations with typed properties. Mark a failed pick, an operator intervention, or a perception glitch once, and it's queryable, shareable with teammates in one click, and curatable from then on. **Event Types** give those annotations a schema so every team member's "pick failure" event looks the same. Together, these turn Foxglove into a turn-key data flywheel. Query for every collision last week, review the matches on the timeline, annotate them with severity, and you have labeled data for triage, or your next model iteration. The same workflow in Studio 1.x is a Jupyter notebook and a long afternoon. **Bring Your Own Storage** lets enterprise customers connect Foxglove to an existing AWS S3, Google Cloud Storage, or Azure Blob Storage bucket. Your raw MCAP data stays at rest in storage you already own and pay for. Foxglove manages indexing, query, and visualization compute on top. Pricing is usage-based -- you pay for the work the platform actually does, not for the bytes you happen to be sitting on. For teams whose data lives in something more exotic (Iceberg tables, internal warehouses, proprietary lakes) **Remote Data Loaders** provide a lightweight backend interface to expose any queryable source as MCAP on demand, with caching and streaming handled for you. > **"We're at a critical juncture as we deliver the first Embodied AI product set to automotive customers - so shaving days off our iteration cycle with Foxglove is a huge advantage."** J'aime Laurenson, Product Lead, Wayve ### 4. Fleet visibility, not just file analysis Studio 1.x had no concept of a device. You opened a file. Whatever robot generated that file was incidental. Foxglove treats devices as first-class. You register them once, attach typed custom properties, set retention policies, track property change history over time, and see fleet-wide coverage on a continuous, **interactive timeline**. When a field team asks: "What happened at 14:32 on robot RV-007 last Tuesday?", you find it in seconds. Foxglove Timeline showing recording coverage across multiple devices over the past seven days. Timeline showing data from all devices in a single view The newest piece, [**Remote Visualization & Teleoperation**](/blog/announcing-remote-visualization-teleoperation-private-beta), extends this to live two-way connections. A secure, one-click connection to a robot in the field, over lossy or restricted networks, with no VPN required. It's the difference between a tool you use after the fact and an operations console for the fleet. ### 5. Team and platform features A short list of things that exist in commercial Foxglove and have never existed in the OSS: - **Shared layouts** at the organization and team level, with history and folder organization - **Web and desktop with the same codebase** let you share a link, and get the same view - **SSO** via Google, Microsoft, or custom OIDC; **SCIM** provisioning on Enterprise - **Projects** for data isolation between teams within the same organization - **REST API and webhooks** for CI/CD integration let you trigger pipelines when recordings arrive, or events are created - **Embedded viewer** with a TypeScript SDK and customizable keybindings for integrating Foxglove into your own review tools or operator dashboards - **AI-powered docs search** and an in-product chat that knows your layouts, your data, and your docs Foxglove Layouts library showing shared organization layouts organized by robot type, including Autonomous Vehicle, Drone, Humanoid, and Quadruped. Layout view in Foxglove > **"With Foxglove, everyone--from software engineers to field teams--can quickly understand and analyze robot performance without needing specialized environments."** Brenden Gibbons, VP of Software Engineering, Square Robot ## Give your non-developers access for free One of the loudest objections we've heard from Studio 1.x teams is seat cost. "I have 250 people on the team, but only 50 of them need Foxglove's full depth. Why am I paying for seats for everyone?" You're not, anymore. **Basic Seats** are free, unlimited, and included on Pro and Enterprise plans. They give viewing access to Foxglove-hosted data with existing layouts. This is perfect for execs, ops teams, field engineers, contractors, and anyone who needs to look at robot data without authoring their own layouts. Pair them with paid **Developer Seats** for the engineers who actually build the views and do deeper analysis. The self-service Pro plan also dropped its entry price significantly. Three Developer Seats and 1 TB of storage now start at **$20/month**, down from $126/month -- a configuration most small teams can run real workloads on. Volume discounts kick in as usage grows. Details and the cost calculator are on the [pricing page](/pricing). ## The hidden cost of forking The seductive thing about an MPL-2.0 codebase is that "free" looks like it stays free. In practice, forking a robotics visualization tool means inheriting a long tail of maintenance you may not be planning for: - **Two years of upstream changes you'd need to replicate**: all of the performance work above and a long list of bug fixes around streaming playback, video buffering, point cloud rendering, and codec support - **Ongoing security and dependency updates**: Electron, browser engine, native modules, image and video decoders - **Codec and schema compatibility**: new MCAP features, new image and video encodings, and new sensor schemas all need to be brought across or written from scratch - **The data, fleet, and collaboration layer** that doesn't exist in the OSS in the first place We've seen teams underestimate this and end up with a fork that lags 6, 12, 18 months behind, accumulates known bugs, and quietly becomes a full-time job for a team of senior engineers. Those engineers' time is the most expensive part of your roadmap. Pulling them off the core value you're delivering to market to maintain a visualizer is rarely the trade you want. The alternative is to let us do that work, which is what we do all day. ## What hasn't changed **MCAP is and always will be open source.** [github.com/foxglove/mcap](https://github.com/foxglove/mcap). The format, the libraries, and the CLI are all Apache-2.0, actively developed, and free. Your data isn't locked in. You can open it with anything that reads MCAP, today and indefinitely. **Layouts, data, and panels are portable.** Layouts are JSON; you can export them from Studio 1.x and import them into Foxglove. Recordings are MCAP or ROS bag, which both products read natively. The migration from Studio 1.x to Foxglove is genuinely low-friction. Most teams move over a long weekend and keep both available during the transition. ## How to evaluate The free tier of Foxglove lets you try almost everything with no time limit: all panels, web and desktop access, 3 developer seats, 10 GB of cloud storage, 5 connected devices, included query capabilities, unlimited personal layouts, and live connections to robots. The right way to evaluate is to put your own data in it. 1. [**Sign up for free**](https://app.foxglove.dev/signup): no credit card, no sales call 2. **Drop in your MCAP or ROS bag files**: same formats Studio 1.x reads 3. **Try a real workflow**: pick one debugging or triage task that frustrates your team today and run it end-to-end in Foxglove with Data Search and Events If you're operating at enterprise scale with large fleets, petabyte-scale data, self-hosted storage, SSO, and compliance requirements, [talk to our team](/contact). Bring Your Own Storage, Primary Sites, and Projects exist for exactly that conversation. > **"The very first time we tried Foxglove, we pinpointed a mis-configured trajectory in under an hour--something invisible to the naked eye."** Fifi Yeung, Founding Engineer, Reframe Systems ## Making your decision If you're one developer working with one bag file at a time on one laptop, Studio 1.x and its forks still do the job. Use them with our blessing. If you're a team scaling from prototype to production, with more data and more devices than you had a year ago, the gap between commercial Foxglove and a frozen 2024 OSS release, or its lightly maintained forks, isn't about a feature list. It's a different tool category. Foxglove today is the data infrastructure your engineers will end up building themselves if you don't bring it in. The question is whether your roadmap can afford that build. Try it on your data. See for yourself. - [**Start free at app.foxglove.dev**](https://app.foxglove.dev/signup) - [**See the full changelog**](https://docs.foxglove.dev/changelog) - [**Read customer stories**](/customers) --- ### Announcing: Remote Data Loaders URL: https://foxglove.dev/blog/announcing-remote-data-loaders Date: 2026-05-14 Tags: product release Remote Data Loaders let enterprise teams connect Foxglove to databases, warehouses, and file storage without migrating data--your service queries the source, emits MCAP, and runs on Kubernetes where your data already lives. Your data lives everywhere. In Databricks. In databases. In data warehouses. In MCAP files. Across multiple storage systems--sometimes all at once. For teams at large enterprise companies, like automotive OEMs, this reality creates a challenge: they want to use Foxglove's powerful visualization tools, but they can't--or won't--migrate all their data into a new storage system. Their data workflows are locked in place by organizational requirements, legacy systems, and the sheer complexity of consolidation. Today, we're solving that problem with Remote Data Loaders. ## What Are Remote Data Loaders? Remote Data Loaders allow you to connect Foxglove directly to your existing data sources without migrating anything. Instead of moving your data into Foxglove's storage, you build a lightweight HTTP server that queries your data however you need--from your database, data warehouse, or file storage--converts it to MCAP format using the Foxglove SDK, and deploys it via Kubernetes. The result? Full access to Foxglove's visualization capabilities while keeping your data exactly where it is, with all your existing workflows intact. ## How It Works The setup involves three steps: 1. Deploy an HTTP server using the Foxglove SDK that queries your data source (database, warehouse, files, etc.) in whatever way makes sense for your infrastructure 2. Deploy the Remote Data Loader using Kubernetes, giving you the flexibility to run it wherever your data lives 3. Visualize in Foxglove with full access to all panels, layouts, user scripts, and visualization tools Architecture diagram: data moves from a storage service (for example PostgreSQL, Databricks, or InfluxDB) through a data backend and the Remote Data Loader, which uses a cache bucket, into the Foxglove app. To demonstrate this, we've built a [working example](https://github.com/foxglove/sqlite-remote-data-loader-example) that loads data from SQLite in Rust. You can extend this concept to wrap whatever source of data you're dealing with--whether it be Postgres, Databricks, InfluxDB, or your own custom storage and query layer. Almost anything queryable can be built into a data backend. ## Who Should Use This? Remote Data Loaders are built for teams that: - Store data across multiple systems - Can't consolidate data into a single storage solution - Want to leverage Foxglove's visualization without disrupting existing workflows - Need flexibility in how they connect to their data ## Get Started Remote Data Loaders are available to customers on [enterprise plans](https://foxglove.dev/pricing) today. For a more detailed overview, take a look at the [documentation](https://docs.foxglove.dev/docs/visualization/connecting/cloud-data/remote-data-loader), or [contact us](https://foxglove.dev/contact) to set up a demonstration. --- ### Announcing: Image Overlays URL: https://foxglove.dev/blog/announcing-image-overlays Date: 2026-05-13 Tags: product release Foxglove now supports image overlays in the Image panel -- composite masks, heatmaps, and model outputs directly on top of your camera feed, with per-layer opacity and blend mode controls. When you are debugging perception, a raw camera stream is rarely enough on its own. You also need to see what your stack thinks is in the scene: lane masks, object tracks, traversability grids, or the output of a segmentation model. Today we are shipping **image overlays** in the **Image** panel. Pick any supported image topic as your base feed, then add one or more overlay layers that Foxglove composites on top in real time during playback. You keep masks and heatmaps on separate topics, and tune how they are drawn from the panel settings instead of baking everything into a single video stream. ## Why image overlays? Before image overlays, comparing a mask to the camera image usually meant opening two panels side by side, or preprocessing frames so the mask was permanently merged into the pixels you logged. With overlays you can: - **Keep recordings clean** -- log the camera and model outputs as separate channels and decide at review time how to view them. - **Stack multiple signals** -- add several overlay topics, each with its own visibility, ordering, opacity, and blend mode. - **Iterate visually** -- change opacity or blend mode while scrubbing time to see exactly where a detector agrees or disagrees with the sensor image. ## Example: agricultural plant masking Imagine an autonomous weeding robot. An image segmentation algorithm identifies vegetation and publishes a binary mask alongside the original camera stream. To make this concrete, we've created a companion [example Jupyter notebook](https://colab.research.google.com/drive/1EpAPXzDoq7GV0jXWqF3hzY1vprgSnGw6). It walks through loading plant imagery from MCAP, generating a cleaned mask in OpenCV using a simple color filter, and logging both the original input and the resulting binary mask as separate topics with the Foxglove Python SDK. The notebook uses Foxglove's [Jupyter integration](https://docs.foxglove.dev/docs/notebook), allowing you to view the results directly within an embedded Foxglove viewer. From left to right: the raw camera input, a binary vegetation mask, and the overlay--clearly showing where the color filter identifies plants in the scene. From left to right: the raw camera input, a binary vegetation mask, and the overlay -- clearly showing where the color filter identifies plants in the scene. To verify that the color filter hasn't missed any vegetation, you can lower the overlay opacity to reveal the underlying image -- making it easier to spot unmasked regions. The example below shows the overlay at 100% opacity (left) and 75% (right). The overlay at 100% opacity (left) and 75% opacity (right), showing how reducing opacity reveals the underlying camera image. ## How to configure image overlays In the **Image** panel, open **settings**, find **Image overlays**, and use **Add image overlay** to attach your mask topic on top of the base camera topic. Point the overlay at your mask topic, then adjust **Opacity** so you can still read texture in the base image. For **Blend mode**, **Alpha** performs standard alpha compositing using the layer opacity; **Add** adds overlay pixel values to the base image, which can be useful for intensity visualizations like brightness or heatmap accumulation. Use **Move up / Move down** to control compositing order when stacking multiple overlays. For single-channel overlays (such as `mono8`), the **Pixel alpha** control is especially useful for classical white-on-black masks. Choose **White is transparent** so pixels that decode as white become fully transparent and the camera pixels show through in those regions, while non-white mask pixels stay opaque on top of the base image. ## Notes Image overlays are designed to work with aligned image data during playback. Currently: - **Image-only support** -- overlays work with image topics (including compressed images), but not video streams - **Aligned inputs required** -- overlay images must match the base image in resolution and `frame_id` to ensure proper compositing These constraints may be relaxed in the future as we expand overlay support. ## Try it out Image overlays are available now in the Image panel -- see the [Image panel documentation](https://docs.foxglove.dev/docs/visualization/panels/image#image-overlays) for the full reference, and try it yourself with the [companion notebook](https://colab.research.google.com/drive/1EpAPXzDoq7GV0jXWqF3hzY1vprgSnGw6). Join our [Discord community](https://foxglove.dev/chat) or follow us on [X](https://x.com/foxglove) and [LinkedIn](https://www.linkedin.com/company/foxglove) to stay up to date on all Foxglove releases. --- ### Compressed Point Clouds in Foxglove URL: https://foxglove.dev/blog/compressed-point-cloud-support-in-foxglove Date: 2026-05-04 Tags: product release Foxglove now supports a CompressedPointCloud schema -- publish Draco-encoded point clouds and visualize them directly in the 3D panel, with all the same features you already use for PointCloud. Dense LiDAR point clouds dominate bandwidth and storage in most robotics stacks. Foxglove now supports a [`CompressedPointCloud`](https://docs.foxglove.dev/docs/sdk/schemas/compressed-point-cloud) schema -- publish Draco-encoded point clouds and visualize them directly in the [3D panel](https://docs.foxglove.dev/docs/visualization/panels/3d), with all the same features you already use for `PointCloud`. ## Getting started The [`CompressedPointCloud`](https://docs.foxglove.dev/docs/sdk/schemas/compressed-point-cloud) schema follows the same pattern as [`CompressedImage`](https://docs.foxglove.dev/docs/sdk/schemas/compressed-image) and [`CompressedVideo`](https://docs.foxglove.dev/docs/sdk/schemas/compressed-video): | field | type | description | | ----------- | --------- | ------------------------------------------------------------ | | `timestamp` | Timestamp | Timestamp of the point cloud | | `frame_id` | string | Frame of reference | | `pose` | Pose | Origin of the point cloud relative to the frame of reference | | `data` | bytes | Complete Draco-encoded point cloud payload | | `format` | string | Compression format. Supported: `"draco"` | Set `format` to `"draco"`, put the encoded bytes in `data`, and fill in `timestamp`, `frame_id`, and `pose`. Open the topic in a 3D panel and Foxglove handles decoding and rendering automatically. Foxglove runs the Draco WASM decoder in a background Web Worker, so decompression doesn't block the UI. The decoder reconstructs an interleaved point buffer equivalent to `PointCloud` and hands it to the same rendering path -- color modes (Flat, Color map, Gradient, RGBA separate fields), decay, point size, and stixels all work with compressed topics. ### Example Here's the core of a Python encoder using [DracoPy](https://pypi.org/project/DracoPy/) -- encode positions plus any named attributes, and the output goes straight into `CompressedPointCloud.data`: ```python import DracoPy import numpy as np def encode_draco(points: np.ndarray) -> bytes: positions = points[:, :3].astype(np.float32) return DracoPy.encode( positions, quantization_bits=14, compression_level=7, create_metadata=False, preserve_order=True, generic_attributes={ "intensity": points[:, 3].astype(np.float32).reshape(-1, 1), "ring": np.rint(points[:, 4]).astype(np.uint16).reshape(-1, 1), }, ) ``` For a complete working example that generates a Draco-compressed MCAP from nuScenes LiDAR data, see [foxglove/compressed-point-cloud-example](https://github.com/foxglove/compressed-point-cloud-example). nuScenes data is copyright © Motional and available under a [CC BY-NC-SA 4.0 license](https://creativecommons.org/licenses/by-nc-sa/4.0/). ### ROS integration `CompressedPointCloud` is available in [`foxglove_msgs`](https://index.ros.org/p/foxglove_msgs/) **>= 3.2.6**. Upgrade the package and publish `foxglove_msgs/msg/CompressedPointCloud` topics. ## Switching from PointCloud to CompressedPointCloud Compared to `PointCloud`, the schema drops `fields` and `point_stride` -- Draco carries that metadata inside the encoded payload, so there's no need to duplicate it on the outer message. Foxglove maps Draco attributes to `PointCloud`-equivalent fields: - **POSITION** → `x`, `y`, `z` (must be 3-component float32) - **Draco `COLOR`-typed attributes** → `red`, `green`, `blue` (+ `alpha` if 4-component) - **Named attributes** (via Draco metadata key `name` or `attribute_name`) → preserved by name (for example, `intensity`, `ring`) - **Multi-component attributes** → expanded with `_x`, `_y`, `_z`, `_w` suffixes So the data requirements are the same as `PointCloud`: your Draco payload needs at minimum a POSITION attribute. Color and other per-point attributes are optional and will show up in the 3D panel settings for color mapping. **Use string keys for generic attributes** when encoding -- DracoPy automatically embeds the key as a `name` metadata entry on each attribute, which Foxglove reads to label fields in the panel. If you use integer keys instead, attributes get generic names like `attribute_0`. **When to stay on `PointCloud`:** If you need lossless data for downstream algorithms, want zero decode overhead, or have custom fields that don't round-trip through Draco cleanly. ## Tips - **Quantization.** Draco quantizes by default. Most LiDAR visualization tolerates this well, but tune quantization bits if you need tighter fidelity. - **Bandwidth vs. CPU.** On constrained links (robot → cloud, remote debug), the tradeoff is almost always worth it. Typical compression is 3-6x depending on data. - **One cloud per message.** Each `CompressedPointCloud` must contain exactly one complete Draco point cloud. - **Decay.** Works with compressed topics. With decay enabled, Foxglove caps queued decodes per topic and drops frames once the queue is full. Without decay, only the latest completed decode is rendered. ## FAQ **What format does `data` need to be in?** A complete [Draco](https://google.github.io/draco/)-encoded point cloud (not a mesh) with `format` set to `"draco"`. The payload must contain the same point attributes you'd use in a `PointCloud` message: at minimum a 3-component float32 POSITION attribute (Foxglove maps this to `x`, `y`, `z`), and optionally a COLOR attribute (`red`, `green`, `blue`, `alpha`) and any other named attributes like `intensity` or `ring`. Use string keys in `generic_attributes` (for example, `"intensity"`, `"ring"`) so Foxglove can recover the field names -- DracoPy embeds the key as attribute metadata automatically. The `format` field is a string, so additional codecs can be supported in the future without a schema change. **Does Foxglove handle Draco's structure-of-arrays output?** Yes. The decoder converts Draco's per-attribute arrays into the interleaved byte layout the renderer expects. You don't need to do anything on your end. **Is it lossless?** Draco quantizes by default, making it lossy. Increase quantization bit depth to reduce loss at the cost of compression ratio. ## Get started See the [`CompressedPointCloud` schema docs](https://docs.foxglove.dev/docs/sdk/schemas/compressed-point-cloud) for reference implementations in Protobuf, FlatBuffers, ROS 1, ROS 2, and more. Join our [Discord community](https://foxglove.dev/chat) or follow us on [Twitter](https://x.com/foxglove) and [LinkedIn](https://www.linkedin.com/company/foxglove) to stay up to date on all Foxglove releases. --- ### Announcing: Improved Device Timeline URL: https://foxglove.dev/blog/announcing-improved-device-timeline Date: 2026-05-01 Tags: product release The device timeline in Foxglove has a new zoom and pan mode, a more flexible date picker, filters, and deep links so you can find the right recordings faster. If you manage a large fleet of robots, you likely spend a lot of time looking at the Timeline view. It's where you go to see a bird's eye view of your data across devices, and select the ranges you need to visualize. When something goes wrong, it's your starting point for finding the right recordings. We've rebuilt the device timeline from the ground up to make it easier to explore time-based recordings across all of your devices. The new timeline removes the friction of fixed time windows and clunky navigation, adds visibility into import status, and supports deep links so other tools can point directly at the precise time range and device you care about. ## What's new ### Improved timeline navigation (pan + zoom) The timeline now has more zoom features. Scrub to any time range using natural gestures (two-finger scroll, mouse wheel, or grab-and-drag), or just click on the column where you want to see more. You can also pan across the timeline to find the exact recording you are looking for. ### Date picker We overhauled the date picker to let you select arbitrary start and end times. If you already know the exact timestamp you need to be at, just paste it in. You're no longer limited to preset time blocks. ### Context preservation when visualizing Jump from the timeline into a visualization and come back without losing your place. The timeline preserves the exact point in time you were inspecting. ### Import-status filtering Toggle visibility based on a recording's import state: imported, pending/partially available, or not yet imported. This gives you clear visibility into what data is actually available now and what's still flowing through the ingestion pipeline (including edge-site availability). ### Device filtering Filter by device name or device ID so you can focus on the robots and devices you care about. ### Deep linking External systems can link directly to a timeline view, zoomed to a chosen time span or highlighting a specific recording on a device. This makes it simple to connect analytics, CI, or incident tools into the timeline workflow. ## Who it's for - Teams with large fleets who need to inspect recordings across devices. - Engineers or operators triaging coverage gaps, diagnostics, or specific incidents across multiple robots. - Integrations that want to link users directly to an exact recording span or device view. ## Get started The updated timeline view is now available on the latest version of Foxglove for all plan tiers. Log in to the [Foxglove web app](https://app.foxglove.dev/) or [download the latest Foxglove desktop app](/download) to give it a try today. More information can be found in our [developer docs](https://docs.foxglove.dev/docs/data/devices). Join our [Discord community](/chat) or follow us on [X](https://x.com/foxglove) and [LinkedIn](https://www.linkedin.com/company/foxglovedev) to stay up to date on all Foxglove releases. --- ### Teleoperating the LeKiwi Robot from a Steam Deck URL: https://foxglove.dev/blog/teleoperating-the-lekiwi-from-a-steam-deck Date: 2026-04-28 Tags: community, tutorial Learn how to turn a Steam Deck into a portable all-in-one LeKiwi controller and Foxglove monitoring station using Pixi, Distrobox, and ROS 2. **tl;dr** This article details how I turned my Steam Deck into a controller and visualization station for my LeKiwi mobile base. Using Pixi to install ROS 2, Distrobox to run the Foxglove desktop app, and the built-in controller with the ROS 2 joy node, I now have a portable, all-in-one setup for driving the robot and monitoring its data in Foxglove simultaneously. ## Context / Why a Steam Deck? A few years ago, I wrote about [using a Steam Deck as a robot controller](https://kamathrobotics.com/steam-deck-as-a-robot-controller) to drive and visualize my mecanum-wheeled robot [AKROS](https://kamathrobotics.com/retiring-the-akros-platform). That setup worked well, but getting ROS 2 running on the Steam Deck's operating system required some workarounds at the time. A lot has changed since then. Last year, I retired the AKROS platform and started working on a new robot - [LeKiwi](https://github.com/SIGRobotics-UIUC/LeKiwi) - to convert it to ROS 2 and make minor hardware upgrades as I progressed. The build has progressed a lot - I covered the [LiDAR integration](/blog/upgrading-the-lekiwi-into-a-lidar-equipped-explorer) and the [camera calibration](/blog/calibrating-a-monocular-camera-for-the-lekiwi-robot-using-ros-2). The robot now has a complete perception stack, [ROS 2 Control integration](https://kamathrobotics.com/wiring-up-ros-2-control-for-lekiwi), and communicates via [Zenoh](https://docs.ros.org/en/kilted/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.html) and [Tailscale](https://tailscale.com/). With all of that in place, I wanted a portable way to drive and monitor it without hauling a laptop around, which brought me back to the Steam Deck. The idea is straightforward: use the Steam Deck's built-in controller to drive the LeKiwi, and use Foxglove to visualize what the robot sees and does - all from a single handheld device. And since the Steam Deck is a full-fledged computer, I can even develop code on it when I need to. ## Setting up ROS 2 using Pixi When I first set up ROS 2 on the Steam Deck two years ago, I used [Distrobox](https://distrobox.it/) to create a full Ubuntu container and installed ROS 2 inside it. The Steam Deck runs on SteamOS, which is based on Arch Linux, so there is no native ROS 2 support available. It worked, but having to enter a container to run ROS commands added friction, and managing dependencies between the host and container was annoying. This time, I used [Pixi](https://pixi.sh/), a package manager that can install ROS 2 packages via the [RoboStack](https://robostack.github.io/) project. Unlike Distrobox, Pixi does not need a container - it resolves and installs packages into a project-local directory, similar to how conda works. No separate OS image to maintain, just native binaries managed by a single `pixi.toml` file. I already use this to run ROS 2 on my MacBook, so extending the same workflow to the Steam Deck was straightforward. ### Installing Pixi Installation is a one-liner using the following command. Then follow [this tutorial](https://pixi.sh/latest/tutorials/ros2/) to set up your favorite ROS 2 distro (I am currently using Kilted). ```bash curl -fsSL https://pixi.sh/install.sh | sh ``` ### Creating a ROS 2 workspace Once Pixi is installed, setting up a ROS 2 workspace is easy: ```bash pixi init ros2_ws -c robostack-kilted -c conda-forge cd ros2_ws ``` This creates a new Pixi project where you can add any ROS 2 packages you need using `pixi add `. ## Setting up Foxglove There are two ways to run Foxglove on the Steam Deck: the desktop app or the browser app. Both methods connect to your robot using the [Foxglove bridge](https://docs.foxglove.dev/docs/fleet/bridge), which runs on the LeKiwi's Raspberry Pi and exposes ROS 2 topics over a WebSocket connection. The bridge is the only additional piece needed on the robot side. ### Option 1: Desktop app via Distrobox Foxglove is not available on the Pixi registry, and there is no native Arch Linux package for it either. So for the desktop app, Distrobox is still my preferred option. First, install Podman and Distrobox, then create and enter an Ubuntu container: ```bash sudo pacman -S podman distrobox distrobox create --name ubuntu24 --image ubuntu:24.04 distrobox enter ubuntu24 ``` Inside the container, install Foxglove following the [official instructions](/download): ```bash sudo apt update && sudo apt install foxglove-studio libasound2t64 ``` The trick I learned this time is to export it as a host application, so you do not have to enter the container every time. This creates an executable on SteamOS that you can pin to the desktop or taskbar: ```bash distrobox-export --app foxglove-studio ``` Foxglove desktop app running on a Steam Deck via Distrobox ### Option 2: Browser app If you would rather skip the Distrobox setup entirely, Foxglove also has a [browser-based version](https://app.foxglove.dev/). No installation or workarounds - just open it in the Steam Deck's browser and connect to the Foxglove bridge running on the robot. In my testing, both options performed about the same, though I did not push either to its limits. I ended up using the desktop app since I already had Distrobox set up, but the browser option is a good alternative if you want to avoid that overhead entirely. ## Controller mapping From the Steam Deck settings, you can map the controller inputs to buttons and axes of a game controller in desktop mode. I reused the mapping I used with my previous robot: trackpads and back buttons as desktop mouse controls, and the remaining buttons mapped to a standard gamepad. Steam Deck controller mapping for robotics teleoperation With this or any other mapping, you can run the default [joy node](https://index.ros.org/p/joy/) without any special configuration. ## Joy node setup One of the nice things about the Pixi setup is how easy it is to add ROS 2 packages. Getting the [joy](https://index.ros.org/p/joy/) node running is as simple as: ```bash pixi add ros-kilted-joy ``` After that, you can launch it using: ```bash pixi shell ros2 run joy joy_node # OR pixi run ros2 run joy joy_node ``` The joy node reads input from the controller and publishes [`sensor_msgs/msg/Joy`](https://docs.ros2.org/latest/api/sensor_msgs/msg/Joy.html) messages, which can then be consumed on the LeKiwi side to drive the robot. You can also create a task in your `pixi.toml`: ```toml [tasks] joy = "ros2 run joy joy_node" ``` With this, a single `pixi run joy` command is all you need for teleoperation. ## Auto-start on boot To take this one step further, I created a [systemd](https://systemd.io/) service that automatically runs `joy` when the Steam Deck boots up and kills the process on shutdown: ```ini [Unit] Description=Joy Node (pixi run joy) After=network-online.target Wants=network-online.target [Service] Type=simple User=deck WorkingDirectory=/home/deck/ros2_ws ExecStartPre=/bin/sleep 15 ExecStart=/home/deck/.pixi/bin/pixi run joy ExecStop=/bin/bash -c 'pkill -f "lib/joy/joy_node" || true' Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target ``` To enable the service: ```bash sudo cp joy.service /etc/systemd/system/joy.service sudo systemctl daemon-reload sudo systemctl enable joy.service sudo systemctl start joy.service ``` Now, when the Steam Deck turns on, it immediately starts publishing Joy messages. I would not recommend it if you have more than one robot on your network, but for a single robot, it is not a problem. ## Integration testing With everything in place - connectivity between the Steam Deck and the robot's Raspberry Pi, the joy node reading controller input, and Foxglove visualizing data - it was time to put it all together. Integrated teleoperation setup with LeKiwi and Steam Deck My workflow looks like this: 1. I start up the Steam Deck in desktop mode, which automatically launches the joy node via the systemd service. On the LeKiwi side, the Raspberry Pi is already running its ROS 2 stack with the Foxglove bridge (I run these manually for now, but I am considering adding them as services on the robot as well). 2. I open the Foxglove app on the Steam Deck, connect to the bridge, and I am immediately seeing live sensor data - LiDAR scans, camera feeds, and the robot model in 3D (the meshes do take about a minute to load). 3. Then I can just pick up the Steam Deck and drive. The built-in analog sticks control the robot's omnidirectional movement, and I can visualize everything on Foxglove at the same time. My layout shows only the 3D panel, which displays the robot model with live LiDAR scans, the image stream, and the URDF. Foxglove 3D panel layout used during teleoperation ## Wrapping up The Steam Deck was already quite a capable platform for robotics work, but with the added service and tools like Pixi, my workflow has become much easier. Adding Foxglove to the mix shows exactly what the robot is seeing and doing as I drive it around. I can simply turn on the Steam Deck, and in a few clicks, I am ready to drive the robot and visualize. This setup has now become my go-to for testing and teleoperating the LeKiwi. It is portable, self-contained, and requires zero extra hardware. Additionally, with Tailscale for networking and Zenoh as middleware, I do not need to worry about communication anymore. My work on the ROS 2-powered LeKiwi is available on [GitHub](https://github.com/adityakamath/lekiwi_ros2), but please note that this is an active project, so expect rapid and sometimes breaking changes. ## Further reading - [Upgrading the LeKiwi into a LiDAR-equipped explorer](/blog/upgrading-the-lekiwi-into-a-lidar-equipped-explorer) -- how the LeKiwi ROS 2 build started, with LiDAR integration and the first teleoperation tests - [Calibrating a monocular camera for the LeKiwi robot using ROS 2](/blog/calibrating-a-monocular-camera-for-the-lekiwi-robot-using-ros-2) -- completing the LeKiwi perception stack ahead of this article - [The Foxglove Bridge and Tailscale VPN](/blog/the-foxglove-bridge-and-tailscale-vpn) -- how to set up live telemetry for your ROS system over a secure network, the same combination used here - [Announcing: Remote Visualization & Teleoperation](/blog/announcing-remote-visualization-teleoperation-private-beta) -- Foxglove's native remote visualization and teleoperation capabilities --- ### Bring Your Own Storage URL: https://foxglove.dev/blog/bring-your-own-storage Date: 2026-04-22 Tags: product release, data management Bring Your Own Storage lets enterprises keep raw MCAP data at rest in their own cloud storage while Foxglove manages the compute for indexing, query, and visualization. Today, we're introducing **Bring Your Own Storage (BYOS)**, a new deployment option for Foxglove Data Platform. With BYOS, you can keep all raw data in your own cloud storage, while Foxglove manages the compute needed to index, query, and visualize at scale. BYOS is a middle ground between Foxglove-hosted and self-managed deployments. It gives you more control over where data lives, avoids duplicating data into Foxglove, and removes the burden of deploying and operating infrastructure yourself. ## What is BYOS? BYOS lets you connect Foxglove Data Platform to an existing AWS S3, Google Cloud Storage, or Azure Blob Storage bucket. Foxglove provides a fully-managed indexing, query, and cloud visualization service (deployed in the same cloud region as your storage to minimize transfer costs), while data at rest remains fully under your control in your storage bucket. Because Foxglove indexes recordings in-place and you no longer need to make expensive copies of data, BYOS is a natural fit to pair with our new [Data Search & Curation](/blog/data-search-curation) features. You can now index petabytes of data, search and query recordings, review results, and annotate events in Foxglove, all without changing the underlying storage format or directory structure. BYOS is a great fit for: - Teams with existing cloud storage in MCAP or other supported formats. BYOS lets your data live in one place and be used by Foxglove and the rest of your stack. - Organizations with heightened security or compliance requirements around data at rest that want more control over where data lives. - Companies lacking the engineering bandwidth to deploy and manage Kubernetes clusters, configure autoscaling, and monitor additional services. ## Get started in minutes, not weeks Before today, if you wanted to deploy Foxglove in your own cloud account, you had to provision and manage a Kubernetes cluster, deploy Foxglove services, and take responsibility for autoscaling, upgrades, and maintenance operations. With BYOS, you can now onboard in minutes: 1. Open organization settings and create a new storage site 2. Enter your cloud provider, bucket name and region 3. Grant Foxglove access to the bucket and configure notifications That's it! Your storage is connected to Foxglove, and you can immediately start using platform features without deploying any additional infrastructure. Foxglove Add Site dialog with Bring your own storage selected for an AWS S3 bucket. ## Pricing BYOS is available on our Enterprise plan. Pricing is usage-based: you only pay for what you use, across indexing, query, and bandwidth. ## Get started Read the [BYOS documentation](https://docs.foxglove.dev/docs/data/primary-sites/foxglove-managed-setup) to learn more, or [contact sales](/contact?reason=sales) to get started. --- ### Data Search & Curation URL: https://foxglove.dev/blog/data-search-curation Date: 2026-04-21 Tags: product release, data management Search MCAP data at petabyte scale. Curate results as sessions, events, and the training datasets that feed your next model iteration. _This is the fourth announcement in a busy launch week at Foxglove, after [Basic Seats](/blog/basic-seats) and [Reduced self-service pricing](/blog/reduced-self-service-pricing) yesterday, and [Device property history](https://foxglove.dev/blog/track-device-property-changes-over-time-in-foxglove) today -- with more coming tomorrow!_ **Most Physical AI companies have no good way to search their data.** Finding every failed pick across last week's fleet usually means scrubbing MCAP files by hand or writing a one-off script. Companies that do have search typically ingest every recording into a separate data warehouse, which means maintaining a separate ingestion pipeline to keep the warehouse in sync with every new recording. Today we're changing that. **Foxglove Data Platform now lets you search and query MCAP data at petabyte scale**, with no warehouse to set up and no copies of the data to keep in sync. Paired with Sessions and Events, it turns Foxglove Data Platform into the best place to find and organize the episodes that feed your data flywheel. ## Data Search Data Search lets you search across: - **Messages:** Query specific fields in your message data (e.g. when acceleration exceeds a threshold) - **Events:** Search event properties and occurrences (e.g. events where a safety stop occurred) - **Devices:** Filter by current or historical device properties (e.g. recordings from when a device was running firmware v2.0) - **Recordings:** Search metadata attached to individual MCAP files (e.g. recordings tagged with a specific build) - **Sessions:** Search session properties (e.g. sessions on test track alpha) You can combine these filters to build more powerful queries. For example: Find all time ranges where acceleration is over 5 m/s² and the device name starts with "fox". Data Search queries MCAP files directly, whether they are hosted in Foxglove Cloud or [self-managed storage](https://docs.foxglove.dev/docs/data/primary-sites). No separate warehouse to stand up, no ingestion pipeline to build, and no second copy of the data to keep in sync. ## Curation Search is how you find things. Sessions and Events are how you turn results into curated training datasets for model iteration, test datasets for validation, or incidents to revisit -- the raw material of a Physical AI data flywheel. ### Sessions Data collection on robotics systems is messy by design. Devices split logs by file size, time intervals, or whatever makes sense for the hardware, and those boundaries rarely align with how engineers want to analyze data. Sessions let you group recordings into logical units. A session might be a single test run, a flight, or a complete drive, and once grouped you can query, filter, and download them as a whole instead of stitching together raw files. You can [read more about Sessions](/blog/announcing-sessions-in-foxglove) here. Foxglove session detail with the Recordings tab listing MCAP files grouped in a session. ### Events Robots don't fail on a schedule. When something important happens (a failed pick, a perception glitch, an operator intervention), you need a way to mark the time range and attach the context you'll want later when triaging issues or curating training data. Events are time-range annotations with typed properties you define. Event Types give those annotations structure. Define a type once with typed properties (strings, numbers, booleans, single-select, multi-select) and a color, and every event of that type looks the same regardless of who creates it. This enables workflows like: - **Debugging:** "Show every dropped item that followed a grasp retry" - **Regression tracking:** "Did e-stops spike after we changed planner parameters?" - **Dataset curation:** "Collect 200 examples of perception flicker in rain, labeled with severity" - **Field notes:** "Operator intervention because of unexpected obstacle, linked to ticket #1234" You can [read more about Event Types](/blog/event-types) here. Foxglove timeline showing colored spans across a recording for navigation and review. Search and curation are most valuable together. Query for every failed pick in your fleet last week, review the matches in the timeline, and annotate them all as "Pick failure" events with severity and tags in one pass. A pattern that used to take hours of manual scrubbing through recordings becomes one query and one batch annotation, and the resulting events are immediately available to the rest of your team. ## Getting started Data Search and the curation features are available today on Free, Pro, Academic, and Enterprise plans. Questions? Check out the [data search docs](https://docs.foxglove.dev/docs/data/search) or [reach out to our team](/contact) for help. --- ### Track device property changes over time in Foxglove URL: https://foxglove.dev/blog/track-device-property-changes-over-time-in-foxglove Date: 2026-04-21 Tags: product release Foxglove now records a full timeline for device properties--whether you update them in the UI or via the API--so teams can see when metadata changed and what it was before. Device properties in Foxglove are a simple way to attach metadata to a device. They're flexible key-value pairs that can represent booleans, text values, arrays, JSON, and more. Teams use them to capture important context such as environment, configuration, feature flags, and other operational details. Foxglove device property view Until now, properties were useful for showing a device's current state, but they didn't preserve how that state changed over time. Once a property was updated, the previous value was gone. That made it difficult to answer basic but important questions: When did a device move from staging to production? How long was a flag enabled? Which configuration was active during a specific test? With **Property history**, Foxglove now keeps a record of every change to device properties, whether the update happens in the **Properties** tab or through the API. ## See the full timeline for a property The new **Property history** view makes it easy to inspect how a property changes over time for a specific device. You can start with a recent window, such as the last seven days, and expand the time range when you need more context. The view is fully filterable and supports the same query syntax Foxglove users already know from sessions and devices. That means you can quickly narrow in on the property you care about and review its full history. Instead of only showing the latest value, Foxglove shows when a property entered a state and when it exited that state. In practice, that turns device metadata from a static label into a usable timeline. Property view history ## Correct or backfill property history when needed Property history is not just a passive record. It can also help teams maintain a complete and accurate record when updates need correction or backfilling. If a value was entered incorrectly, you can edit an existing record inline. If a state change was missed entirely, you can insert a new record to reflect what actually happened. This makes property history useful not only for ongoing device operations, but also for cleanup workflows and historical reconstruction. For teams managing fleets over long periods of time, that flexibility matters. Metadata is most valuable when it reflects reality, even if you need to refine it after the fact. ## Turn metadata into operational insight Historical property data makes device metadata significantly more useful. Teams can use it to understand when a device changed environments, reconstruct the operational state during an incident, or correlate recorded behavior with the property values active at that moment. A property like `env`, for example, becomes much more informative when you can see not only that a device is in production now, but exactly when it entered production and what state it was in beforehand. This also opens the door to richer configuration-tracking workflows. In robotics and autonomy systems, configuration changes can have a major impact on system behavior. Being able to track those changes over time--and connect them back to logs, recordings, or test results--can make debugging and validation much easier. ## From static metadata to a living timeline Device properties have always been a convenient way to attach important information to a device. With Property history, they become much more than a snapshot. Teams can now preserve the story of how device state changes over time, inspect that history when they need answers, and maintain it as part of their broader operational workflow. For anyone already using device properties to track environment, configuration, or runtime state, Property history adds the missing temporal context. That means less guesswork, better traceability, and a much clearer understanding of what changed, when it changed, and why it mattered. ## Resources - [Device properties documentation](https://docs.foxglove.dev/docs/data/devices#properties) - [Update property time interval API docs](https://docs.foxglove.dev/api#tag/Devices/paths/~1devices/post) Learn more about [devices](https://docs.foxglove.dev/docs/data/devices) in Foxglove, and join our [Discord](/chat) community or follow us on [X](https://x.com/foxglove) and [LinkedIn](https://www.linkedin.com/company/foxglovedev) to stay up to date on releases. --- ### Basic Seats URL: https://foxglove.dev/blog/basic-seats Date: 2026-04-20 Tags: product release Basic Seats let you share data visualization across your team without paying for full developer capabilities - ideal for field ops, executives, and contractors who need access without authoring. We're excited to announce a new Basic Seat type, allowing you to share visualization links across your team without worrying about incremental seat costs. Whether you're bringing executives, field ops, or contractors into your Foxglove workspace, Basic Seats let you extend access to your data and encourage collaboration across your team. All Foxglove paid plans now include unlimited Basic Seats at no additional cost! ## What are Basic Seats? Until now, every user in Foxglove had the same level of access to all features. Today, by popular demand, we're expanding to a two-tier system: ### Developer Seat Developer Seats are the status quo. They include: - Full access to all product capabilities - Access to all visualization data sources, including local files and WebSocket data sources - Ability to create and edit visualization layouts ### Basic Seat (free!) - Access to all Data Platform features - Able to visualize cloud data stored or indexed by Foxglove - Able to connect live to robots via [Remote Access](https://docs.foxglove.dev/docs/fleet/remote-access) - Read-only access to visualization layouts - No access to visualize local files or WebSocket data sources - No ability to create or edit layouts The key difference? Users with a Basic Seat can visualize cloud data and connect live to robots via Remote Access, but they cannot create or modify layouts or visualize local and WebSocket data sources. This makes them perfect for occasional users inspecting a link shared among team members. Importantly, seat types are independent from user roles, so users with a Basic Seat can also be an organization admin. This means you can now invite Lucy from finance to manage your Foxglove subscription, without being charged extra. ## Who benefits from Basic Seats? Anyone who needs access to robotics data on your team, but doesn't need full authoring or visualization editing. Some of these roles might include: - **Operations and triage teams** can view and create events against pre-built layouts as part of daily workflows - **Field and test teams** inspecting data from deployments, test runs, or customer sites without needing to customize layouts - **Leaders and cross-functional stakeholders** who click into a shared link to review a specific event or customer issue, without needing a seat they'll use twice a month - **Contractors and external partners** who need temporary access to your data but don't need to build custom visualizations ## Pricing & administration Basic Seats are available on all paid plans at no additional cost. Admins can manage seat types for their team members directly in settings, just like managing roles today. Users with a Basic Seat are able to request an upgrade to a Developer Seat if they need more capabilities, and admins will receive a notification to approve or deny the request. ## Getting started Basic Seats are available now. To assign Basic Seats to your team members, head to your [Member Settings](https://app.foxglove.dev/~/settings/members) page and adjust seat types as needed. Have questions? Check out the [seat type docs](https://docs.foxglove.dev/docs/security/seat-types) or [reach out to our team](https://foxglove.dev/contact) - we'd love to help! --- ### We're reducing self-service prices for Foxglove URL: https://foxglove.dev/blog/reduced-self-service-pricing Date: 2026-04-20 Tags: product release Self-service pricing now starts lower, with Pro at $20/month for 1 TB storage and 3 Developer Seats, unlimited Basic Seats on paid plans, and new volume discount tiers as usage grows. We're lowering self-service prices for Foxglove to make it easier for robotics teams to get started and scale. Pro now starts at a **lower price**, includes **more users**, and we've introduced **volume-based discounts** so data pricing decreases as usage grows. All paid plans now also include unlimited [Basic Seats](/blog/basic-seats) at no additional cost, so teams can share access more broadly across engineering, operations, and leadership. ## What's changing - **A new name:** Our Team plan has been renamed to Pro, to reflect the fact that it's useful to both individuals and organizations. - **Lower entry price:** Pro now starts at **$20/month** and includes **1 TB** storage plus **3 Developer Seats** (previously $126/month for 3 seats, over $100/month savings!). - **Free Basic Seats:** Bring in more teammates without paying for every user. - **Simpler options:** We've deprecated our Starter plan, which was capped at 10 users and 100 GB storage. All customers now benefit from a low base price and usage-based pricing. - **Decoupled meters:** Storage, query, indexing, and bandwidth are now priced independently, so you only pay for what you actually use in each category. - **Volume-based discounts:** As your usage grows on each meter, your per-unit rate for that meter automatically drops. ## Who this helps - **Individuals or small teams getting started:** Upgrade from Free to Pro for just **$20/month** - **Fast-growing organizations:** Easily add seats and data usage, with volume-based discounts kicking in as you scale - **Cross-functional teams:** Share access with occasional users through Basic Seats while keeping Developer Seats for users who author and edit layouts ## What this means for existing customers For existing customers on the Pro (formerly Team) plan, you will see the new prices reflected in your next full billing cycle. With the new pricing meters and volume-based discounts, we think nearly all Pro plan customers will see a lower bill. If you'd like to preview what your pricing looks like under the new plan, check out our [cost calculator](/pricing#cost-calculator), and if you have any questions please [drop us a line](/contact?reason=sales)! Existing Starter plan customers may remain on their existing plan and will not be automatically migrated, but will not benefit from the new volume-based discounts until they upgrade to the new Pro plan. We recommend [comparing prices](/pricing) to see if the new Pro plan will save you money. ## Getting started Our updated pricing is available to new customers immediately, and will be rolled out to existing customers after your next billing cycle. If your team has been considering Foxglove, we now provide a lower-cost entry point, with room to grow to petabyte-scale. Have questions? Check out our [pricing page](/pricing), read the [pricing docs](https://docs.foxglove.dev/docs/pricing), or [contact sales](/contact?reason=sales) and we'd be happy to help! --- ### Extension: Bringing photorealistic 3D maps to Foxglove for outdoor robot navigation URL: https://foxglove.dev/blog/photorealistic-3d-maps-for-outdoor-navigation Date: 2026-04-06 Tags: community, ROS Jion Kubo shares a Foxglove extension that renders photorealistic 3D tiles, fuses ROS 2 robot data in a local ENU frame, and publishes goals and clicked points without leaving the 3D view. When working with large outdoor robots, I often needed two different views of the same system. One was the robot's internal world: TF, URDF, odometry, paths, and navigation topics. The other was the real world: geographic position, terrain, roads, buildings, and the wider environment around the robot. Existing tools covered parts of this workflow well, but I wanted both perspectives in one place. RViz was useful for robot-centered data, and Mapviz was great for GPS-based visualization, but I kept constantly switching between different views depending on the task. What I wanted was a single tool that could show the robot in a real-world 3D environment while keeping the ROS 2 data and navigation workflow connected. To solve this, I built a [Foxglove extension](https://github.com/kubojion/foxglove-3d-tiles) that renders photorealistic 3D tiles, overlays ROS 2 robot data, and allows interactive waypoint placement directly in the scene. The result is a much more practical way to monitor and plan navigation tasks in outdoor environments. Live TF frames and navigation paths overlaid on 3D tiles. _Live TF frames and navigation paths overlaid on 3D tiles._ ## Why Foxglove? I wanted to extend my existing workflow rather than build another standalone tool. Foxglove already provides a strong ecosystem for robotics debugging, making it the perfect platform to build a specialized tool for outdoor navigation. By building this as a custom panel, map interaction, robot visualization, and topic monitoring can all occur side by side. The goal wasn't just to visualize the robot in the real world, but to actively interact with it by placing waypoints, defining headings, and publishing goals without ever leaving the workspace. ## Core capabilities: fusing the robot with the real world The extension is built around three main ideas. First, it uses Google Photorealistic 3D Tiles or local 3D tilesets as the scene foundation, giving the robot a realistic outdoor environment instead of a flat or abstract map. Second, it overlays ROS 2 data, such as URDF, TF, GPS, odometry, paths, markers, and costmaps, directly into that same world. Third, it supports interactive waypoint publishing, allowing users to define navigation goals and headings without leaving the 3D environment. Behind the scenes, the extension also has to connect local robot frames, such as `map`, `odom`, and `base_link`, with global geographic coordinates. This is handled through a local ENU anchor, which keeps the robot overlays stable while the globe remains positioned in global space. Diagram of global WGS84 coordinates transformed into a stable local ENU frame for rendering and interaction. _From global WGS84 coordinates to a stable local ENU frame used for rendering and interaction._ ## Solving the jitter problem Once I had the 3D tiles rendering and the robot overlaid on top of them, I ran into a very annoying problem: the robot model and ROS trajectories were visibly jittering. Instead of moving smoothly through the scene, the model seemed to shake and snap every time the robot moved. It looked like a small rendering issue at first, but it took me a while to figure out what was actually causing it. The root of the problem was the coordinate scale. In a global 3D environment, positions are often represented in Earth-Centered, Earth-Fixed (ECEF) coordinates, where values are on the order of millions of meters because they are measured relative to the centre of the Earth. That is fine for placing a globe, but it becomes a problem when you also want to render a robot moving by just a few centimetres or meters. WebGL rendering uses 32-bit floating-point values, which provide limited precision for very large numbers. At the Earth scale, there is insufficient precision to reliably represent small robot movements. Those small changes get quantized, making the rendered geometry appear to jitter rather than move smoothly. To solve this, I built a GlobeTransformer that pins a local GPS anchor and defines a local ENU (East-North-Up) frame around it. The globe itself stays at its real ECEF position, but the ROS data is transformed into small local coordinates relative to that anchor. In the scene, this is handled through a parent `localOriginGroup` positioned at the anchor and rotated into the ENU frame. This means the robot model, TF data, paths, and other overlays are rendered using small local values instead of huge global ones. The result is a much more stable visualization and properly aligned overlays, even though the underlying map is still globe-scale. Comparison illustrating Float32 precision loss at Earth scale versus stable rendering with a local origin. _Rendering directly at Earth scale causes Float32 precision loss; anchoring the scene to a local origin keeps robot motion and overlays stable._ ## Interactive waypoints: publishing goals from the scene One of the main reasons I built this extension was that I did not want it to stop at visualization. I wanted to interact with the scene and turn that interaction into actual ROS messages for use in a navigation workflow. The panel supports two publishing modes. The first is a PoseStamped mode, intended for topics such as `/goal_pose`, where the result is a full 2D navigation target in the map frame. The second is a PointStamped mode, intended for `/clicked_point`, where the result is published in the WGS84 frame using longitude, latitude, and altitude. The interaction starts with a mouse click in the scene, but internally, the click is not projected onto the raw photorealistic tile geometry. Instead, it is raycast onto a local planning plane aligned with the extension's local coordinate frame. In practice, this functions like an interactive grid within the robot's working area. That local point then becomes the source for publishing. For `/goal_pose`, the local point is used directly as a navigation target in the map frame. The published message is a `geometry_msgs/msg/PoseStamped` with the selected x and y position, while orientation is generated from the chosen heading and converted into a quaternion. This makes the behaviour similar to a 2D navigation goal workflow, but inside a geospatial 3D scene. For `/clicked_point`, the same local point is converted back into geographic coordinates relative to the anchored local frame. The extension converts back to GPS coordinates using the local ENU anchor offset, then publishes the result as a `geometry_msgs/msg/PointStamped` in the WGS84 frame. In that mode, the point is not just a visual marker. It becomes a real geographic output that other ROS tools can consume. Heading selection is also part of the interaction. After placing a point, the user can drag to define direction, and that heading is then used when publishing `/goal_pose`. If the user only clicks without dragging, the extension either falls back to a default heading or, when possible, automatically infers a direction from the previous waypoint. This matters because in real outdoor navigation workflows, the robot's final orientation is often just as critical as the target location itself. Interactive waypoint placement in the 3D scene with publishing options for clicked point and goal pose. _Interactive waypoint placement in the 3D scene, with support for publishing both `/clicked_point` and `/goal_pose`._ ## What works, and what still needs work In practice, the core workflow of planning goals and monitoring navigation in a real-world 3D context is already useful. However, as an evolving project, there is still room to improve. Support for local custom tilesets is functional but requires further refinement. Going forward, I want to improve the custom tile pipeline and add native support for richer overlays like LiDAR point clouds--a feature I am currently exploring as part of a university project. The main goal is to continue making the panel more robust for a wider range of outdoor robotics workflows. ## About the author [Jion Kubo](https://www.linkedin.com/in/jionkubo/) is a robotics developer currently interning at the Łukasiewicz - Poznań Institute of Technology while completing his degree in Automatic Control and Robotics at Poznan University of Technology. With a background spanning embedded engineering and control systems, he spends most of his time developing within the ROS 2 navigation stack. His other technical interests include SLAM and autonomous navigation. ## Resources - [foxglove-3d-tiles on GitHub](https://github.com/kubojion/foxglove-3d-tiles) - [Extensions Documentation](https://docs.foxglove.dev/docs/extensions) - [create-foxglove-extension Package](https://github.com/foxglove/create-foxglove-extension/) --- ### Connect Foxglove to your local player with PlaybackControl URL: https://foxglove.dev/blog/connect-foxglove-to-your-local-player-with-playback-control Date: 2026-04-01 Tags: article Keep your existing data format, control playback from the Foxglove UI, and replay the same run again and again. If your team already has a local executable that can load and seek through recorded data, Foxglove's `PlaybackControl` capability lets you connect to it and control it right from the Foxglove UI. `PlaybackControl` lets Foxglove's UI control playback when your application streams data from a fixed time range over WebSocket. When you take an action in Foxglove, like playing or pausing, seeking on the playback bar, or changing the playback speed, Foxglove can send it to your application. It keeps ownership of the actual playback: it loads the data, handles requests, advances time, and returns updated playback state so Foxglove stays in sync. ## Keep your player, keep your format For robotics developers, you do not need to replace an existing loader or convert every workflow into a new format first before enjoying all the benefits of Foxglove's world-class visualization capabilities. If you already have playback infrastructure for protobuf logs, ROS bags, or your own internal format, `PlaybackControl` lets Foxglove become the frontend for that workflow instead of forcing a rewrite. The result is a much shorter path from "we have data" to "we can inspect it, seek through it, and compare runs." Under the hood, the integration is straightforward. To support `PlaybackControl`, your server needs to advertise the start and end of the data, register a listener that handles playback control requests from Foxglove, broadcast the current playback time as messages are replayed, and send updated playback state whenever something changes. To learn more about PlaybackControl, check out our [documentation](https://docs.foxglove.dev/docs/sdk/websocket-server#playback-control). We also have examples in [Rust](https://github.com/foxglove/foxglove-sdk/tree/main/rust/examples/ws_stream_mcap/src), [Python](https://github.com/foxglove/foxglove-sdk/tree/main/python/foxglove-sdk-examples/ws-playback-control-mcap), and [C++](https://github.com/foxglove/foxglove-sdk/tree/main/cpp/examples/ws-stream-mcap/src) that you can pattern-match to when integrating this capability into your own player. ## An open-source example from Dexory A good example of this pattern in practice is Dexory's [foxglove_mcap_player](https://github.com/botsandus/foxglove_mcap_player). The repository contains a ROS 2 node that plays back MCAP files with dual output: publishing both to Foxglove and enabling its playback controls, and republishing recorded data back to the robotics stack using ROS 2. It reads the MCAP summary, creates Foxglove channels, republishes CDR-encoded messages, plays messages back in log-time order, and broadcasts current playback time to Foxglove. Dexory implementation of PlaybackControl in foxglove_mcap_player _Dexory implementation of PlaybackControl in [foxglove_mcap_player](https://github.com/botsandus/foxglove_mcap_player). Source: Dexory_ Even if your own system is not MCAP-based, the Dexory example is useful because it shows the shape of a real integration: keep a dedicated player process, expose playback over WebSocket, and use Foxglove as the control and visualization surface. Resources: 1. [Foxglove-SDK Playback Control Documentation](https://docs.foxglove.dev/docs/sdk/websocket-server#playback-control) 2. [Dexory's Foxglove ROS MCAP Player](https://github.com/botsandus/foxglove_mcap_player) ## Getting Started Download the latest [Foxglove desktop app](/download) and connect to your local player over WebSocket to try PlaybackControl today. Check out the [documentation](https://docs.foxglove.dev/docs/sdk/websocket-server#playback-control) and SDK examples in [Rust](https://github.com/foxglove/foxglove-sdk/tree/main/rust/examples/ws_stream_mcap/src), [Python](https://github.com/foxglove/foxglove-sdk/tree/main/python/foxglove-sdk-examples/ws-playback-control-mcap), and [C++](https://github.com/foxglove/foxglove-sdk/tree/main/cpp/examples/ws-stream-mcap/src) to get up and running. Join our [Discord](/chat) community or follow us on [X](https://x.com/foxglove) and [LinkedIn](https://www.linkedin.com/company/foxglovedev) to stay up to date on all Foxglove releases. --- ### GrandTour: Taking Legged Robotics Into the Wild URL: https://foxglove.dev/blog/grandtour-taking-legged-robotics-into-the-wild Date: 2026-03-26 Tags: community, ROS Introducing GrandTour: a large-scale, open-access legged-robotics dataset spanning 49 missions across diverse conditions to accelerate the development and benchmarking of autonomy algorithms. Legged robots are redefining the boundaries of robotic mobility. Today, these systems can navigate environments that were previously off-limits, from the rubble of **demolished buildings** and dense **forests** to the depths of **unexplored caves**. To push these capabilities even further, we are introducing [**_GrandTour_**](https://grand-tour.leggedrobotics.com/)_: a large-scale, open-access legged-robotics dataset_. Our goal is to provide a comprehensive suite of multi-modal sensor data to accelerate the development and benchmarking of autonomy algorithms. By providing high-quality data, we aim to guide the development of entirely new applications for legged systems in the field. _ANYmal with Boxi payload traversing forest path. Source: Robotic Systems Lab, ETH Zurich_ The dataset spans more than 49 missions across indoor, urban, industrial, and natural environments, including day and night operations and challenging weather and visibility conditions. Beyond the data itself, GrandTour aims to make real-world, out-of-distribution robotic data more accessible to the machine learning, computer vision, and robotics communities alike. In addition to serving as a dataset release, GrandTour also serves as a benchmark for evaluating localization and perception methods in realistic field conditions. Its broader goal is to support the development of more robust multimodal systems that can operate reliably outside controlled laboratory settings. As part of its mission, GrandTour will continue to expand, incorporating additional environments with different robots. ## Sensor Stack GrandTour platform components _GrandTour platform components_ GrandTour is built around a deliberately diverse and redundant sensor suite. Rather than depending on a single sensing modality, the platform combines complementary sensors for geometry, vision, inertial estimation, proprioception, and global referencing. These sensors span across our integrated sensor suite, Boxi, and the ANYbotics ANYmal-D quadruped base platform. For LiDAR sensing, the platform includes a Livox Mid-360 for near-field 3D structure, a Hesai XT-32 for longer-range perception, and a Velodyne VLP-16 on ANYmal. This combination gives strong geometric coverage across both local and more distant structures. For vision, Boxi integrates five Sevensense CoreResearch global-shutter cameras, three Tier IV C1 HDR rolling-shutter cameras, and a ZED2i stereo camera. ANYmal contributes six Intel RealSense D435i depth cameras. Together, these provide overlapping coverage across monocular, stereo, HDR, and depth-based perception. For inertial sensing, the platform includes multiple IMUs with different performance characteristics, ranging from lower-cost MEMS devices to a higher-grade Honeywell HG4930. ANYmal also contributes its own onboard IMU. This makes the platform useful not only for state estimation, but also for studying the effect of IMU quality on downstream localization performance. For global reference and ground truth, the system uses a dual-antenna NovAtel CPT7 RTK-GNSS setup together with a Leica total-station-based positioning pipeline. These measurements are combined to generate accurate 6-DoF ground-truth trajectories, even in challenging outdoor environments where pure satellite-based positioning or pure local sensing would be insufficient on their own. In addition to exteroceptive and inertial sensing, the dataset includes joint encoders, commanded motion, contact-related robot-state information, motion-compensated LiDAR point clouds, and post-processed INS trajectories. This makes the dataset particularly interesting for researchers working on SLAM, legged state estimation, multi-modal fusion, perception-aware locomotion, and navigation. ## Lessons Learned A fundamental learning is that the design and development of a multimodal payload requires joint optimization of hardware and software. This became apparent to us when we realized that our Ethernet switch is a non-PTP switch, implying that microsecond-level line delays might occur. While this wasn't a blocker for the project, it is important to note that similar considerations must be taken from a sensor's claimed functionality to whether an IMU has a C-level driver available. GrandTour also showed that there is no universally best sensing modality. In practice, LiDAR- and GNSS-based estimation were generally more reliable than camera-only or kinematics-based approaches, but performance still depended strongly on the environment. Open spaces, weak visual texture, smoke, changing lighting, and GNSS-denied areas all changed which modalities were most useful. Another important lesson is that seemingly small hardware substitutions matter. Replacing a higher-quality long-range LiDAR with a lighter, cheaper alternative reduced performance, especially in more challenging scenes. The same held for cameras: global-shutter configurations proved more reliable for visual localization than rolling-shutter configurations. These trade-offs clearly translate into estimator performance, not just into hardware specifications. GrandTour also reinforced that IMU quality matters most when external correction becomes weak or unavailable. In tightly coupled LiDAR-inertial pipelines, higher-grade IMUs did not always produce large gains during normal operation, but they were clearly more robust during dead reckoning and measurement dropouts. A particularly important lesson was that the validation of the claimed synchronization, calibration, and ground truthing accuracy must be impeccable. Many public datasets underestimate this single point in the name of completing their projects and end up with overpromised claims. Hence, why GrandTour took 2 years to realize. Finally, GrandTour showed that robust robotics performance comes from disciplined full-system integration. Good results depend not only on the individual sensors, but on how sensing, compute, networking, timing, and mechanics are designed together. The strongest takeaway is simple: reliable field performance is built at the system level, not added afterward. ## Architecture GrandTour Architecture diagram _GrandTour Architecture_ The GrandTour platform can be separated into two tightly coupled parts: our custom multi-modal sensory payload, Boxi, and an ANYbotics ANYmal quadruped robot as the carrier platform. Boxi is a compact, mechanically rigid payload designed to carry a diverse sensor suite while maintaining calibration consistency and reliable data capture in the field. Boxi contains three compute modules: an NVIDIA Jetson AGX Orin, an Intel NUC, and a Raspberry Pi Compute Module 4. Each module is responsible for a subset of the sensor suite. This division is important because camera pipelines benefit from stronger onboard compute, while IMUs and LiDARs can run efficiently on CPU-based systems. At the core of the system is the UbiSwitch Module 3 Ethernet switch, which enables TCP/IP communication between sensors and compute modules. In practice, this means we avoid unnecessary cross-device communication during recording and focus instead on accurate time synchronization, adequate system integration, and utilities for resilient data recording. In addition to the main compute modules, Boxi also includes a custom Leica Geosystems AP20 and a NovAtel CPT7 INS/GNSS unit, which form the foundation of our ground-truth generation pipeline. These are industrial solutions that help GrandTour achieve adequately synchronized, accurate ground-truth positioning. A particularly important aspect of the architecture is timing and synchronization. CPT7 is the time grandmaster, provides GNSS time if available, otherwise a local-time approximation. Jetson within Boxi IEEE 1588v2 PTP synchronizes to it; the other modules, NUC and Raspberry Pi, synchronize to the Jetson again through the PTP. On the other hand, the main compute module of ANYmal synchronizes with the Jetson on Boxi via the NTP protocol. During deployment, each compute module, including those on ANYmal, records locally to avoid unnecessary network traffic and reduce the risk of data loss. This design choice improves robustness during long and demanding field missions. ### Recording Structure One of the major design questions we had to answer early on was: _how would we handle all this data, both during recording and in post-processing?_ This led us toward a divide-and-conquer strategy. We chose to split the recorded data primarily by sensor stream and, in our internal workflow, also by time. Using time as an additional division parameter makes the number of file divisions more consistent across sensors, helping operators quickly identify anomalies without having to compare file sizes across different data types and rates. We are very happy with this decision. The biggest advantage is modularity. It allows us to inspect, validate, and process sensor streams independently, making it easier to write dedicated post-processing tools for each sensor or modality. This also aligns well with the public dataset philosophy, where users can access the specific streams they need rather than being forced to handle very large, monolithic recordings. Considering the suite can generate more than 1 GB/s of data, these points become even more important. The main downside is a small amount of post-processing overhead. Split recordings often need to be merged, synchronized, or jointly indexed before downstream processing. However, in practice, we found that this overhead is outweighed by the gains in robustness, interpretability, and processing flexibility. ## GrandTour as a Foxglove Example Dataset With the release of this blog post, a section of a single GrandTour recording is [available](https://app.foxglove.dev/~/view?ds=foxglove-sample-stream&ds.recordingId=rec_0eH5fXzqXchvDEhB&ds.overrideLayoutId=lay_0eH5iIe1XHn7QFa7) early to anyone with a Foxglove account. You will always find it in the [example datasets](https://foxglove.dev/examples). GrandTour dataset visualized in Foxglove _GrandTour dataset visualized in Foxglove_ ## Future outlook of GrandTour We have already collected an additional 15 sequences across 3 countries as part of our extension efforts. Including some new sequences with the Radar modality. GrandTour is a multi-year project in which, with different collaborators, we are expanding our outreach and demonstrating that legged-robotic data is vital for training fine-tuned spatial AI models. We are also improving our SW/HW stack, particularly the sensor suite and the post-processing software. We are eager to hear from any collaborators with interesting environments and funding opportunities where we can join them to collect further data. ## About the Authors [**Turcan Tuna**](https://www.linkedin.com/in/turcantuna/) is a Ph.D. candidate at ETH Zurich's Robotic Systems Lab, where he works on robust spatial 3D perception and state estimation for robot autonomy in challenging real-world environments. His research focuses on robust localization and spatial 3D perception in perceptually degraded environments using optimization and data-driven methods. Website: [https://www.turcantuna.com/](https://www.turcantuna.com/) [**Jonas Frey**](https://www.linkedin.com/in/jonasfrey96/) is a Postdoctoral Researcher at Stanford's Autonomous Systems Lab, where he works with Prof. Marco Pavone, and at UC Berkeley's Berkeley Artificial Intelligence Research (BAIR), where he works with Prof. Jitendra Malik. His research focuses on learning-based perception and navigation for legged robots, with particular emphasis on reinforcement learning policies and Large Behaviour Models. Website: [https://jonasfrey96.github.io/](https://jonasfrey96.github.io/) ## Citation and Sources Please cite the following works if you use this dataset. **Journal Publication pre-print (Under-review for Sage IJRR) (arXiv)** GrandTour: A Legged Robotics Dataset in the Wild for Multi-Modal Perception and State Estimation [https://arxiv.org/abs/2602.18164](https://arxiv.org/abs/2602.18164) Turcan Tuna\* and Jonas Frey\* (\*equal contribution), Frank Fu, Katharine Patterson, Tianao Xu, Cesar Cadena, Maurice Fallon, and Marco Hutter **Payload Publication (RSS)** Boxi: Design Decisions in the Context of Algorithmic Performance for Robotics [https://www.roboticsproceedings.org/rss21/p134.html](https://www.roboticsproceedings.org/rss21/p134.html) Jonas Frey\*, Turcan Tuna\*, Lanke Frank Tarimo Fu\* (\*equal contribution), Cedric Weibel, Katharine Patterson, Benjamin Krummenacher, Matthias Müller, Julian Nubert, Maurice Fallon, Cesar Cadena, Marco Hutter --- ### Actuate 26: The Developer Conference for People Who Build Robots URL: https://foxglove.dev/blog/announcing-actuate-2026 Date: 2026-03-24 Tags: actuate This August, more than 1,000 robotics developers will gather in San Francisco for Actuate 26, our annual conference for the engineers and technical leaders building the next generation of AI for the physical world. Actuate is back. This August, more than 1,000 robotics developers will gather in San Francisco for Actuate 26, our annual conference for the engineers and technical leaders building the next generation of AI for the physical world. Physical AI is no longer a research horizon. Models that understand the real world, reason, and act in it are shipping today in autonomous vehicles, humanoids, drones, and industrial machines. Actuate is where the engineers actually building these systems come to accelerate their progress. We created Actuate to give developers and technical leaders a stage for the real work behind building and scaling robots: the engineering challenges, difficult tradeoffs, and hard-won lessons that only come from deploying autonomous systems in the real world. Over the past two years, that mission has clearly resonated, with sold-out conferences since we launched in 2024. > **"This is probably the highest value robotics conference in the world right now for people who actually want to build robots."** -- Chris Paxton, Agility Robotics ## **What to Expect for 2026** This year's conference is our biggest yet. Featured speakers include: - **Alex Kendall**, Co-Founder & CEO, Wayve - **Jason Ma**, Co-Founder & CEO, Dyna Robotics - **Cheng Chi**, Co-Founder & CTO, Sunday - **Keenan Wyrobek**, Co-Founder & CTO, Zipline - **Grace Brown**, Founder & CEO, Andromeda - **Nathan Michael**, CTO & Head of Hivemind, Shield AI - **Engin Anil**, VP of Software & AI, Cobot - **Goutham Subramanian**, VP of Software, Saronic - **Fred Parietti**, Co-Founder & CEO, Multiply Labs - **Abhinav Das**, Co-Founder & CEO, Orangewood Labs More speakers will be announced over the coming months. ## **Join us** If you want to shape the technical direction of this industry, [apply to speak](https://docs.google.com/forms/d/e/1FAIpQLScxSDV47MIWpoklj_KW2AvQKClbIm1Zj9EgTW5poDIEETJ1vw/viewform). We're looking for talks on autonomy, AI, infrastructure, controls, simulation, and production systems, with an emphasis on real lessons from real deployments. Actuate 26 takes place August 18-19 at Fort Mason in San Francisco. Early bird tickets are on sale now, with discounted pricing available until May 31. [Register today](https://actuate.foxglove.dev). We look forward to seeing you there. --- ### Announcing Sessions in Foxglove URL: https://foxglove.dev/blog/announcing-sessions-in-foxglove Date: 2026-03-11 Tags: product release Sessions are a new way to organize and analyze device data in Foxglove that maps directly to how robotics developers view and analyze data. Data collection on robotics and autonomous systems is often messy by design. Your devices split logs by file size, by time intervals, or by whatever makes sense for your hardware, but those technical boundaries rarely align with how engineers review and interact with their data. Today, we're releasing Sessions, a new way to organize and analyze device data in Foxglove that maps directly to how robotics developers view and analyze data. ## The Problem: Technical Splits, Not Logical Ones When you collect data from a device, or any robot running continuous operations, data gets split into multiple files for technical reasons. A self-driving car might rotate logs every gigabyte. A warehouse robot might write a new file every minute. A test platform might split recordings by hour. These splits make sense for your system architecture (i.e. they keep file sizes manageable, align with your infrastructure, etc...), but when you come back to analyze that data, you don't think in terms of individual files. You think in terms of meaningful operations: "This was test run #5" or "This was the experiment we ran yesterday" or "This was the stack launch from 2 PM to 4 PM." Traditionally, developers stitch together multiple recordings to get a complete picture. And if you wanted to compare two test runs side-by-side or feed data into a machine learning pipeline, you'd have to manually select all the relevant recordings every single time. ## Sessions: Logical Grouping for Your Workflow Sessions solve this by letting you define what "meaningful" means for your application. A session is a logical grouping of recordings from the same device that represents a continuous period of operation. For teams running repeated tests, a session maps to a single test run. For a drone, a session might represent a single flight or stack launch. For an autonomous car company, it could be a complete drive or mission. You decide what makes sense for your use case. Sessions detail interface in Foxglove ## Key Benefits ### Complete Data Views Without Manual Work Instead of hunting through individual recordings, developers get a continuous view of all data from a session. No more jumping between files or wondering if you've grabbed all of the relevant data. ### Seamless Integration with Your Workflows Sessions work across Foxglove's entire platform. - Query recordings by sessions via the Foxglove API - Download session data programmatically for ML pipelines - Filter and organize sessions in the UI by device, time, and metadata - Automatically associate recordings with sessions during upload ### Flexible, Real-World Mapping Sessions don't enforce rigid structure. Whether your session is 30 seconds or 4 days, Sessions adapt to how you actually operate. Upload critical recordings immediately while in the field, and finish the upload to the session at a later time when you have reliable connectivity. ### Full ingestion workflow support Tag sessions seamlessly whether you upload via API, web app, or cloud bucket. ## How It Works Creating a session is straightforward: - **Select a device**: Sessions are tied to a specific device (robot, vehicle, etc.) - **Define your metadata**: Add a key that maps to your internal identifiers so you link from internal systems. - **Add recordings**: Assign recordings to the session, automatically during upload or manually after the fact. - **Visualize and analyze**: Visualize all session data as one continuous dataset, download it, or query it via API You can also create empty sessions in advance and let recordings populate them automatically as data uploads. This is perfect for continuous operations where data arrives over time. Find more information in the [docs](https://docs.foxglove.dev/docs/data/sessions) and learn more about [importing data](https://docs.foxglove.dev/docs/data/primary-sites/manage-data#adding-metadata-to-imports) into Foxglove. ## Getting Started Sessions are available now in Foxglove on Free, Pro, Academic, and Enterprise plans. Create your first session and start organizing your device data the way that makes sense for your team. Download the latest Foxglove desktop app to try Sessions today. They're available for Linux, Windows, and macOS. Join our [Discord](/chat) community or follow us on [X](https://x.com/foxglove) and [LinkedIn](https://www.linkedin.com/company/foxglovedev) to stay up to date on all Foxglove releases. --- ### Depth Image Rendering: PNG Support and RGB Colorization URL: https://foxglove.dev/blog/depth-image-rendering-png-support-and-rgb-colorization Date: 2026-03-11 Tags: product release Foxglove now supports PNG compressed depth images as 3D point clouds, RGB colorization from sibling images, and custom color modes for depth encodings in the Image panel. ## The problem If your robot has a depth camera, you've probably wanted to see its output as a 3D point cloud in Foxglove. Since [v2.41.0](https://docs.foxglove.dev/changelog/foxglove/v2.41.0), the 3D panel has supported rendering uncompressed depth images as point clouds, but not all teams publish raw, uncompressed depth images. Uncompressed 16-bit depth frames are large, and streaming them at high frequency can flood your data pipeline with unnecessary bandwidth -- especially when the data is only needed for visualization, not for the robot's real-time decision-making. Teams that compress their depth images as PNGs to save bandwidth previously couldn't visualize them as point clouds in Foxglove. That meant a tradeoff: compress your depth data and lose the ability to visualize it as a point cloud, or publish it uncompressed and stress your data bus. We're changing that in [v2.47.0](https://docs.foxglove.dev/changelog/foxglove/v2.47.0) by making depth visualization more flexible and bandwidth-friendly with PNG compression support, RGB colorization, and new color modes for depth images. ## What's new We've shipped three improvements that eliminate this tradeoff and make depth visualization significantly more useful. ### PNG compressed depth image support The 3D panel now accepts 16-bit grayscale PNG compressed depth images in addition to uncompressed formats. If you're publishing depth data using ROS `compressedDepth` transport (via `sensor_msgs/CompressedImage` with a `compressedDepth` format string), Foxglove will decode the PNG and render it as a point cloud the same way it already handles uncompressed `16UC1`, `32FC1`, and other raw encodings. Depth values in the PNG are interpreted as millimeters along the camera Z axis. No workflow changes needed on your side -- just point Foxglove at your existing compressed depth topic, set the render mode to **Depth map**, and you'll see a point cloud. ### RGB colorization from a sibling image A monochrome point cloud colored by depth value (like a near-to-far heat map) is useful, but it doesn't tell you _what_ you're looking at. You can now colorize depth map point clouds using a sibling RGB image to paint color from the RGB camera onto each 3D point based on its corresponding pixel. The result: instead of a depth-shaded blob, you get a point cloud that actually looks like the real scene in color. To set this up, expand the **Depth map** settings for your depth topic in the 3D panel and choose an **RGB topic** from the dropdown. All available image topics will appear as options. Select "None" to fall back to distance-based coloring. For the best results, the depth and RGB images should use the same camera frame, or have matching intrinsics with only a rigid transform between frames. The current implementation does not perform stereo rectification, so there may be subtle colorization artifacts when the sensors are offset with different intrinsics. Freiburg depth rendering example showing RGB colorized point cloud _Credit to University of Freiburg for this data!_ ### Image panel: custom color modes for depth encodings The Image panel now supports color maps, gradient controls, and min/max value scaling for `32FC1` and `8UC1` (mono8) depth images. Previously, these color options were only available for `mono16`/`16UC1`. **32FC1 images:** Previously, float images were mapped linearly from [0, 1] to grayscale with no range or color map control, so depth values outside that range appeared as solid white or black. Now you can set a custom value range and apply color maps like Turbo or Rainbow. Non-finite values (NaN, Inf) render as black instead of causing artifacts. **8UC1 / mono8 images:** Previously mapped directly to grayscale with no color options. Now supports the same color map, gradient, and min/max scaling controls as 16-bit depth images. This is useful when you want to inspect depth values directly in the Image panel in 2D. For example, verifying depth range and coverage before looking at the 3D point cloud, or when you're working with depth data that doesn't need a full 3D reconstruction. ## Why this matters Before these changes, getting a colored 3D reconstruction of depth camera data in Foxglove required one of two workarounds: 1. **Publish uncompressed depth images** -- works, but wastes bandwidth on your robot's data bus for the sake of visualization. 2. **Compute the point cloud yourself** in your robot's software pipeline -- works, but burns compute resources on the robot's hot path just so someone can look at the data in Foxglove. Now, you can publish your depth images as compressed PNGs (saving bandwidth), publish a standard RGB image alongside it, and let Foxglove handle the 3D reconstruction and colorization on the visualization side. No extra compute on your robot, no bandwidth penalty. ## How to use it 1. Publish a **16-bit grayscale PNG** depth image (e.g., via ROS `compressedDepth` transport) and a corresponding **camera calibration** message. 2. In the Foxglove 3D panel, enable the depth image topic and set **Render mode** to **Depth map**. 3. Optionally, publish a **sibling RGB image**. In the depth topic's settings, expand the **Depth map** section and set **RGB topic** to your RGB image topic for colorization, or select "None" to use distance-based coloring instead. 4. For 2D depth visualization, open the depth topic in an **Image panel**. For `32FC1`, `8UC1`/mono8, and `16UC1`/mono16 encodings, you can apply color maps (e.g., Turbo, Rainbow), adjust the value range with min/max scaling, and use gradient controls to highlight the depth ranges you care about. For full details, see the [3D panel documentation](https://docs.foxglove.dev/docs/visualization/panels/3d) and [Image panel documentation](https://docs.foxglove.dev/docs/visualization/panels/image). ---