# 109-2 電資工程入門設計與實作 第一組

## 成員
* 班別：週一班
* 組別：第一組《PUIPUI》
* 組員1：彭亞綺、B09901059
* 組員2：王芮庭、B09901093
* 組員3：黃茄瑄、B09901119

---

## 第五週記錄 - 組車
> 記錄者：王芮庭
* 課堂應完成事項(下課前必須找助教檢查)
* 將車車組裝完成：
車子組裝完成Part 1(前側柱、馬達座)
車子組裝完成Part 2(下盤)
車子組裝完成Part 3(中盤)
車子組裝完成Part 4(上蓋)
* 可控制馬達，使車車行動自如(往前+往後+轉彎)：
車子通電可動作
> 給助教檢查：趙少緯

* 實際達成事項 (必填)
* 完成部分
->車車車體組裝完成，並完成電源接線，至此車車已可開機(通過助教檢核)，電池充電，部分其他元件接綫
* 未完成部分
->Arduino、MFRC-522、L298N、紅外線模組的部分腳位，此外，藍牙模組訊號的連線、頂板、改造前輪的部分
* 上課內容
教授先簡單說明課程投影片，內容大致在講解如何組裝自走車，接著就開始小組分工實作(佔大部分的時間)。課程快到尾聲時，教授有向大家說明如何撰寫工作紀錄簿。
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排…等等)
* 工作紀錄簿的撰寫為一人一週，重複輪流
* 車車的家在大一女
* 往後若要用助教的lab時間，基本上應該都是選擇星期六早上的時段
* 車車自選專題的討論已開啟話題，但多半還沒有頭緒
* 操作方面之討論：
1. 單芯線和杜邦線一樣嗎
->不一樣，單芯線是最原始的電線，杜邦線是分公母的那種
2. 螺帽到底有沒有方向
->應該有吧
3. 10mm/8mm/12mm的螺絲到底有沒有差
->感覺沒差，只要用的順手、鎖的緊，且不影響整體就好
* 接綫脚位以及程式

* 遇到問題之處理狀況、解決方式 (必填)
* 給助教檢核時才發現電池接頭的材料錯誤
->剪斷電線重新焊接一個正確的電池接頭
* 剝單芯線的外殼時，真的剝到只剩單芯
->剪斷電線重新小心拿捏好力道剝殼
* 單芯線穿不過洞洞
->先把分岔的電線轉緊
* 焊接一直焊不到正確位置
->可先把想焊的位置加熱，再把錫棒靠上去即可熔的恰到好處
* 焊接電線到馬達卻把錫棒焊接到馬達
->再把錫棒熔掉就好了...
* 鎖Arduino、RFID的螺絲時上下分不清、看不懂
->放大投影片的圖片，根據相對位置與看清說明文字來推理做法
* 怎麼找不到15mm螺絲、紅外線模組1個、雷切墊片、金屬萬向輪
->找助教，但像雷切墊片其實不需要
* 助教沒有給arduino的傳輸線
->恰好組員-亞綺有arduino的傳輸綫
* 完成接綫后，程式無法燒入
->sensor shield v5.0的COM port RX TX部分是arduino uno板上0 1脚位的延伸，且digital port上的0 1脚位也是其延 伸，故在接綫時不應接到上述兩點

* 學到的東西
* 如何從組車說明找線索來操作
* 如何充電池
* 有些東西其實要視情況而定(如絕緣膠帶)
* 學會分辨尋跡模組、RFID、藍牙模組、降壓模組等材料
* 如何焊接、處理電線
* 如何與組員有效率的分工合作
* 組員分工 (必填)
* 基本上是一起做同一件事(組裝車車)，互相幫忙，依照投影片的進度走，有人遇到困難時再一起討論解決方法。
* 工作記錄簿每人輪流寫一週，若有額外想補充亦可自行追加
* 課程建議 (選填)
* 雖然知道助教們很辛苦，但還是希望助教在分配材料時能夠更加小心，避免做到最後才發現材料不對，多謝~
* 課程的安排很緊湊，感覺三堂課根本做不完應該要達成的目標，若能再調整一下進度會更好

* 想說的話 (選填)
這週的課程感覺很硬體，雖然要實作的部分很多，但其實不難，考驗的只是團隊合作能力而已。我們學習到很多實際操作的經驗，包括如何焊接、剪與剝電線、鎖螺帽等。助教們人都很好，常常來看我們操作，老師們也很盡責，常會像督促高中生一樣要求大家不要遲到、要著實做好功課，真的是很充實，一點都不能摸魚呢！

## 第五週批閱區 - 組車
* 助教批閱欄
* 記錄的很詳實！
* 造成你們零件沒有備齊，真的很抱歉！零件是我跟俞建琁助教，兩個人晚上留下來分的，所以難免會有點誤差>.<
* 課堂之後，軟體和韌體的部分，就會開始忙起來了，可以好好期待一下！
* 希望你們到之後也可以一直是戰友^^
> [name=趙少緯]
* 教授批閱欄
* 評分等第: `A-`
* 教授回饋
* 記載地很詳細~
> [name=蘇柏青]

## 第六週紀錄 - 循跡
> 記錄者：彭亞綺
* 課堂應完成事項(**下課前必須找助教檢查**)
* 可不輔助、不出軌，連續繞行橢圓狀地圖2圈
> 給助教檢查
> 3/31 openlab已完成圓形及C軌道
> [name=蔡昀哲]
* 實際達成事項 (必填)
* 校正紅外線感測器
* 完成MotorWriting、MotorCheck涵式
* 完成使用窮舉法整合紅外線感測器及馬達，但未成功繞行橢圓狀地圖
* 課堂討論程式:

void MotorWriting(double VL,double VR ){
  //左輪
  if(VL>=0){
    analogWrite(ENA, VL);
    digitalWrite(IN1, HIGH);
    digitalWrite(IN2, LOW);
  }
  else {
    analogWrite(ENA, VL*(-1))
    digitalWrite(IN1, LOW);
    digitalWrite(IN2, HIGH);
  }
  //右輪
  if(VR>=0){
    analogWrite(ENB, VR);
    digitalWrite(IN3, HIGH);
    digitalWrite(IN4, LOW);
  }
  else {
    analogWrite(ENB, VR*(-1))
    digitalWrite(IN3, LOW);
    digitalWrite(IN4, HIGH);
  }
}

* 課程內容摘要
* 紅外線感測器判別黑白的方式(反射量不同)
* 左右馬達控制涵式
* 課堂問題:使用MotorWriting(200,200)時，車身因為馬達或是其他因素影響，會有所偏向，我們組為偏右(左輪轉較快)
* 如何整合
* 1.窮舉法:我們找出合理的共九種情況(考慮只有一個或兩個偵測到黑色)
* 2.P control:藉由一條式子求出現在車子偏左或偏右(正負號)，藉由測試給定適合的參數，來去調整vl、vr
* 3.PD control:記錄現在車身的偏差量，並考慮未來的偏移趨勢
* 4.PID control:除了記錄現在車身的偏差量，還要考量過去的誤差和未來的趨勢
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* 循跡演算法(窮舉):
* <img src="https://i.imgur.com/QQJPcd3.jpg" alt="循跡演算法(窮舉)" width=300 height=300>
* 窮舉法成果影片
* 1.橢圓
* 第一次成功的版本:https://www.youtube.com/embed/6LI8Y395N94

* 參數微調後的版本:https://www.youtube.com/embed/hmi_5OfzS4w
* 2.進階圖形
* 版本1:https://www.youtube.com/embed/pAwXo80AJqs
* 參數微調後版本:https://www.youtube.com/embed/M8-Bw50aWDk

* 紅外線模組代號:A1(SensorValue1)為最左，A5(SensorValue5)為最右
* 馬達代號:ENA為左，ENB為右
* 循跡演算法(P control):
* 完整程式:https://hackmd.io/@iWmP1H_gSwuc5YgMqmbJFQ/By-LtFRru
* P control成果影片(使用係數在影片敘述)
* 橢圓:https://youtu.be/6r7UINGuLRQ
* 進階:https://youtu.be/YoR7gpY3ZiA

