Robot Control Software — Ch.03: Motor Control Software [EN]

STATERA Library · Series 08 · Volume 04 · Chapter 03 · EN
Source: https://github.com/Statera-Library/08_Vol_04_Robot_Control_Software/blob/main/Chapter_03_Motor_Control_Software/Chapter_03_Motor_Control_Software_EN.md

Volume 04 Robot Control Software

03. Motor Control Software

03.01 DC Motor Control Software Structure [w/Code]

DC motor control software forms the execution layer that converts motion or torque commands into deterministic electrical actuation. Within the robot control software hierarchy, it sits between higher-level motion controllers and hardware-dependent motor drivers. A practical implementation must coordinate command handling, feedback acquisition, control computation, PWM generation, protection logic, diagnostics, and state management while preserving predictable real-time behavior.

The software structure is commonly divided into application interfaces, control logic, hardware abstraction, and device-driver functions. The upper interface receives requested speed, torque, position, direction, enable, and braking commands from motion-control software. These commands should not directly manipulate PWM registers. Instead, they pass through validation, limiting, state checking, and control layers so that hardware behavior remains isolated from application-level decisions.

A motor-control state machine provides the supervisory framework for the complete execution sequence. Typical logical states include initialization, disabled, ready, starting, running, braking, stopping, and fault handling. Transitions are triggered by commands, measured operating conditions, diagnostic events, or safety signals. Explicit state management prevents conflicting actions such as simultaneously requesting forward drive and dynamic braking and makes abnormal transitions easier to detect.

At initialization, the software configures PWM timers, ADC channels, encoder or Hall interfaces, GPIO signals, communication peripherals, watchdogs, and protection inputs. Calibration values and motor parameters are loaded before actuator output is permitted. The control software should verify that measured voltage, current, temperature, and feedback signals are within acceptable startup ranges, while PWM outputs remain disabled until initialization and safety checks have completed successfully.

Command processing converts an external motor request into an internally consistent reference. A signed command can represent rotational direction while its magnitude represents requested voltage, current, torque, or velocity. The software applies saturation, dead-zone compensation, slew-rate limitation, and operating-mode constraints before forwarding the reference to the controller. This prevents abrupt command changes from producing excessive current or mechanical shock in the drivetrain.

For a basic brushed DC motor, actuator output is normally produced through an H-bridge controlled by PWM and direction signals. The software calculates a normalized duty-cycle command and maps it to timer compare values according to the configured PWM period. Direction changes require particular care because immediately reversing bridge polarity while substantial current is flowing can generate severe electrical and mechanical stress. A controlled transition through zero output is therefore normally required.

The control loop should execute at a fixed sampling interval rather than being driven by irregular application events. A timer interrupt or real-time task can trigger acquisition of current, voltage, speed, and position feedback followed by control calculation and PWM update. Fast electrical protection may execute directly in an interrupt or hardware-assisted path, while slower velocity control, thermal monitoring, diagnostics, and communication can operate at lower rates through scheduled tasks.

Feedback processing creates reliable control variables from raw hardware measurements. ADC samples for motor current and bus voltage require offset compensation, scaling, range checking, and often digital filtering. Encoder counts can be transformed into position and rotational velocity, while Hall or tachometer signals may provide lower-cost speed information. Timestamp consistency is important because measurement latency and variable sampling intervals directly affect closed-loop controller performance.

A velocity-controlled DC motor typically compares the requested speed with measured speed and processes the error through a PI or PID controller. The resulting command may represent voltage or PWM duty ratio. Anti-windup should be included because actuator saturation is unavoidable when the requested output exceeds available bus voltage. Feedforward terms can additionally compensate for expected back electromotive force, friction, or known load characteristics and reduce feedback error.

Current control can form a faster inner loop when torque regulation or actuator protection requires greater precision. Because DC motor torque is approximately proportional to armature current within the normal operating region, the current reference can represent a desired torque command. A cascaded structure may therefore use an outer velocity controller to generate the current reference and an inner current controller to regulate PWM, separating mechanical and electrical control dynamics.

The hardware abstraction layer separates control algorithms from MCU-specific peripherals. Functions such as setting PWM duty, enabling the bridge, reading current, obtaining encoder counts, or activating braking should be exposed through stable interfaces rather than scattered register operations. This structure allows the same controller logic to be reused across different microcontrollers, motor-driver ICs, simulation targets, and hardware revisions with limited modification to low-level software.

A representative control cycle can conceptually follow the sequence Acquire → Validate → Estimate → Control → Limit → Actuate → Diagnose\. Sensor values are acquired first and checked for plausibility before being used to calculate velocity, current, or other derived states. The controller generates the requested actuator command, which is then constrained by electrical, thermal, mechanical, and safety limits before the final PWM and bridge-control outputs are written.

Protection logic must remain independent enough to override normal control commands whenever operation becomes unsafe. Overcurrent, overvoltage, undervoltage, excessive temperature, encoder failure, stalled rotor, communication timeout, and invalid command conditions can trigger output limitation or shutdown. Critical faults should disable bridge operation immediately, whereas recoverable conditions may request controlled deceleration or reduced-performance operation according to the defined safety strategy.

Diagnostics should preserve sufficient context to explain why motor behavior changed. Fault identifiers, operating state, requested command, measured speed, current, voltage, temperature, PWM duty, and timestamps can be captured when an abnormal event occurs. Counters for repeated overcurrent events, command timeouts, saturation duration, and startup failures provide useful information for maintenance and reliability analysis without requiring continuous storage of every high-frequency control sample.

Concurrency requires careful design because command interfaces, communication tasks, diagnostic services, and fast control loops may access the same motor state. Shared variables should use atomic operations, protected buffers, or deterministic message exchange where appropriate. The fast control path should avoid dynamic memory allocation, blocking communication, file operations, and unbounded computation. Execution time must remain comfortably below the control period under worst-case operating conditions.

The software API should expose motor behavior rather than hardware implementation details. Operations may include enable, disable, set velocity, set torque, stop, brake, clear recoverable fault, obtain status, and retrieve measurements. Each request should pass through state and range validation. Higher-level robot software can consequently treat the motor controller as a predictable actuator service while low-level switching details remain encapsulated inside the motor-control module.

Configuration data should distinguish immutable hardware characteristics from tunable control parameters. Motor resistance, torque constant, gear ratio, encoder resolution, current-sensor gain, PWM frequency, current limit, velocity limit, controller gains, acceleration limits, and thermal thresholds should be explicitly represented and version controlled. Parameter validation at startup prevents corrupted or incompatible calibration data from silently producing unstable or unsafe actuator behavior.

Testing should mirror the layered software structure. Pure control algorithms can first be verified with unit tests and numerical motor models, followed by software-in-the-loop testing of state transitions and saturation behavior. Processor-in-the-loop and hardware-in-the-loop environments can then verify timing, PWM generation, sensor interfaces, communication loss, and fault reactions before operation with the physical motor and mechanical load. This progression reduces debugging risk during integration.

A reusable implementation benefits from representing each motor as an explicit software object or context containing configuration, measurements, references, controller states, diagnostic flags, and operating state. Functions operate on this context rather than relying heavily on global variables. The same control implementation can then support multiple motors, provided scheduling and hardware resources are assigned deterministically, which becomes important in differential-drive robots and multi-axis systems.

The DC motor controller ultimately acts as a deterministic boundary between abstract robot motion and physical energy conversion. Its quality therefore depends not only on the mathematical controller but also on scheduling, state supervision, signal processing, hardware abstraction, fault containment, parameter traceability, and diagnostics. This layered foundation also prepares the software architecture for the more sophisticated BLDC, PMSM FOC, sensor-processing, protection, and multi-axis topics that follow in the motor-control chapter.

03.02 BLDC 6-Step Control Implementation [w/Code]

Brushless DC (BLDC) six-step control is a commutation method that energizes two motor phases at a time while leaving the third phase electrically floating. The inverter advances through six discrete switching states during each electrical revolution, producing an approximately trapezoidal phase-current pattern. The software implementation must coordinate rotor-position detection, commutation sequencing, PWM generation, direction control, startup behavior, current regulation, protection, and timing with deterministic execution.

A three-phase BLDC drive normally consists of phases U, V, and W connected to a six-switch inverter containing three high-side and three low-side power devices. At each commutation step, one phase is connected toward the positive DC bus, another toward the negative bus, and the remaining phase is floating. Software selects the appropriate switch combination while ensuring that complementary devices in the same inverter leg are never simultaneously activated.

The six commutation states correspond to six 60-degree electrical sectors. A typical forward sequence can be represented conceptually as U+V−, U+W−, V+W−, V+U−, W+U−, and W+V−. After the sixth state, the sequence returns to the first state. Reverse rotation is obtained by traversing the commutation sequence in the opposite order rather than simply reversing a single output signal.

Rotor position determines when the controller should advance from one commutation state to the next. Hall-sensored BLDC motors commonly provide three digital Hall signals whose valid combinations identify rotor sectors. The software reads the three inputs as a compact Hall code, validates the code, maps it to the corresponding commutation state, and updates the inverter outputs. Invalid combinations such as all-zero or all-one states should be treated as diagnostic conditions.

Hall transitions can be processed using GPIO interrupts or captured by timer peripherals. Interrupt-driven processing minimizes commutation latency because the inverter state can be updated immediately after a rotor-sector transition. The software should nevertheless reject implausibly fast transitions, detect missing transitions, and verify that the observed Hall sequence agrees with the requested direction. These checks provide basic detection of wiring faults, sensor failures, and stalled operation.

Commutation output should be implemented through a predefined switching table rather than scattered conditional statements. Each table entry identifies the sourcing phase, sinking phase, floating phase, and associated PWM configuration for one electrical sector. A table-driven implementation improves execution-time predictability and makes forward and reverse sequences easier to inspect, test, and modify while keeping switching behavior separate from higher-level speed-control logic.

PWM controls the average voltage applied to the energized windings and therefore influences motor current, torque, and speed. Depending on the gate-driver and inverter strategy, PWM may be applied to the active high-side device, active low-side device, or both using complementary switching. The software converts a normalized voltage or torque request into timer compare values while respecting minimum and maximum duty-cycle limits and the characteristics of the power stage.

Dead time is required when complementary switches share the same inverter leg. During a switching transition, the conducting device must turn off before its complementary device is allowed to turn on. Without sufficient dead time, both devices can conduct simultaneously and create a destructive shoot-through current across the DC bus. Dead-time generation should preferably use dedicated timer hardware, while software configuration ensures that the value matches the switching-device and gate-driver characteristics.

