# 109-2 電資工程入門設計與實作 第三組 ## 成員 * 班別:週一班 * 組別:第三組《55688臺灣大學車車隊》 * 組員1:江秉城、B09901044 * 組員2:葉思妤、B09901070 * 組員3:陳少翔、B09901067 --- ## 第五週紀錄 - 組車 <h3>課堂應完成事項(**下課前必須找助教檢查**)</h3> <ul> <li>車子組裝完成Part 1(模組)</li> <li>車子組裝完成Part 2(電源線)</li> <li>車子組裝完成Part 3(訊號線)</li> </ul> > 給助教檢查[name=趙少緯] <h3>實際達成事項:</h3> * 車子組裝完成Part 1(模組) * 車子組裝完成Part 2(電源線) * 車子組裝完成Part 3(訊號線) * 用藍芽操控車子 <h3>組內討論事項:</h3> <ul> <li>3/22(一)下課前找助教檢查過線路,並通電。拿了電池回去充電。</li> <li>3/22(一)下課後到隔壁MkS接完所有訊號線。<b style ="color: Green">更:OpenLab已拿去測試</b></b></li> <li>電源線都有接正確。降壓模組運行正常,按壓兩邊按鈕可以檢視輸入輸出電壓。</li> <h4>訊號線連接腳位紀錄</h4> <ul> <li>紅外線感測模組:管他GVS是甚麼順序,我們檢查過兩次了,不會接錯。</li> <img src ="https://scontent-tpe1-1.xx.fbcdn.net/v/t1.15752-9/163018027_288365055989294_3529334687017642991_n.jpg?_nc_cat=103&ccb=1-3&_nc_sid=ae9488&_nc_ohc=tcfR2L7VS9wAX_EcWSk&_nc_ht=scontent-tpe1-1.xx&oh=f21794af2bbb6b629c68c6224dfd676b&oe=607DE366" title ="紅外線感測模組" width ="400px" height ="300px"> <li>藍芽模組:整排插在COM上,連順序都不用改 <br><b style ="color: Green">更:這是錯的,OpenLab已重插 </b></li> <li>RFID模組:找不到3.3V的腳位,詳見下方問題說明。 <br><b style ="color: Green">更:OpenLab已解決</b></li> <li>馬達接線:車尾朝車頭方向看。 <br>左輪是A,接L298N的output1,2。由ENA、IN1,2控制。 <br>右輪是B,接L298N的output3,4。由ENB、IN3,4控制。 <br>L298N的IN1,2,3,4分別接Arduino的Output7,6,5,4。 <br>L298N的ENA和ENB分別接Arduino的Output9,3。 <br><b style ="color: Green">更:OpenLab換過L298N </b> </li> </ul> </ul> <h3>組員分工:</h3> <ul> <li>共同完成:組車、焊接、接線、OpenLab有接力出現</li> <li>特殊分工:<ul> <li>江秉城:電路檢查、Arduino和電腦溝通、RFID檢測、工作紀錄簿</li> <li>葉思妤:藍芽檢測、馬達控制、工作紀錄簿</li> <li>陳少翔:電路檢查、Arduino和電腦溝通、藍芽檢測、馬達控制</li> </ul></li> </ul> <h3>遇到問題之處理狀況、解決方式:</h3> <ul> <li>左左板左中板左右板等等...沒有發現這些板子上該印有的標示。一開始左左板與左右板放反,仔細比對一下pdf的圖就解決了。</li> <li><p>arduino 電源頭焊接時兩條線須從中間穿出不然會裝不進去</p></li> <img src ="https://i.imgur.com/EMOhPtZ.jpg" title ="arduino 電源頭" width ="400px" height ="250px"><br> <li><p>arduino 左後銅柱與洞沒對到,而且螺絲頭會卡到板子上的黑色腳位<br> <b style ="color: green">解決:三隻腳鎖起來已夠穩定,故不鎖</b></p></li> <img src ="https://i.imgur.com/7yzr9BD.jpg " title ="距離一旁黑色插槽過近" width ="400px" height ="300px"> <li><p>arduino 電源線太短接不到,儘管嘗試換路徑仍然無法<br> <b style ="color: green">解決:怕電源接觸不良故不另接電線加長,剪了30cm的電線重新焊</b></p></li> <img src ="https://i.imgur.com/GpfmHWb.jpg" title ="太短了QQ" width ="400px" height ="300px"> </p> <li>螺帽在木板裡似乎會鬆動,導致鎖螺絲不好鎖<br> <img src ="https://i.imgur.com/o6aBLZ6.jpg" title ="理想圖" width ="400px" height ="300px"> <img src ="https://i.imgur.com/KEgfSWL.jpg" title ="實際圖" width ="400px" height ="300px"> 上圖為理想狀態,但因切割出來的孔洞大小與螺帽不合,造成會呈現下圖狀態,使得螺絲不好與螺帽的孔對準,且因螺帽沒有被固定,鎖的時候會跟著旋轉。 <b style ="color: green">解決:先用鉗子抵著,幫忙固定螺帽。可以考慮調整雷切規格。亦或是像下圖一樣填入黏土類的東西幫助固定。</b></p></li> <img src ="https://i.imgur.com/ZEJPT9C.jpg" title ="改善圖" width ="400px" height ="300px"> <li><p>電池充電時有(貌似是接觸不良)問題。電池位置沒喬好的話,藍色充電器主機會一直因為斷電而重新啟動。 <br> <b style ="color: Green">更:OpenLab已解決</b></p></li> <img src ="https://i.imgur.com/HPyv55h.jpg" title ="電池餵食圖" width ="400px" height ="300px"> <li><p>RC522的3.3V不知道該接在Arduino擴充板上的哪個腳位。查過Arduino sensor shield v5.0的datasheet後,發現唯一一個3.3V的腳位長在Bluetooth那排...所以不知道該怎麼接 <br> <b style ="color: Green">更:OpenLab已解決</b></p></li> <img src ="https://i.imgur.com/U31vhKn.jpg" title ="Arduino sensor shield v5.0的datasheet" width ="400px" height ="300px"> <h3>3/24 OpenLab進度更新:</h3> <ul> <li><b style ="color: Green">Arduino板和電腦溝通正常</b> <br>原本電腦找不到port,後來去裝置管理員才找到。後來在安裝新版Arduino的驅動程式前,助教就從以前的車車拆舊的Arduino給我們了。後來又解決了藍芽插到0,1pin等等問題,終於完成Arduino和電腦的溝通。 </li> <li><b style ="color: Green">RFID目前功能正常</b> <br>RC522的線接對了!原來擴充板上的所有V洞都是3.3V</li> <li>藍芽的線也重接,因為我們插到擴充板上的COM,那是傳說中的Arduino的0和1腳位。難怪之前一直覺得板子有問題,上傳一直失敗。 藍芽Rx接2,Tx接8腳位 </li> <li>目前藍芽正常運作,也寫好程式透過電腦操控車子。目前只能直行,w指令代表往前,s指令代表向後,其他則代表停止</li> <li><b style ="color: Green">馬達目前功能正常</b> <br>原本的L298N的Enb壞掉,導致只有單邊輪子可旋轉,更換成新的L298N則正常運作</li> <li>紅外線模組</li> <li><b style ="color: Green">電池沒有問題</b>,姑且就當他功能正常</li> </ul> </ul> <h3>課程建議(選填):</h3> <ul> <li>看到不少組都有20cm電線不夠長的問題,感覺這是設計上沒注意到的點。</li> </ul> <h3>想說的話(選填):</h3> <ul><p>某助教是不是演過2018電機營的劇啊XD</p> <p>蟲蟲退散</p> </ul> ## 第五週批閱區 - 組車 ### 助教批閲欄 * 非常詳實的記録! 用html做工作記録簿,真的讓工作記録簿增添幾分色彩,非常厲害!但是要記得,該寫的點都要寫到哦~ * 如果是2018電機營的話,應該是B06的學長姐哦~ * 很高興看到你們利用OpenLAB時段,將問題都解決了。之後如果有問題的話,也可以到OpenLAB或課堂上詢問助教哦~ > [name=趙少緯] ### 教授批閱欄 * 評分等第: A- * 教授回饋 * 記錄的很詳細唷~ 圖文並茂非常清楚! > [name=蘇柏青] ## 第六週紀錄 - 循跡 ### 課堂應完成事項(**下課前必須找助教檢查**) * 可不輔助、不出軌,連續繞行橢圓狀地圖2圈 > 給助教檢查 > 3/31 OPENLAB PID CONTROL全部完成 > [name=蔡昀哲] ### 實際達成事項 (必填) * 能連續繞行橢圓軌道 * 能連續繞行進階軌道,但轉彎較大處會卡 * 實作 P control、 PD control、PID control * 用藍芽將行進時的error、dError、sumError傳回 ### 組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等) <ul> <li> <b style ="color: orange">想法:</b><b>把輪子包成一個 class</b>,有 member function 可以讓輪子做出給定 PWM 的反應(直走多快、轉彎多少)。<br> <b style ="color: orange">結果:</b><b>不直接控制馬達轉速</b>,封裝完整,維護較易。 </li> <br> <li> 為探討 P, I, D 分別在循跡中的作用,我們依次將其中二者的影響歸零,結果如下: <ul> <li>純 P control:主要的修正及對於直線的小幅修正,<b>走直線晃動少。</b></li> <li>純 D control:容易前後原地卡頓。因 <code>dError</code> 只有開始走歪的瞬間出現,可幫助<b>軌道曲率有變</b>(彎道進直線)時過得流暢。</li> <li>純 I control:爆衝不受控制,但能幫車車<b>過急彎</b>。容易修正過度,推測為<b>直線左右擺</b>的原因。</li> </ul> </li> <br> <li> <b style ="color: orange">想法:</b>修正量不夠,將所有參數調大,讓轉彎更順。<br> <b style ="color: orange">結果:</b>修正過大會左右晃,但<b>找到適合的參數比例</b>似乎更重要。 </li> <br> <li> <b style ="color: orange">想法:</b>將 <code>sumError</code> 一段時間歸零。<br> <b style ="color: orange">結果:</b>急彎轉直處不錯但最彎的地方轉不夠,<b>不歸零似乎更加順暢</b>。 </li> <br> <li> <b style ="color: orange">想法:</b><code>sumError</code> 幫助急轉卻造成直線左右擺,故嘗試在直道( <code>error</code> 值小於25)只用 P control。<br> <b style ="color: orange">結果:</b>以直道測驗,<code>error</code> 在此範圍的機會不大,故還是<b>調好比例比較有效</b>。 </li> </ul> ### 組員分工 (必填) <ul> <li>共同完成:調整系統參數、改善車子</li> <li>特殊分工: <ul> <li>江秉城:馬達程式、藍芽傳輸資料、拍攝</li> <li>葉思妤:系統整合(窮舉、P control...)、藍芽傳輸資料</li> <li>陳少翔:調整紅外線靈敏度、馬達程式、拍攝、藍芽傳輸程式</li> </ul> </li> </ul> ### 遇到問題之處理狀況、解決方式 (必填) <ul> <li> 一開始寫馬達程式時間有點久。<br> <b style ="color: Green">解決:腦中的想法應先寫下來,有助統整思考,避免錯誤,也較好與隊友溝通。</b> <p> <img src ="https://i.imgur.com/YnFL82q.jpg" title ="上方為輪子 class 的組成,下方為 P control" width ="400px" height ="450px"></p> </li> <br> <li> 剛啟動時車子會先失控一陣。<br> <b style ="color: Green">解決:後來發現是 motor check 啦!</b> </li> <br> <li> 右輪遇到地面稍不平整會空轉,特別在兩輪速度差大時更嚴重。<br> <b style ="color: green"> 解決:助教建議在輪子內塞紙條或將一前輪取下,成效皆不好;後換一個摩擦力較大的輪子有好一些。</b><br> <b style ="color: orange">想法:</b>在輪內塞重物或許更好,能使重心在後,較不會空轉,<b style ="color: red">仍需持續思考改善</b>。</br> <p> <img src ="https://i.imgur.com/XJSIY7z.jpg" title ="單輪車" width ="560px" height ="300px"><br> </p> </li> <br> <li> 調整紅外線靈敏度時調太多,造成暴衝,且各個感測器之敏感度已不相同。<br> <b style ="color: Green"> 解決:利用軌道板將靈敏度統一,調至正對白色恰會感測到訊號,對黑色很敏感。</b><br> <p> <iframe width="560" height="315" src="https://www.youtube.com/embed/0B4da_U9m24" title="P control 🎛️ - advanced circuit" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </p> </li> <br> <li> 測久了有時會突然停下來。<br> <b style ="color: red"> 待解決:助教說電流過大時 arduino 會重啟,建議將電壓調高(why?),但電池沒電了QQ。</b><br> <p> <iframe width="560" height="315" src="https://www.youtube.com/embed/IKfrBEOMH8Y" title="P control 🎛️ - advanced circuit" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </p> </li> <br> <li> 不明原因電源線斷開了。<br> <b style ="color: green"> 解決:重新焊起來。 </b><br> <p> <img src ="https://i.imgur.com/60Hf4Bu.jpg" title ="斷線"width ="560px" height ="250px" > </p> </li> <br> <li> PID control 之調整,逐步找到適合的係數。發現主要是靠 P 控制,但 <code>dError</code> 參數不可太小,否則直線容易晃,最佳係數在2至3間。<code>sumError</code> 因長時間累積,故係數需極小。 <p> |V_Base|kP |Error|kD|kI|Remarks| | -- | ----- | --- | ------ | -------- | ---- | | 80 | 1 | 100 | 2 | 0.008 |小彎微卡大彎順| | 80 | 1.2 | 100 | 2 | 0.005 |有點太快 容易衝出去 左右晃| | 80 | 1.2 | 100 | 3 | 0.01 |小彎修正次數多 不太會左右晃| |100 | 1 | 100 | 1.5 | 0.02 |太可怕了,根本瘋狗亂衝| |100 | 1 | 70 | 5 | 0.03 |太可怕了,根本瘋狗亂衝| |100 | 1.5 | 100 | 1 | 0.007 |左右晃 小彎轉不過去| |85 | 1 | 100 | 3 | 0.05 |過度修正| |100 | 1 | 100 | 1 | 0 |修正量稍嫌不夠| |70 | 1 | 100 | 6 | 0.02 |一直左右晃| |80 | 1.2 | 100 | 3 | 0.03 |急轉彎表現不錯,仍有點修正| |80 | 1.4 | 100 | 5 | 0.02 |左轉很順,右轉不夠快,best!| </p> </li> <br> <li> 想透過藍芽讓車子邊跑邊傳輸 <code>error</code> <code>dError</code> <code>sumError</code> 未成。藍芽可溝通,但卻顯示不出資料,有一次意外有顯示,卻不知如何出現的。<br> <p> <b style ="color: green">4/7 OpenLab 透過層層除錯已解決。須注意以下幾點:</b> <ul style ="color: green"> <li> 藍牙模組傳資料給 python 端時需加 <span style ="color: black"><code>'\n'</code></span> (如同輸入時按 Enter 一般) 才會立即在 python 端顯示。我們的理解是,若未換行,輸入將持續在 IO buffer 堆積,累積無法負荷後才會顯示幾百行的 squeezed text (如圖)。<br> <p> <img src ="https://i.imgur.com/mZP9nPd.png" title ="Squeezed text" > </p> <p> <img src ="https://i.imgur.com/iYF6tVQ.png" title ="點開就長這樣" > </p> </li> <li> <span style ="color: black"><code>BT.write()</code></span> 只能吃 <span style ="color: black"><code>char</code></span>,數字會轉換為 ASCII code,所以 <span style ="color: black"><code>double</code></span> 形式的 <span style ="color: black"><code>error</code></span> 寫不出東西,且須注意 <span style ="color: black"><code>int</code></span> 與 <span style ="color: black"><code>char</code></span> 之間的轉換(手動加48)。 </li> <li> python console IO 比較慢,顯示會跟不上藍芽,使用 <span style ="color: black"><code>delay(20);</code></span> 使 python 與序列埠視窗數字能同調。 </li> <li> 原本想即時看到 P, I, D 各自對時間的函數圖,但由於電腦接收訊息沒那麼快,所以這個計畫目前擱置呈放棄狀態...... </li> </ul> </p> </li> <br> <li> 4/7 OpenLab 發現左右馬達的轉速不一,兩輪給相同的 power 卻不會直行而是往左偏。<br> <b style ="color: red"> 待解決:當場試驗後將右輪最終速度 *0.9 可走直線,但後來發現其實沒什麼實質改變,一時碰巧罷了。</b> </li> <br> <li> 用 counter 計算一定時間將 <code>sumError</code> 歸零,卻突然暴衝?<br> <b style ="color: green"> 解決:counter 沒正確歸零,而且週期太慢了,調整為每150次歸零。但最新的程式碼並沒有定期歸零,原因見上方「組內討論」。</b> </li> <br> <li> 如何減少直走時的搖晃情形?<br> <b style ="color: green"> 解決:考量到急彎處 I, D 的貢獻才較明顯,所以設定在 <span style ="color: black; font-weight: normal"><code>error</code></span> 超出某個範圍後才起作用。但這在4/8的更新中被拿掉了,因為發現用 <span style ="color: black; font-weight: normal"><code>error</code></span> 判斷直道或彎道並不完全正確。</b> <p> <iframe width="560" height="315" src="https://www.youtube.com/embed/XDsqGrPV4FI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </p> </li> </ul> <h3 style ="color: rebeccapurple; font-weight: bold">—————————————以下為4/8的更新內容—————————————</h3> <ul> <li> 重新思考 P, I, D 分別的影響各是甚麼。搭配前面的結論,只要 <code>error</code> 存在,P 就會把車子推往 <code>error</code> 反向,但<b>在中則不修正(儘管車頭是歪的)</b>;只要車子的 <code>error</code> 正在往正的方向增加,那 D 就會把車子往右推,<b>不管黑線是正在偏離還是修正回來</b>; I 的功用就是<b>在彎道大推特推</b>。 </li> <br> <li> 發現只要<b>基礎速度夠快</b>,走直線時的<b>搖晃情形就越不明顯</b>。 </li> <br> <li> 如果彎道轉過頭,應該就是 I 或 D 太大。修正後的確就好了。 </li> <br> <li> 輪子仍然會空轉,很偶爾會在小彎處甩尾,然後整台車直接噴出去...之後有機會應該測試一下教室地板是否會這樣(反正整台車改裝後應該也得重調參數)。 </li> <br> <li> 目前參數調整為 <b>P=1.4, I=0.02, D=5</b>。在不同彎道都順,但在兩小彎之間會卡,應是目前最好的一組參數(下方錄影有將倒退速度調慢,約從-130調成-70)。 <p> <iframe width="560" height="315" src="https://www.youtube.com/embed/q4uhnokjiPw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </p> </li> <br> </ul> <a href ="https://www.youtube.com/watch?v=xZ324qkjUQ0&list=PLsqh0Iu1huHWqxN9JdkD07Br0J9cjmKfo">其他影片在這裡</a> ### 課程建議 (選填) * 好棒 ### 想說的話 (選填) * (╯‵□′)╯︵┴─┴ * 怎麼還在PID control的部分就在系館越待越晚了... * 兩點了... ## 第六週批閱區 - 循跡 * 助教批閱欄 * 紀錄很詳實!感覺到你們的用心 :smiley: * 其實滿多組都遇到空轉問題的,上學期我們試過(1)增加負重 (2)萬向輪改成一個 (3)在馬達與車體之間墊一個螺帽,並調整馬達螺絲鬆緊,使輪子正向力增大、增加抓地力。雖然偶爾還是會空轉,但有改善一些,給你們做參考~ * 你們的循跡設計上會倒退滿特別的,然後不要太晚回家 XD > [name=周奕慧] * 教授批閱欄 * 評分等第:A * 教授回饋:非常完整的紀錄!作業部分都完成了,加上清楚的PID參數分析討論,甚至還用藍芽回傳偏移量資訊,很讚!!! 另外,"課程建議"可以寫一些你們覺得本周或整體課程可以改進的方向,如教學方式、內容多寡或難易度等,作為以後的參考喔! > [name=陳士元] ## 第八週紀錄 - 指定題介紹 ### 課堂應完成事項(**下課前必須找助教檢查**) <ul> <li> <b>第零題:馬達功率</b> &nbsp;&nbsp;6V×0.18A =1.08W </li><br> <li> <b>第一題:能量估算</b> &nbsp;&nbsp;<b style ="color:red">訂正:驅動模組與降壓模組的功率指的是最大輸出功率,而不是消耗功率</b> <ol> <li>300+1080×2+86+75×5+33 =2854mW</li> <li>239mA</li> <li>9.414hr</li> </ol> </li><br> <li> <b>第二題:記憶體估算</b> <ol> <li>每條邊會增加 8 Bytes(包括距離),考慮 worse case,每條邊皆與其他邊接在一起(C<sup>150</sup><sub style="margin-left:-20px">2 &ensp;&ensp;</sub>),共 87.3 KB &nbsp;&nbsp;<b style ="color:red">訂正:每個 node 最多只會接 4 個 node</b></li> <li>queue 最多會存 150×0.75×2 Bytes,加上 parents 與 check flag 共 675 Bytes</li> <li>No</li> </ol> </li><br> <li> <b>第三題:藍芽速率估算</b> <ol> <li>480 &nbsp;&nbsp;<b style ="color:red">訂正:要傳碰到轉彎塊,而因地圖在電腦上,後續也要傳輸轉彎路線給車車</b></li> <li>可</li> </ol> </li><br> <li> 完成甘特圖 <iframe src="https://hackmd.io/joBq0szlQDaQOxQ5F4nlEQ" width="700" height="300"></iframe> </li><br> <li> 完成系統方塊圖<br> <img src ="https://i.imgur.com/6P5bGJa.jpg" title ="系統方塊圖" height ="200px"> </li><br> </ul> > 甘特圖記得附上組員名字喔,還有是什麼task也要寫清楚[name=俞建琁 4/12 17:00] > 給助教檢查[name=俞建琁] ### 實際達成事項 (必填) * 問題回答並訂正 * 甘特圖完成 * 系統流程圖完成 <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> <ul> <li> <b style ="color: orange">想法:</b>地圖所需空間應可做更精細估算。<br> <b style ="color: orange">結果:</b>一條連接線會佔四個 <code>int</code> (2Byte) 的空間(兩個 node 記住對方和邊的長度),而最多線的情況是 node 排成四方形,除四角和邊外每個 node 都接四條線。而邊長最短的應是 15×10 的長方形, 有 (13×8×4+13×3×2+8×3×2+2×4)/2 =275 條線,所以空間為 275×4×2 =2200 Bytes </li> <br> <li> <b style ="color: orange">想法:</b>不要用 <code>int</code> 而用 <code>unsigned char</code> 存 node。<br> <b style ="color: orange">結果:</b>可在 code 裡實作看看,這樣只需 1 Byte。 </li> </ul> <h3 style ="color: rebeccapurple; font-weight: bold">————————以下 4/14 Open lab 詢問助教後的問題記錄————————</h3> <ul> <li> <b style ="color: orange">問題:</b>因為分數是 xy 座標的差加起來,<b>不一定路徑最長最高分</b>,有可能跟起點的差只有一點點。 <br> <b style ="color: orange">討論:</b>在時間不足的狀況下,只能挑某幾個點走,不過<b>如何判斷走的效益</b>是很大的問題,BFS 分析同時還需考慮其他因素,目前仍在思考。此外,車子轉彎也會有停頓的時間,<b>轉彎次數</b>或許也應列入考慮。 </li> <br> <li> <b style ="color: orange">問題:</b>助教說<b>直接傳所有的轉彎指令給車車</b>快很多。 <br> <b style ="color: orange">討論:</b>可試試看,但沒有電腦一步步控制,不知會不會失控。 </li> <br> <li> <b style ="color: orange">問題:</b>根據往年經驗,之前<b>測地圖的循跡參數貌似偏大</b>,還需要調整。 <br> <b style ="color: orange">討論:</b>除調整 PID 之外,看能否針對<b>直角轉彎</b>優化,加快速度;倒車也需思考,因此時紅外線在車體後方,調整不即時,但倒車可省下迴轉時間,到底要不要實作待定。 </li> <br> <li> <b style ="color: orange">問題:</b>轉彎時怎麼知道轉多少要停? <br> <b style ="color: orange">討論:</b>關於這點助教說只能盡量測,憑經驗。不過助教提到轉彎或迴轉時可以<b>邊邊一偵測到黑線就停</b>,利用慣性修正,再進入循跡。 </li> <br> </ul> * 組員分工 (必填) <ul> <li>共同完成:問題討論、紀錄簿</li> <li>特殊分工: <ul> <li>陳少翔:OpenLab</li> </ul></li> </ul> * 遇到問題之處理狀況、解決方式 (必填) * 主要是用Mermaid畫甘特圖的一些小問題,例如日期格式改MM/DD和移除"今日紅線"。上網查找,很快就解決了。 * 課程建議 (選填) * 感覺可以多放一些甘特圖和系統流程圖的參考範例。 * 想說的話 (選填) * OHO * 誰打錯我的名字😠😠 ## 第八週批閱區 - 指定題介紹 * 助教批閱欄 * 助教回饋 * 看到你們討論好多的問題,感受到你們的細心和用心:smile: * 系統方塊圖可以照投影片p.38那樣分成Python、資料溝通和Arduino。且建議打在電腦上,這樣之後如果想要改,比較方便。 > [name=俞建琁] * 教授批閱欄 * 評分等第: `A-` * 教授回饋: * 問題討論很多、很仔細,希望你們在未來幾週中的實作中可以逐一思考清楚,讓車車的功能達到最佳的狀態. * 如果可以的話,甘特圖建議可以再把分工作得更細一點。尤其是分配給三個人同時作的事要儘量透過討論溝通,再拆解成更具體的subtasks,並化成具體的時程,才能真正發揮這個甘特圖的功用喔! > [name=蘇柏青] ## 第十週紀錄 - 指定題進度報告 <h3>預計完成事項 (必填)</h3> <ul> <li>BFS路線分析、Python藍芽</li> <li>Arduinou依收到的路線指示行走地圖</li> <li>成功走完E型地圖,並獲取RFID訊息</li> </ul> <h3>實際達成事項 (必填)</h3> <ul> <li>能夠將跑遍整個地圖的指令串生成,但僅由近走到遠,未考慮分數</li> <li>成功讀到RFID並將ID傳回給Python</li> <li>若在節點卡住能手動幫忙扶正的話,可以成功走完check point地圖</li> </ul> <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> <ul> <li> 流程圖<br> <img src ="https://i.imgur.com/fe9rWAl.png" title ="系統方塊圖" width ="560px" height ="400px"> </li><br> <li> <b style ="color: orange">問題:</b>測試 Python 是一次傳整個字串,還是拆分成 <code>char</code> 一個一個傳<br> <b style ="color: orange">結果:</b>在 loop 裡放 <code>delay()</code> 。在 Python 端輸入一串時,Arduino 序列埠監控視窗顯示的是一個一個跳出來的字。因此推論 <b>Python 是一次傳完,藍芽端有個接收 buffer,會一個一個字元給序列埠。</b> </li> <br> <li> 我們的作法是將地圖分析出來的結果用一次全部傳給 Arduino,arduino 會再遇到節點時,依照指令行走。 </li> </ul> <h3>組員分工 (必填)</h3> <ul> <li>共同完成:車子參數調整、DebugBFS 的 Code</li> <li>特殊分工: <ul> <li>陳少翔:BFS、檔案的讀入</li> <li>葉思妤:Arduino 相關(RFID 感測、<code>motorWriting()</code>)</li> <li>江秉城:Python 和 Arduino 藍芽溝通</li> </ul> </li> </ul> <h3>遇到問題之處理狀況、解決方式 (必填)</h3> <h3 style ="color: rebeccapurple; font-weight: bold">—————————————以下 4/26測試紀錄————————————</h3> <ul> <li> 遇到一大堆 coding 環境的問題,舉例如下。執行 sample code 的 BT.py 時, VSCode 跟我說 <code>AttributeError:No module name 'serial'</code> ,所以我就去 Powershell 執行 <code>pip install serial</code>。結果VSCode跟我說serial沒有Serial這個東西。<br> <b style ="color: Green">解決:Uninstall serial 和 pyserial,只在電腦上install pyserial。是Python自己搞混兩個套件所產生的問題。</b> </li> <br> <li> sample code 裡 maze 的資料結構與先前有所不同,所以原本 BFS 作業的 code 不能拿來用<br> <b style ="color: Green">解決:努力看懂新的 code,而且發現有一些多餘的變數似乎可以拿掉(如 nodes[ ]),還有東西南北的代表數字不好運算,稍微改了一下。</b> </li> <br> <li> 把 Arduino 程式碼加上迴轉等功能後,車子居然忘了怎麼循跡。推測是在改 Code 時有動到其他架構。<br> <b style ="color: Green">解決:發現是條件判斷出了問題,使車子沒依照循跡走。</b> </li> <br> <li> 老師說我們的優先順序需要調整,應該先讓車子能正確轉彎與前進,再寫 BFS<br> <b style ="color: Green">解決:因為 BFS 已經完成,目前先專注於轉彎、迴轉等參數的調整。</b> </li> <br> <li> 因我們是採用一次傳輸全部移動指令,若在出節點時沒有成功接上路,在紅外線無偵測到時會後退,使得車子再次感應到圖一個節點卻直下一個動作。<br> <b style ="color: Green">解決:改變條件判斷,在兩輪速度都為負值(後.退)時不算感應到節點,但在再次前進時依然會感應到,故又使用<code>millis()</code>,在一定時間內不能感應到節點。</b> </li> <br> <li> 因車車在節點時依照指令移動,無法循跡,且節點為一大黑色區塊也無法正確循跡,若車車沒偵測到線便會後退,導致車車若稍微歪了便容易卡在黑塊角角。<br> <b style ="color: red">未解決:本想用擺頭的方式代替後退,即左右旋轉且幅度逐漸加大尋找黑線,但偵測錯誤的機會變得更高了。 </b><br> <b style ="color: green">更:下方解決了直道的問題,但彎道仍不穩定。</b> </li> <br> </ul> <h3 style ="color: rebeccapurple; font-weight: bold">—————————————以下 4/29<span style ="color: red">~30</span> 測試紀錄————————————</h3> <h4>  由於車車在黑塊時的動作和循跡是獨立的(除了直行之外),因此我們需要精準控制車車的轉向、迴轉。為了達到這個目的,我們測試了多種轉彎方式,但成效皆不彰,而且車體極不穩定,每次測試皆有顯著差異,而我們將過程中遇到的一系列問題整理在此段落。</h4> <ul> <li> 載重前轉彎方法測試<br><br> |轉彎方式|結果(負重前)|影片| | -------- | ----- | --- | | 兩輪一前一後原地轉 | 有點卡 中軸不在定點易打滑 | <a href ="https://youtu.be/KsBi1B9q-kM">這兒</a> | | 兩輪向前 有速度差 | 比較不打滑 但旋轉半徑有點大 | X | | 先後退 兩輪向前 | 較前者優 但動作還是太大 不穩定 | X | | 先後退 一輪不動 | 減小動作 讚 | <a href ="https://youtu.be/7IeatSv08MM">這兒</a> | 一樣的參數下,右轉比左轉轉動幅度更大,可能跟重心偏左有關(電池重量),而且實際跑地圖時轉彎的行為和單獨測試時相當不同,可能與前進時有慣性且會滑有關,故需直接在車車跑地圖的時候觀察調整。 </li> <ul> <li>車輪的速度變化太大會造成打滑。<br> <b style ="color: Green">解決:車車需要「旋轉」時,我們一度採用了逐步升高轉速的方法,以下為右轉指令。</b> ```arduino= MotorWriting(wheel_L,wheel_R,0,0); delay(100); MotorWriting(wheel_L,wheel_R,90,0); delay(80); MotorWriting(wheel_L,wheel_R,150,0); delay(100); MotorWriting(wheel_L,wheel_R,200,0); delay(150); MotorWriting(wheel_L,wheel_R,120,0); delay(100); ``` </li> 我們為防止輪子無法瞬間加速至我們要的速度造成打滑,而使用階段式加速,此法確實減少打滑,卻延長了轉彎時間跟距離,容易使得轉彎後直接到達下一個節點,但不靠循跡直行進入節點,會造成進入節點時方向偏離中間,再做下一個轉彎時會轉不夠或過多。 </ul><br> <li> 每一次輪胎打滑都是能量的浪費,也是造成車子控制穩定性的最大亂源。我們推測車輪可能離車子的質量中心有點遠,所以正向力不夠才會打滑。<br> <b style ="color: Green">解決:把萬向輪改為一個減少前方重量,並幫後輪加上負重,減少打滑可能性,效果奇佳。</b> </li><br> <li>轉彎的機制也和打滑有關,但和硬體配合之後(幫後輪加負重),我們也能應付最容易打滑的轉彎方式。轉彎方式的分析如下。<br> <b style ="color: Green">解決:左邊是最容易打滑的轉彎方式,因為轉軸和質心距離較遠,整台車的轉動慣量大,輪胎抓地力不足就會打滑,此種方法適合迴轉使用。 中間的不易打滑,但迴轉半徑實在是大了些,所以最終我們採用右邊固定一輪的方法,也比較好控制迴轉半徑。總之這些問題在幫後輪加上負重後就不是問題了。<br> <img src ="https://i.imgur.com/e9rQjMF.jpg" title ="" height ="130px"> <img src ="https://i.imgur.com/uMpT5TK.jpg" title ="" height ="130px"> <img src ="https://i.imgur.com/7FYbekG.jpg" title ="" height ="130px"> </b> </li><br> <li> 因我們將萬向輪拆下一個,發現車子循跡時左右晃的幅度加大。<br> <b style ="color: Green">解決:重新調整 PD 參數,發現使用較大的 D 時,走直線較穩定。</b><br> <b style ="color: orange"> 想法:因 D 永遠會往車子左右移動的反方向修正,我們類比之為「空氣阻力」;P 永遠會往偏移的另一邊修正,我們類比之為「彈簧回復力」。為了減少車子搖晃情形,我們希望阻力可以壓制彈簧回復力,所以由這個方向下手。</b> </li><br> <li> 一開始當 node 之指令為直走時,我們便讓車車向前數秒,但發現若車車是斜的走進黑塊,車車會無法成功接上黑線,而紅外線沒有偵測到時會後退,車車又會在節點上循跡,而卡在節點角角。<br> <b style ="color: Green">解決:目前的作法是使車車在直道時持續循跡,利用 <code>millis()</code> 一定時間內再感應到全黑便不再紀錄為下一個 node ,因為發現純循跡在穩定時,通過直線黑塊會表現良好,但若在直線過多晃動,仍有可能卡在節點角角。在進入節點時,紅外線模組不一定全部在節點內有可能只有4個有感應到,故可考慮感應到的4個紅外線偏左或右而使車車往中間做修正。</b><br> </li><br> <li> 在轉彎後加一短時間反向速度可幫助車身達定點即停止。 </li><br> <li> <b style ="color: red">或許可以讓車車進節點時,先以慣性等向前一段,再轉某個固定角度之後繼續轉到偵測到黑線為止?</b> </li><br> </ul> <h4>當天成果(還是有點賽??)</h4> <p> <iframe width="560" height="315" src="https://www.youtube.com/embed/GH338Z1kLJM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </p> <h3>課程建議 (選填)</h3> <ul> <li>無</li> </ul> <h3>想說的話 (選填)</h3> <ul> <li><img src ="https://i.imgur.com/rqrx1JS.png" title ="迷因貓貓" width ="300px" height ="220px"></li> <li>一個禮拜花在車車課的小時數:屈十指不可數...</li> </ul> ## 第十週批閱區 - 指定題進度報告 * 助教批閱欄 * 看到你們的記録,真的非常完整,非常感動 * 每次經過都會看到你們,辛苦了~ * 在轉彎前減速,讓車子回歸初始狀態,真的是很棒的做法!你們能夠把問題拆成小部分,再去做理性的驗證,也是非常難得!期待看到你們的成果哦~ * 關於地圖的部分,如果在非OpenLAB的時段需要用到的話,有一份地圖會放在Makerspace,可以在他們有開的時段問看看。因為我們上課的教室有很多課程使用,所以可能沒辦法想用就用,在這裏先說聲抱歉! > [name=趙少緯] * 教授批閱欄 * 評分等第:A * 教授回饋1:從影片看來,你們的車跑Checkpoint地圖已經很有架式了,祝你們明天好運囉! * 教授回饋2:這個禮拜的紀錄非常仔細且完整,有進步! * 教授回饋3:BFS先做好無妨,指定題競賽週一定會用到,但這禮拜一定要把車子調整好,BFS才能發揮用處啊!!! > [name=陳士元] ## 第十一週紀錄 - 指定題進度檢視 * Checkpoint新版 (依實際通過狀況填寫) * [x] 關卡1:基本駕駛 * [x] 關卡2:蛇行 * [x] 關卡3:S型彎道 * [x] 關卡4:迴轉區 * [x] 關卡5:直行 * [x] bonus:倒車入庫 > 給助教檢查[name=助教姓名] <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> <ul> <li> 循跡初始位置很重要。 </li> <br> <li> 轉彎方式改為先轉依固定時間,之後轉至碰到黑線為止,迴轉也是。 </li> <br> <li> 針對 check point 的倒退,我們讓車車後退一固定時間而不循跡,因測試倒退時狀況極不穩定。幾經嘗試,我們決定以次數拚出好成績。 </li> <br> <li> <b>因此段內容僅限當天討論,與之後測試問題多有重疊,故不重複寫於此。</b> </li> <br> </ul> <h3>組員分工 (必填)</h3> <ul> <li>共同完成:車子參數調整與測試、尋找bug與改善法</li> <li>特殊分工: <ul> <li>陳少翔:BFS、Python的整合</li> <li>江秉城:Python 藍芽、Python的整合</li> </ul> </li> </ul> <h3>遇到問題之處理狀況、解決方式 (必填)</h3> <h3 style ="color: rebeccapurple; font-weight: bold">——————————以下 5/5 測試紀錄(針對check point)—————————</h3> <ul> <li> 讀 RFID 方式改為後退,因車車碰到死巷塊後 RFID 常常超過卡片。<br> <b style ="color: green">更:見 5/9 第三點</b> </li> <br> <li> 車子太暴衝,但能讓車子跑的 PWM 有個下限。我們推測車子在 PWM 過低會跑不動是因為 Duty Cycle 的關係,所以這個 PWM 的門檻是固定的。藉由調低降壓模組的電壓,藉此讓車子再跑慢些,效果真的不錯。 </li> <br> </ul> <h3 style ="color: rebeccapurple; font-weight: bold">———————————以下 5/9 測試紀錄(針對指定題)——————————</h3> <ul> <li> 電池線斷了QQ。<br> <b style ="color: green">解決:重焊之後 PID 參數要調整,改回類似調電壓前的。</b> </li> <br> <li> 經測試,直走或後退歪的原因是某邊引擎不時會突然加速一下,導致車子偏移方向。<br> <b style ="color: red">未解決:硬體限制好像無解,買包乖乖獻祭?</b> </li> <br> <li> 發現讀 RFID 時其位置不一定,雖大部分在後方但有時可能也須往前。<br> <b style ="color: green">解決:改為先前進數秒,未讀到再向後尋找,擴大搜索範圍。</b> </li> <br> <li> PD control 時,dError 會對 error 作 negative feedback,可是因為兩者有著時間差,使得一段時間後會變成 positive feedback,讓車子越晃越大。<br> <b style ="color: Green">解決:dError 與 error同向時才 讓 dError 作用,有改善過度晃動問題。</b> </li> <br> <li> 在直行接轉彎或迴轉時會因為直行的慣性而往前過多<br> <b style ="color: Green">解決:在前一節點是直行時多加一短時間向後速度,以幫助煞車。</b> </li> <br> <li> 車子會將黑塊的角誤判為路,然後就卡住了。<br> <b style ="color: green">解決:用倒退次數k判斷卡角,當k超過某個門檻時就稍微前進,然後左右擺頭(振幅遞增)。這個方法使卡住的車有機會回歸正途,雖然有機會失敗,但也比卡死好。我稱之為防溺自救一百招之忍術放手一搏術!</b> </li> <br> <li> 不知為何,車車有時候會跳過節點,直接執行下一節點的指令,或是少節點。<br> <b style ="color: red">未解決:我們設一變數紀錄上次進節點的時間,因為在直行時會切換回循跡,但不能在同一個節點上重複讀到,所以設置在一定時間內不能讀節點。但儘管盡量拉長或減少了判斷時長,偶爾還是會發生這些問題,不知是何處的錯誤。</b> </li> <br> <li>如果車車在2分鐘內跑不完地圖怎麼辦?假設節點數正比於行走時間。<br> <b style ="color: green"> 解決:修改BFS演算法,讓他依照RFID得分/節點數來選擇進死巷的順序,如此就會得到一條CP值遞減的最佳路徑。</b> <h3>BFS 得分曲線:當前斜率(下次得分/該路徑節點數)最大為優先</h3> <p> <b> ------中型地圖(下方影片中的地圖)</b> <img src ="https://i.imgur.com/ANRQYZw.png" width ="900px" title ="mid maze" style ="margin-left: 10px"><br> </p> <p> <b> ------指定題地圖</b> <img src ="https://i.imgur.com/pBFC97y.png" width ="900px" title ="final maze" style ="margin-left: 10px"> </p> </li> <br> </ul> <h3>以下為經一連串調整前後比較</h3> <iframe width="868" height="488" src="https://www.youtube.com/embed/JsYDoV3XCXM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <iframe width="868" height="488" src="https://www.youtube.com/embed/QIobKP7xH_Q" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <b style ="color: black">shot at 2:00 AM 5/10</b><br> <b style ="color: rebeccapurple">雖然卡角比較有機會脫離困境,不過為啥我覺得循跡變爛了???</b><br> <h3>課程建議 (選填)</h3> <ul> <li>無</li> </ul> <h3>想說的話 (選填)</h3> <ul> <li> 在最後一天業力爆發... </li> </ul> ## 第十一週批閱區 - 指定題進度檢視 * 助教批閱欄 * 助教回饋 > [name=助教姓名] * 教授批閱欄 * 評分等第 * 教授回饋 [name=教授姓名] ## 第十二週紀錄 - 指定題競賽 <h3>預計完成事項 (必填)</h3> <ul> <li> check point 120 分 </li> <li> 指定題尋寶盡量拿分 </li> </ul> <h3>實際達成事項 (必填)</h3> <ul> | 項目 | 分數 | 完成度 |評語| | ---- | ---- | ----- | ----| | check point | 120 | <b style ="color: green">100%</b> | 感謝上蒼 | | 指定題尋寶 | 1580 | <b style ="color: #CF0000">78% ?</b> | 直行循跡還是不太穩,修正花了許多時間<br>最後轉彎過猛,未來得及讀到線便超過了 | <li> 成果影片 <p> <iframe width="868" height="488" src="https://www.youtube.com/embed/qLOkMNAPOEw" title="YouTube video player" frameborder="0" allow="autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen volume ="silent"></iframe> </p> </li> <br> <li> 尋寶得分時間曲線<br> <p> <img src ="https://i.imgur.com/FU5iYmu.png"><br> <b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;註:紅色為實際分數曲線,降低處為手碰的時間點</b> </p> </li> <br> </ul> <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> <ul> <li> 無 </li> </ul> <h3>組員分工 (必填)</h3> <ul> <li>共同完成:調整車車參數</li> </ul> <h3>遇到問題之處理狀況、解決方式 (必填)</h3> <ul> <li> 直線晃動過多,容易卡在角角,浪費時間修正 <br><b style ="color:green">解決:比完賽之後還是有調一下PD control的參數,直線有再穩一點</b> </li> <br> <li> 助教有建議我們在用左右晃動找路的時候,不要只用中間感測,多用邊邊可以更快找到線,嘗試改變條件式後,用五個紅外線去感測卻造成車車完全讀不到線,而用中間三個卻正常。 <br><b style ="color:red">未解決:不懂為什麼使用一模一樣的寫法卻會出問題,可能硬體感測趕不上內部判斷吧? </b> </li> </ul> <h3>課程建議 (選填)</h3> <ul> <li>無</li> </ul> <h3>想說的話 (選填)</h3> <ul> <li>第二名好爽喔</li> </ul> ## 第十二週批閱區 - 指定題競賽 * 助教批閱欄 * 助教回饋 * 你們指定題超強的:+1:恭喜拿到第二名! * 我知道你們有些人這週參與makeNTU競賽,還要準備指定題,辛苦了~ * 期待看到你們自選題的規劃。 > [name=俞建琁] * 教授批閱欄 * 評分等第: `A-` * 教授回饋: 恭喜在競賽中獲獎!你們的BFS得分曲線用(下次得分/路徑節點數)作為優化的目標函數很有創意。而尋寶得分時間曲線,並比較理想與實際值真的很棒,證實了你們的”計畫得分”很準確。讚! > [name=蘇柏青] ## 第十三週紀錄 - 自選題介紹 <h3>預計完成事項 (必填)</h3> <ul> <li> 討論出主題 </li> <br> <li> 建立 project 基本架構 </li> <br> </ul> <h3>實際達成事項 (必填)</h3> <ul> <li> 經過多次討論後,從暫時定案的碰碰車改為較吃重軟體的robot mapping </li> <br> </ul> <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> 想了數個方案,以下一一列舉: <ol> <li> <b>碰碰車</b>(<a href ="https://www.youtube.com/watch?v=GkbAcwYix7I">靈感來源</a>)<br> <b style ="color: orange">描述:</b>製作一黑色場地,讓兩台車車在場內競賽,撞到對方就得分,得分者高獲勝<br> <b style ="color: orange">模組:</b>現有的追加超音波(多個)測距、壓電模組(多個)偵測遭攻擊<br> <b style ="color: orange">問題:</b>需要兩台車,且車車撞了會壞;腳位不足以接那麼多模組,實用意義不明??<br> </li> <br> <li> <b>遊戲車</b><br> <b style ="color: orange">描述:</b>以玩家操控車車作為遊戲角色,即時更新於電腦遊戲畫面<br> <b style ="color: orange">模組:</b>RFID 作為拿取感應、超音波測距<br> <b style ="color: orange">問題:</b>軟體較多,變成是在寫遊戲,硬體則幾乎沒有,且實用教育目的不明??<br> </li> <br> <li> <b>室內掃描車</b>(<a href = "https://howtomechatronics.com/projects/arduino-radar-project/">靈感來源</a>)<br> <b style ="color: orange">描述:</b>做出能走遍場地,描繪室內結構及物件擺設情況的車車<br> <b style ="color: orange">模組:</b>超音波(攝影機)避障及測距、藍芽回傳資料<br> <b style ="color: orange">問題:</b>需要大量數學運算,且數據(影像)處理繪圖的部分太難了,考慮到時間緊迫不甚可行(<a href ="https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8862659">IEEE 論文</a>)<br> </li> <br> <li> <b>依指示路線移動車</b>(<a href = "https://www.hackster.io/phpoc_man/drawing-route-for-car-on-the-office-s-map-0c356d">靈感來源</a>)<br> <b style ="color: orange">描述:</b>人在手機上室內地圖畫出路線,讓車車沿著路線移動運送物品到我們想要的位置<br> <b style ="color: orange">模組:</b>超音波、php板與網路連接才能與同時與手機傳送回饋、用步進馬達做精準移動<br> <b style ="color: orange">問題:</b>沒有甚麼新的東西、php板太貴<br> </li> <br> </ol> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;關於碰碰車,教授建議可以製作一套系統,使每台車車都能參與,但考量這樣每台車都要裝模組,而且馬達參數不甚相同,所以似乎不太可行 <h3>組員分工 (必填)</h3> <ul> <li>共同完成:主題討論、資料搜尋</li> <li>特殊分工: <ul> <li>陳少翔:甘特圖</li> <li>江秉城:BOM表</li> <li>葉思妤:pre-proposal ppt</li> </ul> </li> </ul> <h3>遇到問題之處理狀況、解決方式 (必填)</h3> <ul> <li> 在碰碰車中,我們做了許多著墨,但限於需大量改裝硬體,且多一台車也多了很多成本,最後並沒有實作這個方案,但仍把所想的內容記錄於下,望能提供新的想法。 <ul><br> <li> 參考 Youtube 上的 robot sumo 的影片,車體的外表多是用金屬殼作外裝,且底盤低,前方會再加裝類似鏟子的東西,要將車子改成那種適合大量碰撞的狀態很困難,且馬達也不夠強力。故我們將規則從將對方推出場外改成碰撞到對方就會扣血,每台車有初始血量,並在車子的側面與後面加裝木板與壓力感測器(見附圖),並在車頭前加裝一根長棍(不用也可),用西洋劍比賽的感覺進行。但弊端是須加裝東西太多,需考慮腳位數與成本,且效果仍須測試 </li> <li> 要實作出對戰方式頗為困難,用超音波感測器並無法辨認對方的側、後面,如果用攝影機需影像辨識也會延遲辨認時間。如被擊中的逃離方法也很難想像,如果操作不好會變成單方攻擊,另一方不斷逃離而已。 </li> </ul> <b style ="color:red">基於以上的困難以及疫情問題,我們最終放棄這方案。 </b> </li> <br> <li> 超音波只有距離資訊,不能分辨當下感測範圍內詳細情況<br> <b style ="color:green">解決:直的放減少水平張角</b> </li> <br> <li> robot mapping 需在掃描完現在的點後,移動到下一點且需確認新的與舊的點的位置才能提供出正確的地圖,故採用步進馬達,來精準定位 <br><b style ="color:red">未解決:經過教授提供意見後,才發現我們忽略到即使使用步進馬達仍有微小誤差,而這些誤差逐漸累積會造成地圖的錯誤,後續解決方法更新在下方第十四週的內容中 </b> </li> <br> </ul> <h3>課程建議 (選填)</h3> <ul> <li> 對遠距的應對,希望能真的超前部屬,趕快給出下一步資訊,感覺有點走一步算一步,特別是 pre-proposal 的前一天晚上才寄信說希望重軟體</li> </ul> <h3>想說的話 (選填)</h3> <ul> <li> 選題之路峰迴路轉 </li> <br> </ul> ## 第十三週批閱區 - 自選題介紹 * 助教批閱欄 * 助教回饋 > [name=助教姓名] * 教授批閱欄 * 評分等第 * 教授回饋 > [name=教授姓名] ## 第十四週紀錄 - 自選題proposal報告 <h3>預計完成事項 (必填)</h3> <ul> <li> 確認好硬體材料,然後去填表單 </li> <br> <li> 開始看 SLAM 的系列影片 </li> <br> <li> 確定整個系統架構 </li> </ul> <h3>實際達成事項 (必填)</h3> <ul> <li> 確認好硬體材料,然後去填表單 </li> <br> <li> 開始看 SLAM 的系列影片 </li> <br> </ul> <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> <ul> <li> 關於在 mapping 中要如何正確確認現在位置,教授提出了在周圍放出訊號讓車車辨認以確認在室內的位置的方法,找過資料後,此方法需三個已知位置的 beacon 放出藍芽訊號,透過三角定位來找到位置。此外,還需電子羅盤來確認轉動位置。但這些並不算真正在未知環境中探索,而只是用車車在已知環境中呈現出平面圖而已 </li> <br> <li> 我們發現這是個 Simultaneous localization and mapping(SLAM) 問題,在未知的環境中我們得探索環境做出地圖,卻又要同時確認位置才能做出正確的地圖,我們參考了 <a href = "https://www.youtube.com/watch?v=Fw8JQ5Q-ZwU&list=PLn8PRpmsu08rLRGrnF-S6TyGrmcA2X7kg">MATLAB 的一系列影片</a>了解大概的理論,最終確認出我們需要 SLAM 演算法來幫助我們處理 sensor 送進來的資訊 </li> <br> </ul> <h3>組員分工 (必填)</h3> 甘特圖:https://hackmd.io/aEODUFH6QImMdwidBgtpng?view <ul> <li>特殊分工: <ul> <li>陳少翔:演算法資料搜尋</li> <li>江秉城:硬體資料搜尋</li> <li>葉思妤:演算法資料搜尋</li> </ul> </li> </ul> <h3>遇到問題之處理狀況、解決方式 (必填)</h3> <ul> <li> 在 robot mapping 中,多使用光學雷射當作 sensor 觀測,精度較高 <br><b style ="color:red">未解決:光學雷射很昂貴<a href="https://youtu.be/xkut3yRL61U">(此影片使用 Garmin LiDar-Lite)</a>,所以我們只能想辦法使用超聲波或是紅外線當 sensor,之後再處理精度問題 </b> </li> <br> <li> HC-SR04 超音波測距模組的 FoV(Field of View) 較大,測距的空間解析度會不夠精細。查詢 Datasheet 後,比較了以下幾種測距模組。 |原理|型號|單價|測距範圍|FoV|備註| |---|-----|----|-------|--|----| |超音波|HC-SR04|$60|250cm|30^。^|| |IR雷射|VL53L1X|$280|400cm|15~27^。^|FoV可調| 其他諸如 2y0A21 和 0A51SK,都是運用紅外線測距,但測距範圍較短,不符合我們的需求,故不列出。 VL53L0X(FoV=25^。^) 是 VL53L1X 的上一代,網路上也有人用它來 <a href="https://youtu.be/fQ2iB7qkrUg?t=598">DIY 光達</a>,但感覺精度不太OK,箱子被畫得歪歪的。 <b style="color:orange">結論:買好一點、FoV Programmable 的 VL53L1X 飛時測距模組。</b> </li> <br> </ul> <h3>課程建議 (選填)</h3> <ul> <li> 無 </li> </ul> <h3>想說的話 (選填)</h3> <ul> <li> 咩噗 </li> </ul> ## 第十四週批閱區 - 自選題proposal報告 * 助教批閱欄 * 助教回饋 * 兩次上課報告了完全不同的題目,相信你們在這過程中也做了很多討論!而且還看了很多教學影片。 * 這個題目感覺滿有挑戰的,我和電波不太熟Q,但建議你們在看完各種教學之後,可以更詳細的確認分工喔(軟體)。 * 大家都要健健康康! > [name=周奕慧] * 教授批閱欄 * B+ * 很有趣的想法,但也要注意難度不低喔! * LiDAR是現在很熱門且被廣泛使用在自駕車、無人機上的類雷達系統,原理跟傳統雷達很相似,只是使用了光波(或雷射)作為遙測媒介,以這門課的自選題來說,建議你們可以先評估選擇一種現有的媒介,如超音波或紅外線,來實現基本的測距功能(因為我們手邊就有超音波模組跟紅外線模組,方便好用且成本合理),然後仿照LiDAR的原理,參考影片中的方式把環境的立體影像建構出來,差別將在於空間解析度有很大的不同,但我覺得如果你們可以使用例如超音波模組來實現類似影片中的系統,即便最後你們做出來的系統只能判別大型的環境物件或結構(如面前的一個大箱子),那已是很棒的自選題了喔,加油! * 如果要自己設計產生beacon訊號的電路,對目前的你們來說難度頗高,因此我個人比較不建議那樣的方式。 > [name=陳士元] ## 第十五週紀錄 - 自選題進度報告 <h3>預計完成事項 (必填)</h3> <ul> <li> 上網訂好需要的材料 </li> <br> <li> 生出車子和光達的設計圖 </li> <br> <li> 繼續研究SLAM跟硬體的結合,完成 project 完整的架構 </li> </ul> <h3>實際達成事項 (必填)</h3> <ul> <li> 安裝 linux 以配合 Rpi,並成功在上面跑出 Breezy SLAM 的 example code,但因 example code 的資料是預先存好的,仍需解決感測資料輸入的部分。 </li> <br> <li> 光達Prototype構想如下 <p> <img src ="https://i.imgur.com/D72fsMF.jpg" title ="光達Prototype" width ="400px" > </p> <p> <img src ="https://i.imgur.com/I1SGHrL.jpg" title ="光達內部示意圖" width ="400px" > </p> </li> </ul> <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> <ul> <li> 在linux上裝ROS使用Gmapping來執行SLAM部分 或是 繼續研究BreezySLAM(或其他的SLAM) </li> <br> <li>原本想直接改上次找到的BreezySlam演算法。但我們發現這幾乎是不可行的,因為BreezySLAM只能和現成的市售LiDAR搭配,如果用自製的話會需要自己寫一個python module出來。 </li> <br> <li>找到使用超音波sensor的<a href = "https://github.com/khazit/CrazySLAM?fbclid=IwAR3Mbahw9NaT5ufPFAEjx-Phi7rPTYv8CvSjyECyS-YHsEQvF2mshox4c0Q">SLAM</a>了,研究後覺得容易更改許多,決定使用此SLAM。 </li> <br> <li> 我們只要把無人機改成車子,高度參數應該可以先不用管,將車子的輪子與移動關係加上去,再把紅外線處理出range跟bearing大概就可以使用 </li> <br> <li> 我們可以先試著如同原本寫的用鍵盤操控車子畫圖,等畫圖功能穩定後再寫讓它自動走的部分 </li> </ul> <h3>組員分工 (必填)</h3> <ul> <li>特殊分工: <ul> <li>陳少翔:演算法資料搜尋</li> <li>江秉城:硬體資料搜尋、硬體相關設計</li> <li>葉思妤:演算法資料搜尋</li> </ul> </li> </ul> <h3>遇到問題之處理狀況、解決方式 (必填)</h3> <ul> <li> 訂購材料時,發現之前寫的BOM表有缺漏。例如自製光達不只要會轉,他的線還不能打結,所以我們需要旋轉電線接頭。我原本的構想是步進馬達為中心,帶著紅外線測距模組轉,但仔細想想後發現,就算我們有旋轉電線接頭,電線一樣會纏上馬達的軸。 <br> <b style="color:green">已解決:像<a style="color:" href="https://youtu.be/fQ2iB7qkrUg?t=598">這個影片</a>一樣,用皮帶帶動上面有測距模組的輪軸,但不確定這樣的設計對旋轉角度控制的精確度有何影響。也因為設計的改變,我多買了軸承。</b> </li> <br> <li> 找到將其他型的sensor轉成laser型態的輸入的<a style="color:" href="https://github.com/alexsleat/projectChimaera/wiki/Other-Sensors-and-ROS-gmapping-(SLAM)?fbclid=IwAR3AOqW5pAYfSp0NQuf7IIZNXy0r79obv-gKPYPf5awKiqVuyEC2V8WXaY0">方法</a>,想用這個將紅外線的資料轉換後丟到Gmapping上,但有人說轉換結果正確率太低,製圖非常混亂 <br> <b style="color:green">想法:或許值得試試看</b> </li> <br> <li> 仔細研究才發現ROS太複雜,要熟悉操作可能很困難或是要花時間,不知道單用package要不要懂那麼多 </li> <br> <li> 想用virtual box使用linux來熟悉ROS與Gmapping的用法,但真的太卡,且檔案太大 <br> <b style="color:red">未解決:還是需要直接用Rpi使用比較方便</b> </li> <br> <li> 以下整理找到的SLAM資訊 | ROS內的SLAM | 輸入資訊 | 相關描述 | 備註 | | ------------ | ------------ |:----------------------------------------------- | ------------- | | Gmapping | 雷達、里程計 | 為filtering SLAM,最常被使用 | 需熟悉ROS操作 | | Hector | 雷達 | 依賴雷達的正確性 | 需熟悉ROS操作 | | Cartographer | 雷達、攝影機 | 為graphing SLAM,所需CPU資源較少,在Rpi上跑得快 | 需熟悉ROS操作 | | 自己找的SLAM | 輸入資訊 | 相關描述 | 備註 | | ------------ | -------- | -------------------------------------- | ------------------------ | | BreezySLAM | 雷達 | 將雷達輸入改為紅外線有困難 | 後來發現只能用雷達當輸入 | | CrazySLAM | 超音波 | 用在無人機上,為filtering SLAM,程式內容簡單易懂 | 應該就是這個了 | 還有找到<a style="color:" href="https://openslam-org.github.io/">OpenSLAM</a>上所提供的的SLAM的<a style="color:" href="https://github.com/OpenSLAM-org">Github</a>,但基本上都是雷達輸入,且沒有太多使用說明,要找尋適合我們的需要仍需時間,也要想辦法轉換成紅外線輸入 </li> </ul> <h3>課程建議 (選填)</h3> <ul> <li> 無 </li> </ul> <h3>想說的話 (選填)</h3> <ul> <li> 因為電子廠染疫,竹南最近快炸鍋了,我怕爆。 </li> <br> <li> 沼澤游泳 </li> </ul> ## 第十五週批閱區 - 自選題進度報告 * 助教批閱欄 * 助教回饋 * 你們遇到問題,會自己上網找影片解決,很棒:+1: * 討論事項和組員分工記得補上。 > [name=俞建琁] * 教授批閱欄 * 評分等第: `A-` * 教授回饋: 你們的題目點子很好,也看到你們不斷尋找與 SLAM相關的演算法資訊,也仔細設計硬體的架構。恭喜你們找到輸入超音波的SLAM軟體。希望在有限的時間裡,還是要想辦法收斂到一個夠簡單易實作,同時可以好好展示出concept的做法。加油! > [name=蘇柏青] ## 第十六週紀錄 - 自選題進度報告 <h3>預計完成事項 (必填)</h3> <ul> <li> 修改完CrazySLAM,遙控車車讓車車畫圖 </li> <br> <li> 完成光達 </li> <br> <li> 先寫好車子自走的部分,等遙控測試穩定再加上去 </li> </ul> <h3>實際達成事項 (必填)</h3> <ul> <li> 訂的東西和助教寄的內容陸陸續續到貨了~ </li> <br> <li> Rpi設定完成,放在一個24小時不斷電不斷網的地方,讓大家可以透過VNC隨時連線。然後他的確會發熱,所以上網找了一些能印出Rpi的CPU和GPU溫度的指令,存成一個可在terminal執行的檔案。 <p><img src ="https://i.imgur.com/tDK0v88.png" title ="熱騰騰的樹莓派" width=500 ></p> </li> <br> <li> 修改完CrazySLAM,遙控車車讓車車畫圖,但車子未完成,所以仍未實測 </li> <br> <li> 28BYJ-48測試,功能正常 <br><iframe width="560" height="315" src="https://www.youtube.com/embed/9Fxb8bWgOvQ" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </li> <br> <li> Nema17測試,功能正常。驅動晶片和馬達都蠻燙的,之後應該要注意。 <br><iframe width="560" height="315" src="https://www.youtube.com/embed/akmCoUkgWnQ" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </li> </ul> <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> <ul> <li> CrazySLAM原本是應用在無人機上,使用遙控操控,將所有的資料取完後再丟進SLAM作圖。我們決定也仿造其方法,遙控車子,並記錄每個時間Sensor資料以及車子相對位移於CSV檔中,再讀取檔案資料給SLAM運算 </li> <br> <li> 我們要寫一個車子的class,包含Rpi操控步進馬達與紅外線,還要記錄Sensor感測到的距離與角度以及車子相對位移,並寫入CSV檔 </li> </ul> <h3>組員分工 (必填)</h3> <ul> <li>共同完成:CrazySLAM解析</li> <li>特殊分工: <ul> <li>陳少翔:更改CrazySLAM</li> <li>江秉城:製作光達</li> <li>葉思妤:更改CrazySLAM</li> </ul> </li> </ul> <h3>遇到問題之處理狀況、解決方式 (必填)</h3> <ul> <li> 光達的外殼和輪軸本來應該要用3D列印,但現在只能在家就地取材。今天很幸運發現軸承和焊錫的塑膠卷軸可以完美疊合,所以決定拿這當光達的輪軸。目前遇到的小問題是金屬軸承和塑膠卷軸無法黏合。 <br><b style="color:red">待解決:查資料後發現白膠、熱熔膠、保麗龍膠都不適合,我們需要的是強力膠。明天(6/10)再出去買。</b> <p><iframe width="500" height="315" src="https://www.youtube.com/embed/V9kdBCdcsEU" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p> <p><img src ="https://i.imgur.com/H5EgDYS.jpg" title ="焊錫的新家" height =200></p> </li> <br> <li> 準備幫鋰電池充電時,突然發現Skyrc充電器附的只有input接頭和鱷魚夾(應該是要使用者直接夾在汽車電瓶),但這樣不如之前使用變壓器方便,所以我開始尋找家裡的電腦充電線。沒想到Skyrc充電器只吃11-18V的input,但現行電腦充電線早就都是19.5V規格了。 <br><b style="color:green">已解決:在家挖出一條「過時電腦」的充電線,他的變壓器剛好輸出16V直流,但因為沒辦法直接插進Skyrc,所以原廠附的鱷魚夾和接頭就派上用場了!</b> <p><img src ="https://i.imgur.com/zjgYt2r.jpg" title ="Trust me, I'm an engineer" width=500 ></p> </li> <br> <li> 正準備插上LiPo電池時,發現那個balance charge用線的紅黑位置和記憶中的不太一樣,越想越奇怪。印象是最右邊黑,其他三條紅。 <p><img src ="https://i.imgur.com/PHjPA4e.jpg" title ="Something's wrong, I can feel it" width=500 ></p> <b style="color:green">已解決:因為對正負接錯很有經驗,所以不敢貿然插上去以免冒煙之類的。我決定先用三用電表測量,得到的結論是:上圖由右至左四條線,電位逐漸升高,所以最右邊塗紅色是正確的。</b> <p><img src ="https://i.imgur.com/vqeUd4Q.jpg" title ="Modern problems require modern solutions" width=500 ></p> </li> <br> <li> 步進馬達的軸插不進車輪,需要把車輪中心再磨掉一個弓形柱體。 <br><b style="color:red">待解決:家裡剛好沒有銼刀,先用砂紙試試看。</b> </li> </ul> <h3>課程建議 (選填)</h3> <ul> <li> 無 </li> </ul> <h3>想說的話 (選填)</h3> <ul> <li> 終於走上正軌 </li> <li> Linux 的terminal很好玩欸,笑死 <iframe width="500" height="315" src="https://www.youtube.com/embed/PAxQGbiVLiM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </li> </ul> ## 第十六週批閱區 - 自選題進度報告 * 助教批閱欄 * 助教回饋 > [name=助教姓名] * 教授批閱欄 * 評分等第:A- * 教授回饋1:太棒了,這禮拜有很大的進展,期待看到你們"超音波達"的demo!!! * 教授回饋2:建議錄製的影片可以加上旁白簡單說明,會更清楚喔! * 教授回饋3:我自己也習慣會把一些舊筆電、電器的變壓器留著,以備不時之需 XDDD > [name=陳士元] ## 第十七週紀錄 - 自選題進度 <h3>預計完成事項 (必填)</h3> <ul> <li> 寫完自走的部分 </li> <br> <li> 完成光達 </li> <br> <li> 完成車子 </li> </ul> <h3>實際達成事項 (必填)</h3> <ul> <li> 寫完自走的部分,但車子仍未完成,仍未實測 </li> <br> <li> 實測紅外線 </li> </ul> <h3>組內討論事項 (必填,如問題、構想、分工合作、時間安排...等等)</h3> <ul> <li> 自走的部分一樣是掃完全部的data後才作圖 </li> <br> <li> 因為如何找到下一步這個問題有點複雜,故我們簡化方式,使用與右側牆壁保持一定距離逆時針繞場地的方法,而我們會準備簡單地圖讓車車掃描,讓它沿著牆繞也可以清楚掃描空間 </li> <br> <li> 如上次所述,光達的驅動馬達必須在外面,否則會產生電線纏繞驅動馬達軸的問題,所以上次的解決構想是輪軸和皮帶。還好上次我有多買一顆輪胎,想說如果找不到輪軸的話可以用之代替。現在採用這種設計,連皮帶都省了,少一個變數應該可以讓車子的穩定性提高。 <p><img src ="https://i.imgur.com/p4EhgAm.jpg" title ="Something's wrong, I can feel it" width=500 ></p> </li> <br> <li> 有一顆A4988是壞的,就算程式沒在執行也沒給控制信號,馬達還是看起來像有通電的樣子(發出聲音但轉不動)。真的執行程式給了控制信號,馬達的狀態並沒有改變。<br> <b style="color:red">未解決:上網訂兩顆A4988,順便車子的完整架構想一遍,全部一起買一買。貨還沒到。</b> </li> </ul> <h3>組員分工 (必填)</h3> <ul> <li>陳少翔:增加CrazySLAM自走的部分</li> <li>江秉城:製作光達、車車</li> <li>葉思妤:增加CrazySLAM自走的部分</li> </ul> <h3>遇到問題之處理狀況、解決方式 (必填)</h3> <ul> <li> Nema 17步進馬達用的是A4988控制,查資料後發現上面有個電流調整旋鈕,應該要依照A4988的規格調整,以免馬達過熱。 </li> <br> <li> 原本自走是想使用找每次量測距離最遠的點走,但可能會隨便找到最遠的點,讓方向一直亂轉,也可能造成走回掃過的地方再次掃,且如何確認停止時間也是一大問題,故最後採沿牆走的方式,掃完一圈即可結束 </li> </ul> <h3>課程建議 (選填)</h3> <ul> <li> no </li> </ul> <h3>疫情下之調整與心得建議</h3> <ul> <li> 網購真的蠻麻煩的,一波採買基本上需要一個下午來比較Q<br> 例如標榜快速出貨的不一定快速、沒滿1000不能打統編、賣家規格都不標清楚、要把貨擠在同一個賣家(為了省運費)等等 </li> <br> <li> 同上,好懷念隨時都開著的光華商場和MKS </li> <br> <li> 一開始覺得這個題目很難,並沒有要做的,但礙於要偏軟體的關係,硬是選了這個題目,剛開始時是一頭霧水找了超多資料,還一直覺得是不是做不來,好不容易到現在已經順利解決軟體的部分,要不是疫情的話,大概就不會選這個題目了吧,其實覺得蠻開心能學到新的東西。但最終仍卡在硬體的部分,物流寄送以及只由一個人負責製作造成進度有點不足,疫情還是造成諸多不便啊~ </li> </ul> <h3>想說的話 (選填)</h3> <ul> <li> <a style="color:" href="https://www.youtube.com/watch?v=0bA5Hfd6QXE">溺水尖叫雞</a> </li> </ul> ## 第十七週批閱區 - 自選題進度 * 助教批閱欄 * 助教回饋 > [name=助教姓名] * 教授批閱欄 * 評分等第: `A-`` * 教授回饋: 車車自走的方式改採沿牆走掃完一圈即可結束是一個好的策略,應可大幅降低demo時的不確定性。希望新的A4988到貨後,能夠順利地整合完成。期待看到你們最終的光達SLAM系統demo! > [name=蘇柏青] ###### tags: `電資工程入門設計與實作` `109-2`