Septentrio: Add GNSS resilience reporting #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[`Tools/ros2/ardupilot_dds_tests/test/test_pep257.py`](https://github.com/ArduPilot/ardupilot/blob/master/Tools/ros2/ardupilot_dds_tests/test/test_pep257.py) ensures [PEP 257 – Docstring Conventions](https://peps.python.org/pep-0257) compliance for all Python files in Tools/ros2. Partially addresses the concern at * ArduPilot#30426 (comment) Here are two solutions (we should pick just one) that replicate this functionality in pre-commit. 1. Use `flake8` plus `flake8-docstring` to run the 'ament-style` rules on Tools/ros2. 2. Run [`ament_pep257`](https://pypi.org/project/ament-lint-pep257) on Tools/ros2. Quick equivalent commands: ``` uv tool run --with=flake8-docstrings flake8 --select=D \ --ignore=D100,D101,D102,D103,D104,D105,D106,D107,D203,D212,D404 Tools/ros2 uv tool run --from=ament-lint-pep257 ament_pep257 Tools/ros2 > /dev/null ``` How was this tested? 1. Run both equivalent commands to ensure no errors. 2. `pre-commit run flake8 --all-files` to ensure no errors. 3. `pre-commit run ament-pep257 --all-files` to ensure no errors. Edit `Tools/ros2/ardupilot_sitl/src/ardupilot_sitl/utilities.py` and add a leading or trailing space inside the docstring, and save the file. Rerun the four commands to ensure that each raises a `D210: No whitespaces allowed surrounding docstring text` error.
needed for non-blocking TCP connections
allows for non-blocking TCP connections
Bit 0's description accidentally got deleted
* https://github.com/ArduPilot/Micro-XRCE-DDS-Gen/releases/tag/v4.7.1 * Fixes race in generator that causes often CI failures Signed-off-by: Ryan Friedman <25047695+Ryanf55@users.noreply.github.com>
Signed-off-by: Ryan Friedman <25047695+Ryanf55@users.noreply.github.com>
This currently does not work, in particular resulting in scripting raising an internal error on stop because it doesn't think all the memory is freed because the allocated counter doesn't start out at zero because the zero on allocation behavior is broken. Cygwin has some support for overriding `malloc` (https://cygwin.com/faq/faq.html#faq.programming.own-malloc), but when this is attempted some logic in the runtime detects this case then forwards all allocator calls (`free`/`calloc`/etc.) to the user provided allocation functions. If only `malloc` is overridden, the other functions just call themselves recursively until the stack overflows. There is no supported way to use the original Cygwin allocator while overriding `malloc`, but we do not want to include our own allocator just for Cygwin. Fortunately, in some sense, there is an unsupported way, and our goal can be achieved by overwriting an internal pointer with our `malloc` implementation after the Cygwin runtime logic checks and believes that no overwrite has occurred, thereby never enabling the redirection and allowing non-`malloc` functions to still work. Our version then calls `calloc` to do the allocation and zeroing. Note that the old wrap of `_malloc_r` was faulty as that symbol is no longer used by newlib; it's just `#define`d to `malloc` these days. Tested that at least the scripting issue is fixed by failing to replicate it, plus tracing execution with `gdb` to confirm that our wrapper function is executed and does its job. The correct solution is to not make ArduPilot call `malloc` at all. We still cannot safely change the semantics to make it returned zeroed memory. This is quite the hack!
This is now accomplished at runtime, and the wrap of `_malloc_r` never worked properly anyway.
was getting "None" in the argument list
may not be able to write into the previous directory (eg. on Vagrant VMs which have the checkout at /vagrant)
the device only actually has a single IMU. Three was forced to ensure that the move to being entirely hwdef.dat-based was binary-output-identical
Ensure that ppp install succeeded and the binary executes directly after install, instead of failing deep in the test suite.
AP_Periph has a lot of trouble sending various messages... so guard more of them. Past this we don't get the "sending unknown message ID messages over MAVLink
Tory9
force-pushed
the
pr-resilience3
branch
from
b01f2a9 to
c89ee9e
Compare
…moved to STREAM_EXTRA3
…link_gnss_integrity changed accordingly
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR implements support for collecting GNSS resilience data from Septentrio receivers and relaying it to the Ground Control Station.
Why is this change needed?
GNSS resilience information—such as spoofing, jamming, and authentication states—is crucial for operational safety and informed decision-making. Providing this data to the GCS enhances an operator's situational awareness, allowing for better flight planning and in-flight control.
How is it implemented?
The Septentrio driver has been modified to:
GNSS_INTEGRITYmessage.GNSS_INTEGRITYmessage to theSTREAM_EXTENDED_STATUSto ensure it is sent to the GCS.Related Work & Context
GNSS_INTEGRITYmessage from the development dialect.How has this been tested?
The feature was validated on a CubeOrange+ using a replayed SBF log file that was recorded in an environment with active jamming and spoofing.