這是去年參加的單車拉力組代碼調試記錄，分享給大家
小車的調試日志
2020.11.6
簡單的做了一下小車的尋跡，沒有加入PID控制，轉彎的方法為：檢測的一邊沒有邊線，就直接轉彎。這種方法只適合固定的賽道和固定的舵機電機的值，不具備智能特性。
發現單片給的底層驅動代碼，不能滿足實際的要求，之后對底層代碼進行了修改，修改的函數為PWM_UpdatePwmDutycycle，在修改之前，他的占空比只能在0-100之間，之后通過修改，使得它的可以調區間變大
2020.11.7
按照逐飛科技的教程，使用python3.7.3，簡單的建立了一個模型，只訓練了一次。同時將電機的參數傳到了上位機上，準備開始調試PID，以及學習python。
2020.11.8
搭建了python+Pycharm的環境，簡單的學習使用編譯器，開始學習tensorflow的庫，爭取一個星期學會python+tensorflow。
學習了tensorflow圖的概念，簡單的使用tensor進行運算。
2020.11.10
開始編寫pid控制代碼，P：當前誤差乘以一個系數因子；I：積分項，某個時段內，所有誤差之和乘以一個系數因子；D：微分項，兩個誤差的差值，即兩個誤差之間的斜率乘以一個系數因子。
初步建立好了PID的模型，開始對轉向環進行調節，整體的效果不是特別理想。計算誤差的方法采用對中線進行運算，前后兩個點的差值，然后對整條直線的差值進行累加，得到一個誤差值，當誤差值為零時，認為這個是一條直線；這個誤差值為正或者負的時候，對應右彎道和左彎道。但是最后的效果為，直線計算出來的誤差特別大，而彎道幾乎沒有誤差，這是剛好相反的結果。之后提出了一下的幾種解決方案：
方案一：在計算誤差的函數中，使用了三個一樣的循環，增加了單片機的負擔，做了重復的工作，之后可以考慮改成一個循環運行。
方案二：在計算誤差時，最后一次運算的值不在那個數組中，可能會導致出現錯誤，修改最后的值看情況。
方案三：推到之前的方案，采用計算中線均值的方法，來獲得誤差，具體還是要看最后的效果。
2020.11.11
今天驗證了之前的方案一以及方案二，發現確實存在上述所提到的問題，多個for循環導致延時的情況，最后一次計算的數值不在這個數組里面，尤其是方案二涉及的問題，最整個的誤差計算有著非常大的影響，在更改了計算的次數之后，發現得到了我們想要的誤差，并且能夠很直觀的判斷出是直線還是彎道。
在這個程序的框架下存在的問題：車在快入彎道的時候，誤差會出現一次很強烈的跳變，導致車提前轉彎，加上車速過快，直接沖出賽道；還存在的問題，車在快出彎道的時候，會判斷成直線，舵機就自己回到直線的情況下，在查看攝像頭運行的圖像中發現，在車速達到一定的情況下，賽道有很大一部分信息不被采集到，導致判斷失誤。現在加入新的約束條件，看最后是否可以達到預期的效果值。
晚上結果與隔壁四輪組的討論，發現了我們小車現在存在的問題：對于我們之前使用的通過差值來計算中線誤差，存在很大的問題，我沒有給他一個標準的中線來定義小車的位置，使得小車在邊線的時候，還是不能察覺自己當前的位置，再者就是過彎道的時候，會出現中線跳變的情況，導致整個誤差計算的過程會與實際產生偏離，不能達到實際想要的效果。
結果和他們的討論，對于圖像的處理的改進做出了如下的方案：在屏幕正中間定義一條中線，并且以這條中線為參考基準，之后通過對中線上的點進行加權求和，之后再與標注中線進行比較，通過比較判斷當前車的位置。現在先嘗試使用中線求和的方法對誤差進行計算，放棄之前的計算中線誤差的辦法。
在嘗試這個新的方法中，發現對于直線的效果很好，小車可以判斷當前的位置，對車身進行校正。但是對于彎道，隨著彎道的出現，上面的中線像素點會丟失，到時算出來的平均誤差會偏小，導致判斷錯誤，使得舵機打的角度不夠，不能夠順利的過彎，后期仍需要改進。
2020.11.12
今天采用了均值的方法計算中線誤差，在之前的基礎上進行了改進，之前是中線誤差減去中線之后再除以一個系數，這樣導致的結果是整個系統對誤差的判斷不夠準確，分的級數不夠。現在采用的是中線的誤差減去標準中線的值，在這樣的情況下，每一點的變化都可以被檢測出來，這樣可以做到大彎道舵機打大角度，小彎道舵機打小角度。
現在遇到的問題是，由于轉彎時中線誤差會比較的大，導致還沒有到最佳的入彎時機時，舵機就開始打了。對于這個問題，采用的解決辦法就是，對整個誤差中線上的點加一個加權，使得越靠近車身到的點越有價值，遠離車的點價值不大。
PID調試過程中，在只加P比例項的時候（P值為5.5，I和D為0），車最高可以跑到210的占空比，但是車的整體穩定性會下降，左右搖擺會很嚴重，車子過右彎道的時候比較順利，左彎道的時候會出現提前入彎的情況，可能是圖像處理上的問題。之后開始加入微分項D，在純D值下，車子運行比較穩定，很少出現左右搖擺的情況，但是過彎角度有點大。最后嘗試P值和D值一起加入，正在試驗一組比較完美的數據。實際測試過程，會發現加入P值后，即使在D值的作用下，還是會出現車左右搖擺，出彎角度不好等問題。
2020.11.13
今天計算了兩個輪胎需要的轉速差。
2020.11.14
開始電感的學習使用，初步了解電感的工作方式。采用中間一個、左右各一個的方式排布電感，對電感采集回來的數據進行軟件處理，進行軟件濾波。在經過歸一化處理的電感數據后，之前的毛刺都會被濾掉，得到一個較為穩定的曲線，之后用這個曲線進行誤差的計算。
2020.11.15
采用差比和的辦法，對電感誤差曲線進行擬合，因為采集的電感值是一個類似于正弦波的曲線，所以在進行擬合的時候，不能采用之前的辦法進行擬合。通過了解差比和的公式，設置幾個固定的參數，通過調節各個參數的值，盡量的去擬合一條波動較小的一條曲線，就現在擬合的曲線來說，上下波動的誤差還是較大，在實際的應用中可能會出現舵機搖擺大的問題。之后確定電磁尋跡的方案之后，開始進行電磁尋跡，在這個過程中還要不斷的對誤差曲線以及電感值得歸一化曲線進行進一步的優化擬合。
2020.11.18
記錄一下這幾天所做的事情。在對電感進行操作的時候，遇到了很多問題，嘗試了各種的方法，最終采用的方法為利用左右電感的差值作為誤差，之后對這個誤差進行PID的操作。整體的這個效果很不錯，車子在整個的運行中沒有大的擺動，過彎還是很順利。但是會出現個別彎道過不去的情況，現在初步考慮為pid的值設定不是特別的適合，其次就是電機沒有做差速，轉彎的角度可能不夠。
現在賽道的環島還是不能過，車在過環島的時候會有明顯的標志，可以作為判斷為環島的標志，后續會加上對環島的處理，現在進行電機的調速，做差速，使過彎更加的順滑。
2020.11.20
為了開始訓練AI，加入長前瞻電感進行試車，發現在長前瞻的情況下，車的運行結果不是特別理想，經常出現沖出賽道的情況，一方面是由于車速不夠快的原因，車子又提前打彎；另一方面是由于對整個誤差的處理不是很到位，這一方賣在觀察隔壁四輪組的車子舵機之后，發現一個問題，我們的車，即使在中間平衡的狀態，我們車的舵機依舊會左右搖擺，而別的組沒有，對于這個問題，在觀察了我們的波形之后會發現，最后輸出的誤差是一條類似于正弦波的曲線，所以在中間時刻，它還是一條正弦波，所以舵機會來回震蕩。對于這個問題還在嘗試新的解決辦法，就是左右兩個電感進行相加減的運算，因為采集回來的左右電感值相位基本是相同的，所以做減法會使一部分的誤差會消掉，從而得到一條更加穩定的曲線。
在今天的調試過程中，電感的運放電路不知道什么原因，輸出的電壓非常的大，超過了AD采樣口的額定電壓，會對單片機有一定的損傷，具體是什么原因導致的，目前還沒有找出，后續可能還會出現類似的問題，有待排查。
現在以為沒有電感采樣口，不能進行下去。
2020.11.21
今天調試了電機的PID，觀察看各個參數P、I、D對整個系統的影響，通過上位機進行觀察，至于后面各個參數的設置以及差速的設置，需要在后續發車的過程中不斷總結。
2020.11.22
今天完成了LQ的串口移植，能夠通過上位機接收到單片機發出的數據，但是只能發送ASCII碼，具體應用時不是特別的方便，整體下來的使用下過不是特別好，目前還沒有找到很好的解決辦法。
2020.11.24
在運放打板期間，沒有進行太多的實際操作，就對整體的方案進行了思考，提出了以下的一個觀念：對于電感尋跡，很難做到預判前方很遠的賽道情況，這就要求我們對整個車的控制更加的精確，對誤差的獲取也要更加的精確，否則整個車的運行會十分不穩定，所以對于PID控制，舵機依舊采用PD控制，電機采用PID控制，電機全程一直按照一個速度進行運行，過彎道時，根據舵機打的角度進行運動學分析，然后為了保證順利的過彎，同時要適當的降低車的速度，所以這里暫時通過前后獲得的誤差值得差值作為衡量這個的標準，前后相差越大，說明車偏移軌跡的距離就越大，這個時候減低速度。
這段時間還閱讀了一些國賽隊伍的技術文檔，獲得了很大的啟發，對于電感的尋跡，主要還是采用差比和的方法，嘗試不同的差和組合，觀察車在順時針逆時針的運行情況，考察代碼的對稱性。
2020.12.09
轉做單車組，開始的時候調試的是STC8A8K的芯片，之后會使用STC16F系列的芯片，現在還是在調試8A的芯片。外圍電路的調試基本完成，蜂鳴器、按鍵、編碼開關、編碼器等。
作為單車平衡重要部分的陀螺儀，我們采用的是ICM20602陀螺儀，濾波的算法采用的是卡爾曼濾波，因為IC不帶DMP的姿態解析，所以這部分代碼是借鑒網上的卡爾曼濾波寫的，從最終的效果來看，角速度計部分基本已經完成，可以轉化成角度使用，而陀螺儀部分（也就是）角速度這一環還沒有調試好，之前本來是調試好的了，后面突然出現了問題，這一部分代碼不能使用，后面還會繼續調試陀螺儀。
接下來要完成四輪PID代碼的移植，轉化到單車上去，寫一套切換PID的代碼。
2020.12.11
今天發現陀螺儀的一個問題，在使用卡爾曼濾波進行濾波解算姿態的時候，隨著時間的增加，會發現解算的速度越來越慢，單片機解算出來的姿態與實際的姿態，出現了延時現象，而且隨著時間的推移，這個現象越來越明顯。初步估計是隨著時間的推移，對傳感器數據的數據積分越來越大，導致計算量增大，最終與實際有一定的偏差。后面查閱一些資料發現，卡爾曼濾波的計算量，需要MCU有較強的計算能力，所以就目前STC的單片機來看，卡爾曼濾波的方案可能會被擯棄掉。
后續將采用另外一種的方法進行姿態解算，互補融合算法。首先，陀螺儀的噪聲基本在低頻中，加速度計的噪聲大多位于高頻中，這兩個信號都帶有偏轉角的信息，所以，現在對這兩個分別過高通濾波器和低通濾波器，之后對這兩個進行互補融合，首先嘗試一階濾波器，之后看實際的效果，再采用二階濾波器。
2020.12.14
對于之前卡爾曼濾波，出現的隨著時間的推移，計算量越來越大的問題，在參考16級學長的卡爾曼濾波代碼之后，找到了問題所在。參數C_t的初始化定義出現了一點問題，在改成float之后，程序整個的運行過程變得正常，解算的效果與實際的效果基本符合。在只解算陀螺儀姿態的時候，解算一次的時間大概在1.3ms左右，加上切換PID之后，控制舵機的解算速度在1.8ms左右，解算速度基本滿足要求。
2020.12.15
在進行卡爾曼濾波之后，還是會出現偶然的跳變點，對于單車這種平衡姿態解算要求高的系統，這種大的偶然的跳變可能是危險的，會單片做出錯誤的判斷，可以采用加一個低通濾波器來解決這個問題。
加入低通濾波器，需要對權重系數進行調試，低通濾波器會存在相位滯后的情況，所以要對尋找一個合適的權重參數。
再反觀切換PID系統，當出現跳變的時候，此時前后誤差會很大，切換到加速度環進行調節，一定作用上對這種跳變情況有緩解作用。
不過還是會嘗試經過一個低通濾波器看最后的效果。
2020.12.17
在加入低通濾波器之后，之前出現的偶爾跳變的情況得到了改善，曲線變得更加的平滑，但是會存在相位滯后的情況，后續會根據實際的情況，對濾波的頻率進行調整。
2020.12.19
開始寫模糊控制算法，在這個過程中，要盡量的較少代碼的運行時間，空出更多的時間去做別的事情。
2020.12.25
打了第一版的核心板，發現如下的問題：1.芯片的地沒有接上，原因是不能通過鋪銅去把所有的地接在一起，必須通過手動連線的方式，讓地全部接在一起；2.STC16F芯片是低電平復位，復位引腳懸空，通過萬用表測量，是低電平，所以單片機可以下載程序，但是不能正常的工作，因為一直在復位的條件下，通過外接10K電阻與5V電相接，可以工作。
對于其他引腳的測試，引腳都可以置高低電平，可以正常使用。后面根據之前遇到的問題，開始第二版的核心板的制作，并制作第一版的母板。
目前把所有的代碼整合到一起，代碼的初步架構已經全部完成，在模擬車的運行過程中，符合控制目標。
2020.12.28
單車車模到了之后，開始調車。發現如下幾個問題：1.單片機莫名的會跑死，不工作，原因待查明；2.之前沒有考慮PWM輸出的問題，所以在打板的時候，沒有留意這個問題，舵機和電機的PWM輸出都用的PWMA，所以不能輸出不同的頻率，之后要使用PWMA和PWMB分別控制電機和舵機。
對于單片機跑死的原因，后面采用定時器中斷來檢測。
在調試單車平衡的過程中，車子想跑起來平衡，還是有很多的困難。
2020.12.29
對于昨天出現單片機死機的問題，最后查明是單車車身導電，導致單片機死機。
PWM的問題,目前還沒有解決。
近期軟件部分所要完成的任務：
1. 確定單車的臨界傾斜角度
2. 確定單車的臨界行駛速度
3. 將單車舵機的打角和單車的傾角關聯起來
4. 驗證切換PID的可行性，確定切換的閾值
2020.12.30
在整個陀螺儀姿態解析的過程中，解析出來的是90度的角，但是，這部分的數據，只有在車身閾值角度的范圍內是有用的信息，超出這個范圍，車身可能就會傾倒，此時再想控制車身平衡，已經無法使其平衡了。所以，就使用閾值范圍內的值，其余的值不予討論。
2021.1.4
制作了第二版的核心板、母板以及各種驅動模塊，發現問題如下：
1. 核心板上依舊不能使用USB進行下載，而且復位按鍵不能使用；
2. 母板上存在一些問題，如部分模塊排布過于緊密，不好插模塊使用，后期還要調整布局；
3. 電機驅動板不能使用；
4. 運放模塊沒有驗證是否可以使用；
車的整體框架基本已經完成，后期將開始調試代碼，驗證方案的正確性。
2021.3.1
開學第一天。寒假簡單的完成單車代碼的編寫，采用傳統的PID，在舵機的控制中加入了積分項I，目前情況來看，單車平衡跑的距離大概半米左右。由于左邊比右邊重一些，所以機械平衡還沒有調好。之后還要尋求PID三個參數之間的平衡，達到直立的最佳效果。
單車PCB板子以及機械機構還要進一步的優化。
2021.3.10
記錄單車直立的第一天，在直立的過程中，發現了很多問題，發現的問題如下：1.車身整體結構左右不是十分對稱，車把手位置中間的大螺絲的松緊需要調整，建議是緊一點的，不然車身會存在抖的問題；2.陀螺儀濾波問題，陀螺儀本身采集的數據存在很大的噪聲，需要進行互補融合盡量的解算出實際的角度偏差，后面調試的過程中最大的問題是解算出的角度會超過實際值，之后再回到實際值，這個問題需要引起重視，這樣會導致舵機打兩次角度，會影響平衡；3.PID參數調節過程中，PID三個參數都引入，P稍微大一點30——50，累計誤差需要進行限幅度，不然退耦過程時間過長，且建議I給小一點0.05——0.0001，對于參數D是穩定整個系統的關鍵部分，直接采用陀螺儀采集的角速度值，乘以系數K（0.1左右）進行處理，防止過大影響整個控制，參數D在1——5之間。
總體歸結下來，數據的處理很關鍵，直接影響車是否平衡，之后調節PID參數。
2021.3.18
在之前的代碼上進行了優化，采用卡爾曼濾波，對濾波的幾個系數進行搭配，主要是噪聲協方差（Q_angle）和采樣時間（dt），通過搭配這兩個參數，是解算出來的數據更加的貼近實際的值并且盡量的減少噪聲。同時對整個車身進行配重，適當的增加右邊的重量，但是還是會發現左邊會比右邊重一點，這個問題留到后面的一版板子中進行處理。
在現在的控制系統中，放在1MS中斷函數中進行處理，對應的參數為P = 41，I = 0.001，D = 0.2，同時微分項誤差的引進為陀螺儀直接采集的加速度值（為經過濾波處理）。在這個控制系統下，可以看到，比之前的控制系統更加的穩定，很少出現在中間平衡位置抖動的情況，并且車可以直立的更加久。
后續進行單車的循跡以及電機閉環，如果運算能力達不到預期的效果，可能會采用偽雙核的方案，專門的有一個CPU進行數據的處理，然后發送個決策的CPU，提高整個控制的效率。
2021.3.26
昨天發現引用逐飛的驅動庫時，角速度的引入存在問題，導致濾波出來的結果時錯誤的，這就解釋了之前一些不能解釋的現象，在解決這個問題之后，車的穩定性得到了很大的提高，可以跑更久的直線。
但是現在又出現了新的問題，就是更換電池盒之后，參數調配一直到不了一個很耦合的狀態，PID參數的設置存在問題，整個系統的抗干擾能力不強。
2021.3.29
基本完成車的直立，可以維持較久的平衡。之前沒有對積分項進行清零，并且之前使用的微分項存在方向問題，寫反了。
后面繼續優化參數，增加平衡的抗干擾性。
后續開始循跡調試。
2021.3.30
單車的平衡直立基本完成，總結的經驗如下：
1. 在PID的三個參數中，P的作用的是主導整個的系統的左右偏移量，P要足夠的大，才能保持單車的直立；I的作用是車的慣性量，建議給小小一點，大了之后會影響車回正的速度，而且要對總的誤差進行限幅，最后還要對總的誤差進行清零（每次過零點的時候，防止出現車突然倒地的情況）；D的作用是阻礙車的運動，減少超調現象的出現。
2. 整個車的機械結構盡量的穩定，每次更改結構之后就要重新更改參數，增加工作量，且之前的參數不具備太大的參考意義。車的整體重心盡量保持一致。
3. 在陀螺儀濾波時，分清楚底層驅動變量。后面才發現之前的一個變量使用錯誤，導致前面調試了一個錯誤的方向，參數沒有太大的參考意義。
4. 電機盡量的實現閉環，這樣會增加發車以及車運行過程中的穩定性。
5. 陀螺儀濾波很重要，這個會直接影響整個系統的正確判斷，濾波后的曲線盡量的光滑，沒有較大的突變點，在單車的控制系統中，一個較大的突變點就會導致單車倒地。尤其要注意靜止時突然出現的方向尖峰，及其致命。
6. 要是濾波算法沒有問題的情況下，會存在一套與之較為耦合的參數，所以，濾波參數確定之后，要精細的調節PID參數，先P再I最后D。
蜂鳴器 P43
按鍵 P42 P41
編碼器 DIR=P35 A=P34
撥碼開關 P72 P73
ADC P00 P01 P14 P15 P16
無線串口 UART4_TX_P03 UART4_RX_P02 SET_P04_RTS
舵機 P74
電機 P60 P62
ICM20602 （陀螺儀）SCL-P25
SDA-P23
SA0-P24
CS-P26
ISP（顯示屏） SCL-P25
SDA-P23
RST-P20
DC-P21(液晶命令位引腳定義)
CS-P22
BL-P27(液晶背光引腳定義)
單車組調試規范
在整個車的框架搭好之后，開始整個的調試，小組三個人，一天三班倒。為了更好的調車，方便交流，采用如下的規則：
1. 調試參數時，需記錄下每個參數對應的數值，以及該參數下的效果
2. 組員在使用框架代碼時，如果有改動，則需要表明改動的日期、姓名、改動的地方。
3. 如有添加新的代碼，則也需要注明編寫的時間、姓名、以及簡單的介紹一下該函數的大概用途。
4. 在整個代碼框架搭好之后，就在這個框架上進行修改，每個人在完成自己工作后，將文件名改成日期+姓名+上午/下午/晚上，下一個人在此代碼上繼續修改。
5. 每個小組成員，在完成自己當天任務后，寫一個簡短的日記，記錄自己今天所作的事情以及遇到的問題。
程序下載(代碼不完整,僅供參考):
16F代碼（帶DFP).7z
(332.89 KB, 下載次數: 13)
2022-5-25 16:51 上傳
點擊文件名下載附件
下載積分: 黑幣 -5
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
