|
Autoware.Auto
|
|
Some algorithms or components have an implicit assumption of having (reasonably) a smoothly varying input signal. Another way to view this is that a component might have an undesirable response to different frequency domains.
To avoid these undesirable responses, it is important to use a filter (in the signal processing sense) to reject, remove, or attenuate certain frequencies within a signal.
A simple interface is provided. Implementations of this interface are assumed to be stateful and discrete-time.
The API can be seen in the API docs.
The base class has some input sanitation logic so that implementations need not reimplement this logic.
In addition, standard polymorphism is used for ease of use. This is rationalized by the idea that these filters are intended to work with the vehicle interface on data arriving at most 100 Hz. If these filters are needed to work on data at a higher rate, then the child classes should directly be used or a specialized filter intended for speed should be implemented.
Filters take in a Clock template argument. The purpose of this is two-fold:
A duration-based API and a time_point-based API are provided (exclusive to one another) in order to support different use cases a user might have.
This API currently assumes a 1D output, and a 1D input.
If a multidimensional input or output is desired, then a different API should be provided, or the provided API should be extended.
Implementations of this interface are assumed to be stateful and discrete-time.
The API can be seen in the API docs.
Currently, this package only contains an interface definition with no logic.
The base class ensures the following invariants hold true:
Use of SFINAE prevents the user from mixing API calls, possibly leading to the filter being in an inconsistent state.
Care is also made to ensure modifications to the program state occurs only after exception logic to provide strong exception guarantees.
TBD by a security specialist
Modern filters include: