PaperlayerView exact revision on arXiv

Source-linked AI summary

C2Flight: A Closed-Loop Co-Simulation Framework for Early-Stage Evaluation of Heterogeneous UAV Computing Systems

Xizhu Chen, Shuyuan Zhang, Yixuan Li, Huazhong Yang, Yu Wang, Jincheng Yu, Hongyang Jia

arXiv:2610.14715v1cs.RO

TL;DR

Early-stage UAV computing design needs closed-loop evaluation because algorithm, hardware, and communication choices interact, while existing approaches delay system-level feedback until integration. C2Flight represents systems as parameterized graphs and combines component models with accessible hardware through a unified interface. Validation and case studies report timing fidelity, closed-loop prediction, and early-stage design exploration before full integration.

Abstract

from arXiv · show

Early-stage design of heterogeneous UAV computing systems requires evaluating how algorithm, hardware, communication, and system topology affect closed-loop flight before the complete system is available. However, design choices interact through the robotic feedback loop, making task performance difficult to predict from isolated component metrics, while existing execution-driven approaches postpone system-level design feedback until the computing system is integrated. This work presents C2Flight, a closed-loop co-simulation framework that represents target systems as parameterized dataflow graphs and integrates models of hardware under design with independently accessible physical hardware through a unified node interface. Its graph runtime captures the combined effects of buffering, activation, resource sharing, communication, and local timing on closed-loop flight behavior. Validation against onboard and wireless offboard physical computing pipelines confirms its timing fidelity and closed-loop prediction accuracy. Two case studies demonstrate early-stage exploration of deployment and accelerator bit-width choices. These results show that C2Flight exposes system-level design trade-offs before full-system integration, enabling rapid early-stage design refinement.

I. INTRODUCTION

Early UAV computing design couples algorithm, hardware, placement, and topology choices, but their effects on task performance emerge through the robotic feedback loop. C2Flight uses a parameterized graph and unified interface to evaluate modeled and available hardware together before full-system integration.

I. INTRODUCTION

  • Closed-loop task performance is difficult to infer from isolated metrics because algorithm, hardware, and communication choices interact through the robotic feedback loop.For example, low-bit quantization can reduce computation and communication overhead while degrading perception accuracy, obscuring its net task impact.Source: §I · p. 1
  • Existing closed-loop UAV platforms rely on integrated computing systems, delaying system-level design feedback until substantial development effort has been invested.This leaves early exploration open-loop at the system level, with components optimized locally without insight into their combined effect on robotic performance.Source: §I · p. 1
  • C2Flight combines models of unfinished components and links with available implementations to evaluate their coupled effects before full integration.Its parameterized graph allows components to be replaced while preserving timing dependencies, and its unified interface supports hybrid modeled and real-hardware nodes.Source: §I · pp. 1–2
  • Validation against a physical sensing-to-command pipeline and two case studies examine timing fidelity and how accuracy and control latency shape system-level design trade-offs.The early-stage design feedback supports candidate comparison, bottleneck identification, and optimization prioritization.Source: Figure 1 · p. 1, §I · p. 2

II. RELATED WORK

Existing UAV evaluation platforms capture closed-loop effects through simulation or hardware-in-the-loop execution, while early-stage co-design frameworks explore candidate architectures. C2Flight addresses limits in composing partially implemented heterogeneous systems and modeling execution-dependent effects within a unified closed loop.

II. RELATED WORK

  • Execution-driven platforms derive computing behavior from actual pipeline execution, but require the corresponding subsystems to be implemented and integrated.Examples include simulation-based platforms and HIL systems such as MAVBench, Agilicious, and FlightForge.Source: §II · p. 2
  • Early-stage co-design frameworks explore candidate computing architectures before fabrication, using diverse representations such as policy and accelerator simulation, RTL simulation, or abstract subgraphs.EAGERx synchronization assumes fixed node rates and deterministic delays within each episode.Source: §II · p. 2
  • Prior frameworks remain limited in composing partially implemented heterogeneous systems and capturing execution-dependent computation and communication effects within one closed loop.C2Flight uses a graph-based system abstraction and unified model–hardware interface to preserve interaction and timing semantics as components transition from models to hardware.Source: §II · p. 2

