Ironman: Multidisciplinary Perspectives

• Ironman is a polysemous term denoting systems in endurance sports, astronomical data inference, privacy-preserving ML accelerators, and jet-powered humanoid robotics.
• In triathlon research, it underpins real-time sensing and drafting detection, combining GPS analytics with physiological monitoring for athlete performance.
• In technical domains, Ironman inspires open-source software for exoplanet studies and hardware accelerators that enhance secure computation and innovative robotics design.

Ironman is a polysemous research term whose meaning depends strongly on disciplinary context. In the literature represented here, it denotes: the Ironman triathlon as a setting for pervasive-computing and physiological investigation; “ironman,” an open-source Python package for joint inference of transit photometry, Keplerian radial velocities, and Rossiter–McLaughlin time series in exoplanet studies; “Ironman,” a hardware/software accelerator for oblivious transfer extension in privacy-preserving machine learning; and, by explicit analogy, an “Ironman-style” class of jet-powered humanoid or human-worn flight systems in robotics (Fister et al., 2012, Angelova et al., 2021, Espinoza-Retamal et al., 2024, Lin et al., 22 Jul 2025, Gorbani et al., 1 Jun 2025, Vanteddu et al., 18 Sep 2025).

1. Terminological range

The term has no single technical referent across the cited literature. In sports-oriented work, it names the competition environment and the athletes participating in it. In astronomy, it is stylized in lowercase as a software package. In secure computing, it is a named accelerator whose title is explicitly motivated by the Marvel superhero analogy: a powerful “iron” suit combined with flexibility. In robotics, it appears as an analogy for jet-powered humanoid mobility rather than as the formal name of the platform itself (Lin et al., 22 Jul 2025, Gorbani et al., 1 Jun 2025, Vanteddu et al., 18 Sep 2025).

Domain	Referent	Research function
Pervasive computing / sport	Ironman triathlon	Real-time drafting detection
Physiology	Ironmen athletes	Cardiorespiratory synchronization under extreme stress
Exoplanet astronomy	ironman	Joint fitting of transit, RV, and RM data
PPML hardware	Ironman	OT-extension acceleration with NMP
Aerial robotics	Ironman-style systems	Jet-powered humanoid design analogy

A common misconception would be to treat these usages as variants of one technical program. The papers instead describe independent research lines that share a label. The only direct cross-domain linkage is rhetorical: the OT accelerator explicitly invokes the superhero metaphor, and the robotics papers use “Ironman-style” to denote humanoid flight concepts (Lin et al., 22 Jul 2025, Vanteddu et al., 18 Sep 2025).

2. Ironman triathlon as a pervasive-computing testbed

In the triathlon literature, Ironman is treated as a real-time sensing and rule-enforcement environment. Fister and Fister Jr. describe a drafting-detection concept based on pervasive computing, with competitor-borne mobile devices, a SOAP-based web service, and referee-worn mobile units for alerting (Fister et al., 2012).

The proposed hardware stack comprises a GPS or DGPS receiver sampling at $1\,\mathrm{Hz}$, a wireless modem using a GSM/3G/4G data link, and an on-device Java/Android client implementing a small SOA client via KSOAP2. The server side consists of an Axis2 listener on Apache/Tomcat, context-aware logic for distance calculation and rule application, and a database or in-memory store for recent position tuples. Communication is organized as $1\,\mathrm{Hz}$ UDP/TCP or HTTP–SOAP upload, with the XML/SOAP envelope carrying the tuple $\langle id, lon, lat, alt, t\rangle$ (Fister et al., 2012).

The processing pipeline begins with raw GPS NMEA or DGPS fixes at $\Delta t = 1\,\mathrm{s}$. Incoming geodetic coordinates are transformed to UTM by

$$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$

after which each fix is projected onto the official bike-course polyline to obtain a scalar path length

$$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$

Competitors are then sorted by decreasing path length, and a short-term sliding window such as the last $30\,\mathrm{s}$ of each competitor’s $\langle t,E,N,l\rangle$ is retained for online logic while long-term logs are persisted for post-race audit (Fister et al., 2012).

Drafting detection is formulated geometrically and temporally. Pairwise distance is

$$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$

and ordering is determined by $l_i(t)>l_j(t)$, meaning $1\,\mathrm{Hz}$0 is ahead of $1\,\mathrm{Hz}$1. The rule engine encodes the requirement that the following distance be at least $1\,\mathrm{Hz}$2, except during an overtake, and that the overtake window be at most $1\,\mathrm{Hz}$3. The implementation maintains a per-pair timer,

