There's an increasing amount of slow logged topics at 1-2Hz, which were all
updated in the same logger iteration, leading to data bursts. For log
streaming this started to exceed uart buffer sizes. By distributing updates
more equal over time those bursts are removed, reducing buffer size
requirements.
Tests showed during steady state a reduction of maximum topic updates per
iteration from 40 down to 17.
Also the SD log buffer fill level is more constant.
1. The RTPS IDs are now automatically assigned to the topics
2. Only the topics that get defined to be sent or received in the urtps_bridge_topics.yaml (renamed, since now it doesn't contain IDs) receive the IDs
3. Any addition or removal on the urtps_bridge_topics.yaml file might update the topic IDs - this will require that the agent and the client ID list has to be in sync. This will further require a robustification of the way we check the IDs and the message definitions when starting the bridge.
This allows that all messages (not only timesync messages) that get received on the same system that sent them do not get parsed. As the microRTPS agent is built currently, this will only happen right now if someone sets the same UDP port to send and receive data, or by manually changing the agent topics (which were always autogenerated).
This is an attempt to implement the protocol_splitter with one
read buffer only. The idea is to prevent additional copy
operations from an incoming buffer to the respective protocol buffer.
Right now the benefit is not really there because we are not using a
ringbuffer and have to shift data around quite a bit.
We also try to parse and copy data to the reader immediately without
doing a read from the device which potentially takes 100ms.
We further use a timeout mechanism to prevent starvation if one reader
disconnects and the buffer would fill up from unread data.
A constant large value in the (signed) normalized innovation test ratio is a sign
of bias in the state estimate. This metric can be used to trigger a
covariance boost or reset
Some receivers are initializing to some heading and then resetting to
the correct one after a couple of seconds. EKF2 should detect that and
reset to the new value
The following exception occurs in some rare cases (but only with make build: NO_NINJA_BUILD=1 px4_sitl_default):
Traceback (most recent call last):
File "/__w/PX4-Autopilot/PX4-Autopilot/src/lib/component_information/generate_component_general.py", line 79, in <module>
save_compressed(filename)
File "/__w/PX4-Autopilot/PX4-Autopilot/src/lib/component_information/generate_component_general.py", line 33, in save_compressed
with open(filename, 'r') as content_file:
FileNotFoundError: [Errno 2] No such file or directory: '/__w/PX4-Autopilot/PX4-Autopilot/build/px4_sitl_default/component_general.json'
make[3]: *** [src/lib/component_information/CMakeFiles/component_information_header.dir/build.make:68: component_general.json] Error 1
Jaeyoung-Lim