LadyBug: Multi-domain Research Applications

• LadyBug is a polysemous term encompassing climate simulation plugins, software debugging bots, RSSI-based robot localization algorithms, and biological imaging targets.
• Its applications span environmental analysis in Grasshopper/Rhino, UI-enhanced bug localization in Android projects, and precision imaging in CT and neutron transmission studies.
• The term highlights the need for precise domain qualification to ensure accurate bibliographic retrieval and research reproducibility across architecture, software engineering, robotics, and biology.

LadyBug is a polysemous designation in the technical literature rather than a single method, platform, or dataset. In the cited arXiv record, it denotes a parametric environmental-analysis plugin used inside Grasshopper/Rhino for climate-aware building simulation, a GitHub bot for UI-enhanced bug localization in Android apps, and—through a later swarm-localization paper’s description of prior work—an intensity-based localization bug algorithm based on electromagnetic signal strength. Separate imaging papers use ladybug in the biological sense, as the specimen in dynamic X-ray CT and neutron transmission imaging studies (Soltani et al., 2023, Mahmud et al., 7 Aug 2025, Lentzas et al., 2021, Juurakko et al., 2019, Vu et al., 2020).

1. Scope and referents

The term appears across at least four distinct research contexts in the cited literature. The resulting ambiguity is substantive: the same lexical form can refer to environmental simulation software, a software-engineering automation tool, a robotics localization method, or simply the insect used as an imaging target.

Referent	Domain	Function or role
Ladybug plugin	Building simulation	Imports weather data and supports climate, solar-radiation, and sunlight-hours studies
LadyBug GitHub bot	Software engineering	Localizes likely buggy source files for Android apps using issue text and GUI traces
LadyBug algorithm	Robotics	Intensity-based localization and navigation using received electromagnetic signal strength
ladybug specimen	Imaging	Biological target in cone-beam CT and neutron transmission imaging

In the building-simulation paper, Ladybug is paired with Honeybee as part of a Grasshopper/Rhino workflow for optimizing a kinetic double-skin façade (Soltani et al., 2023). In the software-engineering paper, LadyBug is a GitHub App/bot integrated into issue tracking and driven by UI-enriched retrieval over Android repositories (Mahmud et al., 7 Aug 2025). In the swarm-robotics paper, LadyBug is not the main contribution but the prior algorithmic substrate that the authors explicitly extend from robot-centric self-localization toward swarm-level global localization (Lentzas et al., 2021). The imaging papers are terminologically different in kind: they concern a ladybug specimen rather than a system named LadyBug (Juurakko et al., 2019, Vu et al., 2020).

2. Environmental simulation and kinetic façade optimization

In architectural computation, Ladybug is described as the Grasshopper/Rhino plugin that imports standard EnergyPlus weather files, provides 2D and 3D climate graphics, supports solar radiation studies, supports sunlight hours modeling, and assists early-stage environmental decision-making (Soltani et al., 2023). In the cited study, it forms the weather- and climate-data layer of a parametric workflow for optimizing a kinetic second-skin façade on the south-facing façade of a two-story open-plan office building in Shiraz, Iran.

The building model is defined with 2 floors above ground, floor height 4 m, floor area 39.66 m², north-south length 7 m, east-west width 6 m, HVAC set to Ideal Air Loads, operating hours from 8 am to 4 pm, and materials based on ASHRAE 189.1-2009. Weather data came from Shahid Dastghib Airport station, and the study period was in August. The overall computational loop is explicit: geometry is built in Rhino/Grasshopper, weather data are imported through Ladybug, thermal and daylight simulation is set up through Honeybee, EnergyPlus-based simulation is executed, and the resulting operational energy consumption is passed to a BB-BC optimizer implemented in Python.

Honeybee, in this workflow, performs daylight analysis and thermodynamic/energy analysis by linking Grasshopper geometry to EnergyPlus and OpenStudio. Ladybug therefore serves neither as geometry engine nor optimizer; it is the environmental-context provider that conditions the search over façade states. The second skin consists of 16 modules, each containing up to 16 foldable square elements. The primary design variables are the angle of rotation or folding and the arrangement of module elements, with fold angle reported in the range $0 \le \theta \le 1.57 \text{ rad}$. The optimization objective is $\min OEC$, where OEC is the operational energy consumption needed for air conditioning.

