先分析下OpenTCS的一些策略方面的東西，這是OpenTCS的基礎。
首先需要先明確下OpenTCS內核中的三個概念：
路由(Route) ： 決定了車輛通過什麼樣的方式和算法來獲得一段路徑，未來車輛將沿着此路徑運行。
派遣(Dispacher)： 決定了一個訂單應該關聯哪一輛小車，即爲訂單分配車輛和爲車輛分配訂單。
調度(schedule)：狹義上的調度，交通管制的核心，決定了何時分配共享資源，何時釋放擁有的資源。
以上是來自內核的約定，即如果二次開發，必須要按照這樣的概念進行設計，當然OpenTCS提供了默認的算法實現（可修改和替換）。這些默認實現包含在openTCS-Strategies-Default子項目中。
本節先來分析下OpenTCS提供的默認Route策略，按照我的理解記錄如下:
1、路由算法。
主要是實現了最短路徑算法，OpenTCS提供了三種路由算法供選擇,分別是：
迪傑斯特拉算法
貝爾曼-福特算法
弗洛伊德算法。
一般來說我們直接使用迪傑斯特拉算法就行了，因爲我們的移動機器人一般只需要計算單源最短路徑(機器人到目標點)，也不需要處理負權邊。
這裏有意思的是，OpenTCS支持爲每一臺機器人設置不同的路由計算器，存在類似這樣的結構：
//只做示意,OpenTCS中並未存在這樣的代碼
Map<Vehicle,Router> vehicleToRouter;
這樣當我們在項目中由不同類型的機器人時，可以更加靈活的選擇路由。
2、靜態規劃。
遺憾的是，OpenTCS不支持動態路由，只支持靜態計算路由。這樣發生死鎖的概率其實高很多,特別是當任務存在關聯性時，如果不對任務的下發加以處理，死鎖就經常性的發生了。
另外當所有車的路由算法都一致時，車輛佔道的情況不能處理，具體體現如下：
當有兩輛車分別位於7和8點，其中7點的車發往13號點（7-9-10-11-13），假設其在11號點發生了故障或者遇到了障礙物需要靜止運行。
此時第二輛車若需要去14點，默認的算法就會蒙圈，他依然是傻傻的選擇路由(8-10-11-12-14)，可想而知，如果前面的車一直佔用11點，兩輛車就會死鎖。
關於此問題的改進，需要進行動態規劃，後面有機會再說......
3、自定義路由算法。
如果需要自定義路由算法，則只需要通過實現以下PointRouter接口（此接口只有兩個成員函數）即可。
//路由的算法接口
public interface PointRouter {
//此函數必須返回點到點的Steps
List<Route.Step> getRouteSteps(Point srcPoint, Point destPoint);
//此函數必須返回點到點所需要的代價（在派遣階段可以此決策是否關聯訂單）
public long getCosts(TCSObjectReference<Point> srcPointRef,
TCSObjectReference<Point> destPointRef);
}
因此，我們在二次開發的過程中，如果某輛車的路由是特殊的算法（即不能使用上面所說的三種路由算法）時，即可通過實現上述接口自己開發對應的算法來處理啦。