$1\,\mathrm{Hz}$4

with a violation if $1\,\mathrm{Hz}$5. Neighboring pairs in the leaderboard are checked continuously, and once a breach is flagged, an immediate alert is sent to referee units with geolocation and duration (Fister et al., 2012).

The reported experiments establish feasibility rather than large-scale operational validation. In a precision benchmark with 14 collinear reference points at $1\,\mathrm{Hz}$6 intervals, Garmin Etrex-H (DGPS) yielded $1\,\mathrm{Hz}$7 RMS error, U-blox USB-GPS $1\,\mathrm{Hz}$8 RMS, Samsung Galaxy smartphone $1\,\mathrm{Hz}$9 RMS, and HTC Wildfire smartphone $\langle id, lon, lat, alt, t\rangle$0 RMS; HTC Wildfire gave the best smartphone performance. In a two-athlete drafting simulation on a $\langle id, lon, lat, alt, t\rangle$1 flat loop using Garmin Forerunner 110 devices, the system detected two drafting events, achieved true-positive detection $\langle id, lon, lat, alt, t\rangle$2 $\langle id, lon, lat, alt, t\rangle$3, produced no false positives or false negatives, matched ground truth within $\langle id, lon, lat, alt, t\rangle$4, and exhibited end-to-end latency of approximately $\langle id, lon, lat, alt, t\rangle$5–$\langle id, lon, lat, alt, t\rangle$6. The authors also state a sorting cost of $\langle id, lon, lat, alt, t\rangle$7 at $\langle id, lon, lat, alt, t\rangle$8, with network load $\langle id, lon, lat, alt, t\rangle$9 per athlete per second (Fister et al., 2012).

The limitations are explicit: battery life of off-the-shelf smartphones is insufficient for a full bike leg of up to $\Delta t = 1\,\mathrm{s}$0; GPS multipath and urban-canyon errors can occasionally reach $\Delta t = 1\,\mathrm{s}$1–$\Delta t = 1\,\mathrm{s}$2; and continuous wireless coverage is required. Proposed extensions include specialized low-power high-precision DGPS/Galileo receivers with built-in 4G modems, inertial sensing, device-side drafting timers, fusion with the EasyTime timing system, and eventual use of Galileo full deployment and 4G/LTE broadcast to tighten distance thresholds (Fister et al., 2012).

3. Physiological studies of Ironmen athletes

In physiological research, “Ironmen” refers to athletes exposed to extreme endurance stress. A within-subject study of fourteen seasoned Ironman triathletes examined cardiorespiratory synchronization before and after the full Ironman triathlon while also imposing a cognitive stressor through a five-minute Stroop test (Angelova et al., 2021).

The measurement protocol was technically detailed. Electrocardiogram was acquired at $\Delta t = 1\,\mathrm{s}$3 through a standard three-lead Einthoven triangle configuration, respiration was monitored with a calibrated force transducer on a chest belt, and each session included one minute of quiet baseline breathing immediately before the Stroop task. After the race, with mean recovery time approximately $\Delta t = 1\,\mathrm{s}$4, the identical protocol was repeated. The analysis combined empirical mode decomposition (EMD) with synchrogram analysis based on the Hilbert transform in order to handle noisy, nonstationary signals (Angelova et al., 2021).

EMD decomposes a time series as

$\Delta t = 1\,\mathrm{s}$5

where the $\Delta t = 1\,\mathrm{s}$6 are intrinsic mode functions and $\Delta t = 1\,\mathrm{s}$7 is a final monotonic residue. After decomposition, the analytic signal for each mode is written

$\Delta t = 1\,\mathrm{s}$8

yielding instantaneous phase $\Delta t = 1\,\mathrm{s}$9 and frequency $$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$0. Synchronization is then examined through generalized phase differences,

$$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$1

and, for point-process versus continuous-signal coupling,

$$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$2

with $$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$3 marking the $$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$4th R-peak. Plateau duration in $$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$5 serves as the primary synchronization index (Angelova et al., 2021).

The principal result is that cardiorespiratory synchronization increased post-Ironman race relative to pre-Ironman. Across all fourteen athletes, total synchronized time rose from $$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$6 pre-race to $$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$7 post-race, a ratio of about $$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$8. Lower-order lockings from $$(lat\_zone,\ lon\_zone,\ E,\ N)=\mathsf{Geo2UTM}(lat,lon),$$9 through $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$0 increased by a factor of about $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$1, whereas higher-order ratios $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$2 rose by about $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$3. A Wilcoxon paired test gave $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$4, and no strong correlations emerged between synchronization changes and demographic or performance variables, with $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$5 and all $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$6 (Angelova et al., 2021).

