---
title: 'MoDeSuite: Mobile Deformable Manipulation Benchmark'
url: https://www.emergentmind.com/topics/modesuite
type: topic
---

# MoDeSuite: Mobile Deformable Manipulation Benchmark

Searching arXiv for papers relevant to “MoDeSuite” and closely related uses of the term.
MoDeSuite most explicitly denotes the **Mobile Manipulation Deformable Object task suite** introduced as a benchmark for robot learning in mobile manipulation with elastic and deformable objects. It is presented as the first Mobile Manipulation Deformable Object task suite, with eight tasks, dual physics models for elastic and plastic materials, multimodal observations, and evaluation on both wheeled and legged mobile manipulators, including direct sim-to-real deployment on Spot [2507.21796]. The same label also has distinct meanings in adjacent arXiv material: it is used as a **Mobility-on-Demand Design Suite** in multimodal transport system design [1805.06094], and it is a plausible but non-original suite label for mode-based modeling and verification workflows built around MDM, modal reactors, or modal object diagrams, where the papers themselves do not use the name [1207.0922; 1301.0046; 2301.09597; 1409.2353].

## 1. Canonical usage in robot learning

In its explicit arXiv usage, MoDeSuite is a benchmark for **mobile manipulation with deformable objects**, targeting a gap left by suites centered on rigid-object manipulation or stationary manipulators. The benchmark is motivated by the combined difficulty of nonrigid object dynamics and whole-body robot coordination: deformables introduce state- and action-dependent shape variability, large deformations, partial observability, and contact-rich interactions, while mobile manipulation couples locomotion and arm control so that base motion changes grasp geometry, contact forces, and sensor viewpoints. Within this framing, task success requires coordinated use of the robot base and manipulator and, crucially, deliberate exploitation of object compliance rather than treating deformability as disturbance [2507.21796].

The suite is positioned against two existing families of environments. On one side are rigid-object or mostly stationary-manipulator benchmarks such as ManiSkill, AI2-THOR/Habitat, and robosuite. On the other are deformable-object environments such as SoftGym, Reform, and PlasticineLab, which lack mobile bases or focus on end-effector-only control. MoDeSuite’s distinguishing combination is therefore mobility plus deformable-object physics plus standardized observation/action interfaces in tasks where success depends on bending, stretching, lifting, draping, or displacing compliant materials [2507.21796].

A central implication is that MoDeSuite benchmarks not only manipulation quality, but also **morphology-aware coordination**. The results reported for wheeled and legged platforms show that locomotion embodiment materially changes task difficulty, especially in constrained spaces and under tension, which suggests that the suite is as much a testbed for integrated autonomy architectures as for manipulation policies narrowly construed.

## 2. Formalization, platforms, and simulation stack

MoDeSuite formulates mobile deformable manipulation as a Markov decision process. In the state-based setup, observations are defined as

$$
O_t = (s_{r,t}, s_{o,t}, s_{e,t}),
$$

where the robot state is

$$
s_r = (p_r, q_r, q, \dot{q}),
$$

with $p_r \in \mathbb{R}^2$ the base position, $q_r \in \mathbb{R}^4$ the base orientation quaternion, $q \in \mathbb{R}^n$ the manipulator joint positions, and $\dot{q} \in \mathbb{R}^n$ the joint velocities. Elastic object state is represented by FEM node positions $\{e_i \in \mathbb{R}^3\}_{i=1}^N$, while plastic object state is represented by particle positions $\{p_i \in \mathbb{R}^3\}_{i=1}^M$. The environment state is given as $(g_r, g_o, p_o) \in \mathbb{R}^3 \times \mathbb{R}^3 \times \mathbb{R}^3$, encoding robot and object goals and obstacle position(s). In the image-based setup, observations are defined as

$$
O_t = s_{env,t} = \phi(I_t),
$$

where $I_t$ is RGB input and $\phi$ is the DiNOv2 encoder. The RL objective is the standard discounted return

$$
J(\pi) = \mathbb{E}_{\tau \sim \pi}\left[\sum_{t=0}^{T-1}\gamma^t r_t\right], \qquad \gamma \in (0,1).
$$

These definitions make explicit that the suite supports both fully state-based and vision-based learning regimes [2507.21796].

The action space is equally hybrid. For wheeled systems, the base action is $a_{base}=(v_x,v_y,w_z)$ and the arm action is either joint-space or $SE(3)$ end-effector control. For the legged Spot platform, the base action is either 12 joint commands or $(p_x,p_y,r_z)$ through a locomotion controller, with the arm again controlled in joint space or in $SE(3)$. A discrete 14-action keyboard teleoperation interface is also provided, spanning base translations and rotations, hand Cartesian motions, and grasp/release commands [2507.21796].

