Cloud Robotic Manipulation Overview

• Cloud robotic manipulation is a paradigm that integrates robotic control with cloud and edge computing resources for enhanced perception, planning, and federated learning.
• It enables robots to offload intensive tasks like motion planning, SLAM, and grasp analysis, optimizing performance and leveraging shared data across fleets.
• Service infrastructures such as SRCA and FogROS demonstrate improved latency and scalability while ensuring that time-critical control loops remain local for safety.

Cloud robotic manipulation denotes robotic manipulation systems whose perception, planning, learning, and sometimes control are tightly integrated with a cloud–edge computing infrastructure, so that robots performing grasping, pushing, picking, rearranging, and related operations can offload heavy computation, share models and experience across fleets, and exploit elastic compute and storage beyond onboard resources (Zaland et al., 23 Jul 2025). In this formulation, robots commonly retain latency-critical control loops locally, while cloud and edge services support perception, planning, policy learning, simulation, teleoperation, and large-scale evaluation; the resulting paradigm spans cloud-hosted manipulation services, federated learning across distributed robots, cloud-based testbeds and competitions, and cloud–edge schemes for latency-sensitive continuous control (Zaland et al., 23 Jul 2025).

1. Definition and architectural scope

Cloud robotic manipulation is grounded in a standard manipulation view of “making an intentional change to the environment” through operations such as pushing, grasping, picking, and rearranging, but extends that view by coupling manipulation pipelines to cloud and edge resources (Zaland et al., 23 Jul 2025). The core architectural distinction is the “cloud–edge continuum”: cloud resources provide virtually unlimited compute and storage suitable for heavy training, centralized knowledge bases, and large-scale simulation; edge resources or “cloudlets” provide nearby computation with lower latency than a remote cloud and can preprocess high-bandwidth streams such as raw video and point clouds before further transmission (Zaland et al., 23 Jul 2025). In typical deployments, latency-critical control and safety checks remain local to the robot, whereas learned perception, motion planning, or policy inference may be served from edge or cloud components (Zaland et al., 23 Jul 2025).

Several system frameworks operationalize this division of labor. SRCA, the “Scalable Robotic Cloud Agents” architecture, uses a three-layer design consisting of a Kubernetes cluster, an access and management layer implemented in NodeJS, and a client layer that exposes robotic services through auto-generated API clients and HTTP endpoints (Remmas et al., 2018). Its design is explicitly intended to host “path planning” and “kinematic solvers,” alongside SLAM, object detection/recognition, and human skeleton detection, all of which are directly relevant to manipulation pipelines (Remmas et al., 2018). Cloudroid similarly turns existing ROS packages into Internet-accessible cloud services without changing package code, by deploying each package inside a Docker “servant,” exposing ROS topics and services through a Service Portal and automatically generated service stubs, and using a Choreographer with Docker Swarm for lifecycle and resource management (Hu et al., 2017). FogROS extends ROS in the same general direction by allowing selected nodes to be placed on cloud or fog hardware through launch-file configuration while leaving the ROS programming model unchanged (Kaiyuan et al., 2021).

These architectures make a clear distinction between manipulation functions that tolerate network delays and those that do not. SRCA states that a Pod “cannot handle real time motion control or visual assisted manipulation,” and is therefore suitable for higher-level tasks such as motion planning, grasp planning, inverse kinematics, and cloud-side perception, rather than tight servo loops (Remmas et al., 2018). Cloudroid makes the same separation in different terms: heavy perception, SLAM, planning, and grasp analysis are appropriate for outsourcing, whereas hard real-time control loops remain on the robot (Hu et al., 2017). FogROS likewise emphasizes that components with real-time requirements, such as motor controllers, should not be deployed to the cloud, whereas grasp planning, motion planning, and SLAM can benefit from cloud GPUs and many-core servers despite additional communication latency (Kaiyuan et al., 2021).

This architectural pattern also appears in humanoid and mobile manipulation systems. CARL exposes a torque-controlled humanoid through a cloud-hosted web portal, but keeps whole-body control and local planning close to the robot, using the cloud layer for browser access, state visualization, and higher-level commands (Fok et al., 2016). A fog robotic system for dynamic visual servoing uses cloud-side AprilTag recognition and image-based visual servoing, an edge “Robot Command Unit” for communication and heartbeat logic, and on-robot self-balancing and actuator control, thereby demonstrating a cloud–edge split for dynamic box pickup and human handover scenarios (Tian et al., 2018).

