简单记录了尝试使用ROS与STM32通讯的过程，包括踩的一点坑，其中一些低级问题实在是有点让人哭笑不得😂

ROS串口通讯

ROS串口通讯配置

Ubuntu20.04手动获取Serial包

linux/ros 串口权限获取

转载自(9条消息) Linux/ROS——获取串口权限_不懂音乐的欣赏者的博客-CSDN博客

我这里的串口号是/dev/ttyTHS1，需要适当变动

永久解决串口权限问题

（我试了一下，但是失败了）

创建ttyUSB权限规则文件etc/udev/rules.d/70-ttyUSB.rules

1	$ sudo vim -p /etc/udev/rules.d/70-ttyUSB.rules

在70-ttyUSB.rules文件中写入下列代码

KERNEL==”ttyUSB*”, OWNER=”root”, GROUP=”root”, MODE=”0666”
保存即可,重启或注销用户在登录后生效

临时获取串口权限

先查看插入电脑的串口号

1	ls /dev/ \| grep ttyUSB

知道串口号之后对指定串口赋予权限,以ttyUSB0为例

1	sudo chmod a+rw /dev/ttyUSB0

不用重启即可生效

代码编写问题

Jetson nano与STM32通讯

jetson nano串口

引脚图，直接连即可。

ROS与32串口通讯（ROS端）只能接收不能发送

被这个问题卡了很久。根据情况描述，既然都能正常接收了为什么发送会失败呢？

ROS端

在ROS端串口输出一个字符串所用到的函数是ser.write（string value），在定时器的回调函数里面同时调用。首先就是检查定时器回调函数是否被成功调用，读取数据和发送数据都是在这个回调函数里调用的，那么基本上是没问题的，ROS_INFO一下确实没问题。同理SendMsgs( )一样成功调用了。那至少能肯定，write( )函数肯定被调用了呀。

中间还出了一点岔子，就是代码中不小心打上了一点乱码，结果编译出问题。但是编译日志也没有报错，我虽然看着和原来的不一样，但是没有太在意。但是这就导致了之前改完代码后好几次编译都是不通过的，一直运行的也是那个有问题的节点代码。所以如果编译日志同平时比较为反常，要当心一下。

接下来将nano的TX，RX短接，判断到底是不是nano端的问题。发现确实能自己接收到自己的消息，那就没问题了

nano端没问题了，估计就是32端的问题了。ros只能接受不能发送，是不是rx接对了但tx接错了呢？

nano 8：TX——RX：stm32 PA10

nano 10: RX——TX：stm32 PA9

再检验一遍着实无误。

32端

32端没有再配置一个串口，使用oled屏DEBUG，nano端使用cutecom通讯正常，32能接收到消息，换成ros发消息后32却是一点反应都没有，那这个时候就想到看看串口中断函数到底有没有被调用，32到底有没有接收到消息。我在该函数里面加了些语句：如果串口中断函数被调用的话oled就会显示。

那结果是没有反应。

实际上控制oled显示的时候输完内容，要加个refresh。同时while( )里在不断Set_Z( ),里面也会不断更新内容然后refresh，所以其实串口中断是被调用了的，但在这样的情况下看不到反应。最后是使用keil的在线调试功能设置断点发现的，其实调用了。这个时候再看一下函数关于接收到的消息的过滤，其实正点原子也说过——发送新行。cutecom会，但ros不会。最终在要发送的字符串后面加上\r\n，DEBUG结束。