Simulation documentation

Airport Wind Station — Usage Guide

For the Airport Wind Station simulation

By: RHLab (University of Washington) , Luis Rodriguez Gil (LabsLand) , Zhiyun Zhang (RHLab, University of Washington) , Brian Chap (RHLab, University of Washington) , Rania Hussein (RHLab, University of Washington)

Setup, wind scenarios, control requirements, test sequence, troubleshooting and credits.

Download Word version Download Markdown version
Preview of the Airport Wind Station simulation

Airport Wind Station — Usage Guide

Build a controller that turns a wind turbine toward the wind, enables generation when it is aligned, and brings it to a safe stop when wind conditions change. Airport Wind Station is a REDTAIL activity developed with the Remote Hub Lab (RHLAB) at the University of Washington and integrated with LabsLand. 3D modeling and simulation development: Zhiyun (ZZ) Zhang.

Airport Wind Station weather mast, windsock and turbine. 3D modeling and simulation development by Zhiyun (ZZ) Zhang.

Access and setup

Students use the laboratory access supplied by their instructor or course. This repository provides documentation; it does not issue student laboratory accounts or reservations. Instructors interested in using the activity can contact the REDTAIL team.

  1. Open your course's LabsLand laboratory and select Airport Wind Station with the hardware and language assigned by your instructor.
  2. Open the supplied project or starter. Check the appropriate device mapping on the Airport Wind Station page.
  3. Implement and simulate your controller, then build and program the target.
  4. Open the 3D simulation and confirm that its connection indicator shows Connected before testing. A disconnected scene is not a live test result.

The supported targets are the Altera DE1-SoC FPGA and STM32 Nucleo WB55RG. Existing controller examples cover SystemVerilog, Verilog and VHDL on DE1-SoC, and Mbed OS or C/HAL on STM32. Your course determines which project environment and materials are available.

What you control

The simulation supplies a two-bit wind code and an alignment sensor. Your controller supplies four commands: align the turbine, enable generation, keep the turbine active, and raise a runway wind alert.

The simulated environment owns the wind, turbine orientation, alignment feedback and rotor motion. Your code must respond to its sensors; it does not calculate the 3D animation or implement the browser communication protocol. The angle shown on screen is a visual aid, not an additional board input.

Input Value Meaning
inputCode[1:0] 01 Calm/negligible wind; do not generate
inputCode[1:0] 10 Steady wind; generation is permitted only after alignment
inputCode[1:0] 11 High wind; stop and raise the runway alert
inputCode[1:0] 00 Reserved; use the non-generating safe-stop path
aligned 1 Turbine is aligned with the current wind direction
aligned 0 Turbine needs alignment
Command Meaning when high
align Request turbine yaw toward the wind; movement also requires active and steady wind
generatorEnable Request generation; the plant only generates with steady wind, alignment and an active turbine
active Keep the turbine active during alignment, generation and the stopping interval
runwayWindAlert Indicate high wind at the runway

Operating requirements

Use a one-second state-machine tick for the standard activity. The DE1 wrapper runs from the 50 MHz board clock and uses a clock-enable tick; STM32 uses a non-blocking timer while continuing to sample inputs.

The required outputs for each state are:

  • STOPPED: active=0, align=0, generatorEnable=0.
  • ALIGNING: active=1, align=1, generatorEnable=0.
  • GENERATING: active=1, align=0, generatorEnable=1.
  • STOPPING: active=1, align=0, generatorEnable=0.

Apply these transition rules:

  • Start in STOPPED. With steady wind, move to ALIGNING if unaligned, or directly to GENERATING if already aligned.
  • While wind remains steady, follow the alignment sensor: ALIGNING when it is low and GENERATING when it is high.
  • If wind becomes calm, high or reserved while aligning or generating, enter STOPPING on the next state-machine tick. Enter STOPPED on the following tick, even if steady wind has returned in the meantime.
  • Assert runwayWindAlert whenever the sampled wind code is 11, without waiting for the one-second state-machine tick. On DE1 this follows the supplied input synchronizers; on STM32 it follows the input-sampling loop.

These are discrete learning requirements, not a real-world safety controller. The scene is not a flight simulator and does not model certified aviation operations, realistic energy production or an industrial turbine's protection systems.

Test the weather scenarios

Scenario What to check
Calm The turbine remains stopped, generation is off and the runway alert is off. From an active state, observe STOPPING before STOPPED.
Steady wind An unaligned turbine yaws only when commanded. Once aligned, yaw stops and generation begins.
Wind direction change Alignment falls. Generation is disabled on the next controller tick; the turbine realigns, then generation resumes.
High-wind gust The runway alert responds without waiting for the course tick. Generation stops on the next tick; the controller then becomes inactive on the following tick.

Run the scenarios from both ALIGNING and GENERATING. Also check a repeated scenario, a return to steady wind during STOPPING, and the reserved 00 input in a testbench or host test. The normal weather buttons do not generate 00. Allow time for the one-second controller ticks and for the physical animation to settle; rotor motion can lag a command during acceleration or spin-down.

Compare Current outputs with the sensor values and visible turbine behavior. On the standard DE1 wrapper, LEDR[1:0] shows 00 STOPPED, 01 ALIGNING, 10 GENERATING and 11 STOPPING. Record waveforms or test results alongside your live observations rather than relying on animation alone.

Two different reset operations

Restart activity resets the simulated environment: calm wind, initial orientation, cleared alignment and a stopped rotor. It does not reset the controller running on your board. Its existing outputs are sampled again, so an incorrect command can still produce a warning after restarting the scene.

Controller reset resets the target's controller state, not the weather or turbine geometry. On DE1-SoC, assert the supplied active-high SW[0] reset, then release it. On STM32, use the target's normal reset/reboot mechanism. With steady wind still selected, check that the controller starts safely and then responds to the unchanged plant inputs.

The first physical input slot is reserved and must be ignored. Do not use it as a reset input or shift the other signals to fill the unused slot.

Troubleshooting and accessibility

  • Disconnected or stale scene: check the laboratory session and connection status. Reopen the simulation within the active course session if necessary; do not assume a frozen picture proves that the controller is working.
  • No yaw: check steady wind, active, align, the alignment input and the platform mapping. Never swap input and output pins or remove reserved slots.
  • No generation: check steady wind, alignment and both active and generatorEnable. An unsafe command does not force the simulated plant to generate.
  • Safety notice: inspect the displayed command values and your logic. Restarting the scene is not a substitute for correcting the controller.
  • Unexpected timing: keep a one-second state tick while sampling inputs more frequently. Do not delay the runway alert with a blocking one-second sleep. Keep the supplied input synchronization on FPGA.
  • Use Reduce motion if animation is distracting. Signal details and the text status/output displays provide information without relying only on color or moving objects. Weather controls are operable with the keyboard.

Credits

  • Remote Hub Lab (RHLAB), University of Washington: the research and teaching group developing REDTAIL.
  • Zhiyun (ZZ) Zhang, University of Washington: 3D modeling and simulation development.
  • Luis Rodríguez Gil, LabsLand: concept development, firmware development and system integration.
  • Brian Chap, University of Washington: contributions to the activity specification.
  • Professor Rania Hussein, University of Washington: project leadership and direction, and principal investigator for REDTAIL.
  • LabsLand: remote-laboratory platform integration.

Development was supported in part by the National Science Foundation through REDTAIL under Award No. 2336745. Any opinions, findings, conclusions or recommendations expressed here are those of the authors and do not necessarily reflect the views of the National Science Foundation.