The commutation process and PWM update must be synchronized carefully. Changing phase states at arbitrary points within a PWM cycle can produce unwanted switching pulses, current spikes, or inconsistent output timing. Advanced timers can preload compare and output-mode registers and apply them at defined update events. This allows the software to calculate the next switching configuration while hardware performs the actual transition at a deterministic PWM boundary.

Startup requires special handling because rotor motion may initially be absent and sensorless feedback may therefore be unavailable. With Hall sensors, the initial Hall state can identify the rotor sector and permit immediate selection of a valid commutation state. The controller can then increase duty cycle gradually using a startup ramp. Excessive initial duty should be avoided because a stationary motor has no back electromotive force and can draw substantial current.

For sensorless six-step control, startup generally begins with rotor alignment followed by an open-loop commutation sequence. The controller energizes a known phase combination to establish an initial rotor orientation and then advances the commutation states with progressively changing timing until sufficient speed is reached. Once reliable back electromotive force information becomes available, the software transitions from open-loop startup to closed-loop sensorless commutation.

Sensorless operation commonly observes the back electromotive force of the floating phase. During each commutation sector, the unenergized phase voltage changes as the rotor moves, and its crossing relative to a virtual or measured neutral reference can be used to estimate rotor position. Because the zero crossing does not directly represent the ideal commutation instant, the software normally applies an electrical-angle delay before advancing to the next switching state.

Back-EMF processing requires filtering and blanking because inverter switching produces substantial electrical noise. Immediately after commutation, the floating-phase measurement can contain switching transients that would cause false zero-crossing detection. A blanking interval temporarily suppresses detection, after which ADC or comparator measurements are evaluated. Digital filtering, hysteresis, and timing plausibility checks can further improve robustness without introducing excessive phase delay.

Speed estimation can be derived from Hall-transition periods, commutation intervals, or back-EMF events. The controller measures elapsed timer counts between valid rotor events and converts electrical frequency into mechanical rotational speed using the motor pole-pair count. At low speed, period measurement generally provides better resolution than counting transitions within a fixed interval. Filtering should balance noise reduction against the response required by the outer speed-control loop.

A closed-loop speed controller compares the requested rotational speed with the estimated speed and generates a duty-cycle or current reference. PI control is commonly sufficient for six-step drives, provided output saturation and anti-windup are implemented. Acceleration and deceleration limits should be applied to the reference so that large command steps do not produce abrupt torque changes, excessive current, wheel slip, or mechanical shock when the motor is integrated into a robot drivetrain.

Current measurement provides both control information and critical hardware protection. Depending on the inverter design, current may be measured using a DC-link shunt, low-side phase shunts, or individual phase sensors. Software performs offset correction, scaling, filtering, and plausibility checks before using the measurement. Because current sampling is affected by PWM switching states, ADC triggering should be synchronized to a region where the current signal is sufficiently stable.

Current limiting can operate independently of the slower speed loop. When measured current approaches the configured limit, the controller can reduce PWM duty or constrain the speed-controller output. Severe overcurrent should bypass normal regulation and activate a fast protection path implemented through hardware comparator logic or a high-priority interrupt. This distinction between control limiting and emergency shutdown prevents normal transient loads from being treated identically to dangerous electrical faults.

Direction reversal should be treated as a controlled state transition. Immediately changing from the forward commutation table to the reverse table while the rotor is spinning can produce large regenerative current and mechanical stress. The software should reduce torque, decelerate toward an acceptable speed, disable or brake the inverter according to system requirements, and only then enable the reverse commutation sequence. State-machine supervision makes this sequence deterministic.

Fault handling must cover invalid Hall states, incorrect Hall sequence, commutation timeout, motor stall, overcurrent, DC-bus overvoltage or undervoltage, excessive motor or inverter temperature, gate-driver faults, and command timeout. Each fault should be classified according to severity and recovery policy. Critical electrical faults immediately disable PWM, while recoverable conditions may permit controlled stopping, limited operation, or restart after explicit validation.

A reusable implementation separates the fast commutation path from supervisory and communication functions. High-priority interrupt routines handle Hall transitions, timer events, ADC synchronization, and immediate protection, while periodic control tasks calculate speed, PI output, thermal limits, and diagnostic status. Lower-priority software manages commands, parameter updates, logging, and external interfaces. This separation prevents communication latency from disturbing switching and control timing.

The resulting six-step controller forms a structured chain from command input through speed control, duty calculation, rotor-sector detection, commutation lookup, PWM generation, inverter switching, motor response, and feedback acquisition. Although six-step control is simpler than field-oriented control, robust robot deployment still requires precise timing, synchronized sensing, safe switching, deterministic state management, and comprehensive diagnostics. These principles provide the software foundation for subsequent PMSM FOC and SVPWM implementations.

03.03 PMSM FOC Algorithm: Clark / Park Transform [w/Code]

A Permanent Magnet Synchronous Motor (PMSM) controlled by Field-Oriented Control (FOC) is regulated by transforming three-phase electrical quantities into a rotating reference frame aligned with the rotor magnetic field. This approach converts the coupled AC motor-control problem into two approximately independent DC control channels. The direct-axis current controls magnetic flux, while the quadrature-axis current primarily controls electromagnetic torque.

The FOC software pipeline begins with synchronized acquisition of phase currents, DC-link voltage, rotor electrical position, and optional temperature or speed signals. Current measurements must be sampled at deterministic points relative to PWM switching because inverter transitions introduce noise and measurement distortion. Offset compensation, gain correction, plausibility checking, and filtering are normally completed before measured currents enter the coordinate transformations.

For a balanced three-phase PMSM, the phase currents satisfy approximately \(i_a+i_b+i_c=0\). Consequently, only two independent current components are required to represent the stator current vector. The Clarke transform converts the measured three-phase quantities from the stationary \(abc\) system into the two-axis stationary \(\alpha\beta\) reference frame, significantly simplifying subsequent vector calculations while preserving the electrical information needed for control.

A commonly used amplitude-invariant Clarke transform expresses the stationary components as \(i_\alpha=i_a\) and \(i_\beta=(i_a+2i_b)/\sqrt{3}\), assuming the zero-sequence component is negligible. Equivalent matrix forms can use all three phase measurements. The implementation must maintain one consistent transform convention throughout current sensing, Park transformation, inverse transformation, modulation, and motor-model calculations.

The \(\alpha\beta\) current vector remains stationary with respect to the stator, while the PMSM rotor magnetic field rotates continuously. Direct regulation in this stationary frame would therefore require controllers to track sinusoidally varying quantities. The Park transform solves this problem by rotating the \(\alpha\beta\) coordinate system according to the instantaneous rotor electrical angle, producing the rotating direct-quadrature \(dq\) reference frame.

Using one common sign convention, the Park transform is expressed as \(i_d=i_\alpha\cos\theta_e+i_\beta\sin\theta_e\) and \(i_q=-i_\alpha\sin\theta_e+i_\beta\cos\theta_e\). Here, \(\theta_e\) is the rotor electrical angle. When the reference frame is correctly aligned, \(i_d\) represents the current component parallel to rotor flux and \(i_q\) represents the perpendicular component responsible for producing useful electromagnetic torque.

The electrical rotor angle differs from the mechanical rotor angle according to the number of pole pairs. It is generally calculated as \(\theta_e=p\theta_m+\theta_{offset}\), where \(p\) is the pole-pair count and \(\theta_{offset}\) represents the calibrated electrical alignment offset. Incorrect pole-pair configuration, encoder direction, or offset produces incorrect \(dq\) alignment and can cause poor torque production, excessive current, vibration, or unstable control.

Rotor position can be obtained from incremental encoders, absolute encoders, resolvers, Hall sensors, or sensorless estimators. High-performance FOC requires sufficiently accurate electrical-angle information because transformation error directly couples the d-axis and q-axis quantities. Position acquisition therefore includes sensor decoding, angle normalization, direction handling, electrical-zero calibration, validity monitoring, and compensation for sampling or computational delay where necessary.

After the Park transform, the measured \(i_d\) and \(i_q\) values are compared with their references. For many surface-mounted PMSM applications below the field-weakening region, the d-axis reference is approximately zero while the q-axis reference is generated from the requested torque. Two independent PI current controllers then calculate the required \(v_d\) and \(v_q\) voltage commands, allowing flux and torque to be regulated independently.

The q-axis current reference can be generated directly from a torque request or indirectly by an outer velocity controller. In a cascaded speed-control structure, the velocity PI controller compares requested and measured rotor speed and produces \(i_q^*\). The current controller executes at a substantially higher frequency than the velocity loop so that electrical dynamics are regulated rapidly while the outer loop responds to slower mechanical dynamics.

Current-controller performance can be improved using decoupling and feedforward terms derived from the PMSM voltage equations. Rotating-frame dynamics contain cross-coupling terms involving electrical speed, inductance, current, and permanent-magnet flux. Compensating these terms reduces interaction between the d and q channels and improves dynamic response, particularly when the motor operates at higher electrical speeds where back electromotive force becomes significant.

The requested \(v_d\) and \(v_q\) cannot exceed the voltage that the inverter can generate from the available DC-link voltage. A voltage-vector limiter therefore constrains the command magnitude before modulation. When saturation occurs, PI integrators require anti-windup handling to prevent accumulated error from causing delayed recovery or excessive transient response. Voltage limiting becomes especially important as motor speed approaches the available inverter voltage boundary.

Once the rotating-frame voltage commands are determined, the inverse Park transform converts them back into stationary coordinates. Using the corresponding convention, \(v_\alpha=v_d\cos\theta_e-v_q\sin\theta_e\) and \(v_\beta=v_d\sin\theta_e+v_q\cos\theta_e\). The resulting stationary voltage vector can then be supplied to a modulation algorithm such as Space Vector PWM (SVPWM), which generates three-phase inverter duty cycles.

SVPWM or another modulation stage converts \(v_\alpha\) and \(v_\beta\) into duty ratios for the U, V, and W inverter legs. PWM timers then control the high-side and low-side switching devices while enforcing complementary switching and dead time. Current ADC triggering should be synchronized with these PWM timers so that sensing, transformation, control computation, and actuator update operate as one deterministic real-time sequence.

A typical fast FOC cycle can therefore be represented conceptually as current sampling, offset correction, Clarke transform, rotor-angle acquisition, Park transform, d-q current error calculation, PI regulation, decoupling, voltage limiting, inverse Park transform, modulation, and PWM update. The entire sequence must complete within the assigned control period, with bounded execution time and sufficiently low timing jitter to preserve current-loop stability.

