ConfigBot: Adaptive Resource Allocation for Robot Applications in Dynamic Environments

TL;DR

ConfigBot addresses the challenge of adaptive resource allocation for robot applications in dynamic environments by combining runtime profiling, adaptor-based data throttling, and Bayesian optimization over OS-level (cgroups) and ROS-level (adaptors) knobs. It separates core services from non-core apps, formulates a constrained multi-objective optimization, and maintains a reusable library of context-specific configurations to meet developer-defined performance specifications. The system demonstrates significant improvements over default OS configurations, generalizes across multiple robots and stacks, and adapts to context changes through fast relearning triggered by runtime monitors. The work highlights the practical impact of automatic configuration tuning for robotic deployments, enabling stable, resource-efficient operation in diverse and evolving environments.

Abstract

The growing use of service robots in dynamic environments requires flexible management of on-board compute resources to optimize the performance of diverse tasks such as navigation, localization, and perception. Current robot deployments often rely on static OS configurations and system over-provisioning. However, they are suboptimal because they do not account for variations in resource usage. This results in poor system-wide behavior such as robot instability or inefficient resource use. This paper presents ConifgBot, a novel system designed to adaptively reconfigure robot applications to meet a predefined performance specification by leveraging \emph{runtime profiling} and \emph{automated configuration tuning}. Through experiments on multiple real robots, each running a different stack with diverse performance requirements, which could be \emph{context}-dependent, we illustrate ConifgBot's efficacy in maintaining system stability and optimizing resource allocation. Our findings highlight the promise of automatic system configuration tuning for robot deployments, including adaptation to dynamic changes.

Figures (8)

• Figure 1: Basic-NAV stack. A basic stack (i.e., set of robot apps) w/ sensor processing, navigation, and telemetry robofleet-client via a web dashboard. Navigation is a core service and produces two outputs: (a) command velocity for actuators and (b) a goal image showing the projected path for monitoring and debugging. The minimum safe update rate required for (a) is 35Hz (developer-specified); higher refresh-rates are possible if resources permit. All communication shown in the Figure (arrows) happens via ROS topics; we have omitted topic names for cross-app data flows (dashed arrows) for brevity.
• Figure 2: Impact of resource constraints
• Figure 3: In traditional ROS message passing, every consumer receives all messages published to the topic (i.e.$n=n_1=n_2$). Our custom ROS build places adaptors () on each subscription edge, enabling independent rate control per-consumer.
• Figure 4: ConfigBot flowchart: How ConfigBot learns configs (given a specification -- SPEC) for new contexts and performs runtime monitoring to identify when relearning is needed.
• Figure 5: Robots we use: Spot, Cobot, and Jackal (left to right).