The interpretation offered in the paper is that, although cognitive stress alone tends to disrupt heart–lung coupling, the recovery phase after an Ironman competition strengthens phase-locked interactions because the amount of stress the athletes are recovering from post-competition is greater than the effects of the Stroop test. This suggests that recovery-driven homeostatic re-entrainment may dominate the post-race physiological state. The paper further proposes practical uses: real-time synchrogram or EMD-HHT analysis for recovery monitoring, detection of maladaptation or latent overtraining, and biofeedback or paced-breathing protocols exploiting natural phase-locking frequencies such as $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$7 or $$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$8 (Angelova et al., 2021).

4. ironman in exoplanetary system inference

In astronomy, ironman is a unified, open-source Python package for jointly fitting transit photometry, Keplerian radial-velocity data, and Rossiter–McLaughlin time series in a single probabilistic framework. Espinoza-Retamal et al. describe it as a lightweight interface that reuses specialized packages under the hood while preserving covariance propagation across transit, RV, and RM parameters (Espinoza-Retamal et al., 2024).

Its forward models are assembled from established components. Transit light curves are computed with batman using a quadratic limb-darkening law,

$$l_i(t)=\mathsf{ProjLength}((x_i,y_i),\text{course\_polyline}).$$9

with sampling performed in the transformed limb-darkening variables $30\,\mathrm{s}$0 and $30\,\mathrm{s}$1. Keplerian radial velocities are modeled as

$30\,\mathrm{s}$2

with instrument-specific jitter added in quadrature. For the Rossiter–McLaughlin signal, the package calls rmfit, which implements the analytic Hirano et al. (2010) prescription. It can also infer true 3D obliquity through

$30\,\mathrm{s}$3

Noise models include per-instrument white jitter, optional Matern-3/2 Gaussian processes via celerite for photometry, and linear trends tied to airmass or time (Espinoza-Retamal et al., 2024).

The workflow is organized around instrument-specific inputs. Photometric, RV, and RM time series are supplied as named instruments; the software automatically creates instrument-dependent zero-points, jitters, and, for photometry, optional GP hyperparameters. Priors may be uniform, log-uniform, Gaussian, truncated Gaussian, or fixed. Composite likelihoods are constructed separately for photometry, RV, and RM data, and inference is performed with a Dynesty dynamic nested sampler, yielding posterior samples, Bayesian evidence, maximum-a-posteriori predictions, residuals, and optional publication-ready posterior plots and parameter tables (Espinoza-Retamal et al., 2024).

The package was applied to HATS-38 b and WASP-139 b, using TESS sectors, multiple ground-based transit light curves, and radial velocities from ESPRESSO, HARPS, FEROS, PFS, and CORALIE. For WASP-139 b, the eccentric model was strongly preferred with $30\,\mathrm{s}$4; for HATS-38 b, the evidence was inconclusive. The inferred sky-projected obliquities were $30\,\mathrm{s}$5 degrees for HATS-38 b and $30\,\mathrm{s}$6 degrees for WASP-139 b. The paper does not present explicit run-time benchmarks or a dedicated synthetic validation suite, but it reports recovery of literature parameters within $30\,\mathrm{s}$7 and consistency across multiple instruments (Espinoza-Retamal et al., 2024).

5. Ironman as an oblivious-transfer accelerator for privacy-preserving AI

In secure computing, Ironman is a co-designed hardware/software accelerator for oblivious transfer extension in privacy-preserving machine learning. The motivating observation is that, in modern hybrid HE/MPC PPML frameworks, nonlinear layers such as ReLU, GELU, and Softmax are evaluated with two-party OT protocols, and that PCG-style OT extension becomes the dominant cost once GPU-accelerated linear layers are optimized. The paper reports that PCG-OTE, specifically SPCOT plus LPN, accounts for $30\,\mathrm{s}$8–$30\,\mathrm{s}$9 of total latency (Lin et al., 22 Jul 2025).

