ConfigBot: Adaptive Resource Allocation for Robot Applications in Dynamic Environments

Aditya Akella; Christopher J. Rossbach; Daehyeok Kim; Joydeep Biswas; Rohit Dwivedula; Sadanand Modak

REVIEW 4 major objections 6 minor 27 references

ConfigBot: Adaptive Resource Allocation for Robot Applications in Dynamic Environments

T0 review · 4 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read ConfigBot claims a Bayesian-optimization loop over OS cgroup limits and ROS data-flow throttles can automatically find robot configurations that meet developer-specified performance requirements, letting a navigation stack run on one CPU…

desk verdict A genuine per-subscriber adaptor abstraction with a useful broad evaluation, but the end-to-end stability claims outrun the metric-only evidence; worth refereeing, with a request for direct behavioral validation. read the letter →

arxiv 2501.10513 v2 pith:MUDSDWDL submitted 2025-01-17 cs.RO

Rohit Dwivedula , Sadanand Modak , Aditya Akella , Joydeep Biswas , Daehyeok Kim , Christopher J. Rossbach This is my paper · ORCID

classification cs.RO

keywords ConfigBotadaptiveresourceallocationBayesianoptimizationcgroupsROSadaptorsperformancespecificationservicerobotsruntimeprofiling

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

ConfigBot is a system that automatically retunes a robot's compute resources so that apps meet developer-defined performance targets without manual intervention. The paper argues that default Linux scheduling is a poor fit for robot stacks, and that tuning cgroup CPU limits plus a new 'adaptor' layer that throttles ROS message flows can restore performance. ConfigBot frames resource allocation as a constrained black-box optimization: core services are hard constraints, non-core apps are objectives, and Bayesian optimization searches the configuration space. On a Boston Dynamics Spot running a basic navigation stack, ConfigBot met the 35 Hz command-velocity spec with about one CPU, where the default OS failed to meet it even with four CPUs. The paper reports similar success across other stacks and robots (Jackal, Cobot), supporting the view that automated configuration tuning is a promising direction for robot deployments.

What carries the argument

The load-bearing pieces are (1) cgroup cpu.max controls that cap CPU usage per ROS node, (2) adaptors, a ~150-line modification to ROS's communication library that inserts a per-subscriber message filter to throttle data flows without code changes, and (3) Bayesian optimization over the combined cgroup/adaptor configuration space, using a developer spec that separates core services (constraints) from non-core apps (objectives). Runtime monitoring via eBPF, rosmaster polling, and a constraint monitor detects context shifts and triggers re-optimization or reuse of cached configs.

What would settle it

Run the Basic navigation stack on Spot under ConfigBot's tuned ~1-CPU configuration through an obstacle course while logging both command-velocity frequency and physical stability (IMU-based stumble or collision events); if the robot stumbles during intervals where the 35 Hz constraint is continuously satisfied, the link between the optimized metric and robot stability is broken.

Watch

Extended reading notes

Core claim

The central claim is that robot resource allocation can be treated as an online, context-aware configuration search rather than a static provisioning problem. ConfigBot shows that a combination of OS-level cgroup limits, a thin per-subscription message-throttling layer ('adaptors') in ROS, and Bayesian optimization can satisfy developer-specified core-service constraints while maximizing non-core app performance. On Spot's Basic stack, the learned configuration achieved 99.42% constraint satisfaction with roughly one CPU, while the default OS configuration scored 0% and even a default config with 4 CPUs only reached 84.94%. The paper further shows that the optimal configuration is context-specific: a good config for one navigation stack loses satisfaction when applied to another, motivating continuous monitoring and relearning.

Load-bearing premise

The developer-supplied performance metric and its target value faithfully capture what it means for the robot to behave correctly, so that meeting the numeric spec (e.g., 35 Hz command velocity) guarantees the robot is actually stable.

Editorial extensions

If this is right

