Gear Train — Robotics/Actuators And Drivetrain
Robotics/Actuators_And_Drivetrain/Gear_Train · 2 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.
Gear Train
Robotics / Actuators And Drivetrain
An ideal gear ratio with a real efficiency: ωout = ωin / N and τout = N · η±1 · τin. A reducer trades speed for torque exactly; the efficiency is what it keeps of that trade.
The exponent follows the power flow, and that is the whole block. Driving forward, the output receives η of the ideal torque. When the load drives the gearbox back – regenerative braking, an overhauling load, a robot arm being pushed – the input shaft must be fed 1/η of it instead. A pair of Gain blocks can only apply one of the two factors, so it is right on half a duty cycle and quietly wrong on the other half.
Power flow is read from the two signs: the load is driving back when ωin and τin disagree in sign, and the shaft is driving forward otherwise.
Ports
- omega_in – the input shaft speed, any size [m,n] (rad/s, per the family's convention).
- tau_in – the torque applied to the input shaft, positive in the direction of positive omega_in. It must be the same size as omega_in; the two are paired entry by entry as one shaft's state, and neither is broadcast over the other.
- omega_out – the output shaft speed ωin/N, the same size as the inputs.
- tau_out – the output torque, the same size as the inputs.
Parameters
- Gear Ratio – N = ωin / ωout, a scalar. Greater than one is a reduction (slower, stronger); a negative N is a train that reverses direction, and is accepted. Zero is rejected. Default 10.
- Efficiency – η, a scalar in (0, 1]. The default 1 is a lossless gearbox, at which both branches are the same function – set it below one to model a real train, and note that a test which leaves it at the default verifies only half of this block.
- 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 three HDL targets are genuinely synthesizable Q16.16, not simulation-only: the block emits two comparisons and one multiply per output, with no division and nothing transcendental in the datapath.
N and η are inlined at export, not tunable. What the generated core carries is the three folded coefficients 1/N, N·η and N/η, computed once when the config is read. Exposing the ratio and the efficiency as retunable parameters would mean re-deriving those three on the core – which is exactly the divider the folding exists to keep out of the hardware. Re-export to change a gearbox.
Because both branches are pure multiplication by a constant, every backend agrees with the C++ reference to the last bit in software. The fixed-point targets carry one exposure worth stating: a sample whose omega_in or tau_in lies within one quantum (≈1.5×10−5) of zero can take the other branch in Q16.16 than it does in double precision. The two factors differ by η2, so such a sample is out by that ratio on a torque that is itself near the noise floor.
Simulink bridge
No equivalent (Support::None). The counterpart is
Simscape Driveline's Simple Gear, and Simscape is not installed on
this machine (measured: isfolder([matlabroot '/toolbox/simscape'])
is false, as for the Robotics System Toolbox). It is a physical-network block in
any case, so it would not map onto a signal-flow port list without an
interpretation this block would have to invent. To rebuild the behaviour in
Simulink: a Gain of 1/N on the speed path, and on the torque path a
Switch between gains N·η and N/η driven by a
sign comparison of the two inputs – keep the switch's zero case on the
forward gain, as this block does.
Notes
- Algebraic and stateless: both outputs depend only on the current inputs, so the block cannot break an algebraic loop. It carries no inertia and no compliance – put those in the plant on either side of it ( DC Motor upstream, Two Mass Drivetrain for a flexible shaft).
- Piecewise linear, and deliberately carries no state space. The two half-spaces have different torque gains, so a single (A, B, C, D) would describe one branch and misrepresent the other; a fabricated linear form would let model reduction merge matrices that do not describe this block.
- At zero power the forward factor applies. With ωin = 0 (a stalled shaft holding a load) or τin = 0 no power crosses the mesh and neither factor follows from physics; charging η there is this block's convention, stated rather than derived.
- Efficiency is a single constant, not a friction model. A real train's η falls at low load and with temperature; if that matters, drive this block from a lookup and put a Stribeck Friction term on the shaft.
- The output torque is what the gearbox delivers, not what the load accepts. Nothing here checks that the two are consistent – this is a signal-flow block, not a physical network.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Actuators_And_Drivetrain/Gear_Train |
| family | Robotics/Actuators_And_Drivetrain |
| solver environment class | ICoreBlock_0_Robotics_1_Actuators_And_Drivetrain_2_Gear_Train |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Robotics/Actuators_And_Drivetrain/Gear_Train/ICoreBlock_0_Robotics_1_Actuators_And_Drivetrain_2_Gear_Train.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Robotics/Actuators_And_Drivetrain/Gear_Train/ICoreBlock_0_Robotics_1_Actuators_And_Drivetrain_2_Gear_Train.h |
| default size on canvas | 140 × 84 px |
| ports at insert | 2 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 | omega_in |
| 2 | in | ICoreDouble | tau_in |
| 3 | out | ICoreDouble | omega_out |
| 4 | out | ICoreDouble | tau_out |
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 |
|---|---|---|
Gear Ratio | 10 | — |
Efficiency | 1 | — |
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::None |
| Simulink path | — |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
Caveat (shown to the user): no Simulink equivalent available: the gearbox blocks ship in Simscape Driveline (Simple Gear), and Simscape is not installed on this machine - measured, the same probe that found the Robotics System Toolbox absent. It is a physical-network block in any case, so it carries no signal-flow port list to map onto. To rebuild the behaviour there: a Gain of 1/N on the speed path, and on the torque path a Switch between gains N*eta and N/eta driven by a sign comparison of the two inputs - with the zero case on the FORWARD gain, as this block has it
Catalog contract: src/ICoreSDK/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).
Gear Train — the ratio, and the efficiency that follows the power omega_out = omega_in / N tau_out = N * eta * tau_in when omega_in and tau_in agree in sign tau_out = N / eta * tau_in when they disagree (the load is driving back)
A reducer of ratio N trades speed for torque exactly, and then loses some of it. WHICH WAY the loss is charged depends on which side is supplying the power, and that is the one thing a pair of Gains cannot express: forward, the load gets eta of the ideal torque; back-driven, the input shaft has to be fed 1/eta of it. Regenerative braking and holding torque both live on the branch a single gain gets wrong.
Three things are decided here rather than left to the reader, and each has a reason that survives into the generated code:
- THE BRANCH IS TESTED ON THE TWO SIGNS, NOT ON THE PRODUCT. omega_in * tau_in is the
power, but in Q16.16 a product of two ~1e-3 values is ~1e-6 -- below one quantum (1.5e-5) -- and rounds to zero, which reads as forward. The sign predicate is the same function in exact arithmetic, needs no multiplier, and cannot underflow.
- ZERO POWER IS FORWARD. At omega_in = 0 or tau_in = 0 nothing flows and physics does not
pick a factor; both disjuncts of the predicate are strict, so the block charges eta.
- THE COEFFICIENTS ARE FOLDED ONCE AT CONFIG LOAD -- 1/N, N*eta and N/eta -- and the C++
reference uses the SAME three numbers the generators bake in. Evaluating N/eta per sample in compute_h would leave the block a rounding away from its own export, and it would put a divider in the HDL datapath that the block otherwise never needs.
ALL TEN TARGETS, and the three HDLs are GENUINE SYNTHESIZABLE Q16.16: two comparisons and one multiply per output, no division and nothing transcendental.
Sample results#
| t | in ICoreDouble-Out-0 | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 | out ICoreDouble-Out-1 |
|---|---|---|---|---|
| 0 | -2 | -2 | -0.2 | -20 |
| 0.4 | 0.5 | 0.5 | 0.05 | 5 |
| 0.8 | -2 | -2 | -0.2 | -20 |
| 1.2 | 0.5 | 0.5 | 0.05 | 5 |
| 1.6 | -2 | -2 | -0.2 | -20 |
| 2 | 0.5 | 0.5 | 0.05 | 5 |
| 2.4 | -2 | -2 | -0.2 | -20 |
| 2.8 | 0.5 | 0.5 | 0.05 | 5 |
| 3.2 | -2 | -2 | -0.2 | -20 |
| 3.6 | 0.5 | 0.5 | 0.05 | 5 |
| 4 | -2 | -2 | -0.2 | -20 |
| 4.4 | 0.5 | 0.5 | 0.05 | 5 |
| 4.8 | -2 | -2 | -0.2 | -20 |
| 5.2 | 0.5 | 0.5 | 0.05 | 5 |
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.1 |
ramp | Ramp: slope 1 from t = 0 | 0 … 0.58 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -0.1 … 0.09996 |
step | Step: 0 -> 1 at t = 1 s | 0 … 0.1 |
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 ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Robotics__Actuators_And_Drivetrain__Gear_Train.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).