The design separates two bottlenecks. SPCOT is treated as compute-bound because it requires many PRG calls, while LPN encoding is treated as memory-bandwidth-bound because it performs irregular random XORs. For SPCOT, the accelerator replaces a 2-ary AES-based GGM expansion with a hardware-friendly $\langle t,E,N,l\rangle$0-ary scheme using a fully pipelined ChaCha8 core with $\langle t,E,N,l\rangle$1. A 4-ary tree reduces call count, and one ChaCha8 invocation yields four 128-bit blocks. The paper’s ablation reports: 4-ary + AES gives a $\langle t,E,N,l\rangle$2 speedup; 2-ary + ChaCha8 gives $\langle t,E,N,l\rangle$3; and 4-ary + ChaCha8 gives $\langle t,E,N,l\rangle$4 over the baseline SPCOT. A hybrid traversal schedule combines breadth-first expansion within levels with inter-tree parallelism across multiple trees, achieving $\langle t,E,N,l\rangle$5 utilization of the 8-stage ChaCha8 unit using only $\langle t,E,N,l\rangle$6 buffer memory (Lin et al., 22 Jul 2025).

For LPN, Ironman attaches near-memory processing engines directly to the DRAM buffer. Each DIMM buffer chip hosts one DIMM-NMP module for SPCOT and output combination and two Rank-NMP modules for LPN slices. To improve effective memory bandwidth, the system sorts column indices at compile time through column swap and row look-ahead, then uses a memory-side cache. The bandwidth model is

$\langle t,E,N,l\rangle$7

where $\langle t,E,N,l\rangle$8 is the cache hit rate. The paper reports cache hit rates up to $\langle t,E,N,l\rangle$9–$$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$0 with a $$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$1–$$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$2 on-buffer SRAM (Lin et al., 22 Jul 2025).

Implementation details are likewise explicit. A DIMM-NMP module contains a ChaCha8 core, a unified sender/receiver XOR unit, and node/XorSum buffers; Rank-NMP modules contain an instruction decoder, index-address generator, memory-side cache, and DRAM interface. Hardware resource figures include $$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$3 and $$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$4 for the ChaCha8 core at $$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$5, $$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$6 or $$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$7 for the shared SRAM depending on cache size, and approximately $$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$8 power per DIMM (Lin et al., 22 Jul 2025).

The reported performance is substantial. Across different NMP configurations, the abstract states a $$d_{ij}(t)=\sqrt{(E_i(t)-E_j(t))^2+(N_i(t)-N_j(t))^2},$$9–$l_i(t)>l_j(t)$0 improvement in OT throughput relative to the full-thread CPU implementation, and a $l_i(t)>l_j(t)$1–$l_i(t)>l_j(t)$2 reduction in end-to-end latency for CNN and Transformer PPML frameworks. More detailed results show that, with a $l_i(t)>l_j(t)$3 cache and 16 ranks, latency ranges from $l_i(t)>l_j(t)$4 to $l_i(t)>l_j(t)$5, corresponding to $l_i(t)>l_j(t)$6–$l_i(t)>l_j(t)$7 speedup over CPU and $l_i(t)>l_j(t)$8–$l_i(t)>l_j(t)$9 over an NVIDIA A6000 GPU; for Bolt BERT-Large at $1\,\mathrm{Hz}$00 bandwidth and $1\,\mathrm{Hz}$01 RTT, latency falls from $1\,\mathrm{Hz}$02 to $1\,\mathrm{Hz}$03, a $1\,\mathrm{Hz}$04 reduction. The main caveats are that low-bandwidth, high-latency networks leave communication dominant, capping end-to-end gains at about $1\,\mathrm{Hz}$05–$1\,\mathrm{Hz}$06, and that deployment assumes custom DRAM buffer–ASIC integration (Lin et al., 22 Jul 2025).

6. Ironman as a robotics analogy for jet-powered humanoid flight

In robotics, Ironman is not the formal name of the platform but an explicit analogy for humanoid flight. The relevant experimental platform is iRonCub 3, a jet-powered humanoid robot, and the later CAD-driven co-design study frames its design space around an “Ironman-style jet-powered humanoid” (Gorbani et al., 1 Jun 2025, Vanteddu et al., 18 Sep 2025).

iRonCub 3 integrates four JetCat P250 Pro turbines, with two mounted on the forearms and two in a custom jetpack. Nominal thrust per turbine is approximately $1\,\mathrm{Hz}$07, for total maximum thrust $1\,\mathrm{Hz}$08. With robot mass $1\,\mathrm{Hz}$09, the thrust-to-weight ratio is

$1\,\mathrm{Hz}$10