2. Federated and distributed learning across robot fleets

A central systems question in cloud robotic manipulation is how fleets of robots can learn jointly without centralizing raw sensor streams. Federated learning is presented as a distributed machine learning paradigm in which collaborative training proceeds through dynamic participation of devices that exchange model updates rather than private raw data (Zaland et al., 23 Jul 2025). In cloud robotic manipulation, this maps naturally onto a cloud–edge–robot hierarchy: robots act as clients holding local images, point clouds, tactile signals, trajectories, and rewards; cloud or edge nodes coordinate training and aggregation; and only model parameters or gradients move through the network (Zaland et al., 23 Jul 2025).

The standard centralized FL workflow is summarized in three stages. A cloud server initializes global model parameters $\omega^0$ and selects a subset of robots; each selected robot trains locally for a fixed number of epochs or steps; the server aggregates updates into a new global model $\omega^t$ (Zaland et al., 23 Jul 2025). The paper explicitly gives the FedAvg rule

$$\omega^t = \sum_{c \in \mathcal{C}_m} \frac{n_c}{N} \, \omega_c^{t-1},$$

with weights proportional to local data size $n_c$, and also notes that methods such as FedProx and SCAFFOLD are relevant when heterogeneity is severe (Zaland et al., 23 Jul 2025). Horizontal FL is described as the most natural regime for robot fleets performing similar tasks with the same feature space but different data instances, while vertical and hybrid FL become relevant when different organizations or sensing subsystems contribute complementary information about shared tasks (Zaland et al., 23 Jul 2025).

Within robotic manipulation, the principal attraction of FL is that raw data remain on the robots. This is particularly important in hospitals, homes, and industrial facilities, where images, audio, tactile signals, and logs may contain private or proprietary information; FL reduces raw-data centralization while preserving collaborative learning across many sites (Zaland et al., 23 Jul 2025). At the same time, the paper stresses that FL is not a complete privacy solution because gradient or model leakage remains possible, so secure aggregation, differential privacy, or MPC may still be required (Zaland et al., 23 Jul 2025).

The literature cited around FL-based robotics includes both centralized and decentralized patterns. “Swarm Deep RL (SDRL)” is described as decentralized federated reinforcement learning for robotic manipulation in which robots share actor–critic models peer-to-peer, with convergence improving as more robots participate, though communication load also increases (Zaland et al., 23 Jul 2025). PPAFL is described as privacy-preserving asynchronous FL for mobile robotic swarms, organizing robots into temporary virtual groups based on reputation, performing P2P learning within each cluster, and then dissolving the clusters afterward; this removes a central point of failure but may limit generalization if inter-cluster exchange is weak (Zaland et al., 23 Jul 2025). LFRL is presented as an asynchronous lifelong FL architecture in which any robot can update the global model when ready, a natural match for fleets with intermittent connectivity and nonuniform training times (Zaland et al., 23 Jul 2025).

Distributed estimation and adaptation appear in a more control-theoretic form in cooperative adaptive control for cloud-based robotics. There, multiple manipulators manipulating copies of a common load share parameter information through centralized or decentralized update laws, and the paper introduces “Collective Sufficient Richness” or collective persistency of excitation to formalize the fact that parameter convergence may depend on the ensemble’s trajectories rather than any individual robot’s excitation (Wensing et al., 2017). In the centralized case, the shared parameter estimate is updated by aggregating $\sum_i Y_i^T s_i$; in decentralized variants, each robot keeps its own estimate and consensus-like coupling terms drive agreement even under time-varying network topologies and communication delays (Wensing et al., 2017). This establishes a precise cloud-enabled mechanism by which fleets can identify shared object parameters through cooperation rather than isolated adaptation (Wensing et al., 2017).

3. Service infrastructures, offloading, and quality of service

Cloud robotic manipulation depends not only on learning architectures but also on service infrastructures that expose manipulation-relevant computation as reliable network services. SRCA demonstrates this in a generic Kubernetes-based form. Developers upload a ROS package together with a YAML specification that defines Python functions, arguments, return types, HTTP methods, dependencies, and launch commands; the system then validates the package, generates a Dockerfile, WSGI bindings, an OpenAPI specification, and client libraries, builds the image in a temporary Pod, deploys it through Kubernetes, and exposes stable HTTP endpoints through a reverse proxy (Remmas et al., 2018). Because the architecture is ROS-oriented but can also host non-ROS code, it can export motion planners, inverse-kinematics solvers, grasp pose estimators, or combined mobile-manipulation services behind the same deployment interface (Remmas et al., 2018).

