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.

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日。

熱顯像攝影機(Thermal Camera)於FJUCam2/VCam之應用與考慮

熱顯像攝影機是遠紅外線(Far Infrared Camera, FIRCam)的一種，與近紅外線(Near Infrared Camera, NIRCam)不同的地方，在於紅外線的波長較長因此又稱之為LWIR(Long Wavelength IR)，其優點是不需要主動式的投射紅外光即可取得影像，因此在完全無光源的環境依然可以取得影像，因為如人體之類的發熱物體會發出LWIR的微弱能量，透過FIRCam的特殊感測器吸收後轉換為影像。

熱顯像攝影機在軍事、醫學上都有大量的應用，近來也逐漸應用於視訊監控上。其優點除了在無光源環境可以取得影像外，對於起霧等環境也有優良的取像能力。但由於其價格昂貴，普及性仍不高。此外，以Thermal Image來進行Video Analytics分析時，由於其雜訊較高，雜訊性質與一般可見光影像不同，而且影像解析度低，因此在分析上迥異於一般方法。

目前本實驗室ISLab還沒有熱顯像攝影機，但已經在進行評估，目前以美國的FLIR與日本的NEC-AVIO兩者為主要的評估對象。兩家公司都是以測溫為應用，已發展出非常多的產品，近年來也開始有視訊監控用的攝影機。另外在2010年1月IP Camera大廠AXIS也開始推出低價位的熱顯像監控攝影機，型號為Q-1910（室內型）與Q-1910-E（室外型）價位在美金3000～3500之間。

ISLab發展熱顯像技術分為兩個方面：一個是進行影像分析以進行學術研究；另外一個方向則是要使FJUCam2/VCam結合熱顯像感測器，以自行研發熱顯像攝影機進行有興趣的研究用途。因此AXIS的熱顯像攝影機雖然價格較為低廉，但是並不適用於FJUCam2/VCam。其原因在於Q1910的體積太大，而FJUCam2/VCam是以體積非常迷你的觀念來設計，若搭配體積龐大的Q1910感測器，則會喪失其原本設計的意義。

因此，目前唯有FLIR與NEC-AVIO兩家有出小體積與模組化的熱顯像模組，比較適合本實驗室的研究目標。

FLIR的熱顯像模組有兩個型號：Photon與Tau。Photon體積較Tau大，但兩者都適合於FJUCam2/VCam.

NEC-AVIO則有幾款Camera Module，其體積也適合於FJUCam2/VCam。

但FLIR與NEC-AVIO的攝影機，其可測溫之型號約都需要超過1百萬台幣。僅監控影像的熱顯像攝影機型號，價位較低，約在台幣四、五十萬元的範圍，但仍遠遠比AXIS的Q-1910熱顯像監控攝影機來的價位高昂。

最後，關於AXIS推出的低價位熱顯像監控攝影機，IPVideoMarket.info有介紹以及與FLIR的比較[1,2]。

FLIR有一個製作品質良好的視訊影片，從物理發展歷史來介紹熱顯像的物理原理非常值得一看[3]，是英文解說；網路上可以直接申請免費DVD，寄來的DVD會將視訊影片翻譯成中文。另外，OptoIQ有一個WebCast對於熱顯像的取像原理有詳細的說明[4]，其投影片可以下載。

Youtube中則有許多對FLIR熱顯像攝影機的介紹與說明，如[5]。也有AXIS對於其熱顯像攝影機的產品介紹[6]。

[1] FLIR Thermal Network Cameras Examined, IPVideoMarket, Feb 02, 2010.
[2] Testing and Analysis, IPVideoMarket, Feb 13, 2010.
[3] 瞭解熱成像，FLIR。
[4] Fundamentals of Machine Vision: Infraref Imaging, J. Kane, Apr 20, 2010.
[5] FLIR Thermal Infrared: the camera itself and more demos, Oct. 04, 2006.
[6] AXIS Q1910Therml Network Camera, Feb. 8, 2010.

射頻Combo受歡迎 藍牙+藍牙低功耗被看好 - CTimes

市場趨勢：結合藍牙（Bluetooth）、Wi-Fi、FM以及GPS等主要射頻功能於單晶片封裝的Combo晶片組
http://www.ctimes.com.tw/News/ShowNews.asp?O=201008251817137766



思考：FJUCam2上的無線模組部分，若採用Combo模組的無線晶片，體積可以更輕薄短小！

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上面。