error=(-1)*l2*w2-l1*w1
 +r1*w1+r2*w2
 +0.5*(w1+w2)*(l1+l2==2)
 +0.5*w1*(m+l1==2)
 -0.5*(w1+w2)*(r1+r2==2)
 -0.5*w1*(m+r1==2);`

* PD control
* 程式:https://hackmd.io/@iWmP1H_gSwuc5YgMqmbJFQ/BkIEpFRS_
* 影片:
* 橢圓:https://youtu.be/uhRM2wGqasU
* 進階:https://youtu.be/tezPjQb03j4
* PID control成果影片
* 程式:https://hackmd.io/@iWmP1H_gSwuc5YgMqmbJFQ/Sk47RK0B_
* 影片:
* 橢圓:https://youtu.be/t6-_bxZUf3g
* 進階:https://youtu.be/D6ig4HLaCaU

* 組員分工 (必填)
* 在課程上皆為一起討論一起動手做
* 3/29晚在大一女修正
* 3/30下午在大一女修正完成窮舉橢圓、進階和p的橢圓
* 3/31openlab給助教簽名
* 4/3完成PD、PID橢圓
* 4/10 open lab 完成P、PD、PID進階圖形
* 遇到問題之處理狀況、解決方式 (必填)
* 紅外線模組的靈敏度不一
->用螺絲起子調整電阻
<img src="https://i.imgur.com/qO37XQ3.jpg" width="200" height="200">
<img src="https://i.imgur.com/VtD5quZ.jpg" width="200" height="200">

* 焊接電源的線脫落
->把套子拆下重新焊接
* 不確定馬達的對應
->測試後左邊馬達為ENA右邊為ENB
* 若要往右轉，不知道右馬達給-100(反轉)和0(以右輪為軸)誰會轉得比較多
->測試後發現負愈多轉愈多
* VL、VR=100或105都動力不夠
->後來發現是因為ENA、ENB接腳錯誤(沒接到PWM導致類比訊號讀不到)，接到正確腳位後，經測試發現驅動馬達最低電壓值左輪為90，右輪為80(左右仍不同，但已經較合理)
* 剛開始用一輪正轉一輪反轉來轉彎，會轉太多
->改成一輪正轉一輪不動
* 車子一直暴衝
->一開始把數值改小，但發現沒什麼用，後來才找到真正原因出自於ENA、ENB接腳沒接到PWM
* 車車的狀態變化有延遲
->把原本程式裡回傳感測值和delay註解掉
* 車車解體
->先使用膠帶固定，後來發現我們的底板沒有用螺絲鎖緊，鎖完螺絲後就穩固許多了
* 車車的電線太短容易拉扯脫落
->只能拿螺絲起子鎖好，後來換了一條長一點的線
* 車車左右輪都有時會空轉
->用萬用膠把輪胎內外緣黏好，效果不錯
* 使用P control時左輪一直都不動
->發現是因為中間值正太多，導致扣調corr的左輪電壓值太小，以致無法驅動左輪馬達。改善方法為除了將中間值調到接近0（我們取15），還另寫程式碼，if左輪電壓值太小，直接給與一最低驅動電壓（右輪保險起見也比照辦理）
* 使用P control跑進階地圖時，遇到大轉彎，車車會直線暴衝，但若直接改小直線電壓值有可能導致車車跑更慢更不順
->降低最小電壓(從100改成95)，讓車車跑慢點，以方便Sensor讀值、轉彎
* 後來發現左輪還是容易空轉(輪子轉了車子卻沒有動)
->改成一個萬向輪

* 課程建議 (選填)
* 感覺上課實作的時間很趕。給的紙有點薄，有時候被車子的輪子卡到就很容易破掉。

---

* 想說的話 (選填)
* 這次算是把前面兩節課介紹的元件整合起來控制，雖然我們一開始因為馬達線沒有接到pwm一切都超不順利，花了好幾個小時在修正自己的程式結果才發現是上禮拜接線的問題，不過看到車車真的可以循跡還是非常的有成就感。
* 我們把紙帶回來在大一女調整和實測，結果因為地板超髒，整張紙也髒掉了，邊邊還破掉用膠帶黏XDD

## 第六週批閱區 - 循跡
* 助教批閱欄
* 遇到問題的記錄非常仔細，還附上圖片、影片，很用心 :slightly_smiling_face:
* 那個紙張原則上一組一張，要好好愛惜XD 不過邊邊破掉用膠帶黏，車子走到那裏的話（在轉彎的時候） 可能會因為摩擦力不同受到一點影響喔~ 祝順利ˊˇˋ
> [name=周奕慧]
* 教授批閱欄
* 評分等第：A
* 教授回饋：
* 紀錄很完整且詳細，遇到的大小問題及解決過程都有加以說明，給個讚先!
* 一開始窮舉法循跡感覺會暈車 Orz，後面用P甚至PD control就有漸入佳境的感覺，走得很順，到了PID因為參數變更多，所以或許感覺改善效果有限，但其實適當調整參數應該是會更順的，但現在這樣已經很棒了!
> [name=陳士元]
---

## 第八週紀錄 - 指定題介紹
> 記錄者：黃茄瑄
* 課堂應完成事項(**下課前必須找助教檢查**)
* 問題0回答、答案訂正
* P = IV = 6V*180mA = 1.08W
* 問題1回答、答案訂正

* Q1-1: 電池最多必須提供的功率？
200mW + 33mW +(75mW*5) + 86mW + (1080mW *2) =2854mW
(降壓模組、L298N驅動模組、擴充板功率太小，忽略不計)

* Q1-2: 電池輸出電流為？
2854mW/11.1V=257.12mA
* Q1-3: 可以用多久？
2250mA/257.12mA=8.75hr
(充滿電2250mAh)

* 延申素養思考題
人的運動功率為多少？
B.300mW
一般轎車的功率為多少?
C.100kW
發電機的功率為多少？
10~100MW
CPU的功率為多少？
100mW
GPU的功率為多少？
幾百mW
* 問題2回答、答案訂正
* Q2-1: 地圖本身所需記憶體容量？
150 * 9 * 2 = 2700bytes
（4個distance，4個neighbor，1個自己）

* Q2-2: 執行BFS演算法時，所需最大額外暫存容量？（Arduino SRAM容量為2KB）
（150*pi_function + 150*d_function + 150個已經走訪過Visited及準備要被走訪的陣列queue）*2 = 900bytes

<span style="color:blue;">是否可以不存d_function?
如果都小於150是否可以只用1byte去存整數?</span>

* Q2-3: 地圖跟BFS演算法，可否放入Arduino中
否（3600 > 2KB)

* 問題3回答
* Q3-1: 需要多少通訊速率(bits/sec)？
（FD02AA21有4Bytes，一個4bits，一共32bits）
以byte為單位傳輸，4bytes/0.1 = 40bytes/s
* Q3-2: 藍牙是否可以支持此通訊速率？
可以
* 問題3答案訂正
* 每次遇到轉彎塊需要
通知看到轉彎塊： 上傳1B
告知RFID UID： 上傳4B
接收後續指令 ： 下載1B
所需6Byte / 0.1 sec = 480 bits/sec
藍芽位元速率為9600bits/sec 故可容納

* 完成甘特圖

* 完成系統方塊圖

> 給助教檢查[name=俞建琁]
* 實際達成事項 (必填)
* 回答課內問題、完成甘特圖及系統方塊圖
* 完成藍牙和RFID模組、E地圖、進度更新
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* 要使用P來改寫還是窮舉法，後來基於速度與流暢度，決定先暫時使用窮舉法，若之後想改再說，先試試看(最後考量車車的穩定度和速度，決定使用PD control)
* 指定專題的大致分工(詳見甘特圖)
* RFID程式(初版):
https://hackmd.io/lWkH7QRKQBu4g7axuS5cHg
* RFID程式(完成版):
https://hackmd.io/@iWmP1H_gSwuc5YgMqmbJFQ/rkjHTSwLd
* 測試E型地圖的停止點程式(初版):
https://hackmd.io/@W0mR43kBQhOnutRP20qmPQ/Bknzk5QUd
* 測試E型地圖的停止點程式(完成版):
https://hackmd.io/@W0mR43kBQhOnutRP20qmPQ/H1frUl_Lu
* 測試E型地圖視頻：
https://www.youtube.com/watch?v=AdcI8aJ49k8
* BFS循跡和得分演算法想法草稿:
https://hackmd.io/@iWmP1H_gSwuc5YgMqmbJFQ/ByO4ujB8_
* 進度更新
* 接脚圖更新

* 組員分工 (必填)
* 黃茄瑄、彭亞綺:RFID讀值、藍牙模組，王芮庭:偵測區塊和停止點，三人:BFS演算法
* 4/13 王芮庭完成停止點程式
* 4/14 亞綺、茄瑄完成RFID
* 4/15 亞綺完成藍牙傳送
* 4/17 三人到open lab，完成E地圖右轉成功，並且可以吃分數
* 決定5/1 open lab測試checkpoint地圖
* 遇到問題之處理狀況、解決方式 (必填)
* 在測試停止點時，發現右輪常常空轉
->只好先把轉彎都改成右輪不轉，左輪前進(往右轉)
* 在測試停止點時，左右馬達每次轉速似乎不大相同
->目前先測試車車並取一個幾乎每次都恰可轉180度的值，但是否可行還是要讓車車跑實體E行地圖看看
* 藍牙與python無法傳message
->arduino 所自定義的RX TX需分別接藍牙的TX RX
* RFID值無法透過藍牙顯示但是用之前寫的電腦和藍芽互傳的程式測試卻可以順利傳出
->後來在py檔中發現了這句話，所以我們嘗試著在BT.write("a")後面加上BT.write('\n')，然後就成功傳出去了!

* RFID需接10腳位
->將藍芽的RTX改接到A0腳位，TXD改接到8
* 雖然順利讓BT.write("a");BT.write('\n')能夠成功傳出訊息給電腦，但是當我試著傳RFID讀到的ID值BT.write(id[i]);BT.write('\n')卻出現如下圖的錯誤
->藍芽一次只能傳1byte的封包，但是我們的id[i]有兩個byte，因此寫了一個bt_print_byte(int origin)涵式將2byte拆成1byte並換成16進位，然後就成功了!
* 車車一直轉彎，沒辦法循跡
-> 發現是sensor再車車偵測到黑塊時，值沒有更新，解決方法是在內部的loop、前進後再讀一次sensor的值，且最重要的是sensor讀值一定要放在loop內!!!
* 我們經討論後決定將「直行」視為優先考量，故把usuallydrive();放在狀況一
* 右轉彎飄移，即轉彎時右輪motor writing 0 卻無法讓右輪停下
-> 先讓車車在偵測到轉彎塊時先向前再停下，再轉彎，再停下；偵測到死巷塊時先類似處理辦法(不同動作之間都要先停下)
* 車車在停下後向前會太多，以致於每次轉時無法轉到直黑線上
-> 讓車車前進delay秒數少一點再繼續轉彎
* 車車速度有些快，以致於每次結果都不穩定
-> 從之前三個control來看，PD較穩定，故用PDcontrol，速度會慢一些，結果是較穩定，不需要再後退但可能轉彎要多一些
* PD control第一次試跑很成功，但錄影時出現轉彎不足等許多無法預測的角度，大回轉出現問題
-> 因為原本預計檢測只有中間sensor3！=1時轉彎，但sensor3可能偵測得不太好，故改成當所有sensor沒有偵測到1時才開始回轉，右轉成功
* 爲了後續RFID讀值，目前程式RFID會使它超過死巷塊無法讀值
-> 暴力解決，向前再後退讀值，再向前回轉，但後來覺得應該讀的到，所以就不後退了XD
* RFID值有時無法讀值
-> 方法1：讀值兩次避免第一次沒吃到分數，方法2：放在loop裏一直讀值(但可能要跑很久?)，目前決定先維持現狀

* 課程建議 (選填)
* 本周關於地圖部分較不清晰，因爲有紙張的E地圖和csv檔，剛開始誤以爲是要測試csv檔，對於接下來要跑的地圖不知道還需要測試怎麽樣的路段。
* 想說的話 (選填)
* 這次的工作基本上分開進行，也是這幾周以來較少在平日碰面一起做車車。本周星期六的open lab完成較多事情，也許是因爲有充足的時間直接討論彼此的想法以及測試，發現open lab的重要性:laughing:

## 第八週批閱區 - 指定題介紹
* 助教批閱欄
* 助教回饋
* 看起來你們遇到許多問題，也很努力的自己嘗試解決，很棒:+1:
* 你們問題紀錄很詳細，甘特圖和系統方塊圖也很完整:smile:
* 看到你們對於d_function要不要存有疑問，我這邊提供一個我自己的想法。指定題競賽中，時間上應該沒辦法讓車車跑完地圖上每個有RFID的端點，所以如果你們想拿高分，也許可以概略計算走到各點需要的時間，藉此判斷是否放棄較近的RFID。若要這麼做，可能就會需要知道d_function。以上給你們作為參考。
> [name=俞建琁]
* 教授批閱欄
* 評分等第: `A-`
* 教授回饋:
* 問題討論很多、很仔細。甘特圖與系統方塊圖也都規劃得不錯，希望按圖按表執行可以持續順利!
* 另外，看得出來你們的工作是週一上課後到16號open lab(嗯? 週五有open lab嗎?)的連續很多天的累積成果。建議在「遇到問題之處理狀況、解決方式」時，也可以順便記錄一下日期(時間)，可以讓記錄更有脈絡唷~~~

> [name=蘇柏青]

## 第十週紀錄 - 指定題進度報告
> 記錄者：王芮庭
* 預計完成事項 (必填)
* 討論BFS該如何著手，並開始寫BFS
* 如果可以的話，希望讓車車試跑checkpoint地圖，進行修改(課堂)
* 成功讓車車跑checkpoint地圖(open lab)
* 實際達成事項 (必填)
* 測試了checkpoint的地圖，發現
* 車車馬達的轉速不穩定，導致狀況時好時壞
* 有些參數需要實際測試後才能更改，如遇到轉彎塊後的前進delay秒數
* 車車有時會出軌
* 更改進度分配，決定優先處理硬體
* 初步討論BFS的sample_code
* d_function的功能
* sample_code的node、interface檔案分析
* Successor[]資料儲存方式
* 5/1 於open lab時測試地圖，但尚未成功，目前的狀況是
* pass>5後的轉彎仍不穩定，需要再調整參數
* pass<4時車車會不會仍然出軌?
* 5/2 於open lab時測試地圖，勉強調整至車車成功
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* python檔案統整說明書:
https://hackmd.io/@iWmP1H_gSwuc5YgMqmbJFQ/SkipEnXvu
* checkpoint構思草稿（初版）:
* checkpoint構思草稿（二版）：

* checkpoint程式(初版)： https://hackmd.io/@W0mR43kBQhOnutRP20qmPQ/S1a4_hXv_
* checkpoint程式（二版）：
https://hackmd.io/@W0mR43kBQhOnutRP20qmPQ/H1mEQu9Du
* checkpoint程式(完成版)：
https://hackmd.io/@W0mR43kBQhOnutRP20qmPQ/BJlURG3w_
* 倒車入庫在後退時，要用法一:寫死馬達速度 還是 法二:用偵測的方式 ?
->(法一是簡單跑得快但不嚴謹，法二是嚴謹但跑得慢，雖然這個比賽沒有計時，但其實不嚴謹誤差也不會太大，而且考量到程式碼的簡潔和sensor的負荷量，決定先使用法一，有問題可在open lab時再更正)
* 由於BFS演算法的差別只在於高低分，因此我們決定聽從老師的指示先處理好硬體的部分，讓車車能穩定行走
* 組員分工 (必填)
* 4/25 王芮庭完成checkpoint程式碼
* 4/26-4/30 由黃茄瑄負責測試車體電表，完成後加入BFS演算法團隊，王芮庭和彭亞綺繼續想BFS演算法
* 4/26 彭亞綺完成maze檔案的轉入初始化
* 4/27 彭亞綺完成node的相關函式
* 4/28 黃茄瑄測試輪子以及部分checkpoint地圖
* 5/1 三人於open lab繼續測試checkpoint地圖
* 5/1 彭亞綺讓python程式能夠正確回傳BFS路徑
* 5/2 王芮庭、黃茄瑄於open lab繼續測試checkpoint地圖
* 遇到問題之處理狀況、解決方式 (必填)
* 車車的馬達不穩定
->決定使用電表把車車的元件都測測看電壓值，找出可能出問題的部分(4/26)->利用電表測試當程式給予左右兩邊相等電壓值時，實際車車右輪比左輪快(4/27)
->有其他組別建議可以在車車上負重(蓋蓋子並把電池壓在後方，將於open lab時測試)->測試後發現並沒有顯著改善，決定放棄這個選項(5/1)
->發現一開始會偏應該是PD control的問題，需要一小段路才能穩定下來，也有可能是sensor歪了（4/28）
->讓車車速度減慢、判斷完轉彎塊後停下、並調整參數，以方便sensor繼續PDcontrol讀值，情況有改善(5/1)
* 車車轉彎有時轉太少(4/26)
->轉彎時皆更正為while讀到黑線才停，否則持續轉彎
* 車車會出軌
->老師有建議當讀到全白時，可以讓車頭左右大幅擺動以找到黑線。但因為讀到全白是我們程式中其他的判斷依據，所以目前我們先不考慮出軌狀況，等找出車子馬達哪裡出問題後，若可改善車子暴走的情形，就不用太擔心車車會出軌了(因此實際狀況還是等到open lab，到時再考慮時否需要寫入出軌反應)(4/26)->以目前的狀況來說，車車出軌的機率不高，且若寫出軌的狀況可能讓程式更複雜，故先不考慮出軌(5/1)
* 跑checkpoint地圖的時候，車車一直會卡在第一個轉彎塊，然後就失控了
->應該是助教的地圖破了，卡到輪子，使車車來不及走出第一個轉彎塊，又多偵測一次(4/26)->調整參數直接寫死(5/2)
* 每次停止delay的秒數是否可以不要 ?
->決定先等車子能夠安穩地跑完整個地圖再說，如果處理好硬體的問題，原則上應該是可以刪掉停止部分的秒數(4/26)->必須留著，除了可debug外，還可讓馬達轉速正常運作(5/1)
* 車車不斷原地自轉（5/1）
->最右邊的紅外線模組不斷閃爍，經判斷後發現可能是杜邦線內部的問題，若之後再這樣，可能要換線
* 發現之前寫的checkpoint初版太複雜(5/1)
->將轉彎塊和死巷塊寫在一起寫死，於是有二版
* 車車一直卡在pass = 5的行為(5/1)
->用pass+0.5的方式成功繼續執行，使pass有小數時繼續PDcontrol，可以區隔車車在轉彎塊或死巷塊的特定行為
->設置布林變數flag讓車車做完pass=4的行為後，馬上進到pass=5，因為倒車入庫那段的直線距離實在太短了
* 寫getAction()的時候覺得助教給的sample code對direction的定義會讓判斷變得複雜(原本的設定我只有想到用窮舉來判斷左右轉)(4/29)
->將direction 的 enum改掉(下圖藍筆改成紅筆的部分)
* 為了知道哪一個deadend離現在的最近，我們需要變數去存兩deadend的距離(4/29)
->在node中新增def getDistance(self,nd_to)函數以方便寫BFS_2
* 我利用BFS函數回傳整個路徑，BFS2則是他的副函數(4/29)
* BFS(self, nd):給定起點(nd)回傳一個list為我們找到的最佳路徑上每個node的序列
* BFS_2(self, nd_from, nd_to):給定起點和終點(由BFS呼叫)找出兩者間Breadth-first search的最佳解，回傳他們之間的路徑list和距離distance
* BFS的起點(4/29)
->maze.py有一個getStartPoint的涵式，但我不確定它的作用，我使用的方法是在main中要先手動輸入第一個node的名字再讓BFS去跑，這樣整個程式會更有彈性，之後如果可以的話可以寫寫看用哪個當起點分數會更高來去加入建立路徑過程
* 資料型態的問題(5/1)
->在debug的時候發現自己常常忘記資料型態的一致性和轉換，像是BFS中Class Node和Class str(像是node_name)等，之後寫程式會在注意這方面，像是在建立list或dict的時候可以註記他們的資料型態，避免之後寫更大的程式的時候會有更多麻煩
->程式碼中有加上資料的型態

* 課程建議 (選填)
* 很想把checkpoint的地圖帶回去測試><可惜似乎沒辦法，如果可以希望助教以後也能提供checkpoint的地圖，以方便同學平常有空就能測試車車
* 課程進度希望可以調鬆一點
* 想說的話 (選填)
* 課堂上看到有的組別很厲害，BFS幾乎完成，真讓人想要去請教；也有組別提出不錯的建議，如在車尾加入2個紅外線模組，說不定成效也不錯。透過進度報告，讓我們發現很多組別都和我們有一樣的問題，也提供了我們很多方向，是個很好的課程安排！
* 這次的課程進度超趕，難以想像下周的情況...

## 第十週批閱區 - 指定題進度報告
* 助教批閱欄
* 辛苦你們了！
* 考慮到之後自選題給你們預留多一點時間，才不得不把指定題的部分壓縮，希望你們可以學到不少東西！
* 關於地圖的部分，如果在非OpenLAB的時段需要用到的話，有一份地圖會放在Makerspace，可以在他們有開的時段問看看。因為我們上課的教室有很多課程使用，所以可能沒辦法想用就用，在這裏先說聲抱歉！
* 你們再額外開不少Hackmd的做法，真的很用心！
* 如果要分享Code的話，可以考慮使用[Github](https://github.com/)和[Git for Windows](https://gitforwindows.org/)。而編輯程式的方面，[Visual Studio Code](https://code.visualstudio.com/)甚至可以直接支援，在編輯的頁面直接上傳到Github。如果有興趣的話，可以在OpenLAB找助教問哦~
> [name=趙少緯]
* 教授批閱欄
* 評分等第：A-
* 教授回饋一：紀錄精彩完整，很棒!
* 教授回饋二：時間永遠都不夠啊 XD，重要的是在有限的時間內完成比較關鍵的部分跟功能，不要"完美主義"，要學會妥協。
* 教授回饋三：你們組的分工情形是我們班上寫得最詳實的喔，請繼續加油!
* 教授回饋四：Checkpoint地圖的使用我們未來會改進(也就是說這學期來不及啦 XD)，也謝謝你們的建議!
* 教授回饋五：希望大家明天有好表現!!!
> [name=陳士元]

## 第十一週紀錄 - 指定題進度檢視
> 記錄者：彭亞綺
* Checkpoint新版 (依實際通過狀況填寫)
* [x] 關卡1：基本駕駛
* [x] 關卡2：蛇行
* [ ] 關卡3：S型彎道
* [x] 關卡4：迴轉區
* [x] 關卡5：直行
* [ ] bonus：倒車入庫

* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* python最終檔:
https://hackmd.io/@iWmP1H_gSwuc5YgMqmbJFQ/rkO4XzEOu

* 自選題(包含checkpoint)的arduino code:
https://hackmd.io/@iWmP1H_gSwuc5YgMqmbJFQ/ByhpIfEO_
* checkpoint成功影片：
https://youtu.be/F_Eun_bxF0E
* checkpointplus2程式碼(舊版的checkpoint
):https://hackmd.io/@W0mR43kBQhOnutRP20qmPQ/HyTsGFmOO
* 在Checkpoint時五關中過了四關，只差S型那邊失誤了一點，所以先再微調checkpoint程式，希望下禮拜可以一次挑戰checkpoint成功
* 其餘就是這禮拜要完成藍芽在電腦和arduino的傳輸
* 車車指定題演算法的運作以及python和arduino的資料傳輸:
* 我們希望BFS算完車車的路徑之後，一次將指令(list/string)傳輸給arduino
* arduino做的就是必須計算現在走到第幾個轉彎塊(死巷塊)並且照著那串指令來決定下一個動作
* 在這同時python端還須接收arduino所傳回的UID值
* BFS想法:每次都去找最近的死巷塊
<font color=color.red>可能產生問題:因為都在距離短的地方繞，都吃分數較低的，也許並非最佳解</font>
但是因為我不知道實際的地圖究竟是長怎樣，最理想的情況就是還有時間能夠寫其他種演算法，並在當天讓電腦運算和種算法能在時間內吃到最多分數，若要這麼作則還需去精算車車的速度以及做各種動作的時間(5/3)

* 車子在不同電壓，或是sensor歪掉時都會造成誤差，所以我們決定將最好的狀態紀錄，在星期一時還原(5/8)
* 電量:77%
* 紅外線感測模組:畫出位置
* 車子在某些不平的地方還是會空轉
* 將車子裝上酷炫尾巴!!效果改善很多
* 

* 新增車車停下
* 讓車車在最後一個node的時候停下，比較好拿也比較不會亂跑
* 公布final地圖後把所有該下載的package都下載好了，測試過score.py，也測試過BFS的結果沒問題😁😁
* 自己畫地圖~((自己寫完地圖檔才發現好像有給中地圖的csv檔QQ

* 組員分工 (必填)
* 5/3 王芮庭完成把車車動作模組化
* 5/3 BFS可將ACTION的正確順序回傳
* 5/4 藍芽傳輸可將ACTION的順序傳入ARDUINO
* 5/5 openlab有順利跑完數次checkpoint(有倒車入庫)
* 5/8 openlab測試checkpoint和指定題(早上+晚上)

* 遇到問題之處理狀況、解決方式 (必填)
* 車子輪子有時候都是會空轉，而且車胎有點被磨損了(5/3)
->換個輪子有比較好
* 傳入arduino的action該如何表示(5/4)
->使用自己的編碼('1'代表直走,'2'代表迴轉....等)將action順序以string的形式傳入arduino
->改成使用char陣列，在傳輸完後再傳一個halt訊號，讓arduino知道傳完了，且執行到這邊時停下。char陣列元素預設100(應該不會超過吧?)
* 倒車入庫的地方成功率很低(5/8)
->更改迴轉方式，改成和node 8、9一樣的形式
* 在迴轉的時候，會卡住不動(5/8)
->抬起車子的時候發現輪子是有在動的，所以將轉彎時馬達的電壓調高
* 車車有時會爆衝(地板的問題?)🤷‍♂️
* 車車出軌補救方法(5/8)
->利用先大右擺在大左擺的形式去讓車車找到黑線(詳見程式中find_line()涵式)
* 在大迴轉時，若轉得不好，會在死巷塊讀到第二次(5/8)
->在迴轉的涵式中增加涵式，避免他讀到第二次
* 有時候右轉到死巷的時候，會偵測不到全黑導致少偵測到一個node(5/8)
->將偵測到node的條件放寬，原本要五個sensor都是1才會達成，現在改成三個以上sensor偵測為1及算是進入到node
* 指定題的直走(advence()function)有時候可以順利走出node，但是有時候會無法走出node，delay調太大容易歪，調太小又容易走不出去多偵測一次(5/8)
->使用判斷式的方式，一直往前走直到sensor偵測黑色的小於三個才進入下一個步驟

* 晚上的時候嘗試著寫出checkpoint的地圖，用指定題的方式去跑checkpoint，結果意外地順利，最後可能會使用這樣的方法

* 課程建議 (選填)
* 在練習跑checkpoint的時候，感覺地圖太容易被破壞/弄髒了，也是在上課的時候助教們才把地圖稍微修補，感覺之後可以考慮看看有沒有甚麼比較不容易壞的材料可以替代，然後可以在上課前就把地圖準備好到最佳狀態
* checkpoint有時候會跑超過木板然後就上不來了。再跑中地圖有時候在編編會跑超出紙，很容易再回來的時候捲到紙張然後就破掉了，或是因為前輪離開紙接觸到地板導致摩擦降低，往前滑出一段距離，希望到時候自選題正式跑的時候紙盡量平整或是邊邊留的空白多一點，不然前輪碰到地板真的很容易滑出去一大段就回不來了
* 想說的話 (選填)
* 指定題總算到來，這幾個禮拜真的是好忙இдஇ，希望禮拜一能夠順順利利，在openlab的時候看到車車能夠順利走完整個中地圖真的好感動，感覺就像自己的小孩學會走路了

## 第十一週批閱區 - 指定題進度檢視
* 助教批閱欄
* 助教回饋
> [name=助教姓名]
* 教授批閱欄
* 評分等第
* 教授回饋
> [name=教授姓名]

## 第十二週紀錄 - 指定題競賽
>紀錄者：彭亞綺

指定題競賽最終檔案:https://github.com/amoee-5272/MY_CAR
* 預計完成事項 (必填)
* 希望可以一次順利通過checkpoint，車子硬體乖乖
* 自選題的話，在軟體的路徑規劃都沒問題，只差硬體的一些不確定性，希望他可以順利跑完不要偏離軌道

>我們的車車走得比別人都慢，那是因為它承載著全組的希望(X

* 實際達成事項 (必填)
* checkpoint達成110分，被藍芽gank了 😭 😭，因為藍芽連不上導致沒有接收到第一個uid，之後幾次跑不是藍芽連不上就是車車跑歪了，不過跟上個禮拜比已經進步很多了!

* 指定題跑地圖意外的達成1280分!!
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* 指定題檢討
* 我們有一次跑的時候其實是能跑到1880分的但是因為我們車子的速度不快，加上在每一個node都會有一些停頓的時間導致最後因為時間不夠
* 當天看了許多組他們的演算法是先跑到node44等node41，而我們的則是每次都跑距離自己最近的deadend所以走的順序會先到13->8->24->19->4->36->32->41->44->20->33等，後來有詢問最高分的那組他們的BFS是計算現在這個node到其他的deadend的分數/距離來去決定路徑的，感覺這樣子的演算法比較能夠適應各種地圖來達到更好的結果
* 我們的車子在最後其實跑得蠻穩的，雖然有些小地方我們一直緊張的想去扶他，但其實他都可以自己修正回來~

* 自選題的題目
* 目前組員有的零件列表

* 目前決定製作人體散熱車!!!
* 組員分工 (必填)
* 5/15線上討論自選題主題，並決定開啟google簡報共編作業ppt
* 自選題簡報:https://docs.google.com/presentation/d/1FpZYOlxh4tOmvN6bIJ3lK1HJTUEPOqhGKoP6X6H1ZuU/edit#slide=id.gd9db7a39f8_2_485
* 指定題討論:https://docs.google.com/presentation/d/1vfnbh1TkWxbUIUTVAfejm7PrXDAhi9USBOM2gbOJ3Hc/edit#slide=id.p
* 遇到問題之處理狀況、解決方式 (必填)
* 當天在測試指定題的時候發現有一個uid讀出來會怪怪的出現@的符號
->發現原來arduino那邊把uid轉成十六進位的地方出了問題，我們寫的是當他小於九的時候換成0~9，大於9的時候換成A-E，結果我們在寫判斷的時候忘記是要寫成小於等於9了，導致如果uid的十進位是9的話會轉成@
* 另外當天在測試中地圖的時候一直覺得我們的find_line怪怪的，照理來說每次進入find_line都要先向右轉八次再向左，但是有時候測試的時候都沒有轉到八次
->我們是用變數n去計算轉了8次，之後若跳出find_line那麼n應該要歸零，但是我們把n歸零的這個動作寫在break後面，導致她其實都沒有歸零，改了之後就正常了

* 課程建議 (選填)
* 讚
* 想說的話 (選填)
* 指定題終於到一段落了，最近這兩三個禮拜幾乎每周都花超過20個小時在做車車，最後的結果真的很讓人欣慰呢(而且我們剛天練習的時候都沒有跑超過500分)，總算可以先歇息一下，等到下禮拜完全確定自選題後再繼續努力!!

## 第十二週批閱區 - 指定題競賽
* 助教批閱欄
* 助教回饋
* 你們指定題表現超棒的:+1:
* 你們的車子雖然走得慢，但是很穩定，就算不小心出去，也會自動導回正軌，要對自己的車有信心，看你們在比賽過程中一直很緊張地要用手去扶車，差點就被扣分了。
* 期待看到你們對於人體散熱車的設計。
> [name=俞建琁]
* 教授批閱欄
* 評分等第: `A-`
* 教授回饋: 記錄很仔細清楚，恭喜你們指定題獲得佳績！期待自選題再努力發揮創意。
> [name=蘇柏青]

## 第十三週紀錄 - 自選題介紹
>紀錄者：黃茄瑄
* 預計完成事項 (必填)
* 確定自選題主題，並進行詳細規劃時程
* 實際達成事項 (必填)
* 確定自選題方向，並規劃時程以及分工
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* 偏重趣味或實用
->兩者都可考慮，但主要看主題以及實際可完成的部分。
* 自選題主題
->運輸車！！！

* 組員分工 (必填)
* 亞綺：APP的編程
* 芮庭：應用上的完善以及軟體
* 茄瑄：硬體測試
* 甘特圖
* 

* 遇到問題之處理狀況、解決方式 (必填)
* 自選題主題候選人
* 追著人跑的人體散熱車
->如何判斷是人或者是火爐之類的？
->類似冷氣概念，是否要限制場地範圍，僅限於室内？
->繞著固定物體或許會比較好？
* 推土機/足球車車
->可推土也可把車當球踢
->車車會壞...
* 打掃環境的車車
->若要外加手臂可能有點困難
* 送餐車
->之前有人做過了...
* 便利公車(運輸車)
->首先把車車改造成可乘載物品，然後讓車車像公車一樣按固定路線跑並設置站牌，只要人在站牌邊招手，車車就會停下，我們可以透過車車傳遞物件給位於不同站牌的人(因為人很懶)，如：丟垃圾、拿食物等
->用循跡orAPP設置固定路線與佔點
->平常測試的可行性？
* 目前的方向：懶人公車（輕量運輸車）
->車車的大小還有馬達會影響能夠運的物體大小，目前以輕量的爲主。
->若要循跡則要規定空間並自行規劃地圖，若是用APP設定固定路綫和站點則先以無障礙物的空間爲主。
->零件購買部分仍需確定要實際達成的效果才可決定，馬達部分能不改則不改。
->目前確定要完成的事項有APP的編程、車車最大可負載的重量、以及其他能添加的實際功能
->因疫情可能無法用密集板進行雷切，所以實作時可能要想想要用其他適合的材料來改裝車車(厚紙板之類的)
->加裝酒精消毒籃子
->前兩周以APP爲主，其他小硬體同時進行
* 所需學習的新東西
* [app inventor](https://appinventor.mit.edu/)
* [connect arduino with app inventor](https://blog.cavedu.com/2013/11/08/appinventorandarduinowithbluetooth/)

* 課程建議 (選填)
* 第一次綫上上課，時間規劃上不太像面對面上課一樣那麽有效率，導致反而還要挪課後的時間完成討論，也許可以詳細規定該報告的事項。
* 想說的話 (選填)
* 綫上上課以及open lab的關閉對我們在實作上有一些影響，在進度上也許會落後，期望還是能把自選題做出來。發現自選題時，助教們和老師的建議十分重要，因爲太多因素會影響作品應要有的效果。如果助教們和老師能夠在自選題候選主題上給出建議那就幫大忙了。

## 第十三週批閱區 - 自選題介紹
* 助教批閱欄
* 助教回饋
> [name=助教姓名]
* 教授批閱欄
* 評分等第
* 教授回饋
> [name=教授姓名]

## 第十四週紀錄 - 自選題proposal報告
>紀錄者：黃茄瑄
* 預計完成事項 (必填)
* 研究APPINVENTOR並使之可傳送藍牙訊號
* 購買材料
* 規畫地圖
* 將車車裝上籃子
* 完成Arduino檔的BFS演算法
* 實際達成事項 (必填)
* 5/24 王芮庭初步完成APP連接藍牙程式，黃茄瑄經測試後完成傳送藍牙訊號
* 5/25 彭亞綺購買材料
* 5/29 黃茄瑄完成噴頭組裝，籃子最後連同頂板一同蓋上,使用APP控制馬達噴酒精。
* 噴頭組裝：
* 5/29 王芮庭完成APP與arduino間互相傳訊
* 5/29 彭亞綺製作報告PPT

* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* 目前的車車

* 馬達連接噴頭的方式要用伺服馬達還是繩子控制
->雖然使用繩子控制不需要力矩很大的馬達，但考慮伺服馬達結構較簡單+比較好調整角度+節省時間，目前暫定使用伺服馬達黏在噴頭的柄上
* 太遠藍牙可能斷線，所以考慮wifi?
->考慮時間，決定demo還是先用藍芽連線
* 循跡繼續使用BFS?還是簡單的圓圈?
->覺得可以先繼續用BFS循跡
* 期末如何demo
->可以設定情境，假裝有人想呼叫車車，然後即可觀賞車車表演，且到時候要要確保整個空間只有地圖
* 地圖要長怎樣?
->可先使用之前的E型圖測試程式，如果可以成功那基本上就完成了，真正的地圖等下周再畫出來
->地圖prototype

* 指定題的python演算法要移到arduino(缺點是地圖不能太大)還是APP(不確定會不會太麻煩)內?
->目前暫定放arduino，地圖的設計可以不要太複雜，只要APP傳目的地，arduino就可以自己找路徑，要改程式也較方便
* 目前的呼叫車車的流程：幫每個站點編號，1234之類的，然後使用者輸入希望車車去的站號，arduino收到後再BFS，接著開始循跡，抵達目的地後再等待下一個指令
* 噴酒精是要時間控制還是按APP來控制?
->考慮到demo的效果，目前決定用APP按鈕控制
* 使用界面：

* 組員分工 (必填)
* 更新版甘特圖：

* 遇到問題之處理狀況、解決方式 (必填)
* 如何傳遞APPIMVENTOR的程式碼
->大家共享一個google帳號，共編APPINVENTOR的程式
* 希望使用者輸入的數字可以出現在arduino序列埠內，但一開始卻沒出現
->APP傳給arduino是字串形式，因此必須將變數改為字串型別
->arduino檔BT.availible()前要用if判斷式而不能用while迴圈(還不清楚為什麼)
* 想自製盒子或酒精支架，但製作上需要測量完成品，且不牢固
->尋找現成替代品也許成效更好
* 需要有一個穩固的裝置固定酒精噴瓶以及使它噴酒精時,盡可能噴到大部分籃子的範圍
->預計使用懶人手機夾，固定酒精瓶子，也可控制角度

* 課程建議 (選填)
* 無
* 想說的話 (選填)
* 疫情期間共體時艱

## 第十四週批閱區 - 自選題proposal報告
* 助教批閱欄
* 助教回饋
* 看到你們對於自選題的各種候選人，以及詳實的紀錄，感受到你們的充分討論 :smile:
* 因為你們指定題 & checkpoint 都表現很好，自選題也充分利用你們車子穩定的優點，或許加上盒子配重不同，要稍微調整一下參數。但整體應該不需要大幅度的更改。
* APP 介面也可以放在筆記上讓大家欣賞～
* 如果你們之後需要印地圖，我們都是去佳真影印（一張80*0.8=64）。出門採購要小心 QQ
> [name=周奕慧]
* 教授批閱欄
* 評分等第：A-
* 教授回饋1：你們的籃子看起來很專業喔!酒精灌先不要考慮裝在車上了，會不穩且車子馬力可能不夠，就是一個象徵性的demo，在你們設定的條件下，它就自動噴酒精，甚至噴水意思一下就好，畢竟酒精是防疫戰略物資，要省著點用啊XDDD
* 教授回饋2：建議你們可以設計一下你們的運送規則，讓他變得實用又有趣，還可以善用你們學到的演算法。
* 教授回饋3：現階段車子能不動就不動，建議多朝向車子本體以外的部分去發揮，公告中也說了，自選題期末評分會針對"車子"以外的發想及創意部分。加油囉~
* 教授回饋4：你們的紀錄很詳細清楚，分工也很明確，讚!
> [name=陳士元]
## 第十五週紀錄 - 自選題進度報告
>紀錄者：王芮庭
* 預計完成事項 (必填)
* APP、Arduino酒精+傳訊的檔案整合
* 畫好地圖
* 車車能順利接收指令抵達目的地
* 研究LCD、MP3腳位
* 實際達成事項 (必填)
* 5/31 完成APP酒精檔案整合
* 5/31 完成pythonBFS檔案整理
* 6/1 python檔案可讀寫google sheet
* 6/2 決定改用現有地圖
*
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* 考量現有時間與demo的可行性，決定目前先設定使用者只有1人，等到所有功能都完成後，有時間再來研究APP多人連線的功能
* 採購的東西皆已到貨，剩下助教配送的那部份了

* 組員分工 (必填)
* 0531更新版甘特圖
* 

* 遇到問題之處理狀況、解決方式 (必填)
* python格式寫入arduino時型別不同的資料沒辦法放入同一個list且MIT APP INVENTOR 無法直接使用python
->采用教授的建議，使用server-client的方式，以google spreadsheet為儲存BFS的運算結果
* 在update cell的功能裏，除了要找第一個裏面無資料的cell，還要做到不覆蓋前一次的資料
->目前的寫法可行，但感覺不是很完美，仍待改進->之後改為使用固定儲存格，但在每次的calling完成後清空儲存格再等待下一個指令
* googlesheet和python檔案的型別搞不太清楚
->用type()顯示型別，再另寫函式專門處理型別轉換，基本上都以字串來傳遞
* 不太知道如何控制python要再什麼時機讀資料，APP要在什麼時機讀資料
->目前是設定當python讀到的資料為數字時(但型別還是字串)開始演算法，APP讀到的資料為英文字母時(但型別還是字串)開始傳遞指令給arduino(因為每個站點的代號為數字，給車車的前後左右指令為英文字母)
* 【2021/6/2】[<font color="##008000">已解決</font>]貼地圖時發現沒辦法貼得很精準，會影響到測試的效果，而且太過花時間
->考慮疫情，決定使用現有地圖，一樣可以針對車車的功能demo
* 不太清楚如何讓python一直持續運作，待命等指令
->目前是用while(1)迴圈跑，前3、4次可以成功運作，但之後會有錯誤訊息(gspread.exceptions.APIError)，好像是因為金鑰或權限之類的問題
->原本想在每個迴圈都要求一次金鑰，但還是沒辦法
->在每次迴圈的最後，清空結果的list，執行的流暢度有改善，但還是三不五時有上述的錯誤訊息...
->Google Sheets API 限制為每個項目每 100 秒 500 個請求，每個用戶每 100 秒 100 個請求。讀取和寫入的限制是單獨跟踪的。沒有每日使用限制。解決方法:1.用time.sleep()緩衝時間2.申請放寬API的請求限制3.一次上船多個更改到表單以減少要求權限的次數。但我判斷真實循跡時應該不會有這個問題(因為有車子行走的時間緩衝)
->【2021/6/4】[<font color="##008000">已解決</font>]mit app inventor 開始出現連接問題，參考forum上的解決方法，重新安裝app只能解決一次問題，於是使用AI2 starter和手機usb調試來連接
->【2021/6/5】[<font color="#FFA500">解決部分</font>]Google Sheets API貌似會導致mit app inventor出現runtime error，跑出error的結果看起來是html於是做轉換
->錯誤測試視頻：https://youtu.be/oZnxgU9Hy8
->已脫離陷入error的困境，可能是加入了可輸入起始點，提交表單后再運行python。原因未知

->【2021/6/5 1716】[<font color="#f00">未解決</font>]每次運行時表單無法清除
->目前code block

* 課程建議 (選填)
* 很棒!
* 想說的話 (選填)
* 要遠距合作完成Project真的有點難，再加上進度很趕，時程真的很緊湊！雖然也是另一項挑戰，但還是希望疫情能盡快趨緩，讓大家可以群聚~

## 第十五週批閱區 - 自選題進度報告
* 助教批閱欄
* 助教回饋
* 看來你們已經做了不少事，很棒:+1:
* 地圖的部分的確可以先用現有的，畢竟時間有限，還是先把心力集中在車體上比較好。
* 好奇你們的酒精只能朝固定方向噴嗎?還是可以控制噴出的方向?
* 這學期遇到疫情的攪局，你們辛苦了!我也希望疫情趕快結束，想回到學校上課。
> [name=俞建琁]
* 教授批閱欄
* 評分等第: `A-`
* 教授回饋:
* 看到你們的 python (as the server) & app (as the client)之間的利用google spreadsheet來當資料傳遞的媒介好像遇到一些問題，這裡先提供一些建議給你們參考。
1. 你們現在用的google spreadsheet有點像是把它當作一個資料庫在使用，讓 python & app各自都可以access (Read and write)。以你們的架構，只要做成功了，其實也就ok了。但現在如果你遇到 authorization (因為需要用自己的google帳號登入)的問題，一直沒辦法解決的話，也可以考慮直接用真正的database (例如 mySQL, 或者比較簡單的 sqlite3來作). (雖然可能還需要再學SQL語法，並自己設計資料庫欄位; 但這應該比起用google spreadsheet更合適)(假如都是要花時間debug的話)。
2. 還有一種可能，是不需要用一個shared database來夾在python & app之間，而是直接讓 python (server) & app (client)透過 websocket或者 TCP/IP來溝通。Server這邊用python開一個daemon，一直聽某一個 port上是否有client傳來的指令，有的話，就馬上算BFS，並將結果傳回client. 而client & server之間的指令格式則要自己定義。因為 server的python和 client 的 MIT App inventor是不相容的兩種語言，這個client & server之間的溝通必須要做到 language-independent。一個簡單的格式就是用 json。Json格式幾乎所有語言都支援，不管是parse json or create json都有現成的library (python一定有; MIT app inventor我沒用過比較不熟，但剛順手google了一下發現也都是有)。不用太擔心json的格式不熟悉，因為parser & constructor都可以很容易google找到相對應的library可以call，不用自己寫的。當然，如果想用csv，也是可以。分工時，只要團隊把 指令的格式(例如json, or csv, or any other type)定好，然後就可以分頭做，每個語言的負責同學都要自己寫出那個語言的分析指令/產生回傳結果的routine，就可以兜起來了。
3. 再承上，除了用標準的 TCP或websocket來傳送(你們這裡其實是在整個Internet上直接作; 甚至連google server都讓你們當資料庫了)，也可以考慮類似 mqtt 這利用 subscriber / publisher架構的方式去訂閱及發行一個 topic作為app & python之間的溝通管道。
4. 總之要完成的兩者之間的溝通方法非常多，你們現在用的google spreadsheet只是其中一種。以上面列的意見就讓你們參考一下。只要有一種做法做出來就成功了。
* 期待你們順利完成。我想現在疫情期間，也許硬體上的合作真的比較困難，但軟體上基本上幾乎是不受遠距的影響的，值得投入一些心思在軟體架構上的設計，只要各個entity之間的介面大家有定好，分頭去做應不受影響。加油唷~
> [name=蘇柏青]

## 第十六週紀錄 - 自選題進度報告
>紀錄者:彭亞綺
* 預計完成事項 (必填)

- [x] 將原本利用google sheet達成的app與server互連改成直接傳輸封包between app and server
- [ ] mp3模組的研究
- [x] 整合lcd到app裡
- [x] arduino程式修改
* 實際達成事項 (必填)
* 6/7完成初步server和client連接
* 6/11 已領到助教寄送的零件
* micro SD 32G
* 三用電表
* 焊錫
* arduino程式修改->已完成第一版
* mp3模組的研究->先擱置將arduino整合做完
* 6/12完成APP和Python的運作
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* 由於原本使用google sheet作為傳輸媒介會有一些權限問題，我們採用教授的建議，也就是直接讓app(client)和server連接，利用wifi傳書封包
* BFS時應該要讓arduino自己回傳線在車車的位置以及面向的方向，再加上使用者輸入的終點，三個輸入送到server時，經由運算傳送一串指令給app在經由app傳送給arduino
* 自選題介面訊息傳遞說明:https://docs.google.com/spreadsheets/d/1I8F8bxCvO20Tokx5zIJVMs_RN5YWRzmejm0y3ZUSBD4/edit?usp=sharing
* Arduino 主程式架構:主要是將程式依功能做一個分檔的動作，目前有4個(循跡、LCD、噴酒精、mp3)然後在主程式loop中當藍芽開始接收值的時候，取第一個值當參考，再去決定要進入哪個功能，該功能執行一次之後再告訴app已經執行完畢，讓app更新現在車子的狀況，並且能夠接收下一次指令，為了避免藍芽傳不同訊息打架，一次只能接收一種訊息，做完後才繼續接收
* lcd arduino程式碼:https://github.com/amoee-5272/MY_CAR/blob/%E8%87%AA%E9%81%B8%E9%A1%8Cbobo/lcd1602.ino
* LCD 測試影片:https://youtu.be/v5wllawt0nk
* 第一次要輸入2個值(起點和終點，方向由arduino給)傳給python，之後只要輸入1個值(終點，方向由arduino給)傳給python。自定義python接收到的訊息：(順序這樣排方便寫程式)
若第一次輸入，百位start十位end個位direction
其他次輸入，十位end個位direction
* python是用html的形式寫到網頁上，但我們要的結果是陣列的型別
->按鍵要自行按兩次，使label變成成果，再自行傳送藍牙（本來想用mit app inventor的clock來處理，但發現會影響很多已經做好的部分，並且又不支持從其他檔案複製貼上，更改時需做許多操作故作罷）
->回傳string用"".join函式轉為字串，並將每個動作用「，」隔開，給APP傳遞訊息，若要進一步解析訊息，就交給arduino了(比較好處理程式的部分，且希望盡量減少傳遞過程的複雜度)
* 目前的arduino程式(lcd,servo,車車循跡結合):https://github.com/amoee-5272/bobo_car
* 目前的python程式
https://hackmd.io/@W0mR43kBQhOnutRP20qmPQ/B1TvJ0WsO
* 目前的APP方塊

* 目前的APP顯示介面
* 

* 組員分工 (必填)
* 甘特圖:https://docs.google.com/spreadsheets/d/1kVrpa3IGYdxjiYKD5CGp0oVQkxSvYkxgtIoo27c0YuA/edit?usp=sharing
* 遇到問題之處理狀況、解決方式 (必填)
* LCD已經可以依照app輸入字串的大小來去顯示(一行/二行/跑馬燈)，但是在做跑馬燈時，一直會出現bug，照理來說文字應該是在第一行並且每delay一段時間就向左移，但是有時候會有文字被擠到第二行 影片:https://youtu.be/PkHVP_If4kg
* 上禮拜貼地圖的照片，若未來還是想要用新的地圖，應該會採用列印的方式
* mp3模組需使用SD卡儲存音訊檔案，但目前沒有SD卡能夠測試(已拿到SD卡，以解決)
* mp3的部分目前還沒有找到適合的方法完成我們想要達到的功能(使用app錄音並傳遞給arduino並撥放出來)，目前mp3模組的部分頂多能讓車車變成一個行動式的藍芽喇叭，與我們的主題似乎不合
->目前先把重心放在結合現在3個功能的arduino程式，確保這三者能夠順利運行不會打架，再去處理mp3的部分
* 使用時須告訴車車他自己現在的位置，但不想讓使用者覺得每次都要輸入很麻煩
->讓python自動將車車前一次的終點存成下一次的起點，至於第一次就只能讓使用者輸入了
* LCD的螢幕較小，若是固定在車體上可能會不方便閱讀
->之後硬體實裝時可以考慮將連接LCD的電線延長讓使用者可以拿起來閱讀後再放回(可以設置一個小底座)，以達到方便使用的目的
* 有時車車可能在循跡時會出問題出軌，也許能夠加裝遙控功能(簡單的上下左右控制車子位置)來去輕鬆地幫助他恢復運作，平時無聊也可以把它當遙控車開
* 目前基礎功能大體完成，但仍在整合使用認知，接下來整合程式完畢將會把APP弄得更直覺一些

* 課程建議 (選填)
* 很棒! 不過助教寄零件的箱子完全沒封箱，一拉就開，可能有點危險，不過最後零件們還是經歷了四天從明達館安好的來到了大一女了😄
* 想說的話 (選填)
* 雖然因為疫情生活變化了許多，也比較無法和夥伴們有即時的互動，但我相信我們能最後夠完成這項專案的
* 剛剛在結合各種Arduino檔，為每個分開的功能加上註記，雖然總算編譯是過了，但感覺一直有一些會互相衝突的問題，感覺之後的DEBUG和硬體測試還有一段時間要走阿，~~不知不覺就早上五點了，時光好可怕~~

## 第十六週批閱區 - 自選題進度報告
* 助教批閱欄
* 助教回饋
> [name=助教姓名]
* 教授批閱欄
* 評分等第：A
* 教授回饋1：詳實完整的紀錄，你們的時程規劃跟分工也都很清楚，甘特圖很棒!
* 教授回饋2：確實，mp3是比較獨立的一塊，建議先完成其他部分，再來看有沒有時間完成這部分。
* 教授回饋3：建議要開始規劃你們打算demo的方式跟情境，因為這也跟你們最終需要完成的整合程度有關。(感覺你們好像有在宿舍"一起"做專題喔，希望你們要注意自己的健康，避免群聚喔!)
> [name=陳士元]

## 第十七週紀錄 - 疫情下之調整與心得建議
* 預計完成事項 (必填)
* 整合APP、python、Arduino，讓車車可以實作MP3、噴水、叫車服務
* 美化APP介面
* 實際達成事項 (必填)
* 6/15 完成美化後的介面模板(但功能尚未整合)
* 6/16 完成arduino檔案的初步整合
* 6/17 完成python檔案的整合
* 組內討論事項 (必填，如問題、構想、分工合作、時間安排...等等)
* 經討論後決定車車方向由python自己記著，使用者只須在一開始輸入start、end、direction，之後就只要輸入目的地即可
* 經美化後的APP介面

* 整合後的Arduino檔
https://github.com/amoee-5272/bobo_car
* 整合後的Python檔
https://hackmd.io/@W0mR43kBQhOnutRP20qmPQ/Syli0VijO
* 下周就是期末考週了，希望這週可以把介面的溝通處理好，流程大概是
* 藍芽 -> APP整合 -> APP+Python+Arduino三位一體
* 預告下週至6/28該做的事
* 調整馬達參數 -> 美化車車或其他硬體的最後調整 -> 準備demo(包含策畫+錄影)
* 組員分工 (必填)
* 彭：Arduino的整合、MP3模組的測試
* 王：python的整合、APP的整合
* 黃：測試藍芽連線、調整參數等需實作的部分
* 遇到問題之處理狀況、解決方式 (必填)
* 藍芽連線問題(Arduino序列埠沒反應?)
* 疫情下實作受的影響
* 我們本來都比較常在open lab時段來討論及進行製作，open lab不開放後，溝通上有時不在同一個頻道，而且出問題時沒辦法直接共同測試，常常需要自己處理，效率實在不太好。此外，身在各處，測試方法也不同，出現的問題也相異，有時候很難將自己遇到的瓶頸傳達給組員，容易溝通不良，反而花費更多時間來debug；反過來說，在這種遠距合作的情況，我們也很難掌握進度現況，要維持彼此的聯繫與實作的進展很是不容易。
* 分工如何調整因應的心得
* 面對疫情下種種合作的挑戰，我們嘗試將各個功能分別獨立出來，分割成小部分，以此來減輕個人負擔，但同時也面臨整合的障礙。><
* 我們也將功能範圍縮小，先放棄語音傳訊的部分，將火力集中在主體功能的流暢度。
* 我們有時會以語音通話的方式討論，增進效率，效果顯著。
* 設置一些共同可以access到的檔案(如google表格、或操作影片)，紀錄變數或留下使用說明，讓其他組員可以快速了解現況，且可避免在整合時才來處理使用認知。

## 第十七週批閱區 - 疫情下之調整與心得建議
* 助教批閱欄
* 助教回饋
> [name=助教姓名]
* 教授批閱欄
* 評分等第: `A`
* 教授回饋:
* 美化後的App介面看起來漂亮很多！希望從藍芽到app到python到arduino之間的介面整合可以順利完成。
* 很能理解你們在疫情下實作遭遇的困難與挑戰，也很高興聽到你們嘗試著找出疫情下突破工作效率的瓶頸的各項方法，尤其是團隊成員間溝通的部分。
> [name=蘇柏青]

## 第十八周紀錄 - 終於走到最後一周
* 期末專題最終檔案
* https://drive.google.com/drive/folders/1rcSI43AlZrJsGAvx__wEKAW7kgL4GMwN?usp=sharing
* 接角:
* 遇到的困難
* 原本另外分開測試lcd都沒問題，但是要用車車測試時就完全沒反應連SETUP那邊都無法，
->原本紅外線感測器接再A4 A5但是LCD的I2C模組必須使用這兩個角位，將兩個紅外線模組的角為移開後就順利了
*