Acceleration 6DOF — Robotics/Equations Of Motion

Robotics/Equations_Of_Motion/Acceleration_6DOF · 4 input / 2 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.

6DOF Acceleration

Robotics / Equations Of Motion

The two accelerations a rigid body in body axes actually has, from the total applied force, the mass, the body rates and the body-axis velocity:

A_be = F / m – the acceleration relative to an inertial frame, expressed in body axes.
A_bb = F / m − ω × (k·V_b) – the rate of change of the body-axis velocity components themselves.

The difference is the transport term ω × V_b. A body turning at constant speed has a real inertial acceleration and an unchanging body-axis velocity, and these two outputs are exactly that distinction.

Ports

Vb – the body-axis velocity V_b = [u v w]’, a [3,1] column, in whatever unit Velocity Units says.
omega – the body angular rates ω = [p q r]’ in rad/s, a [3,1] column.
m – the mass, a [1,1] scalar.
F – the total applied force in body axes, a [3,1] column.
Abb – the first output, a [3,1] column: the acceleration of the body-axis velocity itself, the one with the transport term.
Abe – the second output, a [3,1] column: F/m, the inertial acceleration in body axes, with no velocity in it at all.

⚠ Reading the two outputs the other way round is out by ω × V_b, which is zero whenever the body is not turning – so the mistake is invisible in straight and level flight and appears only in a turn. The input order is Vb, omega, m, F, which is the Simulink block's own.

Parameters

Velocity Units – what unit V_b arrives in, and nothing else. It scales V_b before the cross product so that the velocity meets the acceleration in consistent units:
- Metric (MKS) – m/s against m/s²; the scale is 1. The default.
- English (Velocity in ft/s) – ft/s against ft/s²; the scale is also 1, so this setting is arithmetically identical to Metric.
- English (Velocity in kts) – knots against ft/s²; the scale is 1852/(3600·0.3048), a knot in ft/s.
It reaches A_bb only: F/m has no velocity in it.
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.

The velocity scale is inlined at export time rather than exposed as a tunable parameter – it is a unit convention, not a setting to retune on a deployed core – so changing Velocity Units means re-exporting.

The three HDL targets are simulation-only real arithmetic, not synthesizable fixed point: the force is divided by a mass arriving on a port, and the Q16.16 base a block body is given has no division. They quantize at the port boundary and evaluate in real – correct in simulation, and not offered as hardware.

Simulink bridge

Import and export, mapped to Aerospace Blockset's aerolib6dof2/6DOF Acceleration at its Fixed mass type, which is pinned as a fixed parameter. Velocity Units → units, value for value with the dialog's own three strings, so the mapping is 1:1 and lossless in both directions. The Simulink block defines no SampleTime, so the rate stays on the ICore side and a block given an explicit positive period reports that it did not cross.

Notes

Algebraic and stateless: both outputs depend on this sample alone.
A zero mass answers all zeros on both outputs rather than infinities, on an exact zero test and not a tolerance band. A very small mass gives a very large acceleration and is left alone.
Metric and English (ft/s) are the same arithmetic, measured. The parameter distinguishes them for the reader's sake; only the knots setting moves a number.
Variable mass is not this block. The Simulink counterpart's other mass types add a mass flow rate and a relative exhaust velocity; this is the fixed one, and the bridge pins the parameter rather than guessing.
Not linear – a division by an input and a product of two others – so the block carries no state space and model reduction correctly reports it as unmergeable.

Code facts#