III. C2FLIGHT FRAMEWORK

C2Flight describes the target computing system and simulated flight environment, then runs the configured graph to produce timing traces and flight trajectories. Its graph separates interaction policies from node implementations, allowing modeled and physical components to operate in the same UAV workload.

III. C2FLIGHT FRAMEWORK

  • C2Flight takes a target-system description and simulated flight environment as input, producing timing traces and flight trajectories for latency, bottleneck, and task-performance analysis.The system description specifies topology, inter-node policies, and each component’s implementation and timing source.Source: §III · p. 2

A. System Abstraction

  • The parameterized graph separates computation and interaction boundaries from node implementations, with GraphConfig defining inter-node behavior and NodeConfig selecting each node’s function, timing source, and access method.ComputeNodes, CommNodes, and a DroneNode represent processing, independently timed communication, and sensing/control interaction with the environment.Source: §III · p. 2, A. System Abstraction · p. 3

III. C2FLIGHT FRAMEWORK

  • GraphRuntime schedules graph events on a shared target-time axis, carrying environment observations through computation and communication nodes and returning commands to flight dynamics.Replacing node backends leaves graph structure and interaction policies unchanged, so available hardware can be combined with models of unfinished components and links.Source: §III · p. 2, Figure 2 · p. 3

B. Parameterized Dataflow

Parameterized graph policies express data exchange, node activation, execution and resource sharing, and event-time conventions. GraphRuntime applies these rules in causal rounds while advancing graph, backend, and environment events on a shared timeline.

B. Parameterized Dataflow

  • Graph interaction configuration combines data exchange, activation, execution and resource rules, plus a shared time convention.These rules cover buffer and packet selection, triggers and input grouping, execution patterns and resource arbitration, and event priority; Table I presents representative choices.Source: B. Parameterized Dataflow · p. 3, Table I · p. 4
  • GraphRuntime processes causal rounds using the configured time convention, applies transfers and activation, admits tasks under resource rules, and updates downstream readiness.It advances backends to the next graph event, declared clock boundary, or horizon, rejecting skipped interior events and validating backend events.Source: B. Parameterized Dataflow · p. 4
  • The time convention sets publication-first or trigger-first priority for otherwise unordered events within causal rounds, which can change data selected by a coincident trigger.Pipelining separates task initiation from completion, so task latency alone does not determine throughput.Source: B. Parameterized Dataflow · pp. 3–4

C. Closed-Loop Scheduling

GraphRuntime combines node events and graph policies to represent timing and interaction effects while preserving blocked states and enforcing synchronized backend progress.

C. Closed-Loop Scheduling

  • GraphRuntime constructs state from Θg and combines node events, retaining blocked states and terminating unresolved waits or nonconvergent zero-time activity with diagnostic status.Within causal rounds, Θt orders otherwise unordered events using stable tiebreaking; newly generated same-time events enter subsequent rounds.Source: C. Closed-Loop Scheduling · p. 4
  • Assigned-offset tasks mark local output readiness, while receiver visibility begins only after a valid handoff and configured activation and input policies still govern selection.Controlled backends advance to a common boundary constrained by the next graph event, target-clock edge, and horizon; skipped interior events are rejected.Source: C. Closed-Loop Scheduling · p. 4
  • In the environment adapter, Crazyflow advances dynamics and low-level control, while AirSim renders observations without rendering or RPC wall time advancing modeled state.Setpoint readiness, interface submission, and controller consumption are distinct events; graph policies determine submission, while the environment schedule governs controller execution and plant integration.Source: C. Closed-Loop Scheduling · p. 4

