使用ROS開源代碼和激光雷達進行小車的定位導航——里程計信息的計算

寫在前面：

之前挖了個坑，大致講了一下導航定位的思路但是設計到實際的東西還是有很多細節問題需要注意。最近把一個項目做完了，正好有時間可以總結一些技術要點和大家分享一下。

我采用的是gmapping算法來對環境進行地圖的構建，這就需要里程計的信息。首先是gmapping根據我的實際效果在場地不是很大的情況下還是能夠較好的完成建圖的過程的，下面可以給出一張效果圖。

gmapping效果圖

由於gmapping采用粒子濾波的方法，和amcl一樣都是對里程計信息要求比較高的，在我實踐過程中里程計信息幾乎決定了建圖的好壞，下面我會詳細的介紹一下里程計信息的獲取與計算。

一、通信方式

為什么我要開始就提通信呢？因為我的親生經歷就在通信上花費了大把大把的時間，所以一開始選取一種好的通信方式既能提高里程計發布的頻率提高精度又能避免走很多彎路。下面這部分會涉及到一些底層單片機的東西。

首先我采用的是stm32F407作為底層的驅動控制，然后使用一個w5500模塊將spi轉換成以太網和電腦上位機通信。（至於w5500是什么可以上某寶搜一下）通信需要考慮到一下幾個因素，第一就是速度。在我看來普通的串口通信很難滿足gmapping對里程計信息的需求，實際情況測試下延時比較長效果很差，而且容易數據錯誤。以下是我推薦的通信方式

1.USB通信，采用USB的HID模式進行通信，不管是速率還是穩定性都能較好的滿足，我也曾采用過這種方式。

缺點：stm32的usb通信較難，很難在短時間內掌握usb通信，網上資料少。

2.以太網通信，以太網具有10M或100M的高速傳輸數據的能力，完全滿足要求。

缺點：stm32的以太網代碼量較大，可能會導致代碼運行速度變慢或者接觸不良時卡在中斷導致車子瘋掉。

3.w5500模塊spi轉以太網通信，優點就是只需要關注spi通信，代碼少不用理會網絡通信的一些問題。

缺點：每次和電腦連接都要復位一次，不是很方便(電路設計上可以解決這個問題，需要自己設計）

最后，我采用了第三種方式。至於每種方式的代碼和資料，不管是下位機還是上位機的程序，需要的可以留言。

還有一點值得注意，就是我們里程計的信息需要的是浮點型的才能更加精確，但是我們怎么傳輸浮點型的數據呢？

那就是采用聯合結構體的方式。下面給出一個博客，我就不細講了。

https://blog.csdn.net/huhuang/article/details/51585009

二、里程計計算

里程計的計算主要就是下面這個問題：
給你四個或者兩個電機的編碼器的數值，計算出小車目前的位置和速度。

（下面部分內容來自深藍學院的激光slam課程不是打廣告，尊重版權）

首先介紹四個麥克納姆輪的小車的運動模型，這和我做的是一樣的。

可以參考這個博客

麥輪底盤的運動學計算

下面給出我的計算過程，手寫的有點丑湊合着看吧。

計算過程

實際上，ROS大多采用的兩輪的差速控制並不是我們這種麥輪結構。

差速原理

對於兩輪差分的運動學計算，可以參考這個博客

https://blog.csdn.net/u012926144/article/details/80787175

至於其他的比如全向輪的底盤的解算大多大同小異。

現在我們確實是獲得了小車速度信息，但是位置信息還沒有得到。有人說積分一下不就好了，但是實際上沒有那么簡單，因為目前的小車的速度是在小車坐標系下的，並不是世界坐標系下面的。

所以我們需要將速度轉換到世界坐標系下然后再進行積分，求得小車目前的位置。

坐標轉換

將我們利用運動學模型計算出來的值乘上一個旋轉矩陣，然后計算出世界坐標系下的位姿，連成一條軌跡。

三、里程計信息的發布

好了，終於到了最后一步。

現在我們成功的計算出了里程計的信息，那怎么發布到ROS上面給slam算法提供數據呢？

其實只需要關注這兩個信息的發布便可

ros::Publisher odom_pub = n.advertise<nav_msgs::Odometry>("odom", 600);

ros::Publisher chatter_pub = n.advertise<std_msgs::String>("chatter", 600);

一個是發布里程計信息，然后另外一個發布機器人和地圖的位置的TF轉換關系。

好了，今天就到這了有什么問題或者要什么資料都可以留言哦!!!!

本文鏈接： https://blog.csdn.net/RoboChengzi/article/details/82263091