The implementation should separate the high-frequency FOC interrupt from slower supervisory software. The fast interrupt performs ADC acquisition, coordinate transformations, current regulation, voltage limiting, and PWM generation. Lower-frequency tasks can execute velocity control, thermal derating, command processing, diagnostics, parameter management, communication, and logging. This multi-rate architecture prevents noncritical operations from disturbing current-control timing.

Numerical implementation requires particular attention on embedded processors. Floating-point MCUs can execute trigonometric and vector operations directly, while fixed-point systems may use lookup tables, coordinate rotation digital computer algorithms, or scaled integer arithmetic. Regardless of representation, angle wrapping, saturation, division protection, scaling consistency, numerical overflow, and execution-time bounds must be explicitly handled in production motor-control software.

Startup and electrical-angle alignment are essential before closed-loop FOC operation begins. The controller may apply a controlled d-axis current to align the rotor with a known stator field, establish the electrical zero offset, and then transition into torque-producing q-axis control. Systems using absolute position sensors may reduce this procedure, but sensor orientation and electrical alignment still require validation before significant torque is commanded.

Field weakening extends operation beyond the nominal base-speed region when the back electromotive force approaches the inverter voltage limit. The controller introduces an appropriate negative d-axis current to reduce effective air-gap flux and preserve voltage margin. This mode requires current and voltage constraints because additional d-axis current consumes part of the inverter and motor current capability that would otherwise be available for torque production.

Protection remains active independently of normal FOC calculations. Excessive phase current, DC-link overvoltage or undervoltage, inverter temperature, motor temperature, position-sensor failure, loss of synchronization, invalid current measurements, control-loop overrun, and gate-driver faults should trigger predefined responses. Critical faults must disable torque generation rapidly, while supervisory logic records diagnostic information and manages controlled recovery where permitted.

The resulting PMSM FOC implementation forms a continuous transformation and control chain from three-phase physical measurements to mathematically decoupled \(dq\) quantities and back to three-phase inverter actuation. Clarke and Park transformations are therefore not isolated mathematical operations but central interfaces connecting sensing, rotor position, current regulation, voltage control, and PWM generation. This architecture provides the foundation for the following SVPWM implementation and advanced robot joint motor-control functions.

03.04 SVPWM Generation Algorithm [w/Code]

Space Vector Pulse Width Modulation (SVPWM) converts a commanded stator voltage vector into three inverter duty cycles for a three-phase motor drive. In a PMSM Field-Oriented Control architecture, it normally receives the stationary-frame voltage references \(v_\alpha\) and \(v_\beta\) produced by the inverse Park transform. The algorithm determines how the inverter switching states should be combined during each PWM period to approximate the requested voltage vector.

A conventional two-level three-phase inverter contains six controlled switches arranged as three complementary legs for phases U, V, and W. Each leg can connect its phase approximately to the positive or negative DC bus, producing eight possible switching combinations. Six combinations generate nonzero active voltage vectors, while two combinations produce zero voltage vectors because all three upper or all three lower switching devices have equivalent states.

The six active vectors are separated by 60 electrical degrees and form a hexagonal space-vector diagram in the stationary \(\alpha\beta\) plane. The requested voltage vector rotates within this plane as the motor electrical angle evolves. SVPWM first identifies which of the six sectors contains the requested vector and then synthesizes that vector using the two adjacent active vectors together with one or both zero vectors during the current PWM period.

If the reference vector lies in sector \(k\), it can be represented over one switching period \(T_s\) by applying adjacent vectors \(V_k\) and \(V_{k+1}\) for durations \(T_1\) and \(T_2\), respectively. The remaining interval is assigned to the zero-vector duration \(T_0\), giving the fundamental timing relation \(T_s=T_1+T_2+T_0\). This time-domain decomposition is the central computational principle of SVPWM.

Sector identification can be implemented from the signs and relative magnitudes of \(v_\alpha\), \(v_\beta\), or from three intermediate phase-like quantities derived from the reference vector. A production implementation should avoid unnecessary inverse trigonometric calculations because only the sector and timing information are required. Sign tests, comparisons, or precomputed relationships generally provide deterministic execution with lower computational cost.

Within a sector, the active-vector times are determined by the magnitude and angular location of the requested voltage vector relative to the neighboring inverter vectors. Conceptually, \(T_1\) and \(T_2\) are proportional to the projections needed to reconstruct the reference vector. Their values must remain nonnegative and satisfy the available PWM-period constraint. Numerical clipping should prevent rounding errors from producing invalid negative or excessive timing values.

The zero-vector interval \(T_0\) is normally distributed symmetrically around the active-vector intervals. A center-aligned sequence may apply part of the zero-vector time, the first active vector, the second active vector, and the remaining zero-vector time before executing the mirrored sequence. Symmetrical switching reduces waveform asymmetry and provides predictable sampling locations for phase-current acquisition.

For example, a conceptual switching sequence in the first sector can progress through \(V_0\), \(V_1\), \(V_2\), \(V_7\), and then return through \(V_2\), \(V_1\), and \(V_0\). Adjacent switching states are selected so that only a limited number of inverter devices change state at each transition. This arrangement reduces unnecessary switching activity while maintaining a symmetrical voltage waveform over the PWM period.

After \(T_1\), \(T_2\), and \(T_0\) are calculated, the algorithm converts these durations into phase duty ratios \(d_u\), \(d_v\), and \(d_w\). The exact equations depend on the identified sector and selected switching sequence. The duty ratios are normalized to the PWM period and then converted into timer compare values used by the MCU PWM peripheral to generate the three inverter-leg commands.

Another practical SVPWM implementation calculates preliminary three-phase voltage references from \(v_\alpha\) and \(v_\beta\) and then injects an appropriate common-mode voltage. The maximum and minimum phase references are identified, and a common offset is added so that all three commands fit efficiently inside the available DC-bus range. This method can generate duty cycles equivalent to classical sector-based SVPWM while reducing explicit sector-dependent calculations.

One major advantage of SVPWM compared with simple sinusoidal PWM is improved utilization of the available DC-link voltage. By appropriately distributing zero-vector time and introducing common-mode voltage, SVPWM can generate a larger fundamental voltage magnitude before entering overmodulation. This additional voltage capability is valuable at higher motor speeds, where back electromotive force consumes an increasing fraction of the available inverter voltage.

The modulation index represents the relationship between the requested voltage magnitude and the voltage capability of the inverter. Within the linear modulation region, duty cycles vary continuously and the commanded fundamental voltage is reproduced predictably. When the requested vector exceeds the linear SVPWM boundary, the algorithm must limit the voltage vector or deliberately enter a defined overmodulation strategy rather than allowing uncontrolled duty-cycle saturation.

Voltage limiting should therefore occur before or as part of SVPWM generation. In a FOC system, the \(v_d\) and \(v_q\) command vector is typically constrained according to the measured DC-link voltage before the inverse Park transform or modulation stage. If saturation occurs, the current-controller integrators require coordinated anti-windup behavior so that unavailable voltage commands do not accumulate and degrade transient recovery.

DC-link voltage measurement is important because the conversion from requested phase voltage to PWM duty ratio depends on the actual supply voltage. Battery-powered robots can experience substantial bus-voltage variation as state of charge, load current, and regenerative operation change. Using a filtered and validated \(V_{dc}\) measurement allows the modulation stage to preserve the intended voltage command despite these operating variations.

PWM timer configuration strongly influences the software implementation. Center-aligned PWM is frequently used because it produces symmetrical switching patterns and offers useful current-sampling points. Timer preload registers allow newly calculated duty values to become active simultaneously at a defined update event. Without synchronized updates, different phases could temporarily use duty values from different control cycles and generate an unintended voltage vector.

Complementary gate signals require dead time between high-side and low-side switching transitions. SVPWM calculates ideal phase duty ratios, while the timer and gate-control layer translates them into physically safe switching signals. Dead time should normally be inserted by dedicated timer hardware. Excessive dead time causes voltage distortion, whereas insufficient dead time increases the risk of shoot-through, so configuration must reflect the actual inverter switching characteristics.

Dead-time distortion becomes more significant at low commanded voltage because the inserted delay represents a larger fraction of the effective pulse width. Its influence also depends on current direction. Advanced motor-control software may estimate this voltage error and apply dead-time compensation to the phase-voltage command or duty cycles. Compensation should be bounded carefully because incorrect current polarity information can otherwise increase distortion rather than reduce it.

Current sampling must be coordinated with the SVPWM switching pattern. Depending on the shunt topology, some switching states provide valid current-measurement windows while others make one or more phase currents difficult to reconstruct. The modulation software can expose timing information to the ADC scheduler so that samples are triggered near stable portions of the PWM cycle and away from switching edges, dead-time intervals, and transient noise.

At very small duty ratios, the available current-sampling window may become shorter than the ADC acquisition and conversion requirements. The software may then enforce minimum pulse widths, shift sampling points, modify the switching sequence, or reconstruct unavailable phase current from the other measurements using \(i_u+i_v+i_w=0\). These constraints make modulation and current sensing tightly coupled in practical FOC implementations.

A deterministic implementation places SVPWM inside the high-frequency motor-control loop. After current acquisition, Clarke and Park transforms, current PI control, voltage limiting, and inverse Park transformation, the SVPWM function receives \(v_\alpha\), \(v_\beta\), and \(V_{dc}\). It calculates the phase duties and writes them to PWM preload registers before the control deadline, allowing hardware to activate all updated values simultaneously.

The SVPWM function should validate all inputs before generating timer commands. Nonfinite voltage values, invalid DC-link measurements, arithmetic overflow, duty ratios outside the permitted range, or execution overruns must not propagate directly to the inverter. Output values should be saturated to defined safe limits, while serious calculation or synchronization failures should request controlled shutdown through the motor-control protection mechanism.

Software optimization is particularly important when many motor axes execute FOC simultaneously. Sector determination, duty calculation, saturation, and timer conversion should use bounded operations with predictable execution time. Floating-point processors can perform these calculations directly, while fixed-point implementations require carefully defined scaling and saturation. Avoiding unnecessary trigonometric functions is beneficial because the inverse Park stage has already produced the required stationary vector components.

Verification should include mathematical, software, and hardware behavior. Unit tests can sweep \(v_\alpha\) and \(v_\beta\) across all six sectors and verify continuity, sector transitions, duty bounds, zero-vector allocation, and voltage saturation. SIL and HIL tests can verify PWM timing, DC-link variation, current-sampling synchronization, dead time, and fault behavior before the modulation software is connected to a high-power inverter and physical PMSM.

SVPWM ultimately forms the actuator-side bridge between the continuous voltage vector calculated by FOC and the discrete switching states available from a three-phase inverter. Its quality depends on correct sector geometry, timing calculation, DC-bus normalization, synchronized timer updates, safe dead-time handling, and coordinated current sampling. A robust implementation therefore treats modulation, sensing, PWM hardware, and protection as one tightly synchronized real-time subsystem.

