Crossover Pilot Model — Robotics/Pilot Models
Robotics/Pilot_Models/Crossover_Pilot_Model · 2 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.
Crossover Pilot Model
Robotics / Pilot Models
A human pilot closing one control loop, after D. T. McRuer's crossover model: near crossover a trained pilot adapts until pilot and vehicle together look like an integrator with a delay, YpYc = ωce−sτ/s. Given the vehicle's type, the block is the matching pilot:
u = Kp·Fp(s)·e−sτ·(xcom − x)
Ports
- x com – the commanded value of the controlled quantity, a scalar.
- x – the controlled element's actual output, a scalar. The error is x com − x, so the two inputs are not interchangeable: swapping them negates the output.
- u – the pilot's control input to the controlled element, a scalar.
Parameters
- Type of Control – the controlled element the pilot is flying,
which decides Fp(s):
- Proportional – 1/s.
- Rate or velocity, Spiral divergence – 1, a pure gain.
- Second order - Short period – 1/(Tis + 1).
- Acceleration – s, a derivative.
- Roll attitude, Unstable short period, Second order - Phugoid – T·s + 1, a lead.
- Calculated Value – which of the pilot gain and the crossover
frequency is derived from the other:
- Crossover frequency – the gain is Pilot Gain, and ωc = KpKc is only a consequence; Crossover Frequency (rad/s) is not used.
- Pilot gain – the gain is ωc/Kc,
rounded the way the Simulink block rounds it (MATLAB's
num2str: four decimals from 1 up, five significant digits below, a whole number exactly), and Pilot Gain is not used.
- Controlled Element Gain – Kc, a nonzero scalar; it enters only through ωc/Kc. Defaults to 1.
- Pilot Gain – Kp. Defaults to 3.
- Crossover Frequency (rad/s) – ωc. Defaults to 3.
- Pilot Time Delay (s) – τ, a scalar, and it must be greater than zero. Defaults to 0.1. It need not be a whole number of samples: a fractional delay is realized exactly, not rounded.
- Pilot Lead Constant – T in seconds, used by the three lead types. Defaults to 1.
- Pilot Lag Constant – Ti in seconds, nonzero, used by Second order - Short period. Defaults to 5.
- 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 one emits the same recursion the simulation runs: a delay line of past errors, the exactly discretized filter and, for the derivative types, the backward difference – with every coefficient computed at export time from the parameters and the sampling time and printed at 17 significant digits. The parameters are therefore inlined, not tunable: retuning the pilot means re-exporting.
The three hardware targets are genuine Q16.16 fixed point – a shift register for the delay and one multiply-accumulate row per state – and round rather than truncate at every shift back. A derivative type multiplies by KpT/Ts, so keep it inside the Q16.16 range (±32768) for the error steps it will see.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolibpilot/Crossover Pilot Model: Type of Control →
sw_popup (one to one and lossless; Simulink spells the four
derivative types with a trailing (*), which the mapping adds and
removes), Calculated Value → freq_gain_popup,
Controlled Element Gain → Kc, Pilot Gain →
Kp, Crossover Frequency (rad/s) → omega_c,
Pilot Time Delay (s) → time_delay, Pilot Lead
Constant → T, Pilot Lag Constant →
Ti. Simulink recomputes whichever of Kp and
omega_c is derived as soon as the others are set, so the unused one
arrives rewritten rather than as sent. The mask's pade field has no
counterpart: it is the delay's Padé order for linearization
only.
The Simulink block defines no SampleTime parameter,
measured with set_param, so the rate stays on the ICore side.
Notes
- Stateful: at most one filter state (Proportional, Short period) and a line of past errors as long as the delay, all starting at zero as Simulink's do.
- Sampled: the block runs at its sampling time, and its filter is the exact zero-order-hold discretization of the continuous model for an error held between samples – so at the sample instants it equals the continuous model. A fractional delay is realized exactly too.
- The derivative types compute (w[k] − w[k−1])/Ts on the delayed error w. That is what Simulink's Derivative block computes when its model runs at a fixed step equal to this block's sampling time; under a continuous solver Simulink's answer on a sampled error is a spike at every edge whose height depends on the solver step, and no block can match that.
- No state space: a pure delay has no finite A/B/C/D, so model reduction correctly refuses the block rather than merging it with its delay dropped. The output never depends on the input at the same instant.
- When the delay is a whole number of samples, Simulink's continuous delay still emits its initial output at exactly t = τ, where a sampled line already emits the first error. For the pure-gain, lead and derivative types the two therefore differ on that one sample (two, for a derivative), and agree everywhere else; the integrating and lag types do not show it.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Pilot_Models/Crossover_Pilot_Model |
| family | Robotics/Pilot_Models |
| solver environment class | ICoreBlock_0_Robotics_1_Pilot_Models_2_Crossover_Pilot_Model |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Pilot_Models/Crossover_Pilot_Model/ICoreBlock_0_Robotics_1_Pilot_Models_2_Crossover_Pilot_Model.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Pilot_Models/Crossover_Pilot_Model/ICoreBlock_0_Robotics_1_Pilot_Models_2_Crossover_Pilot_Model.h |
| default size on canvas | 130 × 80 px |
| ports at insert | 2 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 | x com |
| 2 | in | ICoreDouble | x |
| 3 | out | ICoreDouble | u |
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 |
|---|---|---|
Type of Control | Proportional%~%Rate or velocity%~%Spiral divergence%~%Sec… | sw_popup |
Calculated Value | Crossover frequency%~%Pilot gain~~Crossover frequency | freq_gain_popup |
Controlled Element Gain | 1 | Kc |
Pilot Gain | 3 | Kp |
Crossover Frequency (rad/s) | 3 | omega_c |
Pilot Time Delay (s) | 0.1 | time_delay |
Pilot Lead Constant | 1 | T |
Pilot Lag Constant | 5 | Ti |
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 | aerolibpilot/Crossover Pilot Model |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Type of Control | sw_popup | Proportional → Proportional, Rate or velocity → Rate or velocity, Spiral divergence → Spiral divergence, Second order - Short period → Second order - Short period, Acceleration → Acceleration(*), Roll attitude → Roll attitude(*), Unstable short period → Unstable short period(*), Second order - Phugoid → Second order - Phugoid(*) |
Calculated Value | freq_gain_popup | Crossover frequency → Crossover frequency, Pilot gain → Pilot gain |
Controlled Element Gain | Kc | passes through |
Pilot Gain | Kp | passes through |
Crossover Frequency (rad/s) | omega_c | passes through |
Pilot Time Delay (s) | time_delay | passes through |
Pilot Lead Constant | T | passes through |
Pilot Lag Constant | Ti | passes through |
Caveat (shown to the user): Simulink recomputes whichever of Kp and omega_c the Calculated value popup derives, so that field arrives rewritten; with Pilot gain derived, the gain Simulink runs is omega_c/Kc at num2str precision, which this block reproduces. The mask's pade field is the delay's Pade order for LINEARIZATION only and has no counterpart. The four (*) types contain a Derivative block, which on a sampled input matches this block only when the Simulink model runs a fixed step equal to the block's sampling time. This block is sampled: with a delay that is a whole number of samples, the direct types differ from Simulink on the one sample at t = delay, where Simulink's continuous Transport Delay still emits its initial output
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).
Crossover Pilot Model — McRuer's crossover law: the pilot the vehicle type calls for u = Kp * Fp(s) * e^(-s*tau) * (x_com - x)
MEASURED IN R2026a, reading the masked subsystem aerolibpilot/Crossover Pilot Model block by block at each of its eight types (the mask's callback is a .p file, so the subsystem is the only readable source). The outer chain never changes:
x com, x -> Sum
|-+-> Transport Delay (time_delay, InitialOutput 0, PadeOrder pade) -> Gain Kp -> "Pilot Transfer Function" -> uand the type decides what the "Pilot Transfer Function" subsystem holds:
Proportional an Integrator Fp = 1/s Rate or velocity a wire Fp = 1 Spiral divergence a wire Fp = 1 Second order - Short period Lead Lag Filter (0, 1, Ti, 1) Fp = 1/(Ti*s + 1) Acceleration() a Derivative Fp = s Roll attitude() Gain T -> Derivative, plus the wire Fp = T*s + 1 Unstable short period() the same Second order - Phugoid() the same
⚠ "CALCULATED VALUE" DECIDES WHICH OF Kp AND omega_c IS ENTERED, and the other is written back into the mask by its callback. Crossover frequency: Kp is the gain and omega_c = Kp*Kc is only displayed -- measured 2.3*1.7 = 3.91 in the field, and nothing downstream reads it. Pilot gain: the gain is omega_c/Kc, WRITTEN INTO THE Kp FIELD WITH num2str's PRECISION and run from there -- measured 5.2/1.7 -> '3.0588', 52/1.7 -> '30.5882', 0.052/1.7 -> '0.030588', 123.456789/0.7 -> '176.3668', 5.2/2.6 -> '2'. The exact quotient would be off by 2.4e-5 relative, which an integrating pilot turns into an error far above any parity tolerance.
⚠ THE FOUR (*) TYPES DIFFERENTIATE THE DELAYED ERROR. Simulink's Derivative takes (u(t) - u(t_prev))/(t - t_prev) over the solver's steps, so on a sampled error its answer is the SOLVER'S: at a fixed discrete step Ts it is the backward difference this block computes; under a continuous solver it is a spike at every edge whose height is set by the step size. The mask's own description says as much ("additional care must be taken so the input is smooth").
Checked against real sims of the block before any C++: Proportional and Short period at 1e-8 (variable-step, tight tolerance) with the delay a whole or a fractional number of samples; the pure-gain and (*) types exactly, apart from the single sample at t = tau where Simulink's continuous delay still emits its initial output.
Sample results#
| t | in ICoreDouble-Out-0 | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|---|
| 0 | -2 | -2 | 0 |
| 0.4 | 0.5 | 0.5 | 0 |
| 0.8 | -2 | -2 | 0 |
| 1.2 | 0.5 | 0.5 | 0 |
| 1.6 | -2 | -2 | 0 |
| 2 | 0.5 | 0.5 | 0 |
| 2.4 | -2 | -2 | 0 |
| 2.8 | 0.5 | 0.5 | 0 |
| 3.2 | -2 | -2 | 0 |
| 3.6 | 0.5 | 0.5 | 0 |
| 4 | -2 | -2 | 0 |
| 4.4 | 0.5 | 0.5 | 0 |
| 4.8 | -2 | -2 | 0 |
| 5.2 | 0.5 | 0.5 | 0 |
Every 4th of 60 samples, from the table stimulus.
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 … 0 |
ramp | Ramp: slope 1 from t = 0 | 0 … 0 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 0 … 0 |
step | Step: 0 -> 1 at t = 1 s | 0 … 0 |
Plotted: table — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample
Category static · sample time 0.1 · 60 steps · commit 383c0ecf1501cf1d43d89b8f688fc2fcad5e9b52 · produced by docsSample --out <folder> --blocks Ideal_Airspeed_Correction WGS84_Gravity_Model Linear_Regression_Predictor Linear_Classifier_Predictor Crossover_Pilot_Model Precision_Pilot_Model Tustin_Pilot_Model FIR_Least_Squares_Design FIR_Equiripple_Design Cartesian_To_Keplerian_Elements Keplerian_Elements_To_Cartesian --steps 60 · data docs/generated/samples/Robotics__Pilot_Models__Crossover_Pilot_Model.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).