The optimization framework uses the Big Bang–Big Crunch algorithm. The paper gives the center-of-mass update

$$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$

and describes new-solution generation as

$$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$

Reported constraints include $R_{\min} = 0.50 \text{ rad}$, $R_{\max} = 1.57 \text{ rad}$, $Sample = 3$, $Iter = 15$, and $a = 0.3$.

The experiment proceeds in three stages. The baseline building without a second skin yields $OEC = 2.76 \text{ kWh/m}^2$. The best optimized static second skin yields $\min OEC$0, reported as a 28% reduction relative to baseline. In the daily kinetic case, optimization is performed separately over three one-day intervals, with best daily results of $\min OEC$1, $\min OEC$2, and $\min OEC$3; the paper states that kinetic operation reduces energy consumption by 4% relative to the static optimized version. The same paper also notes a 25% reduction for the optimized parametric double-skin façade in its conclusion, alongside the 28% figure elsewhere. Taken together, these results position Ladybug as the environmental simulation component of a climate-conditioned parametric design loop rather than as the optimization method itself (Soltani et al., 2023).

3. UI-enhanced bug localization for Android repositories

In software engineering, LadyBug is a GitHub bot for file-level bug localization in Android apps. Its defining premise is that bug-report text alone often leaves a substantial semantic gap between reported behavior and the source files that likely contain the defect; LadyBug augments text retrieval with GUI interaction information extracted from a bug reproduction trace (Mahmud et al., 7 Aug 2025).

The system is organized into three components. MetaMorph, a companion desktop application, records and replays bug reproduction traces and exports GUI interaction data. A ProBot GitHub connector, built on Probot, Node.js, and Octokit, handles repository installation and issue-creation webhooks. A localization engine implemented as a Flask/Python backend clones repositories, preprocesses source code, computes embeddings, processes issue reports and traces, and ranks source files. During repository initialization, the bot records the repository identifier and latest commit SHA, clones the default branch, keeps only .java source files, preprocesses them, computes embeddings, stores those embeddings in a database, and posts status updates back to GitHub.

The preprocessing pipeline is structured as sanitization, tokenization, normalization, and segmentation. Sanitization removes comments, imports, and special characters. Tokenization splits source into syntactic tokens. Normalization removes stop tokens and boilerplate and lemmatizes identifiers and literals. Segmentation divides files exceeding 500 tokens into semantically coherent segments. For embeddings, the paper states that LadyBug uses UniXCoder for both source code and bug-report text, while emphasizing extensibility to other embedding models, including LLM-based alternatives.

GUI evidence is supplied through execution.json, produced from reproduction traces. MetaMorph captures input with getevent, captures screen state with screencap, and uses uiautomator during replay to identify interacted widgets. LadyBug extracts two categories of UI terms from the trace: Screen Component terms, corresponding to resource IDs of widgets or components interacted with, and GUI Screen terms, corresponding to Activity or Fragment names. These terms drive three retrieval augmentations. Query reformulation appends Screen Component terms to the original bug report. Filtering retains only files related to relevant screens when a source file contains any Screen Component term. Boosting moves files containing GUI Screen terms to the top of the ranked list while preserving relative order.

The workflow is issue-centric. A developer installs LadyBug on a repository, reproduces the bug manually or automatically, attaches the bug description and execution.json to a GitHub issue, and receives a ranked list of likely buggy files as a bot comment. The evaluation uses RedWing, an automated benchmark of 80 fully localized and reproducible bug reports from 39 open-source Android applications. The comparison isolates GUI augmentation by contrasting UniXCoder-GUI with UniXCoder-No GUI. The reported results are: Hits@1 of 0.30 versus 0.20, Hits@5 of 0.74 versus 0.61, Hits@10 of 0.81 versus 0.68, MAP of 0.39 versus 0.31, MRR of 0.44 versus 0.36, and Effectiveness of 13.81 versus 16.41. The paper highlights a 16.2% relative increase in Hits@10 when GUI information is used. Within this usage, LadyBug is therefore a retrieval-augmentation and workflow-integration system that combines issue text, reproduction traces, and source-code embeddings inside GitHub itself (Mahmud et al., 7 Aug 2025).