03.05 Current Sensor Signal Processing and Zero Offset [w/Code]

Current sensing is a fundamental feedback function in motor-control software because measured phase or bus current represents the electrical load applied to the motor and power inverter. Accurate current information is required for torque regulation, FOC current loops, current limiting, fault protection, and diagnostic monitoring. The signal-processing chain must convert noisy analog sensor outputs into deterministic, calibrated current values suitable for high-frequency real-time control.

Motor current can be measured using shunt resistors, Hall-effect sensors, magnetic current sensors, or integrated current-sense amplifiers. Shunt-based systems infer current from the voltage developed across a known resistance, while isolated magnetic sensors measure the magnetic field associated with conductor current. Sensor selection affects measurement bandwidth, isolation, offset behavior, noise, thermal drift, cost, and the software processing required to obtain reliable current feedback.

Shunt measurement architectures commonly use single-shunt, dual-shunt, or three-shunt configurations. A single DC-link shunt reduces hardware cost but requires current reconstruction according to inverter switching states. Two-shunt systems directly measure two phase currents and calculate the third using the balanced-current relationship. Three-shunt systems provide greater measurement availability but require additional analog channels and careful synchronization with PWM switching.

For a balanced three-phase motor, the relationship \(i_a+i_b+i_c\approx0\) allows one phase current to be reconstructed when the other two are known. For example, \(i_c=-(i_a+i_b)\). This relationship is frequently used in PMSM FOC implementations because the Clarke transform requires phase-current information while practical inverter hardware may directly measure only two phases. Reconstruction should be performed only after sensor offset and gain corrections have been applied.

The analog signal normally passes through a current sensor, amplifier, optional analog filter, and ADC before entering software. Raw ADC counts do not directly represent amperes. Software converts them using the ADC reference voltage, resolution, amplifier gain, shunt resistance or sensor sensitivity, and calibrated zero-current offset. A general conversion can be represented as \(I=(ADC_{raw}-ADC_{offset})K_I\), where \(K_I\) is the calibrated current scaling factor.

Zero offset is the sensor output measured when actual motor current is zero. In bipolar current measurement, the analog circuit often biases zero current near the midpoint of the ADC input range so that positive and negative currents can both be represented by a unipolar ADC. Component tolerances, amplifier input offset, sensor characteristics, ADC error, temperature, and supply variation cause the actual zero-current value to differ from its theoretical midpoint.

Offset error directly appears as false current feedback. In FOC, even a small persistent phase-current offset can create incorrect \(i_d\) and \(i_q\) values after Clarke and Park transformation, producing unwanted torque, flux error, current-controller bias, acoustic noise, and additional heating. Offset calibration is therefore part of the functional control path rather than merely a measurement-quality improvement.

Startup zero-offset calibration should be performed while the inverter is guaranteed not to produce motor current. PWM outputs are disabled or the power stage is placed in a defined nonconducting state, after which multiple ADC samples are collected for each current channel. The arithmetic mean of these samples provides an initial offset estimate. Averaging many samples suppresses random ADC and analog noise and improves the repeatability of the zero-current estimate.

The calibration procedure should reject invalid operating conditions before accepting an offset. Bus voltage should be within an expected range, gate-driver status should be valid, and no braking or regenerative current should be present. The measured samples should also remain within a reasonable window around the expected sensor midpoint. Excessive deviation or variation may indicate damaged sensing hardware, incorrect ADC configuration, unstable supply voltage, or unintended current flow.

Statistical validation improves calibration robustness. In addition to the average offset, software can calculate the minimum, maximum, range, or variance of the collected samples. A large spread indicates excessive noise or an unstable measurement condition. Calibration should fail rather than storing an unreliable offset when the observed variation exceeds a defined threshold. The motor controller can then remain disabled and report a current-sensor calibration fault.

Once calibration is complete, every runtime current sample is corrected by subtracting its corresponding zero offset. The corrected ADC value is then multiplied by the channel scaling factor and converted into physical current units. Channel-specific calibration is important because amplifier gain, shunt resistance, PCB routing, and ADC characteristics can differ slightly between phases. Using one common offset for all channels can therefore introduce systematic phase-current imbalance.

Gain calibration compensates for errors in the conversion from corrected ADC counts to amperes. A known reference current can be applied during production or service calibration, and the measured response can be compared with an accurate external reference. The resulting gain correction coefficient is stored as calibration data. For higher accuracy, software may support both offset and gain coefficients independently for every current-sensing channel.

Current measurements contain high-frequency switching noise generated by the inverter, gate transitions, diode recovery, common-mode coupling, and PCB parasitics. Filtering can reduce this noise, but excessive digital filtering introduces phase delay into the current-control loop. Because FOC current regulation operates at high bandwidth, the preferred strategy is usually to obtain clean samples through proper hardware design and synchronized sampling, then apply only limited software filtering where necessary.

ADC sampling should be synchronized with PWM generation. Sampling near switching edges can capture transient spikes rather than representative winding current. Center-aligned PWM commonly provides predictable regions where current is relatively stable. A timer event can trigger the ADC automatically at a selected point within the PWM cycle, reducing software jitter and maintaining a consistent relationship between current measurement and the voltage vector applied by the inverter.

SVPWM makes current-sampling timing more complex because valid measurement windows depend on sector, duty cycle, and shunt topology. At very high or very low duty ratios, some active-vector intervals may be too short for amplifier settling and ADC conversion. The software may shift the sampling instant, enforce a minimum pulse width, select another measurable interval, or reconstruct the unavailable phase current from the remaining valid measurements.

ADC acquisition latency must also be considered. The trigger event, sample-and-hold time, conversion time, DMA transfer, interrupt latency, and control computation collectively determine the effective age of the current measurement used by the controller. A deterministic FOC implementation maintains this delay as consistently as possible. Excessive or variable measurement latency introduces phase error and can reduce current-loop stability at high control bandwidth.

Signal plausibility checking should execute before current values are accepted by the control algorithm. Raw ADC values must remain inside valid electrical ranges, corrected currents should remain within physically possible limits, and reconstructed phase currents should satisfy expected relationships. Sudden discontinuities or a channel permanently stuck near zero, full scale, or the bias voltage can indicate open circuits, short circuits, amplifier saturation, or ADC failures.

Software overcurrent detection complements dedicated hardware protection. A filtered or instantaneous current value can be compared against configurable warning and shutdown thresholds. Moderate current excursions may trigger torque limiting or derating, while severe current levels should disable PWM immediately. Hardware comparators or gate-driver protection remain preferable for destructive short-circuit events because software and ADC latency may be too slow to protect the power devices.

Offset changes with temperature and operating time because sensor electronics, amplifiers, ADC references, and shunt-related circuitry are not perfectly stable. Systems requiring high accuracy may therefore support controlled offset tracking. Offset adaptation must occur only when the controller can confidently determine that actual current should be zero. Updating the offset while real motor current is flowing would incorrectly absorb physical current into the calibration value.

A safe runtime offset-tracking strategy can use periods when PWM is disabled and the motor is electrically inactive. New zero-current samples can be combined slowly with the stored estimate using a bounded low-pass update. The software should limit the maximum allowed offset change and record excessive drift as a diagnostic event. This approach compensates for gradual thermal drift without allowing rapid or abnormal sensor behavior to corrupt calibration.

Calibration parameters should be managed as traceable data. Offset values, gain coefficients, sensor type, ADC configuration, calibration temperature, software version, and validity information can be stored in nonvolatile memory where appropriate. Startup software must validate stored data using range checks, version compatibility, and integrity mechanisms before applying it. Invalid calibration data should never silently enter a torque-control loop.

The fast current-processing path should remain compact and deterministic. A typical sequence is PWM-triggered ADC acquisition, raw-value validation, zero-offset subtraction, gain scaling, optional filtering, phase-current reconstruction, plausibility checking, and delivery to the Clarke transform or protection logic. Operations should use bounded arithmetic and explicit saturation so that numerical overflow or invalid sensor values cannot propagate into FOC calculations.

Testing should cover the entire measurement chain from analog input to software current value. Unit tests can verify offset subtraction, scaling, saturation, reconstruction, and fault thresholds. SIL and HIL environments can inject controlled offsets, noise, sensor saturation, missing channels, and PWM-dependent sampling conditions. Hardware tests should compare software-reported current against calibrated measurement equipment across positive and negative current, temperature, and operating voltage ranges.

Current-sensor signal processing ultimately defines the quality of the electrical feedback available to the motor controller. Accurate zero-offset estimation, synchronized ADC sampling, channel-specific scaling, current reconstruction, bounded filtering, drift management, and fault detection are therefore essential parts of reliable motor-control software. These processed measurements provide the trustworthy phase-current information required by FOC, torque estimation, protection, and subsequent multi-axis robot control functions.

03.06 Encoder Signal Processing: Incremental / Absolute [w/Code]

Encoder signal processing provides the motor-control software with rotor position, rotational direction, speed, and motion information required for closed-loop control. Encoders are broadly classified as incremental or absolute devices. Incremental encoders report relative movement through pulse transitions, whereas absolute encoders provide a coded position value associated with a defined mechanical angle. The software architecture must convert either signal type into reliable, time-consistent motor states.

Encoder processing normally belongs to the sensing and estimation layer between hardware interfaces and motor-control algorithms. Raw signals are acquired through timer capture units, quadrature decoder peripherals, SPI, SSI, BiSS, or other communication interfaces. The software validates these measurements, applies scaling and direction conventions, handles counter rollover, estimates velocity, and provides normalized position information to position, velocity, and FOC control loops.

An incremental encoder commonly generates two periodic digital signals called channel A and channel B. These signals are displaced by approximately 90 electrical degrees, creating a quadrature relationship that allows both movement and direction to be determined. When A leads B, the software interprets rotation as one direction, while B leading A represents the opposite direction. The actual direction convention must remain consistent with the motor and coordinate-system definitions.

Quadrature decoding can evaluate one, two, or all four edges of the A and B signals. In x4 decoding, every rising and falling transition contributes to the position count, providing four count events per encoder pulse cycle. If an encoder specifies \(N\) pulses per revolution, the effective count resolution may therefore become \(4N\) counts per revolution, depending on the manufacturer\'s resolution definition and the selected decoding configuration.

Hardware timer peripherals are generally preferable to software GPIO polling for high-speed incremental encoders. A timer configured in encoder mode can automatically increment or decrement a counter according to A/B transitions without requiring an interrupt for every edge. Software periodically reads the counter and converts it into position. This reduces processor load and avoids lost counts that could occur when edge frequency exceeds software interrupt-processing capability.