Fact	Value
registered type	`Robotics/Equations_Of_Motion/Acceleration_6DOF`
family	`Robotics/Equations_Of_Motion`
solver environment class	`ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Acceleration_6DOF`
source	`src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Equations_Of_Motion/Acceleration_6DOF/ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Acceleration_6DOF.cpp`
header	`src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Equations_Of_Motion/Acceleration_6DOF/ICoreBlock_0_Robotics_1_Equations_Of_Motion_2_Acceleration_6DOF.h`
default size on canvas	140 × 104 px
ports at insert	4 in, 2 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`	Vb
2	in	`ICoreDouble`	omega
3	in	`ICoreDouble`	m
4	in	`ICoreDouble`	F
5	out	`ICoreDouble`	Abb
6	out	`ICoreDouble`	Abe

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
`Velocity Units`	`std::string(UNITS_METRIC)%~%UNITS_FTPS%~%UNITS_KTS~~UNITS…`	`units`

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	`aerolib6dof2/6DOF Acceleration`
port-count rule	`PortsParam::None`
`SampleTime` parameter	no — the counterpart defines none; the rate stays on the ICore side
always set	`mtype` = `Fixed`

ICore config	Simulink parameter	Value translation
`Velocity Units`	`units`	`UNITS_METRIC` → `Metric (MKS)`, `UNITS_FTPS` → `English (Velocity in ft/s)`, `UNITS_KTS` → `English (Velocity in kts)`

Caveat (shown to the user): Velocity Units -> units, value for value with the dialog's own three strings, so the enum is 1:1 and lossless both ways. mtype is pinned to Fixed: the other mass types add a mass flow rate and a relative exhaust velocity, which this block does not carry, so an import naming one is reported rather than silently wired. The port order is Vb, omega, mass, Forces, and the OUTPUT order is Abb then Abe -- the transport term is on the FIRST one. No SampleTime parameter, so the rate stays on the ICore side

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

6DOF Acceleration -- the two accelerations a rigid body in body axes actually has Abe = F / m relative to an inertial frame, expressed in body axes Abb = F / m - w x (k * Vb) the rate of change of the body-axis velocity itself

The difference between them is the TRANSPORT term w x Vb: a body turning at constant speed has a nonzero inertial acceleration and a zero rate of change of its own body-axis velocity components, and the two outputs are exactly that distinction.

MEASURED AGAINST R2026a, both outputs bit for bit. At Vb = [85.3 -6.2 3.7]', w = [0.13 -0.27 0.41]', m = 1450.5 and F = [2100 -640 780]', aerolib6dof2/6DOF Acceleration answers

Abb = (-0.095223371251292432, -34.933227163047221, -21.687254395036195) Abe = ( 1.4477766287487073, -0.44122716304722509, 0.53774560496380563)

and F/m - cross(w, Vb) and F/m are those two numbers. Reading the mask confirms the shape: one Divide (the total force over the mass), one Cross Product subsystem, and a Sum -- with two Velocity Conversion subsystems standing in front of the cross product, which is what the units parameter reaches.

⚠ PORT 1 IS Abb AND PORT 2 IS Abe. Reading them the other way round is out by w x Vb, which is ZERO whenever the body is not turning -- so the mistake cannot be seen in straight and level flight and appears only in a turn. The port order in is Vb, omega, mass, Forces.

⚠ units IS LIVE ON THIS BLOCK, unlike on the two Angular Acceleration blocks where the same parameter is inert. MEASURED, all three values on the same numbers: Metric (MKS) and English (Velocity in ft/s) are byte-identical, and English (Velocity in kts) moves Abb and ONLY Abb. It is a scale on Vb before the cross product -- k = 1852/(3600*0.3048), a knot in ft/s -- so that a velocity in knots meets an acceleration in ft/s^2. Abe never sees it, because F/m has no velocity in it.

THE THREE HDL TARGETS ARE SIMULATION-ONLY real. The force is divided by a mass arriving on a PORT, and the Q16.16 base this tree gives a block body has no division -- the same reason Invert 3x3 Matrix evaluates in real. They quantize at the port boundary and are correct in simulation; they are not offered as hardware.

A ZERO MASS ANSWERS ALL ZEROS on BOTH outputs, on an EXACT zero rather than a tolerance band -- the convention Invert 3x3 Matrix set in this tree for the same situation.

Sample results#

No stimulus produced a sampled output in this rig — Invalid input size at 6DOF Acceleration block: ICore Blocks/Home/Acceleration 6DOF. 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 901c8f3d91c4f7251430ad097012afb44717ccc2 · produced by docsSample --out <folder> --blocks Equations_Of_Motion --steps 60

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