Odom data interruption occurred（里程计数据出现中断）

[FeiPF2020]

The problem is shown in the above figure, the device is Jetson Xavier NX, and the radar is livox MID360;
There is no problem with the data of livox MID360, but the cloudregistered release blocks interrupts, causing Odom data to be blocked and output to be interrupted. There is a 3-4 second data interruption here
Analyzing program usage and CPU temperature, the current temperature is around 47 degrees Celsius, and the CPU usage is not high;
The location of this interruption is uncertain; It is also difficult to reproduce, but the frequency of occurrence is quite high
What are the specific reasons and how can they be improved?

问题如上图所示，设备是Jetson Xavier NX，雷达为livox MID360；
livox MID360数据是没有问题的，但是发布的cloudregistered堵塞中断，导致odom数据堵塞，输出中断，这里有3-4s的数据中断；
分析程序占用以及CPU温度，此时的温度在47摄氏度左右，CPU占用也不高；
这个中断的地方是不确定的；复现也很难复现，但是出现的频率也挺高的。
请问具体是哪些原因，如何改进？非常感谢！

[FeiPF2020]

The latest debugging process is shown in the figure above, after subscribing to the radar information, ROS INFO prints a sub livox handle, where avia_handle represents the time of the subscribed point cloud and the avia_handle processing time. Print sub IMU in the information subscribed to IMU.

It can be seen that after the timestamp is 1734076974.8, it jumps directly to 1734076977.113, and the data is blocked and then concentrated on this one timestamp processing.

So what is the reason for this, how to correct it, is the queue set too big?

最新调试过程如上图所示，在订阅到雷达信息之后ROS INFO打印 sub livox handle，其中avia_handle 表示订阅到的一帧点云，经过avia_handle处理的时间。在订阅到imu的信息打印sub imu。

可以看到，在时间戳1734076974.8后，直接跳到1734076977.113，数据堵塞之后集中在这一个时间戳处理。

所以这是什么原因，如何纠正，是队列设置的太大了吗?

[FeiPF2020]

根据代码的主要模块，每一个模块计算耗时，发现在堵塞的时候，单个代码的耗时并没有明显的增大，将雷达的订阅队列和IMU的订阅队列调小，数据输出中断的现象仍然出现；请问这个队列为什么设置的这么大，以及主循环的频率为什么设置5000这么大？