update

app/scripts/latex-to-markdown/mdx-converter.mjs

@@ -62,33 +62,62 @@ Examples:
  */
 const usedComponents = new Set();
 
+/**
+ * Track individual image imports needed
+ */
+const imageImports = new Map(); // src -> varName
+
 /**
  * Add required component imports to the frontmatter
  * @param {string} content - MDX content
  * @returns {string} - Content with component imports
  */
+/**
+ * Generate a variable name from image path
+ * @param {string} src - Image source path
+ * @returns {string} - Valid variable name
+ */
+function generateImageVarName(src) {
+    // Extract filename without extension and make it a valid JS variable
+    const filename = src.split('/').pop().replace(/\.[^.]+$/, '');
+    return filename.replace(/[^a-zA-Z0-9]/g, '_').replace(/^[0-9]/, 'img_$&');
+}
+
 function addComponentImports(content) {
-    console.log('  📦 Adding component imports...');
+    console.log('  📦 Adding component and image imports...');
 
-    if (usedComponents.size === 0) {
-        console.log('    ℹ️  No components to import');
-        return content;
+    let imports = [];
+
+    // Add component imports
+    if (usedComponents.size > 0) {
+        const componentImports = Array.from(usedComponents)
+            .map(component => `import ${component} from '../components/${component}.astro';`);
+        imports.push(...componentImports);
+        console.log(`    ✅ Importing components: ${Array.from(usedComponents).join(', ')}`);
+    }
+
+    // Add image imports
+    if (imageImports.size > 0) {
+        const imageImportStatements = Array.from(imageImports.entries())
+            .map(([src, varName]) => `import ${varName} from '${src}';`);
+        imports.push(...imageImportStatements);
+        console.log(`    ✅ Importing ${imageImports.size} image(s)`);
     }
 
-    // Create import statements
-    const imports = Array.from(usedComponents)
-        .map(component => `import ${component} from '../components/${component}.astro';`)
-        .join('\n');
+    if (imports.length === 0) {
+        console.log('    ℹ️  No imports needed');
+        return content;
+    }
 
-    console.log(`    ✅ Importing: ${Array.from(usedComponents).join(', ')}`);
+    const importBlock = imports.join('\n');
 
     // Insert imports after frontmatter
     const frontmatterEnd = content.indexOf('---', 3) + 3;
     if (frontmatterEnd > 2) {
-        return content.slice(0, frontmatterEnd) + '\n\n' + imports + '\n' + content.slice(frontmatterEnd);
+        return content.slice(0, frontmatterEnd) + '\n\n' + importBlock + '\n' + content.slice(frontmatterEnd);
     } else {
         // No frontmatter, add at beginning
-        return imports + '\n\n' + content;
+        return importBlock + '\n\n' + content;
     }
 }
 
@@ -98,54 +127,150 @@ function addComponentImports(content) {
  * @param {string} content - MDX content
  * @returns {string} - Content with ResponsiveImage components
  */
+/**
+ * Create ResponsiveImage component with import
+ * @param {string} src - Clean image source
+ * @param {string} alt - Alt text  
+ * @param {string} id - Element ID
+ * @param {string} caption - Figure caption
+ * @param {string} width - Optional width
+ * @returns {string} - ResponsiveImage component markup
+ */
+function createResponsiveImageComponent(src, alt = '', id = '', caption = '', width = '') {
+    const varName = generateImageVarName(src);
+    imageImports.set(src, varName);
+    usedComponents.add('ResponsiveImage');
+
+    const props = [];
+    props.push(`src={${varName}}`);
+    props.push('zoomable');
+    props.push('downloadable');
+    if (id) props.push(`id="${id}"`);
+    props.push('layout="fixed"');
+    if (alt) props.push(`alt="${alt}"`);
+    if (caption) props.push(`caption={'${caption}'}`);
+
+    return `<ResponsiveImage\n  ${props.join('\n  ')}\n/>`;
+}
+
 function transformImages(content) {
-    console.log('  🖼️  Transforming images to ResponsiveImage components...');
+    console.log('  🖼️  Transforming images to ResponsiveImage components with imports...');
 
     let hasImages = false;
 
-    // Transform HTML figure/img to ResponsiveImage
+    // Helper function to clean source paths
+    const cleanSrcPath = (src) => {
+        return src.replace(/.*\/output\/assets\//, '../assets/')
+            .replace(/\/Users\/[^\/]+\/[^\/]+\/[^\/]+\/[^\/]+\/[^\/]+\/app\/scripts\/latex-to-markdown\/output\/assets\//, '../assets/');
+    };
+
+    // Helper to clean caption text
+    const cleanCaption = (caption) => {
+        return caption
+            .replace(/<[^>]*>/g, '')          // Remove HTML tags
+            .replace(/\n/g, ' ')              // Replace newlines with spaces
+            .replace(/\r/g, ' ')              // Replace carriage returns with spaces
+            .replace(/\s+/g, ' ')             // Replace multiple spaces with single space
+            .replace(/'/g, "\\'")             // Escape quotes
+            .trim();                          // Trim whitespace
+    };
+
+    // Helper to clean alt text
+    const cleanAltText = (alt, maxLength = 100) => {
+        const cleaned = alt
+            .replace(/<[^>]*>/g, '')          // Remove HTML tags
+            .replace(/\n/g, ' ')              // Replace newlines with spaces
+            .replace(/\r/g, ' ')              // Replace carriage returns with spaces
+            .replace(/\s+/g, ' ')             // Replace multiple spaces with single space
+            .trim();                          // Trim whitespace
+
+        return cleaned.length > maxLength
+            ? cleaned.substring(0, maxLength) + '...'
+            : cleaned;
+    };
+
+    // 1. Transform complex HTML figures with style attributes
+    content = content.replace(
+        /<figure id="([^"]*)">\s*<img src="([^"]*)"(?:\s+style="([^"]*)")?\s*\/>\s*<figcaption>\s*(.*?)\s*<\/figcaption>\s*<\/figure>/gs,
+        (match, id, src, style, caption) => {
+            const cleanSrc = cleanSrcPath(src);
+            const cleanCap = cleanCaption(caption);
+            const altText = cleanAltText(cleanCap);
+            hasImages = true;
+
+            return createResponsiveImageComponent(cleanSrc, altText, id, cleanCap);
+        }
+    );
+
+    // 2. Transform standalone img tags with style
+    content = content.replace(
+        /<img src="([^"]*)"(?:\s+style="([^"]*)")?\s*(?:alt="([^"]*)")?\s*\/>/g,
+        (match, src, style, alt) => {
+            const cleanSrc = cleanSrcPath(src);
+            const cleanAlt = cleanAltText(alt || 'Figure');
+            hasImages = true;
+
+            return createResponsiveImageComponent(cleanSrc, cleanAlt);
+        }
+    );
+
+    // 3. Transform images within wrapfigure divs
+    content = content.replace(
+        /<div class="wrapfigure">\s*r[\d.]+\s*<img src="([^"]*)"[^>]*\/>\s*<\/div>/gs,
+        (match, src) => {
+            const cleanSrc = cleanSrcPath(src);
+            hasImages = true;
+
+            return createResponsiveImageComponent(cleanSrc, 'Figure');
+        }
+    );
+
+    // 4. Transform simple HTML figure/img without style
     content = content.replace(
         /<figure id="([^"]*)">\s*<img src="([^"]*)" \/>\s*<figcaption>\s*(.*?)\s*<\/figcaption>\s*<\/figure>/gs,
         (match, id, src, caption) => {
-            // Clean up the source path for web
-            const cleanSrc = src.replace(/.*\/output\/assets\//, '/assets/');
+            const cleanSrc = cleanSrcPath(src);
+            const cleanCap = cleanCaption(caption);
+            const altText = cleanAltText(cleanCap);
+            hasImages = true;
+
+            return createResponsiveImageComponent(cleanSrc, altText, id, cleanCap);
+        }
+    );
+
+    // 5. Clean up figures with minipage divs
+    content = content.replace(
+        /<figure id="([^"]*)">\s*<div class="minipage">\s*<img src="([^"]*)"[^>]*\/>\s*<\/div>\s*<figcaption[^>]*>(.*?)<\/figcaption>\s*<\/figure>/gs,
+        (match, id, src, caption) => {
+            const cleanSrc = cleanSrcPath(src);
+            const cleanCap = cleanCaption(caption);
+            const altText = cleanAltText(cleanCap);
             hasImages = true;
-            usedComponents.add('ResponsiveImage');
 
-            return `<ResponsiveImage src="${cleanSrc}" alt="${caption.replace(/<[^>]*>/g, '')}" id="${id}" />`;
+            return createResponsiveImageComponent(cleanSrc, altText, id, cleanCap);
         }
     );
 
-    // Transform Pandoc-style images: ![alt](src){#id attr="value"}
+    // 6. Transform Pandoc-style images: ![alt](src){#id attr="value"}
     content = content.replace(
         /!\[([^\]]*)\]\(([^)]+)\)(?:\{([^}]+)\})?/g,
         (match, alt, src, attributes) => {
-            // Clean up the source path for web
-            const cleanSrc = src.replace(/.*\/output\/assets\//, '/assets/');
+            const cleanSrc = cleanSrcPath(src);
+            const cleanAlt = cleanAltText(alt || 'Figure');
             hasImages = true;
-            usedComponents.add('ResponsiveImage');
-
-            let props = [];
-            props.push(`src="${cleanSrc}"`);
-            if (alt) props.push(`alt="${alt}"`);
 
-            // Parse attributes if present
+            let id = '';
             if (attributes) {
                 const idMatch = attributes.match(/#([\w-]+)/);
-                if (idMatch) props.push(`id="${idMatch[1]}"`);
-
-                const widthMatch = attributes.match(/width="([^"]+)"/);
-                if (widthMatch && widthMatch[1] !== '\\linewidth') {
-                    props.push(`width="${widthMatch[1]}"`);
-                }
+                if (idMatch) id = idMatch[1];
             }
 
-            return `<ResponsiveImage ${props.join(' ')} />`;
+            return createResponsiveImageComponent(cleanSrc, cleanAlt, id);
         }
     );
 
     if (hasImages) {
-        console.log('    ✅ ResponsiveImage component will be imported');
+        console.log('    ✅ ResponsiveImage components with imports will be created');
     }
 
     return content;