D. Node Execution Interface

The node interface gives modeled and physical backends shared task, port, and boundary-event meanings while assigning timing and state-control responsibilities according to backend class.

D. Node Execution Interface

  • The interface defines common task identities, port formats, and boundary events, while NodeConfig selects the backend class, implementation, local timing, and access method.The three classes are call, request, and timed.Source: D. Node Execution Interface · p. 4, Figure 3 · p. 5
  • call handles local software, replay, and forwarding, returning functional outputs with timing supplied by profiles or analytical models and combined with graph policies.For assigned event times, profiles provide offsets from task start; GraphRuntime does not duplicate graph-owned waiting.Source: D. Node Execution Interface · pp. 4–5
  • request accesses task-based hardware through CALL–RESULT exchanges, using configured profiles or local measurements while preserving logical state order and graph-scheduled concurrency.Adapters validate boundaries and clock-unit conversion and must ensure that excluding access time leaves target behavior unchanged.Source: D. Node Execution Interface · p. 5
  • timed supports controlled backends with internal queues, pipelines, or contention, using OFFER, ACCEPT, OUTPUT, TRANSFER, and task-level READY events to coordinate handoffs.Backends retain outputs until transfer and confirm reaching each common boundary through advance(h).Source: D. Node Execution Interface · p. 5, Figure 3 · p. 5
  • Component replacements preserve observable transfers and control inputs when they match boundary behavior for admissible inputs and acceptance histories under fixed conditions.Each interaction has one execution owner, supporting compatible replacement without rebuilding the surrounding graph.Source: D. Node Execution Interface · p. 5

IV. EVALUATION

C2Flight is evaluated against integrated onboard and offboard physical pipelines using hybrid configurations of modeled and real-hardware nodes. The evaluation setup maps the systems into graph nodes, then compares C2Flight modes with subsystem-centric and software-only alternatives.

IV. EVALUATION

  • C2Flight’s timing fidelity and closed-loop prediction accuracy are validated using hybrid modeled and real-hardware nodes against integrated onboard and offboard sensing-to-command pipelines.The physical pipelines serve as references.Source: §IV · p. 5

A. Experimental Setup

  • The onboard graph maps camera capture, GAP8 quantized DroNet perception, UART transfer, and STM32 navigation to separate nodes; the offboard graph represents ROS processes and communication links.The offboard pipeline uses an RTX 4070 workstation running PULP-DroNet at FP32 precision, with graph constraints modeling Wi-Fi buffer capacity and latest-image retention.Source: A. Experimental Setup · p. 5

B. Evaluation Configurations

  • CH combines independently accessed modeled and real-hardware backends, CM uses independent component timing profiles, and SM replaces graph scheduling with serial delay accumulation.SC simplifies sensing and peripheral interactions around the computing subsystem, while SW models algorithmic behavior and vehicle dynamics without target computation or communication delays.Source: B. Evaluation Configurations · pp. 5–6

C. Timing Fidelity Validation

C2Flight’s CM and CH modes closely reproduce command-age distributions and better predict closed-loop task limitations than subsystem-centric and software-only modes. Their trajectory predictions also better capture motion progression than those alternatives.

C. Timing Fidelity Validation

  • CM and CH had normalized W1 errors below 2.5% onboard and 1.9% offboard, while SM’s larger errors highlight the graph scheduler’s role in capturing timing interactions.The validation compared command-age distributions against integrated physical GT pipelines across three independent runs and more than 100 frames in total.Source: C. Timing Fidelity Validation · p. 6

