LED independent coordinate system visual feedback control method and system of force feedback knob

Abstract

The application discloses a kind of LED independent coordinate system visual feedback control method and system of force feedback knob. Visual rendering field establishes the LED coordinate system independent of physical angle sensor, and the angle change is mapped as visual indication position with physical zero point reference, so that the center of moment control field is repositioned without affecting visual zero point. When the center of moment reference is repositioned, asynchronous return animation with a function of slow motion is triggered, and the visual indication is updated smoothly. The animation output is the only value source of LED angle. Two domains communicate through double buffering mechanism through data update notification with cross-domain write visibility guarantee, and moment writing is never blocked. The application eliminates visual jump and cross-domain communication delay, and realizes the decoupling and cooperation of touch-visual double channels.

Description

Technical Field

[0001] This invention relates to the field of human-computer interaction and embedded visual feedback technology, specifically to a method and system for LED independent coordinate system visual indication management, asynchronous centering animation, cross-domain double buffer communication, interpreter mode rendering architecture, and adaptive frame rate control applied to force feedback knob devices. Background Technology

[0002] Force feedback knobs are a new type of high-end human-computer interaction device. They typically feature a ring of LED lights around the knob to provide users with visual feedback on rotation position and mode status. Ideally, the visual pointer on the LED ring should accurately reflect the physical rotation position of the knob, allowing users to obtain a consistent interactive experience through both visual and tactile channels.

[0003] However, in the practical application of force feedback knobs, the following prominent technical problems exist:

[0004] First, the spring-rebound mode of the force feedback knob requires repositioning the spring center each time it is activated or deactivated from the rotation mode—that is, setting the spring center to the current knob angle position to avoid sudden torque changes during switching. If the visual pointer of the LED ring directly follows the original reading of the physical angle sensor, the repositioning of the spring center will cause an unpredictable shift in the visual pointer's position relative to the "zero point" of the ring. Specifically, users expect the visual zero point in spring mode to always remain at the 12 o'clock position (directly above) of the ring, but the repositioning of the spring center causes the physical zero point to shift, and the visual pointer shifts accordingly, disrupting visual consistency. In a common use case, a user swings the knob in spring mode to enter rotation mode, and the rotation stops 120° away from the spring center before exiting rotation. At this point, the torque control domain repositions the spring center to the knob's current position (shifted 120°). If the visual pointer directly follows the physical angle, the user will see the visual zero point, which was originally at the 12 o'clock position, suddenly jump to the 4 o'clock position—the user cannot understand how this visual jump is related to their previous operation.

[0005] It is important to note that the aforementioned technical issues are fundamentally different from coordinate system management, easing animations, and double buffering mechanisms in general game engines, front-end UI frameworks, or operating system kernels. The coordinate system separation (world coordinates and camera coordinates) in game engines (such as Unity / Unreal) addresses the perspective rendering problem in virtual 3D space. The frequency difference between its physics engine (FixedUpdate) and rendering engine (Update) only affects screen smoothness and does not lead to a degradation of the user's tactile experience. The tween easing animations in front-end UI frameworks address the transition effects of planar graphic elements. Input locking during animation only involves blocking mouse / touch events and does not guarantee the real-time performance of torque control. The double buffering mechanism in operating system kernels (such as page flipping in the Linux framebuffer) addresses the tearing problem in display output. Its "dirty flag" is used to mark screen areas that need redrawing, which is completely different from the cross-domain communication semantics of marking torque reference center relocation events in this invention. The core technical challenge of this invention lies in the fact that the force feedback knob is a closed-loop system with a deep coupling between a tactile input device and a visual output device. Any parameter change in the torque control domain (such as the repositioning of the torque reference center) will be directly perceived by the user's fingers and simultaneously reflected in the visual output within millisecond time constraints. Any improper handling—whether it is a shift in visual coordinates, discontinuity in animation transitions, or torque control delay caused by cross-domain communication—will be captured by the user's touch and vision simultaneously, resulting in an experiential defect of "incoordination between tactile feedback and lighting effects." This tactile-visual closed-loop coupling constraint is a unique technical problem that does not exist in the aforementioned general technical fields, and those skilled in the art have no technical motivation to migrate game engine rendering architecture or UI animation framework to the force feedback knob scenario.

[0006] Second, when the force feedback mode switches (e.g., from rotation mode back to spring mode), the visual pointer needs to return from its current position to the zero position. If an instantaneous jump is used, the user will see the pointer move instantaneously across the light ring, creating a discontinuous visual experience. In extreme cases (e.g., the pointer moves instantaneously from the 6 o'clock position to the 12 o'clock position), the visual jump spans 180° of the light ring's arc, and the human eye cannot track such instantaneous displacement, causing confusion for the user's perception of the knob's current state.

[0007] Third, the force feedback control logic (torque calculation, mode switching, sensor reading) and the LED lighting effect rendering logic operate at different frequencies and may run on different processor cores. Torque control requires a high frequency (above 200Hz) to ensure the real-time performance of haptic feedback, while LED rendering only needs 30-60Hz to ensure visual smoothness. If a mutex is used for data sharing between the two domains, the following problem will occur: when the rendering domain holds the lock to copy data (taking about 5-10 microseconds), the torque control domain is blocked while attempting to write data, waiting for the lock to be released. In a 500Hz torque control loop, each control cycle is only 2 milliseconds. Although the 5-10 microsecond lock wait time is very short in absolute terms, in extreme cases (lock contention, priority inversion), it may cause the torque control cycle to time out, resulting in slight jitter in the haptic feedback.

[0008] Fourth, when the LED rendering frame rate switches between active (60Hz) and idle (30Hz) states, the frame interval changes from 16.7 milliseconds to 33.3 milliseconds. If the low-pass filter for the LED angle uses a fixed filter coefficient, the filtering effect per frame differs from that at high frame rates—at 30Hz, a single-step filter with a fixed coefficient covers 33.3 milliseconds of data, while at 60Hz, the same coefficient only covers 16.7 milliseconds of data. This results in a significant weakening of the filtering effect at 30Hz, leading to a decrease in the smoothness of the visual pointer. Summary of the Invention

[0009] To address the aforementioned technical problems, the present invention aims to provide a visual feedback control method and system for an LED independent coordinate system of a force feedback knob. This method establishes an LED coordinate system independent of the physical angle sensor readings, ensuring that the reference position of the visual indication is unaffected by the repositioning of the spring center in the torque control domain; it achieves a smooth transition of the pointer position during mode switching through asynchronous centering animation with an easing function; it enables lock-free cross-domain communication between the torque control domain and the visual rendering domain through a double-buffering mechanism with a data update notification mechanism that guarantees cross-domain write visibility; and it ensures consistency of filtering behavior before and after frame rate switching through adaptive filtering coefficients.

