A quadrotor that flies on LiDAR-inertial odometry closes its control loop on the estimate, so a divergence that nobody notices can cost the vehicle. Many of the failures we met came from the sensors rather than the scene: clock steps, a blocked view, starting while moving, an IMU that clips at impacts. AGIptive-LIOM is a flight-safe, failure-aware LiDAR-inertial odometry for quadrotors: it guards against these faults, knows when its estimate is degraded, and tells the flight controller.

Highlights

• Guards against real sensor faults. A timing layer tells a clock step from a data dropout using the other sensor's timestamps and repairs the step; further guards handle a blocked view, a moving start and merged scans.
• Knows when it is degraded. An onboard health monitor that needs no ground truth reports OK, DEGRADED or FAILED with every scan, including a drift indicator for directions the LiDAR cannot see.
• Tells the flight controller. The monitor sets the quality of the vision message to PX4, so PX4's own filter stops fusing a failed estimate. In simulated closed-loop flights this kept PX4's filter on the truth while the odometry failed.
• Judged by how it fails. Eight methods on identical public recordings, fault injection and closed-loop simulated flights, with failures counted by cause. It is not the most accurate method, and real flights in the loop are still to come.

A hopping robot whose internal IMU clips at every landing (public HOPPER data, one run per method). FAST-LIO2 diverges and Point-LIO drifts; AGIptive-LIOM and RESPLE2 stay at a few centimetres.

Code will be released once the paper is submitted.

EDGE-IO in its cross-platform configuration (in progress). Blue parts are shared by every drone, orange parts are fitted per drone. The benchmark results below train one model per dataset.

Status

Ongoing work. A paper is in preparation (target venue tentative); there is no preprint or public code yet. Authors: Sasanka Kuruppu Arachchige and Joni-Kristian Kämäräinen. This page summarises the method and the results so far, and will be updated as the cross-platform experiments finish.

Publication

Sasanka Kuruppu Arachchige and Joni-Kristian Kämäräinen, EDGE-IO: Calibrated Learned Inertial Odometry Across Quadrotor Platforms, in preparation (venue tentative).

@unpublished{KuruppuArachchige2026EDGEIO,
  author = {Kuruppu Arachchige, Sasanka and Kämäräinen, Joni-Kristian},
  title  = {{EDGE-IO}: Calibrated Learned Inertial Odometry Across Quadrotor Platforms},
  note   = {In preparation},
  year   = {2026}
}

Introduction

A drone's IMU works in the dark, in fog and through motion blur, but integrating it directly drifts within seconds. Learned inertial odometry fixes much of this: a network looks at a short window of IMU data, plus the rotor signals on a quadrotor, and predicts the vehicle's velocity, which an Extended Kalman Filter (EKF) then fuses with the IMU. For that fusion to work, the network also has to say how sure it is. An over-confident prediction pulls the filter off course; an under-confident one is wasted.

EDGE-IO is my framework for building, testing and eventually deploying such estimators on small flight computers. It has three goals:

• Calibrated velocity. Predict a velocity distribution, not just a value, and check that the filter stays statistically consistent.
• A benchmark that can tell real gains from noise. Four public quadrotor datasets, cleaned, with 8 training seeds per model and significance tests.
• One model for many drones. Every dataset logs rotor activity differently (rpm, rad/s, PWM, thrust command), so today each drone gets its own network. EDGE-IO is moving towards one shared encoder that adapts to a new drone from a few minutes of flight.

Built on AI-IO and VeloBins

EDGE-IO builds on two published methods by other groups:

• AI-IO (Cui et al., arXiv 2603.00597, code): a Transformer that regresses body velocity from IMU and rotor speeds, fused in an EKF. EDGE-IO starts from its open-source code and encoder.
• VeloBins (Azhari et al., arXiv 2608.29720): replaces the regression head with a decoder that predicts a probability over 512 velocity bins per axis, trained on error-conditioned Gaussian labels. The mean and variance of that distribution become the filter's measurement and its covariance.