4. RSSI-based localization and swarm-global coordinates

In robotics, LadyBug is described—by a later paper that extends it—as an intensity-based localization bug algorithm. That paper cites Lentzas and Vrakas (2020), “LadyBug. An Intensity based Localization Bug Algorithm,” and characterizes LadyBug as a method in which a robot with sensors measuring received electromagnetic signal strength can infer the location of the signal source and navigate toward it. The source may be a beacon or another robot. The same paper states that LadyBug was effective and had benefits over related approaches such as I-Bug (Lentzas et al., 2021).

The cited arXiv contribution does not present the original LadyBug algorithm directly; instead, it extends the localization scheme toward global localization for a swarm in unknown, GPS-free, and landmark-free environments. The central idea is to use three stationary robots or beacons emitting electromagnetic signals to define a shared 3D coordinate system, within which other robots localize themselves via RSSI. This shifts the problem from local source localization in a robot-centric frame to global localization in a common swarm frame.

The robot model includes three receivers on the perimeter—front, left, and right—and one transceiver at the center; an enhanced version uses five sensors total with redundant receivers. The paper states an inverse-square signal model, $\min OEC$4, where stronger signal strength implies shorter distance. Using robot geometry, it writes a system of distance equations for the source coordinates $\min OEC$5, including

$\min OEC$6

$\min OEC$7

$\min OEC$8

and

$\min OEC$9

By subtracting equations, $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$0 and $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$1 can be recovered; substitution then yields $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$2. The enhanced localization scheme forms four sensor groups, each a triangle comprising the center transceiver and two perimeter receivers, computes four source estimates, and averages them.

Global localization is then constructed from three beacons: $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$3 as the center of the global coordinate system, $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$4 defining the global $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$5-axis, and $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$6 defining the global $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$7-axis. After localizing $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$8, $$X_c = \frac{\sum_{i=1}^{n} \frac{1}{f_i} X_i}{\sum_{i=1}^{n} \frac{1}{f_i}},$$9, and $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$0 in the robot-centric frame, the method forms vectors $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$1 and $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$2, computes a normal via $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$3, and derives the remaining axes, with the paper giving $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$4. Robot position is expressed by projecting the vector from $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$5 to the robot onto the global basis: $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$6

Experiments were performed in Webots with four identical round robots of 20 cm radius, three acting as beacons. Each source localization used an average over 100 RSSI packets. The primary metric was Euclidean localization error between true and estimated global position. Under Gaussian noise, reported error was about 0.6 m at 10% noise and about 1.4 m at 20% noise. In a distance-to-beacon experiment with three beacons in an isosceles triangle of side length 4 m and noise fixed at 10%, the error could be as low as 0.1 m when the robot was close to the source, performed best at approximately 3–3.5 m, remained under 1 m up to nearly 6 m, and degraded beyond that. The paper’s conclusion explicitly frames future work as integration of this global-localization infrastructure with LadyBug, making the latter the local intensity-based component and the new method the shared-coordinate extension for swarm operation (Lentzas et al., 2021).

5. Biological imaging uses of the ladybug specimen

Two arXiv papers use ladybug not as a software or robotics label but as the biological target of imaging experiments. These uses are terminologically adjacent but conceptually separate from the software and algorithmic senses of LadyBug.

