Point Mass Longitudinal — Robotics/Equations Of Motion
Robotics/Equations_Of_Motion/Point_Mass_Longitudinal · 2 input / 4 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 Longitudinal
Robotics / Equations Of Motion
A fourth-order point-mass model of flight in the vertical plane: the airspeed V, the flight-path angle γ, the altitude h and the downrange x, integrated from the force along the velocity Feast and the force normal to it Fup:
- V' = Feast/m, γ' = (Fup/m)/V
- h' = V·sin γ, x' = V·cos γ
It is the integrating half of Point Mass Forces Longitudinal, whose two outputs have the same names.
Ports
- Feast – the force along the velocity, a scalar [1,1].
- Fup – the force normal to the velocity, in the vertical plane, positive up, a scalar [1,1].
- gamma – the flight-path angle γ in radians, [1,1].
- V – the airspeed, [1,1].
- x – the downrange 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 Airspeed – V0, a nonzero scalar. Defaults to 100.
- Initial Downrange – x0. 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 four 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/4th Order Point Mass (Longitudinal): Units →
units (the two offered values 1:1), Initial Flight Path Angle
→ gamma0, Initial Airspeed → V0,
Initial Downrange → x0, 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: four continuous states, all of them outputs, so there is no direct feedthrough.
- The airspeed divides, so the model is undefined as V reaches 0; keep the run in forward flight.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Equations_Of_Motion/Point_Mass_Longitudinal |
| family | Robotics/Equations_Of_Motion |
| solver environment class | ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Point_Mass_Longitudinal |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Equations_Of_Motion/Point_Mass_Longitudinal/ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Point_Mass_Longitudinal.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Equations_Of_Motion/Point_Mass_Longitudinal/ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Point_Mass_Longitudinal.h |
| default size on canvas | 130 × 100 px |
| ports at insert | 2 in, 4 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 | Fup |
| 3 | out | ICoreDouble | gamma |
| 4 | out | ICoreDouble | V |
| 5 | out | ICoreDouble | x |
| 6 | 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 Airspeed | 100 | V0 |
Initial Downrange | 0 | x0 |
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/4th Order Point Mass\n(Longitudinal) |
| 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 Airspeed | V0 | passes through |
Initial Downrange | x0 | passes through |
Initial Altitude | h0 | passes through |
Mass | mass0 | passes through |
Caveat (shown to the user): aerolibptmass/4th Order Point Mass (Longitudinal) 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).
4th Order Point Mass (Longitudinal) — a point mass flown in the vertical plane State [V gamma h x], inputs Feast (along the velocity) and Fup (normal to it, up):
V' = Feast/m h' = sin(gamma)*V gamma' = (Fup/m)/V x' = cos(gamma)*V
⚠ MEASURED AGAINST R2026a BEFORE ANY OF IT WAS WRITTEN. The masked subsystem is four Integrators fed exactly that: Mux[Feast, Fup] ./ mass0, Demux, Product(a2, V) with "*/", and sincos(gamma) times V for the two positions -- and this chain, integrated with ode4 at 1e-4 under constant forces, reproduces its four outputs to EVERY printed digit. Three things the measurement settled:
- The ports are named Feast and Fup, which is what Point Mass Forces (Longitudinal) outputs --
the two blocks are meant to be wired together, and the forces are ALONG and NORMAL TO the velocity, whatever the names suggest.
- Metric and English (ft/s) are the same arithmetic; kts converts the airspeed around the
integrator (V0 in, V out) and is not offered -- an imported kts value is reported.
- The outputs are gamma, V, x, h -- in THAT order, which is not the state order.
V divides, so the model is undefined as the airspeed reaches zero. Continuous, with the discrete path and every exported core running ICoreEomRk4's map (bit-exact to ode4 at Ts/100 at M = 100).
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_Longitudinal.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).