[0010] The "non-gradual repositioning" described in this invention refers to a one-time, leapfrog change in the torque reference center position due to mode switching, host computer commands, or internal system state transitions. This differs from the gradual, progressive displacement in ratchet or gear modes, where the torque reference center automatically advances to the next predefined gear with each user's rotation. In gradual, progressive displacement, the angle amplitude of each advance is typically a fixed small angle (e.g., 10° or 15°), and the direction of advance is consistent with the user's rotation direction; the change in the torque reference center is an immediate response to the user's operation. In non-gradual, progressive repositioning, the amplitude and timing of the torque reference center change are determined by system state transitions or external commands, potentially spanning any angle range, and have no direct correlation with the user's current rotation direction or operational intent. The asynchronous centering animation in this invention is triggered only when non-gradual, progressive repositioning occurs to avoid unnecessary visual animation interference in ratchet / gear-like operations.

[0011] To achieve the above objectives, the present invention provides an LED independent coordinate system visual feedback control method for a force feedback knob, which is applied to a force feedback knob device having a torque actuator, an angle sensor and a ring LED light ring, wherein the device includes two processing domains that operate independently at different frequencies: a torque control domain and a visual rendering domain. The visual rendering domain maintains an LED angle state variable, which, referenced to the physical zero-point reference, maps changes in the physical angle of the knob to the visual indicator position on the LED ring. This LED angle state variable is the sole determinant of the visual indicator position on the LED ring—when the rendering domain needs to render visual effects on the ring, it directly uses this variable to calculate the index and brightness of the target LED, without referencing the raw readings from the physical angle sensor. The physical zero-point reference is anchored to the current physical angle value when the spring mode is first activated, its physical meaning being "this current physical angle corresponds to the 12 o'clock position on the LED ring." Subsequent spring center repositioning operations in the torque control domain only change the torque parameters and do not affect the physical zero-point reference. When the torque reference center position in the torque control domain undergoes a non-progressive repositioning, and there is a deviation between the LED angle state variable and the target angle position, the visual rendering domain initiates a progressive centering animation with an easing function to smoothly transition the LED angle state variable from its current value to the predetermined target angle position value. During the animation execution, the output of the progressive centering animation serves as the sole source of value for the LED angle state variable, replacing the updated value calculated based on the physical angle; the current value of the LED angle state variable drives the visual indication rendering of the ring-shaped LED light ring. The torque control domain and the visual rendering domain communicate via a double-buffered mechanism. The torque domain acts as the sole writer, and the rendering domain as the sole reader. Write operations set a volatile dirty flag, and read operations check and clear the dirty flag before performing a structure copy. The torque domain will never be blocked.

[0012] The beneficial effects of the above technical solution are as follows: (1) LED coordinate system independence: The LED angle state variables are completely independent of the physical angle sensor readings. Operations such as spring center repositioning and mode switching in the torque control domain only change the torque calculation parameters and do not affect the visual indication position of the LED ring. The visual zero point seen by the user always remains at the 12 o'clock position of the ring, regardless of how the underlying torque parameters change. (2) Visual continuity of asynchronous centering animation: When the torque reference center position undergoes non-gradual repositioning, the LED visual indicator smoothly transitions from the current position to the target angle position through a gradual centering animation with an easing function. After an initial rapid movement, it gradually decelerates and stops, simulating the natural movement of physical inertia. During the animation execution, the animation output serves as the sole source of values ​​for the LED angle state variable, replacing the update value driven by the physical angle, ensuring that the animation process is not interrupted. (3) Double-buffered lock-free cross-domain communication: The torque control domain writes data at 200Hz, and the visual rendering domain reads data at 30-60Hz. The write operation of the torque control domain will never be blocked - even if the rendering domain is reading, the torque domain can still write the next frame of data to the write buffer. A data update notification mechanism with cross-domain write visibility guarantee ensures data synchronization between the two domains. (4) Frame rate independence of adaptive filtering: The filter coefficients are dynamically calculated based on the actual time increment of each frame using the formula α = 1 - exp(-Δt / τ), which mathematically guarantees that the temporal behavior (time constant) of the filter remains unchanged regardless of the frame rate. When the frame rate switches from 60Hz to 30Hz, the smoothness and responsiveness of the visual pointer remain consistent. Attached Figure Description

[0013] Figure 1 This is a schematic diagram showing the relationship between the LED independent coordinate system and the physical coordinate system of the present invention, illustrating the correspondence between the physical zero-point reference, the spring center, and the LED angle;

[0014] Figure 2 This is a schematic diagram illustrating the principle of maintaining the continuity of the LED angle during spring center repositioning according to the present invention.

[0015] Figure 3 This is the easeOutCubic easing curve and adaptive duration calculation diagram for the asynchronous return animation of this invention;

[0016] Figure 4 This is a schematic diagram of the cross-domain double-buffered communication architecture of the present invention, showing the data flow between the torque control domain and the visual rendering domain;

[0017] Figure 5 This is a three-layer architecture diagram of the interpreter mode rendering pipeline of the present invention;

[0018] Figure 6 This is the state transition diagram for the adaptive frame rate control of this invention;

[0019] Figure 7 This diagram illustrates the consistency of the adaptive filtering coefficients' behavior at different frame rates. Detailed Implementation

[0020] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. I. System Hardware Architecture

[0021] The force feedback knob control system of the present invention includes: a dual-core microcontroller (in this embodiment, an ESP32-S3 is used, with two Xtensa LX7 cores, a main frequency of 240MHz, and a hardware single-precision floating-point arithmetic unit), a torque actuator (in this embodiment, a 14-pole logarithmic brushless DC motor is used; those skilled in the art will understand that other types of torque actuators, such as brushed DC motors, voice coil motors, or stepper motors, can also be used), a 14-bit magnetic angle sensor (resolution 0.022°), a ring of LEDs arranged around the knob (in this embodiment, 6 RGB LEDs are used; those skilled in the art will understand that the number of LEDs can be 12, 24, or more), and an event output interface (USB HID or Bluetooth Low Energy HID).

[0022] The system runs two core domains on the microcontroller: Torque Control Domain (FOC Domain): Running in the high-frequency main loop of Core 1, driven by the task scheduler of the real-time operating system (FreeRTOS) with the highest priority, the execution frequency is approximately 200Hz to 1000Hz (approximately 500Hz in this embodiment, with a control cycle of approximately 2 milliseconds). It is responsible for FOC motor vector control, angle sensor reading, torque calculation, force feedback mode management, and control event generation. Visual Rendering Domain (LED Domain): Runs in a standalone FreeRTOS task in Core 0, with a task stack size of 6144 bytes, a task priority of 4, and a rendering frequency of 60Hz (approximately 16.7 milliseconds frame interval) in active state, decreasing to 30Hz (approximately 33.3 milliseconds frame interval) in idle state. It is responsible for LED coordinate system management, interpreter routing, lighting effect rendering, adaptive frame rate control, and audio response processing. The two domains communicate through a double buffering mechanism, without blocking each other. II. LED Independent Coordinate System

