38 Lab: UAV FANET Hardware Simulation
External ESP32 Lab Workflow, Route Records, Mesh Events, and Traceable FANET Tests
38.1 Start Simple
Start with a mission that moves, loses energy, and changes its radio path while it works. In Lab: UAV FANET Hardware Simulation, the practical question is what the aircraft must sense, relay, decide, and prove before the flight or network role is safe enough to trust.
38.2 Learning Objectives
By the end of this lab, you will be able to:
- Set up an external ESP32 simulator workspace for a UAV FANET exercise.
- Explain how beacon messages, neighbor tables, route state, and fallback events support mesh checks.
- Run normal, weak-link, low-reserve, leader-change, and route-gap scenarios.
- Capture a compact run record from serial output instead of relying on memory.
- Decide whether a lab result should promote, revise, hold, or reject the tested behavior.
38.3 Simulation Records, Not Flight Proof
The external ESP32 workspace is a safe place to practice FANET reasoning, but it is not evidence that a real aircraft network is ready. Its value comes from the records it produces: scenario name, changed condition, node role, battery reserve, link freshness, route state, leader state, and readiness decision.
Mobile summary: A simulator run is useful only when the scenario, serial excerpt, gate result, decision, and next revision are visible.
A clean baseline run is only the starting point. The useful learning happens when the lab stresses one condition at a time and shows why a stale link, low relay reserve, leader change, or route gap changes the decision.
38.4 FANET Lab Record Pack
For each run, keep a short serial excerpt, the exact scenario, the changed field or rule, the gate result, the promote/revise/hold/reject decision, and the next revision. That pack is small enough for someone else to review without replaying the whole simulator session.
Run single-stress scenarios before combined stress. Baseline, stale edge link, low relay reserve, leader change, and route gap each test a different claim, so mixing them too early hides the reason a decision changed.
38.5 Stale State Breaks Mesh Claims
FANET behavior depends on fresh neighbor records and route state, not only on whether a node still appears in a table. A node can have enough battery and still be unsafe as a relay if its link record is old or its route continuity is unproven.
The simulator exposes that boundary by turning hidden assumptions into fields. Battery, link age, leader role, and route continuity are simplified signals, but they teach the operational habit: promote only when the record supports the claim, and revise when the evidence is stale or incomplete.
- A simulator workspace is a lab tool, not proof that the FANET design works.
- Each run needs a scenario, expected records, observed records, and a readiness decision.
- Simulated drones should be treated as route-state records: position, link freshness, battery reserve, role, and fallback state.
- Weak-link and low-reserve cases are more valuable than a single clean run.
- Live external embeds can create page errors; this chapter uses an external launch link and local records instead.
38.6 Prerequisites
Revisit these chapters if the terms are unfamiliar:
- UAV FANET Fundamentals: aerial ad hoc links, routing choices, and topology records.
- UAV FANET Gateway Selection: gateway role, candidate records, and handoff.
- UAV Swarm Coordination: role ownership and fallback behavior.
- UAV Trajectory Labs and Implementation: lab workflow, gates, and lab record packs.
38.7 How This Lab Fits
The UAV trajectory implementation chapter explains how to check a route lab. This chapter applies that discipline to a hardware-simulation setting. The ESP32 sketch models a few virtual UAV records on one board so learners can observe beacon freshness, link decisions, route events, and fallback records without needing flight hardware.
The overview depth layer shows the simulator workflow that ties external setup, starter sketch, scenario run, serial evidence, readiness gate, and revision decision into one reviewable FANET lab loop.
38.8 External Simulator Workspace
Use Wokwi as an external workspace instead of embedding it inside this page. The live embed can generate authentication, hydration, and failed-request noise during checks; an external workspace keeps the chapter stable and still gives learners a runnable lab.
38.8.1 Open the workspace
Open a new ESP32 project in Wokwi
Keep the lab page open in another tab so you can copy the starter sketch and record observations.
38.8.2 Use one board
The starter sketch models several virtual UAV records on one ESP32. This keeps the lab simple and avoids confusing board-to-board radio setup with FANET concept checks.
38.8.3 Record run data
Use the serial monitor as the record source. Copy short excerpts that show neighbor freshness, route decision, leader state, and fallback events.
38.9 Lab Testbed Model
The lab models a small FANET using virtual records rather than real aircraft. Each record has a role, battery estimate, link freshness, and route state. The sketch updates those records and prints a compact decision log.
Virtual UAV records Each record has an identifier, role, link freshness, battery estimate, and current route state.
Scenario injection Change one variable at a time: stale neighbor, weak relay, low reserve, leader loss, route gap, or fallback trigger.
Serial records The serial monitor should print a concise run record rather than a long stream of unchecked debug lines.
Readiness decision Every run ends with promote, revise, hold, or reject. The decision should cite the observed records.
38.10 Starter Sketch
Paste this compact sketch into the external ESP32 workspace. It is intentionally small: the goal is to inspect FANET records, not to simulate a full autopilot.
#include <Arduino.h>
struct Node {
uint8_t id;
const char* role;
int battery;
int linkAge;
bool leader;
bool routeOk;
};
Node swarm[] = {
{0, "gateway", 84, 1, true, true},
{1, "survey", 76, 2, false, true},
{2, "relay", 68, 3, false, true},
{3, "edge", 42, 7, false, true}
};
const int nodeCount = sizeof(swarm) / sizeof(swarm[0]);
int runId = 0;
void printHeader(const char* scenario) {
Serial.println();
Serial.print("RUN ");
Serial.print(runId);
Serial.print(" SCENARIO ");
Serial.println(scenario);
Serial.println("id role battery linkAge leader route decision");
}
const char* decisionFor(Node n) {
if (n.battery < 30) return "revise-low-reserve";
if (n.linkAge > 5) return "hold-stale-link";
if (!n.routeOk) return "reject-route-gap";
if (n.leader) return "promote-leader";
return "promote";
}
void printNode(Node n) {
Serial.print(n.id);
Serial.print(" ");
Serial.print(n.role);
Serial.print(" ");
Serial.print(n.battery);
Serial.print(" ");
Serial.print(n.linkAge);
Serial.print(" ");
Serial.print(n.leader ? "yes" : "no");
Serial.print(" ");
Serial.print(n.routeOk ? "ok" : "gap");
Serial.print(" ");
Serial.println(decisionFor(n));
}
void runScenario(const char* scenario) {
runId++;
printHeader(scenario);
for (int i = 0; i < nodeCount; i++) {
printNode(swarm[i]);
}
}
void setup() {
Serial.begin(115200);
delay(500);
runScenario("normal-mesh");
swarm[3].linkAge = 9;
runScenario("stale-edge-link");
swarm[2].battery = 24;
runScenario("low-relay-reserve");
swarm[0].leader = false;
swarm[1].leader = true;
swarm[3].routeOk = false;
runScenario("leader-change-route-gap");
}
void loop() {
delay(2000);
}38.10.1 Expected Output Shape
The exact line order can vary if you edit the sketch. A useful run should still show:
RUN 2 SCENARIO stale-edge-link
id role battery linkAge leader route decision
3 edge 42 9 no ok hold-stale-linkThe important part is the decision column. It connects the simulated condition to a readiness action.
38.11 Lab Procedure
Step
Action
Records to keep
- Prepare
Open the external ESP32 workspace, paste the sketch, start the simulator, and open the serial monitor.
Project type, sketch version, serial baud, and run date.
- Baseline
Run the normal-mesh scenario and confirm all records produce a readiness decision.
One serial excerpt that shows leader, route, link freshness, and decision columns.
- Stress
Edit one field at a time: stale link, low reserve, route gap, or leader change.
Before and after excerpts that show which condition changed.
- Check
Classify each run as promote, revise, hold, or reject.
Decision reason tied to the observed condition.
- Revise
Change the decision rule or scenario and rerun only the affected case.
What changed and whether the new records are stronger.
38.12 Scenario Set
Run it: Before you run these scenarios as a static node table in the ESP32 sketch, see the mesh itself in the FANET routing workbench below. Set the Routing policy to Link-quality mesh, then press Play or Step and watch a multi-hop route form toward the gateway — this is the route continuity you record as routeOk = true in Scenario 1 (Normal mesh). Now shrink the Radio range or raise the Mobility speed until the mesh can no longer reach the gateway and falls back toward Direct A2G only: that broken multi-hop path is exactly the Scenario 5 (Route gap) condition that forces a reject or revise. Use the workbench to see when a route gap appears; keep the battery, link-freshness, leader, and decision columns on your serial record.
38.12.1 Scenario 1: Normal mesh
All records have fresh links, acceptable reserve, and route continuity.
Expected decision: promote the baseline as a reference run.
38.12.2 Scenario 2: Stale edge link
Increase the edge node’s linkAge above the freshness threshold.
Expected decision: hold or revise until the neighbor record is fresh enough.
38.12.3 Scenario 3: Low relay reserve
Lower the relay node’s battery below the reserve gate.
Expected decision: revise relay ownership or reduce scope.
38.12.4 Scenario 4: Leader change
Move leader = true from the gateway to another node.
Expected decision: promote only if the new leader has adequate reserve and link freshness.
38.12.5 Scenario 5: Route gap
Set routeOk = false for the edge node.
Expected decision: reject the run or revise the route before promotion.
38.12.6 Scenario 6: Combined stress
Combine low reserve and stale link only after single-stress cases are understood.
Expected decision: hold or reject unless the fallback record is explicit.
38.13 Lab Record Pack
A useful lab submission should be small enough to check. Do not paste the whole serial log. Keep the records that support the decision.
- Scenario name: normal mesh, stale edge link, low relay reserve, leader change, route gap, or combined stress.
- Changed condition: the exact field or rule changed before the run.
- Serial excerpt: three to six lines that show the records, not the entire log.
- Gate result: link freshness, reserve, route continuity, leader state, or fallback result.
- Decision: promote, revise, hold, or reject.
- Next revision: the smallest change that would improve the next run.
38.14 Worked Example: Stale Edge Link
Scenario: The edge node can still appear in the route, but its link record is stale. A learner changes swarm[3].linkAge from 3 to 9.
Observed excerpt
RUN 2 SCENARIO stale-edge-link
id role battery linkAge leader route decision
3 edge 42 9 no ok hold-stale-linkCheck
- The route is not rejected because
routeOkis still true. - The run is not promoted because the link freshness gate failed.
- The correct decision is hold or revise until the edge node has fresher neighbor records.
Revision
Reduce the edge node’s link age or change the route so the stale edge node is not required for a critical relay. Rerun only the affected scenario and keep the new excerpt.
38.15 Common Pitfalls
38.15.1 Treating the simulator as proof
A simulator run is useful only when the scenario, changed condition, and decision rule are visible.
38.15.2 Keeping full logs
Long logs hide the decision. Keep short excerpts that show the tested condition and result.
38.15.3 Testing combined failures first
Single-stress cases make the cause visible. Combined stress is useful only after each single gate is understood.
38.15.4 Ignoring stale links
A node with acceptable battery can still be unsafe as a relay if the neighbor record is too old.
38.15.5 Promoting low-reserve relays
Relay ownership should change before a low-reserve node becomes critical to telemetry delivery.
38.15.6 No next revision
A lab that does not name the next change is a demo, not an implementation check.
38.16 Lab Completion Checklist
Before marking this lab complete, confirm that:
- The external ESP32 workspace starts and prints serial output.
- The baseline run has a saved excerpt.
- At least two stress scenarios have saved excerpts.
- Each excerpt includes role, battery, link age, leader state, route state, and decision.
- A route gap, stale link, or low reserve case is not promoted.
- The final submission names the next revision.
38.17 Interactive Checks
38.18 Summary
This lab turns an ESP32 simulator workspace into a traceable UAV FANET exercise. The core skill is not copying a large program into a browser; it is designing small scenarios, capturing serial records, applying link, reserve, route, leader, and fallback gates, and recording the next revision. This keeps the hardware-simulation lab aligned with the broader UAV trajectory and FANET check process.
38.19 See Also
- UAV FANET Fundamentals: aerial ad hoc links and topology records.
- UAV FANET Gateway Selection: gateway candidates and handoff records.
- UAV Trajectory Labs and Implementation: lab workflow and lab record packs.
- UAV Networks: Production Checks: production-readiness checks for UAV systems.
38.20 What’s Next
38.20.1 Next module
38.20.2 Energy-aware design
38.20.3 UAV production checks
38.20.4 Lab workflow recap
38.21 Key Takeaway
A UAV simulation lab is useful for practicing telemetry, state logic, messaging, and failure handling. Treat it as preparation for field validation, not a substitute for real flight records.