If ConfigBot's approach holds, robot developers can replace manual trial-and-error tuning with a specification-driven search that keeps core apps stable under resource pressure.
The combination of cgroup limits and data-flow throttling lets non-core apps degrade gracefully under contention, avoiding the thread-oversubscription collapse seen with pure CPU throttling.
Context-specific configs mean robots need continuous monitoring and relearning; a static 'one good config' does not transfer across workloads or environments.
The framework's success on three robot platforms with six stacks suggests OS- and ROS-level automated tuning generalizes beyond the evaluated hardware.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A promising extension is to apply ConfigBot's search to GPU, memory, and network budgets, where the same contention pathologies likely appear.
The paper's future-work sketch of RL-driven proactive tuning could be combined with ConfigBot's reactive loop: a predictive model could pre-empt context shifts before the constraint monitor fires.
Because adaptors work at the ROS pub/sub layer, the same mechanism could be applied to ROS2 and other middleware with similar subscription APIs, potentially widening the impact.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Bottom line: this is a real systems paper with a genuinely useful new mechanism, but the headline stability claims go further than the data supports. It deserves peer review, not acceptance as is.

What's new and good: the per-subscriber ROS adaptor is a real contribution. Intercepting message flows on individual subscription edges and throttling them independently is a lever ROS doesn't expose, and the ~150-line ros_comm modification makes it plausible for others to adopt. The paper also asks a good question—can automated config search replace manual cgroup tuning and static over-provisioning—and answers it with a sensible Bayesian optimization loop over cgroup limits and adaptor thresholds. The evaluation across three robots and six stacks, with default, random, and cgroups-only baselines, is genuinely useful. The cross-evaluation in Table VI, showing no globally optimal config, is a nice honest result that supports their context-dependent relearning argument.

Soft spots: the strongest claims are about end-to-end stability (stumbling, collisions, pauses), but the experiments only measure developer-specified message-rate constraints. On Spot the core constraint is 35 Hz command-velocity publishes; nothing checks whether those commands are computed from fresh perception or produce collision-free motion. The adaptor's entire purpose is dropping messages, so a config could sustain 35 Hz while starving perception, and the metric wouldn't care. Table III attributes failures to low update rates, but no experiment restores update rate and then measures those failure modes directly. That gap is real, and the abstract's "maintaining system stability" goes beyond what the measurements show.

Methodologically, the headline percentages are single-run, without error bars or significance tests. Table IV's "Default (4x CPUs)" only reaches 84.94% satisfaction, which does support the over-provisioning argument, but the 49–193% non-core improvement ranges need variance. There's also an oddity in Table V: ConfigBot-cg shows 100% satisfaction on Terrain while ConfigBot shows 96%—the text explains the non-core tradeoff, but not the satisfaction drop. No code or data is provided, which hurts reproducibility. The VI-A assumption that developer-defined metrics capture correct robot behavior is asserted rather than argued; the paper says metrics are "often easy to define," and the whole evaluation inherits that assumption.

Who this is for: systems researchers working on resource management for ROS robots. The adaptor idea alone is worth citing. The mechanism is sound, the evaluation is suggestive but not airtight, and the stability claims need a direct behavioral test. I'd send it to review: the adaptor contribution is enough to merit expert scrutiny, and the authors can reasonably be asked to add repeated trials and, ideally, a behavioral check (actual collision counts or stabilization success) before publication.

Referee Report

4 major / 6 minor

Summary. The paper presents ConfigBot, a runtime resource-allocation framework for ROS-based service robots. ConfigBot treats core robot services as constrained optimization targets and non-core apps as objectives, then uses Bayesian optimization to tune per-node Linux cgroup CPU limits and ROS-layer adaptor thresholds that throttle message rates on selected subscription edges. The system monitors for new processes and nodes and triggers relearning when context changes. Experiments on three robots (Spot, Jackal, Cobot) and six stacks compare ConfigBot against default OS configurations, three random configurations, and a cgroups-only ablation, reporting core constraint satisfaction rates and non-core app performance. Headline results include meeting a 35 Hz command-velocity target on Spot with about 1 CPU where the default configuration fails with 4 CPUs, and improved non-core performance of 49-193% over default.

Significance. If the empirical results hold, ConfigBot would be a practical contribution to robot resource management: it combines OS-level cgroup control with a transparent, application-agnostic ROS-layer adaptor abstraction, and it evaluates on multiple real robots and stacks with several baseline comparators, including random configurations and an ablation. These are genuine strengths. However, the central evidence currently consists of single-run point estimates, and the success metric is the same developer-specified objective that ConfigBot optimizes; no behavioral validation links satisfaction rates to collision-free or stable operation. The claimed end-to-end stability and real-world effectiveness therefore require additional evidence before the paper's central claims are fully supported.

