-
Notifications
You must be signed in to change notification settings - Fork 2
Description
All runtime sensing today assumes perfect observability of targets. Guidance, evasion, and evaluation logic therefore receive exact range/angle/velocity transforms every frame. How can we model realistic sensor non-idealities and degradation?
Current system
Sensor configs only expose an IDEAL type and frequency, so we cannot describe noise magnitudes, dropout behavior, or occlusion handling in data.
IdealSensor simply mirrors the agent-to-target Transformation into the output without modification, yielding zero-error measurements at any distance.
Higher-level behaviors such as OrthogonalEvasion read Agent.Sensor.Sense(...) each frame and assume the result is valid, so there is no mechanism to detect or react to occluded or stale tracks.
The only randomness that exists in the simulator is injected into initial conditions
Desired non-ideal sensing
Extend Simulation.SensorType with new options. SensorConfig might carry parameters like:
- per-axis noise parameters
- dropout probabilities
- occlusion layer masks
Introduce a NonIdealSensor : SensorBase that samples noise, clamps impossible results, maintains the last valid track, and emits flagged measurements when line-of-sight is obstructed or a dropout occurs.
Add an occlusion service (e.g., Physics.Raycast/SphereCast with configurable margin) that ignores the sensed agent’s colliders and uses a layer mask to identify terrain and structures to block the beam.
We may need to extend SensorOutput to include metadata that some sensors are capable of producing like validity/occlusion flags, timestamps, and covariance so downstream systems can more interestingly adapt to degraded measurements
Implementation notes
- Reuse or extend
Utilities.GenerateRandomNoiseto support spherical noise, correlated components, and reproducible seeding. - Occlusion checking with raycasting will be pretty nasty expensive at our scale. We might want to cache per-frame raycast results or use layer-based exclusion to keep occlusion checks scalable. Would be a good idea to somehow profile the sim performance before and after the changes.
- Useful to emit sensed measurements (value, validity, occlusion cause) via
SimMonitor?
Open questions
- Should occlusion trigger a hard dropout, inflate measurement noise, or both (configurable)?
- Do we need per-agent override of occlusion masks/layer lists to model different sensor apertures?
- How should sensor frequency gating interact with ad-hoc
Sensecalls from controllers. Would we buffer latest sample or throttle the callers one layer higher in the abstraction