WP5-11 ACO
| ID | WP5-11-ACO |
| Contributor | ACORDE |
| Levels | Platform, Function |
| Require | GLAD+ platform WP3-15_2 |
| Provide | Navigation data (position, attitude, velocity) |
| Input | Specific messages from underlying GNSS receivers. |
| Output | Jamming and spoofing detection via the user API and Mavlink API |
| C4D building block | (see WP3-15_2 ) |
| TRL | 4 |
| Parent Building block | WP3-15_2 |
| Contact | fernando.herrera@acorde.com |
Description
One activity of ACORDE in WP5 of COMP4DRONES has been to enable anti-jamming and anti-spoofing capabilities to its low-cost geo-referenced outdoor positioning and attituded estimation solution, i.e. GLAD+ WP3-15_2.
The challenge tackled has been to enable such a feature in a way that:
- hold the low-cost of the solution
- enabled a smooth integration
How
ACORDE has achieved this by tackling the following actions:
- designing and implementing a novel hardware platform that integrates low-cost GNSS receivers with anti-jamming and anti-spoofing capabilities
- at the SW platform level, specific drivers have been developed which enable the positioning application to configure the detection and detect both spoofing and jamming events.
- application-level API has been also enabled. Moreover, a Mavlink semantic extension has been proposed to enable a Mavlink base integration able to transfer spoofing/jamming event information.
Figure below sums up these actions:
The figure below shows the definition of the ESTIMATOR_STATUS Mavlink message.
The semantics of this message has been smoothly widen to provide the quality information on the positioning parameters. The expressive power of the ESTIMATOR_STATUS message has been improved, by defining extra ranges within the default invalid range (1.0<V) of theinnovation test ratio field. These ranges provide additional information on the root causes of the abnormal measurement. An additional benefit of the proposed extension is that it maintains backward compatibility with existing MAVLink integrations.
Evaluation
The evaluation performed consisted in verifying that the enablinh/diabling and configuration of the spooging and jamming capabiltiies could be done, and that their correspondign detection events were correctly send to the navigation application and to the user level interfaces.
The configuration through a simple .ini file was tested, as illustrated in the following figure:
(via this file takes effect, different configurations were performed, with their later corresponding runs of GLAD+ application on the HW platform upgraded during the COMP4DRONEs project. For these experiments, GLAD+ application debug traces where enabled. These traces enable the application to dump the spoofing and jamming status obtained from the driver-level API. In this way, from the configuration of Figure 3, a log whose excerpt is shown in Figure 4 was produced. The log shows how the anti-jamming and anti-spoofing features are disabled, as was configured.
A different case was configured as shown in Figure 5, to enable both anti-spoofing and anti-jamming features. The corresponding debug traces are shown in Figure 6.
Again, the debug traces of GLAD+ software provide different information, but consistent with the new configuration. Specifically, it provides the novel detection status of both spoofing and jamming events (enabled), plus additional information, i.e. that a jamming status is detected. This is explainable because this experiment was performed in a semi-indoor (with a dumped GNSS signal) noisy environment.
Moreover, a bit more detailed look to the debug log, shows that the specific jamming status report correspond to a “low-level” jamming. This corresponds to a jamming level which could eventually yet correspond to a valid (worse quality) position, in contrast to a high-level jamming event, which would immediately cause an invalid fix on the application.