TERRADRONE-SIM

Inspiration

Farm and agricultural research crews plan aerial surveys days in advance, always asking the same critical question: "If I launch at this time in 2–3 days, will the drone finish the survey safely, and how much battery will it take?"

Traditional weather apps only provide raw numbers like wind speed or temperature, leaving operators to guess how a sudden gust front, blowing dust, or cold-air density drop will actually impact a multispectral quadrotor flying a tight grid over a potato trial or cherry orchard. We were inspired to bridge this gap between AI weather forecasting and rigid-body flight dynamics. Instead of relying on static rules of thumb, we built a flight lab that takes high-resolution ensemble forecasts for a specific field and actually flies the survey in simulation across every forecast hour and scenario before the crew ever leaves the ground.

What it does

TERRADRONE-SIM is a weather-aware survey-drone flight lab, mission planner, and 6-DOF physics simulator modeled around the DJI P4 Multispectral and FAA 14 CFR 107.51(c) regulations.

It pulls hourly ensemble forecasts for a field's exact latitude and longitude using NVIDIA Earth-2 StormCast-CONUS (a 3 km high-resolution AI ensemble steered by NOAA GFS), standard NOAA GFS, or synthetic storm fronts. For every launch hour and ensemble scenario, the planner flies a custom-drawn survey grid using our point-mass simulator to evaluate flight time, battery consumption, pack count, and airframe stress. It then outputs an actionable CLEARED, CONDITIONAL, or NOT CLEARED verdict against 10 m/s gust limits, precipitation (>0.5 mm/h), FAA 3-statute-mile (4.8 km) visibility minimums, cold-weather battery derating, and emergency landings. Finally, it replays the selected launch window in a 500 Hz, 17-state rigid-body simulator to compare calm-air baselines against wind-perturbed trajectories, analyzing roll/pitch tilt, cross-track error, and individual rotor power draw.

How we built it

We architected TERRADRONE-SIM as a modular pipeline connecting Python-based AI weather ingestion with a zero-dependency browser and Node.js simulation engine.

Our weather pipeline (earth2_weather.py) uses earth2studio to run NVIDIA Earth-2 StormCast-CONUS and fetch NOAA GFS data, compiling hourly multi-scenario ensembles into forecast_scenarios.json. We translated these meteorological outputs into flight boundary conditions by scaling 10-meter winds to flight altitude z via a power-law boundary layer profile and deriving gust magnitudes from mean wind U and ensemble spread σ:

Altitude Wind Profile: U(z) = U₁₀ · (z / 10)^0.14
Ensemble Gust Magnitude: U_gust = √((0.15 · U)² + σ²)

We also modeled light extinction from blowing dust and rainfall to estimate flight visibility against the 4.8 km FAA minimum, and applied temperature-driven battery capacity derating at -0.75% per °C below 20°C.

For the interactive Flight Lab and headless CLI planner (app.js, planner.js, mission_planner.cjs), we built a deterministic 0.1 s point-mass simulator that runs identically in the browser with 16x / 64x time-warp and in Node.js to generate standalone mission_plan.html reports. To validate the chosen launch window, we built a 17-state 6-DOF physics engine (physics6dof.js) integrated via 4th-order Runge-Kutta (RK4) at 500 Hz. The state vector tracks 3D position p, velocity v, attitude quaternion q, body angular rates ω, and four first-order motor thrust states Tᵢ, governed by the following equations of motion:

Position & Velocity: ṗ = v and v̇ = (R(q)·[0, 0, ΣTᵢ] + F_drag(v − w)) / m − g
Attitude & Body Rates: q̇ = ½ q ⊗ [0, ω] and ω̇ = J⁻¹(τ − ω × Jω)
Motor Dynamics: Ṫᵢ = (Tᵢ,cmd − Tᵢ) / τ_motor

The aircraft is flown by a cascaded controller featuring route guidance, a wind-learning velocity PI loop, a 35° tilt-limited thrust vector mapper, and geometric attitude control on SO(3) feeding an X-quad mixer under Dryden low-altitude turbulence (MIL-HDBK-1797) and GNSS noise. Electrical power per rotor is computed via momentum theory and scaled by local air density ρ:

Rotor Power & Density Scaling: Pᵢ ∝ Tᵢ^1.5 / √(2ρA) and P_hover(ρ) = P_hover,0 · √(1.225 / ρ)

Challenges we ran into

Our biggest challenge was balancing simulation speed against physical fidelity. Running a 500 Hz 17-state RK4 simulation across 8 launch hours and multiple ensemble members directly in the browser would take minutes of compute time and stall the UI. We solved this by designing a two-tier architecture where our fast 0.1 s point-mass simulator sweeps the entire forecast matrix in seconds, while the 500 Hz 6-DOF engine runs on-demand to validate the chosen window against calm and median baselines.

Another major challenge was modeling realistic wind coupling without "cheating." Because a real autopilot does not directly know the ambient wind vector, we designed our flight controller to estimate wind from the discrepancy between ground velocity and airspeed using a 3 s time constant. This naturally reproduced how sudden gusts and turns push the drone off its survey track and exposed how standard calm-air return-to-home calculations can deplete battery reserves mid-return under strong headwinds.

Accomplishments that we're proud of