major comments (4)

[§VIII-A, §VIII-B, Tables IV-VII] All headline quantities in Tables IV-VII are single-run percentages or single non-core performance values, with no standard deviations, confidence intervals, or numbers of repeated trials. Because Bayesian optimization is stochastic and robot experiments are noisy, differences such as ConfigBot 100% vs. Random-1 99.3% in Table V, or ConfigBot 100% vs. ConfigBot-cg 100% in the Basic and Intermed rows, may be within noise. The claims of 'near-perfect satisfaction' and '49-193% better' non-core performance are not yet supported by the reported data. Please report repeated runs with distributions, and use an appropriate significance test or effect-size metric, or explain why single runs are representative.
[§VI-A, §VIII-A, Table III] The abstract and Table III claim that ConfigBot maintains system stability, listing failure modes such as stumbling, collisions, and pauses and attributing them to low update rates. However, Tables IV-VII measure only whether the developer-specified metric Ji (e.g., a 35 Hz command-velocity publish frequency) is satisfied and what the non-core performance value is; no experiment records collisions, stumbles, pauses, or manipulation errors under ConfigBot versus default configurations. Since adaptors drop messages and cgroups throttle computation, satisfying the publish-rate constraint does not by itself imply fresh perception inputs or stable control. The conclusion that ConfigBot 'maintains system stability' is therefore unsupported; please add direct behavioral outcome measurements or explicitly limit the claims to meeting developer-specified performance constraints.
[§VI-A] The optimization problem and the evaluation both rest on the assertion that developer-provided metrics and targets are 'reasonable' and 'often easy to define,' but no support or validation is given. This assumption is load-bearing because ConfigBot optimizes only Ji; if a 35 Hz publish rate can coexist with stale odometry or starved perception, the satisfaction rates in Tables IV-VII do not imply effective robot behavior. Please validate the proxy for at least the headline Spot/Basic case (e.g., by showing that command velocities are computed from fresh LiDAR and odometry under the tuned configuration), or reframe the contribution as meeting developer specifications rather than achieving end-to-end stability.
[§VI-B, §VIII-D] The dynamic-adaptation contribution is not quantified. Section VIII-D reports that the eBPF monitor detects new nodes in under 2 seconds, but the time to converge to a new configuration (number of Bayesian optimization iterations, the 5-second profiling rounds, total downtime, and whether constraints were violated during retraining) is not reported. Without this information, the claim that ConfigBot 'quickly reapplies' configurations and handles dynamic changes is not fully supported. Please report the timing and overhead of initial learning and relearning, including the configuration-library hit path.

minor comments (6)

[Abstract] The abstract contains a typo: 'ConifgBot' should be 'ConfigBot'.
[Table V and §VIII-B] The non-core performance values in parentheses (e.g., '2.12', '1.45') lack units and a definition; please state what 'obj performance' measures (frames per second, messages per second, or a composite score) in the text or table caption.
[Table VI] The entry '45.31 ( 1.52)' appears to be missing a percent sign or decimal point; it should likely read '45.3% (1.52)'.
[§VI-B] The Bayesian optimization implementation is underspecified: the surrogate model, acquisition function, and hyperparameters are not given, which makes reproduction difficult. Please add these details or cite a specific implementation.
[Fig. 3] The adaptor symbol in Figure 3 appears as a blank placeholder '( )' in the rendered text; please ensure the symbol is visible in the final version.
[§VIII-B] The sentence 'between 49% (for Intermed) to 193% (for Terrain)' is ambiguous about the baseline and whether the percentages are relative improvements; please clarify with a formula or explicit comparison.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: ConfigBot is evaluated against external baselines and the headline result is an achieved optimization objective, not a disguised re-statement of its inputs.

full rationale