[0023] The visual rendering domain maintains the following key state variables: `led_independent_angle`: An independent angle state variable for the LED, a floating-point type, with a value range of [0, 2π]. This variable is the sole determinant of the position of the visual pointer on the LED ring. When the visual rendering domain needs to render the pointer on the ring, this variable is used directly to calculate the index and brightness ratio of the target LED, without referencing the raw readings from the physical angle sensor. `led_coordinate_zero_reference`: The physical zero-point reference of the LED coordinate system, a floating-point type. This value is anchored to the physical angle value at the time of the first activation of spring mode, and its physical meaning is "this physical angle corresponds to the 12 o'clock direction of the LED light ring". led_independent_velocity: LED independent angular velocity, floating-point type, used for velocity-related visual effect calculations. led_coordinate_system_active: LED independent coordinate system enabled flag, Boolean type.

[0024] The method for calculating the independent angle of the LED involves executing different coordinate transformation logic based on the current force feedback mode in each rendering cycle: Spring-rebound mode (and not during the return-to-center animation): physical_offset = angleDifference(θ_filtered, θ_zero_reference) led_independent_angle = normalize_to_positive(physical_offset) This calculation ensures that when the knob begins to deflect from the center position of the spring, the LED pointer begins to deflect from the 12 o'clock position, and the amount of deflection is consistent with the physical deflection.

[0025] Non-spring modes (point mode, gyroscope mode, damped mode, etc.): physical_offset = angleDifference(θ_filtered, θ_zero_reference)angle_diff = angleDifference(physical_offset, led_independent_angle) led_independent_angle = normalize(led_independent_angle + angle_diff × α) Where α is the mode-dependent smoothing coefficient—0.8 for gyroscope mode (high responsiveness, visual pointer quickly follows high-speed rotation), and 0.3 for other modes (moderate smoothing, reducing the visual visibility of high-frequency sensor jitter).

[0026] The engineering significance of smoothing coefficients α=0.8 (gyroscope mode) and α=0.3 (other modes): In gyroscope mode, the knob is driven by a motor to rotate at a speed of 10-20 rad / s. The visual pointer needs to quickly follow the rotation to present the effect of "the pointer rotating with the knob." A coefficient of 0.8 allows the pointer to converge to its physical position within 2-3 frames. In other modes (such as dot-matrix mode), the knob is usually operated manually at a low speed. The noise of the sensor at low speeds is more significant than the signal amplitude. A coefficient of 0.3 provides a stronger smoothing effect, requiring 5-8 frames to converge, but eliminating the pointer jitter caused by sensor noise. III. Analysis of LED Angle Continuity During Spring Center Repositioning

[0027] When the torque control domain performs a spring center repositioning operation (typical scenario: after exiting rotation mode, setting the spring center to the current knob position to prevent rebound), the physical zero-point reference (θ_zero_reference) is synchronously updated to the new spring center angle. The following analysis demonstrates that this synchronous update ensures the numerical continuity of the LED angle before and after repositioning: Let the spring center before repositioning be θ_center_old, and the current knob angle be θ_current. The LED angle before repositioning is: LED_angle_before = angleDifference(θ_current, θ_center_old) After repositioning, the spring center becomes θ_center_new = θ_current, and the physical zero-point reference is synchronously updated to θ_center_new. The LED angle after repositioning is: LED_angle_after = angleDifference(θ_current, θ_center_new) =angleDifference(θ_current, θ_current) = 0