I re-implemented VeloBins on top of the AI-IO encoder in one PyTorch package, matching the paper's parameter counts exactly (69.8k encoder + 6.8k decoder), and fixed several upstream issues on the way, for example an input normaliser that kept updating its statistics during testing and filtering.

Method

• Encoder (shared). A 1 s window at 100 Hz. Separate 1-D convolutions for the accelerometer, the gyroscope and the four rotor signals, followed by a 2-layer, 8-head Transformer.
• Decoder (per platform). The VeloBins bin decoder gives a full velocity distribution per axis. Its mean and variance go to the filter as they are, with no hand-set scaling.
• Filter. The EKF propagates with the raw IMU at 100 Hz and takes a velocity update at 10–20 Hz. Its noise settings are tuned per dataset on validation flights only, and its consistency is measured with the normalised estimation error squared (NEES).
• Thrust map (per platform, in progress). A fitted per-rotor model turns each drone's actuation signal into the same physical unit, mass-normalised thrust in m/s² per rotor, so a shared encoder sees inputs that mean the same thing on every drone.
• Small by design. The full network has 76.7k parameters. A JAX and ROS 2 port for on-board deployment is the next engineering step.

A benchmark that can tell the difference

• Four public datasets: AI-IO, NanoBench, TII-RATM and NeuroBEM, from four different quadrotors and four actuation signals.
• Cleaned data. The cleaning only removes data, and every decision is logged: 20 duplicate NanoBench flights, AI-IO files whose ground truth is 18–51% interpolated, extrapolated tails and ground-truth gaps.
• 8 seeds per model. On the AI-IO data, seed-to-seed spread alone was 6% in velocity error and 22% in trajectory error, the same size as the improvements reported for VeloBins on that dataset. Every comparison below is a mean over 8 seeds with a significance test.
• Fair filtering. The filter for each dataset is chosen on validation data, then frozen for the test flights.

Because the datasets are cleaned, the numbers on this page are not directly comparable with numbers published on the original files. As a check, AI-IO's released model on the cleaned AI-IO data matches the published EKF velocity error to within 0.01 m/s on average, on the test groups the cleaning left intact.

Results so far

The network: VeloBins is better calibrated everywhere

Network alone on the test flights, best-validation checkpoint, mean of 8 seeds per model. NLL scores the predicted distribution against the true velocity; lower means more accurate and better-calibrated uncertainty.

• Uncertainty: VeloBins' predicted distributions fit the true velocity better on all three datasets (NLL lower by 0.40, 1.22 and 0.10; p < 0.001).
• Accuracy depends on the dataset: VeloBins is 8% better in RMSE on TII-RATM, 4% worse on NanoBench, and 15% worse on NeuroBEM at its best-validation checkpoint (2% at its final one).
• On the AI-IO dataset, the same picture holds at 8 seeds: the calibration gain is clear (p < 0.001), while the accuracy difference is within seed-to-seed noise on our cleaned copy.

The filter: tuning matters more than the network

Velocity RMSE of the network alone, with AI-IO's default EKF, and with the EKF tuned per dataset on validation flights. Mean ± std of 8 seeds. Each panel has its own scale.

• The default filter fails on all three datasets. It is strongly over-confident (median NEES 53–150, against 2.37 for a consistent filter) and doubles or triples the network's error.
• Tuning on validation cuts the filter's error by 34–71%. With it, VeloBins + EKF is as good as AI-IO + EKF or better everywhere: 0.517 vs 0.589 m/s on TII-RATM, 0.175 vs 0.176 on NanoBench, 0.632 vs 0.700 on NeuroBEM.
• Check the grid edges. On NeuroBEM the first tuning grid picked its smallest measurement-noise scale. Widening the grid found a better setting between two old grid points, which cut VeloBins' fused error by a further 8% (0.685 → 0.632 m/s) and brought its NEES median from 4.7 to 2.9.
• The filter does not yet beat the network on TII-RATM and NanoBench (5–10% worse). On TII-RATM the accelerometer itself is the limit: integrated with the true attitude, it drifts 0.7 m/s within one second.

