ARRC: Robotics Control & Cloud Optimization

• ARRC is an acronym for two distinct systems—robotic manipulation via retrieval-augmented planning and edge–cloud resource optimization through explainable agents.
• In Advanced Reasoning Robot Control, natural-language instructions are transformed into safe, executable actions using RGB-D perception, a curated knowledge base, and JSON-structured planning.
• In Automatic Recommender for Resource Configurations, modular agents coordinate via a versioned blackboard to deliver evidence-backed, workflow-integrated recommendations for sustainable resource management.

ARRC is an acronym used for two distinct systems in recent literature. In robotics, ARRC denotes Advanced Reasoning Robot Control, a practical robot manipulation framework that uses retrieval-augmented generation (RAG) to convert natural-language instructions into safe, executable robot actions on a real arm (Vorobiov et al., 7 Oct 2025). In edge–cloud operations, ARRC denotes Automatic Recommender for Resource Configurations, an explainable, workflow-integrated recommender system for sustainable resource optimization across the edge–cloud continuum (Jahnke et al., 16 Jul 2025). The shared acronym conceals substantially different technical agendas: one connects language reasoning to RGB-D-guided manipulation with guarded execution, while the other delivers evidence-backed recommendations for rightsizing and security/compliance into operator workflows.

1. Acronym, scope, and disambiguation

The two uses of ARRC differ in domain, architecture, and operational objective.

Expansion	Domain	Core purpose
Advanced Reasoning Robot Control	Robot manipulation	Connects natural-language instructions to safe local robotic control
Automatic Recommender for Resource Configurations	Edge–cloud resource optimization	Delivers explainable, cross-layer resource recommendations directly into operator workflows

In the robotics usage, ARRC is explicitly not an end-to-end neural policy; it is a knowledge-driven manipulation pipeline in which the robot consults retrieved procedural and safety knowledge before planning and execution. In the edge–cloud usage, ARRC is explicitly a modular, agent-based architecture coordinated through a versioned blackboard, designed to avoid opaque and intrusive automation. A common misconception is that the acronym denotes a single framework; the literature instead uses it for two unrelated systems with different abstractions, interfaces, and evaluation criteria (Vorobiov et al., 7 Oct 2025).

2. Advanced Reasoning Robot Control: retrieval-augmented manipulation

Advanced Reasoning Robot Control addresses a recurrent robotics failure mode: large language or vision-LLMs can generate plausible plans, but those plans are often not physically grounded, may violate safety constraints, or may not fit the current robot, workspace, or task procedure. The framework combines a curated robotics knowledge base, retrieval-augmented prompting, an LLM that generates structured JSON plans, RGB-D + AprilTag perception for object-centric metric state, and a safety-checked executor on a UFactory xArm 850 (Vorobiov et al., 7 Oct 2025).

The pipeline has three major stages. In perception, an Intel RealSense D435 RGB-D camera and AprilTags are used to detect objects and estimate their 3D poses. The perception output is described as compact object observations of the form {tag_id, bbox, position_xyz, confidence}. For each detected tag, depth is taken from the median depth value inside the tag region, back-projected using camera intrinsics, and transformed from camera coordinates into the robot base frame. A temporal filter smooths jitter across frames.

In retrieval-augmented planning, the system maintains a robotics knowledge base made of short textual entries containing movement primitives, task templates, safety heuristics, short demonstration transcripts, and parameterized affordances. These entries are embedded with SentenceTransformers / Sentence-BERT and indexed in ChromaDB or FAISS. At runtime, the user instruction is embedded and matched to the stored knowledge using cosine similarity:

$$\text{sim}(q, k_i) = \frac{q^\top k_i}{\|q\| \|k_i\|}$$

where $q \in \mathbb{R}^d$ is the embedded query, $k_i$ are knowledge-base embeddings, and the top-$m$ most similar items are retrieved. The retrieved snippets are concatenated with the current environment summary to form the prompt context

$C = [\mathcal{R}^\top, s_t^\top]^\top$

where $\mathcal{R}$ is the retrieved knowledge and $s_t$ is the symbolic observation of the current state.

In execution, the LLM does not directly emit motor commands. It produces a JSON-structured plan consisting of a goal, a sequence of action steps, and bounded parameters for each step. The paper writes the plan as

