激光雷达驱动一小会就会出现Failed to get scan
-
补充一下，当一直Failed之后，ctrl+c打断后，重新1驱动雷达，能正常一会
-
@eework 大概率是网络问题，请介绍下你的网络结构
-
@小鱼 不好意思鱼哥，我才看到提问题的格式，下次一定遵守！
我的网络拓扑是
从问题现象来说，开始驱动激光雷达的时候，肯定是通的，rviz2看雷达数据开始是有的
就是几秒钟后就Failed中断了https://fishros.org.cn/forum/topic/2465/fishbot雷达建图中断
刚也看到类似的帖子，跟他的情况不太一样 -
@eework 大概率还是网络问题，可以测试一下，虚拟机ping雷达板的网络延时，比较正常的网络结构大概10ms以内，需要注意wifi是有损网络，过多转接和路由器一些配置会造成网络堵塞变慢。
-
@小鱼 平均几十ms左右，在wifi网络里面还算正常吧，这就奇怪了
这个激光雷达板卡我能接串口调试看看具体问题吗？为啥我接usb后用115200的波特率，串口不输出？
-
@eework 在 激光雷达驱动一小会就会出现Failed to get scan 中说：
平均几十ms左右，在wifi网络里面还算正常吧
算不正常的了，主要是网络波动很大，突然一个100ms左右的，就会掉线
串口调试需要调整跳线帽到串口模式
@小鱼 在 激光雷达驱动一小会就会出现Failed to get scan 中说：
比较正常的网络结构大概10ms以内，
-
@小鱼 展示下我这边的哈
笔记本：192.168.0.4 无线到路由器
主控板：192.168.0.5 无线到路由器在笔记本终端ping显示延时如下：
fishros@fishros-KLVC-WXX9:~$ ping 192.168.0.5 PING 192.168.0.5 (192.168.0.5) 56(84) bytes of data. 64 bytes from 192.168.0.5: icmp_seq=1 ttl=255 time=4.22 ms 64 bytes from 192.168.0.5: icmp_seq=2 ttl=255 time=2.20 ms 64 bytes from 192.168.0.5: icmp_seq=3 ttl=255 time=8.37 ms 64 bytes from 192.168.0.5: icmp_seq=4 ttl=255 time=2.48 ms 64 bytes from 192.168.0.5: icmp_seq=5 ttl=255 time=4.09 ms 64 bytes from 192.168.0.5: icmp_seq=6 ttl=255 time=2.07 ms 64 bytes from 192.168.0.5: icmp_seq=7 ttl=255 time=2.86 ms 64 bytes from 192.168.0.5: icmp_seq=8 ttl=255 time=2.45 ms 64 bytes from 192.168.0.5: icmp_seq=9 ttl=255 time=3.97 ms 64 bytes from 192.168.0.5: icmp_seq=10 ttl=255 time=6.54 ms 64 bytes from 192.168.0.5: icmp_seq=11 ttl=255 time=4.29 ms 64 bytes from 192.168.0.5: icmp_seq=12 ttl=255 time=2.53 ms 64 bytes from 192.168.0.5: icmp_seq=13 ttl=255 time=5.67 ms路由器后台展示：
-
雷达数据从小车到ubuntu虚拟机走的是tcp协议，8889端口，映射docker里面的8888端口，从我这边的ping的情况来看，没出现网络断开的情况，网络只要不断地话而且数据量不大的话就不会丢包的
我这个无线网络质量应该是很普遍的，按理应该是没问题的。我先看一下ros那边雷达数据接收处理的代码，先理解一下大概的逻辑流程线
-
我进去容器看了一下，但出现一直Failed的时候，8888端口的连接的接收队列的数据就会一直累积，应该是接收处理的消费端出问题了。
https://github.com/fishros/ydlidar_ros2.git的V1.0.0/fishbot
分支代码来看，雷达数据从ttyUSB0读取消费的？
8888端口数据->ttyUSB0的转换是从哪里做的？没看到
另外这个串口的波特率设置为115200，小车网络发过来的雷达数据带宽会不会大于这个115200的速率？ 如果抖动的时候长时间大于是不是就会出现数据溢出丢包，会不会有问题？ -
@eework 雷达的数据量是很大的，这种情况以往通过优化网络结构和速度都可以解决。 8888端口到tty的映射有专门的程序完成，详细可以参考资料页面最下方的源码。
-
鱼哥，网络环境有时候不可控，能不能从提高串口消费处理的吞吐量来解决问题？修改提高ydlidar_node.cpp的波特率baudrate可以吗？如果这样能解决问题，就能增加网络质量的容错率
https://github.com/fishros/ydlidar_ros2.git 我如果手动修改这个波特率，编译出来的包怎么替换到docker镜像里面呢？
-
-
https://fishros.org.cn/forum/topic/1523/拓展2-fishbot配套雷达驱动教程-源码版
我用上面的源码，调试了一下发现一些现象（没使用docker）但ydlidar_launch出现一直Failed to get scan之后，接收雷达数据的程序就会卡在串口写操作中，下面是我加的日志的接收代码
try: while is_connect: fdlist = mypoll.poll(256) for fd, event in fdlist: data = os.read(fd, 256) write_fd = client.fileno() if fd == master else master if len(data) == 0: print("connect loss error!!!") is_connect = False break print(f"recv laser {len(data)} data") #加的日志 os.write(write_fd, data)
从输出的日志来看，连接没断开，还是保持的。
我把雷达数据消费端的ydlidar_launch也关掉后，结果也一样。现象初步判断1：所以初步判断，雷达数据接收程序阻塞在os.write(write_fd, data)串口写操作中了
然后我接着做了另外一个调试：只去调用接受雷达数据写到串口的python程序，不拉起ydidar_launch去消费，这种情况没出现过接收卡住的情况
判断2：
有没有可能是两个进程对同样一个串口设备操作的竞争锁问题导致的操作阻塞？
这里还得请鱼哥帮忙分析看看 -
@eework 他们操作的不是同一个串口，是雷达驱动那边的bug,我抽空改改
-
@小鱼 辛苦大佬