Finding: NeuroBEM's gyroscope reads 2.5% high

NeuroBEM test segments, VeloBins with the tuned EKF, mean of 8 seeds. Scale factors are fitted on the training flights only.

Even with a tuned filter, three NeuroBEM test segments diverged. The cause was not the network: on those segments the heading drifted by 20–59° during highly tilted manoeuvres with 6–9 full turns. Regressing the ground-truth heading change on each gyro axis over the training flights shows the x-axis gyro reading 2.5% high (scale 1.0249, 95% CI 1.0238–1.0265). Correcting only the filter's gyro input, with the network unchanged, lowers the filter's test error by 41%, from 1.165 to 0.685 m/s (at the first tuned filter setting), and the three diverging segments drop from 1.5–5.1 to 0.4–2.0 m/s.

A spectral-norm bound fixes late over-confidence on NanoBench

NanoBench test flights, 8 seeds per model. Left and middle: network alone at both checkpoints. Right: tuned EKF with the final checkpoints.

Without regularisation, VeloBins becomes over-confident on NanoBench by the end of training (NLL rises from −1.34 to −0.63). Keeping every encoder weight matrix at spectral norm ≤ 2, as Neural-Fly does, prevents this and makes the model more accurate:

• Network: 10.5% lower RMSE than VeloBins at the final checkpoint (0.150 vs 0.167 m/s, p < 10⁻⁴) and 7.5% lower than AI-IO.
• Filter: 9–11% lower fused velocity error than either baseline, and a NEES median of 2.45, close to the 2.37 of a consistent filter.
• But it is dataset-dependent: in a 3-seed screen the same bound made TII-RATM and NeuroBEM up to about 10% worse. A looser bound of 3 is roughly neutral there and is the candidate setting for the cross-platform work.

What did not work

• Battery voltage as an input. Motivated by command-based platforms, where the same command gives less thrust as the battery drains. All effects stayed within ±4% with no consistent direction; the accelerometer likely already tells the network how much thrust a command produces.
• A rotor-drag physics loss. At low weight it changed nothing; at higher weight it pulled predictions towards the drag model, whose velocity is 1.3–1.9 m/s off, and the error doubled or worse.
• Physics as a second velocity sensor. Inverting a hybrid aerodynamic model gives velocity 2.5–5× less accurate than the networks, and fusing the two gained nothing measurable.

Ongoing: one encoder for every drone

The four datasets come from four different drones, each trained separately so far. The current experiments train one shared encoder on all of them, with a separate actuation normaliser and bin decoder per drone, and then test transfer to a drone left out of training using only 0.5, 2 or 8 minutes of its flight data. The aim is a pretrained encoder that a new platform can adopt with minutes of flight logs instead of hours.

To make the rotor input mean the same thing on every drone, I fit a per-rotor thrust map, f = a·u² + b·u, from each drone's actuation signal to mass-normalised thrust. It is fitted on the training flights against the thrust implied by the ground-truth motion, and checked on validation flights:

• R² of 0.84 (AI-IO, rpm), 0.90 (TII-RATM, thrust command) and 0.95 (NeuroBEM, rad/s).
• An independent check against the accelerometer, which the fit never sees, agrees in scale to within 2%.
• NanoBench is the exception (R² 0.15): its flights hold nearly constant thrust, so there is little variation to explain.

There are no cross-platform results yet; they will be added here. After that comes the JAX and ROS 2 port, to run EDGE-IO on board.

Team ManseRobot from the Computer Vision Group at Tampere University won the Earth Rover Challenge at IROS 2026 in Pittsburgh (28–30 September 2026), finishing first overall out of 12 teams from around the world. The challenge asks a simple question: can an AI policy drive a sidewalk rover the way a human can? Our answer was a single learned navigation stack that drove robots in cities across the Americas and Africa, through indoor hallways using nothing but a camera, and on the 50-mile marathon from UC Berkeley to Stanford.

