FJUCam2/VCam的生態系統

近日看到EETimes文章提出一個觀念：Robust Ecosystem=Embedded Success[1,2]，意指一個嵌入式系統要成功，必須要能提供完整的生態系統（Ecosystem），例如完整的開發環境、完整的應用、完整的周邊。

我看了後深有感觸，覺得我們智慧型實驗室在發展FJUCam/VCam的方式，就是這樣一個觀念，因此乃撰此文以為呼應。

我們的FJUCam/VCam也有野心要提供Ecosystem，但是是針對Smart Camera概念的生態系統，範圍從軟硬體元件、開發環境、應用等3個方面，都提供完整的嵌入式視覺(Embedded Vision) [3,4] 系統架構。

為何這樣做？因為嵌入式的應用包羅萬象，涵蓋範圍廣泛，尤其是朝嵌入式視覺方向走，則更需要高性能的MCU/DSP來完成。再加上需要高速網路連結、大量記憶體、快速資料儲存傳輸等需求來完成電腦視覺運算，則更難找到適合的平台（含硬體與軟體的整合平台）。

我在大約三年前(民國96年)開始尋找適當的平台。我的目的其實很簡單：有一套效能跟PC接近的嵌入式系統，處理器能在2GHz以上，記憶體需要1G，可以用C語言來開發電腦視覺演算法，能達到至少每秒10張影像的處理效能。

更重要的是，最好學生都不用懂硬體，直接就可以撰寫演算法達到此效能。

我從MCU、FPGA、一路找到DSP，全都失望。不僅效能不夠，絕大部分都不談如何接攝影機以輸入影像與視訊，更有許多都沒有作業系統。

這個探索的歷程，真是一言難盡。

直到98年我才突然醒悟：原來所謂的嵌入式系統，其定義就是「資源有限」。而我們以前在PC上發展電腦視覺演算法，都是本著「資源無限」的觀念來開發。

所幸在98年開始，發現計算機硬體開始有一個新潮流走向：多核心。其效能看來可以有我預期的程度，因此開始有了信心。

再加上Embedded Linux從99年開始大量使用，開發環境趨於普及，開始覺得我們有機會可以做作看了。

但是有了晶片、有了OS，問題仍然存在：我無法讓學生都不用懂硬體，直接就可以撰寫演算法達到良好效能。

原因是：現有的多核心嵌入式開發板，體積大的像恐龍，無法連接各種介面的Camera介面（USB等），有些還要自行編譯或撰寫驅動程式。

除此之外，軟體發展環境複雜的難以接受，一大堆的設定，還要瞭解記憶體規格才能完成設定。我一直都找不到直接就設定好的軟體環境，以供學生自由開發演算法。

後來才又發現：原來多核心這樣一個新的計算機技術，在硬體與軟體層面都是新挑戰。硬體上，板子還沒有人有能力做到非常小。軟體上，還沒有人能將多執行緒平行化的程式庫建立起來。

因此就是還沒有可以用的板子。看來要等人做出來的話，要等至少3～5年。而且還不見得可以適用於發展電腦視覺演算法。

但為何國外的前瞻實驗室，都可以做嵌入式視覺的研究呢？

原來就是要一切自己來。

我忽然醒悟：原來前瞻的研究，軟硬體都要自己來。MIT Media Lab就是如此。這樣創意才不會受限。

原來我已經不是單純要做論文或發展演算法而已，我是要朝創意發展。

所以得要自己做板子，瞭解硬體的特點並知道如何發揮硬體效能，然後自己發展軟體程式庫，就可以開始做演算法，並實現創意應用技術。

為做到這樣，我們真的開始建立一個Smart Camera Ecosystem了。

我們面臨的挑戰，是我們必須深入瞭解Camera硬體與計算機硬體的軟硬體架構，拆解其技術成分；然後我們再去尋找各個技術的解答，分析其優缺點，決定自己的規格；最後再再開始自行做硬體與軟體，以發展出我們理想中的軟硬體平台，成為FJUCam。

我們已經有發展一套FJUCam，是以ARM7為核心，運算能力雖然只有60MHz，記憶體只有64KB，且沒有作業系統，但整合了一套C語言程式庫以供開發演算法，可以做人臉偵測與機器人視覺的簡單應用，並且適合應用在Sensor Nework。預計在100年1月會有碩士論文產出，並放在網站上公開其研究內容。