Mechanical integration keeps the jetpack and rear force/torque sensors close to the center of mass, tilts the forearm jets slightly outward for yaw and roll control, and uses aluminum alloy brackets together with carbon-fiber composite and Aerogel heat protection. The iCub3 rotary joints remain unmodified; low-level jet control runs at $1\,\mathrm{Hz}$11, joint control at $1\,\mathrm{Hz}$12, and the base-pose estimator at $1\,\mathrm{Hz}$13. Safety interlocks include automatic turbine shutdown when orientation error exceeds about $1\,\mathrm{Hz}$14 and a tether-tension monitor for lateral drift (Gorbani et al., 1 Jun 2025).

The control framework combines Linear Parameter Varying Model Predictive Control with centroidal-momentum dynamics and a second-order nonlinear jet model. State estimation fuses an Xsens MTI-670G IMU, Intel RealSense T265 visual odometry, and six-axis force/torque sensors on each arm and on the jetpack through an Extended or Unscented Kalman Filter. Testing was conducted on the rooftop terrace at the IIT Genoa CRIS center with a $1\,\mathrm{Hz}$15 steel crane, concrete bollards, loose cables, Aerogel shielding, and raised cement tiles. In the reported flight tests, thrust ramps from $1\,\mathrm{Hz}$16 to $1\,\mathrm{Hz}$17 over $1\,\mathrm{Hz}$18; the robot detaches at about $1\,\mathrm{Hz}$19; lift-off begins about $1\,\mathrm{Hz}$20 after the reference; air-time is about $1\,\mathrm{Hz}$21 up to $1\,\mathrm{Hz}$22; roll, pitch, and yaw remain within $1\,\mathrm{Hz}$23; and horizontal drift is $1\,\mathrm{Hz}$24 in $1\,\mathrm{Hz}$25 and $1\,\mathrm{Hz}$26 in $1\,\mathrm{Hz}$27. The paper is explicit that tests use a vertical crane and tethers rather than free-standing operation (Gorbani et al., 1 Jun 2025).

The CAD-driven co-design work generalizes this idea by sampling $1\,\mathrm{Hz}$28 geometrically varied and mechanically feasible designs via a Uniform Latin Hypercube over turbine angle, offsets, mounting height, limb dimensions, and CAD-derived link masses. Each design is instantiated in SolidWorks, checked by FEM, collision-free assembly verification, and joint-limit feasibility, then exported to URDF and MuJoCo XML. The performance objective uses a minimum-jerk trajectory for the center of mass together with a momentum-based linearized MPC, and a multi-objective NSGA-II search minimizes tracking error

$1\,\mathrm{Hz}$29

and mechanical energy

$1\,\mathrm{Hz}$30

The 100-cluster optimization uses population $1\,\mathrm{Hz}$31, generations $1\,\mathrm{Hz}$32, crossover $1\,\mathrm{Hz}$33, and mutation $1\,\mathrm{Hz}$34 (Vanteddu et al., 18 Sep 2025).

Five centroid models repeatedly appear on the Pareto front: IDs 44, 1188, 2586, 4082, and 4256. ID 1188 is reported at $1\,\mathrm{Hz}$35 and $1\,\mathrm{Hz}$36; ID 2586 at $1\,\mathrm{Hz}$37 and $1\,\mathrm{Hz}$38; and IDs 44, 4082, and 4256 in the “knee” region at $1\,\mathrm{Hz}$39–$1\,\mathrm{Hz}$40 and $1\,\mathrm{Hz}$41–$1\,\mathrm{Hz}$42. For an Ironman-style humanoid, the summary recommends a center-knee specimen such as Model 44, with $1\,\mathrm{Hz}$43, $1\,\mathrm{Hz}$44, $1\,\mathrm{Hz}$45, $1\,\mathrm{Hz}$46, $1\,\mathrm{Hz}$47, $1\,\mathrm{Hz}$48, $1\,\mathrm{Hz}$49, and $1\,\mathrm{Hz}$50, describing it as a compromise between agility and endurance with thrust-to-weight ratio around $1\,\mathrm{Hz}$51 and tracking error below $1\,\mathrm{Hz}$52 (Vanteddu et al., 18 Sep 2025).

Taken together, these robotics papers indicate that “Ironman” in this domain functions as a design metaphor for whole-body humanoid flight under severe constraints of thrust-to-weight ratio, thermal management, vibration rejection, and safety interlocks. A plausible implication is that the analogy is useful chiefly at the level of co-design objectives and experimental framing; the demonstrated system is a tethered jet-powered humanoid robot, not a human-worn autonomous flying suit (Gorbani et al., 1 Jun 2025, Vanteddu et al., 18 Sep 2025).