EOM 3DOF Wind Axes — Robotics/Equations Of Motion
Robotics/Equations_Of_Motion/EOM_3DOF_Wind_Axes · 3 input / 5 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.
EOM 3DOF Wind Axes
Robotics / Equations Of Motion
The longitudinal equations of motion of a rigid body of fixed mass, carried in wind axes. With the airspeed V, the incidence α, the pitch rate q, the pitch attitude θ, the flight-path angle γ = θ − α and the earth-frame position [xe; ze]:
- V' = Fx/m − g·sin γ
- α' = Fz/(m·V) + q + g·cos γ / V
- q' = M/Iyy, θ' = q
- xe' = V·cos γ, ze' = −V·sin γ
Ports
- Fx – the force along the wind x axis (along the velocity), a scalar [1,1].
- Fz – the force along the wind z axis, a scalar [1,1].
- M – the pitching moment about the centre of gravity, a scalar [1,1].
- gamma – the flight-path angle γ in radians, [1,1].
- q – the pitch rate in rad/s, [1,1].
- Xe – the position [xe; ze] in the flat-earth frame, [2,1].
- Vw – the velocity in wind axes, [V; 0], [2,1].
- alpha – the incidence α in radians, [1,1].
Parameters
- Units – Metric (MKS) (the default) or English (velocity in ft/s). The two are the same arithmetic – the gravity is a parameter – so the choice only says which units the numbers are in.
- Initial Airspeed – V0, a scalar. Defaults to 100.
- Initial Flight Path Angle – γ0 in radians; the initial attitude is γ0 + α0. Defaults to 0.
- Initial Body Rotation Rate – q0 in rad/s. Defaults to 0.
- Initial Incidence – α0 in radians. Defaults to 0.
- Initial Position [x z] – the initial [xe ze], two values. Defaults to [0 0].
- Mass – m, a scalar > 0. Defaults to 1.
- Inertia – Iyy, a scalar > 0. Defaults to 1.
- Gravity – g, a scalar. Defaults to 9.81.
- Integration Substeps – M, how many fourth-order Runge-Kutta steps a sample is integrated with on the discrete solver and in exported code, a whole number of 1 or more. Defaults to 100. No Simulink counterpart.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. A core holds the six states, publishes the five outputs from them, and integrates one sample with the inputs held and M Runge-Kutta substeps – with M = 100, the same computation as Simulink's fixed-step ode4 at one hundredth of the sample time. The mass, inertia, gravity and substep are folded to constants; a core does 4·M derivative evaluations per sample.
The three HDL targets are simulation-only real
arithmetic, quantized at the port: a sine of a state has no Q16.16 form. The cores
simulate correctly and are not offered as synthesizable.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolib3dof2/3dof (Wind Axes): Units → units
(the two offered values 1:1), Initial Airspeed → v_ini,
Initial Flight Path Angle → gamma_ini, Initial Body
Rotation Rate → q_ini, Initial Incidence →
alpha_ini, Initial Position [x z] → pos_ini,
Mass → mass, Inertia → Iyy and
Gravity → g. Always emitted with axes =
Wind, mtype = Fixed, g_in =
Internal and vre_flag and mass_flag off: each
of those moves that block's port list, and this block has one. The knots unit
system is not offered – it converts velocities inside the integration
– and an imported one is reported. "Sampling Time (s)" does not
cross: the Simulink block is continuous and defines no
SampleTime.
Notes
- Stateful, continuous and nonlinear: six continuous states. The outputs are states, so the block has no direct feedthrough and a loop through it is not an algebraic loop.
- The airspeed divides, twice, so the model is undefined as V reaches 0; keep the run in forward flight.
- Variable mass, an external gravity and a relative-velocity input are the Simulink block's other port shapes and are not offered here.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Equations_Of_Motion/EOM_3DOF_Wind_Axes |
| family | Robotics/Equations_Of_Motion |
| solver environment class | ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_EOM_3DOF_Wind_Axes |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Equations_Of_Motion/EOM_3DOF_Wind_Axes/ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_EOM_3DOF_Wind_Axes.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Equations_Of_Motion/EOM_3DOF_Wind_Axes/ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_EOM_3DOF_Wind_Axes.h |
| default size on canvas | 130 × 110 px |
| ports at insert | 3 in, 5 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 | Fx |
| 2 | in | ICoreDouble | Fz |
| 3 | in | ICoreDouble | M |
| 4 | out | ICoreDouble | gamma |
| 5 | out | ICoreDouble | q |
| 6 | out | ICoreDouble | Xe |
| 7 | out | ICoreDouble | Vw |
| 8 | out | ICoreDouble | alpha |
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#
| Config variable | Default | Simulink parameter |
|---|---|---|
Units | Metric (MKS)%~%English (velocity in ft/s)~~Metric (MKS) | units |
Initial Airspeed | 100 | v_ini |
Initial Flight Path Angle | 0 | gamma_ini |
Initial Body Rotation Rate | 0 | q_ini |
Initial Incidence | 0 | alpha_ini |
Initial Position [x z] | [0 0] | pos_ini |
Mass | 1.0 | mass |
Inertia | 1.0 | Iyy |
Gravity | 9.81 | g |
Integration Substeps | 100 | not crossed |
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 | aerolib3dof2/3dof (Wind Axes) |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| deliberately not crossed | Integration Substeps |
| always set | axes = Wind, mtype = Fixed, g_in = Internal, vre_flag = off, mass_flag = off |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Units | units | Metric (MKS) → Metric (MKS), English (velocity in ft/s) → English (velocity in ft/s) |
Initial Airspeed | v_ini | passes through |
Initial Flight Path Angle | gamma_ini | passes through |
Initial Body Rotation Rate | q_ini | passes through |
Initial Incidence | alpha_ini | passes through |
Initial Position [x z] | pos_ini | passes through |
Mass | mass | passes through |
Inertia | Iyy | passes through |
Gravity | g | passes through |
Caveat (shown to the user): aerolib3dof2/3dof (Wind Axes) is continuous and has NO SampleTime parameter (verified against the R2026a block dialog). axes, mtype, g_in, vre_flag and mass_flag are pinned because each moves that block's port list; the kts unit system is not offered because it converts velocities inside the integration; "Integration Substeps" is how this block integrates a sample and has no counterpart
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
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).
3dof (Wind Axes) — longitudinal rigid-body equations of motion in wind axes, fixed mass State [V alpha q theta xe ze], gamma = theta - alpha, inputs Fx, Fz (WIND axes) and M:
V' = Fx/m - g*sin(gamma) theta' = q alpha' = (Fz/(m*V) + q) + g*cos(gamma)/V xe' = V*cos(gamma) q' = M/Iyy ze' = (-V)*sin(gamma)
⚠ MEASURED AGAINST R2026a: aerolib3dof2/3dof (Wind Axes) is the same compiled EOM3DOFNoAccel block as the body-axes one with axes = Wind, so it cannot be read either. Integrated with ode4 at 1e-4 for 0.5 s under constant inputs, the equations above reproduce its five outputs to ~2e-15 (the last digit or two -- an association inside the compiled block this spelling does not copy, well inside every band). What the measurement settled:
- The outputs are gamma, q, [xe ze], the wind-axis velocity [V; 0] and alpha -- five ports.
- The initial state is V0 = v_ini, alpha0 = alpha_ini and theta0 = gamma_ini + alpha_ini: the
dialog's flight-path angle is what gamma starts at, and theta_ini is not read.
- Units, mtype, g_in and the flags behave exactly as on the body-axes block.
V divides twice, so a run that takes the airspeed through zero is outside the model; the description says so. Continuous, with the discrete path and every core running ICoreEomRk4's map.
Sample results#
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | -0.5251 … 0 |
ramp | Ramp: slope 1 from t = 0 | -0.6392 … 0 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -0.5231 … 0 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -0.5361 … 0 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category dynamic · sample time 0.1 · 60 steps · commit 7a143da00 · produced by docsSample --out <folder> --blocks EOM_3DOF_Body_Axes EOM_3DOF_Wind_Axes Point_Mass_Longitudinal Point_Mass_Coordinated_Flight Acceleration_3DOF --steps 60 · data docs/generated/samples/Robotics__Equations_Of_Motion__EOM_3DOF_Wind_Axes.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).