Incremental encoders may also provide an index signal, commonly called Z or I, that occurs once per mechanical revolution. The index establishes a repeatable angular reference but does not by itself provide absolute position immediately after power-up. Software can use the index during a homing or calibration sequence to establish a known count reference, verify accumulated counts, or synchronize the mechanical position with the motor electrical-angle model.

Position calculation begins by converting encoder counts into mechanical angle. If the effective resolution is \(N_c\) counts per revolution, a normalized shaft angle can be expressed as \(\theta_m=2\pi(C \bmod N_c)/N_c\). Multi-turn position is obtained by preserving accumulated counts beyond a single revolution. Gear ratio, encoder mounting location, and joint transmission geometry must be included when converting motor-shaft position into robot-joint position.

Counter rollover requires explicit handling when a finite-width hardware counter is used. For example, a 16-bit timer wraps from its maximum value to zero and vice versa. Simply subtracting consecutive raw counter values can therefore create an apparent large position jump. Software should calculate the signed modular difference between samples and accumulate that difference into a wider software position variable, preserving continuous motion across hardware counter boundaries.

Velocity can be estimated by measuring position change over a known sampling interval. The basic relation is \(\omega=\Delta\theta/\Delta t\). This method performs well at moderate and high speed because many encoder counts occur within each estimation interval. At very low speed, however, the small number of count transitions produces quantization and a staircase-like velocity estimate, requiring another estimation method or appropriate filtering.

Period-based velocity estimation measures the elapsed time between encoder edges rather than counting edges during a fixed interval. This approach provides higher resolution at low speed because the measured interval changes continuously even when pulses are sparse. A practical encoder module may combine count-based estimation at high speed with period-based estimation at low speed, using hysteresis or blending to avoid discontinuities when switching between methods.

Velocity filtering must balance measurement noise against control-loop delay. A low-pass filter can suppress quantization and edge-timing noise, but excessive filtering reduces phase margin and slows the velocity controller response. Filter coefficients should therefore be selected according to encoder resolution, control-loop frequency, expected motor speed, and mechanical dynamics. Position feedback generally requires less filtering because unnecessary smoothing introduces direct tracking error.

Absolute encoders provide a coded rotor or shaft position without requiring pulse accumulation from an unknown startup state. Single-turn absolute encoders identify angular position within one revolution, while multi-turn devices additionally retain or determine the number of completed revolutions. This capability is particularly valuable for robot joints where the controller must know mechanical configuration immediately after power-up without performing a large homing movement.

Absolute encoder interfaces can use parallel data, SPI, SSI, BiSS, CAN-based communication, or manufacturer-specific protocols. Unlike incremental edge counting, these interfaces normally deliver a complete position word during each transaction. The software must manage communication timing, frame format, bit ordering, resolution, status fields, parity or CRC verification, timeout detection, and conversion of the received code into the internal position representation.

A raw absolute position word is scaled according to encoder resolution. For an \(n\)-bit single-turn encoder, the nominal range contains \(2^n\) angular states, and the mechanical angle can be calculated from the decoded position value. Software should normalize the result to the selected range, such as \(0\) to \(2\pi\) or \(-\pi\) to \(+\pi\), while preserving a separate continuous representation when multi-turn motion or trajectory tracking requires it.

Absolute position does not automatically mean that the encoder coordinate system matches the motor or robot coordinate system. Mechanical installation can introduce an angular offset, reversed direction, or gear-related transformation. Calibration therefore establishes a relation such as \(\theta_{joint}=s(\theta_{encoder}-\theta_{offset})/G\), where \(s\) represents the direction convention and \(G\) represents the relevant transmission ratio.

For PMSM FOC, the mechanical encoder position must be converted into rotor electrical angle. The electrical angle is related to mechanical angle by \(\theta_e=p\theta_m+\theta_{elec\_offset}\), where \(p\) is the motor pole-pair count. Accurate electrical offset calibration is essential because an angular error rotates the measured current vector into an incorrect dq frame and reduces the intended separation between flux-producing and torque-producing current.

Encoder sampling must be synchronized appropriately with the control architecture. The position used for FOC should correspond as closely as possible to the time at which phase currents are sampled. If position data are delayed by communication, filtering, or computation, the rotor can rotate significantly before the value is used. High-speed systems may compensate for known latency by extrapolating the measured angle using estimated rotor velocity.

Incremental and absolute encoder signals require different fault-detection strategies. Incremental processing can detect illegal A/B transitions, unexpected direction changes, missing edges, index inconsistency, excessive count rate, or motion that disagrees with commanded torque. Absolute interfaces can detect CRC errors, parity faults, communication timeout, invalid status bits, implausible position jumps, repeated stale values, or disagreement between position and estimated velocity.

Signal integrity is especially important because motor inverters generate substantial electromagnetic interference. Incremental encoder lines may require differential signaling, shielding, hardware input filtering, or digital glitch rejection. Software filtering should reject pulses shorter than physically plausible encoder transitions without suppressing valid high-speed edges. Communication-based absolute encoders similarly require robust timeout and integrity checking rather than assuming every received frame is valid.

Position plausibility can be evaluated using physical limits and temporal consistency. The change between consecutive samples should correspond to a velocity that the motor and mechanism can physically achieve. Estimated acceleration can provide another validation layer. In a robot joint, software can additionally compare encoder position against configured mechanical travel limits and detect movement beyond the expected operating region before it becomes a larger system-level fault.

Redundant sensing may combine incremental and absolute measurements or use two independent position sensors. The absolute encoder can provide startup reference and long-term position integrity, while the incremental channel can provide low-latency high-resolution motion information. Software can compare the two measurements after transforming them into the same coordinate system. Persistent disagreement beyond a defined tolerance indicates a sensor, coupling, calibration, or mechanical problem.

The encoder module should expose normalized information rather than raw hardware details to higher-level controllers. Typical outputs include mechanical position, electrical angle, continuous multi-turn position, velocity, direction, validity state, timestamp, and diagnostic flags. Position, velocity, and FOC algorithms can then consume a consistent interface regardless of whether the underlying sensor is an incremental quadrature encoder or a serial absolute encoder.

A deterministic processing sequence can be represented as signal acquisition, integrity validation, count or frame decoding, rollover handling, offset and direction correction, mechanical-angle calculation, velocity estimation, electrical-angle conversion, plausibility checking, and publication to the control loop. Fast operations should use bounded execution paths, while communication management, calibration storage, statistics, and extended diagnostics can execute in lower-priority tasks.

Testing should cover normal motion as well as boundary and fault conditions. Incremental encoder tests should verify forward and reverse counting, rollover, index behavior, missing or illegal transitions, low-speed estimation, and maximum edge frequency. Absolute encoder tests should verify scaling, wraparound, CRC or parity errors, communication loss, stale data, offset calibration, and multi-turn behavior. HIL testing can inject controlled encoder faults while the motor-control software remains operational.

Reliable encoder processing ultimately converts hardware-dependent position signals into trustworthy motion states for the entire motor-control hierarchy. Incremental encoders emphasize deterministic edge counting, rollover management, referencing, and velocity estimation, while absolute encoders emphasize frame integrity, position decoding, latency, and calibration. A unified software interface allows both technologies to support position control, speed regulation, PMSM FOC, diagnostics, and multi-axis robot coordination.

03.07 Motor Overcurrent / Overtemp Protection SW [w/Code]

Motor overcurrent and overtemperature protection software prevents electrical and thermal operating conditions from exceeding the safe capability of the motor, inverter, wiring, and power source. Protection must operate independently enough to override normal torque or speed commands whenever required. A robust architecture combines fast hardware protection, high-frequency software monitoring, thermal supervision, controlled derating, fault-state management, diagnostics, and recovery logic.

Overcurrent protection must distinguish between normal transient current, sustained overload, and destructive short-circuit current. Motor acceleration and sudden load changes can legitimately produce currents above the continuous rating for short periods, while semiconductor short circuits may require shutdown within microseconds. Software therefore uses multiple protection levels and time scales instead of treating every current threshold crossing as an identical fault condition.

Current information may originate from phase-current sensors, DC-link shunts, Hall-effect sensors, or gate-driver current monitoring. Before protection logic uses these values, the measurement chain should apply zero-offset correction, gain scaling, range validation, and synchronized sampling. Protection thresholds must correspond to calibrated physical current values so that ADC offsets, sensor tolerances, or conversion errors do not significantly alter the intended safety limits.

A typical current-protection architecture includes warning, limiting, shutdown, and hardware-trip thresholds. A moderate overload can request torque reduction, while a higher sustained current can initiate controlled stopping. A severe overcurrent condition should immediately disable PWM or activate the inverter shutdown path. The fastest destructive-current protection is normally implemented by hardware comparators or intelligent gate drivers because software execution and ADC conversion may be too slow.

Software current limiting can operate continuously inside the motor-control loop. When measured current approaches the configured operating limit, the controller constrains the torque-producing current reference, PWM command, or output of the velocity controller. In PMSM FOC, the magnitude of the d-q current vector can be limited according to the motor and inverter capability. This allows normal closed-loop control to continue without repeatedly entering a hard fault state.

Current-vector limiting should consider the combined magnitude rather than independently clipping each axis when appropriate. The relationship \(I_s=\sqrt{i_d^2+i_q^2}\) represents the stator current magnitude in the rotating reference frame. If \(I_s\) exceeds the permitted value, the current references can be scaled while preserving the desired vector direction. Field-weakening operation requires additional consideration because negative d-axis current consumes part of the available current capability.

Time-dependent overload protection can represent the fact that motors and inverters tolerate elevated current for limited durations. Software can integrate an overload quantity or use an \(I^2t\)-type model in which heating stress increases approximately with the square of current. Short current peaks may therefore be accepted, while repeated or sustained overload accumulates thermal stress and eventually causes derating or shutdown even if the instantaneous hard-trip threshold is never reached.

Motor stall detection complements overcurrent protection. A stalled motor may draw substantial current while producing little or no mechanical motion, causing rapid winding heating. Software can compare commanded torque or PWM, measured current, and encoder velocity over a defined time interval. High current combined with near-zero speed for longer than an allowed duration can be classified as a stall condition and trigger torque reduction or shutdown.

Temperature protection normally monitors several possible thermal locations, including motor windings or housing, inverter MOSFET or IGBT modules, gate-driver region, PCB, and ambient environment. Sensors may include NTC thermistors, PTC devices, semiconductor temperature sensors, or digital sensors. Each measurement channel requires conversion, plausibility checking, filtering, and sensor-specific calibration before it is used by the protection state machine.

