選的是無線充電組，理由是隊友覺得好玩就選了

校賽的通過是意料之中，隊伍組成是兩個可靠的硬體隊友和我這個姑且算是可靠的純程式碼人。

記一下流水賬

我不在的二月與三月上旬

git的第一次提交是在2月16日

蘇州疫情導致了本該二月就能回校的我硬是拖到了三月中旬（甚至再晚一天回校就真再也回不了學校了）。

在這期間兩個硬體隊友已經完成了無線充電的任務、以及微控制器核心板、主控板的設計。

雖說我沒法碰到板子，但是也做了挺多能做的事情。在這期間熟悉了ide的使用、瞭解了rtt的核心實現並能夠進行基礎的使用、TC264基本外設的使用（逐飛套皮套皮庫）、同時準備了車的程式碼框架。

慢慢進步的三四月

得益於在家就完成的程式碼框架，我在車搭好第一天就完成了底層速度環的調參。緊接著則開始著手影象巡線程式碼的編寫，印象中第一次積分賽什麼元素都不能識別，甚至彎道都不好跑。
在第一次積分賽過後開始去找別人的方案，看了不算多，主要還是想多自己實現，看一點寫一點，各種方案相互縫合，各種賽道的元素識別還老是相互誤判，從git的記錄上來看，從T字路口到三岔到環島，陸陸續續寫了二十天才能勉勉強強把整個賽道跑完。第二次積分賽也算是順利通過了。

擦輪胎的五月

之前的勉強跑完一整圈並沒有包括坡道，這點是一直沒能解決的問題，直到我們學著四輪組開始擦輪胎才發現，輪胎和賽道的保潔真的很重要，沾灰和不沾灰完全是兩個效能。
之後就開始每跑一次都要擦輪胎，甚至到了看見別人沾灰輪胎都要開始渾身不自在的程度。
不過擦完輪胎就發現我們的車開始內切嚴重，而到後面更是發現如果不內切影象很容易出bug的問題，因此選擇直接不管內切嗯調，就這樣給我們的車加上了無線充電和訊號檢測。
很讓人想吐槽的是，我們一開始並不知道比賽使用的龍邱的發射端，因此現在一共有一個龍邱和兩個逐飛的發射端，從充電角度來講區別確實是沒大區別，但是訊號檢測的角度上講，龍邱和逐飛的發生端在我們訊號檢測板上檢測出來的訊號居然是有明顯不同的，龍邱能被檢測到的距離更遠，這就很蛋疼，調好了逐飛線圈的停車但是在龍邱板子上效果卻不是很好。
臨時遇到bug就儘量修，就這樣縫縫補補的跑完了校賽。

目前的方案

準備把車remake了，感覺影象的底層不夠牢固，程式碼寫的還不夠好，不破不立，準備直接重寫一套控制邏輯和影象處理程式碼。

控制

一層轉向環pid，當前值由影象處理得到的值提供，輸出值一個加一個減到速度環的基礎目標值上實現轉向
當然兩個環都是基礎的pid，其中速度環為了抗積分飽和加入了簡單的積分限幅。

影象

採用的邊緣檢測來提取賽道邊緣資訊，而元素識別的思路是檢測幾個關鍵的特徵點並分類，之後通過特徵點來判斷當前賽道的元素，最後進行補線操作，將中線的整體斜率作為輸出值。

檢測線圈並停車

隊友的訊號檢測板範圍可以在較遠的位置檢測到，與此同時其也有一個特性：當訊號檢測板位於線圈外時訊號幅度呈現隨距離減小而增大的趨勢，而當訊號檢測板進入線圈後則會出現訊號大小驟降的情況。因此思路就是當檢測到訊號大於一個閾值之後減速，等到訊號驟降的時候剎車。

其他想瞎BB的

現在遇到的問題是影象的程式碼非常的不可靠，魯棒性非常差，主要原因其實是底層特徵點檢測寫的非常粗糙，同時幀率也不高。然後線圈檢測的魯棒性也不夠高。主要也是意識到自己的程式碼能力還不夠強，做事也不夠細心，本應該多參考其他方案的卻心急就先寫了，導致效果非常不好。

期末考試之後（也可能是期末考試之前）要做的應該就是重構程式碼，順便想封裝一個調參的庫，通過螢幕和按鍵進行簡單的調參吧。