Centrifugal Effect Model — Robotics/Gravity Models

Robotics/Gravity_Models/Centrifugal_Effect_Model · 1 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.

Centrifugal Effect Model

Robotics / Gravity Models

The centrifugal acceleration a rotating planet adds to the gravity felt at a point given in that planet's own fixed frame. The frame's z is the spin axis, so with a rotational rate ω:

gx = ω²·x
gy = ω²·y
gz = 0, exactly – a point feels the effect directly outward in the equatorial plane and nothing at all along the axis

There is no latitude here, no ellipsoid and no iteration: two multiplies and a zero. It is the term a gravity model leaves out when it reports gravitational rather than gravity acceleration.

Ports

p – the position as one [3,1], [x; y; z] in the planet-fixed frame. The shape is fixed: it is how the Simulink block is drawn, and one point crosses at a time. Its length unit is whatever ω is paired with – metres with radians per second gives metres per second squared.
g_centrifugal – the acceleration as one [3,1], in the same frame. Its third entry is always zero.

Parameters

Rotational Rate – the planet's spin rate ω, a scalar in radians per second. Defaults to 7.292115×10⁻⁵, Earth's WGS84 rate. Only its square is ever used, so a negative value gives the same answer as its magnitude.
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.

ω² is folded into a single literal at export time rather than published as a tunable parameter – a planet's spin rate is structural, and squaring it once means no target repeats the multiply. The third output row is emitted as a literal zero rather than as 0·z, so no backend can disagree about it in the last place.

The three hardware targets are simulation-only, and here the reason is unusually concrete: Earth's ω² is 5.3×10⁻⁹, about 2900 times SMALLER than the Q16.16 quantum of 1.5×10⁻⁵. Baked into a fixed-point literal it would round to zero and the block would answer zero everywhere, silently. The three carry the multiply in floating-point real and quantize only at the port boundary, so a hardware export is honest at any rate; a fixed-point core of this block would only be meaningful for a spin rate far above a planet's.

Simulink bridge

Import and export, mapped to Aerospace Blockset's aerolibgravity2/Centrifugal Effect Model. Rotational Rate → omega, value passing straight through.

Two Simulink parameters are always implied and carry no configuration here: ptype is always Custom and rate_loc always off. Custom is not cosmetic – measured in R2026a, a block left on its Earth setting accepts a written ω and discards it, answering for Earth regardless. rate_loc would move ω onto a second input port; this block reads it from its configuration, so it is pinned off. Simulink's ptype also offers eight named planets, which do not cross: each is a stored constant on the Simulink side and this block takes the number itself. The Simulink block defines no SampleTime, so the rate stays on the ICore side.

Notes

Algebraic and stateless: the output depends only on this sample's input.
No state space, although this is the one block in the family where one would be defensible – the map really is y = D·u with a constant diagonal D. It is left out because ω is a configuration rather than a signal, and model reduction has no use for a fixed scaling of a position.
The Simulink BLOCK and MATLAB's own gravitycentrifugal do not use the same Earth rate, and this block follows the block. Measured at x = 1, where gx is ω² itself: the block answers 5.3174941173224997×10⁻⁹, which is its dialog's 7.292115×10⁻⁵ squared exactly, while the function answers 5.3174941525226164×10⁻⁹ – a longer constant out of zonalplanetparams. The difference is in the eighth significant digit of the answer, far outside the 10⁻¹² band this block is held to.

Code facts#