The software and physics stack is built in **Isaac Lab** and **Isaac Sim** within NVIDIA Omniverse, using **NVIDIA PhysX 5** soft-body support. Elastic objects are modeled with FEM tetrahedral meshes, while plastic deformables are modeled as PBD particle systems. The suite supports RGB, depth, and state observations; GPU-parallel training; and two robot configurations, namely Franka+Ridgeback and Spot+Arm. Simulation runs at approximately 60 Hz, while the real Spot deployments reported in the paper run at approximately 10 Hz [2507.21796].

## 3. Task taxonomy and reward structure

MoDeSuite contains eight tasks divided into elastic/FEM and plastic/PBD categories [2507.21796].

| Task | Physics/object | Goal |
|---|---|---|
| Place | Elastic rod, FEM | Put rod endpoint on tabletop beyond nominal arm reach |
| Bend | Elastic rod, FEM | Move rod through an L-shaped narrow corridor |
| Transport | Elastic rod, FEM | Reach final target via intermediate waypoint around obstacle |
| Drag | Elastic belt, FEM | Move belt midpoint over obstacle while base stays near body target |
| Lift | Elastic belt, FEM | Raise belt to create passage, then move base through |
| Uncover | Cloth, PBD | Remove table cover by grasping and pulling |
| Cover | Fabric, PBD | Drape cloth to cover gap between two cubes |
| Curtain | Hanging curtain, PBD | Move curtain aside and drive through opening |

The five elastic tasks use dense distance-based rewards with a stability penalty. For example, **Place** is defined by

$$
r_t = - d_{end,table}(t) - d_{base,table}(t) - \lambda s_t,
$$

with success when the endpoint distance threshold is satisfied. **Bend**, **Drag**, and **Lift** use analogous formulations with task-specific target distances, while **Transport** sums endpoint and base distances to both intermediate and final targets. In all such cases, $\lambda \ge 0$ weights a stability penalty that is zero for wheeled robots and positive for legged robots. This reward family makes explicit that the benchmark is evaluating not only manipulation outcome, but also locomotion-conditioned object placement and platform stability [2507.21796].

The three plastic tasks instead use sparse binary rewards: $r=1$ on success and $0$ otherwise. **Uncover** requires that the cover be fully removed and the handle pulled beyond the far table edge. **Cover** requires that the gap be covered and the fabric handle moved to the other cube. **Curtain** requires collision-free passage beyond the curtain. These sparse formulations materially increase horizon and exploration difficulty and make perception quality more important, because success depends on subtle cloth states, occlusions, and contact outcomes not directly decomposed into shaped geometric subgoals [2507.21796].

Across the task set, the benchmark repeatedly tests two coupled capabilities. The first is **base–manipulator coordination**: base motion must reshape the reachable workspace and stabilize interaction. The second is **functional use of deformability**: rods must be bent to pass corners, belts stretched or lifted to traverse obstacles, and fabric draped or displaced without entanglement or collision. This suggests that MoDeSuite is designed to expose failure modes of policies that treat the base and arm as separable controllers or that rely on rigid-body intuitions in nonrigid environments.

## 4. Baselines, training protocol, and empirical performance

The suite evaluates two RL methods and two imitation-learning methods. The RL baselines are **PPO** and **SAC**, implemented through RL Games for GPU training. The imitation baselines are **Behavior Cloning** and a **Retrieval-based method** using state similarity and DiNOv2 visual features from DeMoBot. For elastic tasks, RL policies use state-based observations, including positions of four points along elastic objects. For plastic tasks, imitation methods use purely image-based observations encoded by DiNOv2. The reported protocol uses 5 independent seeds per RL algorithm and task, 20-trial evaluation per trained agent, and 30 demonstrations per plastic task for imitation learning [2507.21796].

The paper reports that **PPO generally outperforms SAC** across robot platforms and tasks, with a notable exception on **Bend with Spot**, where collisions and loss of balance cause failures. The elastic tasks are described as solvable but challenging. For the image-based plastic tasks, the reported success rates over 20 trials are: **Behavior Cloning** at 85% for Uncover, 60% for Cover, and 60% for Curtain; and **Retrieval** at 90% for Uncover, 80% for Cover, and 80% for Curtain. These figures show that even demonstration-based methods trained on only 30 trajectories can perform competitively in simulation, although task difficulty differs sharply across cloth-manipulation scenarios [2507.21796].

The sim-to-real results on Spot are especially central to the suite’s empirical identity. For **Place**, SAC achieves 90% success in simulation with 217.6 steps and 90% success in reality with 172.1 steps, while PPO achieves 100% success in simulation with 83.4 steps and 100% success in reality with 62.6 steps. For **Drag**, SAC achieves 10% success in simulation with 92.5 steps and 0% success in reality, with unsafe motions disallowed by hardware safety constraints; PPO achieves 100% success in simulation with 81.3 steps and 100% success in reality with 32.9 steps. These results indicate strong sim-to-real alignment for state-based elastic tasks, but also show that physically acceptable action distributions on hardware may invalidate policies that rely on aggressive behaviors tolerated in simulation [2507.21796].