$\pi = \{g, A\}$

where $g$ is the high-level goal and $A = \{a_1, \dots, a_l\}$ is the action queue. The planner is prompted with retrieved knowledge snippets, environment summary, explicit constraints, a JSON schema, and few-shot exemplars. The executor accepts high-level action types such as SCAN_AREA, APPROACH_OBJECT, MOVE_TO_POSE, OPEN_GRIPPER, CLOSE_GRIPPER, and RETREAT_Z, and maps them into atomic XArm SDK commands.

The knowledge base is intentionally curated and structured rather than raw web text. Entries are about 50–400 tokens each and include examples such as hover approaches, retreat motions, grasp offsets, scan area → approach → grasp → retreat, safe hover heights, velocity limits, force limits, recovery strategies, and demonstration-derived affordances such as “grasp handle from the side and lift slowly.” This design means that the LLM is not relying only on generic language priors; it is grounded in current objects and poses, task templates, safety heuristics, and known manipulation patterns. The paper emphasizes improved plan specificity, validity, and adaptability compared with using the LLM alone.

3. Perception grounding, guarded execution, and robotics evaluation

ARRC’s perception stack is deliberately simple and robust: AprilTags provide reliable object identity and image-space pose cues, while the RealSense D435 provides depth for metric localization. The camera is rigidly mounted and extrinsically calibrated to the robot, allowing detections to be transformed into the robot base frame and checked against workspace and safety constraints before being used by inverse kinematics (Vorobiov et al., 7 Oct 2025).

The system also includes a hierarchical scanning algorithm for object discovery. It performs a horizontal sweep scan at a fixed height across the workspace; if no object is found, it switches to a fallback arc scan using three hardcoded joint-space viewpoints: LEFT, CENTER, and RIGHT. The stated purpose is to avoid singularities and provide deterministic alternate views for occluded objects. The paper’s screwdriver example uses this logic: a first horizontal scan fails due to occlusion, the arc scan changes viewpoint, the target becomes visible, and the system proceeds to approach and grasp.

Safety is a major part of the framework. The executor is the final safeguard before motion is sent to hardware. The described safety mechanisms are workspace bounds, joint limits, maximum Cartesian speed, maximum joint speed, maximum Cartesian acceleration, maximum single move distance, per-step timeouts, gripper torque/load gating, emergency open / release on anomaly, bounded retries, and return-to-safe configuration on abort. The software limits table gives 150 mm/s for max Cartesian speed, 30 deg/s for max joint speed, 1000 mm/s² for max Cartesian acceleration, workspace $q \in \mathbb{R}^d$0 as [150, 650] mm, workspace $q \in \mathbb{R}^d$1 as [-300, 300] mm, workspace $q \in \mathbb{R}^d$2 as [50, 500] mm, 300 SDK units for gripper max speed, 100 SDK units for gripper max force, 0.1 s for the safety check interval, and 400 mm for the max single move distance. The text further states that commanded positions must satisfy $q \in \mathbb{R}^d$3, Cartesian speed satisfies $q \in \mathbb{R}^d$4, joint speeds satisfy $q \in \mathbb{R}^d$5, and each step has a maximum duration $q \in \mathbb{R}^d$6.

The validation workflow proceeds by parsing the JSON plan, checking parameters against bounds, checking plan length and feasibility, synchronizing steps that need up-to-date scene information with the latest perception, optionally requiring human confirmation for high-risk actions, and enforcing runtime monitoring with timeouts and load-based stops. The hardware setup consists of a UFactory xArm 850, a parallel-jaw gripper driven by Dynamixel motors, an Intel RealSense D435, an Ubuntu 22.04 workstation with Python 3.10, and the official XArm Python SDK over Ethernet.

Experimental evaluation covered three tabletop manipulation tasks: Scan, Approach, and Pick–Place. Objects included bottles, boxes, screwdrivers, and hand tools, and scenes were moderately cluttered, with partial occlusion and randomized placements. Each condition was repeated for at least 10 trials. The reported metrics were Plan Validity, Scan success, Approach Accuracy (%), Pick-and-Place success, and Time Frame. Across 10 trials, the summary reports 80% plan validity, 100% scan success, 87.1% average approach accuracy, 100% pick-and-place success, and 1.225 s average time frame. The paper further states that only trials 3 and 5 had invalid plans. Reported prototyping failures included missed detections under partial occlusion, low-confidence objects causing approach timeouts, and fragile objects needing force/tactile awareness. The stated limitations are that the knowledge base is curated and static, tactile/torque-heavy tasks are out of scope, the LLM may still generate infeasible plans, and retrieval and cloud inference introduce latency.

