??????????? 簡單消息協議：定義了ROS與工業機器人之間簡單的消息協議。額外的處理程序和管理器類包含用于處理有限連接的系統。這個包是ROS-Industrial計劃的一部分。

????????????

??????????? 簡單消息協議定義了ROS驅動層與機器人控制器層通信的消息結構。該消息結構符合下列要求：

??????????? 1、結構足夠簡單，可以讓ROS與控制器之間共同處理。（對于那些支持C/C++的控制器）。對于那些不支持C/C++的控制器，結構要足夠簡單，以適應解碼能力有限的機器人編程語言。這個需求的一個必然的結果是：協議不應如此繁重，而耗盡機器人控制器有限的資源。

???????????? 2、結構應該允許數據流（ROS 服務等）

???????????? 3、結構應該允許數據回復(ROS服務等)

???????????? 4、協議并不打算封裝版本信息。由個體開發人員以確保交流平臺開發的代碼沒有任何版本沖突(這包括消息類型標識符)。

消息結構：

??????????? PREFIX Not considered part of the message 前綴???? 不作為消息的一部分考慮

????????????int ?? LENGTH (HEADER + DATA) in bytes?? 文件頭與文件主體加在一起的字節數。

??????????? HEADER?? 文件頭

??????????? int MSG_TYPE??? 確定消息的類型? ( 標準和機器人特定的值 )? identifies type of message (standard and robot specific values)

??????????? int COMM_TYPE 確定通信類型? identified communications type

??????????? int REPLY CODE? 回復服務? (service reply only) reply code

??????????? BODY???????? 文件主體

??????????? Byte Array???? 被數據類型和通信類型確定的，可變長度的數據變量，具體數據變量的結構，可參考下面:? DATA variable length data determined by message type and and communications type.

消息類型

???????????? 消息協議允許任意的消息類型和通訊類型的載體數據。但是，客戶端/服務器模式? 要求雙方都需要理解不同的消息類型和通訊類型相關的載體數據。消息類型強制要求載體的數據結構。? 消息類型的基類提供 創建主題，回復，請求消息的方法。???如果在客戶端和服務器共同使用，開發人員不需要了解載體的數據結構。????不幸的是，一個典型的機器人控制器不能使用C + +類，因此，開發人員必須理解該消息的協議和載體數據的數據結構，以從語法上解析機器人側發過來的載體數據。消息的具體結構的文檔可以在頭文件中找到。 為方便起見，消息結構也在這里顯示為普通的消息類型。對于類型化的消息結構的更詳細的例子， tutorial.

Joint Message

關節消息

?????????? 這個消息代表關節數據。 注：在早期版本，JOINT message被簡單提供，很多關節消息因此造成了混淆（位置、速度、返回值）。為了消除混淆，這個消息類型被改為JOINT_POSITION.??????? 其他類型的消息也會創建，如速度消息、返回值消息。

Member	Type	Value	Size
Message Type:	StandardMsgType::JOINT_POSITION	10	4 bytes
Communications Type:	CommType	ANY	4 bytes
Reply Type:	ReplyType	ANY	4 bytes
Data (Topic, Requests, & Response)	?
sequence	shared_int	ANY	4 bytes
joints	shared_real[10]	ANY	40 bytes

File: trajectory_msgs/JointTrajectoryPoint.msg

Raw Message Definition

Compact Message Definition

float64[] positions
float64[] velocities
float64[] accelerations
float64[] effort
duration time_from_start

Joint Trajectory Point Message

關節軌跡點消息

??????? 點數據作為一個沿著一個軌跡運動的方式，其目的是鏡像trajectory_msgs/JointTrajectory點消息。這個點與ROS的軌跡點有以下不同：

??????? 的關節速度在工業機器人的標準方法（作為一個單一的值）。
?????? 持續時間是一些什么比ROS時間戳不同。時間戳指定當移動應該開始，因為那里的持續時間是移動需時多久。一個很大的假設是，繼續執行點的序列。這通常是一個ROS的軌跡真實的，但不是必需的。

The point data serves as a waypoint along a trajectory and is meant to mirror thetrajectory_msgs/JointTrajectoryPoint message. This point differs from the ROS trajectory point in the following ways:

• 關節速度通過工業機器人的標準方法。The joint velocity in an industrial robot standard way (as a single value).
• 持續時間與ROS的時間戳有所不同。 時間戳制定了什么時候應該移動，應該移動的距離。一個大的假設是：持續執行點的隊列。這通常是一個真實的ROS軌跡，但不是必須的。The duration is somewhat different than the ROS timestamp. The timestamp specifies when the move should start, where as the duration is how long the move should take. A big assumption is that a sequence of points is continuously executed. This is generally true of a ROS trajectory but not required.

Member	Type	Value	Size
Message Type:	StandardMsgType::JOINT_TRAJ_PT	11	4 bytes
Communications Type:	CommType	ANY	4 bytes
Reply Type:	ReplyType	ANY	4 bytes
Data(Topic & Requests, Response data are empty)	?
sequence	shared_int	ANY	4 bytes
joints	shared_real[10]	ANY	40 bytes
velocity	shared_real	ANY	4 bytes
duration	shared_real	ANY	4 bytes

???????? ??? 簡單的信息利用抽象的連接(SmplMsgConnection)接口發送消息到工業機器人控制器。接口有兩個假設:

1. 能夠發送原始字節的連接（raw bytes）。
2. 數據連接有一個明確的連接,建立連接(方法)和斷開連接的方法。注意:無連接的數據連接,如UDP連接，連接方法可以是一個空操作，用以占位。

???????????? tcp套接字連接被包裹在連接接口中。這是推薦的連接類型。

連接管理器和消息處理程序

????????? 消息管理器和處理器(MessageHandler 和 MessageManager)類可以用來管理連接,允許多個消息類型處理。消息管理器包含一個消息處理程序列表和接收到消息時執行適當的處理程序。????? 在擁有少量連接的機器人控制器中，這些類是特別有用的。

Wireshark協議解析器

A Lua Wireshark dissector plugin for the simple message protocol is available fromros-industrial/packet-simplemessage at GitHub. See the readme for information on how to install it.