What the simulation is and is not, the parameters it runs on, what a static site can and cannot check, the rules for the two assignments, accessibility, and who to ask.
Policies and boundaries#
1. What the simulation is#
Slop Hill, the kitchen, the twenty orders, the two drone types, the two charging pads and the corridor are a teaching model. The constraints come from a real task; the numbers, the safety margins and the rules are course settings, chosen so that each week’s question has a clean answer. Nothing on this site claims that a real drone, a real airspace rule or a real delivery business works this way. A result here is a result about this model.
Every page says which model it assumes. The model grows in five steps — weeks 1–3, week 4, weeks 5–6, weeks 7–8, weeks 9–12 — and a plan that was correct under an earlier step is not wrong in hindsight when a later step changes the answer. Results under different steps are labelled and never compared as if they were the same conditions.
2. Parameters#
The canonical scenario has four input files: map, orders, fleet and rules. Charging pad capacity is part of rules. Their checksums are pinned in the repository’s own tests, and every weekly case is a subset or a view of them. The table below lists what the model depends on and which values are fixed. These are course-set parameters, published in the downloadable canonical scenario on each assignment page; they are not manufacturer specifications.
| Parameter | Value | Status |
|---|---|---|
| Area | 2 km × 2 km; a hill of 120 m with a 45 m knob at the top; the summit house at 165 m; the kitchen at the foot | fixed |
| Streets | 51 nodes, 148 directed edges; a ridge with the corridor (298 m) as its only crossing on rows 2–4; the detour around the ridge is 1 607 m, 5.4 times the corridor | fixed |
| Hilltop | A track of 173 m rising 43 m (grade 0.25) and a spiral of 531 m rising 51 m (grade 0.10) | fixed |
| Orders | #01–#20, numbered by ready time, 18:00–20:11; #07 at the summit, promised 25 minutes after ready; #13 across the corridor; #20 3.5 kg; the others 0.3–1.4 kg | fixed |
| Type L | 12 m/s; climb 3.0 m/s; payload 1.5 kg; battery 95 kJ; cruise 120 W plus 15 % per kg; climb power 300 W; lift 60 J per metre of rise, times (1 + 20 × grade); hover 100 W | fixed |
| Type H | 8 m/s; climb 2.0 m/s; payload 4 kg; battery 250 kJ; cruise 200 W plus 8 % per kg; climb power 500 W; lift 90 J/m, times (1 + 20 × grade); hover 220 W | fixed |
| Fleet | A, B, C are type L; D, E are type H | fixed |
| Charging pads | Two; a full charge takes 1 200 s; turnaround 60 s | fixed |
| Time | Ticks of 1 s; loading 60 s; service 45 s; evening 18:00–21:00; evaluation cut-off 21:30 | fixed |
| Reserve | 15 % of the battery must remain on landing | fixed |
| Objective | Total lateness, then all-returned time, then total energy, in that order | fixed |
| Calibrated facts | A light drone can fly #01–#06. For #07 its fastest round trip (447 s, 84.7 kJ) is over its 80.75 kJ budget, so a slower, cheaper one (472 s, 80.4 kJ) is flown. Every order can be flown by some type; #20 only by H; H reaches all twenty; L cannot reach #14. | checked by the repository’s tests |
| Reference plan | A greedy assignment on static costs delivers 13 of the 20 on time. The reference method — that assignment, then best-improvement migrations with every candidate re-evaluated as a whole plan, charging queue and corridor reservations included — delivers all 20 on time and has every drone back by 20:23. | checked by the repository’s tests |
That reference plan is the baseline the assignments compare against. It is stored and re-checked by the same evaluator every time the site is built, never trusted from the file.
3. What a static site can and cannot do#
This site is static. Everything it computes runs in your browser, and everything it holds — the data files, the reference plans, the cases — can be read by anyone who opens the page source. The reference plans on the site are labelled reference plan, re-validated live: the assignment was computed in advance; the evaluator reconstructs its tasks and the resource validator checks their intervals.
The independent full-plan checker reconstructs directed edges, durations, payload, service, energy, reserve, drone availability, FCFS charging, corridor intervals and completion from the action record. Invalid or incomplete plans have no comparable formal objective. The Lab accepts versioned experiment inputs and local scenario copies; imported totals are discarded and Run recomputes them. A stored reference assignment is labelled and evaluated again under the selected scenario.
Strategy functions run in a terminable worker with network access blocked. Custom functions have an eight-second limit; other runs stop after 45 seconds. Errors and cancellation keep the previous result visibly stale, with no successful fallback. Importing JavaScript source never executes it automatically. Local practice-pack code runs as your own Node program.
The site has no submission service. Export a record for the assignment process; importing it into the Lab is an experiment, not a submission.
Your own records stay in your browser unless you export them. Export before you clear your browser data; the site cannot recover them.
4. Assignments#
Both assignments are individual work. Discussing the problems with other students is expected; submitting the same code or the same analysis is not. Name every person you discussed the work with and every external source, including code, in the analysis.
AI assistance is allowed and must be declared. It does not replace your own explanation: the analysis is yours, in your words, and you should be able to defend any line of it in a conversation. A generated report is not an experiment; a claim about a result points at your code, your input and your run record.
Every claim of feasibility is checked by the validator before performance is compared. A plan with a constraint violation is not a valid plan. An accurate diagnosis of why a plan fails earns analysis marks; a plan that “works” with a dropped order or a changed parameter earns none.
Late work loses 5% of the assignment’s marks per calendar day, for up to five days; after that it is not marked. Ask the convenor for an extension before the due date, with the reason; extensions after the due date are given only for documented circumstances.
5. Tutorial attendance and participation#
All twelve tutorials count towards the 20% tutorial component. Each week has one attendance point and one participation point, recorded separately by the tutor. Show your prediction, experiment and explanation during the session; a reasoned failure can earn the participation point. All 24 possible raw points are scaled to the 20% course weight.
For a missed session or an access need, contact the tutor as soon as possible to agree an equivalent activity and check-in. The teaching team confirms any alternative credit. The assignment late penalty above does not apply to tutorial attendance. This website does not record marks or attendance.
6. Accessibility#
Controls use native buttons, lists and text fields and work with a keyboard. Maps have named landmarks, route legends and an accessible evidence table. Search stepping is separate from flight playback. The W4 profile uses actual waypoint heights; the 3D view exaggerates height threefold to reveal the slope and labels real elevations in metres.
The shared 3D scene appears on home, W1, W4, W9, W10, W12 and Lab. It is loaded on request on a phone, with a 2D map and readable tables as the fallback. Named camera buttons support keyboard users. Nothing autoplays; reduced motion retains static selection and explicit replay controls. Leaving a page disposes of its scene and cancels its active computation.
7. Who to ask#
The tutor first, for anything in the workbench, your code, a counterexample that will not behave, or the practice-pack format — in the Wednesday tutorial, or by email when it cannot wait. The convenor for what the course expects, why a rule is the way it is, marking and extensions. Both are on the people page.