4. Automatic Recommender for Resource Configurations: explainable edge–cloud optimization

In a distinct line of work, Automatic Recommender for Resource Configurations addresses safe, transparent, and low-effort resource optimization in dynamic, multi-tenant edge–cloud systems. The system is introduced as an explainable, workflow-integrated recommender system for sustainable resource optimization across the edge–cloud continuum, motivated by persistent overprovisioning, heterogeneous platforms, layered abstractions, and the maintenance burden created by opaque automation (Jahnke et al., 16 Jul 2025).

The operational setting spans virtual machines, containers, Kubernetes/OpenStack infrastructure, and compliance/security controls. Operators must choose resource requests and limits with incomplete knowledge because workloads are often opaque, multi-tenant, and constrained by privacy/compliance boundaries. The paper frames the central problem as enabling optimization without disrupting established workflows or increasing technical debt. ARRC answers this by generating actionable recommendations rather than automatically mutating infrastructure in a black-box manner. It is designed to work with tickets, merge requests, pull requests, and GitOps workflows, so that automation remains auditable and incremental.

The paper explicitly emphasizes four design goals. Sustainable resource optimization targets right-sizing of VMs and containers, compliance/security-related configuration issues, reduced compute waste, improved energy efficiency, and lower operational overhead. Explainability requires that each recommendation include underlying observations, historical statistics, forecast values, rationale, projected impact on cost, utilization, reliability, or compliance, and versioned identifiers for auditability. Maintainability is pursued through specialized agents and a shared interface, rather than a monolithic optimizer. Workflow integration means that operators do not need to switch tools; recommendations are delivered into GitHub/GitLab merge requests or pull requests, tickets, and issues.

The paper positions ARRC against several limitations of existing solutions: they are often reactive rather than proactive, focused on a single abstraction layer, characterized by poor explainability, dependent on intrusive integration requirements, weak in workflow integration, and vulnerable to maintainability concerns. A plausible implication is that the system’s recommender-centric design is meant to preserve operator control while still extracting substantial optimization benefit.

5. Agent-based architecture, blackboard coordination, and recommendation logic

ARRC follows a modular, agent-based architecture coordinated through a versioned blackboard. The described high-level pipeline has four phases: ingestion and normalization, analysis and recommendation generation, prioritization and conflict resolution, and workflow delivery (Jahnke et al., 16 Jul 2025).

The paper summarizes five core components. The Observer ingests and normalizes telemetry and creates versioned observations. Recommender Agents generate evidence-backed recommendations. The Strategizer prioritizes, sequences, and resolves conflicts between recommendations. The Workflow Adapter translates internal recommendation objects into workflow-native artifacts such as tickets or pull requests. The Blackboard stores observations and recommendations in a versioned, atomic, auditable form. The blackboard is described as supporting traceability, consistency, and auditability in both centralized and distributed deployments.

The RightSizing Recommender Agent targets resource allocation optimization for VMs and containers. It groups observations by resource handle over a rolling window of seven days by default and analyzes CPU requests/limits, memory requests/limits, actual usage, and metadata such as flavor, project, owner, image, and instance ID. It computes P95, minimum, maximum, and slack, where slack is defined as allocated minus used resources. For forecasting, it runs Prophet and ARIMA in parallel, then chooses the most suitable model using a heuristic selector based on sample entropy and variance. It matches candidate demand against the available catalog, adds a default 10% buffer, and emits a recommendation only if the chosen configuration differs from the current one. Output includes a YAML or JSON patch, an impact analysis, a rationale, and versioned references to supporting data.