The paper’s experimental results use a trivial add_two_ints() service rather than a manipulation algorithm, but the latency figures are informative about service behavior under load. On a 3-node cluster with 500 concurrent HTTP requests, using 3 workers per Pod, increasing the number of Pods from 1 to 3 reduced average time_total from 3.46107 s to 2.32103 s, and total − start_transfer from 2.02840 s to 0.80597 s, showing that service replication improved throughput and end-to-end latency (Remmas et al., 2018). Yet SRCA also states explicitly that such a system “cannot be used for time critical operations,” which situates cloud-side manipulation primarily at the level of planning, scene understanding, and non-servo learning tasks rather than sub-second visual servo loops (Remmas et al., 2018).

Cloudroid develops the same service idea in a QoS-aware direction. Existing ROS packages are encapsulated as Dockerized “servants” that expose their interfaces via ROSBridge and a Service Portal, while automatically generated ROS stubs on the robot preserve the original package interface and can fall back to a local package instance when request-response time exceeds specified thresholds (Hu et al., 2017). The QoS model is built around a desirable RRT $T_{\text{desire}}$ and a maximal acceptable RRT $T_{\text{max}}$; a satisfaction variable $Q$ is increased when cloud latency is good and decreased when it exceeds acceptable bounds, triggering local fallback if $Q$ drops below a threshold (Hu et al., 2017). For heavy perception and mapping components, the reported speedups are substantial: Cloudroid reports a 25.05× speedup for SSD object detection on a cloud GPU compared with a local Ultrabook, and RGBD-SLAM computation time falls from 2.095 s on a Raspberry Pi to 0.542 s when offloaded, despite network overhead (Hu et al., 2017). These figures explain why cloud-hosted perception and grasp analysis remain attractive even when per-request latency cannot support hard real-time control (Hu et al., 2017).

FogROS provides a ROS-native deployment model for similar workloads. In the evaluated Dex-Net FC-GQ-CNN grasp-planning setup, a GPU cloud instance reduces grasp-planning compute from 7.3 s on an edge CPU to 0.6 s in the cloud, with 0.6 s of network time and 1.2 s total end-to-end latency in the compressed VPC configuration, corresponding to an overall speedup of about 6× (Kaiyuan et al., 2021). For a multi-core motion planner on a 96-core cloud instance, planning time for the “Apartment” scenario falls from 157.6 s on the edge to 4.6 s total with FogROS VPC, an improvement on the order of 34× (Kaiyuan et al., 2021). These numbers are specific to the paper’s benchmarked planners, but they establish a concrete pattern: heavy planning and grasp synthesis are precisely the workloads for which cloud offloading materially alters feasible manipulation throughput (Kaiyuan et al., 2021).

Cloud-based manipulation infrastructures also support remote access and benchmarking rather than only service offloading. OCRTOC packages participant solutions inside Docker containers, runs them on cloud simulation infrastructure and on identical physical robot setups, and scores object rearrangement tasks automatically using the average 3D Euclidean distance error per object, with per-object upper error bounds (Liu et al., 2021). The formal task specification $\mathbb{X} := \{\mathbb{O}, C^I, C^G\}$ and the evaluation function based on $\omega^t$0 make cloud-hosted physical evaluation reproducible across teams worldwide (Liu et al., 2021). This benchmark perspective is distinct from online offloading, but it is part of the same cloud robotic manipulation ecosystem because it treats standardized robot cells as remotely scheduled cloud resources (Liu et al., 2021).

4. World models, 3D representations, and policy architectures

Cloud robotic manipulation increasingly relies on heavy 3D perception and world-model computation that is natural to centralize. ParticleFormer is exemplary in this regard: it defines the environment state as point clouds for manipulated objects $\omega^t$1 and end effectors $\omega^t$2, material codes $\omega^t$3, and control inputs $\omega^t$4, then learns a transition function

$\omega^t$5

that predicts the next 3D point-cloud state directly from stereo perception (Huang et al., 29 Jun 2025). The model uses a Transformer-based dynamics backbone, multi-head self-attention across all particles, and a hybrid point-cloud reconstruction loss combining Chamfer Distance and a differentiable approximation of Hausdorff Distance (Huang et al., 29 Jun 2025). This removes the need for explicit graph construction and for elaborate 3D scene reconstruction with tracked particles (Huang et al., 29 Jun 2025).