By contrast, **Curtain** exposes a substantial visual transfer problem. Policies trained in simulation do not solve the real task; the Retrieval policy only approaches or contacts the curtain in 2 of 10 trials, and Behavior Cloning fails to reach the curtain. The paper attributes this to a strong visual domain gap, supported by t-SNE analysis of DiNOv2 embeddings showing separation between simulated and real observations despite similar state trajectories under teleoperation. A plausible implication is that, within MoDeSuite, state-based deformable control and vision-based deformable control probe fundamentally different bottlenecks rather than merely different sensor front ends [2507.21796].

## 5. Limitations, open problems, and methodological significance

Several limitations are explicit in the reported benchmark. Object dimensions, material properties such as Young’s modulus and Poisson’s ratio, and friction coefficients are not specified in the paper, even though elastic objects are modeled with FEM and cloth with PBD. Programmatic object parameterization is not yet exposed, although adjustable object sizes are available through the Isaac Sim GUI and future programmatic APIs are planned. The paper also reports no ablation studies on removing base control, varying material properties, or isolating individual reward components [2507.21796].

The benchmark nonetheless clarifies several methodological directions. One is the importance of **state-based policies for sim-to-real robustness** in elastic tasks. Another is the need for **domain adaptation or richer multimodal sensing** in image-based cloth manipulation, where DiNOv2 alone does not close the simulation-to-reality gap. The paper also points toward **hierarchical policies**, **dynamics models for elasto-plastic objects**, **safe RL with stability-aware constraints**, and **curricula or intermediate goals** for sparse long-horizon tasks such as Cover, Uncover, and Curtain [2507.21796].

From a benchmarking perspective, MoDeSuite is significant because it treats mobility, manipulation, deformability, and transfer as a coupled evaluation problem. The reported morphology effects—legged platforms being harder in constrained corridors and under belt tension—imply that benchmark outcomes cannot be reduced to arm dexterity alone. This suggests a broader research role for the suite: it can function as a comparative testbed for whole-body policy architectures, contact-aware planning, and representations of nonrigid dynamics under embodiment constraints.

## 6. Other uses and reinterpretations of the name

The term **MoDeSuite** is not unique to the robot-learning benchmark in the broader provided material. A distinct usage expands it as **Mobility-on-Demand Design Suite**, describing an integrated modeling–optimization environment that couples a behavioral mode-choice model, an operational simulator for multiple MoD services and public transit, and a Bayesian Optimization outer loop for fleet sizes and fares/discounts. In that setting, the decision variables are $x=(n_1,n_4,n_{10},\gamma_4,\gamma_{10})$, the mode-choice model is MNL, convergence is defined by a mode-share fixed point with stopping rule $Z^n < 0.01$, and BO with a Gaussian Process surrogate and GP-UCB acquisition is used to optimize operator profit under multimodal equilibrium [1805.06094].

Several other papers are relevant because they are sometimes interpretable as **suite-like foundations**, even though they do not themselves use the name. The MDM papers introduce the **Mode Diagram Modeling Framework** for periodic control systems together with a property specification language based on interval logic and verification via statistical model checking; the provided descriptions state that if “MoDeSuite” is used as a tool-suite label in that context, it corresponds directly to these three tightly coupled elements [1207.0922; 1301.0046]. The **Modal Reactors** paper likewise does not mention MoDeSuite, but its mode semantics, runtime machinery, and visualization affordances are described as directly underpinning a mode-based design suite built on Lingua Franca [2301.09597]. The **Modal Object Diagrams** paper also does not use the name, yet its language, Alloy-based verification reduction, and prototype Eclipse plug-in are presented as the core capabilities one would expect in a structural specification and verification suite [1409.2353].

| Usage of “MoDeSuite” | Source | Status of the name |
|---|---|---|
| Mobile Manipulation Deformable Object task suite | [2507.21796] | Explicit title and primary usage |
| Mobility-on-Demand Design Suite | [1805.06094] | Explicit expansion in provided description |
| Suite label for MDM + interval logic + SMC | [1207.0922], [1301.0046] | Interpretive; papers use “MDM,” not “MoDeSuite” |
| Suite label for modal reactors or modal object diagrams workflows | [2301.09597], [1409.2353] | Interpretive; papers do not use the term |

Because of this polysemy, the unqualified name “MoDeSuite” requires domain disambiguation. In robotics, it refers to the deformable-object mobile-manipulation benchmark [2507.21796]. In transportation, it denotes a multimodal Mobility-on-Demand design environment [1805.06094]. In formal methods, it is best treated as an expository shorthand for suite-like combinations of modeling, property specification, verification, and tooling rather than as the original terminology of the cited papers [1207.0922; 1301.0046; 2301.09597; 1409.2353].

Source: https://www.emergentmind.com/topics/modesuite