D. Closed-Loop Task Prediction

  • Navigation prediction was tested in an 8.0 m by 1.5 m tunnel with four alternating obstacles, sweeping maximum forward speed at 0.3 m flight height.Task success required the vehicle center to reach x ≥7.8 m without collision before timeout.Source: D. Closed-Loop Task Prediction · p. 6
  • At onboard 1.0 m/s, GT completed 2/7 runs versus CM 0/7, CH 1/7, and SC/SW 7/7; offboard at 1.00 m/s, CM/CH reproduced GT failures while SC/SW completed every run.At offboard 0.75 m/s, CM was more pessimistic than GT, while CH gave a closer completion estimate.Source: Table III · p. 6, D. Closed-Loop Task Prediction · p. 6
  • C2Flight modes better capture motion progression than SC/SW beyond predicting final task outcomes in the onboard 1.0 m/s trajectory analysis.The comparison uses seven seed-matched runs and positions at matched simulation timestamps.Source: Table IV · p. 6, D. Closed-Loop Task Prediction · p. 6

V. CASE STUDY

C2Flight lets designers compare UAV computing systems by closed-loop task performance before full integration. The case studies show how system-level interactions shape that behavior.

V. CASE STUDY

  • The case studies use closed-loop performance to compare candidate UAV computing systems before full-system integration.They examine compute placement and accelerator precision selection.Source: §V · p. 6
  • Figure 4 shows illustrative mean onboard trajectories at 1.0 m/s; Table IV errors are computed from paired runs, not mean curves.Source: Figure 4 · p. 7
  • Further analysis of the evaluation results reveals how system-level interactions shape closed-loop behavior.Source: §V · p. 7

A. Onboard–Offboard Deployment Choice

The case studies examine onboard versus offboard deployment and accelerator bit-width selection. Their results show how timing, accuracy, and system constraints shape closed-loop performance.

A. Onboard–Offboard Deployment Choice

  • The deployment sweep varies image-acquisition request rates from 2 to 20 Hz, comparing effective update period, end-to-end latency, and successful speed cap.Both systems retain computation and communication parameters profiled from their physical implementations.Source: A. Onboard–Offboard Deployment Choice · p. 7
  • As sensing requests increase, overlapping operations can raise command-ready latency while effective update rate eventually plateaus, so excessive requests may degrade control.Source: A. Onboard–Offboard Deployment Choice · p. 7
  • At approximately 15 Hz, onboard computation achieves a higher successful speed cap despite a lower update rate, making it preferred under the evaluated constraints.Source: Figure 5 · p. 7, A. Onboard–Offboard Deployment Choice · p. 7

B. Accelerator Bit-Width Selection

  • Four INT4, INT8, FP16, and FP32 RTL designs are modeled under a common approximate area budget and integrated into the validated onboard system in place of GAP8 perception.The DroNet architecture, UART communication, and STM32 navigation remain unchanged.Source: B. Accelerator Bit-Width Selection · p. 7
  • At 0.75 m/s, INT4 and INT8 outperform wider formats, but their performance diverges at higher speeds.The observed pattern is consistent with a trade-off between INT4 accuracy loss and greater computation and data-movement overhead at larger bit widths.Source: B. Accelerator Bit-Width Selection · p. 7
  • INT8 achieves 5/5 completions at 1.0 m/s, where all other candidates fail.C2Flight identifies INT8 as preferred under the evaluated area, memory-bandwidth, and resource constraints.Source: B. Accelerator Bit-Width Selection · pp. 7–8, Table V · p. 8

VI. CONCLUSION

C2Flight supports closed-loop evaluation of heterogeneous UAV computing systems before full integration. Validation and case studies demonstrate its use for comparing compute placement and accelerator precision, while future work targets physical-flight validation and broader design exploration.

VI. CONCLUSION

  • C2Flight combines a parameterized dataflow graph and unified node interface to model components alongside independently accessible hardware while preserving timing interactions.Source: §VI · p. 8
  • Validation against integrated physical computing pipelines coupled to simulated flight showed close agreement in command timing and closed-loop behavior.Source: §VI · p. 8
  • Future work will extend validation to physical flight and broader operating conditions, streamline profiling and backend integration, and connect C2Flight to automated design-space exploration.Source: §VI · p. 8
Loading 2610.14715v1…