- move to high priority work queue (from low priority)
- schedule slightly more often to avoid missing messages
- perf counter include all FFT processing work
- lazily allocate gyro gap perf counters on initial sensor selection
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.
- 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