The Security Recommender Agent handles Kubernetes security/compliance violations through KubescapeObserver and KubescapeRecommender. The observer runs Kubescape scans against frameworks such as NSA-CISA and CIS Benchmarks, then converts failed checks into versioned observations containing check name, resource name and kind, namespace, severity, documentation links, and remediation hints. For each failed check, the recommender builds a contextual prompt for an LLM, includes JSON-serialized scan data, scrapes the linked documentation, and asks for step-by-step remediation. The resulting recommendation includes severity, rationale, documentation links, and the originating observation reference.

The Strategizer is the global decision-making layer. It uses a hybrid static/dynamic weighting system based on operator-defined priorities aligned with ISO 25010-style qualities: reliability, performance, security, cost, and sustainability. Conflict resolution uses goal-oriented action planning (GOAP). The system also limits how many recommendations are surfaced: the pipeline description states that a configurable cap limits surfaced recommendations per reporting period, with a default of 10 per week, and the Strategizer discussion states that the default cap is 10 per reporting window. Operators can approve, reject, or modify recommendations. Rejected recommendations are not resurfaced during the same reporting window, reducing churn and notification fatigue.

The paper also specifies an error criterion: a recommendation is erroneous if, in the following week, actual peak utilization diverges by more than 15% from the recommended value. This criterion is used to assess safety and accuracy. Recommendations can project changes in cost, energy, utilization, and reliability, and are normalized to cluster capacity and classified by type, such as reliability improvement, performance improvement, and cost efficiency.

6. Production evaluation, safety posture, and broader significance

The evaluation of the edge–cloud ARRC was conducted in a real production environment combining OpenStack and Kubernetes across multiple geographic regions, with mixed tenants and workloads including R&D, IT, and external clients. Workloads were treated as opaque third-party applications under privacy and multi-tenancy constraints, with intermittent connectivity and latency constraints. The dataset covered three months of operational data, from July to September 2024, with 528 unique VMs and five-minute utilization records; the evaluation pipeline used two months of historical context for forecasting (Jahnke et al., 16 Jul 2025).

The observed workload characteristics were strongly skewed toward overprovisioning. The paper reports average CPU utilization for 90% of VMs: 14.5%, 85% of VMs below 10% CPU utilization, 80% long-lived workloads, 5% of VMs consuming more than half the CPU hours, >95% of workloads with less than 15% week-to-week variance, nearly 70% of projects using one machine type, only 2% exceeding 64 GiB RAM, and resource starvation events below 1%. The paper states that these findings support the argument that the environment is highly suitable for proactive rightsizing.

The reported empirical gains are substantial. At the 25th percentile, applying ARRC recommendations increased CPU utilization by 6.9x and memory utilization by 1.6x; these approached theoretical maxima of 7.7x for CPU and 1.6x for memory. ARRC identified 95.2% of VMs as candidates for downscaling, 4.8% as correctly sized, and 17.1% as suspected idle. The prioritization results are also explicit: the top 15% of prioritized recommendations captured 79% of the attainable optimization benefit, and 91% of total optimization was achieved after only 23% of recommendations were applied.

The operator-workload results quantify the workflow argument. Before ARRC, the environment saw 38 manual optimization tickets per month, about 27 minutes per ticket, and around 19 hours/month total effort. With ARRC, the system generated 72 recommendations per month, operators spent about 7 minutes per ticket, and total effort fell to 8.4 hours/month. The paper reports this as a 56% reduction in operator effort. Reliability outcomes are stated using the paper’s error definition: ARRC maintained a 3.1% error rate, below the stated 5% threshold, with no observed application failures, no service degradations, and all errors being single-sided threshold violations.

In fully autonomous mode, the paper compares ARRC with Kubernetes Vertical Pod Autoscaler (VPA). The reported wasted vCore usage is 239 for No Scaling, 46 for VPA (Auto), and 13 for ARRC (Auto). The paper states that this means ARRC reduced total wasted vCore usage by over 3x compared to VPA and did so with no observed crashes or application errors.

Across both meanings of ARRC, a shared design principle is visible: flexible high-level decision logic is constrained by auditable structure. In robotics, that structure is a curated knowledge base, JSON-structured planning, local perception, and software safety gates. In edge–cloud operations, it is a versioned blackboard, specialized auditable agents, Strategizer-based prioritization, and operator-approved workflow delivery. This suggests that, despite domain divergence, the acronym has been associated with systems that prefer bounded, inspectable execution over opaque end-to-end autonomy.