# 專題 - 新思 AIoT 2022
### 概述：
本專題為參加[新思科技 2022 之 AIoT 應用比賽](https://contest.synopsys.com.tw/2022ARC)[^3]，期間為(2022/03/03~2022/07/22)
成果：取得「**企業贊助獎**，獎金共三萬元」 - [所有得獎作品連結](https://contest.synopsys.com.tw/2022ARC/PreviousWinner)、[本隊得獎作品連結](https://contest.synopsys.com.tw/2022ARC/WinnerDetail?ID=21)
[demo影片連結](https://youtu.be/1bMMYYZJOPc?t=281)
[作品說明及程式碼](https://github.com/ARC-AIOT/Hardware/tree/master/combine)

### 指導教授：
成大電機系 陳中和教授，計算機架構與系統實驗室主持人
### 組員：
成大電機系大四 蔡哲偉、蔡孟宗、吳泓修

### 本隊題目 - 結合 AI 影像辨識的輔助老人用藥系統：
希望做出一個系統藉由影像辨識從藥袋讀出用藥資訊，並達到以下功能：
1）在正確的時間自動提醒老人用藥
2）避免老人因忘記自己已經吃過藥了再次重新吃藥

### 分工
蔡孟宗（我）：
硬體顧問，負責除超音波模組外所有硬體相關的功能、軟硬體整合、硬體架構圖繪製及說明文件的撰寫，可從我們的 [github repo history](https://github.com/ARC-AIOT/Hardware/commits/master?before=2520b948961fca6d4cc4e20c35e73646cef19ea1+35&branch=master&qualified_name=refs%2Fheads%2Fmaster) 看出我負責所有硬體相關程式碼的編寫（我的帳號是 fennecJ），同時也協助組員順利使用開發板提供的相機模組進行拍照蒐集 data set。
報告時負責介紹各個硬體及作品的 DEMO 情形。

吳泓修 ：
負責所有 data set 的蒐集，並與我合作使超音波模組順利運作

蔡哲偉 ：
負責將泓修蒐集的 data set 餵給機器訓練模型，並將訓練好的 AI 模型上傳到開發板，同時擔任組長負責和主辦單位接洽。
報告時負責介紹 AI 模型的設計和預測表現評估。

### 硬體架構圖：
架構圖：
硬體概覽詳見 [Overview of hardwares](https://github.com/ARC-AIOT/Hardware/tree/master/combine#overview-of-hardwares)

### 我的貢獻：
* 在有限的 I/O socket 下整合 OLED 模組，dfplayer及喇叭模組，搖桿模組及超音波模組。
* 結合搖桿和 OLED 模組設計直覺的 UI (使用者互動界面)。
* 使照片傳輸的所需的時間從 **8 分鐘降低至 3 秒鐘**，節省了**99.4％的傳輸時間**，提升 data set **160 倍的蒐集效率**
* 為了方便使用dfplayer，參考了 dfplayer 的 [data sheet](https://picaxe.com/docs/spe033.pdf) 為他寫了專屬的[驅動程式](https://github.com/ARC-AIOT/Hardware/blob/master/DFPlayer/src/DFPlayer.c)（driver）並成功運作，這是我在這個專題中遇到的最大挑戰也是最有成就感的事，因為要順利寫好 driver 必須要：
* 搞懂 uart 的溝通原理
* 追蹤開發板的程式碼，找出用它發出 uart 訊號的 function
* 從 data sheet 中看懂 dfplayer 的通訊協定格式並使板子傳遞正確的訊號給它

<br/>
<br/>
<br/>
### 我解決的難點：
### 難點一：
如何順利驅動 dfplayer
#### 描述：
一開始即使參考 [data sheet](https://picaxe.com/docs/spe033.pdf) ，照著硬體要求的訊號格式傳訊號給 dfplayer 模組它仍然絲毫不動
#### 問題解決：
仔細追蹤程式碼後發現
1. 開發板有**多個訊號溝通模式**，需要切換到特定溝通模式才能使用 uart
2. 開發板有兩種傳 uart 的 function，但**其中一種只會傳給 usb**，另一種才能藉由 uart socket 和外界溝通，而另一種 function **並未出現在開發板官方的參考技術文件中**，因此我花了很多時間追蹤程式碼才找到這個 function

找到對應的 function 後就能順利驅動 dfplayer 了

### 難點二：
圖片傳輸效率過低
#### 描述：
我們需要用板上的相機拍照製作 data set 以便用來進行機器訓練，但原本官方提供的照片傳輸方法效率過低，一張清晰照片的傳輸需要約8分鐘[^1]，且**需要經過人工處理**，因此有時會失敗。
#### 問題解決：
##### 階段一 - 解決人工處理造成偶爾失敗的問題：
原本官方提供的作法是將資料以 ASCII 的形式經由**序列埠 (Serial port)** 傳輸到電腦的終端機上，然後**人工手動複製及編輯終端機收到的資料**，最後以腳本把處理好的資料轉換為圖片。
為了避免人工手動複製這個問題，我學習了如何**以 python 接收序列埠的資料，將資料處理的流程自動化**後餵給官方提供的腳本，**移除人工手動處理的流程，降低傳輸資料缺失損壞的可能**

<br/>
<br/>
##### 階段二 - 提昇傳輸效率
雖然降低了人工處理導致資料缺失的可能，但即使如此一張照片仍須等待 8 分鐘，而我們的 data set 預計會需要用到數百張圖，8 分鐘的傳輸時間是難以接受的。
仔細審視官方提供的程式碼，可以發現官方的傳輸效率極差：
官方提供的作法會將二進位圖形資料轉為 ASCII 文字資料在傳過來，相當於需要傳輸的資料會變為**3 倍左右**[^2]，且使用 uart 經由 usb 接口傳輸到電腦上， 而連接 usb 接口的 uart 傳輸速度被鎖死在 9.6Kbps。
一開始我打算讓板子直接傳二進位的圖形資料而不經過 ASCII 轉換，如此有望**節剩 66％ 的傳輸時間**，但後來在我仔細研究開發板相關文件後，發現相機可藉由 SPI 接口和電腦溝通，而 SPI 的傳輸速度從 5Mbps～20Mbps，甚至更快的速率都有，相當於比原本 uart 的 9.6Kbps 快數百倍以上，因此花了幾天研究後，順利以 SPI 接口從電腦接收板子傳輸過來的圖片，並**從原本 8 分鐘降到 3 秒鐘**就能產生一張 data set，節省了**99.4％的傳輸時間**，提升 data set **160 倍的蒐集效率**。

### 難點三：
板子只提供一個 ADC 接口
#### 描述：
我們用到的搖桿有三個訊號：
* 按鈕有無壓下的數位訊號
* x 方向和 y 方向的類比訊號
其中 x y 這兩個訊號都需要用 ADC 解析才能得出不同的數值，而板子雖提供多個數位訊號接口，但只提供一個 ADC 接口
#### 問題解決：
重新設計使用者互動界面，改成：
1. 搖桿 y 方向訊號接ADC用來讓使用者可以上/下調整選單游標
2. 搖桿 x 方向訊號僅用來表示返回（詳見下頁 ascii 圖）

+---------------------+             +---------------------+       +---------------------+
|Sat Jan 1 2022       |             |Sat Jan 1 2022       | Press |Sat Jan 1 2022       |
|00:00                |             |00:00                |  Btn  |00:00                |
|  time setting       |             |  time setting       +------>|                     |
|> text detect        |             |> text detect        |       |                     |
|  When to take med   |             |  When to take med   |<------+                     |
|                     |             |                     | Stick |                     |
|                     |             |                     | left  |<- back              |
+-----+---------+-----+             +---------------------+       +---------------------+
      |         ^                                  (x-dir for go back only)
      |   Joy   |
 Down |  Stick  | Up
      |         |
      v         |
+-----+---------+-----+
|Sat Jan 1 2022       |
|00:00                |
|  time setting       |
|  text detect        |
|> When to take med   |
|                     |
|                     |
+---------------------+
 (y-dir for go up/down)

由於 x 方向的訊號僅用來表示返回，因此搖桿 x 方向只要有：
1. idle
2. 搖桿向左

兩種狀態即可，也就是說我們可以把它當作像是一個按鈕一樣來看待，以三用電錶測試後發現搖桿在 x 方向 **idle 時傳遞的類比訊號數值並未超過開發板 High 訊號的域值，而搖桿向左時傳遞的類比訊號數值則能超過開發板 High 訊號的域值**，因此直接把它接在數位接口上仍能運作正常。

### 最終結果：
硬體部份：
所有硬體都能如預期順利運作，這部份由我負責。
軟體部份（AI）：
AI 的部份因為板子上可用做AI運算的資源（暫存器數量，memory等）過少，
導致原本 train 好的 model 無法順利部署到板子上，我們為了能將 model 部署到板子上對模型做了很多的精簡，最終雖然順利將 AI 部署到板子上，但代價確是準確率變得很低。
即使 AI 表現不佳，但由於我們並未使用任何額外的開發板就整合所有硬體，且靠自己找到使用 uart 的方法，因此最終有幸獲得企業贊助獎。

<br/>
### 註解
[^1]:官方提供的傳輸方法為將圖片進行**16倍**的壓縮後傳到電腦上並進行後續處理轉換成圖片，一張圖片約須**30秒鐘**，但照片過於模糊，若傳輸未壓縮的照片則需要約8分鐘且可靠度差，平均成功律僅6成，因為傳入的資料後續**還須經過人工處理**

[^2]:1 byte 的二進位資料轉成 16 進位 ASCII 值加上分隔用的空格會有 2 ~ 3 個字元（分隔用的空格 1 個，16進位的數值 1～2 個），而每個字元 (Char) 佔 1 個 byte，相當於傳輸量變為 2～3 倍。
而要有三個字元只要二進位資料的 10 進位數值大於等於16 (0x10) 即可，也就是說 0～255 這 256 個數字中，只有 0～15 這 16 個數字會對應到兩個字元，假設資料平均分佈，則圖片放大倍率的期望值約為：
$$ 2 * \frac{16}{256} + 3 * \frac{240}{256} = 2.93 倍 $$
但由於我們拍的 data set 是藥袋，會有大面積的白色部份，而越亮（白）的部份其數值會越大，放大三倍的佔比會更多，因此最後放大倍率會 $ > 2.93 $，我們可以直接把它視為傳輸變為原本來的三倍
[^3]: 所有藍色字體皆為可點選之超連結