Thermistor processing typically converts ADC voltage into resistance and then resistance into temperature using a lookup table, interpolation, the Beta equation, or a Steinhart-Hart model. Because temperature changes much more slowly than electrical current, thermal measurements can be processed at a lower task frequency. Filtering can also be stronger than in the current-control loop, provided genuine overheating conditions are still detected with adequate response time.

Direct motor temperature measurement may not accurately represent the hottest internal winding temperature because sensors are often mounted on the housing or stator structure. Software can therefore combine measured temperature with a thermal model that estimates internal temperature from current, operating time, speed, cooling conditions, and motor thermal parameters. The estimated winding temperature provides an additional protection variable when direct sensing of the thermal hotspot is impractical.

Thermal protection should preferably begin with derating before reaching the shutdown temperature. When temperature exceeds a warning threshold, the software gradually reduces the allowable torque or current command. A continuous derating function avoids abrupt changes in actuator behavior and allows the robot to continue operating at reduced performance. If temperature continues rising and reaches the shutdown threshold, torque generation must be disabled according to the defined safety strategy.

Separate temperature thresholds should normally include hysteresis. Without hysteresis, a measured temperature fluctuating around one threshold could repeatedly enable and disable the motor. For example, shutdown may occur at a high temperature while restart is prohibited until the motor or inverter cools below a significantly lower recovery threshold. Minimum cooldown time can also be applied to prevent rapid cycling when thermal inertia remains substantial.

Sensor fault detection is essential because an invalid temperature measurement must not be interpreted as a safe low temperature. Open-circuit or short-circuit thermistors often produce ADC values near electrical limits, while digital sensors can report communication or CRC errors. Software should identify out-of-range, implausible, frozen, or rapidly changing temperature values and apply a defined fail-safe response according to the importance of the affected sensor.

Protection logic should be organized by fault severity and reaction time. Warning conditions may only set diagnostic flags, while derating conditions modify allowable torque or current. Recoverable faults may request controlled stopping and require specific recovery conditions. Critical faults such as severe overcurrent, gate-driver failure, or extreme inverter temperature should transition directly to a safe state and inhibit PWM regardless of the normal controller output.

A dedicated protection state machine can coordinate transitions among normal operation, warning, derating, controlled stop, fault shutdown, cooldown, and recovery. Separating these states from the normal motion-control state machine makes protection behavior explicit and testable. Every transition should have defined entry conditions, exit conditions, timing requirements, output restrictions, and diagnostic consequences so that fault behavior remains deterministic.

Protection priority is important when several conditions occur simultaneously. A controlled thermal derating request must not delay a severe hardware overcurrent trip, and a normal stop command must not re-enable outputs after a critical fault. The final motor-enable and PWM-enable decisions should therefore pass through a centralized safety arbitration layer where the highest-severity active condition determines the permitted actuator state.

Hardware and software protection should cooperate rather than duplicate identical functions. Hardware comparators, gate-driver desaturation detection, or overcurrent inputs provide extremely fast shutdown for destructive electrical events. Software provides calibrated thresholds, temporal filtering, overload accumulation, derating, diagnostics, and system-level coordination. After a hardware trip, software should capture the event, maintain the safe state, and determine whether recovery is permitted.

Fault latching prevents dangerous conditions from disappearing from the controller merely because a measurement temporarily returns to normal. Critical faults can remain latched until PWM is disabled, the underlying condition is cleared, a defined cooldown or waiting period has elapsed, and an explicit reset request is accepted. Less severe warnings may clear automatically after hysteresis and validation conditions are satisfied.

Recovery logic must prevent immediate restart into the same fault condition. Before enabling the inverter again, software should verify acceptable bus voltage, current-sensor validity, safe temperatures, gate-driver status, encoder or rotor-position validity where required, and absence of active shutdown requests. Torque references and controller integrators should also be reset or initialized appropriately to prevent an abrupt command when PWM resumes.

Diagnostics should capture the context surrounding a protection event. Useful information includes fault type, timestamp, motor state, commanded torque, measured phase currents, current limit, motor and inverter temperatures, DC-link voltage, speed, PWM duty, and active derating level. Recording peak current, maximum temperature, accumulated overload, fault count, and previous recovery attempts supports debugging, maintenance, and reliability analysis.

Protection parameters should be stored as controlled configuration data rather than scattered constants throughout the source code. Continuous-current limits, peak-current limits, overload durations, warning temperatures, derating slopes, shutdown temperatures, recovery thresholds, hysteresis values, and sensor-validity ranges should be traceable to motor, inverter, and system requirements. Startup validation should reject incompatible or corrupted parameter sets.

The protection software must execute with deterministic timing. Fast current checks belong in the PWM or FOC control path, while thermal processing and long-duration overload models can execute in slower periodic tasks. Critical fault signals may enter through high-priority interrupts. Communication, logging, or user-interface activity must never block the execution of protection functions or delay a required PWM shutdown.

Verification should include threshold boundaries, timing behavior, sensor failures, and combined faults. SIL and HIL tests can inject current ramps, short overload pulses, sustained overload, stalled-rotor conditions, temperature ramps, sensor open circuits, communication failures, and simultaneous electrical and thermal faults. Hardware testing should verify that the complete path from physical fault detection to gate disable satisfies the required response time.

Motor overcurrent and overtemperature protection software ultimately forms a supervisory safety boundary around the normal motor-control algorithms. Current limiting and thermal derating preserve operation when possible, while fast shutdown prevents dangerous electrical or thermal stress when necessary. Coordinating calibrated sensing, hardware trips, software thresholds, state management, diagnostics, and controlled recovery provides the robust protection foundation required for reliable single-axis and multi-axis robot actuators.

03.08 Torque Estimation and Force Control [w/Code]

Torque estimation converts electrical and mechanical measurements into an estimate of the torque generated by a motor or transmitted through a robot joint. Force control extends this information to interaction with the environment, allowing a robot to regulate contact force rather than only position or velocity. Together, torque estimation and force control provide the foundation for compliant manipulation, safe human interaction, assembly, gripping, walking, and disturbance rejection.

In a PMSM controlled by field-oriented control, electromagnetic torque can be estimated directly from the d-q current components and motor parameters. A general expression is \(T_e=\frac{3}{2}p[\lambda_m i_q+(L_d-L_q)i_di_q]\), where \(p\) is the pole-pair count, \(\lambda_m\) is permanent-magnet flux linkage, and \(L_d\) and \(L_q\) are d- and q-axis inductances. This model connects measured motor current to generated electromagnetic torque.

For a surface-mounted PMSM, \(L_d\) and \(L_q\) are approximately equal, so the reluctance-torque term becomes small. The torque equation can then be simplified to \(T_e\approx K_t i_q\), where \(K_t\) is the effective torque constant. This relationship makes q-axis current particularly useful for real-time torque estimation because the current is already available inside the FOC loop and requires little additional computation.

Current-based torque estimation depends strongly on accurate current sensing and motor parameters. Zero-offset error, gain error, inverter nonlinearity, magnetic saturation, temperature-dependent resistance, and uncertainty in the torque constant can introduce systematic estimation errors. The software should therefore use calibrated phase-current measurements and parameter sets corresponding to the actual motor, inverter, and operating temperature whenever higher torque accuracy is required.

The electromagnetic torque estimated from motor current is not necessarily equal to the torque available at the robot joint. Transmission ratio, gearbox efficiency, bearing friction, seal friction, belt or harmonic-drive losses, and drivetrain elasticity affect the relationship. A simplified joint estimate can be written as \(T_j\approx \eta G T_m-T_f\), where \(G\) is the transmission ratio, \(\eta\) is efficiency, and \(T_f\) represents friction-related torque.

Friction compensation improves torque estimation at low velocity, where Coulomb friction and stiction may represent a significant fraction of actuator torque. A practical model can combine Coulomb friction, viscous friction, and a smooth transition around zero velocity. Because abrupt sign functions can create discontinuities, software often uses a continuous approximation so that compensation remains numerically stable when the joint repeatedly crosses zero speed.

Dynamic torque estimation can additionally account for rotor and drivetrain inertia. The motor torque is divided among load torque, friction torque, and acceleration torque, giving a conceptual relation such as \(T_{load}=T_m-J\dot{\omega}-T_f\). Reliable acceleration estimation is therefore important, but numerical differentiation of encoder velocity amplifies noise. Filtering or observer-based estimation is commonly required before acceleration is used in the torque model.

Direct torque sensors provide an alternative to model-based estimation. Strain-gauge torque sensors, magnetoelastic sensors, series elastic actuator deflection measurements, or integrated joint torque sensors can measure transmitted torque more directly. Their software interfaces require offset calibration, gain scaling, filtering, temperature compensation, plausibility checking, saturation detection, and communication diagnostics similar to other precision feedback sensors.

A series elastic actuator estimates force or torque from the deformation of a known elastic element. If the spring stiffness is \(K_s\) and measured deformation is \(\Delta\theta\), joint torque can be approximated as \(T_j=K_s\Delta\theta\). The difference between motor-side and load-side position measurements provides the deformation signal. Accurate stiffness characterization and synchronized position sensing are essential for reliable estimation.

Torque estimates from multiple sources can be combined when available. Current-based motor torque provides fast internal information, while a joint torque sensor measures transmitted load more directly. Comparing the two can identify friction changes, mechanical binding, unexpected contact, sensor faults, or transmission damage. Sensor fusion or observer techniques can provide a more robust estimate than relying on a single measurement channel.

Joint torque is converted into Cartesian force through robot kinematics. The fundamental static relationship is \(\tau=J^T F\), where \(\tau\) is the vector of joint torques, \(J\) is the manipulator Jacobian, and \(F\) represents Cartesian force and moment at the end effector. Estimating external force from joint torque therefore requires the current robot configuration and an appropriate Jacobian transformation.

Force estimation must separate external interaction from torques caused by the robot itself. Gravity, link inertia, Coriolis and centrifugal effects, friction, and payload generate joint torques even without environmental contact. A model-based estimator can calculate these internal contributions and subtract them from measured or estimated joint torque. The remaining residual torque can then be interpreted as an indication of external contact or disturbance.

A six-axis force/torque sensor mounted near the wrist provides direct measurement of end-effector forces and moments. Software processing typically includes bias removal, coordinate transformation, gravity and tool-weight compensation, filtering, overload detection, and sensor-status validation. The measured wrench must be transformed from the sensor coordinate frame into the tool, base, or task frame required by the force-control algorithm.