ConfigBot's optimization objective (§VI-A) is to maximize non-core performance subject to Ji(c) ≥ Joi for core apps, and its primary evaluation metric is the rate at which those same constraints are satisfied (§VIII). This is self-referential in a weak sense — success is measured by the controller's own objective — but it does not reduce the paper's claims to its inputs by construction. Bayesian optimization does not guarantee constraint satisfaction, and the paper grounds its results with external comparators: default OS configurations, random configurations, and ConfigBot-cg (cgroups-only) ablations. The high satisfaction rates are therefore meaningful as an achieved outcome of the search process, not as a fitted quantity renamed as a prediction. Self-citations ([2], [4], [11], [12], [21]) appear only as background or as descriptions of workloads used in evaluation; none is invoked as a load-bearing uniqueness theorem or as justification for the core mechanism. The paper does not smuggle an ansatz via citation, nor does it rename a known result. The limitation that developer-specified metrics may not capture true robot stability is explicitly acknowledged (§VI-A, §IX) and is a correctness or validity concern, not a circularity concern.

Assumptions & free parameters 4 free parameters · 4 assumptions · 1 invented entities

The system rests on a small set of domain assumptions: accurate developer metrics, stable contexts, safe message dropping, and known core/non-core categorization. The hand-chosen adaptor threshold, profiling window, and monitor period are design parameters that influence results, while Bayesian optimization hyperparameters are unreported. No theoretical free constants are fitted; the tuned cgroup and adaptor values are outputs of the system rather than upstream assumptions.

free parameters (4)

Adaptor insertion rate threshold = 5 Hz
Hand-chosen cutoff in Section VI-B (conditions A and B) to reduce the number of adaptor knobs; determines which data flows can be throttled and therefore shapes the achievable performance.
Per-configuration profiling window = 5 seconds
Chosen profiling duration per Bayesian optimization iteration in Section VI-B; too short may misestimate performance, too long slows the learning process.
rosmaster monitor wakeup interval = 30 seconds
Periodic check for new ROS nodes in Section VI-B; sets detection latency when the eBPF wakeup mechanism is not triggered.
Bayesian optimization hyperparameters = not specified
Kernel, acquisition function, initialization, and iteration count are not reported; these choices materially affect convergence and final configuration quality.

assumptions (4)

domain assumption Developer-provided performance metrics Ji and targets Joi are accurate proxies for correct robot behavior.
Stated in Section VI-A as 'This assumption is reasonable, as such metrics are often easy to define'. The entire optimization objective and evaluation use these metrics, so an inaccurate metric would invalidate the central claim of maintaining system stability.
domain assumption Workloads and environments are stable long enough for a profiled configuration to remain valid.
Section I says ConfigBot 'optimizes resource allocation infrequently targeting stable environments with consistent workloads'. If contexts shift faster than profiling and Bayesian optimization converge, learned configurations will be stale.
domain assumption Dropping or throttling messages at adaptors is semantically safe for non-core apps and does not break core services.
Section V claims adaptors are application-transparent, but the paper does not verify that message loss preserves application correctness across all stacks. If dropping data corrupts app state, the adaptor mechanism could harm the very services it protects.
domain assumption Core and non-core application categorization is available to the developer.
The optimization formulation in Section VI-A treats core services as constraints and non-core apps as objectives; the categorization is assumed given rather than learned or inferred.

invented entities (1)

ROS-layer adaptor
purpose: Per-subscriber message rate and volume control inserted at subscription edges to shape app resource usage transparently.
New abstraction introduced in Section V. Its benefits are demonstrated only in this paper's experiments; no external implementation, independent benchmark, or formal guarantee is provided.

how reviews work

0 comments

Cite this review

Pith. "Pith review of ConfigBot: Adaptive Resource Allocation for Robot Applications in Dynamic Environments." pith.science (2026). https://pith.science/paper/MUDSDWDL

@misc{pith2026250110513,
  author       = {Pith},
  title        = {Pith review of: ConfigBot: Adaptive Resource Allocation for Robot Applications in Dynamic Environments},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MUDSDWDL}},
  note         = {Machine review of arXiv:2501.10513}
}

read the original 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

Figures reproduced from arXiv: 2501.10513 by the authors.

**Figure 1.** Basic-NAV stack. A basic stack (i.e., set of robot apps) w/ sensor processing, navigation, and telemetry [12] 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 resour… view at source ↗

