哈哈哈, 相信很多人在搜索這個標題吧?
如我一個月折騰的經過, 參考我之前的那篇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