Moments About CG Due To Forces — Robotics/Mass Properties
Robotics/Mass_Properties/Moments_About_CG_Due_To_Forces · 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.
Moments about CG due to Forces
Robotics / Mass Properties
The moment a force applied at a point produces about the centre of gravity: the lever arm from the CG to the point of application, crossed into the force.
M = (CP − CG) × F
Ports
- Forces – the applied force F, a [3,1] column in body axes.
- CG – the centre of gravity, a [3,1] column of positions in the same frame and units as CP.
- CP – the centre of pressure, or wherever the force is applied, a [3,1] column.
- Moments – the moment M, a [3,1] column. Its size does not follow any input: it is always three.
The port order is Forces, CG, CP, which is the Simulink block's own and is not the order the formula reads – the force is wired first and the lever arm is formed from the two positions after it.
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: all three quantities arrive on ports.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text.
The three HDL targets are genuinely synthesizable: three
subtractions, six products and three differences, with no root, no division and
nothing evaluated in real. The one caution is the usual one for a
product in Q16.16 – it is the range that bounds it, not the
precision, and an arm of 100 crossed into a force of 400 has already left it.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolibbdyn/Moments about CG due to Forces. 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. Its library path carries an embedded newline with a trailing
space before it, which is why the entry spells it out rather than typing it.
Notes
- Algebraic and stateless: the output depends on this sample alone.
- The argument order is the sign. (CP − CG) × F and F × (CP − CG) differ only by a minus, so a model that has them the wrong way round produces a moment of the right magnitude turning the wrong way – which no size check and no suite that compares magnitudes can catch. A force along +x applied at +y, about a CG at the origin, must give a moment along −z.
- A force through the CG produces no moment: CP = CG makes the arm zero and the output exactly zero in all ten targets.
- Linear in each input separately, but not jointly – every term is a product of two inputs – so the block carries no state space and model reduction correctly reports it as unmergeable.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Mass_Properties/Moments_About_CG_Due_To_Forces |
| family | Robotics/Mass_Properties |
| solver environment class | ICoreBlock_0_Robotics_1_Mass_Properties_2_Moments_About_CG_Due_To_Forces |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Mass_Properties/Moments_About_CG_Due_To_Forces/ICoreBlock_0_Robotics_1_Mass_Properties_2_Moments_About_CG_Due_To_Forces.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Mass_Properties/Moments_About_CG_Due_To_Forces/ICoreBlock_0_Robotics_1_Mass_Properties_2_Moments_About_CG_Due_To_Forces.h |
| default size on canvas | 132 × 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 | Forces |
| 2 | in | ICoreDouble | CG |
| 3 | in | ICoreDouble | CP |
| 4 | out | ICoreDouble | Moments |
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 | aerolibbdyn/Moments about CG \ndue to Forces |
| 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: Forces, then CG, then CP -- which is NOT the order the formula (CP - CG) x F reads. The library path carries an embedded newline with a SPACE before it, so it is written out rather than typed. The rate stays on the ICore side
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).
Moments about CG due to Forces -- M = (CP - CG) x F The moment a force applied at a point produces about the centre of gravity: the lever arm from the CG to the point of application, crossed into the force.
MEASURED AGAINST R2026a, with unit probes chosen so that the ARGUMENT ORDER and the SIGN -- which are the same mistake -- cannot both be wrong and still pass. A force along +x applied at +y about a CG at the origin gives [0 0 -1]; the same force along +y applied at +x gives [0 0 +1]. Swapping the cross product's arguments negates both. A general point agrees to the last bit: F = [2 -3 1.5]', CG = [0.4 -0.2 0.7]', CP = [1.1 0.9 -0.3]' answers (-1.3499999999999999, -3.0499999999999998, -4.3000000000000007).
⚠ THE PORT ORDER IS Forces, CG, CP -- read off the Simulink block's own inner Inport names. It is worth stating because the FORMULA reads CP first, so the natural wiring order and the natural reading order are not the same one.
SYNTHESIZABLE in all three HDL targets: three subtractions, six products and three differences. Nothing converts to
real, and the only Q16.16 caution is the usual one for a product -- an arm of 100 crossed into a force of 400 already leaves the range.
Sample results#
Plotted: vector — Sine Wave, [3,1]: amplitudes 1/2/3 at 2 rad/s (tried only because every scalar stimulus was refused)
Category dynamic · sample time 0.1 · 60 steps · commit 3c100aff6f27235305db4ad4d572f32e342718ad · produced by docsSample --out <folder> --blocks Calculate_Range Moments_About_CG_Due_To_Forces Symmetric_Inertia_Tensor --steps 60 · data docs/generated/samples/Robotics__Mass_Properties__Moments_About_CG_Due_To_Forces.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).