第一步 雷達型號
本節將對4種雷達進行室外環境下的對比建圖實驗，並進行地圖分析，最終給出每種雷達的最優參數。
4種雷達分別爲：
1 倍加福的二維激光雷達-R2000（型號貌似只有一種）：
在10Hz頻率下角分辨率能達到0.042度，頻率越高角分辨率越大。當出點數太多時carto會出現drop points 的情況，如下實驗是在25Hz的最大出點數的情況下進行的，也就是25Hz允許的最小角分辨率。跑carto雷達的頻率最好是35-40Hz之間，這個頻率caro不出現drop points的出點數還需再進行試驗。雷達最遠範圍大致爲30m.
2 velodyne的VLP-16：
16線雷達，18.08Hz，每秒點數爲30萬；逆時針旋轉，Y軸向前，X軸向右；電機RPM可以爲300,600,900,1200，對應的角分辨率分別爲0.1,0.2,0.3,0.4度。最遠大致爲130m。
需要用VLP-16分別進行二維與三維的建圖實驗。
3 hokuyo：
4 sick:
第二步 實驗結果對比
1 倍加福雷達-2D-室內：
1.1 只用倍加福雷達，雷達頻率25hz，打開online這個參數，其餘默認。
1.2 倍加福雷達25hz+9軸imu，沒開online
雷達最遠範圍設置爲15米（因爲距離遠了偏差一點角度，最遠處的偏差就很明顯）。
經過調參之後的建圖效果（使用默認參數建不成地圖）：
2 倍加福雷達-2D-室外：
2.1 25hz雷達+online
下圖中綠點是起始點，紅點是終止點，可以看到，圖中的圓弧部分產生了偏移，並且非常明顯。後來找原因是由於閉環沒有閉環上導致的。
下圖爲carto中的約束的顯示，中間部分相距10米左右的部分並沒有檢測出來閉環約束，導致了建圖的偏差很大。
所以，第二次又進行實驗，這次控制機器人回到起始點，以讓他能夠找到閉環。可以看到，圓弧部分的偏差很小，成功的添加了閉環約束並進行了累計誤差的消除。同時，也可以得到，carto的後端優化不能很好的消除累計誤差，主要是靠閉環約束來消除累計誤差的。
3 vlp16-室內-2D
3.1 imu猜測
室內環境下進行建圖，實驗了半個月始終建不成圖，困擾了很久。什麼叫建不成圖呢，結果如下圖所示：
這是在配置了使用imu的時候纔出現這種情況。如果是laser+online，或者是laser+odom，都不會出現這種狀況。所以基本可以確定是imu的原因，但具體是什麼就不知道了。
那原因是什麼呢？探索了很久。。。很久。。。得有半個月吧。這期間實驗了carto的各種調參，各種錄製數據包，都是不行。
原因猜測1：
加速度太大，導致Imu數據不好。結果錄製了全程慢速的數據包，還是會飄。。。
原因猜測2：
urdf的問題。由於我用的是9軸的Imu，型號如下，但是我實際放置imu的位置和urdf的位置不一致。在carto的github的issue中官方人員說這種強烈的旋轉是由於urdf不對導致的。之後我又把urdf調整正確，發現效果確實好很多，但是還是會在某一時刻發生莫名的旋轉導致圖重疊。所以這個原因也不能解決我的問題。
原因猜測3：
carto的github的issue中遇到差不多問題的人提供了一種解決方案，就是將 imu的角速度中的x ,y 設置爲0，他說他imu不準，這樣只用z軸的角速度。我自己試了，還是不行。。。
這沒啥辦法了。。。換一個Imu試試，由於carto需要角速度和線速度，實驗室還有一個4軸的Imu,數據量不夠所以一直不願意用。。。而且9軸的頻率可以設置爲200hz，最好400hz。4軸的這個最高只有100hz。爲了讓大家少走彎路所以我將具體型號放出來了。換上了這個imu之後發現數據非常穩定，一點也不漂，就是在突然停車時點雲會衝出去一下，不能瞬間停住，但是caro會將他修回來，不會影響建圖效果。
真實原因(補充)：
經過對4軸和9軸的imu進行對比測試，發現9軸imu的數據準確度確實沒有4軸imu高，但是也沒有差很多。後來經過對lua文件進行調參，發現imu並不是影響地圖強烈旋轉的主要因素。
主要因素是ceres的平移和旋轉的權重沒有進行重新配置，當時使用的是默認的權重參數。
3.2 使用默認參數 建圖效果如下：
參數配置爲 laser(20hz)+imu，
submap.num_range_data=60，
num_accumulated_range_data = 2 (velodyne在20hz時只能輸出一半的點雲，所以這個參數設置爲2,2幀scan爲一個完整的點雲)
(注：velodyne 在20hz下可以輸出360度範圍的點雲，當時只改了launch裏的電機轉速爲1200，沒進雷達的配置網頁裏改rpm。)
POSE_GRAPH.optimize_every_n_nodes = 60. 沒開online的結果如下：
開了online，並把submap.num_range_data=40（因爲發現地圖的偏移比較大）。結果如下：
好吧，開與不開感覺沒啥區別。。。github的issue中官方人員說，在urdf不準時只用laser+online 依然可以很好的建圖。urdf和imu準了online的效果就一般了？？？
雖然稍微有點偏，但是終於建成圖了，還是很開心的。同時，在調參時發現，室內場景下，當雷達的範圍爲100米時，建圖時只要稍微偏了一度，那這個100米的邊就偏出去很大，所以可以得知，並不是雷達的範圍越遠越好。而且，velodyne的頻率爲10hz,在20hz時只有一半的點雲，而carto的掃描匹配 是 對雷達的頻率 依賴比較高的。因爲只有頻率越高，2幀間的時間越短，誤差才能越小。所以20hz的頻率的累積誤差是很大的，室內環境下都會發生較明顯的偏移。
caro的demo的數據包的雷達頻率不知道怎麼寫的驅動，雷達的頻率能達到1500hz，每一幀數據只有大概10度的點雲，可能是這樣數據處理起來比較省資源？？？
3.3 經過調參之後的效果：
圖的質量總是上不去，每次旋轉都會有偏差，雖然後端優化能夠修正一下但不會完全消除誤差。
大致猜測是由於雷達頻率的問題，20hz的點雲只有一半，就相當去10hz的雷達數據，頻率太低導致預測的偏差很大，難以修正回來。之前使用倍加福雷達在30hz時這樣的旋轉偏差就很微小。
不管怎麼調參，在旋轉時機器人位姿都會向當前朝向的右側偏，還不知道原因，還有待深入發掘實驗。
4 vlp16-室內-3D
還是用的20hz的velodyne，4軸的imu，submap.num_range_data=90, POSE_GRAPH.optimize_every_n_nodes = 90
一次成圖，實驗了將 POSE_GRAPH.optimize_every_n_nodes = 0 ，即不進行後端優化，發現建圖效果依然很好，從房間裏走出去，在走廊轉一圈回到房間時點雲依然能房間匹配上。
點雲圖如下：
4.1 如何生成點雲：
使用asset，具體說明https://google-cartographer-ros.readthedocs.io/en/latest/assets_writer.html
voxel_filter_and_remove_moving_objects 這個配置可以去處移動的物體。這個配置文件讀取pbstream，和bag，可以生成ply和pcd 兩種類型的點雲。還可以生成點雲的圖片的3視圖圖片，透視效果。
--assets_writer_vlp16_3d.lua
VOXEL_SIZE = 5e-2
include "transform.lua"
options = {
tracking_frame = "footprint",
pipeline = {
{
action = "min_max_range_filter",
min_range = 0.2,
max_range = 100.,
},
{
action = "voxel_filter_and_remove_moving_objects",
voxel_size = 0.1,
},
{
action = "dump_num_points",
},
{
action = "intensity_to_color",
min_intensity = 0.,
max_intensity = 4095.,
},
-- We also write a PLY file at this stage, because gray points look good.
-- The points in the PLY can be visualized using
-- https://github.com/googlecartographer/point_cloud_viewer.
-- {
-- action = "write_ply",
-- filename = "points.ply",
-- },
{
action = "write_pcd",
filename = "b3-2imu-backend+offline.pcd",
},
{
action = "write_xray_image",
voxel_size = VOXEL_SIZE,
filename = "xray_xy_all_intensity",
transform = XY_TRANSFORM,
},
}
}
return options
第一個點雲地圖是沒加voxel_filter_and_remove_moving_objects的效果，下圖是加了voxel_filter_and_remove_moving_objects之後的結果，發現點雲圖確實乾淨了一些，但是它也把地面刪去了不少。
4.2 如何看點雲：
谷歌的文檔說可以通過 point_cloud_viewer or meshlab 看 ply的點雲。point_cloud_viewer 的安裝可以參考如下鏈接：
https://blog.csdn.net/chongzi865458/article/details/84137531
我根據這個安裝了一下，安裝過程特別繁瑣。。。裝完了之後發現是全黑屏，以爲沒打開，結果是太黑了。。。我真是醉了，一直按8調亮亮度，發現了點雲，結果動起來特別卡，旋轉操作也沒太清楚，一卡一卡的根本調整不到好視角，可能是由於我工控機的顯卡驅動沒裝的原因。
也裝了meshlab。。。沒找到能打開的文件。。。不懂這個。
我是用hdl_localization看的點雲圖，他能加載pcd的點雲。
下圖是我用9軸的Imu和20hz的雷達 使用 hdl_graph_slam 建的點雲圖，這個slam能夠時實的生成點雲圖，不像carto只能後期處理。大致一看效果還不錯，但是發現他的地面翹起來了。
在配置hdl的時候出現了一個問題，就是機器人在不動的時候始終 向上 或者 向下 跳動，並且一下向下。後來發現是launch配置雷達高度的問題，hdl根據雷達高度檢測地面，而地面對於hdl是一個很強的約束，後來把高度調對了就好了很多。
4.3 調參之後的效果
vlp+9軸imu，沒開online，參數大致調了調，沒太細調，還是有點偏差的。由於我對點雲還不太瞭解，很難查看偏差的程度，只能通過肉眼觀察偏差。
以爲pbstream單純保存位姿，想着用3d 的pbstream文件生成二維的柵格地圖，結果發現pbstream文件中會將點雲也保存下來，並不能用於生成二維地圖。
5 vlp16-室外-2D
還是存在和室內一樣的問題，在純旋轉時地圖會偏移很大。
經過調參之後的地圖：
在走到盡頭之後再回來之後的地圖不能完全重疊，會產生偏移，因此這是走了一遍的結果。
在建圖的過程中發現，雷達點的跳動達到10CM，因此地圖的邊爲10cm，由於旋轉導致的偏移能夠到30cm。
6 vlp16-室外-3D
室外環境，使用vlp-16 20hz + 9軸imu 。這9軸imu在後續的實驗中發現imu數據本身問題不太大，只不過數據沒有4軸的那個準。後來我將使用200hz的imu建成了室外環境的3d圖。當然，我把imu的link 改成正確的了，之前imu是隨意貼的。
效果非常好，牆很直，誤差也很小。跑的過程中的內存佔用和cpu佔用都不多。
但是2d的內存佔用非常高，跑5分鐘就已經佔７個G了，所以到現在爲止vlp-16室外的二維圖還沒有做出來。不過有一點很奇怪，我用倍加福25hz跑室外時內存佔用不高，用vlp16 20hz（可以看成10hz) 時內存佔用就很高。(原因爲 submap大小的值設置的太小，室外環境下設置爲40，太小，導致了內存佔用過高)。
第三步 實驗分析
1 carto對雷達頻率要求比較高
在純旋轉的狀態下，分別用10hz, 20hz, 30hz +9軸imu 進行建圖實驗。
10hz情況下：
20hz情況下：
30hz情況下：
結果：
發現當頻率達到30hz時，做純旋轉運動時不會產生地圖的偏移。
2 vlp16 20hz 時整體地圖會向前進方向的右側偏，目前沒找到原因。
3 vlp16 室外情況下，地圖的邊爲10cm，旋轉導致的偏移將偏差30cm，並且在遠處偏移更多。