第十九組 rm -f隊
一、認識
朱慶章:
1.認識程度:雖然自己還沒用過,但是之前看同學用過。4B上市后還是比較心動的,相對3提升很大,最高支持到4G的內存就是飛躍了，一度想買不過沒啥時間玩放棄了。
2.可以用來做什么:見過做智能家居物聯網這類的,也有看過搭網站的,后面有空跑一個人臉識別吧,家里還有一個I2C的12864OLED看看到時候可以玩啥。
陳夢雪:
1.認識程度：有聽說過這個名字，但是不知道它到底是干嘛的
2.用途：可以用在機器人等智能設備上 如果是我我會用在動態只能攝像頭上
潘海東:
1.應該算半個樹莓派愛好者吧，接觸樹莓派2年多時間了，自己買過兩個樹莓派，雖然大部分時間都是在吃灰，但一出新版還是忍不住想買。特別是這次的4，大內存+USB3可太令人滿意了，之前好多想玩的項目就是因為會爆內存做不了，這次有了4G內存，能玩多新花樣。也在樹莓派上玩過挺多項目，搭過web服務器，做過NAS，還做過多媒體服務器，有時也會跑一些簡單的Python腳本。
2.可以用來做什么：樹莓派價格友好，且是一種介於PC機和單片機之間的形態，不僅具有單片機的特點，還有着遠超單片機的性能，能夠完成很多很多工作。如微型服務器、對計算量有一定要求的嵌入式系統、機器人、甚至還有人用幾百台樹莓派組成超級計算機進行大規模運算。
想用樹莓派來做什么：因為接觸樹莓派已經有一段時間了，一些比較正常的項目都已經自己嘗試過了，但是最近偶然發現了一個好項目，樹莓派版“小愛同學”，利用樹莓派搭建一個AI智能助手，看上去挺好玩的，而且實現好像也不是很困難，但就是對硬件有一定要求，如果能湊齊硬件，應該會試着實現一下。
二、系統燒錄和備份
1.下載鏡像
訪問官網(https://www.raspberrypi.org/downloads/raspbian/)下載鏡像
Lite版本是最小化安裝，沒有桌面環境；
Desktop版本則帶有桌面；
Desktop and recommended software版本帶有推薦軟件，比較大
2.燒錄鏡像
燒錄軟件很多,我比較常用的還是Rufus,當然軟碟通之類的同理都可以,大同小異
引導類型選擇一欄右側的選擇按鈕選擇你的鏡像
點擊開始寫入鏡像
寫入完畢
3.備份
備份工具也有很多,這里我用win32diskimager
在你指定的目錄下創建一個空的.img文件,點擊讀取即可
三、訪問樹莓派
因為目前手上沒有顯示器,這里使用SSH和VNC訪問樹莓派
1.開啟ssh並配置網絡
創建一個空白的文件ssh用來開啟ssh
編輯創建一個wpa_supplicant.conf用於聯網，根據你的實際情況填寫ssid和psk
country=CN
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="TP-LINK_ED40"
psk="18750060424"
priority=1
}
然后把這兩個文件放到SD卡的根目錄
SD卡插入樹莓派，插電開機
2.ssh
訪問路由器管理界面,獲取到樹莓派的IP地址
可以看到樹莓派的IP地址
如果你使用Windows,可以安裝一個openssh(只安裝客戶端即可)
openssh的官網(https://www.mls-software.com/opensshd.html)
只勾選客戶端即可，其余一路默認
當然這里也可以用Putty替代openssh,大同小異
打開cmd，通過ssh登錄到你的樹莓派
初始默認用戶名pi 密碼raspberry
登錄后可以嘗試進行改密碼的操作
修改默認pi賬戶的密碼
3.VNC
ssh登錄后開啟VNC以便我們連接時使用圖形化界面
sudo raspi-config
在自己的機器上下載VNC
官網(https://www.realvnc.com/en/connect/download/viewer/windows/)
直接輸入樹莓派的IP訪問
如果需要使隊友也可以遠程訪問的話,建議做內網穿透。可以用花生殼、蒲公英這類的東西。
有動手能力的話，推薦Padavan,可以把花生殼集成在路由中。
但是因為我目前在家使用廣電網絡,入戶前套了多層NAT,網絡質量感人,做內網穿透沒有很大意義。
4.文件傳輸
(1).WinSCP
原理是SFTP
為了方便傳輸文件，可以安裝一個winscp
官網(https://winscp.net/eng/download.php)
官網訪問挺慢的，以前玩路由有裝一個winscp就直接用了
填好相關信息就可以登錄了
winscp支持直接拖拽
舉個栗子，把后面提到拍照生成的test.jpg拉下來。
(2).使用VNC進行樹莓派與PC端之間的文件雙向傳輸
樹莓派向PC發送文件
點擊樹莓派頂部狀態欄中的VNC圖標
點擊右上方菜單欄圖標
選擇文件傳輸功能
選擇好需要傳輸的文件，就可以向PC傳輸文件。
PC向樹莓派傳文件
點擊VNC界面中間的文件傳輸圖標
同樣，選擇好想要傳輸的文件即可。
四、接入攝像頭
1.開啟攝像頭
關機插入攝像頭排線，再開機
首先在設置中打開攝像頭的連接
sudo raspi-config選擇interfacing opinions，選擇Camera，並Enable
然后重啟
2.控制攝像頭拍照
from picamera import PiCamera
from time import sleep
camera = PiCamera()
sleep(5) # 攝像頭感光
camera.capture('/home/pi/Desktop/test.jpg') # 拍照並保存
3.實時視頻監控
我拍攝了下面五種方法效果視頻，從視頻中可以直觀地看出各個方法的延遲，視頻附在博客中了(特別鳴謝:海東同學的圖床)
如果博客中看不了可能是我們的圖床流量爆掉了,請在評論提醒我們。
也可以點擊后方鏈接觀看，視頻我已上傳B站,鏈接:(https://b23.tv/BhWRGr)。視頻BV號:BV1r5411s7Lg
或B站搜索我用戶名JanOJorgensen。
方法(3)(4)(5)都比vlc直接接收網絡視頻流延遲低。
速度慢的原因分析在遇到的問題3中。
（暗示加分）
(1).OpenCV
import cv2
cap = cv2.VideoCapture(0)
while(1):
ret, frame = cap.read()
cv2.imshow("capture", frame)
if cv2.waitKey(1) & 0xFF == ord('q'):
break
cap.release()
cv2.destroyAllWindows()
這個方法只能在本地窗口中顯示，雖然畫面延遲很低但是對於實時監控的意義不大。
opencv本地：
(2).raspivid +vlc獲取實時視頻流
通過vlc實時讀取攝像頭捕獲的影像,也就是老師博客里的方法了。這個方法延遲非常高。
延遲高的原因我在遇到的問題中詳細分析。
raspivid -o - -t 0 -w 640 -h 360 -fps 15|cvlc -vvv stream:///dev/stdin --sout '#standard{access=http,mux=ts,dst=:8090}' :demux=h264
官網資料：(https://www.raspberrypi.org/documentation/usage/camera/raspicam/raspivid.md)
access=http 使用http協議傳輸視頻流
-h 視頻高度
-w 視頻寬度
-o - 輸出寫到stdout
-t 0 無延時
-fps 每秒傳輸幀數
dst 網絡端口
demux h264 視頻壓縮格式
然后vlc里選擇打開網絡串流
這個方法非常慢，雖然局域網其他機器也可以通過vlc獲取到樹莓派拍攝視頻流，但是延遲非常高，大約快到五秒了。可以看我視頻中向下轉動攝像頭的動作，很明顯延遲巨大。
vlc串流：
(3).motion
motion官網(http://www.lavrsen.dk/foswiki/bin/view/Motion)
motion的特點在於運動物體的檢測，可以在畫面中出現活動物體時才開始拍攝並記錄
安裝
sudo apt-get install motion
編輯設置
sudo nano /etc/motion/motion.conf
然后修改
deamon off 改成 on
分辨率幀率訪問端口等等都可以自己設置
啟動
sudo motion
然后在瀏覽器查看
http://localhost:8080/
效果在上面提到的視頻鏈接
最后關閉
sudo killall -TERM motion
motion：
(4).Pi Video Streaming Demo
項目GitHub地址:(https://github.com/waveform80/pistreaming)
原理上是在客戶端使用了基於JavaScript的MPEG1解碼器
js解碼器的GitHub：(https://github.com/phoboslab/jsmpeg)
這個方法的流暢程度和下面的方法(5)不相上下的。
安裝依賴
pip3 install ws4py
clone項目到本地
git clone https://github.com/waveform80/pistreaming.git
運行
cd pistreaming/
python3 server.py
瀏覽器打開
http://localhost:8082/
Pi Video Streaming Demo：
(5).mjpeg-streamer
安裝依賴
sudo apt-get install cmake libjpeg8-dev
項目git(https://github.com/jacksonliam/mjpg-streamer/)
下載mjpeg-streamer的源碼
並解壓到用戶主目錄
進入到源碼的mjpg-streamer-experimental目錄，然后編譯
cd mjpg-streamer-master/mjpg-streamer-experimental/
make
編譯結束安裝
sudo make install
然后就可以運行了
根據你的攝像頭選擇參數,他也支持uvc
/usr/local/bin/mjpg_streamer -i "/usr/local/lib/mjpg-streamer/input_raspicam.so -fps 15" -o "/usr/local/lib/mjpg-streamer/output_http.so -p 8080 -w /usr/local/share/mjpg-streamer/www"
然后打開瀏覽器
訪問http://localhost:8080/
延遲和上面提到的第四種方法使用js解碼器是接近的,會略好一些
mjpg：
五、遇到的問題和解決方法
問題1:VNC無法顯示桌面
解決方法：
ssh進去調整一下分辨率
修改后會提示重啟機器。
問題2:OpenCV無法import
首先，樹莓派的官方鏡像里不只有python3也有python2，所以在pip install的時候，如果你想使用python3運行程序，請用pip3 install
然后是版本的問題，雖然在老師博客(https://www.cnblogs.com/fjlinww/p/11956264.html)上我看到4B+python3.7+opencv4.1.2可以使用，
但在我這出現了問題(依賴我也都裝了)。故嘗試降低版本，退到3嘗試成功了。
我的建議:
pip3 install opencv-python==3.4.6.27
下次實驗我會再嘗試一次4B+python3.7+opencv4.1.2
問題3:為什么使用vlc接受網絡串流的時候速度這么慢？
我翻到的一篇文章，可供參考
節選了重點內容:(文章比較長我就不翻譯了,沒有什么生僻詞,內容還是比較容易讀懂的)
When streaming JPEGs, the camera captures a full frame, encodes it, and dumps it over the net. The client now has a full frame to display (and decoding time is negligible) so the latency is down to the capture, encoding, and transmission time of the frame. In practice, capture and encoding are tiny too, so we'll say it's all down to transmission time.
When streaming H.264 (or any MPEG-ish format in general) things are a tad more complex but not much so. The first frame output by the encoder will be an I-frame (a full frame), so this case is exactly like JPEG (except H.264 I-frames are better quality for the same number of bits): the latency is down to transmission time of the frame. The next frame output by the encoder will most likely be a P-frame (a "predicted" frame) which can't be decoded without knowledge of the preceding frame. All that really means in practice though is that it's much smaller; again, latency is down to transmission time.
What if the prior frame got dropped (you are using UDP after all)? Assuming no re-transmissions, you can't (accurately) decode further frames until the next I-frame. This doesn't exactly affect latency, but in the JPEG scenario it would result in one corrupt frame; in the H.264/MPEG scenario it results in multiple corrupt frames (how many depends on the I-frame period - it's typical to set this quite low when streaming, e.g. once every second or two).
So far, both schemes are looking exactly the same for latency (except H.264 suffers more with dropped packets, but provides better quality). When dealing with camera output that is indeed the case: there's no reason H.264 should have any worse latency than JPEG (and given the smaller transmission sizes it should actually be a bit better). So why does streaming H.264 give poor latency with things like this recipe?
There's another frame-type we haven't considered in the H.264/MPEG scenario: B-frames ("bi-directional predicted" frames). These can't be decoded without knowledge of prior and subsequent frames. Obviously, in a streaming application this will incur latency as you have to wait for the next frame before you can decode the current one. However, we don't have to worry about that because the Pi's H.264 encoder never produces B-frames (I have heard it's common for most video cameras to only produce I-frames and P-frames, which makes perfect sense when you consider they're encoding live material, not pre-recorded stuff where they can look at the next frame to produce a B-frame). So, on the camera side of things B-frames aren't relevant...
But what about the client side? H.264/MPEG players don't know that their source is never going to produce a B-frame. They also assume (not unreasonably) that the network is not reliable and that uninterrupted playback is the primary goal, rather than low latency. Their solution is simple, but effective: buffering. This solves uninterrupted playback and providing space for decoding B-frames based on subsequent frames all in one shot. Unfortunately it also introduces as much latency as there are frames in the buffer!
So, your major issue is on the client side: you need to write/find/coerce client software into forgoing buffering to immediately decode and display incoming frames. Sadly, this is where my knowledge runs out. While mplayer can be cajoled into low latency playback by seeking forwards after playback starts, that's a nasty hack and I'm not aware of ways to accomplish this in other software (VLC, HTML5 <video> tags, etc.), or ways to reliably automate it either.
問題4:mjpg-streamer源碼編譯出錯
這個問題出現在我嘗試各個版本的mjpg-streamer時。
版本r172在樹莓派4B的最新系統上編譯會出現問題(前文我提到的使用方法用的不是r172)
這個版本可以在(https://sourceforge.net/p/mjpg-streamer/code/HEAD/tree/)找到
需要用svn下載
解決方法:修改源碼的utils.c
sudo nano utils.c
注釋掉
#include <linux/stat.h>
#include <sys/stat.h>
問題5:重新燒入系統后ssh登陸失敗
刪除原有的記錄就好
六、小組協作
組員
朱慶章 | 031702426 | 負責實際操作 |
陳夢雪 | 031702405 | 負責查找資料 |
潘海東 | 031702428 | 負責提供指導意見和博客圖床搭建 |
我們組的樹莓派是寄到我這的，不過海東自己也有一台並翻出來一個USB接口的攝像頭，我在機器上實驗的時候海東也可以在自己的機器上實驗
小組內主要通過視頻和圖片分享協作
