RTLinux-Based FAST Feed Cabin Fine-Tuning Control System

RTLinux-Based FAST Feed Cabin Fine-Tuning Control System

🧭 Overview

#

Precise positioning of the feed cabin in the Five-hundred-meter Aperture Spherical radio Telescope (FAST) is a hard real-time control problem requiring strict timing guarantees and sub-millimeter-level stability.

This system implements a real-time secondary fine-tuning control architecture on RTLinux, combining interrupt-driven execution, deterministic scheduling, FIFOs, and shared physical memory to maintain feed vibration within 4 mm using a Stewart platform.

📡 Control Requirements of the FAST Feed Cabin

#

The FAST feed cabin is suspended at approximately 150 m height using a cable-driven support system. While effective for large-scale positioning, this mechanism alone cannot suppress high-frequency disturbances such as wind-induced motion.

To achieve fine positioning, a Stewart parallel mechanism is used:

• Upper platform: connected to feed cabin
• Lower platform: supports feed payload
• Six actuators: control 6-DOF motion

Core Real-Time Tasks

#

Each control cycle must execute the following sequential operations:

• Cabin pose acquisition
• Trajectory prediction under dynamic disturbance
• Real-time target tracking
• Optimal trajectory planning
• Actuator command generation

All operations are strictly periodic and time-constrained. The system must maintain feed stability within 4 mm, even when cabin displacement reaches 50 cm.

⚙️ RTLinux as the Real-Time Control Platform

#

The system requires deterministic scheduling with microsecond-level latency control. Several platforms were evaluated:

• DOS

  • Direct hardware access but no multitasking
  • Severe memory and architectural limitations

• Windows/NT

  • Enhanced with VxD and threading models
  • Still lacks deterministic real-time guarantees

• RTLinux

  • Hard real-time microkernel beneath Linux
  • POSIX-compliant real-time API support
  • Interrupt isolation from Linux kernel
  • Typical interrupt latency < 15 µs
  • Task jitter often < 35 µs (sub-µs on optimized x86 systems)

RTLinux was selected due to its hybrid architecture, deterministic behavior, and open-source flexibility.

🏗️ System Architecture

#

RTLinux separates execution into two domains:

• Real-Time Domain

  • Pose acquisition
  • Prediction and trajectory computation
  • Actuator control
  • Exception handling

• Linux (Non-Real-Time) Domain

  • HMI interface
  • Logging
  • Network communication

This strict separation ensures that non-critical workloads cannot interfere with deterministic control execution.

⏱️ Timing Model and Control Synchronization

#

The system is driven by a hardware interrupt clock from a servo motion control card:

• Base interrupt period: 2 ms
• Full control cycle: 100 ms (50 interrupts)

Control Strategy

#

A synchronized timing strategy ensures actuator motion remains aligned with predicted cabin dynamics:

• Measurement and prediction share a 100 ms cycle
• Actuation is subdivided into 2 ms steps
• A calibrated 2 ms offset compensates computation delay

This ensures linearized actuator response across each cycle.

Execution Flow

#

• Hardware interrupt triggers ISR
• ISR checks control flag state
• If enabled:
  • Launch measurement/prediction thread
• Thread computes trajectory then suspends
• Next interrupts generate actuator outputs every 2 ms
• Cycle repeats every 100 ms

This design guarantees deterministic execution with bounded jitter.

🔄 Inter-Domain Communication

#

Communication between real-time and non-real-time subsystems is implemented using two mechanisms:

FIFO Channels

#

• POSIX-compliant unidirectional streams
• Used for:
  • Command output
  • HMI data transfer
• Throughput: up to ~100 MB/s

Shared Physical Memory

#

• Bidirectional low-latency communication
• Used for:
  • Pose targets
  • System status flags
  • Control synchronization variables

This hybrid design avoids unnecessary copying while preserving real-time determinism.

⚡ Interrupt-Driven Control Implementation

#

The core scheduling mechanism is implemented entirely in the RTLinux ISR layer.

ISR Behavior

#

// ISR (hardware interrupt handler)
pthread_create(...);   // spawn measurement & prediction thread

Real-Time Thread Behavior

#

// Real-time control thread
pthread_suspend_np(pthread_self());

Execution Semantics

#

• ISR triggers every 2 ms
• Measurement/prediction executes within a bounded time window (< 2 ms)
• Thread suspends after computation
• Next interrupt resumes actuator output phase
• Entire pipeline repeats every 100 ms

This guarantees:

• No missed deadlines
• No cumulative drift
• Deterministic scheduling under load

📊 System Performance Characteristics

#

Validated on a 1:5 scale experimental platform, the system demonstrates:

• Sub-4 mm feed vibration control accuracy
• Stable tracking under wind-induced disturbances
• Deterministic execution with bounded jitter
• Reliable real-time scheduling under continuous load

Key outcomes:

• Strict timing guarantees maintained via hardware interrupt clock
• Predictable actuator synchronization with cabin motion
• Robust separation of control and non-real-time subsystems

✅ Conclusion

#

The RTLinux-based FAST feed cabin fine-tuning system demonstrates that hard real-time control of large-scale astronomical structures can be achieved using:

• Hardware-interrupt-driven scheduling
• Interrupt-driven real-time threads
• FIFO-based communication channels
• Shared physical memory for synchronization

This architecture delivers deterministic performance and sub-millimeter-level stability, meeting the stringent requirements of the FAST telescope feed positioning system.