What the simulator models

This is the page to read before you tell a class that the simulator “is” the drone, and the page to read before deciding whether this product suits your course.

Short version: the model is good enough that bad flying fails for real reasons, and it is not calibrated to any particular aircraft you might buy.

What it reproduces

The simulator runs a rigid-body physics engine at 60 times a second, and sends the view to the browser at 120 frames a second so the drone moves smoothly. What acts on the aircraft:

	What the model does
Mass and thrust	Each airframe has a real mass and thrust-to-weight ratio. A heavier drone accelerates less for the same command.
Motor lag	Rotors take time to spool up — tens of milliseconds, and different per airframe. You cannot change thrust instantly, which is why abrupt programs overshoot.
Drag	The drone is slowed by the air it moves through.
Wind	A genuine aerodynamic force, not a nudge: it depends on the drone’s speed relative to the air, and on which way the body is facing, so a broadside drone catches more than an edge-on one.
Thin air	Air density falls with altitude, and thrust falls with it. Climb high enough and the drone stops being able to climb.
Ground and ceiling effect	Flying close to the floor or under a roof changes the lift available, the way it does in reality.
Confined spaces	In a tight space the model reduces thrust authority and destabilises the aircraft, so a corridor is harder than open air.
Battery	A 1S lithium pack modelled from 4.2 V full to a 3.3 V cutoff, draining faster the harder the drone works. Voltage sags as it empties.
Collisions	Selectable per mission: bounce off, crash, or pass through.
Sensor noise	The accelerometer, gyroscope and magnetometer all carry noise and a slowly wandering bias, so readings are never perfectly clean.

What a student can actually reach

The table above is what the flight model does. It is not the same question as what a student can do, and the difference catches people out.

Blocks do not drive the simulator directly. They generate a program against an adapter, and the adapter decides which of the drone’s abilities are exposed. On today’s block set — APEX GD240, which is what every student gets — the reachable commands are flight (take off, fly, rotate, throttle, land, emergency stop), headless mode, photo and recording, and reading the battery level.

Two consequences worth knowing before you plan a lesson around something:

• There are no sensor blocks. The simulator itself carries a rangefinder, barometer, lidar and a set of environment sensors, and missions can use them — but a student cannot read one from a block today. Do not promise a class a sensor exercise on the strength of the simulator having the sensor.
• A student cannot change the weather. The simulator can be told to blow a wind, but that is not something a block does. Wind arrives because a world or a mission specifies it, which is what keeps it fair — nobody can turn the wind off to pass.

What each block does is in the Blocks section, which is the authority on the student-facing surface.

Lessons can narrow it further

A lesson can lock capabilities for the flight it sets up — a restricted world, a particular airframe, certain controls disabled. So “can the simulator do X” is partly a per-lesson question rather than one global answer.

What it does not do

There is no satellite positioning in the model at all. The simulated drone always knows exactly where it is. Everything a real pilot learns about GPS — that it drifts, that it is poor near buildings, that losing it changes how the aircraft behaves — cannot be taught here, because from the drone’s point of view it never happens.

There is no radio link. Programs run without the possibility of losing contact, so failsafe behaviour is not something a student meets.

Weather is wind and nothing else. No rain, no temperature effects on the pack, no turbulence beyond what wind and confined spaces produce.

Nothing wears out or breaks. Props stay true, motors stay matched, and the battery is new every time.

So what does a clean simulator flight tell you?

It tells you the program is right. The order of operations, the geometry, the timing, whether the student thought about how long a movement takes. That is the thing the course is teaching, and the simulator tests it honestly.

It does not tell you the flight would work outdoors. A real first flight adds wind you did not choose, a surface that is not flat, positioning that wanders, and a battery that is not new. Students who go on to the hardware track should expect their first real flight to be harder than their last simulated one, and that is the correct expectation to set.

Is that enough to teach with?

For a programming course, yes, comfortably — and the reason is worth stating positively rather than as a concession.

A student who writes a program that ignores how long a movement takes will see it overshoot, because motor lag is real here. A student who flies a heavy airframe with a light-airframe program will see it sink. A student who plans a route without thinking about the battery will run out. Those failures are the lesson, and they arrive as physics rather than as a mark.

What it will not do is stand in for flight training. See What UAVProg is for where that line sits in the product as a whole.

Related

• What a session is — the machinery underneath
• Missions and scoring — how a flight becomes a number
• Blocks — the commands a student actually has