ParticleFormer is notable because it is already close to a cloud service model. Stereo matching with FoundationStereo, object segmentation with GroundingDINO and Segment Anything, Transformer-based rollouts, and MPPI all sit naturally on GPU-equipped servers rather than embedded controllers (Huang et al., 29 Jun 2025). In real-world experiments, the sensing stack uses a ZED-2i stereo camera at 10 Hz with 1280×720 images and one or two xArm-6 manipulators; training is performed on A100 GPUs, while control uses an RTX 3090, which directly suggests a cloud-hosted “world model as a service” for robot fleets (Huang et al., 29 Jun 2025). The model is then used in Model Predictive Path Integral control, optimizing action sequences against a cost based on normalized CD+HD between predicted and target point clouds (Huang et al., 29 Jun 2025). This suggests a systems pattern in which robots become thin clients that provide observations and receive short-horizon action proposals from a shared world-model service.

Learned 3D representations also matter for cloud-wide policy sharing. PolarNet uses multi-view RGB-D projected into a unified world-frame point cloud, a PointNext encoder, a frozen CLIP text encoder, and a multimodal transformer to predict keyframe actions for language-guided manipulation (Chen et al., 2023). Its position decoder performs a soft integral over a point heatmap plus per-point offsets rather than quantizing the workspace into voxels, and the training loss combines MSE on Cartesian position and quaternion orientation with BCE for gripper state (Chen et al., 2023). On RLBench, PolarNet reports an average success rate of 92.1% in single-task 10-task evaluation and 89.8% in the corresponding multi-task model, outperforming the compared 2D and voxel-based baselines in those settings (Chen et al., 2023). The relevance to cloud robotic manipulation lies in the fact that calibrated multi-view point clouds provide a standardized 3D interface across sites, so a centrally trained policy can be shared without binding to a single camera view (Chen et al., 2023).

FP3 pushes the same idea to the foundation-model regime. It is a 1.3B-parameter diffusion-transformer policy pre-trained on 60k trajectories with point-cloud observations and then adapted through LoRA fine-tuning using only 80 demonstrations per downstream real-robot task (Yang et al., 11 Mar 2025). In the reported real-robot experiments, FP3 achieves over 90% in-domain success and 82.50% average success in-the-wild across four tasks, substantially surpassing the compared foundation baselines (Yang et al., 11 Mar 2025). Its cloud relevance is explicit in the training footprint—3M pre-training steps on 8×A800 GPUs—and in the parameter-efficient post-training regime, which supports centralized base-model maintenance with lightweight adapter distribution to robots (Yang et al., 11 Mar 2025). This suggests a cloud architecture in which the foundation policy and continual pre-training remain centralized, while task-specific adaptation is disseminated across fleets.

CL3R focuses on the perception backbone rather than the policy. It pre-trains a 3D point-cloud encoder using a point-cloud masked autoencoder and two contrastive losses that align 3D features with image and text features from a pre-trained 2D foundation model, with total objective

$\omega^t$6

using $\omega^t$7 (Cui et al., 11 Jul 2025). Crucially, CL3R unifies all point clouds into a robot/world coordinate frame and randomly fuses multi-view point clouds during pre-training, reducing camera-view ambiguity across datasets and improving viewpoint robustness (Cui et al., 11 Jul 2025). The paper frames this directly as a reusable 3D representation backbone for robotic tasks, which is well matched to cloud-scale pre-training and later deployment on many robots (Cui et al., 11 Jul 2025).

A complementary line of work asks whether real 3D sensing is necessary at all. NoReal3D predicts a relative monocular depth map from RGB, normalizes it, back-projects it into a pseudo point cloud through approximate camera intrinsics, encodes the resulting coordinate image with a 2D backbone, and fuses the pseudo-3D features with ordinary RGB features (Yu et al., 20 Sep 2025). On RLBench with ACT, VC1 plus NoReal3D reaches a mean success rate of 0.36, close to 0.37 for PointNet+ACT, and on RLBench with Diffusion Policy the NoReal3D-enhanced 2D models outperform the reported 3D baselines and DP3 (Yu et al., 20 Sep 2025). In cloud terms, this line suggests that some benefits of shared 3D perception may be obtainable even for fleets equipped only with inexpensive monocular cameras, reducing sensor cost while preserving a geometry-aware centralized training regime (Yu et al., 20 Sep 2025).

