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.
- devices in PX4/Firmware (48b31124a4cdab9f7f91dba14649206f41c30c97): f51267815d
- devices current upstream: 6815e1d3b2
- Changes: f51267815d...6815e1d3b2
6815e1d 2021-08-04 zhangft - femtomes: add UAVSTATUS and fall back to 10Hz rate if 20Hz not supported
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