The first is an open dynamic 3D cone-beam CT dataset of a ladybug, created to provide realistic time-varying tomographic data for research in dynamic and limited-data CT reconstruction (Juurakko et al., 2019). The dataset consists of eight separate CT measurements stored as MATLAB files named sinogram1.mat through sinogram8.mat. Each file contains a 3D cone-beam sinogram of size $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$7, where 1024 is detector width, 360 is the number of projection angles, and 186 is the number of selected detector rows from the full 967 measured rows. The sinograms are log-transformed and normalized, and the 186 rows were chosen from the central horizontal cross-sections of the ladybug target. The eight scans correspond to different starting positions of the same object, which constitutes the dynamic aspect of the dataset. Acquisition used a Procon X-ray CT portable device at Aalto University with a 50 kV source, 50 W maximum output, 400 ms exposure time, 400 mA tube current, detector pixel size of 48 $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$8m, raw image size $$X_i^{k+1} = X_c + r \cdot \frac{a (X_{\max} - X_{\min})}{k+1}.$$9, focus-to-object distance 111 mm, and focus-to-detector distance 241 mm. The dataset is explicitly intended for dynamic, sparse-view, and limited-angle tomographic reconstruction, and the paper formalizes the measurement model as $R_{\min} = 0.50 \text{ rad}$0.

The second paper demonstrates neutron transmission imaging of a dried seven-spotted ladybug using a four-channel superconducting detector based on the current-biased kinetic inductance detector, or CB-KID (Vu et al., 2020). In that system, a $R_{\min} = 0.50 \text{ rad}$1B conversion layer converts neutrons into charged particles, which create hot spots in orthogonal superconducting meanderlines. Position reconstruction uses four arrival timestamps in a delay-line readout over a 15 mm $R_{\min} = 0.50 \text{ rad}$2 15 mm sensitive area, with reported average position increments of approximately $R_{\min} = 0.50 \text{ rad}$3 in $R_{\min} = 0.50 \text{ rad}$4 and $R_{\min} = 0.50 \text{ rad}$5 in $R_{\min} = 0.50 \text{ rad}$6. A $R_{\min} = 0.50 \text{ rad}$7B dot absorber array was used to establish spatial homogeneity and linearity, with measured pitches close to the nominal 250 $R_{\min} = 0.50 \text{ rad}$8m. The ladybug transmission image was rendered using an average pixel size of about $R_{\min} = 0.50 \text{ rad}$9 and was reported to resolve the two elytra, six legs, pronotum, eyes, antennas, flight muscle, and cuticle supporting the wings. The paper presents this as noninvasive characterization of an intact specimen, while also noting that operation at 4 K yielded rather low simultaneous X-and-Y detection efficiency.

These imaging papers matter to the disambiguation of LadyBug because they demonstrate a recurrent lexical confusion in search and citation practice: ladybug may designate the insect subject of a dataset or imaging experiment rather than the name of a computational method (Juurakko et al., 2019, Vu et al., 2020).

6. Disambiguation in citation and research practice

The cited literature does not support treating LadyBug as a unified research artifact. Instead, it identifies a family of unrelated usages distributed across architecture, software engineering, robotics, and imaging. The building-simulation Ladybug is a plugin that supplies weather and environmental analysis inside a Grasshopper/Honeybee workflow (Soltani et al., 2023). The software-engineering LadyBug is a GitHub bot that combines issue text, reproduction traces, and neural embeddings for source-file ranking (Mahmud et al., 7 Aug 2025). The robotics LadyBug is an intensity-based localization bug algorithm whose role, in the cited arXiv paper, is primarily that of antecedent method to be extended into a global RSSI-based swarm-localization framework (Lentzas et al., 2021). The imaging papers use ladybug only as the specimen name (Juurakko et al., 2019, Vu et al., 2020).

A plausible implication is that any technical discussion of LadyBug should be domain-qualified at first mention. In practice, this means pairing the name with its field and, where possible, an arXiv identifier or explicit system description. Without that qualification, statements such as “LadyBug uses weather data,” “LadyBug improves Hits@10,” or “LadyBug localizes a source using RSSI” are all individually correct within their own literatures yet mutually incompatible across domains.

A second plausible implication concerns search reproducibility. Because the same lexical token indexes both named systems and zoological specimens, bibliographic retrieval by title alone can conflate architectural simulation, issue-driven bug localization, swarm robotics, and biological imaging. For technical readers, the relevant unit of reference is therefore not the string LadyBug by itself, but the string plus domain-specific context: environmental simulation in Grasshopper, Android bug localization in GitHub, RSSI-based robotic localization, or imaging of a ladybug specimen.