Wind Angular Rates — Robotics/Flight Parameters
Robotics/Flight_Parameters/Wind_Angular_Rates · 3 input / 1 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
Wind Angular Rates
Robotics / Flight Parameters
Re-expresses the body angular rates in wind axes. The wind frame is itself turning relative to the body whenever the incidence angles change, so the block subtracts that turn before rotating what is left:
[pw qw rw]’ = DCMbw · [ p − β̇·sinα , q − α̇ , r + β̇·cosα ]’
with the body-to-wind direction cosine matrix
DCM_bw = [ cosαcosβ sinβ sinαcosβ ;
-cosαsinβ cosβ -sinαsinβ ;
-sinα 0 cosα ]
Ports
- ab – the incidence pair [α β]’, a [2,1] column in radians: angle of attack then sideslip.
- abdot – their rates [α̇ β̇]’, a [2,1] column in radians per second, in the same order.
- pqr – the body angular rates [p q r]’, a [3,1] column in radians per second.
- pqr_w – the same rates in wind axes, a [3,1] column [pw qw rw]’. Its size does not follow any input: it is always three.
Parameters
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
There are no others: every quantity arrives on a port.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text.
The three HDL targets are simulation-only: four sines and
cosines have no Q16.16 form, so the values convert at the port boundary and the
arithmetic runs in real. The cores simulate correctly and are not
offered as synthesizable. Nothing here is a tunable parameter – there is no
configuration to expose.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolibasang/Wind Angular Rates. That block has no dialog
parameters at all – measured in R2026a – so nothing is mapped and
the add_block carrying nothing is itself the assertion. It defines
no SampleTime either, so the rate stays on the ICore side.
Notes
- Algebraic and stateless: the output depends on this sample alone. α̇ and β̇ arrive as signals; the block never differentiates α and β itself.
- The angles are radians. The neighbouring Radius at Geocentric Latitude takes degrees, and the two come from the same Simulink sublibrary – check which one you are wiring.
- Not linear – every term is a trigonometric function of one input multiplying another – so the block carries no state space and model reduction correctly reports it as unmergeable.
- At zero incidence and zero incidence rate the block is the identity: [p q r]’ comes straight through, which is the cheapest check that a rig is wired the way it thinks it is.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Flight_Parameters/Wind_Angular_Rates |
| family | Robotics/Flight_Parameters |
| solver environment class | ICoreBlock_0_Robotics_1_Flight_Parameters_2_Wind_Angular_Rates |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Flight_Parameters/Wind_Angular_Rates/ICoreBlock_0_Robotics_1_Flight_Parameters_2_Wind_Angular_Rates.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Flight_Parameters/Wind_Angular_Rates/ICoreBlock_0_Robotics_1_Flight_Parameters_2_Wind_Angular_Rates.h |
| default size on canvas | 126 × 88 px |
| ports at insert | 3 in, 1 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | ab |
| 2 | in | ICoreDouble | abdot |
| 3 | in | ICoreDouble | pqr |
| 4 | out | ICoreDouble | pqr_w |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
No config variable beyond the Sampling Time (s) every block carries.
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::Both |
| Simulink path | aerolibasang/Wind Angular Rates |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
Caveat (shown to the user): the Simulink block carries no dialog parameters and no SampleTime, so the whole mapping is the library path and the port order: [alpha beta]' first, then [alphadot betadot]', then the body rates [p q r]'. Both angle ports are in RADIANS. The rate stays on the ICore side
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:
B0every stimulus in the sample errored — cross-checks skipped
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
Wind Angular Rates -- body angular rates expressed in the WIND axes [pw qw rw]' = DCM_bw * [ p - betadot*sin(alpha), q - alphadot, r + betadot*cos(alpha) ]'
The bracket is the body rate MINUS the rate at which the wind frame itself is turning relative to the body; the matrix then re-expresses what is left in wind axes. Both halves are needed and neither is a rotation on its own.
MEASURED AGAINST R2026a COLUMN BY COLUMN rather than recalled. At alpha = 0.4, beta = 0.25 rad, driving [p q r]' with each unit vector in turn, aerolibasang/Wind Angular Rates answers [1 0 0]' -> ( 0.892427438242549, -0.22787413663122019, -0.38941834230865052) [0 1 0]' -> ( 0.24740395925452294, 0.96891242171064473, 0) [0 0 1]' -> ( 0.37731226910481941,-0.096343639693493244, 0.9210609940028851) which are cos(a)cos(b), -cos(a)sin(b), -sin(a) | sin(b), cos(b), 0 | sin(a)cos(b), -sin(a)sin(b), cos(a) -- the three COLUMNS of DCM_bw, to the last bit. alphadot = 1 alone answers minus the second column, and betadot = 1 alone answers exactly [0 0 1]', which is what pins the signs of the two betadot terms: they are DCM_bw applied to [-sin(a), 0, cos(a)]', whose first two rows cancel identically and whose third is sin^2 + cos^2 = 1.
⚠ THE ANGLES ARE IN RADIANS. Nothing on the block face says so, and the neighbouring Radius at Geocentric Latitude takes DEGREES -- the two live in the same Simulink sublibrary and disagree. The column measurements above are only consistent with radians.
⚠ THE THREE HDL TARGETS ARE SIMULATION-ONLY: four sines and cosines have no Q16.16 form, so every value converts at the port boundary and the arithmetic runs in
real. The same choice, for the same reason, as Incidence, Sideslip & Airspeed.
Sample results#
No stimulus produced a sampled output in this rig — Invalid input size at Wind Angular Rates block: ICore Blocks/Home/Wind Angular Rates. That is a fact about the single-block rig, not a verdict on the block: an offline batch fit, a block whose output only appears at onSolverFinish, or one that needs a driven environment cannot be exercised alone.
Category unsampled · sample time 0.1 · 60 steps · commit 3c100aff6f27235305db4ad4d572f32e342718ad · produced by docsSample --out <folder> --blocks Radius_At_Geocentric_Latitude Relative_Ratio Wind_Angular_Rates --steps 60
Sample data: docs/generated/samples/Robotics__Flight_Parameters__Wind_Angular_Rates.json