The team was Sasanka Kuruppu Arachchige, Lauri Suomela and Abhimanyu Bhowmik, supervised by Prof. Joni-Kristian Kämäräinen. This builds directly on our runner-up finish at the ICRA 2025 edition.

• Overall

  1st · 12.50

  NYU 9.00 · Anna University 7.00

• Indoor

  5 / 5

  Checkpoints, zero interventions

• Marathon

  Best score

  UC Berkeley → Stanford

The challenge

Every team drives the same standardised Earth Rover sidewalk robots, which are deployed in different cities and controlled remotely over 4G. All computation runs off-board: camera, GPS and IMU data arrive at around 20 Hz with roughly half a second of latency, and velocity commands go back the same way. Missions are scored by difficulty, so the total rewards both reach and consistency. The IROS 2026 edition had four tracks over three days:

• Urban: follow GPS checkpoints along sidewalks and street crossings in cities including Colón (Panama), La Plata (Argentina) and Selebi-Phikwe (Botswana), plus an unseen-environment mission.
• Off-road: reach image goals on trails, slopes and gravel, without GPS.
• Indoor: reach image goals through hallways, atriums and labs, again with camera only.
• Marathon: new this year. A cross-domain endurance run from UC Berkeley to Stanford, about 50 miles in seven legs, driven by a single policy.

Results

As the organisers put it, ManseRobot finished in the top two in the Urban, Indoor and Marathon tracks, and that consistency is what won the overall title. Highlights include a complete 8/8-checkpoint urban run in Colón, Panama, with no interventions, a perfect 5/5 indoor run, and the best marathon score of the event.

How it works

The whole system comes from two of our recent papers. Instead of hand-tuning a pipeline for each track, we used the same learned policies everywhere and added a thin safety layer around them.

• A navigation policy trained on real data at scale. The driving policy comes from our study Data Scaling for Navigation in Unknown Environments (RA-L 2026), trained on thousands of hours of crowd-sourced FrodoBots driving data. For this edition we retrained it to take RGB images together with traversability maps, and to output actions through a diffusion head, using the LUMI supercomputer.
• Traversability as a safety layer. SAM-TP, the pixel-wise traversability model from GeNIE, is projected into a bird's-eye-view map around the robot. A repulsive field pushes the commanded motion away from untraversable space, and a recovery state gets the robot unstuck when it stalls.
• GPS goals in the city. In the urban track the policy follows sub-goals derived from the GPS checkpoints, with explicit heading control so the robot points at the next checkpoint before committing to a direction.
• Image goals without GPS. Indoors we run FAINT (ICRA 2026), our image-goal navigation transformer trained largely in simulation, on a topological map: a sequence of images recorded along the route. The robot localises itself in that map with EigenPlaces place-recognition features, and a cone detector and tracker confirms each checkpoint.

Urban: Colón, Panama

Indoor: one-shot image-goal navigation

The indoor track has no GPS and no prior map: the only information about the building is a short sequence of images along the route. We built and tested the indoor pipeline on corridors in our own lab in Tampere, then deployed it single-shot on the competition building at NYU, completing all five checkpoints with zero interventions.

What's next

We are turning the system and the lessons from the competition into a paper, ManseRover: Cross-Domain Navigation from Scaled Real Data and Simulation (tentative title), targeting IROS 2027. It brings together our work on data scaling for navigation and FAINT: large real-world datasets give a policy that generalises across cities, and simulation-trained image-goal navigation handles the places GPS cannot reach. This page will link to the paper when it is out.

Links

• Earth Rover Challenge: rules, tracks and past editions
• Official podium announcement by BitRobot, the challenge sponsor
• Data Scaling for Navigation in Unknown Environments (RA-L 2026)
• Synthetic vs. Real Training Data for Visual Navigation (FAINT, ICRA 2026)