但我們目前也已經開始著手第二代的FJUCam，稱之為FJUCam2/VCam，採用異質雙核心(Heterogeneous Dual-core)的DSP，CPU運算速度可以比FJUCam快10倍：600MHz，記憶體容量高2000倍：256MB，並且可以外接各種周邊。若會撰寫DSP程式再使用其DSP核心，則會有更高的效能。

我們的FJUCam2/VCam目前已經有以下的成果：

1.在軟硬體元件方面，我們開發一個異質雙核心(Heterogeneous Dualcore)處理器的高效能嵌入式電腦。其視訊輸入可以連接3種攝影機介面(Camera Bus、LVBS Video In、USB)，並且可以自行組合各種Camera元件(各種焦距距離的鏡頭、CCS/CMOS感測器、Omni-cam、NIR/Thermal Cam [5]、Wearable Cam、Stereo Cam等) [6]。視訊輸出可以用HDMI/DVI連接液晶螢幕與投影機。作業系統方面以Embedded Linux為主，但已經可以有5種作業系統：Android[7], Angstrom, Meego[8], Linaro, Ubuntu。

2.在開發環境方面，我們除整合既有的API/Lib(OpenCV, FFMpeg等)，也發展自己的API/Lib: EVK(Embedded Vision Kit)。我們可以依不同的作業系統，建立GNU整套開發環境。我們也整合Qt的視窗程式庫。

3.在應用方面，我們已經有幾組同學，分別將FJUCam2/VCam應用在開發醫療(Medical)、視訊監控(Video Surveillance)、擴增實境(AR)、機器人視覺(Robotic Vision)、3D/Stereo、與行動雲(Mobile Cloud)。

我們認為FJUCam2/VCam是一個高效能的嵌入式視覺平台，是一個經過整合好的硬體、軟體、與攝影機的開發環境，可以讓後續的研究生與研究者不需瞭解太多軟硬體細節，很容易就可以開始實現電腦視覺演算法，並開發創意的應用。

我們在短期內將會陸續有成果產出，並透過網路公開分享給有興趣的研究者。開發環境部分含EVK會Open Source，應用方面會挑選重要者提供Reference Design。軟硬體元件則交由廠商去發展。

我們希望透過這些研究成果，展現ISLab同學的能力，並與其他有興趣者一起來努力，發展嵌入式視覺的研究。

[1] ST Virtual Conference: Robust Ecosystem=Embedded Success, EE Times, December 2, 2010.
[2] From Microcontrollers to Ecosystems, EE Times, December 2, 2010.
[3] Towards Embedded Computer Vision邁向嵌入式電腦視覺，王元凱，blog.ykwang.tw，2010年10月3日。
[4] 嵌入式視覺系列, Part I-嵌入式系統上DSP的發展方向:ISP，王元凱，blog.ykwang.tw，2010年10月9日。
[5] 熱顯像攝影機(Thermal Camera)於FJUCam2/VCam之應用與考慮，王元凱，blog.ykwang.tw，2010年9月5日。
[6] FJUCam2/VCam可以使用的Camera Module，王元凱，blog.ykwang.tw，2010年11月14日。
[7] Android beyond the phone─兼論FJUCam2的下一步Android發展方向，王元凱，blog.ykwang.tw，2010年8月26日。
[8] Meego，王元凱，blog.ykwang.tw，2010年10月5日。

FJUCam2/VCam可以使用的Camera Module

我們ISLab實驗室目前正發展FJUCam2/VCam板子，以自行發展Smart Camera，並進行Video Surveillance, Robotic Vision, Augmented Reality、Portable Medical System等Embedded Vision的應用。

我們的FJUCam2/VCam是一個高性能的嵌入式系統，仍需要再搭配Camera Module以成為完整的Camera System。本文旨在說明FJUCam2/VCam可與各種不同Camera Module的結合方式。

我們發展的FJUCam2/VCam,，已經有雛形出來，如下所示：

FJUCam2/VCam正面

FJUCam2/VCam背面

可以看到此板子雖然稱之為Camera，但是其實沒有包含光學鏡頭與感測器。因此還需要加上這兩個組件。