[0028] In other words, after repositioning, the LED angle jumps to 0 (at the 12 o'clock position). However, this jump occurs when the spring mode is reactivated, at which point the system simultaneously starts an asynchronous centering animation. The centering animation uses the LED angle value before repositioning as the starting angle (non-zero value) and 0 as the target angle, smoothly transitioning through an easing function. Therefore, the effect the user sees is that after exiting the rotation, the visual pointer smoothly "slides back" from its current position to the 12 o'clock position, rather than jumping instantly.

[0029] The core of this design lies in the fact that updating the physical zero-point reference and initiating the return-to-center animation are an atomic sequence of operations—first update the physical zero-point reference, then start the animation (starting from the LED angle before the update). If the order of these two operations is reversed (start the animation first, then update the physical zero-point reference), the starting angle of the animation will be calculated based on the old physical zero-point reference, and the physical zero-point reference will only be updated after the animation ends. This will cause the LED angle to be inconsistent with the new physical zero-point reference when the animation is completed, resulting in a secondary jump. IV. Asynchronous Return Animation

[0030] When the force feedback mode switches to the spring rebound mode (e.g., after exiting gyroscope mode), the system executes the following asynchronous return-to-center animation process: Step 1 – Animation Parameter Initialization: Record the current value of led_independent_angle as start_angle; Set target_angle to 0.0 (12 o'clock position); Calculate the shortest angle path: direct_distance = angleDifference(0.0, start_angle); Determine the animation direction—clockwise if direct_distance is positive, counterclockwise if negative; Calculate the adaptive animation duration: duration = 300 + (|direct_distance| / π) × 400 milliseconds.

[0031] The engineering significance of distance-adaptive duration: When the pointer is very close to the 12 o'clock position (e.g., offset by 30° ≈ 0.524 radians), the animation duration is approximately 300 + (0.524 / π) × 400 ≈ 367 milliseconds, quickly returning to the center with almost no waiting time for the user; when the pointer is far from the 12 o'clock position (e.g., offset by 170° ≈ 2.967 radians), the animation duration is approximately 300 + (2.967 / π) × 400 ≈ 678 milliseconds, allowing for a smooth transition and avoiding visual discomfort caused by the pointer rapidly flying across half of the light ring. The shortest duration of 300 milliseconds corresponds to the edge case where the pointer is exactly at the 12 o'clock position (distance≈0). In this case, the animation still executes but is completed almost instantaneously, providing a deterministic transition window for the state machine. The longest duration of 700 milliseconds (300+400) corresponds to the pointer being at the 6 o'clock position (distance=π, i.e., 180° opposite). This is the maximum movement speed that the human eye can comfortably track—180° is completed within 700 milliseconds, with an equivalent rotation speed of approximately 257° / second, which is lower than the human eye's tracking limit for a moving light spot on an LED ring (approximately 500° / second).

[0032] Step 2 – Frame-by-frame update (executed in each rendering cycle): Calculate linear time progress: progress = elapsed_time / duration, range [0, 1]. Apply the easing function three times: eased_progress = 1 - (1 - progress)³ The motion characteristics of the three gradual exits and easing phases are as follows: near progress=0, the rate of change of eased_progress is approximately 3 (derivative = 3 × (1-0)² = 3), and the pointer starts moving quickly; at progress=0.5, the rate of change is approximately 0.75 (derivative = 3 × 0.5² = 0.75), and the pointer begins to decelerate; near progress=1, the rate of change approaches zero (derivative = 3 × (1-1)² = 0), and the pointer stops smoothly. The entire motion simulates a natural deceleration process of "fast at first, then slow," which is highly consistent with the frictional sliding stop in the physical world.

[0033] Calculate the LED angle in the current frame: total_diff = angleDifference(target_angle, start_angle) animated_angle = normalize(start_angle + total_diff × eased_progress) led_independent_angle = animated_angle Angular interpolation is performed in a circular space—the `angleDifference` function calculates the difference between the shortest paths from `start_angle` to `target_angle` (ranging from [-π, +π]), ensuring that the interpolation path always takes the shortest arc rather than a longer route. For example, when `start_angle=350°` and `target_angle=10°`, the shortest path is 20° clockwise (instead of 340° counterclockwise), and the animation follows the shortest arc of 20°.

[0034] Step 3 – Animation Protection Mechanism: During animation execution (when the `spring_return_animation_active` flag is true), the physical angle update logic for the LED independent coordinate system is skipped. In the `updateLEDIndependentSystem()` method, the first check in the spring mode branch is "whether the return-to-center animation is active." If so, it skips directly without performing any physical angle to LED angle conversion. This ensures that the LED angle is completely controlled by the animation logic during the animation and is not interrupted or overwritten by physical angle data. This protection mechanism addresses a critical race condition: while animation is executing, the torque control domain continues to write the latest physical angle data to the double buffer at a frequency of 200Hz. Each rendering cycle of the rendering domain reads new physical angles from the double buffer; without the animation protection mechanism, this new physical angle data would overwrite the LED angle values ​​being calculated by the animation, causing the pointer to blink and jump between the animation path and the physical position.

[0035] State restoration after animation completion: `led_independent_angle` is precisely set to 0.0 (12 o'clock position), and the `spring_return_animation_active` flag is cleared. Subsequent rendering cycles resume normal LED angle calculations based on physical angle offsets. Since the physical zero-point reference has been synchronously updated to the new spring center angle, and the knob has returned to the vicinity of the spring center under the action of spring force, the physical offset is close to zero—the transition of the LED angle from the animation endpoint (0.0) to the normal calculation result (close to 0.0) is continuous, without producing a perceptible jump. V. Cross-domain double-buffered communication mechanism

[0036] Data transfer between the torque control domain and the visual rendering domain employs a double-buffering mechanism, as implemented below: The data structure, FocInputBuffer, contains the following fields: angle_rad (floating-point, angle value in radians), velocity_rad_per_s (floating-point, angular velocity value in radians / second), mode (enumerated type, force feedback mode identifier, values ​​include spring rebound mode, gyroscope mode, damped mode, point mode, etc.), is_in_deadzone (boolean, dead zone status flag), has_detent_pulse (boolean, whether there is a point pulse), detent_amplitude (floating-point, point pulse intensity, value [0, 1]), and timestamp_ms (32-bit unsigned integer, timestamp, in milliseconds).

[0037] Write operation (torque control domain, execution frequency approximately 200Hz): At the end of each control cycle, the torque control domain writes the current knob state to the write buffer (foc_write_buffer) and then sets the dirty flag (foc_buffer_dirty) to true. The dirty flag is declared as a volatile bool type. The volatile keyword ensures that the compiler will not optimize reads and writes to this variable, guaranteeing that a write to one core is immediately visible to another core.

[0038] Read operations (visual rendering domain, execution frequency 30-60Hz): At the beginning of each rendering cycle, the visual rendering domain checks the dirty flag. If the dirty flag is true, a complete copy of the structure is performed, copying the contents of the write buffer to the read buffer (foc_read_buffer), and then the dirty flag is set to false. Subsequent rendering calculations use the data in the read buffer.

[0039] Analysis of the correctness of this mechanism: The torque domain is the only writer, and the rendering domain is the only reader; there is no write-write competition. If new data is written to the torque field during the copying process in the rendering domain, the worst-case scenario is that the rendering domain reads data from an intermediate state of a frame (the first half is the old value, and the second half is the new value). However, since all fields of the FocInputBuffer describe the knob's state at the same moment, even if data from two moments are mixed, the impact on rendering is only a slight inconsistency in angle and speed. At a torque control frequency of 200Hz, the change in knob angle between two adjacent control cycles is approximately |ω| × T = 10 rad / s × 0.005s = 0.05 radians (approximately 2.9°), and the change in speed is approximately |α| × T ≈ 0.5 rad / s. At rendering frame rates of 30-60Hz, this level of data mixing has a far lower impact on the visual pointer position than the angular resolution of a single LED (the resolution of a 6-LED ring is 60° / LED), making it completely imperceptible to the human eye.

[0040] The torque domain is never blocked by the rendering domain. Even if the rendering domain is performing a structure copy (reading from `foc_write_buffer`), the torque domain can still write to `foc_write_buffer` in the next control cycle. The worst-case scenario is that the rendering domain reads some new data in the current copy and then reads the complete new data when it re-copyes in the next frame. This non-blocking characteristic is crucial for the real-time performance of torque control—any delay in haptic feedback is immediately perceived by the user, while inconsistencies in visual data over a single frame (overwritten by the next frame after 16.7–33.3 milliseconds) are completely invisible to the user. VI. Adaptive Filtering Coefficients

[0041] The filter coefficients in the visual rendering domain do not use fixed values, but are dynamically calculated based on the actual time increment of each frame: α = 1 - exp(-Δt / τ) Where Δt is the actual time interval between the current frame and the previous frame (converted from milliseconds to seconds), and τ is the preset filtering time constant. Angle filter: τ_position = 8 ms (fastly follows position changes) Velocity filter: τ_velocity = 12 ms (moderately smooths velocity fluctuations)

[0042] Proof of consistent filtering behavior during frame rate switching: When the rendering frame rate is 60Hz, Δt = 16.7 milliseconds, the angle filtering coefficient α_60 = 1 - exp(-16.7 / 8) = 1 - exp(-2.088) ≈ 1 - 0.124 = 0.876. When the rendering frame rate is 30Hz, Δt = 33.3 milliseconds, the angle filtering coefficient α_30 = 1 - exp(-33.3 / 8) = 1 - exp(-4.163) ≈ 1 - 0.016 = 0.984. This means that at 60Hz, the filter jumps from the old value to the new value in 87.6% of each frame; at 30Hz, it jumps to the new value in 98.4% of each frame. From a temporal perspective, the convergence speeds are equivalent—at 60Hz, it takes 2 frames (33.3 ms) to converge to approximately 99.5% of the new value ((1-0.876)² ≈ 0.015), while at 30Hz, it takes 1 frame (33.3 ms) to converge to 98.4%. At both frame rates, within the same 33.3 ms time window, the residual error ratios of the filter are similar (1.5% vs 1.6%), demonstrating the consistency of their temporal behavior.

[0043] If a fixed coefficient is used (e.g., fixed α=0.8), the frame rate jumps to the new value by 80% per frame at 60Hz, and also by 80% at 30Hz. However, the frame interval at 30Hz is twice that of 60Hz. This means that the filter at 30Hz performs only one step (residual 20%) within the same 33.3 milliseconds, while at 60Hz it performs two steps (residual 4%), resulting in a five-fold difference in filtering behavior. This difference manifests as a noticeably slower visual pointer response when switching from 60Hz to 30Hz, and the user will perceive the pointer as "sluggish" at the moment of frame rate switching. The adaptive formula eliminates this problem. VII. Interpreter Pattern Rendering Architecture

[0044] The visual rendering domain adopts the Interpreter Pattern architecture, which completely decouples "what to do" from "how to render": The first layer—FocReactiveState—is extracted and filtered from double-buffered data by the ReactiveStateManager. It includes normalized angle ([0, 2π)), normalized velocity ([-1, 1]), normalized rate ([0, 1]), response strength ([0, 1]), mode type, dead zone state, center angle, relative angle, and deviation. All fields are dimensionless normalized values, completely decoupled from specific hardware parameters (such as the number of LEDs, motor rated torque, and sensor resolution).

[0045] The second layer—the Interpreter: Each force feedback mode corresponds to a separate interpreter implementation. The interpreter receives a FocReactiveState and outputs an array of GeometryPrimitives. The GeometryPrimitive system defines three basic types: POINT type: Used to represent pointers, cursors, and pulse points. Each POINT primitive specifies a logical index position and an intensity value in the range [0, 1]. In this embodiment, the interpreter for each mode outputs two POINT primitives to achieve an anti-aliased two-point pointer—after mapping the independent angles of the LEDs to floating-point positions on the LED ring, the integer part and the next index are each used to generate a POINT primitive, with their respective intensities being (1 - interpolation factor) and the interpolation factor. When the pointer is exactly between two LEDs, the brightness of each of the two POINT primitives is approximately 0.5, producing a visually smooth effect of "being between two LEDs". ARC type (arc): Used to represent progress bars and energy bars. Specifies the starting logical index, arc length (number of LEDs), and intensity value. RING type (full ring): Used for full ring effects and speed indication. Covers the entire LED ring and specifies the overall intensity value.

[0046] The geometric primitive collection is stored using a fixed-size array (maximum capacity of 10 primitives) to avoid dynamic memory allocation on embedded platforms. The ReactiveGeometry struct provides the add() method to append primitives to the array; it returns failure when the array is full, without triggering memory allocation.

[0047] The third layer—the lighting effect renderer—receives an array of geometric primitives, combines the current color scheme (provided by the color palette service) and the lighting effect family configuration, and renders the primitives into the final CRGB color values. The renderer can apply post-processing effects to the primitives (such as Glow diffusion—when the brightness of an LED exceeds a preset threshold, it diffuses some brightness to adjacent LEDs, producing a soft halo effect). The core advantage of this three-tier architecture is that adding a new force feedback pattern only requires implementing a new interpreter class (inheriting the IReactiveInterpreter interface and implementing the interpret() method), which is then registered in the interpreter mapping table during initialization. No modifications to the lighting renderer or the reactive state manager are needed. Similarly, changing the LED hardware (e.g., upgrading from 6 LEDs to 24 LEDs) only requires adjusting the renderer's physical mapping parameters and topology configuration; the interpreter and reactive state manager remain unchanged. VIII. Inter-inhibition mechanism

[0048] When the force feedback knob is equipped with an audio signal source (such as a microphone or audio data transmitted from a host computer) for audio-visual lighting effects, there is a visual conflict between the control feedback lighting effect generated by the user operating the knob and the audio-driven visual lighting effect. The simultaneous driving of the LED ring by the two lighting effects will cause the pointer position to be interfered with by the audio beat pulse, and the user will not be able to clearly identify the current rotation position. The interaction suppression mechanism addresses this issue by detecting user interaction with a knob (pressing or rotating), whereby the torque control domain or button processing logic calls the suppression method `inhibitFor(duration_ms)` through the audio signal source's abstract interface. This method sets a suppression cutoff timestamp (current time + duration_ms). In the main loop processing of the audio signal source, if the current time has not exceeded the suppression cutoff timestamp, all spectrum analysis and event generation are skipped.

[0049] User experience: When the user rotates the knob, the LED ring only displays the control pointer and rotation feedback, without showing audio beat pulses or spectrum animations; approximately 500 milliseconds after the user releases the knob (typically the inhibitFor parameter value), the audio response lighting effect gradually resumes. The entire switching process requires no user intervention; the system automatically recognizes and switches the input. The audio signal source is integrated with the lighting system through an abstract interface (IAudioAnalyzer). This interface defines core methods for acquiring spectrum data, obtaining response status, popping up audio events, setting gain, resetting automatic gain control, temporarily suppressing audio response, and calibrating the microphone. The specific implementation of the interface can be a local MEMS microphone (acquiring audio data and performing FFT analysis via an I2S DMA interface), spectrum data transmitted back from a host computer via USB or Bluetooth, or a line-in audio signal. All implementations output spectrum data and response status in a uniform format; the lighting system only consumes these two standardized data structures and is completely unconcerned about the source of the audio data. 9. Adaptive Frame Rate Control

[0050] The visual rendering domain maintains a two-state frame rate control mechanism: Active state (60Hz) → Idle state (30Hz): Condition: More than 2000 milliseconds of inactivity since the last active timestamp (no rotation, no key presses, no audio events, no point pulses). Idle (30Hz) → Active (60Hz): Condition: Any non-zero velocity event, point pulse event, or audio event is detected. The switch takes effect immediately with no delay.

[0051] A 30Hz rendering frame rate is still higher than the human eye's perception threshold for flicker fusion of LED brightness changes (approximately 24Hz), meaning that static or slowly changing LED lighting effects will not exhibit visible flickering in idle states. Reducing the refresh rate from 60Hz to 30Hz can decrease CPU usage for LED rendering tasks by approximately 50%, freeing up processing time for other tasks running on the same core (such as Bluetooth communication and audio analysis). The engineering significance of a 2000ms activity timeout: The reason for choosing 2 seconds instead of shorter ones (such as 500ms) is that the typical interval between two user operations is 0.5-3 seconds (such as the pause for thought when scrolling through a list). A timeout that is too short would cause the frame rate to switch frequently during these intervals. Although the switch from 30Hz back to 60Hz is visually imperceptible, the frame rate switching itself triggers the recalculation of adaptive filter coefficients and the adjustment of the frame clock, increasing unnecessary computational overhead. A 2-second timeout ensures that a high frame rate of 60Hz is maintained throughout normal continuous operation. 10. Anti-aliasing processing for LED pointer rendering

[0052] When mapping independent LED angles to physical LED positions, all interpreters use the same anti-aliased two-point pointer rendering method: (a) Convert led_independent_angle from radians to a floating-point position on the LED ring: pointer_pos_f = (led_independent_angle / (2π)) × ring_led_count (b) Calculate the primary and secondary LED indices: pos0 = floor(pointer_pos_f) mod ring_led_count pos1 = (pos0 + 1) mod ring_led_count (c) Calculate the interpolation factor: interpolation = pointer_pos_f - floor(pointer_pos_f) (d) Generate two POINT primitives: POINT(pos0, intensity = 1.0 × (1 -interpolation)) POINT(pos1, intensity = 1.0 × interpolation) The second primitive is generated only when interpolation > 0.01 to avoid unnecessary rendering at extremely low brightness.

[0053] On a six-LED light ring, each LED covers a 60° arc. When the pointer is exactly between two LEDs (interpolation = 0.5), both LEDs are lit at 50% brightness. When the pointer is exactly aligned with one LED (interpolation < 0.01), only one LED is lit at 100% brightness. This rendering method achieves sub-LED-level angular indication accuracy on a low-resolution light ring with only six LEDs, allowing users to intuitively perceive the precise position of the pointer between two LEDs. XI. Cooperative operation with the torque control domain

[0054] The LED visual rendering domain obtains the knob state from the torque control domain through the FOC State Provider interface (IFocStateProvider). This interface defines a sample() method that returns a FocSample structure containing the angle, angular velocity, force feedback mode type, and dead zone state. The LED system actively calls `sample()` to sample during each rendering cycle (pull mode), rather than having the torque domain actively push events (push mode). The advantage of pull mode is that the rendering domain samples at its own frame rate, naturally achieving a frequency reduction from 200Hz to 30-60Hz without requiring additional rate limiting logic. If push mode is used, the torque domain will generate 200-1000 events per second and push them into the message queue, while the rendering domain only consumes 30-60 per second. This will cause the queue to continuously accumulate events, eventually overflowing or causing latency.

[0055] The state data (angle, speed, mode type) of the torque control domain is transmitted to the LED system through a double buffer structure: the 200Hz main loop writes to the write buffer and sets a volatile dirty flag. After the LED task detects the dirty flag, it copies the entire write buffer to the read buffer, thereby realizing the down-frequency transmission of 200Hz sampling data to the 30-60Hz rendering frame rate without blocking the main loop. Mode switching events are transmitted from the torque control domain to the visual rendering domain via the FreeRTOS message queue (LED task message queue, 16 messages deep). Message types include discrete events such as FOC mode switching (FOC_MODE_CHANGE) and point pulse (FOC_DETENT). The message queue complements the double buffer—the double buffer transmits high-frequency continuous states (angle, speed), while the message queue transmits low-frequency discrete events (mode switching, button presses). XI. Supplementary Note: Design-based handling of domain isolation across domain boundaries and high-frequency overwriting

[0056] It is important to note that the asynchronous back-center animation in the visual rendering domain and the operation of the LED independent coordinate system in this invention maintain strict domain isolation from the torque calculation and event sending logic in the torque control domain. Specifically: The LED angle state variable (LED independent angle) in the visual rendering domain exists only in the memory space of the visual rendering domain. The torque calculation function and event sending function in the torque control domain do not reference, depend on, or modify this variable. Conversely, the animation logic and coordinate system update logic in the visual rendering domain also do not reference, depend on, or modify the torque target value or event queue content in the torque control domain. The only data channel between the two domains is a double-buffering mechanism—the torque control domain transmits the physical state information (angle, angular velocity, mode type) of the knob unidirectionally through the write buffer, while the visual rendering domain passively receives it through the read buffer. This unidirectional read-only data flow design ensures that no operation in the visual rendering domain (including pausing physical angle updates during centering animation) can negatively affect the torque calculation accuracy and event sending timing of the torque control domain.

[0057] Regarding the design handling of high-frequency overwriting scenarios: When the torque control domain writes data to the write buffer at a frequency of 200Hz to 1000Hz, while the visual rendering domain only reads at a frequency of 30Hz to 60Hz, the data in the write buffer will be overwritten multiple times by the torque control domain between the two reads. This loss of intermediate frames is a design behavior of the architecture, not a defect—the visual rendering domain always reads the complete state data most recently written by the torque control domain (latest frame strategy), and for LED rendering at 30Hz to 60Hz, the lost intermediate frames have no perceptible impact on the visual effect. In extreme scenarios (such as operating system interruptions causing delays of tens of milliseconds in the visual rendering domain), the write buffer may be overwritten hundreds of times, but the write operation of the torque control domain is not affected in any way (only two non-blocking assignment operations), and the visual rendering domain immediately reads the latest frame after resuming operation, and the visual pointer position is automatically synchronized to the current physical state, requiring no recovery logic. XII. Alternative Implementation Methods

[0058] Those skilled in the art will understand that the above-described specific embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Without departing from the core concept of the present invention (LED independent coordinate system + asynchronous return animation + double-buffered lock-free cross-domain communication), the following alternative embodiments all fall within the scope of protection of the present invention: (1) Alternative implementation of LED coordinate system The maintenance of the LED independent angle state variables is not limited to offset calculations based on a physical zero-point reference. Alternative methods include using an independent cumulative angle counter (not associated with the physical angle, only accumulating angle increments) and using a virtual angle sensor (simulating an angle signal source completely independent of the physical sensor within the visual domain). All alternative methods share the characteristic that the visual indication position of the LED ring is determined by independent state variables within the visual rendering domain, without directly referencing the raw readings of the physical angle sensor. (2) Alternative implementation of the return-to-center animation The easing function is not limited to the cubic ease-out function (easeOutCubic). Alternatives include the quadratic ease-in ease-out function (easeInOutQuad, which accelerates first and then decelerates), elastic easing functions (overshoot followed by rebound), linear interpolation, cosine interpolation, or a custom Bézier curve. The animation duration is not limited to the 300-700 millisecond range and can be adjusted from 50 milliseconds to 2000 milliseconds depending on application requirements. All alternatives share the common characteristic that the LED angle gradually transitions from the current position to the target position, rather than abruptly changing. (3) Alternative implementation of cross-domain communication The communication method for the double-buffered volatile dirty flag is not limited to the simple single-writer, single-reader model. Alternative methods include FreeRTOS queues (xQueueSend / xQueueReceive, providing inherent thread safety but potentially introducing minor blocking latency), circular buffers (supporting lock-free FIFOs with multi-level buffering), shared memory with semaphores (synchronizing access to shared data areas via binary semaphores), or a triple buffer mechanism (where the writer writes to the current buffer, the renderer reads the previously completed buffer, and the third buffer serves as an intermediate state, completely eliminating the possibility of partial copying). All alternative methods share the characteristic that write operations to the torque control domain are not blocked by read operations to the visual rendering domain, and the visual rendering domain can obtain the latest state data of the torque control domain at its own frame rate. (4) Alternative implementations of the interpreter architecture The geometric primitive system is not limited to the three types: POINT, ARC, and RING. Alternatives include richer primitive types (such as gradient bar primitives, Bézier curve primitives, and particle effect primitives) or direct pixel-level output (the interpreter directly outputs the CRGB color value of each LED, skipping the primitive abstraction layer). The interpreter routing method is not limited to static mapping based on mode type (each mode registers a corresponding interpreter); alternatives include dynamic routing based on a rule engine or priority-based multi-interpreter overlay (running multiple interpreters simultaneously and mixing their output primitives according to priority). All alternatives share the common feature that the interpretation logic of physical input is separated from the visual presentation logic, and adding new force feedback modes does not require modification of the existing rendering logic. (5) Alternative implementation of adaptive filter coefficients The adaptive formula α = 1 - exp(-Δt / τ) based on exponential decay is not limited to this specific mathematical form. Alternative methods include linear interpolation α = min(1.0, Δt / τ), piecewise linear functions, or lookup tables based on the sampling rate. All alternative methods share the common characteristic that the filter coefficients are dynamically adjusted according to the actual time increment of each frame, ensuring that the temporal response characteristics of the filter remain consistent as the frame rate changes. (6) Alternative implementation of frame rate control The dual-state frame rate control (60Hz / 30Hz) is not limited to switching between two fixed frame rates. Alternative methods include multi-level frame rates (such as four levels: 60Hz / 45Hz / 30Hz / 15Hz), continuously variable frame rates (dynamically calculating the target frame rate based on the current rendering load and activity intensity), or adaptive frame rates based on content change rate (reducing the frame rate when the color change of the LED ring is below the threshold perceptible to the human eye). (7) Alternative configurations for LED hardware The ring-shaped LED light ring is not limited to 6 RGB LEDs. Alternatives include ring arrays of 12, 24, 48, or more LEDs, or non-ring-shaped LED arrays (such as linear or matrix arrangements). The LED type is not limited to RGB LEDs; alternatives include RGBW LEDs (with an added independent white light channel) or monochrome LEDs. The abstraction layer design of the interpreter architecture ensures that changes in the number and arrangement of LEDs only affect the final rendering layer, without affecting coordinate system management, animation logic, or interpreter implementation. (8) Alternative types of torque actuators The torque actuator is not limited to a brushless DC motor. Alternatives include any electromagnetic or piezoelectric actuator capable of outputting controllable torque, such as a brushed DC motor, voice coil motor, stepper motor, or piezoelectric motor. (9) Alternative types of event output interfaces The event output interface is not limited to a USB HID interface. Alternatives include Bluetooth Low Energy HID interfaces, 2.4GHz proprietary wireless protocol interfaces, Wi-Fi interfaces, or other standard human-machine interface device protocol interfaces. The LED visual feedback control method is independent of the specific transmission interface type. (10) Alternative implementation of audio signal source The specific implementation of the audio signal source interface is not limited to a MEMS microphone audio analyzer. Alternative methods include a spectrum data analyzer sent by the host computer via USB or Bluetooth, an analog line input audio analyzer, or no audio signal source configured at all (in which case the interaction suppression mechanism is not enabled, and the lighting system only responds to knob operation input). The specific signal processing link of the audio signal source (such as FFT transformation, automatic gain control, beat detection, etc.) belongs to the existing technology in the field of audio analysis, and its specific implementation does not affect the core technical solutions of the present invention, namely the LED independent coordinate system, asynchronous back-center animation, and cross-domain double-buffered communication.

Claims

1. A visual feedback control method for an LED independent coordinate system of a force feedback knob, applied to a force feedback knob device having a torque actuator, an angle sensor, and a ring-shaped LED light ring, the device comprising a torque control domain for running force feedback control logic and a visual rendering domain for running lighting effect rendering logic, characterized in that, include: LED Independent Coordinate System Establishment: The visual rendering domain maintains an LED angle state variable independent of the physical angle sensor reading. The LED angle state variable uses a physical zero-point reference as a reference to map the physical angle change of the knob to the visual indication position on the LED ring. The physical zero-point reference is anchored to the physical angle value at the time of the first activation of the force feedback mode, so that the subsequent repositioning operation of the torque reference center position in the torque control domain only changes the torque calculation parameters and does not affect the physical zero-point reference and the visual indication position. Asynchronous centering animation: When the torque reference center position in the torque control domain undergoes a non-progressive repositioning, and there is a deviation between the LED angle state variable and the target angle position, the visual rendering domain initiates a progressive centering animation with an easing function to smoothly transition the LED angle state variable from its current value to the predetermined target angle position value; during the animation execution, the output of the progressive centering animation serves as the sole source of value for the LED angle state variable, replacing the updated value calculated based on the physical angle; the current value of the LED angle state variable drives the visual indication rendering of the ring LED light ring; Cross-domain double-buffered communication: In each torque control cycle, the torque control domain writes the knob angle, angular velocity, force feedback mode type, and dead zone state to a write buffer, and marks the existence of unread new data in the write buffer through a data update notification mechanism with cross-domain write visibility guarantee; In each rendering cycle, the visual rendering domain checks the data update notification mechanism to determine whether new data exists. If it does, the read buffer obtains the complete data content of the write buffer and updates the synchronization state of the data update notification mechanism to mark the reading as complete; The torque control domain and the visual rendering domain operate independently at their respective frequencies, and the write operation of the torque control domain will never be blocked by the read operation of the visual rendering domain.

2. The method according to claim 1, characterized in that, The specific calculation method for the LED angle state variable is as follows: When the force feedback mode is a force feedback mode with a torque reference center position and is not during the return animation execution: with the physical zero point reference as a reference, calculate the angle difference between the current physical angle of the knob and the physical zero point reference, and standardize the angle difference to the range of [0, 2π) as the value of the LED angle state variable; When the force feedback mode is a force feedback mode without a torque reference center position: calculate the offset of the current physical angle of the knob relative to the physical zero point reference, then calculate the shortest annular angle difference between the offset and the current value of the LED angle state variable, multiply the shortest annular angle difference by the mode-related smoothing coefficient, and then add it to the LED angle state variable; the smoothing coefficient is a preset value between 0.7 and 0.9 for the high-speed rotation mode to provide fast following, and a preset value between 0.2 and 0.4 for other modes to provide smooth transition; The physical zero-point reference is anchored to the physical angle value at the time of the first activation of the force feedback mode with the torque reference center position; When the torque control domain performs a non-progressive repositioning of the torque reference center position, the physical zero-point reference is synchronously updated to the new torque reference center angle, so that the LED angle state variable remains numerically continuous before and after repositioning.

3. The method according to claim 1, characterized in that, The specific execution steps of the progressive return-to-center animation are as follows: The current value of the LED angle state variable at the start of the animation is the starting angle, and the target angle of the animation is set to the zero point position; Calculate the shortest path distance and direction from the starting angle to the target angle in the annular space [0, 2π). The animation duration is calculated based on the shortest path distance, and the duration is equal to a preset base time plus a distance normalization value multiplied by a preset maximum additional time. The distance normalization value is the absolute value of the shortest path distance divided by π; In each rendering cycle, the current time progress is calculated and an easing function is applied to obtain the easing progress value; the starting angle and target angle are interpolated using the easing progress value to calculate the LED angle of the current frame, and the result is standardized to the range [0, 2π) and then written into the LED angle state variable; After the animation is complete, the LED angle state variable is precisely set to the target value, the animation activity flag is cleared, and the normal LED angle update logic based on physical angle is restored.

4. The method according to claim 3, characterized in that, The easing function is a cubic easing-out function: eased_progress = 1 - (1 - progress)³ Where progress is a linear time progress, with a value range of [0, 1]; the base time is a preset value between 200 milliseconds and 500 milliseconds; and the maximum additional time is a preset value between 200 milliseconds and 600 milliseconds.

5. The method according to claim 1, characterized in that, The write buffer is a data structure containing the following fields: angle value, angular velocity value, force feedback mode identifier, dead zone status flag, point pulse flag, point pulse intensity, and timestamp. The torque control domain runs in the high-frequency main loop of the microcontroller, with an execution frequency of 200Hz to 1000Hz; the visual rendering domain runs in an independent real-time operating system task, with a rendering frequency of 60Hz in the active state and 30Hz in the idle state; the execution frequency of the torque control domain is at least 3 times the rendering frequency of the visual rendering domain.

6. The method according to claim 1, characterized in that, The visual rendering domain also includes an adaptive frame rate control mechanism: Maintain the last activity timestamp; update the timestamp when a non-zero velocity event or point pulse event is detected; When the difference between the current time and the timestamp is less than the preset activity timeout, rendering is performed at a high frame rate; when the time difference exceeds the activity timeout, rendering is automatically reduced to a low frame rate. The activity timeout is a preset value between 1000 milliseconds and 3000 milliseconds; the high frame rate is a preset value between 50Hz and 120Hz; and the low frame rate is a preset value between 20Hz and 40Hz.

7. The method according to claim 1, characterized in that, The visual rendering domain also includes adaptive filtering coefficient calculation: Independent low-pass filters are maintained for the LED angle state variable and angular velocity, and the filter coefficients of the filters are dynamically calculated based on the actual time increment of each frame according to the following formula: α = 1 - exp(-Δt / τ) Where Δt is the actual time interval between the current frame and the previous frame, and τ is a preset filtering time constant; the time constant of the angle filter is a preset value between 5 milliseconds and 15 milliseconds; the time constant of the speed filter is a preset value between 8 milliseconds and 20 milliseconds; the adaptive calculation ensures that the temporal response characteristics of the filter remain consistent before and after frame rate switching.

8. The method according to claim 1, characterized in that, The visual rendering domain also includes a lighting rendering pipeline based on an interpreter-mode architecture: A corresponding interpreter is registered for each force feedback mode. The interpreter receives a response state snapshot containing normalized angle, normalized velocity, normalized rate, response intensity, mode type, and dead zone state, and outputs geometric primitives that are independent of specific LED hardware. All fields in the response state snapshot are dimensionless normalized values. The geometric primitives include at least point type, arc type and complete ring type, and each primitive carries logical index, intensity and length information; the geometric primitive set is stored using a fixed-size array to avoid dynamic memory allocation; The lighting effect renderer receives the set of geometric primitives, combines the current color scheme and material parameters, and renders the geometric primitives into the final LED color values; adding a new force feedback mode only requires implementing the corresponding interpreter, without modifying the lighting effect renderer.

9. The method according to claim 1, characterized in that, It also includes interaction inhibition mechanisms: When it is detected that the user is operating the knob, the suppression method is called through the abstract audio signal source interface to set a suppression period of preset duration; During the suppression period, the audio signal source pauses generating audio events and updating response status, allowing the lighting system to focus on displaying visual feedback from the knob interaction; after the suppression period ends, the audio signal source automatically resumes normal operation. The audio signal source interface is an abstract interface, and its specific implementation includes at least one of the following: audio acquisition by the local microphone, audio spectrum data transmitted back by the host computer through a wired or wireless interface, or line input audio signal.

10. A force feedback knob with an LED independent coordinate system visual feedback control system, characterized in that, include: The microcontroller has multi-task scheduling capabilities; A torque actuator, electrically connected to the microcontroller, is used to output torque to provide tactile feedback; An angle sensor is used to detect the rotation angle and angular velocity of the knob and output the detection results to the microcontroller; A ring of LED lights, arranged around the knob, is used to display visual feedback; An event output interface is used to send the control events generated by the microcontroller to the target device; The microcontroller is configured with a torque control domain and a visual rendering domain, and runs the method of any one of claims 1 to 9. In the torque control domain, force feedback control logic is run, and in the visual rendering domain, an LED coordinate system independent of the physical angle sensor readings is maintained and lighting effect rendering logic is run. The two domains communicate through a double-buffered mechanism with a data update notification mechanism that guarantees cross-domain write visibility and do not block each other. The torque actuator is a brushless DC motor. The microcontroller uses a dual-core processor, and the torque control domain and the visual rendering domain run on different processor cores.

Images