If you are not redirected automatically, click here.

Code and pretrained models

The code, the data pipeline and the trained weights are open source: github.com/SasaKuruppuarachchi/Ex-IMO. The repository reproduces every result below from the public datasets, step by step, and the v1.0 release holds 12 pretrained models (base IMO and EX-IMO on four UAV datasets) with their tuned filter settings.

Publication

Sasanka Kuruppu Arachchige and Joni-Kristian Kämäräinen, Extended Model-Based Learned Inertial Odometry, International Conference on Unmanned Aircraft Systems (ICUAS), 2026, pp. 207–212. doi:10.1109/ICUAS69441.2026.11598619

@inproceedings{KuruppuArachchige2026EXIMO,
  author    = {Kuruppu Arachchige, Sasanka and Kämäräinen, Joni-Kristian},
  title     = {Extended Model-Based Learned Inertial Odometry},
  booktitle = {International Conference on Unmanned Aircraft Systems (ICUAS)},
  pages     = {207--212},
  year      = {2026},
  doi       = {10.1109/ICUAS69441.2026.11598619}
}

Introduction

Accurate state estimation is at the heart of agile drone flight. While cameras are commonly used for localization, they fail in low light, high-speed motion, or textureless environments. Inertial odometry — using only IMU (Inertial Measurement Unit) data — offers a lightweight and robust alternative, but it often suffers from drift over time due to sensor noise and bias.

In this project, I explored how far we can push IMU-only odometry by extending a recent learning-based inertial odometry (IMO) framework for autonomous drone racing. The core idea was to make the learned model “aware” of the drone’s underlying physics — not just what it feels through accelerations and rotations, but also the forces and torques acting on its body.

Method

IMO feeds a Temporal Convolutional Network (TCN) with IMU and thrust data; the network predicts the drone's displacement over the next 0.5 s, and an Extended Kalman Filter (EKF) fuses these predictions with the IMU for continuous pose estimation. EX-IMO changes three things:

• Body frame. The network predicts the displacement in the drone's own frame instead of the world frame, so it cannot learn the absolute headings of the training tracks.
• Torque input. The body-frame torques from the full quadrotor dynamics are added as an input, so the network sees how the vehicle is being driven, not only how it moves.
• Thrust from the rotors. The collective thrust comes from a per-platform fit of the rotor signals, which is available in flight.

Results

In the paper, we validated the approach on the Blackbird and DIDO drone flight datasets and deployed it on a real racing quadrotor. The results show up to 61% improvement in relative error compared to the original IMO on unseen trajectories — demonstrating that embedding physical insight into learning models enhances robustness and transferability.

Open reproduction on four public UAV datasets

With the code release, we re-ran the comparison from scratch on four more public datasets (AI-IO, NanoBench, TII-RATM and NeuroBEM): 3 seeds per model, the filter tuned on validation data only, and whole groups of trajectory shapes held out of training. On trajectories never seen in training, EX-IMO lowers velocity error in all 8 held-out sets, by up to 72%, and position error in 5 of 8, by up to 80%.

EX-IMO vs base IMO on held-out trajectories, mean of 3 seeds. Faded bars are not significant (paired t-test p ≥ 0.05). Full tables in the repository.

What the reproduction shows:

• Torque from the rotors carries velocity information. On its own it explains up to 94% of the variance of the body-frame displacement, likely because the rotors trim against aerodynamic moments that grow with airspeed. Torque computed from the gyro adds nothing the network does not already see.
• The world-frame baseline memorises track headings. Rotating the TII-RATM flights by 90° in yaw raises base IMO's validation error from 0.34 to 5.8 m/s; the body-frame models do not change.
• Position error is mixed on small datasets. On TII-RATM, with only 6 training flights per fold, neither model generalises well across tracks, and EX-IMO's position error is higher on the ellipse.

These numbers come from cleaned copies of the datasets that the repository builds, so they are not directly comparable with numbers published on the original files.