We are especially proud of the close physical agreement between our two simulation tiers and our commitment to scientific transparency. Under an 8 m/s crosswind, our fast point-mass simulator predicts a 14.4° steady-wind lean angle compared to 13.9° in the full 17-state 6-DOF engine, and our entire physics core is verified via automated test suites (tests/physics.test.cjs and tests/flight.test.cjs) against analytical hand calculations for hover thrust, hover power, steady-wind tilt, and air-density scaling. Furthermore, rather than hiding assumptions inside a black box, we explicitly audited and tagged every single parameter in our UI and codebase as MODEL, DERIVED, SPEC, or ASSUMED so operators know exactly what to trust. We also built the JavaScript simulation engine with zero external dependencies, allowing the exact same step() loop to power both the interactive 3D web canvas and the headless Node.js batch planner.

What we learned

Through building TERRADRONE-SIM, we learned how to operationalize NVIDIA Earth-2 StormCast high-resolution mesoscale ensembles into downstream robotics and mission-planning tools. We gained deep practical insight into how atmospheric thermodynamics—specifically temperature, barometric pressure, and humidity—alter air density ρ and measurably shift multirotor hover power and multi-battery survey logistics. On the flight dynamics side, we saw firsthand the mathematical elegance of geometric attitude control on SO(3) paired with quaternion kinematics, which completely avoids gimbal lock and handles aggressive turbulent gust recovery smoothly.

What's next for TERRADRONE-SIM

Next, we plan to expand from a single forecast grid cell per field to spatially varying 3D wind fields paired with Digital Elevation Model (DEM) terrain-following for sloped orchards and valleys. We also want to implement wind-optimal route re-planning that automatically rotates survey sweep angles to align with forecast wind vectors, minimizing crosswind crabbing and turn-around energy penalties. Finally, we aim to add direct MAVLink and QGroundControl export so operators can take weather-cleared, 6-DOF-validated mission plans and export them directly to .plan and .waypoints formats for immediate field deployment.

Built With

6-dof-simulation
control-systems
css3
dji-p4-multispectral
drones
dryden-turbulence
earth2studio
flight-dynamics
geometric-control
hrrr
html5
javascript
json
noaa-gfs
node.js
nvidia-earth-2
nvidia-gpu
precision-agriculture
python
quaternions
runge-kutta
stormcast
uav
weather-forecasting

Submitted to

Gator Hack V - AI Days 2026

Created by

I added the Gemma part of Drone Scout. The planner already decided whether a flight was safe, but its output was mostly numbers, so I wanted the decision explained in plain English. I connected the planner to a local Gemma model through Ollama. Each time you pick a launch hour, the planner’s reasons and numbers go to Gemma, and the page shows GO, CAUTION or NO-GO with a short explanation. Gemma only explains the result and can never change a call. If Ollama isn’t running, the page falls back to the planner’s own reasons. Getting it working took some trial and error with browser CORS settings and file paths. Analyzing photos with Gemma is future work and not built yet.

Ashritha Narne
Weather pipeline (my part). I wrote the script that gives the planner its weather. It takes a field’s latitude and longitude and produces hourly wind, gusts, temperature, rain, air density and an estimated visibility. It supports NVIDIA Earth-2 StormCast for an AI forecast, NOAA GFS as a fallback that works anywhere, and a synthetic mode for demos. I ran StormCast on a Colab A100 GPU to generate forecast data. Every input is labelled as model output, derived or assumed, and visibility is marked as an estimate. I also included a sample forecast so the app runs without a GPU.

Nikhitha Nagabhyru
I conceived and directed Drone Scout, a local drone survey simulator built on real UF IFAS crop data. I collected and curated about 20 GB of agricultural datasets (potato, cherry orchard, apple, cashew, WebODM, CoFly and Gast Agrowing imagery). I specified the core requirements: a realistic drone configuration based on DJI Phantom 4 Multispectral specs, user-selected survey areas, an animated flight view, and exportable mission data. I reviewed the results critically. I questioned why only a fraction of the 7.8 GB of imagery was used, which led to far more of the data being embedded, and I required every value to be labelled as real imagery or simulated telemetry. I then brought in the local source and data audit, which led to the restored workstation and data browser. I developed it with Claude as an AI coding assistant, which wrote the implementation under my direction. It is a simplified point-mass model with no physical-drone connection.

Arvind kanagasabapathi chandirakala
I made the pieces work together and get ready to submit. I put the Gemma box into the planner panel, tested it against real planner output, and fixed the problems we hit along the way, including CORS errors, a leftover HTML block, and Git merge conflicts. I updated the README so a new person can run the app with or without Ollama, and I wrote and recorded the demo. I also set up the team’s Devpost submission and the repo so that everything lined up before the deadline. The photos in the demo come from UF IFAS datasets and not from our own flights, and we say so in the video.

Vatsalya Nallagangula
I worked on how a forecast turns into a decision. Instead of using a simple wind limit, I had the planner fly the whole survey in the simulator for every launch hour and every forecast scenario, so battery use and path error come from the flights themselves. I set the rules from the DJI Phantom 4 Multispectral limits and the FAA’s 3-mile visibility minimum: gusts over 10 m/s, rain, low visibility, bad temperatures, emergency landings or too few batteries all mean not cleared. Each hour gets a verdict, and the planner recommends a launch time. I also looked into why strong headwinds sometimes end in emergency landings. The planner uses a simplified point-mass model.

Bhaveetha Patel Marri