关于lidar_det接收不到消息引发的一个“阻塞式接收”的问题：以上是技术人员的回答。然后我根据回答查看了netbind文件对应修改处：疑惑的是：我把雷达接在了5口上，对应的位置是Rear.Lidar发布的数据是Front，是因为我是用的instanceIdentifier=3.然后我根据我接的“5“口的“Rear”认为应该改为“4”，就应该通信成功。但是改为4之后，仍然无法成功。然后，我依据我的“安装位置-5”将instanceIdentifier改为5，看看等否通信成功。结果还是无法成功。然后我就只能再尝试6和7，最终发现只有改为7的时候，才能通信成功。（为什么？）回显结果：想问一下为什么？另外想问一下，这两种方式有什么区别？

产品名称：MDC  610软件版本：MDC 610 1.1.029-0000000T1问题现象（问题描述）：毫米波雷达传感器，型号：ARS408-21XX，接入mdc610对应CAN接口上（线缆标签RADAR_C3~RADAR_C8都尝试过），手动拉起抽象进程/opt/platform/mdc_platform/script/radar_a_ars408_start.sh后，执行rtfevent list | grep -i sensor无法查询到数据收发事件故障后已采取的措施：1>尝试使用candump抓取线缆标签RADAR_C3~RADAR_C8（分别对应can0~can4和can6）的数据，但未抓取到任何数据;                                      2>将毫米波雷达接入线缆标签GPS_C11（对应can7），使用candump能够抓取到can7的数据（另外，can7与1>中所有的can接口配置一致，如，波特率为500KBaud，采样点为：800，CAN模式为CANFD）.具体版本信息截图如下：SOC侧的can配置均一样，部分截图如下（所有can都有“state ERROR-ACTIVE”字样，包括can7） 

在完成关于LidarParsing()函数中所有的功能性代码的调试内容后，尝试与ADSFI端的Lidar_det进行通讯：Lidar_det端：在LidarDetection::SubLidar()函数体中，添加如下代码，当收数成功或失败后，打印相应的消息提醒。在LidarParsing()函数中，我增加了打印点云坐标的代码：运行结果：同时也可以用mviz可视化看到点云原始数据：但是运行Lidar_det的结果：发现没有打印收数成功或者失败的消息，而是程序卡在if判断语句（if (node.GetLidar(my_lidarData, node.GetLidarInsIdx()[0]) != HAF_SUCCESS)）了，既没有打印成功，也没有打印失败。然后我们怀疑是前端（抽象）没有发送成功，所以使用rtfevent hz <eventname>查看前端是否在发：可以看到，前端确实已经发送了，但是为什么ADSFI端收不到数呢？我们查询手册，想看看if判断语句中使用的GetLidar的接口使用说明：这里边说了一个“阻塞式接收”，是不是有可能是因为这个问题？问题：Lidar_det收数失败的原因是不是“阻塞式接收”的问题？又该如何解决呢？

在官方例程MDC_Sample-2.1.003-T0000000> PLATFORM_Sample> modules> can_sample> can_receive_sample例程中添加CM通讯相关代码。并发送数据，并编译通过接着在MDC板端运行二进制文件，没啥问题接着使用rtfevent hz查看发布主题是否有数据发送，发现一直没有数据发送，这该怎么解决呢？

1.启动ros：roscore  2.启动mviz：./run.py回显结果：[ERROR] [1740377559.226422968]: PluginlibFactory: The plugin for class 'rviz_plugin/Positioning and Traffic Elements' failed to load.  Error: Failed to load library /home/noob/MDC/MDC_Application_Visualizer-3.0.002-0000000-Ubuntu20/rviz_plugin/lib//librviz_plugin.so. Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML. Error string: Could not load library (Poco exception = /home/noob/MDC/MDC_Application_Visualizer-3.0.002-0000000-Ubuntu20/rviz_plugin/lib//librviz_plugin.so: undefined symbol: _ZN4rviz12BoolPropertyC1ERK7QStringbS3_PNS_8PropertyE)  