**Figure 2.** Impact of resource constraints can form a useful mechanism to mitigate application contention in the previous section. For instance, the performance degradation seen in Fig 2a- (ii) could trivially be solved by starving the object detection app. In practice, robot developers today manually identify an appropriate cpu.max limit for the new app, ensuring it does not overuse resources, through a combination of trial a… view at source ↗

**Figure 3.** In traditional ROS message passing, every consumer [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 5.** Figure 5: Robots we use: Spot, Cobot, and Jackal (left to right). [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

**Figure 6.** Figure 6: Optimizing Basic with ConfigBot on Spot constraint. The optimizer chooses the highest performing bluedot (i.e. constraints satsified) as the best config; the green solid line tracks the best config identified so far. The constraint satisfaction rate is a binary metric…

**Figure 7.** Figure 7: Histogram: performance of core-services TABLE V: Performance of NAV stack with obj. Basic Intermed Terrain ConfigBot 100% (2.12) 100% (1.79) 96.0% (1.35) ConfigBot-cg 100% (1.78) 100% (1.71) 100% (0.70) Default 22.4% (1.45) 0.0% (1.20) 0.4% (0.46) Random-1 99.3% (0.62)…

**Figure 8.** Figure 8: ConfigBot runtime monitoring + relearning either start the reoptimization process (or reuse a config from the library, if this context has been seen before); however, for illustrative purposes, we don’t do so, and wait for constraint violations to accumulate over a per…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

27 extracted references · 21 canonical work pages

[1]

Llm-personalize: Aligning llm planners with human preferences via reinforced self-training for housekeeping robots,

D. Han, T. McInroe, A. Jelley, S. V. Albrecht, P. Bell, and A. Storkey, “Llm-personalize: Aligning llm planners with human preferences via reinforced self-training for housekeeping robots,” arXiv preprint arXiv:2404.14285, 2024

arXiv 2024
[2]

SYNAPSE: SYmbolic Neural-Aided Preference Synthesis Engine

S. Modak, N. Patton, I. Dillig, and J. Biswas, “Synapse: Learn- ing preferential concepts from visual demonstrations,”arXiv preprint arXiv:2403.16689, 2024

work page Pith review arXiv 2024
[3]

Appld: Adaptive planner parameter learning from demonstration,

X. Xiao, B. Liu, G. Warnell, J. Fink, and P. Stone, “Appld: Adaptive planner parameter learning from demonstration,” IEEE Robotics and Automation Letters, vol. 5, no. 3, pp. 4541–4547, 2020

2020
[4]

Deploying and evaluating llms to program service mobile robots,

Z. Hu, F. Lucchetti, C. Schlesinger, Y. Saxena, A. Freeman, S. Modak, A. Guha, and J. Biswas, “Deploying and evaluating llms to program service mobile robots,”IEEE Robotics and Automation Letters, 2024

work page 2024
[5]

{CherryPick}: Adaptively unearthing the best cloud configu- rations for big data analytics,

O. Alipourfard, H. H. Liu, J. Chen, S. Venkataraman, M. Yu, and M. Zhang, “{CherryPick}: Adaptively unearthing the best cloud configu- rations for big data analytics,” in14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17), 2017, pp. 469–482

work page 2017
[6]

{Config-Snob}: Tuning for the best configurations of networking protocol stack,

M. Bin-Yahya, Y. Zhao, H. Shafieirad, A. Ho, S. Yin, F. Wang, and G. Li, “{Config-Snob}: Tuning for the best configurations of networking protocol stack,” inUSENIX Annual Technical Conference, 2024

work page 2024
[7]

Automatic configuration tuning on cloud database: A survey,

L. Zhang and M. A. Babar, “Automatic configuration tuning on cloud database: A survey,”arXiv preprint arXiv:2404.06043, 2024

arXiv 2024
[8]

{OPPerTune}:{Post- Deployment} configuration tuning of services made easy,

G. Somashekar, K. Tandon, A. Kini, C.-C. Chang, P. Husak, R. Bhag- wan, M. Das, A. Gandhi, and N. Natarajan, “ {OPPerTune}:{Post- Deployment} configuration tuning of services made easy,” in 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), 2024, pp. 1101–1120

work page 2024

Show all 27 references

[9]

{SelfTune}: Tuning cluster managers,