5. Benchmarks, teleoperation, and large-scale data collection

Cloud robotic manipulation is also a data and benchmarking paradigm. CloudGripper exemplifies a physical cloud-robotics testbed built as a rack of 32 enclosed robot arm work cells, each with a low-cost 5-DOF Cartesian arm, a parallel-jaw gripper, two RGB cameras, a Raspberry Pi 4B, and a Teensy 4.1 microcontroller (Zahid et al., 2023). The rack provides 1 Gbit/s Ethernet per robot and a 10 Gbit/s aggregation network, and the per-robot REST API exposes state queries, still images, streaming, and motion commands (Zahid et al., 2023). In a local stress test with 32 robots and 2 cameras per robot at 10 fps, aggregate bandwidth reached about 80 MB/s, less than 10% of the theoretical 10 Gbit/s limit, while 95th percentile latency stayed near 70 ms and maximum latency remained below 100 ms (Zahid et al., 2023). These figures matter because they quantify the network headroom needed for cloud-scale manipulation experimentation rather than merely asserting feasibility (Zahid et al., 2023).

CloudGripper also contributes a concrete large-scale dataset: CloudGripper-Rope-100 contains more than 100 hours of randomized rope-pushing interactions and approximately 4 million camera images (Zahid et al., 2023). The platform’s motion repeatability measurements—$\omega^t$8 and $\omega^t$9—show that low-cost rack-scale hardware can still support quantitatively meaningful manipulation research (Zahid et al., 2023). This combination of standardized work cells, remote API access, and multi-terabyte data collection is one route by which cloud robotic manipulation becomes a fleet learning problem rather than a single-lab hardware problem (Zahid et al., 2023).

OCRTOC supplies a complementary benchmark model based on remote execution of user-submitted manipulation software on identical real robot setups for object rearrangement (Liu et al., 2021). In its IROS 2020 competition, 59 teams participated worldwide, 14 beat the simulation baseline, and the best real-robot team achieved 31.1% improvement over the baseline error, with a grasp success rate of 26/33 = 78.8% (Liu et al., 2021). The result is not simply a leaderboard; it is a controlled cloud workflow in which standardized manipulation systems, scenes, and scoring procedures expose the failure modes of perception, grasp generation, and motion planning in clutter (Liu et al., 2021).

Teleoperation-based cloud systems address data collection more directly. CARL showed that a smartphone browser could command a torque-controlled humanoid through a cloud-hosted interface and whole-body operational-space control, enabling a dual-arm bottle manipulation demonstration by an inexperienced operator (Fok et al., 2016). COBALT generalizes this into a large-scale cloud teleoperation platform. It uses cloud-hosted, vectorized simulation and load-balanced infrastructure to support many users concurrently, with control via smartphones, VR headsets, 3D mice, and keyboards, and it reports operation at 20 Hz with sub-100 ms end-to-end latency for up to 8 concurrent users per GPU, as well as stable support for 256 simulated clients across 8 GPUs (Agarwal et al., 18 May 2026). A global pilot dataset was then crowdsourced: 7500+ demonstrations, 50+ hours, operators across nine countries, and collection over five days (Agarwal et al., 18 May 2026). The platform also logs path length, translational and rotational jitter, completion time, reset rate, and network timing metrics so that suboptimal demonstrations can be filtered automatically before imitation learning (Agarwal et al., 18 May 2026).

A more focused fog-robotic teleoperation example appears in dynamic visual servoing for a self-balancing robot. There, remote teleoperation over the cloud required 340 s on average with 4/10 success for box pickup, whereas automatic image-based visual servoing through the same cloud–edge system reduced average duration to 46 s with 10/10 success, near the 43 s and 9/10 achieved by local teleoperation (Tian et al., 2018). This makes an important point for cloud robotic manipulation: cloud-connected human operation alone may not be enough, but cloud perception coupled with local autonomy can restore both efficiency and reliability (Tian et al., 2018).

6. Challenges, safety, and research directions

The challenges of cloud robotic manipulation recur across infrastructures, learning schemes, and teleoperation systems. Communication and latency remain primary. In FL for manipulation, exchanging model updates rather than raw data reduces bandwidth relative to centralized learning, but large fleets still create stragglers, aggregation delays, and stale-model effects; the paper explicitly calls for adaptive FL algorithms, straggler-resilient device selection, compression, and edge aggregators (Zaland et al., 23 Jul 2025). In cloud service frameworks, measured end-to-end latencies can be acceptable for planning but not for tight control loops, which is why SRCA, Cloudroid, and FogROS all leave low-level control local (Remmas et al., 2018). In continuous control, latency becomes a stability issue rather than only a throughput issue.

