手遊轉PC趨勢分析

最近微軟大放送無線搖桿，這不算什麼，也許在清庫存。

然後Bee還在玩為數不多的手遊都開始出PC版本，基本上都支援無線搖桿。

這就怪了! 怪事不會連著來，一定有事。

資訊不足，改用反推法。

若手遊要移植到PC，應做那些事?

1. 使用的電腦語言可以換去PC重編，沒人會想重寫，又會有維護問題，沒有相同的程式碼一定不可能。
2. 驅動程式要相容，這個不保證，但工一定比第一項來得小
3. 引擎要相容，主要是3D引擎或是物理引擎。若有同套問題就小。

個人認為2,3項看運氣，但game數量如此多，一定有符合的。

再來就是第1項了。PC軟體主導是微軟，若是微軟的compiler打通這條路，後面會自然生成。

微軟如何造這場局往微軟想要的地方發展?

搖桿是XBOX的! 也就是局勢要往XBox走微軟才有商機。XBox也是一種PC。

這樣路就明顯了，若是手遊轉PC很簡單，同時轉成XBox也會很方便。

重點是PC的操作和XBox有點不同，這個坎要弄平，怎做?

就大量撒搖桿給PC。這下就串起來了。

嗯，這局有很多行銷行為，值得再研究。

手機上C compiler應用心得

算是記錄，因為還沒有找到理想的。

個人目標是做MCU上的程式試跑及除錯用。

(老婆逛街時放置狀態)

Mobile C

簡中介面，範例多。也可以連上手機部分裝置。

但只能單檔，在移轉應用上不方便。

移轉來的程式要另外作業，不容易作這樣的準備。

Cxxdroid

可以使用CMake，但試跑我的直譯器時，出現segment fault，不知道是那裏有問題。VS2019下沒有什麼問題。同程式在Mobile C下沒有問題。

CPP N-IDE

也可以用，相容性不錯。但缺少可以用的make，所以目前也是只能單檔。

工件語言及工作語言的功能及插件功能設計

DXP或是SVG都是工件語言，它只描述工件的樣子，但沒有說是如何做加工。

機器手動作語言是有加工程序，但它有它自己的語言及函式，和工件語言並不相同。

且各家機器人使用的工作語言也都不相同。

所以MCU製作的機器人就有二套語言，一個是工件語言解析器，另一個是它自己動作用的工作語言解析器。

工件語言解析器分解後變成工作語言格式，這是一般工作。

但現在軟體都流行插件，也就是使用者可以加工作程序。很多軟體會後加工DXP檔，就是要加入一些機器才有的工作行為。

若是沒有將工作語言獨立出來，插件功能就無法成形。

所謂的插件，就是工作語言函式，它由使用者從機器操作界面輸入，然後在指定的工件語言指令中插入。

對於使用者來說是工件語言指令插入，實則是分解成工作語言後才插入，只是使用者看不到工作語言層的狀況下會以為是工件指令插入。

本來是想以巨集方式解決，就是使用文章插入的方式做。

但後來想到有可能要解析工件語言參數的狀況，改成用函式插入，這樣就可以在執行時取得參數做判定。

有了工件語言，也有機會做使用者新加指令的可能。

在解析工件語言，若遇到無法解析指令，就轉跳去工作語言的使用者新增指令掛勾，就有機會利用工作語言去做新指令解析並插入對應函式。

在實際上這個插件功能可以做什麼? 主要用在加工中插入檢查功能。

機器手上除了加工手指外，還有camera手指，工件語言不會使用機器檢查機制，就要用插件來做。

變成加工到一半，可以叫camera進來看，簡言之就是拍照存證。

這樣的機器可以由使用者加檢查點，或是改變部分加工行為。

照顧用機器人工作及需求分析

機器人取代人的工作，個人是認為取代照顧工作最多。

此類工作需求量大，照顧對象固定，可以寫成標準照顧程序。

問題出在辨識能力，先不管需求多少計算力，依辨識反應時間可以應用的需求就不同。

一般檢知仍以camera識別為主，其他環境檢知為輔。

辨識反應時間定義為：輸入新的影像資料，辨別出目標物的狀況，並找到對應的處理行為。

依據反應時間不同，應用的目標就不同。

反應時間級的定義：1分鐘級，表示可以在1分鐘到10分鐘內完成。

若是反應等級為10分鐘級的，可以做為植物照顧用，應用於自動化農場。

若是反應等級為1分鐘級的，可以照顧魚類，應用於自動化水產養殖。

若是反應等級為1秒級的，可以照顧動物，應用於自動化畜牧。

反應到0.1秒級的，可以照顧人。

反應到0.01秒的，可以開車。

所以MCU做機器人再和AI聯合，後面還是有很多事可以做。

Sine等面積計算

A=0~90

B=2/90*A

C=arccos(1-B)

D=sin(C)

C,D畫圖

A為角度

B調整分割數目

機器人座標轉換規劃

主要是幾個工作座標轉換之間的關係。

目前機器人都是吃工件檔案，機器手再輸出。中間其實沒有如此簡單。

因為機器人都是由馬達控制，所以馬達要做加減速控制。

馬達吃的指令其實是移動量/單位時間。

將馬達吃的指令也當成是指令，MCU的角色就是直譯器。

主要是將工件指令一路分解到馬達指令。

工件指令可能是DXF檔一類的，實驗或是模擬也可以用SVG來做。

目前有數個轉換在中間。

1.工件指令轉成工件座標：主要是轉成簡單向量，因為向量圖檔有一大堆高階指令，主要是分解成單一向量座標。

2.媒體座標分割：有時輸出座標過大，可能要做分次輸出，或是和檢知器對位做座標修正。

3. 分割/分檔管理：可以做輸出管理，或是重覆次數管理

4.裝置映射：機器人指尖轉換，因為機器人指尖是可以變換的。加工用的和檢查用的不會在同一個座標上。這個就要套上不同的裝置映射。例如鑽頭和camera可以在同手臂上，但看的位置不同，加工中檢查，可以快速轉換。

5.工區座標轉換：因為加工手指可能可以控制，也有被動控制，在這一階完成轉換。平移式手臂比較好轉換，轉軸式手臂就要解反向機器人運動學矩陣。另外機構座標檢查及保護也在這一層。

6.馬達路徑規劃：向量轉成馬達指令，馬達加減速路徑解析，才可以產出移動量/單位時間的指令列表。

平行編譯實驗

舊式MCU Compiler只能發動單核心執行。想利用多核心平行編譯。

找到可以利用 start指令將make分去新的cmd上去執行。這個可以成功。但合併成一個的make分不了。

另外也無法測平行化的cmd是否全部結束。

後來將編譯最久的make改成使用start /wait指令，就可以順利的接回來編譯並包成hex檔案。