A. Karthikeyan, N. Natarajan, G. Somashekar, L. Zhao, R. Bhagwan, R. Fonseca, T. Racheva, and Y. Bansal, “{SelfTune}: Tuning cluster managers,” in20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), 2023, pp. 1097–1114

2023
[10]

Context dependant iterative parameter optimisation for robust robot navigation,

A. Binch, G. P. Das, J. P. Fentanes, and M. Hanheide, “Context dependant iterative parameter optimisation for robust robot navigation,” in 2020 IEEE International Conference on Robotics and Automation (ICRA). IEEE, 2020, pp. 3937–3943

2020
[11]

Self-supervised terrain representation learning from unconstrained robot experience,

H. Karnan, E. Yang, D. Farkash, G. Warnell, J. Biswas, and P. Stone, “Self-supervised terrain representation learning from unconstrained robot experience,” inICRA Workshop on Pretraining for Robotics, 2023

2023
[12]

Robofleet: Open source communication and management for fleets of autonomous robots,

K. S. Sikand, L. Zartman, S. Rabiee, and J. Biswas, “Robofleet: Open source communication and management for fleets of autonomous robots,” in 2021 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). IEEE, 2021, pp. 406–412

2021
[13]

Multi-resource packing for cluster schedulers,

R. Grandl, G. Ananthanarayanan, S. Kandula, S. Rao, and A. Akella, “Multi-resource packing for cluster schedulers,”ACM SIGCOMM Com- puter Communication Review, vol. 44, no. 4, pp. 455–466, 2014

2014
[14]

Resource central: Understanding and predicting work- loads for improved resource management in large cloud platforms,

E. Cortez, A. Bonde, A. Muzio, M. Russinovich, M. Fontoura, and R. Bianchini, “Resource central: Understanding and predicting work- loads for improved resource management in large cloud platforms,” in Proceedings of the 26th Symposium on Operating Systems Principles, ser. SOSP...

2017
[15]

Learning delicate local representations formulti-personposeestimation,

Y. Cai, Z. Wang, Z. Luo, B. Yin, A. Du, H. Wang, X. Zhang, X. Zhou, E. Zhou, and J. Sun, “Learning delicate local representations formulti-personposeestimation,”in ComputerVision–ECCV2020:16th European Conference, Glasgow, UK, August 23–28, 2020, Proceedings, Part III 16. Spri...

2020
[16]

A coarse-fine network for keypoint localization,

S. Huang, M. Gong, and D. Tao, “A coarse-fine network for keypoint localization,” in Proceedings of the IEEE international conference on computer vision, 2017, pp. 3028–3037

2017
[17]

Improving multiple object tracking with single object tracking,

L. Zheng, M. Tang, Y. Chen, G. Zhu, J. Wang, and H. Lu, “Improving multiple object tracking with single object tracking,” in IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2021

2021
[18]

Effective compression of range data streams for remote robot operations using H.264,

F. Nenci, L. Spinello, and C. Stachniss, “Effective compression of range data streams for remote robot operations using H.264,” inIEEE/RSJ International Conf. on Intelligent Robots and Systems, 2014

2014
[19]

Edge assisted real-time object detec- tion for mobile augmented reality,

L. Liu, H. Li, and M. Gruteser, “Edge assisted real-time object detec- tion for mobile augmented reality,” inThe 25th annual international conference on mobile computing and networking, 2019, pp. 1–16

2019
[20]

Fogros2: An adaptive platform for cloud and fog robotics using ros 2,

J. Ichnowski, K. Chen, K. Dharmarajan, S. Adebola, M. Danielczuk, V. Mayoral-Vilches, N. Jha, H. Zhan, E. LLontop, D. Xu, et al., “Fogros2: An adaptive platform for cloud and fog robotics using ros 2,” in2023 IEEE International Conference on Robotics and Automation (ICRA). IEE...

2023
[21]

Principles and guidelines for evaluating social robot navigation algorithms,

A. Francis, C. Pérez-d’Arpino, C. Li, F. Xia, A. Alahi, R. Alami, A. Bera, A. Biswas, J. Biswas, R. Chandra, et al., “Principles and guidelines for evaluating social robot navigation algorithms,” arXiv preprint arXiv:2306.16740, 2023

2023 arXiv
[22]