Fact	Value
registered type	`Robotics/Gravity_Models/Centrifugal_Effect_Model`
family	`Robotics/Gravity_Models`
solver environment class	`ICoreBlock_0_Robotics_1_Gravity_Models_2_Centrifugal_Effect_Model`
source	`src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Gravity_Models/Centrifugal_Effect_Model/ICoreBlock_0_Robotics_1_Gravity_Models_2_Centrifugal_Effect_Model.cpp`
header	`src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Gravity_Models/Centrifugal_Effect_Model/ICoreBlock_0_Robotics_1_Gravity_Models_2_Centrifugal_Effect_Model.h`
default size on canvas	150 × 72 px
ports at insert	1 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`	p
2	out	`ICoreDouble`	g_centrifugal

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
`Rotational Rate`	`cFmt(EARTH_OMEGA)`	—

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	`aerolibgravity2/Centrifugal Effect Model`
port-count rule	`PortsParam::None`
`SampleTime` parameter	no — the counterpart defines none; the rate stays on the ICore side
always set	`ptype` = `Custom`, `rate_loc` = `off`

ICore config	Simulink parameter	Value translation
`CONFIG_OMEGA.c_str()`	`omega`	passes through

Caveat (shown to the user): the position crosses as one [3,1] in the PLANET-FIXED frame, whose z is the spin axis, and the acceleration comes back the same shape with its third entry always zero. 'ptype' is always written as Custom, because a block left on Earth accepts a written omega and discards it -- measured in R2026a, where a written 1.7e-4 still answered for Earth. Simulink's eight other named planets do not cross: each is a stored constant there and this block takes the number itself. 'rate_loc' is always off: switching it on moves omega onto a SECOND INPUT PORT and this block reads it from its configuration. The Simulink block has no SampleTime, so the rate stays on the ICore side. ⚠ Note the Simulink BLOCK and MATLAB's own gravitycentrifugal do NOT use the same Earth rate -- the block's dialog carries 7.292115e-5 and the function's zonalplanetparams carries 7.2921150241357389e-5, an eighth-digit difference in the answer -- and this block follows the BLOCK, which is what parity compares it against

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:

B0 1 Simulink params rule(s) this tool cannot resolve
B0 every 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.

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).

Centrifugal Effect Model -- what a planet's spin adds to the gravity it is felt with gx = omega^2 * x, gy = omega^2 * y, gz = 0

The position arrives in the planet's own fixed frame, whose z IS the spin axis, so the centrifugal acceleration points directly outward in the equatorial plane and has no component along the axis at all. There is no latitude here, no ellipsoid and no iteration: two multiplies and a zero.

⚠ gz IS EXACTLY ZERO RATHER THAN NEARLY SO, and the block writes a literal zero rather than computing one. That is what the reference does too -- gravitycentrifugal ends with gz = zeros(size(p(:,3))) -- and it matters for the export: a backend that multiplied z by something tiny would disagree in the last place on every sample for no reason.

⚠⚠ THE SIMULINK BLOCK AND MATLAB'S OWN FUNCTION DO NOT USE THE SAME EARTH RATE, AND THIS BLOCK FOLLOWS THE BLOCK. Measured in R2026a at x = 1, where gx IS omega^2:

the Simulink block, ptype Earth 5.3174941173224997e-09 -> omega 7.292115e-5 its own dialog's omega, squared 5.3174941173224997e-09 identical MATLAB's gravitycentrifugal 5.3174941525226164e-09 -> omega 7.2921150241357389e-5

The function reaches for zonalplanetparams, which carries a longer constant than the block's dialog does. The difference is in the ninth significant digit of omega and the eighth of the answer -- far outside a 1e-12 parity band, and invisible to anyone who checks the block against the function instead of against itself.

⚠ ptype MUST BE WRITTEN AS Custom OR omega IS DISCARDED. Measured: a block left on Earth accepts a written omega of 1.7e-4 and answers 5.3174941173e-09 anyway -- the Earth value. The same trap the LLA blocks carry for F and R.

ALGEBRAIC and STATELESS.

Sample results#

No stimulus produced a sampled output in this rig — Invalid input size at Centrifugal Effect Model block: ICore Blocks/Home/Centrifugal Effect Model. 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 bdad587a606126371cea1bff31197cd014d7b244 · produced by docsSample --out <folder> --blocks Centrifugal_Effect_Model Zonal_Harmonic_Gravity_Model --steps 60

Sample data: docs/generated/samples/Robotics__Gravity_Models__Centrifugal_Effect_Model.json

Centrifugal Effect Model — Robotics/Gravity Models

Description#