This work contributes to the ongoing effort to make autonomous drones faster, smaller, and more resilient — capable of navigating even when vision fails.

If you are not redirected automatically, click here.

If you are not redirected automatically, click here.

Building a Low-Cost Air-Ground Robotic System for Nuclear Plant Inspection

In June 2025, our team participated in the EnRicH 2025 Robotics Hackathon held at the decommissioned Zwentendorf Nuclear Power Plant in Austria — one of the most unique and challenging testbeds for field robotics. The goal: to design a robotic system capable of mapping, radiation detection, and inspection inside an environment where GPS is unavailable, communication is unreliable, and radiation levels can be hazardous for humans.

From Idea to Field-Ready Robot in 3 Weeks

We had just three weeks to design, build, and deploy a heterogeneous robotic system combining a drone and a ground vehicle. Using off-the-shelf parts, 3D-printed components, and open-source frameworks like ROS2 and PX4, we created: - A quadrotor equipped with LiDAR, IMU, and a Geiger counter for aerial radiation mapping. - An Ackermann-steering ground robot (UGV) for 3D mapping and navigation in tight corridors.

Both platforms shared the same onboard computer — an NVIDIA Orin NX — running ROS2 for perception, SLAM, and navigation. This unified design allowed faster integration, debugging, and modular scalability.

Navigating Inside a Nuclear Plant

Operating inside thick concrete walls meant no GPS and poor communication. We tackled this by deploying a mesh Wi-Fi network with repeaters and dynamic reconnection routines. Our robots relied on LiDAR-inertial odometry (DLIO) and LIO-SAM for robust mapping, even in visually and magnetically challenging conditions.

The UGV performed autonomous exploration using frontier-based mapping, while the UAV executed trajectory-based flight planning with RRT* and minimum-snap trajectory generation — ensuring smooth, collision-free navigation even with limited range and time.

Field Trials and Lessons Learned

Open Science and Future Work

All our mechanical designs, schematics, and ROS2 packages are open-sourced, supporting other researchers and practitioners who want to build adaptable robotic solutions for nuclear or hazardous environments. This project demonstrated that high-impact field robotics doesn’t require high budgets — just the right mix of collaboration, open-source tools, and creativity under pressure.

Publication

Published at the IEEE International Symposium on Safety, Security, and Rescue Robotics (SSRR 2025). Paper: Low-Cost Rapid-Development Air-Ground Robotic Solution for Nuclear Power Plant Inspection (open-access copy).

Update: one year later, we went one better: first place at the Earth Rover Challenge, IROS 2026.

Navigating the Wild: Remote Robot Control in the EarthRover Challenge

While robotics labs are full of polished systems relying on clean data and controlled environments, real world “in the wild” navigation is messier—sensor data is noisy, delayed, inconsistent, and environments unpredictable. At the EarthRover Challenge, we tested exactly this kind of problem—and our team from Tampere University came away 2nd place by building a system that can handle it.

What Was the Challenge?

