哈哈哈, 相信很多人在搜索这个标题吧?
如我一个月折腾的经过, 参考我之前的那篇mbed的博客, 折腾一个月之后, 我决定放弃mbed, 原因不是mbed不好, 也不是在线IDE有多慢, 原因其实是..
我的C++很烂.....
忏悔1分钟...
直接搬家去STM32, 分析协议, 重写驱动, 也就花了我4,5天而已, 不过在这之前的一个月里, 我无意之中, 学了点儿python, 竟然对我分析ROS_Serail的代码起了一定作用, 再次可见, 艺多不压身啊, 啥都会点儿, 不坏...
总之, 第一步, 分析协议, 发现这个ROS_Serial真日怪, 最起码indigo的版本是这样, 举个例子
上位机发过来的时钟/同步帧, 顺序是:
起始/版本号/内容长度/内容长度验证/topic_id/内容/内容CHK
0xFF/0xFE/0x08/0x00/CHK/0x0A/0x00/8个bytes/CHK
干净利落对吧,
好, topic_id的包跟结束会话的包是这样的:
开始/版本号/长度/长度校验/topic_id/内容校验
0xFF/0xFE/0x00/0x00/0xFF/0x00/0x00/0xFF
开始/版本号/长度/长度校验/topic_id/内容校验
0xFF/0xFE/0x00/0x00/0xFF/0x0B/0x00/0xE3
这么说, topic_id也是内容了?
OK, 下面是更诡异的,
上位机如果publish一个message, 是stm32要订阅的topic的时候, 包是nie样的:
0xFF/0xFE/0x0E/0x00/0xF1/0x64/0x00/0x0A/0x00/0x00/0x00/10个bytes的消息/CHK
开始/版本/长度/长度检验/topic(0x64=100, 是订阅主题的编码)/这4个字节是个什么鬼?/内容/CHK
这个跟一开始给上位机传的消息是一样的, 回顾一下
看, 这个表示在内容部分表示内容长度的部分也是4个字节...
我大胆猜测一下, 是不是msg里面如果有多种数据类型, 可以用这种方法, 分隔不同的数据类型用???
哦对了, 最后我都用了string做消息类型, 这很不合理, 但是, whatever, 哪天我真的蛋疼了, 再改吧...
再说电机驱动跟编码器的部分.
如果你是一个熟练的stm32玩家, 电机嘛, 就是pwm咯, 搞个频率控制一下, 对了, 昨天犯了一个低级错误, 用了我最少三个小时, 说明我的基础还是不扎实, STM32引脚, 所谓默认功能, 其实也是AF的, 跟remap是没有关系的...一个是重定向, 一个是复用....反正我发现之后, 是扇了自己一个耳光...3个小时啊...
编码器就更简单了, 就是一个外部中断, 我没做什么差异化, 1乘4什么的, 蛋疼么, 直接就是下降沿触发, 完事.
另外, 如果这是一个分工详细的公司, 我会花时间, 把通讯的部分跟控制的部分分开, 会把代码写得更有层次感, HAL层, APP层, 哈哈哈哈.....
STM32部分的代码如下:
https://github.com/MontaukLaw/ROS_STM32_SERIAL_MOTOR_ENCODER