Multipath Image Object Generation

Description

This describes the implementation of the "image method" used in FERS to simulate single-bounce specular reflection multipath. It works by creating "dual" Transmitter and Receiver objects. These dual objects are placed at positions corresponding to the geometric reflection of the original objects across the defined multipath surface (Multipath Surface Definition). Their motion and orientation paths are also derived by reflecting the original platform's path coordinates point-wise. The core simulation logic then treats these dual objects like regular simulation entities, allowing paths like RealTx -> Target -> DualRx to be calculated, representing a reflected path. This relies on the principle that waves reflected from a flat surface appear to originate from a mirror image source.

Assumptions

• Assumes that reflecting the individual waypoints or start/rate parameters of a path and then interpolating between these reflected points accurately models the true reflected path geometry. This is generally true for static or linear paths but an approximation for higher-order interpolation like cubic splines.
• Assumes the MultipathSurface::reflectPoint function correctly performs the geometric reflection calculation for both position vectors and direction vectors across the defined plane.
• Assumes the internal conversions between Cartesian coordinates (used for reflection) and Spherical coordinates (potentially used for rotation representation) are correct.
• Assumes that simply copying the constant angular rotation rates (RotationPath::_start, _rate) from the original object to the dual object is a physically correct representation of the reflected rotation (this is highly questionable from a kinematics perspective).

Limitations

• Python Path Incompatibility: Platform positional paths defined using external Python scripts (Positional Path (Python)) cannot be reflected using this method; the simulation will likely throw an error if attempted.
• Constant Rotation Reflection: The reflection logic for RotationPath objects using INTERP_CONSTANT (fixed rate) appears incorrect. It copies the original angular rates directly instead of reflecting the axis of rotation and adjusting the rates accordingly, which doesn't match physical reflection.
• Cubic Path Reflection Accuracy: Reflecting the control points of a cubic spline path does not necessarily yield the exact cubic spline path of the true geometric reflection. This introduces potential inaccuracies for platforms following complex curved paths.
• Rotation Interpolation Accuracy: The interpolation between reflected RotationCoord waypoints uses basic element-wise interpolation, which does not guarantee the shortest path or constant angular velocity on the sphere and may introduce inaccuracies for complex rotations.
• Single Bounce Only: This mechanism inherently models only single-bounce specular reflection from the one defined surface. It does not support multiple bounces or reflections from multiple different surfaces.
• Increased Object Count: Creates additional Platform, Transmitter, and Receiver objects in the simulation (World), potentially doubling the number of entities and increasing computational load.

Related Components

• Mechanism: radar_obj.cpp::createMultipathDualBase<T> (Template function for creating Tx/Rx duals)
• Mechanism: platform.cpp::createMultipathDual (Function for creating Platform duals)
• Path Logic: path.cpp::reflectPath, rotation_path.cpp::reflectPath (Core geometric reflection for paths)
• Internal State: Radar::setDual, Platform::setDual (Methods storing pointers to dual objects)
• Configuration: Multipath Surface Definition
• Simulation Use: Simulation of Reflected Paths via Duals, Reflection Factor Application
• Object Model: Multipath Dual Object Creation, Radar Object Hierarchy
• Motion Models: Positional Path (Waypoints), Rotational Path (Waypoints), Rotational Path (Fixed Rate)

Validation Status

• Needs Verification: The core assumptions about path reflection accuracy (especially for cubic position and all rotation types) require rigorous testing. The handling of constant rotation rates needs confirmation of its (likely incorrect) behavior. Error handling for Python path reflection attempts should be verified.
• Key Areas for Validation:
  • Geometric accuracy of reflected waypoints and interpolated paths (linear, cubic) vs. analytical solutions for simple geometries.
  • Accuracy of reflected orientation, especially for constant rate rotation and interpolated waypoints. Compare against expected kinematic behavior.
  • Verify that attempting to reflect a Python-based positional path results in a clean error or expected failure, not undefined behavior.
  • Confirm that only single-bounce paths involving one dual object (e.g., Tx->Tgt->DualRx or DualTx->Tgt->Rx) are generated and simulated, not double-dual paths (DualTx->Tgt->DualRx) which would violate the single-bounce model.
• Priority: Medium-High (Incorrect geometry significantly impacts multipath simulation results, which rely directly on propagation paths derived from these positions/orientations).