Three Axis Accelerometer — Robotics/Navigation Sensors

Three-axis Accelerometer

Robotics / Navigation Sensors

What a three-axis accelerometer mounted away from the centre of gravity reads: the specific force at the sensor, passed through a scale-factor and cross-coupling matrix, a bias, an optional second-order sensor response and output limits.

d = [1 −1 1] · (CG − location) – the lever arm in body axes
A = (A_b − g) + ω × (ω × d) + ω̇ × d – the specific force at the sensor
A_meas = sat( H( SFCC · A + bias ) ), with H(s) = ω_n² / (s² + 2ζω_ns + ω_n²) on each axis

Ports

• Ab – A_b, the acceleration of the CG in body axes, a [3,1] column.
• w – ω, the body angular rates p, q, r in rad/s, a [3,1] column.
• dw/dt – ω̇, the body angular accelerations in rad/s², a [3,1] column.
• CG – the centre of gravity, a [3,1] column in the same axes and units as the Accelerometer Location: station (positive aft), buttline (positive right), waterline (positive up).
• g – the gravity vector in body axes, a [3,1] column; it is subtracted, so feed zeros to measure the kinematic acceleration alone.
• A_meas – A_meas, the measured acceleration, always a [3,1] column.

The port order is the Simulink block's own. Every input must be a [3,1] column.

Parameters

• Accelerometer Location – where the sensor sits, three numbers in the station/buttline/waterline axes the CG port uses. Default [0 0 0].
• Second-order Dynamics – whether the sensor has a response:
  • on – each axis passes through H(s) above (default).
  • off – the sensor is instantaneous: A_meas = sat(SFCC · A + bias).
• Natural Frequency (rad/s) – ω_n, a scalar greater than zero. Default 190.
• Damping Ratio – ζ, a scalar of zero or more. Default 0.707.
• Scale Factors and Cross-coupling – the [3,3] matrix SFCC. The identity (default) is a perfect sensor; the diagonal holds the scale factors and the off-diagonal entries the cross-axis sensitivities.
• Measurement Bias – three numbers added after the matrix and before the dynamics, so a step in the bias is filtered like any other input. Default [0 0 0].
• Update Rate (s) – how the dynamics are realized, and the Simulink block's own "Update rate":
  • 0 (default) – continuous. Under a continuous solver the response is integrated as it stands; when the block is stepped – the discrete solver, and every code export – it is the exact zero-order-hold discretization at the block's period, which is what the continuous sensor computes from inputs that hold across each sample.
  • greater than 0 – a discrete sensor updating every that many seconds, with the Tustin (bilinear, unwarped) discretization of H(s) – exactly what the Simulink block builds for a positive rate. The block then runs at its own period, which must be this same value: set Sampling Time (s) to it, or leave that at zero with the model's sampling time equal to it. A mismatch is reported and stops the run.
• Lower and Upper Output Limits – six numbers, the three lower limits then the three upper ones, applied last. -inf and inf (default on all six) mean no limit. Each lower limit must not exceed its upper one.
• 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. Every parameter is baked in at export time, and so is the discretization: the section coefficients are computed for the block's period (or its update rate) and printed at full precision. All ten are rendered from the one description of the arithmetic the block's own simulation runs, so they perform the same operations in the same order.

The three HDL targets are simulation-only: they carry the whole model in real arithmetic and quantize only at the ports. At a period short against the sensor's response the section's poles sit close to z = 1, where Q16.16 coefficients lose the filter's DC gain, and the default limits are infinite, which fixed point cannot hold. VHDL keeps the arithmetic in a function of its own, called once per value it returns.

Simulink bridge

Import and export, mapped to Aerospace Blockset's aerolibnav/Three-axis Accelerometer. Accelerometer Location ↔ acc, Second-order Dynamics ↔ dtype_a (on/off, 1:1), Natural Frequency (rad/s) ↔ w_a, Damping Ratio ↔ z_a, Scale Factors and Cross-coupling ↔ a_sf_cc, Measurement Bias ↔ a_bias, Update Rate (s) ↔ a_Ts, Lower and Upper Output Limits ↔ a_sat, all passing their values through unchanged.

Two settings are fixed: gtype ("Subtract gravity") is always on, because turning it off deletes Simulink's g port and the port lists would no longer line up – a zero on g gives the same answer; and a_rand ("Noise on") is always off (see Notes). A model importing either at another value is reported rather than silently changed. units does not cross: on this block it changes no number (measured), only the labels. The block has no SampleTime, so Sampling Time (s) stays on the ICore side and its rate crosses as a_Ts instead – which is not the same thing: a rate of −1 in a_Ts makes the Simulink block's filter diverge.

Notes

• Stateful with the dynamics on: two states per axis, starting at zero. With Update Rate (s) at 0 the output has no direct feedthrough (it reads the response state); with a positive rate, or with the dynamics off, it does.
• No sensor noise. The Simulink block can add white noise from its own random number generator; no generated code can reproduce that sequence, so no test could confirm a noisy export, and the option is not offered. To model noise, add a Band-Limited White Noise per axis after this block – it lands after the output limits rather than before them.
• Nonlinear – the lever-arm terms are products of the rates, and the limits clamp – so the block carries no state space and model reduction reports it as unmergeable.
• The lever arm uses the [1 −1 1] sign flip because station and waterline run opposite to body x and z; a sensor at the CG sees neither lever-arm term.