Dynamicalgorithmselection for mobile robots motion planning,

W.Tang,L.Zheng,M.Jiang,andZ.Ding,“Dynamicalgorithmselection for mobile robots motion planning,” in6th International Conference on Dependable Systems and Their Applications, 2019, pp. 499–500

2019
[23]

Completely fair scheduler,

C. S. Pabla, “Completely fair scheduler,”Linux Journal, vol. 2009, no. 184, p. 4, 2009

2009
[24]

Grounded sam: Assembling open-world models for diverse visual tasks,

T. Ren, S. Liu, A. Zeng, J. Lin, K. Li, H. Cao, J. Chen, X. Huang, Y. Chen, F. Yan,et al., “Grounded sam: Assembling open-world models for diverse visual tasks,”arXiv preprint arXiv:2401.14159, 2024

2024 arXiv
[25]

eBPF: Extended Berkeley Packet Filter,

eBPF Community, “eBPF: Extended Berkeley Packet Filter,” https://ebpf.io/, 2025, accessed: 2025-03-01

2025
[26]

Phoenix stack army research lab,

“Phoenix stack army research lab,” 2025. [Online]. Available: https://arl.devcom.army.mil/cras/sara-cra/sara-overview/

2025
[27]

Yolov11: An overview of the key archi- tectural enhancements,

R. Khanam and M. Hussain, “Yolov11: An overview of the key archi- tectural enhancements,”arXiv preprint arXiv:2410.17725, 2024

2024 arXiv

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

Llm-personalize: Aligning llm planners with human preferences via reinforced self-training for housekeeping robots,

D. Han, T. McInroe, A. Jelley, S. V. Albrecht, P. Bell, and A. Storkey, “Llm-personalize: Aligning llm planners with human preferences via reinforced self-training for housekeeping robots,” arXiv preprint arXiv:2404.14285, 2024

arXiv 2024

[2] [2]

SYNAPSE: SYmbolic Neural-Aided Preference Synthesis Engine

S. Modak, N. Patton, I. Dillig, and J. Biswas, “Synapse: Learn- ing preferential concepts from visual demonstrations,”arXiv preprint arXiv:2403.16689, 2024

work page Pith review arXiv 2024

[3] [3]

Appld: Adaptive planner parameter learning from demonstration,

X. Xiao, B. Liu, G. Warnell, J. Fink, and P. Stone, “Appld: Adaptive planner parameter learning from demonstration,” IEEE Robotics and Automation Letters, vol. 5, no. 3, pp. 4541–4547, 2020

2020

[4] [4]

Deploying and evaluating llms to program service mobile robots,

Z. Hu, F. Lucchetti, C. Schlesinger, Y. Saxena, A. Freeman, S. Modak, A. Guha, and J. Biswas, “Deploying and evaluating llms to program service mobile robots,”IEEE Robotics and Automation Letters, 2024

work page 2024

[5] [5]

{CherryPick}: Adaptively unearthing the best cloud configu- rations for big data analytics,

O. Alipourfard, H. H. Liu, J. Chen, S. Venkataraman, M. Yu, and M. Zhang, “{CherryPick}: Adaptively unearthing the best cloud configu- rations for big data analytics,” in14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17), 2017, pp. 469–482

work page 2017

[6] [6]

{Config-Snob}: Tuning for the best configurations of networking protocol stack,

M. Bin-Yahya, Y. Zhao, H. Shafieirad, A. Ho, S. Yin, F. Wang, and G. Li, “{Config-Snob}: Tuning for the best configurations of networking protocol stack,” inUSENIX Annual Technical Conference, 2024

work page 2024

[7] [7]

Automatic configuration tuning on cloud database: A survey,

L. Zhang and M. A. Babar, “Automatic configuration tuning on cloud database: A survey,”arXiv preprint arXiv:2404.06043, 2024

arXiv 2024

[8] [8]

{OPPerTune}:{Post- Deployment} configuration tuning of services made easy,

G. Somashekar, K. Tandon, A. Kini, C.-C. Chang, P. Husak, R. Bhag- wan, M. Das, A. Gandhi, and N. Natarajan, “ {OPPerTune}:{Post- Deployment} configuration tuning of services made easy,” in 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), 2024, pp. 1101–1120

work page 2024