问题描述1智能驾驶计算平台设备无法通过ACC唤醒，但可以通过CANN方式唤醒。对比另一台智能驾驶计算平台设备，可以通过相同的ACC唤醒。解决方式两个设备上MCU二次开发的版本不一致，不能通过ACC唤醒的设备上使用的MCU版本过老。问题描述2使用TBB库，SDK中的交叉编译工具编不出来。解决方式支持在MDC上使用TBB库，更新TBB版本或许能解决问题。问题描述3MDC610 上是否支持 Ascend sample 代码中samples/cplusplus/common/acllite目录下的 ACLLite库的编译。解决方式MDC配套软件栈未适配ACLLite库，可以使用ADSFI框架，或者原生ACL接口。说明：信息来源于cid:link_0，单击此链接查看原贴。问题描述4在同样的网络环境下，从MDC610内通过scp向服务器上传文件的速率，明显低于从MDC300F内上传，平均速率只有后者的三分之一左右。从MDC610内上传起始速率较高，但随着上传进度，速率逐渐降低，最后稳定在一个较低的速率上传，原因是什么。MDC300F  MDC610  答复1、在局域网传输速率很快，说明MDC网络传输正常。2、向广域网主机传输，受公网带宽、网络拥塞情况等情况影响，无法做出答复。 3、即使是在同一局域网下，向同一公网传输，由于原IP和mac的不同，在网关或vpn处有针对IP或mac的限速或优先级相关处理，需要排查。4、跳数多的链路速率较慢，符合分析逻辑，即一个报文经过的设备越多，速率一般越慢，MDC 本身对网络传输速率 未做限制。说明：信息来源于cid:link_1，单击此链接查看原贴。问题描述5系统开机启动一段时间后，突然MDC610风扇狂转，系统通过ssh也连不上，过差不多5-7分钟风扇才恢复正常，ssh才能连上，重新登录系统后发现系统应该是重启过了。这个现象经常发生，只要开机启动一段时间后就会复现，但是复现的时间不规律。可能原因程序占用的内存一直在增加，没有释放，导致系统内存被占满，故触发了系统自动重启。解决方式将程序占用的内存及时释放后重启系统，查看是否还会自动重启。说明：信息来源于cid:link_2，单击此链接查看原贴。

升级内核后，MDC差不多5分钟就自动重启一下，这个是什么问题呢

我们把ins的cm通信的相关的代码整合到canreceive例子里我这里只是添加了头文件，并且我再CMakeLists文件中也添加了头文件路径但是编译未通过，结果如下，说是没有定义，这怎末解决

MDC和路由器接在一起，九个设备上电2分钟就可以ssh连接上，有一台MDC连上wifi后要5分钟以上才可以连接上。这个怎么排查，有什么命令可以看一下系统启动时间的

硬件连接：在MDC中运行PLATDFORM_Sample->modules->can_sample->can_receive_sample程序在这里读取soc侧的can0口显示读取超时，我再下位机端也在不停发送报文，这是啥原因。

 毫米波雷达采用大陆•ARS408-21毫米波雷达​毫米波雷达接入CAN4口，没有修改任何CAN网络配置手动拉起抽象进程/opt/platform/mdc_platform/script/radar_a_ars408_start.sh​抽象服务正常启动验证数据收发执行命令rtfevent list | grep -i sensor，查询毫米波雷达抽象的event信息。​查询不到任何信息，请问各位大佬问题可能出现在哪里之前连接激光雷达挺顺利有没有可能是毫米波雷达的连线或者是毫米波雷达本身的问题，有没有排查方法

问题描述升级版本后订阅相机数据失败。解决方式查看MMC通信是否为NDSHM，若不是，需要修改通信为NDSHM。

问题描述执行mdc-dbg em query processStatus命令，查询EM状态，发现状态异常，无法升级。可能原因/解决方式可能是升级后未执行结束升级命令就修改系统文件导致，删除“/opt/cfg”下的“part_fault*”文件后，执行结束升级命令，重启即可解决问题。

MDS工具常见问题汇总（1）：cid:link_0MDS工具常见问题汇总（2）：cid:link_1

MVIZ工具常见问题汇总（一）：cid:link_2MVIZ工具常见问题汇总（二）：cid:link_0MVIZ工具常见问题汇总（三）：cid:link_1