Force control changes the actuator objective from following only a geometric trajectory to regulating physical interaction. The controller compares desired force \(F^*\) with measured or estimated force \(F\), producing the error \(e_F=F^*-F\). A force controller can then generate a position correction, velocity command, torque command, or joint-current reference depending on the robot architecture and the bandwidth of the inner actuator loops.

Direct force control commands actuator torque from the force error, typically through inner current or torque loops. This structure can achieve relatively high interaction bandwidth when the actuator and force sensor are sufficiently responsive. However, contact stiffness, communication delay, filtering, drivetrain elasticity, and sampling frequency strongly influence stability. Controller gains must therefore be selected for the expected environment and mechanical structure.

Impedance control regulates the dynamic relationship between motion and interaction force rather than enforcing force alone. A desired behavior can be represented conceptually by \(M_d\ddot{x}+D_d\dot{x}+K_d(x-x_d)=F_{ext}\). The parameters define virtual inertia, damping, and stiffness, allowing the robot to behave like a programmable mechanical system. Lower virtual stiffness produces more compliant interaction with uncertain environments.

Admittance control performs the complementary transformation by converting measured external force into commanded motion. It is particularly useful for robots with stiff position-controlled actuators because an outer admittance loop can generate position or velocity references for the existing servo system. The virtual mass, damping, and stiffness determine how the commanded motion responds to applied force and must be selected to maintain stable contact.

Hybrid position/force control assigns different control objectives to different Cartesian directions. A robot can regulate position along a surface while controlling contact force normal to that surface. Selection matrices or task-space projections separate the controlled directions so that position and force loops do not compete for the same degree of freedom. This approach is useful for polishing, grinding, inspection, insertion, and surface-following tasks.

Contact detection is an important transition mechanism between free-space motion and force-controlled operation. Software can monitor force, torque residuals, motor current, velocity deviation, or combinations of these signals. When the measured interaction exceeds a validated threshold for a defined duration, the controller can transition from approach mode to contact mode while reducing velocity and initializing force-control states to avoid an abrupt force transient.

Force and torque signals normally require filtering, but excessive filtering introduces delay that can destabilize contact control. The filter bandwidth should therefore remain compatible with the force-control bandwidth and mechanical resonance characteristics. Notch filters may suppress known structural resonances, while low-pass filtering can reduce sensor noise. Timestamp alignment is important when torque, position, velocity, and force measurements originate from different devices.

Command limiting remains necessary during force control. Desired force, torque, current, velocity, position correction, and rate of change should remain within actuator and mechanism limits. Anti-windup should be applied when force-controller outputs saturate. A separate safety layer must retain authority to override the force controller when overcurrent, overtemperature, excessive contact force, joint-limit violation, communication loss, or sensor failure occurs.

Multi-axis robots require coordinated torque and force processing across joints. Joint torque measurements must correspond to a common time base before they are transformed through the Jacobian. Delayed measurements from one axis can distort the reconstructed Cartesian wrench, especially during rapid motion. Deterministic communication, synchronized sampling, timestamping, and interpolation therefore become increasingly important as the number of controlled axes grows.

Diagnostics should record desired and estimated torque, measured current, force references, measured wrench, joint position and velocity, controller saturation, contact state, and safety-limit activation. Comparing these signals helps distinguish controller tuning problems from mechanical friction, sensor drift, unexpected payload, or environmental changes. Long-term trends can also reveal increasing gearbox friction or deterioration of an elastic transmission element.

Verification should progress from mathematical models to controlled physical contact. Unit tests can validate torque equations, coordinate transformations, Jacobian operations, saturation, and calibration. SIL and HIL environments can inject friction, payload changes, sensor offsets, contact stiffness, delays, and communication faults. Hardware testing should then verify torque accuracy, force tracking, contact transitions, stability, overload behavior, and safe release from contact.

Torque estimation and force control ultimately connect low-level motor current regulation with robot-level physical interaction. Calibrated current sensing and motor models provide electromagnetic torque, drivetrain models or torque sensors provide joint torque, and robot kinematics transform joint information into Cartesian force. Combined with impedance, admittance, hybrid control, synchronized sensing, protection, and diagnostics, this architecture enables robots to interact with their environment accurately, compliantly, and safely.

03.09 Multi-Axis Motor Control Synchronization [w/Code]

Multi-axis motor control synchronization coordinates multiple actuators so that their position, velocity, torque, and timing relationships remain consistent during robot motion. Each motor may have an independent high-bandwidth servo loop, but robot-level motion depends on all axes executing coordinated references at the intended instant. Synchronization therefore connects individual motor controllers with trajectory generation, communication, shared timing, safety supervision, and system-level motion control.

A typical architecture separates centralized coordination from distributed axis control. A robot controller or motion coordinator generates synchronized trajectories for all joints, while individual motor-control nodes execute local position, velocity, torque, current, or FOC loops. This separation allows fast electrical control to remain close to the inverter while slower kinematic and trajectory calculations operate at the robot-controller level without compromising local control-loop determinism.

Synchronization begins with a common definition of time. If each motor controller uses an independent oscillator, clock drift gradually causes sampling and command execution to occur at different instants. Distributed systems therefore require clock synchronization or periodic time correction. Industrial Ethernet, EtherCAT distributed clocks, IEEE 1588 PTP, or dedicated synchronization signals can establish a shared time base with accuracy appropriate to the required motion performance.

A common time base does not automatically guarantee simultaneous control execution. Software must also align task activation, ADC sampling, encoder acquisition, control calculations, and PWM updates. A synchronized trigger can cause each axis to capture feedback at nearly the same physical instant, after which controllers compute their outputs and apply new PWM values at a defined update boundary. This reduces temporal skew between measured and commanded joint states.

Control-loop periods should be selected according to the dynamics of each layer. Current and FOC loops may execute at tens of kilohertz, velocity loops at lower rates, and position or trajectory loops at still lower frequencies. In a multi-axis system, axes participating in the same coordinated motion should normally use compatible servo-cycle timing. Integer relationships between loop periods simplify scheduling, data exchange, and deterministic synchronization across layers.

Trajectory synchronization ensures that joints with different travel distances begin and complete coordinated segments according to the same motion plan. The trajectory generator calculates position, velocity, and acceleration references as functions of a shared trajectory time. Rather than commanding each motor to reach its target independently, the system scales axis motion so that all participating joints follow the temporal relationship required by the robot path.

Interpolation is essential when the central trajectory update rate is slower than the local servo rate. A motion coordinator may transmit reference points every millisecond while local motor loops execute many times within that interval. Each axis can interpolate position, velocity, or torque references between received points using linear, polynomial, spline, or higher-order trajectory representations. This prevents staircase commands and preserves smooth synchronized motion.

Reference data should normally include timing information rather than relying only on packet arrival time. A command can contain a sequence number, generation timestamp, and intended execution time. Each motor node buffers the command and applies it when the synchronized local clock reaches the specified instant. Time-triggered execution reduces the effect of variable communication latency and allows multiple axes to act simultaneously even when packets arrive at slightly different times.

Communication jitter directly affects synchronization if commands are executed immediately upon reception. Variable network delay can create axis-to-axis phase error, which becomes visible as contour error, vibration, or mechanical stress during fast motion. Deterministic buses, scheduled communication, buffering, and timestamp-based execution reduce this sensitivity. The acceptable jitter should be derived from servo bandwidth, maximum velocity, mechanism stiffness, and required path accuracy.

Feedback synchronization is as important as command synchronization. Joint positions measured at different times do not represent one physically consistent robot configuration during motion. Encoder values should therefore be sampled simultaneously or accompanied by precise timestamps. The robot controller can then use time-aligned measurements, or interpolate measurements to a common timestamp, before performing forward kinematics, Jacobian calculations, force estimation, or coordinated control.

Multi-axis position control often evaluates not only individual joint errors but also coordination errors between axes. For mechanically coupled axes, gantry systems, dual-motor joints, or parallel mechanisms, the difference between paired positions can be explicitly controlled. A synchronization error such as \(e_s=x_1-x_2\) can feed a cross-coupling controller that generates corrective commands while preserving the primary motion objective.

Cross-coupled control improves coordinated tracking when independent servo loops alone cannot maintain the required geometric relationship. Instead of treating each axis error separately, the controller considers how one axis deviates relative to another or relative to the desired Cartesian path. Corrective torque or velocity terms can then reduce contour error. Coupling gains must remain compatible with individual servo stability and mechanical compliance.

Dual-motor mechanisms require especially careful synchronization because both actuators may drive the same load. Small position or torque differences can generate internal mechanical stress even when the external load follows the intended trajectory. Master-slave, average-position, torque-sharing, or symmetric cross-coupled structures can be used depending on the mechanism. Torque balance should be monitored in addition to position synchronization.

Torque synchronization is important for shared-load actuators and multi-contact robotic systems. If two motors contribute to one mechanical function, total demanded torque must be distributed according to motor capability, transmission ratio, temperature, and operating limits. Equal current does not necessarily produce equal output torque when actuator characteristics differ. Torque commands should therefore be normalized using calibrated motor and drivetrain parameters.

Multi-axis force control adds another synchronization requirement because Cartesian force is reconstructed from joint torques and robot configuration. The relationship \(\tau=J^T F\) assumes that joint torque and position values represent the same physical instant. Timestamp mismatch between axes can corrupt the calculated wrench during rapid motion. Synchronized torque sensing, encoder sampling, and deterministic data exchange are therefore essential for accurate force estimation.

Shared power constraints can influence coordinated motion even when axis timing is correct. Several motors accelerating simultaneously may exceed DC-link current, battery power, regenerative capability, or thermal limits. A system-level power manager can distribute available current or torque among axes while maintaining trajectory priorities. Regenerative energy from decelerating axes may also interact with accelerating axes through the common DC bus.

Synchronization software must handle command loss without allowing one axis to continue uncontrolled relative to the others. Sequence numbers, watchdog timers, timestamps, and validity flags can detect missing, duplicated, delayed, or out-of-order commands. When a reference becomes stale, the affected axis should enter a defined hold, controlled-stop, or fault state. Coordinated mechanisms may require all related axes to transition together rather than stopping only one motor.

Fault handling should consider the mechanical consequences of asymmetric actuator behavior. If one joint in a robot arm loses torque while others continue following their trajectories, the resulting motion may be unsafe. Similarly, one side of a dual-motor gantry stopping while the other continues can damage the structure. A synchronization supervisor should propagate critical axis faults to the appropriate motion group and initiate a coordinated reaction according to system requirements.

Coordinated stopping requires its own trajectory rather than simply disabling every motor at the same instant. Different axes have different velocities, inertias, loads, and braking capabilities. The motion controller can generate synchronized deceleration profiles that bring the robot to a safe state while respecting joint limits and maintaining mechanical coordination. Emergency hardware shutdown remains available when controlled stopping cannot provide adequate protection.