EarthRover is a remote urban navigation competition: robots located in cities across the world are given GPS checkpoints. Teams must control them remotely, often using delayed and unreliable streams of camera, IMU, GPS, and other sensors. Environments vary, mission difficulty varies (crowds, roads, sidewalks, obstacles). The goal is to be robust, safe, and generalize across seen and unseen conditions. [earth-rover-challenge.github.io](https://earth-rover-challenge.github.io)

Our Approach

We took a two-pronged strategy:

Heading Reference System (Filter-based)

To cope with inconsistent orientation and heading data, we built a filter (e.g., combining IMU and when available magnetometer/GPS) to produce a more stable and reliable heading reference. This acts as our “compass,” so the system knows which way is forward/turning.

Data-Driven Steering Model

Relying only on the heading reference isn’t enough in complex or delayed visual situations. We trained a steering policy (neural network or other regression/learning approach) that takes input from the available sensor streams (e.g., camera, delayed GPS, IMU) and outputs control commands such as turn left/right and go forward/back. The model is robust to noise, delays, and inconsistent data.

By combining the filter-based heading with the learned steering, the system adapts: when sensor data is bad, we depend more on the heading system; when visual cues or other data are good, the steering model takes more control.

Gallery

Results & What We Learned

Our system successfully navigated in several “in-the-wild” urban locations under varying lighting, traffic, pedestrian density, weather, and sensor conditions. We placed 2nd overall in EarthRover among competing AI teams.

Key lessons

• Robustness to sensor noise and delay is non-negotiable in real deployments.
• Hybrid systems (filter + learned model) outperform pure learning or pure classical methods when conditions degrade.
• Generalization to unseen environments is harder than it looks; overfitting to “nice” scenes hurts performance in the wild.

Why It Matters

Robot navigation under messy, delayed, and partial data is closer to how deployed systems in cities, disaster zones, or remote sites must work. Winning 2nd place shows that you can build systems that generalize across “unseen” environments, not just labs. For applications like delivery robots, autonomous inspection, and remote monitoring, this kind of robustness is essential.

In industrial environments like factories, warehouses, or power plants, inspection and maintenance are still largely human‑operated—time‑consuming, repetitive, and often risky. Our project, RAICAM (Robotics and Artificial Intelligence for Critical Asset Monitoring), aims to change that by creating a framework that lets aerial and ground robots work together autonomously to perform inspection and mapping tasks.

This work was carried out at ENSTA, Paris and presented at TAROS 2025 (Towards Autonomous Robotic Systems), where we demonstrated the full system in a realistic facility‑management scenario.

Gallery

The Idea: Robots That Complement Each Other

Drones are agile and can quickly scan large areas or hard‑to‑reach places, but they have limited endurance and payload capacity. Ground robots, on the other hand, can carry heavier sensors and operate longer but are constrained by terrain. RAICAM bridges these strengths by enabling tight coordination between the two.

We designed a ROS 2‑based architecture that allows both robots to share real‑time state, semantic information, and task goals. The drone performs aerial visual inspection and mapping, while the UGV handles close‑up exploration, data collection, and relay networking. The system dynamically assigns tasks depending on robot capability, energy level, and visibility.

Method

• Shared Semantic Map: A unified map that merges LiDAR, visual, and inertial data from both robots for joint situational awareness.
• Collaborative Planning: Decentralized trajectory generation ensures both robots plan around each other, avoiding collisions and maximizing coverage.
• Human‑in‑the‑Loop Supervision: A web‑based control interface allows an operator to oversee missions, trigger reassignments, or pause tasks when needed—all in real time.

This hybrid autonomy approach balances robot independence with human oversight—crucial for deploying robots safely in operational facilities.

Field Deployment

We validated the method in an indoor mock industrial environment equipped with stairs, corridors, and elevated pipelines. The air–ground pair collaboratively performed inspection and mapping while maintaining a shared localization frame. The demo showed robust communication, real‑time visualization, and reliable mission continuity even when the aerial link briefly dropped.

Looking Ahead

RAICAM paves the way for scalable robotic teams that can handle routine maintenance, environmental monitoring, and asset inspection in large industrial sites. By combining the complementary strengths of aerial and ground robots, the project moves us a step closer to fully autonomous, cooperative robotic ecosystems.

Publication

Paper: Lessons Learned from the RAICAM Doctoral Network Research Sprints

Citation

@inproceedings{kenan2025lessons,
  title={Lessons Learned from the RAICAM Doctoral Network Research Sprints},
  author={Kenan, Alperen and Kordkheili, Sahar Sadeghi and Cardenas, Juan Jose Garcia and Melone, Alessandro and Tian, Changda and Li, Haichuan and Raei, Hamidreza and Kuruppu Arachchige, Sasanka and Tang, Yifeng and Tapus, Adriana and others},
  booktitle={Annual Conference Towards Autonomous Robotic Systems},
  pages={526--539},
  year={2025},
  organization={Springer}
}