至於Camera Module，包含也就是光學鏡頭(Lens)與影像感測器(CMOS/CCD Sensor）與ISP(Image and Signal Processing)[2]都需要另外連接。

將FJUCam2/VCam與Camera Module組合好的硬體，我們稱之為Camera System；若再加上軟體（作業系統、驅動程式、電腦視覺演算法），則我們稱之為Smart Camera。

FJUCam2/VCam與Camera Module連接的方式有三種：USB、Composite Video、Camera Bus。以下分別說明之。

一、USB
       以USB來將Camera Module擷取的影像傳送到FJUCam2/VCam，是比較單純的作法，此作法需要搭配OS安裝該USB Camera的驅動程式方能擷取影像，方便之處在於FJUCam2/Vcam的OpenCV可以直接從該驅動程式抓取影像成為IPLImage影像結構的記憶體。
        目前FJUCam2/VCam的主板已經有2個USB介面，可供連接USB Camera Moduel。

        此種作法又有2種差別：

   1. 一體成形的Camera Module
         也就是一般PC上常用的USBCam/WebCam。此種Camera的鏡頭與、攝影機、ISP都已經是一套成形的產品。如羅技(Logitec)、Minoru等Camera都屬於此類，並且已經可以與FJUCam2/VCam整合。
          此種方法的優點是可以快速整合FJUCam2/VCam硬體成為一台完整的Camera，缺點是影像品質較低、解析度較差、只能定焦、可變化性少。

   2. 分離式Camera Module(分別組裝Lens與Image Sensor)
          自己找Lens與Image Sensor來組合成為Camera Module。例如我們ISLab實驗室已經有PointGray等Image Sensor多台，並有Tamron的二十餘顆監控用定焦光學鏡頭，有各種不同的焦距。因此可以自行組合出各種不同的Camera Module。
          Lens與Image Sensor連接的方式，有C Mount與CS Mount兩種。
          分離式方法的好處，在於可以自行組合各種變化的Camera System，如近紅外線攝影機、變焦攝影機、高畫素攝影機等。

二、Composite Video
        此種方式是善用現在市場上大多數Camera Module都已經採用Composite video輸出，因此可大幅擴充FJUCam2/VCam的Camera能力。例如熱顯像攝影機[3]的輸出介面都是Composite Video。
        目前FJUCam2/VCam的主板並未提供Composite Video In的介面，需在第二層擴充版提供。FJUCam2/VCam的硬體架構將在論文發表後，再來撰文說明。
        此種作法的立即好處，是可以讓FJUCam2/VCam直接成為特殊規格Smart Camera，如Thermal Smart Camera。

三、Camera Bus
        此種方式透過OMAP3530的Camera Interface直接將Camera Module的影像以數位匯流排直接傳送給OMAP3530，通常也是使用一體成形的Camera Module，如Miniture camera module[1]。但由於傳輸協定較為複雜，目前FJUCam2/VCam並不採用此種方法。


本文先將FJUCam2/VCam的模組連接方式簡要說明如上。後續會另外撰文說明Smart Camera的觀念，並闡述FJUCam2/VCam與Smart Camera的關連。

[1] Color Camera Cubes, A. Wilson, OptoIQ, 2010/11/1.
[2] 嵌入式視覺系列, Part I-嵌入式系統上DSP的發展方向:ISP，王元凱，2010/10/09.
[3] 熱顯像攝影機(Thermal Camera)於FJUCam2/VCam之應用與考慮，王元凱，2010/9/5.

嵌入式視覺系列, Part I-嵌入式系統上DSP的發展方向:ISP

我預計以一系列文章來說明Embedded Vision嵌入式視覺的概念，也就是在嵌入式系統上面發展電腦視覺(Computer Vision)與影像辨識(Image Recognition)的方法。

本文為該系列文章的第一篇，先從DSP開始，說明ISP此名詞的意義，我並且將自行定義Special-Purpose ISP與General-Purpose ISP，最後並將說明General-Purpose ISP常見的三種開發方式。

從DSP到ISP

DSP(Digital Signal Processing)嵌入式系統是一個大題目，難以講清楚，因此我將縮小其意義與範圍來論述之。本文中我將說明嵌入式系統上的DSP概念，近年來已經逐漸朝向ISP(Image and Signal Processing)發展。

1D/2D/3D訊號處理

DSP的歷史太久了，其意義又太廣泛。單純的DSP是泛指各種訊號處而的方法、演算法、軟體與硬體。DSP的名詞與觀念，應該從有數位系統以來，就開始有數位訊號處理的領域出現了，最早是先從語音訊號的處理開始，後來廣泛應用於通訊、影像處理、生醫訊號處理，現在則有更廣泛的應用與意義，如地震等訊號的數位處理。

訊號可分為1D與2D、與3D幾種。1D訊號可以語音、通訊、生醫、地震為例。2D則為影像(Image)，從可見光影像、高頻電磁波影像（X光等）、低頻電磁波影像（紅外線、超音波）等都可稱之，其訊號處理運算量大，但應用範圍比1D來的更廣泛。3D則可以視訊(Video)做為代表，也就是連續的影像，因此又時又稱為Image Sequence，其運算量比單張影像更巨量，理論難度也更高。

嵌入式系統原來的運算資源非常侷限，CPU較慢、記憶體少量、周邊少，因此傳統的嵌入式系統都是以1D訊號為主，在電子電機則應用在控制與通訊的訊號處理。

ISP: Image and Signal Processing

由於現在的訊號處理幾乎都是在數位系統上進行，因此DSP的Digital一詞已經沒有意義。此外，DSP在傳統上幾乎是泛指各種1D訊號的處理。因此近年來出現一個新名詞：ISP，以與DSP做區分。

ISP的發展，有其歷史軌跡。近10年來，由於VLSI與SOC的進步，數位系統的晶片有大幅進步卻同時縮小化的進展，使得現在的嵌入式系統可以在低價位的情形下，提供高速CPU、大量記憶體、更多的周邊控制，甚至可以有多核心的Processor。在此進步下，嵌入式系統已經開始朝多媒體邁進，增加影像與視訊等2D/3D訊號的運算，以擴大應用範圍。手機從Feature Phone進展到Smart Phone就是一個明顯的例子：體積約略不變，但現在已經可以提供500萬以上畫素的相機，並進行壓縮、處理與視訊傳輸。

因此Smart Phone的CPU，就可稱為ISP的晶片，因為其DSP的運算速度已經可以到2D的處理能力，當然也可以進行1D訊號處理，因此稱之為Image and Signal Processing的晶片並不為過。

另外，近年來有許多的IC Design House也自行設計ISP專用的晶片，亦稱為ISP但全名為Image and Signal Processor。此類ISP，多用來指擴加的影像處理功能的CMOS晶片。

ISP的兩種型態:Special Purpose v.s. General Purpose

ISP的名稱還沒有被廣泛使用，因此這個專有名詞尚未得到廣泛的使用。此外，目前也尚未有人將ISP進行分類。

此處我根據個人經驗，我自己將ISP區分為兩種型態：General-Purpose ISP與Special-Purpose ISP。

Special-Purpose ISP是指晶片上已有固定影像處理功能的晶片，由於功能固定，因此多使用在已經成熟的大量市場，如手機Camera、數位相機、USB Camera、Notebook/Netbook Camera等。這些攝影機的功能大約都相似，如2A(AE/AWB，自動曝光/自動白平衡)等，以提供使用者簡易使用的功能，並且不需要再使用軟體來調整影像品質，例如Omnivision的CMOS晶片(如OV9655)即是如此。此外，有些甚至開始加入3A（2A加上AF自動對焦）等原本數位向機才有的Image Processing Pipeline[1-3]，甚至加入WDR/HDR(High Dynamic Range/Wide Dynamic Range)、人臉偵測等。另外學界也有許多論文在探討各種ISP硬體的實做方式[4-5]。

但是Special-Purpose ISP不能再自行改進ISP演算法，其為ASIC，ISP的功能都是固定的，因此不適合學界進行論文研究，僅適用於已經成熟大量但需要低價的產品來使用。

若學界要在嵌入式平台上進行ISP的演算法研究，則需要General-Purpose ISP。例如採用High-end ARM、Extreme DSP或FPGA的平台來作為ISP演算法的研究。

General-Purpose ISP的三種開發方法

High-end ARM是指高階適合用於多媒體的ARM晶片，以ARMv7的最新架構為例，其具有兩個協同運算器(Co-processor)以加速訊號處理：1. NEON media coprocessor，可有多路SIMD加速平行運算，以及2. VFP浮點運算器，因此適合於ISP演算法的發展。以ARMv7-A 架構為例，目前有Cortex-A系列的A8與四核心的A9、A15。Apple iPad, iPhone 4, iPhone 3GS, Motorola的Droid X, Nokia N900等都是使用Cortex A8。這些Smart Phone/Portable Device具有足夠的CPU處理速度(600MHz~1GHz)，以執行ISP的運算。但這些現成的可攜式裝置內已經安裝有許多軟體佔用掉CPU資源，因此實際可用的CPU處理速度應不到400MHz。若要使用全部的ARM Cortex A8運算量，可使用開發平台，如TI OMAP 3xxx, Beagleboard, Gumstix等。

Extreme DSP此名詞意指高階DSP並且有特別的Video IO周邊介面設計之晶片與平台，例如TI DaVinci或OMAP。這些DSP除了時脈至少為400MHz以上外，其晶片已經內含Composite Video IO、USB控制器，可接S-video、DVI/HDMI數位影像輸出裝置，並且可以外接高容量儲存裝置如硬碟、SD等。這些Extreme DSP已經有許多的開發平台。

FPGA則這幾年開始朝向多媒體發展，因此逐漸有許多FPGA開發平台外加Video IO，並提供影像與視訊處理的IP Core。以Altera為例，其DE2系列之開發平台就已經包含非常豐富之視訊輸出入介面與儲存裝置介面，並提供VIP(Video and Image Processing) Megafunction，可進行色彩模型轉換、濾波器等基本影像處理功能，最近也有一個IP Camera的reference design。Xilinx也有Video Starter Kit(Vertex-4或Spartan 3A)，其功能與DE2類似。另外Xilinx也提供更多的視訊與影像處理IP，甚至有Video Analytics的IP。

CPU、DSP與FPGA三個ISP的嵌入式發展方向，其難易度並不相同[6]。Embedded CPU開發方式與PC相似，也可以用C語言，因此最簡單。DSP開發方式可用C語言，但需瞭解DSP訊號平行運算的程式指令，方能得到高速處理效果，因此需瞭解DSP硬體觀念才能寫出好的ISP程式，難度次之。FPGA則需要以Verilog或VHDL來開發，C語言(System C或SA-C等）的開發方式仍有其困境，目前成熟度尚待改進；因此FPGA的開發需要很清楚的硬體架構設計觀念，難度最高。

我現在三個方向都有在嘗試[6]，並期待逐漸建立一些研究成果。目前嵌入式視覺的研究概況，則可以參考[7]。

下篇文章將延伸說明ISP的觀念，繼續說明在嵌入式系統上進行影像辨識開發的觀念：Embedded Vision。

[1] Color Image Processing Pipeline, by Ramanath, R.; Snyder, W.E.; Yoo, Y.; Drew, M.S.; IEEE Signal Processing Magazine, vol. 22, no. 1, pp. 34-43.
[2] An Introduction to the Digital Still Camera Technology, A tutorial by M. Mancuso and S. Battiato.
[3] Design Considerations for Color Image Processing Pipeline for Digital Cameras, by Wen-Chung Kao; Sheng-Hong Wang; Lien-Yang Chen; Sheng-Yuan Lin; IEEE Transactions on Consumer Electronics, vol. 52, no. 4, pp. 1144-1152.
[4] Coarse-grain reconfigurable image signal processor for digital still camera, Chen, J.C.; Chun-Fu Shen; Shao-Yi Chien, IEEE Int. Symp. Circuits and Systems, 2006. Online [Available]: http://ntur.lib.ntu.edu.tw/bitstream/246246/200704191001112/1/01693599.pdf
[5] Search IEEE Explorer, http://ieeexplore.ieee.org/search/searchresult.jsp?newsearch=true&queryText=.QT.image+signal+processor.QT.&x=0&y=0
[6] 邁向嵌入式電腦視覺，王元凱，2010年10月3日。
[7] Embedded Computer Vision研究現況，王元凱，2010年10月3日。

MeeGo

2010年出來一個新的可攜式裝置作業系統：MeeGo。它是Open Source，看來也可以作為嵌入式系統課程的學習對象，也許可以作為輔仁大學智慧型系統實驗室FJUCam2/VCam的Embedded OS平台。

本篇文章將來探討MeeGo的特點與性質，藉以分析其為何MeeGo可能可以作為本實驗室的Embedded OS平台。

MeeGo is YAOS(Yet Another OS)？

但初看到MeeGo的新聞，一般人會認為：MeeGo不過是YAOS，另外一個 Embedded Linux而已。因為在手機與平版電腦市場，隨著Google Android，Apple iOS，以及Nokia的Symbian的盛行，一般人已經很難再想去用其他的Embedded OS了。

但其實不然。

原因是此作業系統是由Intel 與Nokia兩大公司合作。以該兩家公司聯手的實力，有機會與Google、Apple的作業系統來一較高下，因此MeeGo在目前的情況下還是有機會勝出。

此外，MeeGo也非全新的作業系統，而是由兩家公司已經穩定的一些前身組合而來的。換句話說，MeeGo ＝ Intel Moblin ＋ Nokia Qt。因此，MeeGo要迎頭趕上Google與iOS的佔有率，也是有機會。

以下分別從Intel與Nokia兩個方面來說明。

Intel Moblin

話說Intel其實早在多年前，就開始有打算脫離WINTEL的架構，也就是WIndows + INTEL CPU的PC電腦產業架構。尤其是在手機、Netbook部分這類的可攜式裝置，微軟的WinCE、Windows Phone市場佔有率都表現的不理想，因此Intel在可攜式裝置上，早有Computing continuum strategy，也就是學界稱謂的Ubiquitous computing。在此方向上，Intel早有意採用Linux。

因此，Intel其實一直都有支援Open Source Foundry，所以也有多年的Linux Open Source基礎，並在2007年推出x86架構的Embedded Linux，應用於Intel Atom，也就是Intel要放在所有可攜式裝置上的省電型CPU。該Embedded Linux是從Ubuntug改良而來，稱之為Moblin作業系統，並實質使用於2007年在Atom的產品，如ASUS EeePC。

因此MeeGo其實可以視為Moblin的下一代，其目標將用在Intel的可攜式CPU上面，尤其是Atom，因此Intel對MeeGo的期待，是要廣泛使用在Tablet、Smart Phone、Netbook、以及TV。

關於Nokia與Qt

至於Nokia，其主要的手機仍採用Symbian，因此其策略主要是將Qt與Moblin結合成為MeeGo，也就是將Qt當作MeeGo的GUI與UX(User Experience)核心。Nokia在前幾年併購Trolltech後，將Qt大幅整理，使Qt也成為Open Source的一員，但另外也有商業版作為Nokia的產品。

Qt的歷史淵源跟Apple的iOS也有關，iOS的GUI介面程式庫，其實也是從Qt改良而來。

換句話說，Qt其實是Linux與Embedded Linux上眾多GUI Library中，效能與功能最出色的一套SDK。以往Qt不被Open Source User支持的原因，只是因為Qt不是Open Source，因此受到部分Linux & Open source社群的抵制，使得Linux/Embedded Linux上的GUI到去年都呈現多家耕耘的混亂局面。

但是自從Nokia將Trolltech買下來並在去年公布Qt的Open Source版本後，Qt已經呈現主流的態勢。根據個人的猜測，在Qt將會逐漸成為Linux Open Source上主流的GUI與UX，取代GTK等Linux GUI Library。並且Nokia也會在Qt上面增加小尺寸螢幕的UX，使的Qt適合從大尺寸螢幕的PC到小尺寸螢幕的智慧型手機。

也因此，我們實驗室在2009年時，即做了一個重要決定，在GUI介面上為求跨Windows、Linux與iOS平台，我們將使用Qt。

MeeGo的架構

以下是其兩個重要的架構圖。詳情請參考IEEE 2010的論文[1]。

MeeGo的架構圖

Qt的架構圖

採用MeeGo的好處

依據我的觀察與思考，對於本實驗室而言，使用MeeGo比起使用Android與iOS，有以下3個好處。

1. 可以跨CPU平台
     雖然目前在手機上的CPU以ARM為主流，但是Intel的ATOM其實也有機會在可攜式裝置上佔有一席之地。因此若使用MeeGo，其好處在於將來本實驗室的演算法與EDK，可輕易同時在兩種CPU架構中使用。

     MeeGo在ARM的支援，要從Nokia來看。目前Nokia多款Smart Phone都是採用TI OMAP，例如N900就是使用OMAP3430。因此可以想見，將來MeeGo在Nokia的支援下，在OMAP晶片的支援會非常快速而完整。

     由於我們的FJUCam2/VCam是採用OMAP系列或由其延伸的DaVinci晶片，因此在硬體平台相容度下有良好的利基。

2. 可以跨多種尺寸的可攜式裝置
     目前Android 2.2版以下主要的問題，在於無法用在超過5吋螢幕的可攜式裝置。因為Google對於Android的方向設定，一直是以Smart Phone為目標。只因Apple iPad出現打亂了Google Android的佈局方向。

     雖然Android 3.0版預計要解決此問題，但僅能等到2010年底/2011年才能看到確實的作法，目前還不清楚其詳細作法。詳情可以參考另外一篇文章。

     另外，目前Google還有Chrome的作業系統，並以5～12吋螢幕的可攜式裝置為主。將來Google要如何結合Android與Chrome，成為一套作業系統，其策略我還不是很清楚。在Android前途渾沌不明下，即便業界都很難決定要如何再繼續使用Android做為平台。

3. 介面移植容易
    另外在演算法層面的移植性來看，我們在MeeGo採用Qt GUI介面，有利於在PC Windows與PC Linux上移植影像辨識演算法。

     因為我們發展影像辨識方法的過程，是先在PC Windows上進行演算法的研究，經過研究與詳盡的實驗確認方法的有效性後，才開始將其程式碼做速度的最佳化，並移植到PC Linux與Embedded Linux。

     在這樣的過程中，我們都需要視窗介面。若能在一開始PC Windows環境時就使用Qt，則移植到PC Linux與Embedded Linux的困難度與陣痛期可以大幅降低。

      至於Android，則被限制要以Java來開發介面，因此必需採用JNI(Java Native Interface)架構來連結Java與C語言，對於以C語言當作Native Language的影像演算法開發者而言，實在是多了一層門檻與痛苦。也降低開發與移植的速度。


然而問題在於

我們還不清楚MeeGo的詳細特點與缺點。這要實際經過使用、移植與測試後，我們才能確定。另外也還要觀察Android與iOS的進展。至少還要再觀察半年後三個作業系統的消長，再來斷定。

目前我們實驗室在PC Linux，已經有Fedora、CentOS與Ububtu的能力與經驗。在Embedded Linux，則有Angstrom、Android的經驗。目前將試著移植MeeGo，並瞭解其優缺點。

半年後再來評估優劣得失。

[1] Introduction to MeeGo, by S. Schroeder, IEEE Pervasive Computing, vol. 9, no.4, 2010.

Towards Embedded Computer Vision邁向嵌入式電腦視覺

近年來由北到南有許多的演講邀約，自97年開始我大部分都將講題鎖定為：Towards Embedded Computer Vision[1]。演講內容除了介紹電腦視覺如何透過3大類嵌入式系統來實現外，並說明輔仁大學的智慧型系統實驗室(www.islab.tw)這幾年來在嵌入式電腦視覺的研究成果。

此演講的主要概念之一，就是在闡述要再嵌入式系統上實現電腦視覺，是一件艱困的研究挑戰。不僅要非常熟悉電腦視覺的演算法，得在演算法上進行創新改進外，還得瞭解硬體的特性，進行符合硬體特性的平行化架構設計。

我們實驗室這幾年雖然開始嘗試，但進度還不算多。但我環視國內各個學校的研究群，似乎還很少將Embedded Computer Vision(ECV)列入其研究主軸，因此想大膽的開始嘗試將ECV列入本實驗室的主要研究方向之一，並繼續朝此方向邁進。

目前我們在Multicore CPU、DSP(Heterogeneous)、FPGA都有研究群分別在進行。Multicore CPU以ARM為主，DSP則以TI為主，FPGA則選擇Altera平台。

ECV的應用，則以Visual Surveillance/Video analytics, Human Computer Interface, Biometrics(Face),  Robotic Vision, Home healthcare, Sensor/Camera Network等應用為主。另外，也在開始思考應用在Computational Camera。

此外，今年開始也將探討Embedded Vision在嵌入式系統上，如何跟Cloud Computing搭配，成為Cloud Computing的Thin Client，成為完整的前後端(Front End+Back End)電腦視覺架構。

在硬體平台部份，由於找尋許久後都沒有見到合適的既有產品，因此我們實驗室也嘗試自行開發硬體平台。目前我們已經有兩套平台：FJUCam1 與FJUCam2. 這些名稱是實驗室專案代號(Code Name)，而FJUCam2對外可能將定名為VCam，意義為Vision Camera。

有一些觀念可從我的演講投影片得到端倪。此處將我的演講投影片附上[1]，歡迎有興趣者一起研究討論。另外也有一篇部落格文章[2]說明目前的研究現況。

[1] Yuan-Kai Wang, Towards Embedded Computer Vision, Fu Jen University, 2009.
[2] Yuan-Kai Wang, Embedded Computer Vision研究現況，2010年10月3日。

Android beyond the phone─兼論FJUCam2的下一步Android發展方向

自2008年Google推出Android 1.0版以來，其目標就是作為Mobile Phone的作業系統。經過2年後釋出的Android 2.2版(Froyo)，2010年在美國（目前為全世界Smart Phone最大銷售量的國家）更已經成為Smart Phone第二大的OS平台(Canalys)，以38％的佔有率超過iPhone的21%；其應用程式也快速成長中(Androlib)。預計在2010年10月會有Android 3.0(Gingerbread)，其最重要的改變就是支援大螢幕的Mobile Device。

本文希望說明Android的觀念，並思考與我們FJUCam2的關連，最後則建議FJUCam2的Android平台可採用Open source project: Rowboat 。

我們的FJUCam2以OMAP3x為基礎，也可以移植Android。目前暫時先以Beagle board Rec C當作實驗板並已經輕易移植成功Android 1.6版。看來要移植Android 2.2版應該也不是難事。我們應該可以在FJUCam2的硬體完成後，開始著手移植新版的Android。

雖然我們自2009年底到2010年中發展X-Eye的過程中，暫時以Ubuntu與Angstrom的Linux為主，但仍不排除會採用Android，因為Android在與Google Cloud Computing的連結性方面，仍比其他Embedded Linux來的優越，因此要朝向Cloud Computing發展的過程中，採用Android是必要的方向。

但即便是Android 2.2仍還有很多改善的空間。近來一個重要的方向是開始朝向Beyond Smart Phone，例如：小筆電、Set-top Box, VoIP Phone, Google TV, Tablet（平板電腦）等。這些Beyond phone devices與phone devices的差別，就在於螢幕尺寸的大小。以Smart phone為例，目前約為4吋到6吋螢幕。但是小筆電與Tablet則為8吋到10吋螢幕，而Google TV則更可能到42吋螢幕。

由於螢幕變大，因此解析度需求也變高。一般Smart Phone解析度為320x240,最高可達800x480。但是在小筆電與Tablet而言，一般至少都是1024*768,而HD TV則可以到

但是，直到2010年5月發佈的Android 2.2(Froyo)(Android in Wiki)，仍然只能支援最大800x480的解析度（Google作梗 Android平板電腦難產，工商時報，2010/8/22）。而Android Market的應用程式，許多則只有支援到320x240。不論是320x240或800x480，在10吋以上的螢幕看起來都有低品質的嚴重問題，因此限制了Android的在大螢幕行動裝置上的使用。

有一個參考連結:Android beyond the phone - A Progress Report by Mentor Graphics，即是在說明從Mobile Phone作業系統成為更大螢幕的行動裝置作業系統，需要修改Android的Linux Kernel, Dalvik VM，嵌入式版子的驅動程式/BSP(Board Support Package)、UI/Java Library等。

只是這是Mentor Graphics公司自行修改的Android，可能需要付費才能使用。但是Mentor Graphics在Google code提供一個Open Source Project: Rowboat，以TI OMAP 35x, AM37x等為主，提供其修改後的Android以在大螢幕裝置上高解析度的效果。

截至2010/8/26為止，Rowboat仍為1.0版，該版本是以Android 2.1(Eclair)與Linux Kernel 2.6.29為基礎，採用Apache License。除了為大螢幕裝置提供UI、Graphics與Multimedia的最佳化之外，也提供Dual-core的ARM與DSP之間的傳輸與運算機制:DSP Stack Integration與OMX DSP system。此外，Rowboat更將Android的開發環境由Java為主修改為以C/C++為主，因此可以C/C++來開發OMAP 35x上面的Android C應用程式，此點對於影像辨識與電腦視覺而言，是非常重要的特點。

由於FJUCam的開發理念，是希望發展一套可自由研究Embedded Vision的嵌入式平台，該平台以ARM+DSP的Dual-core為硬體，以Linux/OpenCV為軟體，提供EVK作為Embedded Vision的軟體堆疊(Software Stack)程式庫(Library)，並且以C/C+為主要的程式語言，因此Rowboat與FJUCam2的理念不謀而合。此外，電腦視覺的運算結果，常需要以大螢幕來顯示，因此Rowboat的開發方向，更符合FJUCam的想法。雖然有傳聞Google官方將於2010/10釋出的Android 3.0(Gingerbread)也會支援大螢幕裝置，但是對於Dual-core以及C/C++開發環境的支援性，仍遠遠不及Rowboat。

因此，我認為FJUCam2的下一步開發方向，是開始嘗試使用Rowboat。第一部是先將其安裝在Beagle board上面，並移植X-Eye與我們的Embedded/DSP程式到Rowboat上。若成功，則可以開始將整套軟體架構移植到我們的FJUCam上面。