Real-time scheduling is fundamental to deterministic multi-axis control. High-priority current loops, synchronized servo tasks, communication processing, trajectory interpolation, and diagnostics must have defined execution budgets. Priority inversion, unbounded memory allocation, blocking I/O, or excessive logging can introduce timing jitter. Worst-case execution time and communication latency should therefore be considered when designing the multi-axis software architecture.

Scalability becomes important as the number of controlled axes increases. A six-axis robot arm may tolerate communication and computation structures that become inefficient for a humanoid or complex mobile manipulator with dozens of actuators. Axis software should use reusable motor-control objects, standardized command and feedback structures, grouped synchronization domains, and efficient data transport so that additional actuators do not fundamentally change the control architecture.

Each axis should expose a consistent interface containing commanded and measured position, velocity, torque, control mode, timestamp, sequence information, validity, and fault state. Standardized interfaces allow the synchronization layer to coordinate motors with different power ratings or transmission systems. Hardware-specific details remain inside the local drive, while the robot controller operates on normalized joint-level information.

Diagnostics should measure synchronization quality directly. Useful metrics include command latency, communication jitter, clock offset, servo-cycle jitter, timestamp age, missed cycles, position skew, torque imbalance, contour error, and maximum inter-axis timing difference. Recording these values with trajectory and fault information makes it possible to distinguish mechanical tuning problems from communication, scheduling, clock, or individual drive-control problems.

Verification should begin with simulated clocks, communication delay, and multiple virtual axes before progressing to physical hardware. SIL and HIL testing can inject clock drift, packet jitter, delayed commands, encoder timestamp errors, missed cycles, motor faults, and unequal actuator dynamics. Hardware tests should measure actual command-to-PWM timing, feedback alignment, trajectory error, coordinated stopping, and behavior under communication or axis failures.

Multi-axis motor control synchronization ultimately transforms independent motor drives into a coordinated robotic motion system. Shared time, synchronized feedback, timestamped commands, trajectory interpolation, cross-coupled control, deterministic communication, coordinated fault handling, and system-level power management preserve the intended relationship between actuators. These mechanisms provide the software foundation for precise robot arms, humanoids, mobile manipulators, gantries, and other tightly coordinated multi-axis machines.

03.10 Robot Joint Motor Control SW Integration Case [w/Code]

Robot joint motor control software integration combines sensing, estimation, cascaded control, inverter actuation, protection, communication, and diagnostics into one deterministic actuator subsystem. The objective is not simply to operate a motor, but to convert robot-level joint commands into controlled mechanical position, velocity, and torque while continuously reporting joint state and maintaining electrical, thermal, and mechanical limits.

A representative joint actuator consists of a PMSM or BLDC motor, three-phase inverter, current sensors, rotor encoder, temperature sensors, gearbox, mechanical joint, and embedded motor-control processor. The software must treat these components as one coordinated control plant. Motor-side measurements are converted into physical joint quantities using encoder offsets, pole-pair count, transmission ratio, torque constants, and calibrated sensor parameters.

The software architecture can be divided into hardware abstraction, signal processing, fast motor control, joint servo control, protection, communication, and supervisory state management. Hardware-specific ADC, PWM, timer, encoder, SPI, and GPIO functions remain beneath stable software interfaces. This separation allows control algorithms to be developed and tested independently from a particular MCU, inverter, encoder, or joint hardware implementation.

Initialization begins before torque production is permitted. The software configures PWM timers, ADC triggering, encoder interfaces, communication, watchdogs, gate-driver inputs, and temperature channels. Current-sensor zero offsets and encoder validity are checked, configuration parameters are loaded, and protection status is evaluated. PWM remains disabled until the joint reaches a defined ready state and all mandatory initialization conditions are valid.

Rotor position processing provides both mechanical joint information and the electrical angle required by FOC. Incremental or absolute encoder data are validated, corrected for direction and offset, and converted into continuous motor position. Mechanical angle is multiplied by the motor pole-pair count to obtain electrical angle, while gearbox ratio converts motor-shaft position and velocity into joint-side position and velocity used by robot-level control.

Current acquisition is synchronized with PWM operation so that phase currents are sampled during valid measurement windows. Raw ADC values pass through offset correction, gain scaling, reconstruction, and plausibility checking before entering the Clarke and Park transformations. The resulting d-q currents form the high-bandwidth feedback variables for electromagnetic torque control and simultaneously support overcurrent protection and torque estimation.

The innermost FOC loop regulates d-axis and q-axis currents. Current errors pass through PI controllers, decoupling or feedforward terms, voltage limiting, inverse Park transformation, and SVPWM generation before new inverter duty cycles are applied. This loop executes at the highest periodic control rate because current dynamics and inverter switching require substantially faster response than mechanical position or robot trajectory control.

Above the current loop, a velocity controller converts velocity error into a torque-producing current reference. The q-axis reference is constrained by motor, inverter, thermal, and system limits, while the d-axis reference is normally near zero for a surface-mounted PMSM below the field-weakening region. Anti-windup prevents controller integrators from accumulating unrealistic commands when current or voltage limits become active.

The position loop forms the outer servo layer of the joint. Desired joint position is compared with measured joint position, and the resulting error generates a velocity reference for the inner velocity loop. Position, velocity, and current loops therefore form a cascaded structure in which each inner loop operates faster than the outer loop. Bandwidth separation helps preserve stability while providing precise trajectory tracking and disturbance rejection.

Joint torque can be estimated from q-axis current using the calibrated motor torque constant and then transformed through the gearbox model. Transmission efficiency, friction, inertia, and drivetrain elasticity can be included when greater joint-side accuracy is required. If the actuator includes a direct torque sensor or series elastic element, measured torque can supplement current-based estimation and provide an independent feedback or plausibility channel.

The integrated joint controller may support several operating modes, including disabled, position, velocity, torque, and calibration modes. A mode manager determines which reference enters the cascaded control structure and initializes controller states during transitions. Bumpless transfer is important because switching directly between controllers with inconsistent integrator states or references can generate abrupt current and torque commands.

Command processing occurs before references reach the servo loops. Robot-level commands are checked for validity, timestamp, sequence, joint limits, velocity limits, acceleration limits, and torque constraints. Slew-rate or trajectory limiting can prevent discontinuous requests from reaching the motor. When synchronized multi-axis operation is required, commands can include an intended execution time so that several joint controllers apply references using a common time base.

Feedback returned to the robot controller should use normalized joint-level quantities rather than raw motor hardware values. Typical information includes joint position, velocity, estimated or measured torque, motor current, motor and inverter temperature, operating mode, timestamp, validity, and fault state. This standardized interface allows the higher-level robot software to coordinate different joint actuators without depending on their internal motor or sensor implementation.

Protection logic operates across every control layer. Fast hardware overcurrent protection can disable inverter gates independently of normal software execution, while high-frequency software limits current and torque. Slower supervision evaluates motor and inverter temperature, overload accumulation, encoder faults, communication timeout, stall conditions, DC-link voltage, and mechanical limits. Protection always retains higher authority than normal position or torque commands.

Thermal derating allows the actuator to remain operational when possible rather than immediately entering shutdown. As motor or inverter temperature approaches its configured limit, the software reduces the allowable current or torque envelope. The servo controller then operates within this reduced capability. If temperature continues rising, a protection state transition disables torque and prevents restart until defined recovery conditions are satisfied.

A joint state machine coordinates initialization, calibration, ready, enabled, running, stopping, fault, cooldown, and recovery behavior. Control algorithms calculate actuator commands only when the current state permits torque generation. Critical faults transition directly toward a safe state, while recoverable conditions may request controlled stopping. Explicit state transitions make actuator behavior predictable during startup, normal operation, faults, and reset sequences.

Communication failure requires a defined joint-level reaction. A watchdog monitors command age or periodic heartbeat messages and detects stale references. Depending on the robot architecture, the actuator may hold position, ramp torque toward zero, execute a controlled stop, or disable the inverter. In a multi-axis robot, the local fault is also reported to the synchronization supervisor so that mechanically related joints can perform a coordinated response.

Real-time scheduling separates control functions according to required bandwidth and criticality. PWM-triggered current acquisition and FOC execute in the highest-priority periodic context, velocity control runs at a lower rate, and position or trajectory processing runs more slowly. Temperature supervision, diagnostics, parameter management, and communication services occupy slower tasks. Execution time must remain bounded so that lower-priority activity cannot disturb motor-control timing.

Data exchange between tasks should preserve temporal consistency. Position, current, velocity, torque, and command values used within one servo calculation should represent a coherent control cycle rather than an arbitrary mixture of old and new samples. Double buffering, atomic data structures, timestamps, sequence counters, or lock-free exchange mechanisms can be used to transfer state between interrupt-level control code and supervisory tasks.

Calibration data connects software algorithms to the physical actuator. Current offsets and gains, encoder zero position, electrical-angle offset, pole-pair count, gearbox ratio, torque constant, friction parameters, temperature conversion data, and protection thresholds should be stored with version and validity information. Invalid or incompatible calibration data should prevent normal torque-enabled operation rather than silently applying uncertain parameters.

Diagnostics provide visibility into the complete integrated control chain. Useful traces include commanded and measured position, velocity, d-q current, estimated torque, electrical angle, PWM duty, DC-link voltage, temperatures, controller saturation, communication timing, and fault flags. Capturing pre-fault and post-fault samples makes it possible to reconstruct the sequence leading to a joint failure instead of relying only on a final fault code.

Multi-axis integration extends the same joint architecture across the robot. Every actuator executes local deterministic loops while a higher-level controller distributes synchronized trajectory references. Shared timestamps and aligned feedback allow robot kinematics and force-control algorithms to operate on a consistent joint state. Fault propagation, coordinated stopping, and system-level power limits connect otherwise independent joint controllers into one robotic system.

Verification should proceed from individual software functions to the complete actuator. Unit tests validate transforms, scaling, limits, state transitions, and fault logic. SIL verifies the cascaded controller against a simulated motor and mechanism, while HIL introduces realistic encoder, current, communication, and fault signals. Hardware testing then confirms current regulation, position tracking, torque response, thermal behavior, protection timing, and recovery on the actual joint.

An integrated robot joint controller therefore forms a layered path from robot command to physical torque and back to validated joint feedback. Encoder and current processing support cascaded position, velocity, and FOC loops; SVPWM drives the inverter; torque estimation and protection supervise mechanical output; and communication connects the actuator to synchronized robot control. The resulting architecture provides a reusable foundation for reliable, precise, and scalable robot joints.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go