Point Mass Coordinated Flight — Robotics/Equations Of Motion
Robotics/Equations_Of_Motion/Point_Mass_Coordinated_Flight · 3 input / 6 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.
Point Mass Coordinated Flight
Robotics / Equations Of Motion
A sixth-order point-mass model of coordinated flight: the airspeed V, the flight-path angle γ, the heading χ, the altitude h and the two horizontal positions x and y, integrated from the force along the velocity Feast, the horizontal force normal to it Fnorth and the vertical one Fup. With Vh = V·cos γ:
- V' = Feast/m, γ' = (Fup/m)/V, χ' = (Fnorth/m)/(V·cos γ)
- h' = V·sin γ, x' = Vh·cos χ, y' = Vh·sin χ
It is the integrating half of Point Mass Forces Coordinated Flight, whose three outputs have the same names.
Ports
- Feast – the force along the velocity, a scalar [1,1].
- Fnorth – the horizontal force normal to the velocity, a scalar [1,1].
- Fup – the vertical force normal to the velocity, positive up, a scalar [1,1].
- gamma – the flight-path angle γ in radians, [1,1].
- chi – the heading χ in radians, [1,1].
- V – the airspeed, [1,1].
- x – the downrange position, [1,1].
- y – the crossrange position, [1,1].
- h – the altitude, [1,1].
Parameters
- Units – Metric (MKS) (the default) or English (Velocity in ft/s): the same arithmetic, so the choice only names the units.
- Initial Flight Path Angle – γ0 in radians. Defaults to 0.
- Initial Heading Angle – χ0 in radians. Defaults to 0.
- Initial Airspeed – V0, a nonzero scalar. Defaults to 100.
- Initial Downrange – x0. Defaults to 0.
- Initial Crossrange – y0. Defaults to 0.
- Initial Altitude – h0. Defaults to 0.
- Mass – m, a scalar > 0. Defaults to 1.
- 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 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 and the substep are folded to constants.
The three HDL targets are simulation-only real
arithmetic, quantized at the port: a sine of a state and a division by one have no
Q16.16 form. The cores simulate correctly and are not offered as synthesizable.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolibptmass/6th Order Point Mass (Coordinated Flight): Units →
units (the two offered values 1:1), Initial Flight Path Angle
→ gamma0, Initial Heading Angle → chi0,
Initial Airspeed → V0,
Initial Downrange → x0, Initial Crossrange →
y0, Initial Altitude →
h0 and Mass → mass0 – the whole dialog.
The knots unit system is not offered – it converts the airspeed around the
integrator – 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, all of them outputs, so there is no direct feedthrough.
- The airspeed and cos γ divide, so the model is undefined as V reaches 0 or the flight path goes vertical.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Equations_Of_Motion/Point_Mass_Coordinated_Flight |
| family | Robotics/Equations_Of_Motion |
| solver environment class | ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Point_Mass_Coordinated_Flight |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Equations_Of_Motion/Point_Mass_Coordinated_Flight/ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Point_Mass_Coordinated_Flight.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Equations_Of_Motion/Point_Mass_Coordinated_Flight/ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Point_Mass_Coordinated_Flight.h |
| default size on canvas | 130 × 130 px |
| ports at insert | 3 in, 6 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 | Feast |
| 2 | in | ICoreDouble | Fnorth |
| 3 | in | ICoreDouble | Fup |
| 4 | out | ICoreDouble | gamma |
| 5 | out | ICoreDouble | chi |
| 6 | out | ICoreDouble | V |
| 7 | out | ICoreDouble | x |
| 8 | out | ICoreDouble | y |
| 9 | out | ICoreDouble | h |
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 Flight Path Angle | 0 | gamma0 |
Initial Heading Angle | 0 | chi0 |
Initial Airspeed | 100 | V0 |
Initial Downrange | 0 | x0 |
Initial Crossrange | 0 | y0 |
Initial Altitude | 0 | h0 |
Mass | 1.0 | mass0 |
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 | aerolibptmass/6th Order Point Mass\n(Coordinated Flight) |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| deliberately not crossed | Integration Substeps |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Units | units | Metric (MKS) → Metric (MKS), English (Velocity in ft/s) → English (Velocity in ft/s) |
Initial Flight Path Angle | gamma0 | passes through |
Initial Heading Angle | chi0 | passes through |
Initial Airspeed | V0 | passes through |
Initial Downrange | x0 | passes through |
Initial Crossrange | y0 | passes through |
Initial Altitude | h0 | passes through |
Mass | mass0 | passes through |
Caveat (shown to the user): aerolibptmass/6th Order Point Mass (Coordinated Flight) is continuous and has NO SampleTime parameter (verified against the R2026a block dialog). The kts unit system is not offered because it converts the airspeed around the integrator; "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).
6th Order Point Mass (Coordinated Flight) — a point mass flown in three dimensions State [V gamma h x chi y], inputs Feast (along the velocity), Fnorth (horizontal, normal to it) and Fup (vertical, normal to it), with Vh = cos(gamma)*V:
V' = Feast/m h' = sin(gamma)*V gamma' = (Fup/m)/V x' = Vh*cos(chi) chi' = ((Fnorth/m)/V)/cos(gamma) y' = sin(chi)*Vh
⚠ MEASURED AGAINST R2026a BEFORE ANY OF IT WAS WRITTEN: six Integrators inside the mask fed exactly that chain -- Mux[Feast, Fnorth, Fup] ./ mass0, Product3 as "*//" (a2 / V / cos gamma), Product2 = cos(gamma)*V shared by both horizontal positions -- and it reproduces the block the way the 4th-order one does, which it extends by the heading and the crossrange. Outputs gamma, chi, V, x, y, h, in THAT order. Same unit rule as the 4th-order block (kts not offered).
V and cos(gamma) divide, so the model is undefined as the airspeed reaches zero or the path goes vertical. 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 … 9.995e-4 |
ramp | Ramp: slope 1 from t = 0 | 0 … 0.1605 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 0 … 0.009949 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -0.003506 … 0.02078 |
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__Point_Mass_Coordinated_Flight.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).