Speculative Policy Orchestration addresses that latter regime. It places a policy network and world model in the cloud, predicts $$\omega^t = \sum_{c \in \mathcal{C}_m} \frac{n_c}{N} \, \omega_c^{t-1},$$0 future kinematic waypoints, caches them at the edge, and allows the robot to execute them only if an $$\omega^t = \sum_{c \in \mathcal{C}_m} \frac{n_c}{N} \, \omega_c^{t-1},$$1-tube verifier confirms that actual and predicted states remain sufficiently close (Nguyen et al., 19 Mar 2026). The verifier checks

$$\omega^t = \sum_{c \in \mathcal{C}_m} \frac{n_c}{N} \, \omega_c^{t-1},$$2

against a threshold $$\omega^t = \sum_{c \in \mathcal{C}_m} \frac{n_c}{N} \, \omega_c^{t-1},$$3, and the horizon $$\omega^t = \sum_{c \in \mathcal{C}_m} \frac{n_c}{N} \, \omega_c^{t-1},$$4 is adapted online by an Additive-Increase / Multiplicative-Decrease rule (Nguyen et al., 19 Mar 2026). Under emulated 150 ms ± 30 ms RTT on RLBench tasks at 50 Hz control, SPO reduces network-induced idle time by over 60% relative to blocking remote inference and discards about 60% fewer cloud predictions than static caching baselines, while keeping a local safety filter in the loop (Nguyen et al., 19 Mar 2026). This is a concrete answer to the long-standing objection that cloud-side manipulation is necessarily too slow for continuous control: it may be too slow for direct synchronous inference, but not necessarily for speculative cloud–edge orchestration (Nguyen et al., 19 Mar 2026).

Privacy, security, and trust form another challenge cluster. FL-based cloud manipulation reduces raw-data exposure but still faces model-poisoning, gradient leakage, malicious task delegations, and general trust-management problems across robots and cloud services (Zaland et al., 23 Jul 2025). Cloud service platforms similarly assume the need for authentication, authorization, secure communication, and robust aggregation or fallback when cloud performance degrades (Hu et al., 2017). In competitive or shared cloud settings such as OCRTOC and the Real Robot Challenge, the challenge is broader: untrusted code must be sandboxed while real hardware is protected against unsafe torque commands, self-collisions, or prolonged abuse (Liu et al., 2021). The Real Robot Challenge solved this through a combination of mechanical robustness, software torque and position limits, automatic monitoring, and batch-style execution that avoids direct WAN control (Bauer et al., 2021).

Resource heterogeneity and energy are equally persistent. FL papers emphasize that robots differ in compute, memory, network, battery, and local data distributions, and that robotic environments add an extra layer of non-iid variation because homes, warehouses, and hospitals generate distinct sensor statistics and task frequencies (Zaland et al., 23 Jul 2025). Edge–cloud scheduling must therefore consider not only model accuracy but also on-robot training cost, wireless transmission energy, and interference with real-time control (Zaland et al., 23 Jul 2025). This suggests hierarchical FL, clustered FL, asynchronous updates, and energy-aware scheduling during idle or charging periods as natural design directions (Zaland et al., 23 Jul 2025).

A final set of open directions concerns representation scale and interoperability. FP3, CL3R, PolarNet, ParticleFormer, and NoReal3D all point toward a future in which cloud robotic manipulation relies on shared 3D backbones, world models, and language-conditioned policies, but they also expose unresolved issues: dependence on calibrated depth sensors or segmentation modules, limited zero-shot generalization, per-scene training in some world models, and the need for better multi-task scaling (Yang et al., 11 Mar 2025). The FL position paper identifies clustered FL for multi-task fleets, multimodal LLM integration, interoperability across diverse sensors and domains, and responsible FL with fairness, interpretability, and trustworthiness as major research directions (Zaland et al., 23 Jul 2025). A plausible implication is that cloud robotic manipulation will increasingly be organized around centralized 3D foundation models and shared world-model services, but only if communication, safety verification, and cross-robot heterogeneity are treated as first-class systems problems rather than afterthoughts (Zaland et al., 23 Jul 2025).