@@ -258,8 +383,9 @@ function cleanMdxSyntax(content) {
 function processMdxContent(content) {
     console.log('🔧 Processing for Astro MDX compatibility...');
 
-    // Clear previous component tracking
+    // Clear previous tracking
     usedComponents.clear();
+    imageImports.clear();
 
     let processedContent = content;
 

app/src/content/article.mdx

@@ -4,7 +4,48 @@ description: "Converted from LaTeX to MDX"
 date: "2025-09-18"
 ---
 
-import ResponsiveImage from "../components/ResponsiveImage.astro";
+import ResponsiveImage from '../components/ResponsiveImage.astro';
+import ch1_lerobot_figure1 from '../assets/image/figures/ch1/ch1-lerobot-figure1.png';
+import ch2_approaches from '../assets/image/figures/ch2/ch2-approaches.png';
+import ch2_platforms from '../assets/image/figures/ch2/ch2-platforms.png';
+import ch2_cost_accessibility from '../assets/image/figures/ch2/ch2-cost-accessibility.png';
+import ch2_so100_to_planar_manipulator from '../assets/image/figures/ch2/ch2-so100-to-planar-manipulator.png';
+import ch2_planar_manipulator_free from '../assets/image/figures/ch2/ch2-planar-manipulator-free.png';
+import ch2_planar_manipulator_floor from '../assets/image/figures/ch2/ch2-planar-manipulator-floor.png';
+import ch2_planar_manipulator_floor_shelf from '../assets/image/figures/ch2/ch2-planar-manipulator-floor-shelf.png';
+import ch2_classical_limitations from '../assets/image/figures/ch2/ch2-classical-limitations.png';
+import ch3_learning_benefits from '../assets/image/figures/ch3/ch3-learning-benefits.png';
+import ch3_learning_atlas from '../assets/image/figures/ch3/ch3-learning-atlas.png';
+import ch3_rl_examples from '../assets/image/figures/ch3/ch3-rl-examples.png';
+import ch3_agent_env from '../assets/image/figures/ch3/ch3-agent-env.png';
+import ch3_rl_algorithms_atlas from '../assets/image/figures/ch3/ch3-rl-algorithms-atlas.png';
+import ch3_duck_sim_vs_real from '../assets/image/figures/ch3/ch3-duck-sim-vs-real.png';
+import ch3_many_ducks from '../assets/image/figures/ch3/ch3-many-ducks.png';
+import ch3_hil_serl_examples from '../assets/image/figures/ch3/ch3-hil-serl-examples.png';
+import ch4_bc_trajectories from '../assets/image/figures/ch4/ch4-bc-trajectories.png';
+import ch4_observation_action_mapping from '../assets/image/figures/ch4/ch4-observation-action-mapping.png';
+import ch4_issues_with_bc from '../assets/image/figures/ch4/ch4-issues-with-bc.png';
+import ch4_task_effect_on_pairs from '../assets/image/figures/ch4/ch4-task-effect-on-pairs.png';
+import ch4_latent_variable_model from '../assets/image/figures/ch4/ch4-latent-variable-model.png';
+import ch4_many_latents from '../assets/image/figures/ch4/ch4-many-latents.png';
+import ch4_diffusion_robot_actions from '../assets/image/figures/ch4/ch4-diffusion-robot-actions.png';
+import ch4_action_vs_observation_distribution from '../assets/image/figures/ch4/ch4-action-vs-observation-distribution.png';
+import ch4_normalizing_flows from '../assets/image/figures/ch4/ch4-normalizing-flows.png';
+import ch4_diffusion_vs_flowmatching from '../assets/image/figures/ch4/ch4-diffusion-vs-flowmatching.png';
+import ch4_act from '../assets/image/figures/ch4/ch4-act.png';
+import ch4_act_encoder from '../assets/image/figures/ch4/ch4-act-encoder.png';
+import ch4_act_decoder from '../assets/image/figures/ch4/ch4-act-decoder.png';
+import ch4_diffusion_policy from '../assets/image/figures/ch4/ch4-diffusion-policy.png';
+import ch5_ml_vs_robotics_foundation from '../assets/image/figures/ch5/ch5-ml-vs-robotics-foundation.png';
+import ch5_generalist_policies_timeline from '../assets/image/figures/ch5/ch5-generalist-policies-timeline.png';
+import ch5_trends from '../assets/image/figures/ch5/ch5-trends.png';
+import ch5_pi0 from '../assets/image/figures/ch5/ch5-pi0.png';
+import ch5_smolvla from '../assets/image/figures/ch5/ch5-smolvla.png';
+import ch2_planar_manipulator_floor_box from '../assets/image/figures/ch2/ch2-planar-manipulator-floor-box.png';
+import ch4_async_inference from '../assets/image/figures/ch4/ch4-async-inference.png';
+import ch4_queues from '../assets/image/figures/ch4/ch4-queues.png';
+import ch5_pi0_sampling_timesteps from '../assets/image/figures/ch5/ch5-pi0-sampling-timesteps.png';
+
 
 # Foreword
 
@@ -14,11 +55,11 @@ Nonetheless, we also hold that the wealth of research from both academia and ind
 
 This tutorial...
 
-- Does *not* aim to be a comprehensive guide to general field of robotics, manipulation or underactuated systems: [@sicilianoSpringerHandbookRobotics2016](#bibliography) and [@tedrakeRoboticManipulationPerception](#bibliography), [@tedrakeUnderactuatedRoboticsAlgorithms](#bibliography) do this better than we ever could.
+- Does *not* aim to be a comprehensive guide to general field of robotics, manipulation or underactuated systems: @sicilianoSpringerHandbookRobotics2016 and @tedrakeRoboticManipulationPerception, @tedrakeUnderactuatedRoboticsAlgorithms do this better than we ever could.
 
-- Does *not* aim to be an introduction to statistical or deep learning: [@shalev-shwartzUnderstandingMachineLearning2014](#bibliography) and [@prince2023understanding](#bibliography) cover these subjects better than we ever could.
+- Does *not* aim to be an introduction to statistical or deep learning: @shalev-shwartzUnderstandingMachineLearning2014 and @prince2023understanding cover these subjects better than we ever could.
 
-- Does *not* aim to be a deep dive into Reinforcement Learning, Diffusion Models, or Flow Matching: invaluable works such as [@suttonReinforcementLearningIntroduction2018](#bibliography), [@nakkiranStepbyStepDiffusionElementary2024](#bibliography), and [@lipmanFlowMatchingGuide2024](#bibliography) do this better than we ever could.
+- Does *not* aim to be a deep dive into Reinforcement Learning, Diffusion Models, or Flow Matching: invaluable works such as @suttonReinforcementLearningIntroduction2018, @nakkiranStepbyStepDiffusionElementary2024, and @lipmanFlowMatchingGuide2024 do this better than we ever could.
 
 Instead, our goal here is to provide an intuitive explanation as per why these disparate ideas have converged to form the exciting field of modern robot learning, driving the unprecedented progress we see today. In this spirit, we follow the adage: "a jack of all trades is a master of none, *but oftentimes better than a master of one*."
 
@@ -26,4 +67,611 @@ We sincerely hope this tutorial serves as a valuable starting point for your jou
 
 # Introduction
 
-<ResponsiveImage src="/assets/image/figures/ch1/ch1-lerobot-figure1.png" alt="lerobot is the open-source library for end-to-end robotics developed by Hugging Face. The library is vertically integrated on the entire robotics stack, supporting low-level control of real-world robot devices, advanced data and inference optimizations, as well as SOTA robot learning methods with simple implementations in pure Pytorch." id="fig" />
+<ResponsiveImage
+  src={ch1_lerobot_figure1}
+  zoomable
+  downloadable
+  id="fig:figure1"
+  layout="fixed"
+  alt="lerobot is the open-source library for end-to-end robotics developed by Hugging Face. The library is..."
+  caption={'lerobot is the open-source library for end-to-end robotics developed by Hugging Face. The library is vertically integrated on the entire robotics stack, supporting low-level control of real-world robot devices, advanced data and inference optimizations, as well as SOTA robot learning methods with simple implementations in pure Pytorch.'}
+/>
+
+Autonomous robotics holds the premise of relieving humans from repetitive, tiring or dangerous manual tasks. Consequently, the field of robotics has been widely studied since its first inception in the 1950s. Lately, advancements in Machine Learning (ML) have sparked the development of a relatively new class of methods used to tackle robotics problems, leveraging large amounts of data and computation rather than human expertise and modeling skills to develop autonomous systems.
+
+The frontier of robotics research is indeed increasingly moving away from classical model-based control paradigm, embracing the advancements made in ML, aiming to unlock (1) monolithic perception-to-action control pipelines and (2) multi-modal data-driven feature extraction strategies, together with (3) reduced reliance on precise models of the world and (4) a better positioning to benefit from the growing availability of open robotics data. While central problems in manipulation, locomotion and whole-body control demand knowledge of rigid-body dynamics, contact modeling, planning under uncertainty, recent results seem to indicate learning can prove just as effective as explicit modeling, sparking interest in the field of *robot learning*. This interest can be largely justified considering the significant challenges related to deriving accurate models of robot-environment interactions.
+
+Moreover, since end-to-end learning on ever-growing collections of text and image data has historically been at the core of the development of *foundation models* capable of semantic reasoning across multiple modalities (images, text, audio, etc.), deriving robotics methods grounded in learning appears particularly consequential, especially as the number of openly available datasets continues to grow.
+
+Robotics is, at its core, an inherently multidisciplinary field, requiring a wide range of expertise in both *software* and *hardware*. The integration of learning-based techniques further broadens this spectrum of skills, raising the bar for both research and practical applications. `lerobot` is an open-source library designed to integrate end-to-end with the entire robotics stack. With a strong focus on accessible, real-world robots <span class="text-hf-secondary">(1) `lerobot` supports many, openly available, robotic platforms</span> for manipulation, locomotion and even whole-body control. `lerobot`also implements a <span class="text-hf-secondary">(2) unified, low-level approach to reading/writing robot configurations</span> to extend support for other robot platforms with relatively low effort. The library introduces `LeRobotDataset`, <span class="text-hf-secondary">(3) a native robotics dataset’s format</span> currently being used by the community to efficiently record and share datasets. `lerobot` also supports many state-of-the-art (SOTA) algorithms in robot learning--mainly based on Reinforcement Learning (RL) and Behavioral Cloning (BC) techniques--with efficient implementations in Pytorch, and extended support to experimentation and experiments tracking. Lastly, `lerobot` defines a custom, optimized inference stack for robotic policies decoupling action planning from action execution, proving effective in guaranteeing more adaptability at runtime.
+
+This tutorial serves the double purpose of providing useful references for the Science behind--and practical use of--common robot learning techniques. To this aim, we strike to provide a rigorous yet concise overview of the core concepts behind the techniques presented, paired with practical examples of how to use such techniques concretely, with code examples in `lerobot`, for researchers and practitioners interested in the field of robot learning. This tutorial is structured as follows:
+
+- Section <a href="#sec:classical" data-reference-type="ref" data-reference="sec:classical">2</a> reviews classical robotics foundations, introducing the limitations of dynamics-based approaches to robotics.
+
+- Section <a href="#sec:learning-rl" data-reference-type="ref" data-reference="sec:learning-rl">3</a> elaborates on the limitations of dynamics-based methods, and introduce RL as a practical approach to solve robotics problems, considering its upsides and potential limitations.
+
+- Section <a href="#sec:learning-imitation" data-reference-type="ref" data-reference="sec:learning-imitation">4</a> further describes robot learning techniques that aim at solving single-tasks learning, leveraging BC techniques to autonomously reproduce specific expert demonstrations.
+
+- Section <a href="#sec:learning-foundation" data-reference-type="ref" data-reference="sec:learning-foundation">5</a> presents recent contributions on developing generalist models for robotics applications, by learning from large corpora of multi-task  multi-robot data (*robotics foundation models*).
+
+Our goal with this tutorial is to provide an intuitive explanation of the reasons various disparate ideas from Machine Learning (ML) have converged and are powering the current evolution of Robotics, driving the unprecedented progress we see today. We complement our presentation of the most common and recent approaches in robot learning with practical code implementations using `lerobot`, and start here by presenting the dataset format introduced with `lerobot`.
+
+## `LeRobotDataset`
+
+`LeRobotDataset` is a standardized dataset format designed to address the specific needs of robot learning research, and it provides a unified and convenient access to robotics data across modalities, including sensorimotor readings, multiple camera feeds and teleoperation status. `LeRobotDataset` also accommodates for storing general information regarding the data being collected, including textual descriptions of the task being performed by the teleoperator, the kind of robot used, and relevant measurement specifics like the frames per second at which the recording of both image and robot state’s streams are proceeding.
+
+In this, `LeRobotDataset` provides a unified interface for handling multi-modal, time-series data, and it is designed to seamlessly integrate with the PyTorch and Hugging Face ecosystems. `LeRobotDataset` can be easily extended by users and it is highly customizable by users, and it already supports openly available data coming from a variety of embodiments supported in `lerobot`, ranging from manipulator platforms like the SO-100 arm and ALOHA-2 setup, to real-world humanoid arm and hands, as well as entirely simulation-based datasets, and self-driving cars. This dataset format is built to be both efficient for training and flexible enough to accommodate the diverse data types encountered in robotics, while promoting reproducibility and ease of use for users.
+
+### The dataset class design
+
+A core design choice behind `LeRobotDataset` is separating the underlying data storage from the user-facing API. This allows for efficient storage while presenting the data in an intuitive, ready-to-use format.
+
+Datasets are always organized into three main components:
+
+- **Tabular Data**: Low-dimensional, high-frequency data such as joint states, and actions are stored in efficient memory-mapped files, and typically offloaded to the more mature `datasets` library by Hugging Face, providing fast with limited memory consumption.
+
+- **Visual Data**: To handle large volumes of camera data, frames are concatenated and encoded into MP4 files. Frames from the same episode are always grouped together into the same video, and multiple videos are grouped together by camera. To reduce stress on the file system, groups of videos for the same camera view are also broke into multiple sub-directories, after a given threshold number.
+
+- **Metadata** A collection of JSON files which describes the dataset’s structure in terms of its metadata, serving as the relational counterpart to both the tabular and visual dimensions of data. Metadata include the different feature schema, frame rates, normalization statistics, and episode boundaries.
+
+For scalability, and to support datasets with potentially millions of trajectories (resulting in hundreds of millions or billions of individual camera frames), we merge data from different episodes into the same high-level structure. Concretely, this means that any given tabular collection and video will not typically contain information about one episode only, but rather a concatenation of the information available in multiple episodes. This keeps the pressure on the file system limited, both locally and on remote storage providers like Hugging Face, though at the expense of leveraging more heavily relational-like, metadata parts of the dataset, which are used to reconstruct information such as at which position, in a given file, an episode starts or ends. An example struture for a given `LeRobotDataset` would appear as follows:
+
+- `meta/info.json`: This metadata is a central metadata file. It contains the complete dataset schema, defining all features (e.g., `observation.state`, `action`), their shapes, and data types. It also stores crucial information like the dataset’s frames-per-second (`fps`), `lerobot`’s version at the time of capture, and the path templates used to locate data and video files.
+
+- `meta/stats.json`: This file stores aggregated statistics (mean, std, min, max) for each feature across the entire dataset, used for data normalization for most policy models and accessible externally via `dataset.meta.stats`.
+
+- `meta/tasks.jsonl`: This file contains the mapping from natural language task descriptions to integer task indices, which are useful for task-conditioned policy training.
+
+- `meta/episodes/*` This directory contains metadata about each individual episode, such as its length, the corresponding task, and pointers to where its data is stored in the dataset’s files. For scalability, this information is stored in files rather than a single large JSON file.
+
+- `data/*`: Contains the core frame-by-frame tabular data, using parquet files to allow for fast, memory-mapped access. To improve performance and handle large datasets, data from multiple episodes are concatenated into larger files. These files are organized into chunked subdirectories to keep the size of directories manageable. A single file typically contains data for more than one single episode.
+
+- `videos/*`: Contains the MP4 video files for all visual observation streams. Similar to the `data/` directory, the video footage from multiple episodes is concatenated into single MP4 files. This strategy significantly reduces the number of files in the dataset, which is more efficient for modern filesystems.
+
+## Code Example: Batching a (Streaming) Dataset
+
+This section provides an overview of how to access datasets hosted on Hugging Face using the `LeRobotDataset` class. Every dataset on the Hugging Face Hub containing the three main pillars presented above (Tabular, Visual and relational Metadata), and can be assessed with a single instruction.
+
+In practice, most reinforcement learning (RL) and behavioral cloning (BC) algorithms tend to operate on stack of observation and actions. For the sake of brevity, we will refer to joint spaces, and camera frames with the single term of *frame*. For instance, RL algorithms may use a history of previous frames $o_{t-H_o:t}$ to mitigate partial observability, and BC algorithms are in practice trained to regress chunks of multiple actions ($a_{t+t+H_a}$) rather than single controls. To accommodate for these specifics of robot learning training, `LeRobotDataset` provides a native windowing operation, whereby users can define the *seconds* of a given window (before and after) around any given frame, by using the `delta_timestemps` functionality. Unavailable frames are opportunely padded, and a padding mask is also returned to filter out the padded frames. Notably, this all happens within the `LeRobotDataset`, and is entirely transparent to higher level wrappers commonly used in training ML models such as `torch.utils.data.DataLoader`.
+
+Conveniently, by using `LeRobotDataset` with a Pytorch `DataLoader` one can automatically collate the individual sample dictionaries from the dataset into a single dictionary of batched tensors for downstream training or inference. `LeRobotDataset` also natively supports streaming mode for datasets. Users can stream data of a large dataset hosted on the Hugging Face Hub, with a one-line change in their implementation. Streaming datasets supports high-performance batch processing (ca. 80-100 it/s, varying on connectivity) and high levels of frames randomization, key features for practical BC algorithms which otherwise may be slow or operating on highly non-i.i.d. data. This feature is designed to improve on accessibility so that large datasets can be processed by users without requiring large amounts of memory and storage.
+
+<div class="pbox">
+
+Batching a (Streaming) Dataset
+
+```python
+import torch
+from lerobot.datasets.lerobot_dataset import LeRobotDataset
+from lerobot.datasets.streaming_dataset import StreamingLeRobotDataset
+
+delta_timestamps = {
+    "observation.images.wrist_camera": [-0.2, -0.1, 0.0]  # 0.2, and 0.1 seconds *before* each frame
+}
+
+# Optionally, use StreamingLeRobotDataset to avoid downloading the dataset
+dataset = LeRobotDataset(
+    "lerobot/svla_so101_pickplace",
+    delta_timestamps=delta_timestamps
+)
+
+# Streams frames from the Hugging Face Hub without loading into memory
+streaming_dataset = StreamingLeRobotDataset(
+    "lerobot/svla_so101_pickplace",
+    delta_timestamps=delta_timestamps
+)
+
+# Get the 100th frame in the dataset by 
+sample = dataset[100]
+print(sample)
+# 
+
+batch_size=16
+# wrap the dataset in a DataLoader to use process it batches for training purposes
+data_loader = torch.utils.data.DataLoader(
+    dataset,
+    batch_size=batch_size
+)
+
+# Iterate over the DataLoader in a training loop
+num_epochs = 1
+device = "cuda" if torch.cuda.is_available() else "cpu"
+
+for epoch in range(num_epochs):
+    for batch in data_loader:
+        # Move data to the appropriate device (e.g., GPU)
+        observations = batch["observation.state"].to(device)
+        actions = batch["action"].to(device)
+        images = batch["observation.images.wrist_camera"].to(device)
+
+        # Next, you can do amazing_model.forward(batch)
+        ...
+```
+
+</div>
+
+# Classical Robotics
+
+<div class="epigraph">
+
+*Know your enemy* \[...\]
+
+Sun Tzu
+
+</div>
+<div class="callout">
+
+TL;DR Learning-based approaches to robotics are motivated by the need to (1) generalize across tasks and embodiments (2) reduce dependency on human expertise (3) leverage historical trends on the production of data--all traditionally overlooked by dynamics-based techniques.
+
+</div>
+
+## Explicit and Implicit Models
+
+<ResponsiveImage
+  src={ch2_approaches}
+  zoomable
+  downloadable
+  id="fig:generating-motion-atlas"
+  layout="fixed"
+  alt="Overview of methods to generate motion (clearly non-exhausitve, see @bekrisStateRobotMotion2024). Th..."
+  caption={'Overview of methods to generate motion (clearly non-exhausitve, see @bekrisStateRobotMotion2024). The different methods can be grouped based on whether they explicitly (dynamics-based) or implicitly (learning-based) model robot-environment interactions.'}
+/>
+
+Robotics is concerned with producing artificial motion in the physical world in useful, reliable and safe fashion. Thus, robotics is an inherently multi-disciplinar domain: producing autonomous motion in the physical world requires, to the very least, interfacing different software (motion planners) and hardware (motion executioners) components. Further, knowledge of mechanical, electrical, and software engineering, as well as rigid-body mechanics and control theory have therefore proven quintessential in robotics since the field first developed in the 1950s. More recently, Machine Learning (ML) has also proved effective in robotics, complementing these more traditional disciplines @connellRobotLearning1993. As a direct consequence of its multi-disciplinar nature, robotics has developed as a rather wide array of methods, all concerned with the main purpose of <span class="text-hf-secondary">producing artificial motion in the physical world</span>.
+
+Methods to produce robotics motion range from traditional *explicit* models--<span class="text-hf-secondary">dynamics-based</span>[^1] methods, leveraging precise descriptions of the mechanics of robots’ rigid bodies and their interactions with eventual obstacles in the environment--to *implicit* models--<span class="text-hf-secondary">learning-based</span> methods, treating artificial motion as a statistical pattern to learn given multiple sensorimotor readings @agrawalComputationalSensorimotorLearning, @bekrisStateRobotMotion2024. A variety of methods have been developed between these two extrema. For instance,  @hansenTemporalDifferenceLearning2022 show how learning-based systems can benefit from information on the physics of problems, complementing a traditional learning method such as Temporal Difference (TD)-learning @suttonReinforcementLearningIntroduction2018 with Model-Predictive Control (MPC). Conversely, as explicit models may be relying on assumptions proving overly simplistic--or even unrealistic--in practice, learning can prove effective to improve modeling of complex phenomena or complement perception @mccormacSemanticFusionDense3D2016. Such examples aim at demonstrating the richness of approaches to robotics, and Figure <a href="#fig:generating-motion-atlas" data-reference-type="ref" data-reference="fig:generating-motion-atlas">2</a> graphically illustrates some of the most relevant techniques. Such a list is clearly far from being exhaustive, and we refer to @bekrisStateRobotMotion2024 for a more comprehensive overview of both general and application-specific methods for motion generation. In this section, we wish to introduce the inherent benefits of <span class="text-hf-secondary">learning-based approaches to robotics</span>--the core focus on this tutorial.
+
+## Different Types of Motion
+
+<ResponsiveImage
+  src={ch2_platforms}
+  zoomable
+  downloadable
+  id="fig:robotics-platforms-atlas"
+  layout="fixed"
+  alt="Different kinds of motions are achieved with potentially very different robotic platforms. From left..."
+  caption={'Different kinds of motions are achieved with potentially very different robotic platforms. From left to right, top to bottom: ViperX, SO-100, Boston Dynamics’ Spot, Open-Duck, 1X’s NEO, Boston Dynamics’ Atlas. This is an example list of robotic platforms and is (very) far from being exhaustive.'}
+/>
+
+In the vast majority of instances, robotics deals with producing motion via actuating joints connecting nearly entirely-rigid links. A key distinction between focus areas in robotics is based on whether the generated motion modifies (1) the absolute state of the environment (via dexterity), (2) the relative state of the robot with respect to its environment (exercising mobility skills), or (3) a combination of the two (Figure <a href="#fig:robotics-platforms-atlas" data-reference-type="ref" data-reference="fig:robotics-platforms-atlas">3</a>).
+
+Effects such as (1) are typically achieved *through* the robot, i.e. generating motion to perform an action inducing a desirable modification, effectively *manipulating* the environment (manipulation). Motions like (2) may result in changes in the robot’s physical location within its environment. Generally, modifications to a robot’s location within its environment may be considered instances of the general *locomotion* problem, further specified as *wheeled* or *legged* locomotion based on whenever a robot makes use of wheels or leg(s) to move in the environment. Lastly, an increased level of dynamism in the robot-environment interactions can be obtained combining (1) and (2), thus designing systems capable to interact with *and* move within their environment. This category is problems is typically termed *mobile manipulation*, and is characterized by a typically much larger set of control variables compared to either locomotion or manipulation alone.
+
+The traditional body of work developed since the very inception of robotics is increasingly complemented by learning-based approaches. ML has indeed proven particularly transformative across the entire robotics stack, first empowering planning-based techniques with improved state estimation used for traditional planning @tangPerceptionNavigationAutonomous2023 and then end-to-end replacing controllers, effectively yielding perception-to-action methods @koberReinforcementLearningRobotics. Work in producing robots capable of navigating a diverse set of terrains demonstrated the premise of both dynamics and learning-based approaches for locomotion @griffinWalkingStabilizationUsing2017, @jiDribbleBotDynamicLegged2023, @leeLearningQuadrupedalLocomotion2020, @margolisRapidLocomotionReinforcement2022, and recent works on whole-body control indicated the premise of learning-based approaches to generate rich motion on complex robots, including humanoids @zhangWoCoCoLearningWholeBody2024, @bjorckGR00TN1Open2025. Manipulation has also been widely studied, particularly considering its relevance for many impactful use-cases ranging from high-risk applications for humans @fujitaDevelopmentRobotsNuclear2020, @alizadehComprehensiveSurveySpace2024 to manufacturing @sannemanStateIndustrialRobotics2020. While explicit models have proven fundamental in achieving important milestones towards the development of modern robotics, recent works leveraging implicit models proved particularly promising in surpassing scalability and applicability challenges via learning @koberReinforcementLearningRobotics.
+
+## Example: Planar Manipulation
+
+Robot manipulators typically consist of a series of links and joints, articulated in a chain finally connected to an *end-effector*. Actuated joints are considered responsible for generating motion of the links, while the end effector is instead used to perform specific actions at the target location (e.g., grasping/releasing objects via closing/opening a gripper end-effector, using a specialized tool like a screwdriver, etc.).
+
+Recently, the development of low-cost manipulators like the ALOHA @zhaoLearningFineGrainedBimanual2023 ALOHA-2 @aldacoALOHA2Enhanced and SO-100/SO-101 @knightStandardOpenSO100 platforms significantly lowered the barrier to entry to robotics, considering the increased accessibility of these robots compared to more traditional platforms like the Franka Emika Panda arm (Figure <a href="#fig:robotic-platforms-costs" data-reference-type="ref" data-reference="fig:robotic-platforms-costs">4</a>).
+
+<ResponsiveImage
+  src={ch2_cost_accessibility}
+  zoomable
+  downloadable
+  id="fig:robotic-platforms-costs"
+  layout="fixed"
+  alt="Cheaper, more accessible robots are starting to rival traditional platforms like the Panda arm platf..."
+  caption={'Cheaper, more accessible robots are starting to rival traditional platforms like the Panda arm platforms in adoption in resource-constrained scenarios. The SO-100, in particular, has a cost in the 100s of Euros, and can be entirely 3D-printed in hours, while the industrially-manufactured Panda arm costs tens of thousands of Euros and is not openly available.'}
+/>
+
+Deriving an intuition as per why learning-based approaches are gaining popularity in the robotics community requires briefly analyzing traditional approaches for manipulation, leveraging tools like forward and inverse kinematics (FK, IK) and control theory. Providing a detailed overview of these methods falls (well) out of the scope of this tutorial, and we refer the reader to works including @sicilianoSpringerHandbookRobotics2016, @lynchModernRoboticsMechanics2017, @tedrakeRoboticManipulationPerception, @tedrakeUnderactuatedRoboticsAlgorithms for a much more comprehensive description of these techniques. Here, we mostly wish to highlight the benefits of ML over these traditional techniques
+
+<ResponsiveImage
+  src={ch2_so100_to_planar_manipulator}
+  zoomable
+  downloadable
+  id="fig:make-so100-planar-manipulator"
+  layout="fixed"
+  alt="The SO-100 arm is a 6-dof manipulator arm. Preventing some of its joints (shoulder pane, wrist flex ..."
+  caption={'The SO-100 arm is a 6-dof manipulator arm. Preventing some of its joints (shoulder pane, wrist flex and wrist roll) from actuating, it can be represented as a traditional 2-dof planar manipulator (the gripper joint in the end-effector is not considered towards the count of the degrees of freedom used to produce motion).'}
+/>
+
+Consider the (simple) case where a SO-100 is restrained from actuating (1) the shoulder pane and (2) the wrist flex and roll motors. This effectively reduces the degrees of freedom of the SO-100 from the original 5+1 (5 joints + 1 gripper) to 2+1 (shoulder lift, elbow flex + gripper). As the end-effector does not impact motion in this model, the SO-100 is effectively reduced to the planar manipulator robot presented in Figure <a href="#fig:make-so100-planar-manipulator" data-reference-type="ref" data-reference="fig:make-so100-planar-manipulator">5</a>, where spheres represent actuators, and solid lines indicate length-$l$ links from the base of the SO-100 to the end-effector (*ee*).
+
+Further, let us make the simplifying assumption that actuators can produce rotations up to $2 \pi$ radians. In practice, this is seldom the case due to movement obstructions caused by the robot body itself (for instance, the shoulder lift cannot produce counter-clockwise movement due to the presence of the robot’s base used to secure the SO-100 to its support and host the robot bus), but we will introduce movement obstruction at a later stage.
+
+All these simplifying assumptions leave us with the planar manipulator of Figure <a href="#fig:planar-manipulation-simple" data-reference-type="ref" data-reference="fig:planar-manipulation-simple">6</a>, free of moving its end-effector by controlling the angles $\theta_1$ and $\theta_2$, jointly referred to as the robot’s *configuration*, and indicated with $q = [\theta_1, \theta_2 ] \in [-\pi, +\pi]^2$. The axis attached to the joints indicate the associated reference frame, whereas circular arrows indicate the maximal feasible rotation allowed at each joint. In this tutorial, we do not cover topics related to spatial algebra, and we instead refer the reader to and for excellent explanations of the mechanics and theoretical foundations of producing motion on rigid bodies.
+
+<figure id="fig:planar-manipulator-floor-shelf">
+<ResponsiveImage
+  src={ch2_planar_manipulator_free}
+  zoomable
+  downloadable
+  id="fig:planar-manipulation-simple"
+  layout="fixed"
+  alt="Free to move"
+  caption={'Free to move'}
+/>
+<ResponsiveImage
+  src={ch2_planar_manipulator_floor}
+  zoomable
+  downloadable
+  id="fig:planar-manipulator-floor"
+  layout="fixed"
+  alt="Constrained by the surface"
+  caption={'Constrained by the surface'}
+/>
+<ResponsiveImage
+  src={ch2_planar_manipulator_floor_shelf}
+  zoomable
+  downloadable
+  id="fig:planar-manipulator-floor-shelf"
+  layout="fixed"
+  alt="Constrained by surface and (fixed) obstacle"
+  caption={'Constrained by surface and (fixed) obstacle'}
+/>
+<figcaption>Planar, 2-dof schematic representation of the SO-100 manipulator under diverse deployment settings. From left to right: completely free of moving; constrained by the presence of the surface; constrained by the surface and presence of obstacles. Circular arrows around each joint indicate the maximal rotation feasible at that joint.</figcaption>
+</figure>
+
+Considering the (toy) example presented in Figure <a href="#fig:planar-manipulation-simple" data-reference-type="ref" data-reference="fig:planar-manipulation-simple">6</a>, then we can analytically write the end-effector’s position $p \in \mathbb R^2$ as a function of the robot’s configuration, $p = p(q), p: \mathcal Q \mapsto \mathbb R^2$. In particular, we have: 
+$$
+`p(q) = 
+\begin
+p_x(\theta_1, \theta_2)\\
+    p_y(\theta_1, \theta_2)
+\end{pmatrix}
+=
+\begin{pmatrix}
+l \cos(\theta_1) + l \cos(\theta_1 + \theta_2)\\
+    l \sin(\theta_1) + l \sin(\theta_1 + \theta_2)
+\end{pmatrix}
+\in S^{n=2}_{l_1+l_2} = \{ p(q) \in \mathbb R^2: \Vert p(q) \Vert_2^2 \leq (2l)^2, \ \forall q \in \mathcal Q \}`
+$$
+
+
+Deriving the end-effector’s *pose*--position *and* orientation--in some $m$-dimensional space $\boldsymbol{p} \in \mathcal{P} \subset \mathbb{R}^{m}$ starting from the configuration ${\textnormal{q}}\in \mathcal Q \subset \mathbb R^n$ of a $n$-joints robot is referred to as *forward kinematics* (FK), whereas identifying the configuration corresponding to any given target pose is termed *inverse kinematics* (IK). In that, FK is used to map a robot configuration into the corresponding end-effector pose, whereas IK is used to reconstruct the configuration(s) given an end-effector pose.
+
+In the simplified case here considered (for which $\boldsymbol{p} \equiv p$, as the orientation of the end-effector is disregarded for simplicity), one can solve the problem of controlling the end-effector’s location to reach a goal position $p^*$ by solving analytically for $q: p(q) = f_{\text{FK}}(q) = p^*$. However, in the general case, one might not be able to solve this problem analytically, and can typically resort to iterative optimization methods comparing candidate solutions using a loss function (in the simplest case, $\Vert p(q) - p^* \Vert_2^2$ is a natural candidate), yielding:
+
+$\min_{q \in \mathcal Q} \Vert p(q) - p^* \Vert_2^2 \, .
+$
+
+Exact analytical solutions to IK are even less appealing when one considers the presence of obstacles in the robot’s workspace, resulting in constraints on the possible values of $q \in \mathcal Q \subseteq [-\pi, +\pi]^n \subset \mathbb R^n$ in the general case of $n$-links robots.
+
+For instance, the robot in Figure <a href="#fig:planar-manipulator-floor" data-reference-type="ref" data-reference="fig:planar-manipulator-floor">7</a> is (very naturally) obstacled by the presence of the surface upon which it rests: $\theta_1$ can now exclusively vary within $[0,  \pi]$, while possible variations in $\theta_2$ depend on $\theta_1$ (when $\theta_1 \to 0$ or $\theta_1 \to \pi$, further downwards movements are restricted). Even for a simplified kinematic model, developing techniques to solve eq. <a href="#eq:ik_problem" data-reference-type="ref" data-reference="eq:ik_problem">[eq:ik_problem]</a> is in general non-trivial in the presence of constraints, particularly considering that the feasible set of solutions $\mathcal Q$ may change across problems. Figure <a href="#fig:planar-manipulator-floor-shelf" data-reference-type="ref" data-reference="fig:planar-manipulator-floor-shelf">9</a> provides an example of how the environment influences the feasible set considered, with a new set of constraints deriving from the position of a new obstacle.
+
+However, IK--solving eq. <a href="#eq:ik_problem" data-reference-type="ref" data-reference="eq:ik_problem">[eq:ik_problem]</a> for a feasible $q$--only proves useful in determining information regarding the robot’s configuration in the goal pose, and crucially does not provide information on the *trajectory* to follow over time to reach a target pose. Expert-defined trajectories obviate to this problem providing a length-$K$ succession of goal poses $\tau_K = [p^*_0, p^*_1, \dots p^*_K]$ for tracking. In practice, trajectories can also be obtained automatically through *motion planning* algorithms, thus avoiding expensive trajectory definition from human experts. However, tracking $\tau_K$ via IK can prove prohibitively expensive, as tracking would require $K$ resolutions of eq. <a href="#eq:ik_problem" data-reference-type="ref" data-reference="eq:ik_problem">[eq:ik_problem]</a> (one for each target pose). *Differential* inverse kinematics (diff-IK) complements IK via closed-form solution of a variant of eq. <a href="#eq:ik_problem" data-reference-type="ref" data-reference="eq:ik_problem">[eq:ik_problem]</a>. Let $J(q)$ denote the Jacobian matrix of (partial) derivatives of the FK-function $f_\text{FK}: \mathcal Q \mapsto \mathcal P$, such that $J(q) = \frac{\partial f_{FK}(q)}{\partial q }$. Then, one can apply the chain rule to any $p(q) = f_{\text{FK}}(q)$, deriving $\dot p = J(q) \dot q$, and thus finally relating variations in the robot configurations to variations in pose, thereby providing a platform for control.
+
+Given a desired end-effector trajectory $\dot {p}^*(t)$ (1) indicating anchor regions in space and (2) how much time to spend in each region, diff-IK finds $\dot q(t)$ solving for joints’ *velocities* instead of *configurations*, $\dot q(t) = \arg\min_\nu \; \lVert J(q(t)) \nu - \dot {p}^*(t) \rVert_2^2
+$
+
+Unlike eq. <a href="#eq:ik_problem" data-reference-type="ref" data-reference="eq:ik_problem">[eq:ik_problem]</a>, solving for $\dot q$ is much less dependent on the environment (typically, variations in velocity are constrained by physical limits on the actuators). Conveniently, eq. <a href="#eq:reg_ik_velocity" data-reference-type="ref" data-reference="eq:reg_ik_velocity">[eq:reg_ik_velocity]</a> also often admits the closed-form solution $\dot q = J(q)^+ \dot {p}^*$, where $J^+(q)$ denotes the Moore-Penrose pseudo-inverse of $J(q)$. Finally, discrete-time joint configurations $q$ can be reconstructed from joint velocities $\dot q$ using forward-integration on the continuous-time joint velocity , $q_{t+1} = q_t + \Delta t\,\dot q_t$ for a given $\Delta t$, resulting in tracking via diff-IK.
+
+Following trajectories with diff-IK is a valid option in well-controlled and static environments (e.g., industrial manipulators in controlled manufacturing settings), and relies on the ability to define a set of target velocities to track $[\dot {p}^*_0, \dot {p}^*_1, \dots, \dot {p}^*_k ]$--an error-prone task largely requiring human expertise. Furthermore, diff-IK relies on the ability to (1) access $J(q) \, \forall q \in \mathcal Q$ and (2) compute its pseudo-inverse at every iteration of a given control cycle--a challenging assumption in highly dynamical settings, or for complex kinematic chains.
+
+### Adding Feedback Loops
+
+While very effective when a goal trajectory has been well specified, the performance of diff-IK can degrade significantly in the presence of modeling/tracking errors, or in the presence of non-modeled dynamics in the environment.
+
+<div class="wrapfigure">
+
+r0.3 <ResponsiveImage
+  src={ch2_planar_manipulator_floor_box}
+  zoomable
+  downloadable
+  layout="fixed"
+  alt="image"
+/>
+</div>
+
+One such case is presented in Figure <a href="#fig:planar-manipulator-box-velocity" data-reference-type="ref" data-reference="fig:planar-manipulator-box-velocity">[fig:planar-manipulator-box-velocity]</a>, where another rigid body other than the manipulator is moving in the environment along the horizontal axis, with velocity $\dot x_B$. Accounting analytically for the presence of this disturbance--for instance, to prevent the midpoint of the link from ever colliding with the object--requires access to $\dot x_B$ at least, to derive the equation characterizing the motion of the environment.
+
+Less predictable disturbances however (e.g., $\dot x_B \leftarrow \dot x_B + {\varepsilon}, {\varepsilon}\sim N(0,1)$) may prove challenging to model analytically, and one could attain the same result of preventing link-object collision by adding a condition on the distance between the midpoint of $l$ and $x_B$, enforced through a feedback loop on the position of the robot and object at each control cycle.
+
+To mitigate the effect of modeling errors, sensing noise and other disturbances, classical pipelines indeed do augment diff-IK with feedback control looping back quantities of interest. In practice, following a trajectory with a closed feedback loop might consist in backwarding the error between the target and measured pose, $\Delta p = p^*- p(q)$, hereby modifying the control applied to $\dot q = J(q)^+ (\dot {p}^*+ k_p \Delta p )$, with $k_p$ defined as the (proportional) gain.
+
+More advanced techniques for control consisting in feedback linearization, PID control, Linear Quatratic Regulator (LQR) or Model-Predictive Control (MPC) can be employed to stabilize tracking and reject moderate perturbations, and we refer to for in-detail explanation of these concepts, or for a simple, intuitive example in the case of a point-mass system. Nonetheless, feedback control presents its challenges as well: tuning gains remains laborious and system-specific. Further, manipulation tasks present intermittent contacts inducing hybrid dynamics (mode switches) and discontinuities in the Jacobian, challenging the stability guarantees of the controller and thus often necessitating rather conservative gains and substantial hand-tuning.
+
+We point the interested reader to , , and  for extended coverage of FK, IK, diff-IK and control for (diff-)IK.
+
+## Limitations of Dynamics-based Robotics
+
+Despite the last 60+ years of robotics research, autonomous robots are still largely incapable of performing tasks at human-level performance in the physical world generalizing across (1) robot embodiments (different manipulators, different locomotion platforms, etc.) and (2) tasks (tying shoe-laces, manipulating a diverse set of objects). While essential in the early development of robotics, the aforementioned methods require significant human expertise to be used in practice, and are typically specific to a particular applicative problem.
+
+<ResponsiveImage
+  src={ch2_classical_limitations}
+  zoomable
+  downloadable
+  id="fig:classical-limitations"
+  layout="fixed"
+  alt="Dynamics-based approaches to robotics suffer from several limitations: (1) orchestrating multiple co..."
+  caption={'Dynamics-based approaches to robotics suffer from several limitations: (1) orchestrating multiple components poses integration challenges; (2) the need to develop custom processing pipelines for the sensing modalities and tasks considered hinders scalability; (3) simplified analytical models of physical phenomena (here friction at the gripper; credits to @antonovaReinforcementLearningPivoting2017) limit real-world performance. Lastly, (4) dynamics-based methods overlook trends in the availability and growth of robotics data.'}
+/>
+
+Dynamics-based robotics pipelines have historically been <span class="text-hf-secondary">developed sequentially, engineering the different blocks</span> now within most architectures for specific purposes. That is, sensing, state estimation, mapping, planning, (diff-)IK, and low-level control have been traditionally developed as distinct modules with fixed interfaces. Pipelining these specific modules proved error-prone, and brittleness emerges--alongside compounding errors--whenever changes incur (e.g., changes in lighting for sensing, occlusion/failure of sensors, control failures). Adapting such a stack to new tasks or robotic platforms often entails re-specifying objectives, constraints, and heuristics at multiple stages, incurring significant engineering overhead.
+
+Moreover, classical planners operate on compact, assumed-sufficient state representations; extending them to reason directly over raw, heterogeneous and noisy data streams is non-trivial. This results in a <span class="text-hf-secondary">limited scalability to multimodal data and multitask settings</span>, as incorporating high-dimensional perceptual inputs (RGB, depth, tactile, audio) traditionally required extensive engineering efforts to extract meaningful features for control. Also, the large number of tasks, coupled with the adoption of *per-task* planners, goal parameterizations, and safety constraints, results in an explosion in design and validation options, with little opportunity to reuse solutions across tasks.
+
+Setting aside integration and scalability challenges: developing accurate modeling of contact, friction, and compliance for complicated systems remains difficult. Rigid-body approximations are often insufficient in the presence of deformable objects, and <span class="text-hf-secondary">relying on approximated models hinders real-world applicability</span> of the methods developed. In the case of complex, time-dependent and/or non-linear dynamics, even moderate mismatches in parameters, unmodeled evolutions, or grasp-induced couplings can qualitatively affect the observed dynamics.
+
+Lastly, dynamics-based methods (naturally) overlook the rather recent <span class="text-hf-secondary">increase in availability of openly-available robotics datasets</span>. The curation of academic datasets by large centralized groups of human experts in robotics @collaborationOpenXEmbodimentRobotic2025, @khazatskyDROIDLargeScaleInTheWild2025 is now increasingly complemented by a <span class="text-hf-secondary">growing number of robotics datasets contributed in a decentralized fashion</span> by individuals with varied expertise. If not tangentially, dynamics-based approaches are not posed to maximally benefit from this trend, which holds the premise of allowing generalization in the space of tasks and embodiments, like data was the cornerstone for advancements in vision @alayracFlamingoVisualLanguage2022 and natural-language understanding @brownLanguageModelsAre2020.
+
+Taken together, these limitations (Figure <a href="#fig:classical-limitations" data-reference-type="ref" data-reference="fig:classical-limitations">10</a>) motivate the exploration of learning-based approaches that can (1) integrate perception and control more tightly, (2) adapt across tasks and embodiments with reduced expert modeling interventions and (3) scale gracefully in performance as more robotics data becomes available.
+
+# Robot (Reinforcement) Learning
+
+<div class="epigraph">
+
+*Approximate the solution, not the problem* \[...\]
+
+Richard Sutton
+
+</div>
+<div class="callout">
+
+TL;DR The need for expensive high-fidelity simulators can be obviated by learning from real-world data, using sample-efficient algorithms that can safely train directly on hardware.
+
+</div>
+<ResponsiveImage
+  src={ch3_learning_benefits}
+  zoomable
+  downloadable
+  id="fig:robot-learning-upsides"
+  layout="fixed"
+  alt="Learning-based robotics streamlines perception-to-action by learning a (1) unified high-level contro..."
+  caption={'Learning-based robotics streamlines perception-to-action by learning a (1) unified high-level controller capable to take (2) high-dimensional, unstructured sensorimotor information. Learning (3) does not require a dynamics model and instead focuses on interaction data, and (4) empirically correlates with the scale of the data used.'}
+/>
+
+Learning-based techniques for robotics naturally address the limitations presented in <a href="#sec:classical" data-reference-type="ref" data-reference="sec:classical">2</a> (Figure <a href="#fig:robot-learning-upsides" data-reference-type="ref" data-reference="fig:robot-learning-upsides">11</a>). Learning-based techniques typically rely on prediction-to-action (*visuomotor policies*), thereby directly mapping sensorimotor inputs to predicted actions, streamlining control policies by removing the need to interface multiple components. Mapping sensorimotor inputs to actions directly also allows to add diverse input modalities, leveraging the automatic feature extraction characteristic of most modern learning systems. Further, learning-based approaches can in principle entirely bypass modeling efforts and instead rely exclusively on interactions data, proving transformative when dynamics are challenging to model or even entirely unknown. Lastly, learning for robotics (*robot learning*) is naturally well posed to leverage the growing amount of robotics data openly available, just as computer vision first and natural language processing later did historically benefit from large scale corpora of (possibly non curated) data, in great part overlooked by dynamics-based approaches.
+
+Being a field at its relative nascent stages, no prevalent technique(s) proved distinctly better better in robot learning. Still, two major classes of methods gained prominence: <span class="text-hf-secondary">reinforcement learning (RL)</span> and <span class="text-hf-secondary">Behavioral Cloning (BC)</span> (Figure <a href="#fig:robot-learning-atlas" data-reference-type="ref" data-reference="fig:robot-learning-atlas">12</a>). In this section, we provide a conceptual overview of applications of the former to robotics, as well as introduce practical examples of how to use RL within `lerobot`. We then introduce the major limitations RL suffers from, to introduce BC techniques in the next sections (<a href="#sec:learning-bc-single, sec:learning-bc-generalist" data-reference-type="ref" data-reference="sec:learning-bc-single, sec:learning-bc-generalist">[sec:learning-bc-single, sec:learning-bc-generalist]</a>).
+
+<ResponsiveImage
+  src={ch3_learning_atlas}
+  zoomable
+  downloadable
+  id="fig:robot-learning-atlas"
+  layout="fixed"
+  alt="Overview of the robot learning methods implemented in lerobot."
+  caption={'Overview of the robot learning methods implemented in lerobot.'}
+/>
+
+In Figure <a href="#fig:robot-learning-atlas" data-reference-type="ref" data-reference="fig:robot-learning-atlas">12</a> we decided to include generalist robot models @blackp0VisionLanguageActionFlow2024, @shukorSmolVLAVisionLanguageActionModel2025 alongside task-specific BC methods. While significant different in spirit--*generalist* models are language-conditioned and use instructions to generate motion valid across many tasks, while *task-specific* models are typically not language-conditioned and used to perform a single task--foundation models are largely trained to reproduce trajectories contained in a large training set of input demonstrations. Thus, we argue generalist policies can indeed be grouped alongside other task-specific BC methods, as they both leverage similar training data and schemas.
+
+Figure <a href="#fig:robot-learning-atlas" data-reference-type="ref" data-reference="fig:robot-learning-atlas">12</a> illustrates this categorization graphically, explicitly listing all the robot learning policies currently available in `lerobot`: Action Chunking with Transformers (ACT) @zhaoLearningFineGrainedBimanual2023, Diffusion Policy @chiDiffusionPolicyVisuomotor2024, Vector-Quantized Behavior Transformer (VQ-BeT) @leeBehaviorGenerationLatent2024, $\pi_0$ @blackp0VisionLanguageActionFlow2024, SmolVLA @shukorSmolVLAVisionLanguageActionModel2025, Human-in-the-loop Sample-efficient RL (HIL-SERL) @luoPreciseDexterousRobotic2024 and TD-MPC @hansenTemporalDifferenceLearning2022.
+
+<ResponsiveImage
+  src={ch3_rl_examples}
+  zoomable
+  downloadable
+  id="fig:robotics-with-rl-examples"
+  layout="fixed"
+  alt="Examples of two different robotics tasks performed using RL. In the manipulation task (A) an agent l..."
+  caption={'Examples of two different robotics tasks performed using RL. In the manipulation task (A) an agent learns to reach for a yellow plastic block in its environment, and to put it inside of a box. In the locomotion task (B) an agent learns to move its center of mass sideways without falling.'}
+/>
+
+Applications of RL to robotics have been long studied, to the point the relationship between these two disciplines has been compared to that between physics and matematics @koberReinforcementLearningRobotics. Indeed, due to their interactive and sequential nature, many robotics problems can be directly mapped to RL problems. Figure <a href="#fig:robotics-with-rl-examples" data-reference-type="ref" data-reference="fig:robotics-with-rl-examples">13</a> depicts two of such cases. Reaching for an object to move somewhere else in the scene is an indeed sequential problem where at each cycle the controller needs to adjust the position of the robotic arm based on their current configuration and the (possibly varying) position of the object. Figure <a href="#fig:robotics-with-rl-examples" data-reference-type="ref" data-reference="fig:robotics-with-rl-examples">13</a> also shows an example of a locomotion problem, where sequentiality is inherent in the problem formulation. While sliding to the side, the controller has to constantly keep adjusting to the robot’s propioperception to avoid failure (falling).
+
+## A (Concise) Introduction to RL
+
+The RL framework @suttonReinforcementLearningIntroduction2018, which we briefly introduce here, has often been used to model robotics problems @koberReinforcementLearningRobotics. RL is a subfield within ML fundamentally concerned with the development of autonomous systems (*agents*) learning how to *continuously behave* in an evolving environment, developing (ideally, well-performing) control strategies (*policies*). Crucially for robotics, RL agents can improve via trial-and-error only, thus entirely bypassing the need to develop explicit models of the problem dynamics, and rather exploiting interaction data only. In RL, this feedback loop (Figure <a href="#fig:rl-most-famous-pic" data-reference-type="ref" data-reference="fig:rl-most-famous-pic">14</a>) between actions and outcomes is established through the agent sensing a scalar quantity (*reward*).
+
+<ResponsiveImage
+  src={ch3_agent_env}
+  zoomable
+  downloadable
+  id="fig:rl-most-famous-pic"
+  layout="fixed"
+  alt="Agent-Environment interaction diagram (image credits to @suttonReinforcementLearningIntroduction2018..."
+  caption={'Agent-Environment interaction diagram (image credits to @suttonReinforcementLearningIntroduction2018).'}
+/>
+
+Formally, interactions between an agent and its environment are typically modeled via a Markov Decision Process (MDP) @bellmanMarkovianDecisionProcess1957. Representing robotics problems via MDPs offers several advantages, including (1) incorporating uncertainty through MDP’s inherently stochastic formulation and (2) providing a theoretically sound framework for learning *without* an explicit dynamic model. While accommodating also a continuous time formulation, MDPs are typically considered in discrete time in RL, thus assuming interactions to atomically take place over the course of discrete *timestep* $t=0,1,2,3, \dots, T$. MDPs allowing for an unbounded number of interactions ( $T \to + \infty$ ) are typically termed *infinite-horizon*, and opposed to *finite-horizon* MDPs in which $T$ cannot grow unbounded. Unless diversely specified, we will only be referring to discrete-time finite-horizon (*episodic*) MDPs here.
+
+Formally, a lenght-$T$ Markov Decision Process (MDP) is a tuple $\mathcal M = \langle \mathcal S, \mathcal A, \mathcal D, r, \gamma, \rho, T \rangle$, where:
+
+- $\mathcal S$ is the *state space*; $s_t\in \mathcal S$ denotes the (possibly non-directly observable) environment state at time $t$. In robotics, states often comprise robot configuration and velocities ($q_t, \dot q_t$), and can accomodate sensor readings such as camera or audio streams.
+
+- $\mathcal A$ is the *action space*; $a_t\in \mathcal A$ may represent joint torques, joint velocities, or even end-effector commands. In general, actions correspond to commands intervenings on the configuration of the robot.
+
+- $\mathcal D$ represents the (possibly non-deterministic) environment dynamics, with $\mathcal D: \mathcal S\times \mathcal A\times \mathcal S\mapsto [0, 1]$ corresponding to $\mathcal D\, (s_t, a_t, s_{t+1})= \mathbb P (s_{t+1}\vert s_t, a_t)$. For instance, for a planar manipulator dynamics could be considered deterministic when the environment is fully described (Figure <a href="#fig:planar-manipulation-simple" data-reference-type="ref" data-reference="fig:planar-manipulation-simple">6</a>), and stochastic when unmodeled disturbances depending on non-observable parameters intervene (Figure <a href="#fig:planar-manipulator-box-velocity" data-reference-type="ref" data-reference="fig:planar-manipulator-box-velocity">[fig:planar-manipulator-box-velocity]</a>).
+
+- $r: \mathcal S\times \mathcal A\times \mathcal S\to \mathbb R$ is the *reward function*, weighing the transition $(s_t, a_t, s_{t+1})$ in the context of the achievement of an arbitrary goal. For instance, a simple reward function for quickly moving the along the $x$ axis in 3D-space (Figure <a href="#fig:robotics-with-rl-examples" data-reference-type="ref" data-reference="fig:robotics-with-rl-examples">13</a>) could be based on the absolute position of the robot along the $x$ axis ($p_x$), present negative penalties for falling over (measured from $p_z$) and a introduce bonuses $\dot p_x$ for speed, $r (s_t, a_t, s_{t+1})\equiv r(s_t) = p_{x_t} \cdot \dot p_{x_t} - \tfrac{1}{p_{z_t}}$.
+
+Lastly, $\gamma \in [0,1]$ represent the discount factor regulating preference for immediate versus long-term reward (with an effective horizon equal to $\tfrac{1}{1-\gamma}$), and $\rho$ is the distribution, defined over $\mathcal S$, the MDP’s *initial* state is sampled from, $s_0 \sim \rho$.
+
+A length-$T$ *trajectory* is the (random) sequence
+``` math
+\begin{equation}
+
+    \tau = (s_0, a_0, r_0, s_1, a_1, r_1, \dots, s_{T-1}, a_{T-1}, r_{T-1}, s_T),
+\end{equation}
+```
+with per-step rewards defined as $r_t = r (s_t, a_t, s_{t+1})$ for ease of notation.Interestingly, assuming both the environment dynamics and conditional distribution over actions given states--the *policy*--to be *Markovian*: 
+$$
+`\mathbb P(s_{t+1}\vert s_t, a_t, s_{t-1}, a_{t-1}, \dots s_0, a_0 ) = \mathbb P (s_{t+1}\vert s_t, a_t)\\
+    \mathbb P(a_t\vert s_t, a_{t-1}, s_{t-1}, s_0, a_0) = \mathbb P(a_t\vert s_t) `
+$$
+ The probability of observing a given trajectory $\tau$ factorizes into
+``` math
+\begin{equation}
+
+    \mathbb P(\tau) = \mathbb P (s_0) \prod_{t=0}^{T-1} \mathbb P (s_{t+1}\vert s_t, a_t)\ \mathbb P(a_t\vert s_t).
+\end{equation}
+```
+
+Policies $\mathbb P(a_t\vert s_t)$ are typically indicated as $\pi(a_t\vert s_t)$, and often parametrized via $\theta$, yielding $\pi_\theta (a_t\vert s_t)$. Policies are trained optimizing the (discounted) *return* associated to a given $\tau$, i.e. the (random) sum of measured rewards over trajectory:
+``` math
+G(\tau) = \sum_{t=0}^{T-1} \gamma^{t} r_t.
+```
+In that, agents seek to learn control strategies (*policies*, $\pi_\theta$) maximizing the expected return $\mathbb E_{\tau \sim \pi_\theta} G(\tau)$. For a given dynamics $\mathcal D$--i.e., for a given problem--taking the expectation over the (possibly random) trajectories resulting from acting according to a certain policy provides a direct, goal-conditioned ordering in the space of all the possible policies $\Pi$, yielding the (maximization) target $J : \Pi \mapsto \mathbb R$ 
+$$
+`J(\pi_\theta) = \mathbb E_{\tau \sim \mathbb P_{\theta; \mathcal D}} [G(\tau)],\\
+    \mathbb P_{\theta; \mathcal D} (\tau) = \rho \prod_{t=0}^{T-1} \mathcal D (s_t, a_t, s_{t+1})\ \pi_\theta (a_t\vert s_t).`
+$$
+
+
+Because in the RL framework the agent is assumed to only be able to observe the environment dynamics and not to intervene on them, <a href="#eq:RL-j-function" data-reference-type="ref" data-reference="eq:RL-j-function">[eq:RL-j-function]</a> varies exclusively with the policy followed. In turn, MDPs naturally provide a framework to optimize over the space of the possible behaviors an agent might enact ($\pi \in \Pi$), searching for the *optimal policy* $\pi^* = \arg \max_{\theta} J(\pi_\theta)$, where $\theta$ is the parametrization adopted by the policy set $\Pi: \pi_\theta \in \Pi, \ \forall \theta$. Other than providing a target for policy search, $G(\tau)$ can also be used as a target to discriminate between states and state-action pairs. Given any state $s \in \mathcal S$--e.g., a given configuration of the robot--the *state-value* function
+``` math
+V_\pi(s) = \mathbb E_{\tau \sim \pi} [G(\tau) \big \vert s_0 = s]
+```
+can be used to discriminate between desirable and undesirable state in terms of long-term (discounted) reward maximization, under a given policy $\pi$. Similarily, the *state-action* value function also conditions the cumulative discounted reward on selecting action $a$ when in $s$, and thereafter act according to $\pi$:
+``` math
+Q_\pi(s,a) = \mathbb E_{\tau \sim \pi} [G (\tau) \big \vert s_0 = s, a_0=a]
+```
+Crucially, value functions are interrelated: 
+$$
+`Q_\pi(s_t, a_t) = \mathbb{E}_{s_{t+1}\sim \mathbb P(\bullet \vert s_t, a_t)} [r_t + \gamma V_\pi(s_{t+1})]\\
+    V_\pi(s_t) = \mathbb E_{a_t\sim \pi(\bullet \vert s_t)} [Q_\pi (s_t, a_t)]
+`
+$$
+ Inducing an ordering over states and state-action pairs under $\pi$, value functions are central to most RL algorithms. A variety of methods have been developed in RL as standalone attemps to find (approximate) solutions to the problem of maximizing cumulative reward (Figure <a href="#fig:rl-algos-atlas" data-reference-type="ref" data-reference="fig:rl-algos-atlas">15</a>).
+
+<ResponsiveImage
+  src={ch3_rl_algorithms_atlas}
+  zoomable
+  downloadable
+  id="fig:rl-algos-atlas"
+  layout="fixed"
+  alt="Popular RL algorithms. See @SpinningUp2018 for a complete list of citations."
+  caption={'Popular RL algorithms. See @SpinningUp2018 for a complete list of citations.'}
+/>
+
+Popular approaches to continuous state and action space--such as those studied within robotics--include @schulmanTrustRegionPolicy2017, @schulmanProximalPolicyOptimization2017, @haarnojaSoftActorCriticOffPolicy2018. Across manipulation @akkayaSolvingRubiksCube2019 and locomotion @leeLearningQuadrupedalLocomotion2020 problems, RL proved extremely effective in providing a platform to (1) adopt a unified, streamlined perception-to-action pipeline, (2) natively integrate propioperception with multi-modal high-dimensional sensor streams (3) disregard a description of the environment dynamics, by focusing on observed interaction data rather than modeling, and (4) anchor policies in the experience collected and stored in datasets. For a more complete survey of applications of RL to robotics, we refer the reader to @koberReinforcementLearningRobotics, @tangDeepReinforcementLearning2024.
+
+## Real-world RL for Robotics
+
+Streamlined end-to-end control pipelines, data-driven feature extraction and a disregard for explicit modeling in favor of interaction data are all features of RL for robotics. However, particularly in the context of real-world robotics, RL still suffers from limitations concerning machine safety and learning efficiency.
+
+First, especially early in training, <span class="text-hf-secondary">actions are typically explorative, and thus erractic</span>. On physical systems, untrained policies may command high velocities, self-collisiding configurations, or torques exceeding joint limits, leading to wear and potential hardware damage. Mitigating these risks requires external safeguards (e.g., watchdogs, safety monitors, emergency stops), often incuring in a high degree of human supervision. Further, in the typical episodic setting considered in most robotics problems, experimentation is substantially slowed down by the need to manually reset the environment over the course of training, a time-consuming and brittle process.
+
+Second, learning with a limited number of samples remains problematic in RL, <span class="text-hf-secondary">limiting the applicability of RL in real-world robotics due to consequently prohibitive timescales of training</span>. Even strong algorithms such as SAC @haarnojaSoftActorCriticOffPolicy2018 typically require a large numbers of transitions $\{ (s_t, a_t, r_t, s_{t+1})\}_{t=1}^N$. On hardware, generating these data is time-consuming and can even be prohibitive.
+
+<ResponsiveImage
+  src={ch3_duck_sim_vs_real}
+  zoomable
+  downloadable
+  id="fig:synthetic-vs-real-duck"
+  layout="fixed"
+  alt="Simulated (left) vs. real-world (right) OpenDuck. Discrepancies in the simulation dynamics (reality ..."
+  caption={'Simulated (left) vs. real-world (right) OpenDuck. Discrepancies in the simulation dynamics (reality gap) pose risks to policy transfer.'}
+/>
+
+Training RL policies in simulation @tobinDomainRandomizationTransferring2017 addresses both issues: it eliminates physical risk and dramatically increases throughput. Yet, simulators require significant modeling effort, and rely on assumptions (simplified physical modeling, instantaneous actuation, static environmental conditions, etc.) limiting transferring policies learned in simulation due the discrepancy between real and simulated environments (*reality gap*, Figure <a href="#fig:synthetic-vs-real-duck" data-reference-type="ref" data-reference="fig:synthetic-vs-real-duck">16</a>). *Domain randomization* (DR) is a popular technique to overcome the reality gap, consisting in randomizing parameters of the simulated environment during training, to induce robustness to specific disturbances. In turn, DR is employed to increase the diversity of scenarios over the course of training, improving on the chances sim-to-real transfer @akkayaSolvingRubiksCube2019, @antonovaReinforcementLearningPivoting2017, @jiDribbleBotDynamicLegged2023. In practice, DR is performed further parametrizing the *simulator*’s dynamics $\mathcal D \equiv \mathcal D_\xi$ with a *dynamics* (random) vector $\xi$ drawn an arbitrary distribution, $\xi \sim \Xi$. Over the course of training--typically at each episode’s reset--a new $\xi$ is drawn, and used to specify the environment’s dynamics for that episode. For instance, one could decide to randomize the friction coefficient of the surface in a locomotion task (Figure <a href="#fig:ducks-on-terrains" data-reference-type="ref" data-reference="fig:ducks-on-terrains">17</a>), or the center of mass of an object for a manipulation task.
+
+<ResponsiveImage
+  src={ch3_many_ducks}
+  zoomable
+  downloadable
+  id="fig:ducks-on-terrains"
+  layout="fixed"
+  alt="The same locomotion task can be carried out in different (simulated) domains (exemplified by the dif..."
+  caption={'The same locomotion task can be carried out in different (simulated) domains (exemplified by the difference in terrains) at training time, resulting to increased robustness over diverse environment dynamics.'}
+/>
+
+While effective in transfering policies across the reality gap in real-world robotics @tobinDomainRandomizationTransferring2017, @akkayaSolvingRubiksCube2019, @jiDribbleBotDynamicLegged2023, @tiboniDomainRandomizationEntropy2024, DR often requires extensive manual engineering. First, identifying which parameters to randomize--i.e., the *support* $\text{supp} (\Xi)$ of $\Xi$--is an inherently task specific process. When locomoting over different terrains, choosing to randomize the friction coefficient is a reasonable choice, yet not completely resolutive as other factors (lightning conditions, external temperature, joints’ fatigue, etc.) may prove just as important, making selecting these parameters yet another source of brittlness.
+
+Selecting the dynamics distribution $\Xi$ is also non-trivial. On the one hand, distributions with low entropy might risk to cause failure at transfer time, due to the limited robustness induced over the course of training. On the other hand, excessive randomization may cause over-regularization and hinder performance. Consequently, the research community investigated approaches to automatically select the randomization distribution $\Xi$, using signals from the training process or tuning it to reproduce observed real-world trajectories.  @akkayaSolvingRubiksCube2019 use a parametric uniform distribution $\mathcal U(a, b)$ as $\Xi$, widening the bounds as training progresses and the agent’s performance improves (AutoDR). While effective, AutoDR requires significant tuning--the bounds are widened by a fixed, pre-specified amount $\Delta$--and may disregard data when performance *does not* improve after a distribution update @tiboniDomainRandomizationEntropy2024.  @tiboniDomainRandomizationEntropy2024 propose a similar method to AutoDR (DORAEMON) to evolve $\Xi$ based on training signal, but with the key difference of explicitly maximizing the entropy of parametric Beta distributions, inherently more flexible than uniform distributions. DORAEMON proves particularly effective at dynamically increasing the entropy levels of the training distribution by employing a max-entropy objective, under performance constraints formulation. Other approaches to automatic DR consist in specifically tuning $\Xi$ to align as much as possible the simulation and real-world domains. For instance,  @chebotar2019closing interleave in-simulation policy training with repeated real-world policy rollouts used to adjust $\Xi$ based on real-world data, while  @tiboniDROPOSimtoRealTransfer2023 leverage a single, pre-collected set of real-world trajectories and tune $\Xi$ under a simple likelihood objective.
+
+While DR has shown promise, it does not address the main limitation that, even under the assumption that an ideal distribution $\Xi$ to sample from was indeed available, many robotics problems <span class="text-hf-secondary">cannot be simulated with high-enough fidelity under practical computational constraints</span> in the first place. Simulating contact-rich manipulation of possibly deformable or soft materials--i.e., *folding a piece of clothing*--can be costly and even time-intensive, limiting the benefits of in-simulation training.
+
+A perhaps more foundamental limitation of RL for robotics is the general unavailability of complicated tasks’ *dense* reward function, the design of which is essentially based on human expertise and trial-and-error. In practice, *sparse* reward functions can be used to conclude whether one specific goal has been attained--*has this t-shirt been correctly folded?*--but unfortunately incur in more challenging learning. As a result, despite notable successes, deploying RL directly on real-world robots at scale remains challenging.
+
+To make the most of (1) the growing number of openly available datasets and (2) relatively inexpensive robots like the SO-100, RL could (1) be anchored in already-collected trajectories--limiting erratic and dangerous exploration--and (2) train in the real-world directly--bypassing the aforementioned issues with low-fidelity simulations. In such a context, sample-efficient learning is also paramount, as training on the real-world is inherently time-bottlenecked.
+
+Off-policy algorithms like Soft Actor-Critic (SAC) @haarnojaSoftActorCriticOffPolicy2018 tend to be more sample efficient then their on-policy counterpart @schulmanProximalPolicyOptimization2017, due to the presence a *replay buffer* used over the course of the training. Other than allowing to re-use transitions $(s_t, a_t, r_t, s_{t+1})$ over the course of training, the replay buffer can also accomodate for the injection of previously-collected data in the training process @ballEfficientOnlineReinforcement2023. Using expert demonstrations to guide learning together with learned rewards, RL training can effectively be carried out in the real-world @luoSERLSoftwareSuite2025. Interestingly, when completed with in-training human interventions, real-world RL agents have been shown to learn policies with near-perfect success rates on challenging manipulation tasks in 1-2 hours @luoPreciseDexterousRobotic2024.
+
+#### Sample-efficient RL
+
+In an MDP, the optimal policy $\pi^*$ can be derived from its associated $Q$-function, $Q_{\pi^*}$, and in particular the optimal action(s) $\mu(s_t)$ can be selected maximizing the optimal $Q$-function over the action space,
+``` math
+\mu(s_t) = \max_{a_t\in \mathcal A} Q_{\pi^*}(s_t, a_t).
+```
+Interestingly, the $Q^*$-function satisfies a recursive relationship (*Bellman equation*) based on a very natural intuition [^2]:
+
+> \[...\] If the optimal value $Q^*(s_{t+1}, a_{t+1})$ of the \[state\] $s_{t+1}$ was known for all possible actions $a_{t+1}$, then the optimal strategy is to select the action $a_{t+1}$ maximizing the expected value of $r_t + \gamma Q^*(s_{t+1}, a_{t+1})$
+> ``` math
+> Q^*(s_t, a_t) = \mathbb E_{s_{t+1} \sim \mathbb P(\bullet \vert s_t, a_t)} [r_t + \gamma \max_{a_{t+1} \in \mathcal A} Q^*(s_{t+1}, a_{t+1}) \big\vert s_t, a_t]
+> ```
+
+In turn, the optimal $Q$-function  is guaranteed to be self-consistent by definition. *Value-iteration* methods exploit this relationship (and/or its state-value counterpart, $V^*(s_t)$ ) by iteratively updating an initial estimate of $Q^*$, $Q_k$ using the Bellman equation as update rule (*Q-learning*):
+``` math
+Q_{i+1}(s_t, a_t) \leftarrow \mathbb E_{s_{t+1} \sim \mathbb P(\bullet \vert s_t, a_t)} [r_t + \gamma \max_{a_{t+1} \in \mathcal A} Q_i (s_{t+1}, a_{t+1}) \big\vert s_t, a_t],  \quad i=0,1,2,\dots,K
+```
+Then, one can derive the (ideally, near-optimal) policy by explicitly maximizing over the action space the final (ideally, near-optimal) estimate $Q_K \approx Q^*$ at each timestep. In fact, under certain assumptions on the MDP considered, $Q_K \to Q^* \, \text{as } K \to \infty$.
+
+Effective in its early applications to small-scale discrete problems and theoretically sound, vanilla Q-learning was found complicated to scale to large $\mathcal S\times \mathcal A$ problems, in which the storing of $Q : \mathcal S\times \mathcal A\mapsto \mathbb R$ alone might result prohibitive. Also, vanilla Q-learning is not directly usable for *continuous*, unstructured state-action space MPDs, such as those considered in robotics. In their seminal work on *Deep Q-Learning* (DQN), @mnihPlayingAtariDeep2013 propose learning Q-values using deep convolutional neural networks, thereby accomodating for large and even unstructured *state* spaces. DQN parametrizes the Q-function using a neural network with parameters $\theta$, updating the parameters by sequentially minimizing the expected squared temporal-difference error (TD-error, $\delta_i$): 
+$$
+`\mathcal L(\theta_i) = \mathbb E_{(s_t, a_t) \sim \chi(\bullet)} 
+    \big[ 
+        (\underbrace{y_i - Q_{\theta_i}(s_t, a_t)}_{\delta_i})^2 
+    \big],\\
+    y_i = \mathbb E_{s_{t+1} \sim \mathbb P(\bullet \vert s_t, a_t)} \big[ r_t + \gamma \max_{a_t\in \mathcal A} Q_{\theta_{i-1}} (s_{t+1}, a_{t+1}) \big], `
+$$
+ Where $\chi$ represents a behavior distribution over state-action pairs. Crucially, $\chi$ can in principle be different from the policy being followed, effectively allowing to reuse prior data stored in a *replay buffer* in the form of $(s_t, a_t, r_t, s_{t+1})$ transitions, used to form the TD-target $y_i$, TD-error $\delta_i$ and loss function <a href="#eq:dqn-loss" data-reference-type="ref" data-reference="eq:dqn-loss">[eq:dqn-loss]</a> via Monte-Carlo (MC) estimates.
+
+While effective in handling large, unstructured state spaces for discrete action-space problems, DQN application’s to continous control problems proved challenging. Indeed, in the case of high-capacity function approximators such as neural networks, solving $\max_{a_t \in \mathcal A} Q_\theta(s_t, a_t)$ at each timestep is simply unfeasible due to the (1) continous nature of the action space ($\mathcal A\subset \mathbb R^n$ for some $n$) and (2) impossibility to express the find a cheap (ideally, closed-form) solution to $Q_\theta$.  @silverDeterministicPolicyGradient2014 tackle this fundamental challenge by using a *deterministic* function of the state $s_t$ as policy, $\mu_\phi(s_t) = a_t$, parametrized by $\phi$. Thus, policies can be iteratively refined updating $\phi$ along the direction:
+``` math
+\begin{equation}
+
+    d_\phi = \mathbb E_{s_t \sim \mathbb P (\bullet)} [\nabla_\phi Q(s_t, a_t)\vert_{a_t = \mu_\phi(s_t)}] = \mathbb E_{s_t \sim \mathbb P(\bullet)} [\nabla_{a_t} Q(s_t, a_t) \vert_{a_t = \mu_\phi(s_t)} \cdot \nabla_\phi \mu(s_t)]
+\end{equation}
+```
+Provably, <a href="#eq:deterministic-pg" data-reference-type="ref" data-reference="eq:deterministic-pg">[eq:deterministic-pg]</a> is the *deterministic policy gradient* (DPG) of the policy $\mu_\phi$ @silverDeterministicPolicyGradient2014, so that updates $\phi_{k+1}\leftarrow \phi_k + \alpha d_\phi$ are guaranteed to increase the (deterministic) cumulative discounted reward, $J(\mu_\phi)$.  @lillicrapContinuousControlDeep2019 extended DPG to the case of (1) high-dimensional unstructured observations and (2) continuous action spaces, introducing Deep Deterministic Policy Gradient (DDPG), an important algorithm RL and its applications to robotics. DDPG adopts a modified TD-target compared to the one defined in <a href="#eq:TD-target" data-reference-type="ref" data-reference="eq:TD-target">[eq:TD-target]</a>, by maintaining a policy network used to select actions, yielding
+``` math
+\begin{equation}
+
+y_i = \mathbb E_{s_{t+1} \sim \mathbb P(\bullet \vert s_t, a_t)} \big[ r_t + \gamma Q_{\theta_{i-1}} (s_{t+1}, \mu_\phi(s_{t+1})) \big] .
+\end{equation}
+```
+Similarily to DQN, DDPG also employs the same replay buffer mechanism, to reuse past transitions over training for increased sample efficiency and estimate the loss function via MC-estimates.
+
+Soft Actor-Critic (SAC) @haarnojaSoftActorCriticOffPolicy2018 is a derivation of DDPG in the max-entropy (MaxEnt) RL framework, in which RL agents are tasked with <span class="text-hf-secondary">maximizing the discounted cumulative reward, while acting as randomly as possible</span>. MaxEnt RL @haarnojaReinforcementLearningDeep2017 has proven particularly robust thanks to the development of diverse behaviors, incentivized by its entropy-regularization formulation. In that, MaxEnt revisits the RL objective $J (\pi)$ to specifically account for the policy entropy, $J(\pi) = \sum_{t=0}^T \mathbb{E}_{(s_t, a_t) \sim \chi} [r_t + \alpha \mathcal H(\pi (\bullet \vert s_t))] $ This modified objective results in the *soft* TD-target:
+``` math
+\begin{equation}
+
+    y_i = \mathbb E_{s_{t+1} \sim \mathbb P( \bullet \vert s_t, a_t)} [r_t + \gamma \left( Q_{\theta_{i-1}} (s_{t+1}, a_{t+1}) - \alpha \log \pi_\phi(a_{t+1} \vert s_{t+1}) \right)], \quad a_{t+1} \sim \pi_\phi(\bullet \vert s_t)
+\end{equation}
+```
+Similarily to DDPG, SAC also maintains an explicit policy, trained under the same MaxEnt framework for the maximization of <a href="#eq:J-soft" data-reference-type="ref" data-reference="eq:J-soft">[eq:J-soft]</a>, and updated using:
+``` math
+\begin{equation}
+
+    \pi_{k+1} \leftarrow \arg\min_{\pi^\prime \in \Pi} \text{D}_{\text{KL}}\left(\pi^\prime (\bullet \vert s_t) \bigg\Vert \frac{\exp(Q_{\pi_k}(s_t, \bullet))}{Z_{\pi_k}(s_t)} \right)
+\end{equation}
+```
+The update rule provided in <a href="#eq:sac-policy-update" data-reference-type="ref" data-reference="eq:sac-policy-update">[eq:sac-policy-update]</a> optimizes the policy while projecting it on a set $\Pi$ of tractable distributions (e.g., Gaussians, @haarnojaReinforcementLearningDeep2017).
+
+#### Sample-efficient, data-driven RL
+
+Importantly, sampling $(s_t, a_t, r_t, s_{t+1})$ from the replay buffer $D$ conveniently allows to approximate the previously introduced expectations for TD-target and TD-error through Monte-Carlo (MC) estimates. The replay buffer $D$ also proves extremely useful in maintaining a history of previous transitions and using it for training, improving on sample efficiency. Furthermore, it also naturally provides an entry point to inject offline trajectories recorded, for instance, by a human demonstrator, into the training process.
+
+Reinforcement Learning with Prior Data (RLPD) @ballEfficientOnlineReinforcement2023 is an Offline-to-Online RL algorithm leveraging prior data to effectively accelerate the training of a SAC agent. Unlike previous works on Offline-to-Online RL, RLPD avoids any pre-training and instead uses the available offline data $D_\text{offline}$ to improve online-learning from scratch. During each training step, transitions from both the offline and online replay buffers are sampled in equal proportion, and used in the underlying SAC routine.
+
+#### Sample-efficient, data-driven, real-world RL
+
+Despite the possibility to leverage offline data for learning, the effectiveness of real-world RL training is still limited by the need to define a task-specific, hard-to-define reward function. Further, even assuming to have access to a well-defined reward function, typical robotics pipelines rely mostly on propioperceptive inputs augmented by camera streams of the environment. As such, even well-defined rewards would need to be derived from processed representations of unstructured observations, introducing brittleness. In their technical report, @luoSERLSoftwareSuite2025 empirically address the needs (1) to define a reward function and (2) to use it on image observations, by introducing a series of tools to allow for streamlined training of *reward classifiers* $c$, as well as jointly learn forward-backward controllers to speed up real-world RL. Reward classifiers are particularly useful in treating complex tasks--e.g., folding a t-shirt--for which a precise reward formulation is arbitrarily complex to obtain, or that do require significant shaping and are more easily learned directly from demonstrations of success ($e^+$) or failure ($e^-$) states, $s \in \mathcal S$, with a natural choice for the state-conditioned reward function being $r \mathcal S \mapsto \mathbb R$ being $r(s) = \log c(e^+ \ vert s )$. Further, @luoSERLSoftwareSuite2025 demonstrate the benefits of learning *forward* (executing the task from initial state to completion) and *backward* (resetting the environment to the initial state from completion) controllers, parametrized by separate policies.
+
+Lastly, in order to improve on the robustness of their approach to different goals while maintaing practical scalability, @luoSERLSoftwareSuite2025 introduced a modified state and action space, expressing proprioperceptive configurations $q$ and actions $\dot q$ in the frame of end-effector pose at $t=0$. Randomizing the initial pose of the end-effector ($s_0$),@luoSERLSoftwareSuite2025 achieved a similar result to that of having to manually randomize the environment at every timestep, but with the benefit of maintaining the environment in the same condition across multiple training episodes, achieving higher scalability of their method thanks to the increased practicality of their approach.
+
+<ResponsiveImage
+  src={ch3_hil_serl_examples}
+  zoomable
+  downloadable
+  id="fig:hil-serl-blocks"
+  layout="fixed"
+  alt="(A) HIL-SERL allows for real-world training of high performance RL agents by building on top advance..."
+  caption={'(A) HIL-SERL allows for real-world training of high performance RL agents by building on top advancements presented by of SAC, RLPD and SERL. (B) Example of human intervention during a HIL-SERL training process on a SO-100.'}
+/>
+
+Building on off-policy deep Q-learning with replay buffers, entropy regularization for better exploration and performance, expert demonstrations to guide learning, and a series of tools and recommendations for real-world training using reward classifiers (Figure <a href="#fig:hil-serl-blocks" data-reference-type="ref" data-reference="fig:hil-serl-blocks">18</a>), @luoPreciseDexterousRobotic2024 introduce human interactions during training, learning near-optimal policies in challenging real-world manipulation tasks in 1-2 hours.
+
+Human in the Loop Sample Efficient Robot reinforcement Learning (HIL-SERL) @luoPreciseDexterousRobotic2024 augments offline-to-online RL with targeted human corrections during training, and employs prior data to (1) train a reward classifier and (2) bootstrap RL training on expert trajectories. While demonstrations provide the initial dataset seeding learning and constraining early exploration, interactive corrections allow a human supervisor to intervene on failure modes and supply targeted interventions to aid the learning process. Crucially, human interventions are stored in both the offline and online replay buffers, differently from the autonomous transitions generated at training time and stored in the online buffer only. Consequently, given an intervention timestep $k \in (0, T)$, length-$K$ human intervention data $\{ s^{\text{human}}_k, a^{\text{human}}_k, r^{\text{human}}_k, s^{\text{human}}_{k+1},\}_{k=1}^K$ is more likely to be sampled for off-policy learning than the data generated online during training, providing stronger supervision to the agent while still allowing for autonomous learning. Empirically, HIL-SERL attains near-perfect success rates on diverse manipulation tasks within 1-2 hours of training @luoPreciseDexterousRobotic2024, underscoring how offline datasets with online RL can markedly improve stability and data efficiency, and ultimately even allow real-world RL-training.
+
+### Code Example: Real-world RL
+
+**TODO(fracapuano): work out rl training example**
+
+### Limitations of RL in Real-World Robotics: Simulators and Reward Design
+
+Despite the advancements in real-world RL training, solving robotics training RL agents in the real world still suffers from the following limitations:
+
+- In those instances where real-world training experience is prohibitively expensive to gather @degraveMagneticControlTokamak2022, @bellemareAutonomousNavigationStratospheric2020, in-simulation training is often the only option. However, high-fidelity simulators for real-world problems can be difficult to build and maintain, especially for contact-rich manipulation and tasks involving deformable or soft materials.
+
+- Reward design poses an additional source of brittleness. Dense shaping terms are often required to guide exploration in long-horizon problems, but poorly tuned terms can lead to specification gaming or local optima. Sparse rewards avoid shaping but exacerbate credit assignment and slow down learning. In practice, complex behaviors require efforts shaping rewards: a britlle and error prone process.
+
+Advances in Behavioral Cloning (BC) from corpora of human demonstrations address both of these concerns. By learning in a supervised fashion to reproduce expert demonstrations, BC methods prove competitive while bypassing the need for simulated environments and hard-to-define reward functions.
+
+# Robot (Imitation) Learning