研究週記_20190317
上週預計待辦事項：
- 模擬中，從幾何座標S到時間座標T僅以是直接轉換，並未經過時間規劃(time law)，因此會發生中間速度減慢的現象，預期修正目標是在軌跡上能夠等速前進
- 加入物理尺度與輸入飽和限制，並比較3種控制法則的響應
- 將整個控制移植至Linux系統，以C++或Python包裝成ROS package並搭配turtlesim去模擬(輸入為三個座標點，輸出為根據規畫時間丟出速度與角速度命令)
本週進度概要：
- 修正無法等速前進的問題，並加入飽和限制
- 路徑規劃的部份已移植到python上，但仍未加入模擬實測
本週進度呈現：
經過修正後，用Matlab重新模擬的結果如上，可以發現速度明顯均勻許多，沒有明顯的忽快忽慢，算是達成了上週預計的待辦事項1，記錄一下所做的處理：
首先，問題並不是出現在沒有進行時間規劃，因為經過老師提醒，其實直接將幾何座標S換成時間座標T，其實應該是等速率前進，而出現上週那樣忽快忽慢的原因，其實主要在於我的路徑規劃和時間分配有問題。
假設我希望車子的整個速度維持在一個速度V_avg，那兩點之間行走的時間應該會跟距離有關，但我上周都是預設1000個時間單位去進行，因此會變成距離無論有多長，計畫的行走時間都一樣，這樣速度自然會忽快忽慢。另外一個問題是我對路徑規劃的k值有輕忽，從邊界條件，可以發現k值其實會與初速度和末速度有關，但我上周卻只是隨手預設一個10，因此造成車子需要同時滿足與平均速率不符的初速末速，又不論長短也要在同樣時間內走完路徑，最後的結果即是上周那樣的忽快忽慢。
作為修正，我將整體參數改變，首先預設一個平均速率V_avg，接著由於希望初速末速也同樣等於V_avg，就應該要設定k = V_avg * T ，T 為整段路徑所花費的時間。但這邊出現了雞生蛋、蛋生雞的問題，因為k值會決定路徑長度，但T卻要在知道路徑長度才能計算，因此我決定先以一個預設的k值為10(即預設方格間的直線距離)，在算出第一個路徑後，計算路徑長，再重新設定k，重新算出較符合目的的路徑。等於是做一次疊代，理想上進行多次疊代效果應該會更好，但目前先以一次進行測試。
最後加上飽和條件(|V|<=0.25/s |W|<=0.5rad/s)以及發布速度命令的頻率(10Hz)後，最後的速度圖形如下，其中藍線為理想上的速度；橘線為速度命令。
從上圖可以發現，若車子起始與路徑有些距離，會需要一段時間來追上，而根據測試，若飽和速度和預設速度差距較小，會出現追不上路徑的問題。而發布頻率若過慢，也同樣會追不上路徑。這兩點是之後實作時需要特別注意的。
而以上在Matlab實作的部分，已部分轉換至python上，但由於python的模擬呈現還在思考實現方式，所以仍無結果，下周繼續努力。
下周待辦事項：
- 將整個控制移植至Linux系統，以C++或Python包裝成ROS package並搭配turtlesim去模擬(輸入為三個座標點，輸出為根據規畫時間丟出速度與角速度命令) (上週擱置)
- 行人方位辨識的整體架構規劃與初步實作
- AMR_100 交接事項
- 以移動機器人模擬地圖可行性探討
Memo：python部分語法
- Library部分：
- 多項式計算：numpy
- 基本繪圖：matplotlib.pyplot
- 數學運算；math
- List格式：範例：goal_set = [[-15,-15],[-25,-5],[-25,5],[-25,15],[-15,15],[-5,15]]
- List的長度：goal_num = len(goal_set)
- for loop： for i in range(0,goal_num-1):
- if-else： if 條件:
- X.append ： 在X矩陣最後塞入元素
- 多項式值：numpy.polyval
- 指數：X ** 2 = X平方