更新了大量文档

application/APP层应用编写指引.md

@@ -6,7 +6,7 @@
 
 **应用之间不应该有任何包含关系，它们必须是平行工作的。**而这通过pub-sub的机制实现。module层提供了`message_center`模块，支持发布订阅者的消息订阅机制。以传统的框架为例，负责整车控制的应用和其他应用（或任务）是从属的树状结构，或不同的任务和应用之间通过全局变量传递消息（**请不要使用全局变量！**），而此框架下的不同应用是并行的关系。
 
-如果一个应用希望获取另一个应用的数据，那么他应该**订阅**由此此应用发布的话题（事件）。一个应用要把自己希望共享的数据，注册到消息中心，即**发布**。为了区别不同的消息来源（你希望订阅谁的消息？哪一个消息？），可以通过**话题名**进行订阅。也就是说，消息中心作为第三方，管理所有的消息发布者和订阅者，它像报刊亭一样对消息进行中转，使得不同的应用之间不需要包含彼此，更不用全局变量也能共享消息。
+如果一个应用希望获取另一个应用的数据，那么他应该**订阅**由此此应用发布的话题。一个应用要把自己希望共享的数据，注册到消息中心，即**发布**。为了区别不同的消息来源（你希望订阅谁的消息？哪一个消息？），可以通过**话题名**进行订阅。也就是说，消息中心作为第三方，管理所有的消息发布者和订阅者，它像报刊亭一样对消息进行中转，使得不同的应用之间不需要包含彼此，更不用全局变量也能共享消息。
 
 > 更多关于发布-订阅的实现，请参考`modules/message_center`下的文档。
 
@@ -15,7 +15,7 @@
 
 这是机器人的参数配置文件，必须要针对每个机器人进行修改。包括机器人的尺寸参数和性能参数等。你还需要在这里设定软硬件配置：云台板/底盘板/单板等。这里定义的宏会作为条件编译的决断。
 
-app层共用的状态变量和结构体等也应该定义在这里（例如用于应用之间通信的数据）。记得通信变量要用:
+app层共用的状态变量和结构体等也应该定义在这里（例如用于应用之间通信的数据）。记得用于通信的变量要用:
 ```c
 #pragma pack(1) 
 typedef struct
@@ -25,7 +25,9 @@ typedef struct
 } your_struct;
 #pragma pack()
 ```
-包裹起来，取消字节对齐以防止出现访问8byte地址而出现错误。
+包裹起来，取消字节对齐以防止出现访问8-bit地址而出现错误。
+
+如果你需要其他的通信数据类型或修改模块间通信数据的格式，直接在此处更改即可。
 
 ## robot_cmd
 
@@ -35,6 +37,8 @@ typedef struct
 
 robot_cmd工作起来就像一个遥控数据的兼容层，不论数据的来源是视觉上位机/遥控器/键鼠/图传通信链路/ps手柄，最后都会被转化成真实参考输入提供给其他的app。它的任务是将其他来源的数据映射到控制输入上。
 
+
+
 ## gimbal
 
 以步兵为例，云台应用应当包含两个电机，分别用于驱动yaw和pitch轴（除非你是一个三轴的云台），还有一个imu（开发板一般放在云台上）。gimbal模块会接收robot_cmd发来的控制信息（云台的角度、转速等），并通过电机提供的接口完成电机的参考值设定。gimbal还要把imu的数据反馈给cmd，用于和视觉的通信以及云台状态的判断。
@@ -63,3 +67,4 @@ robot_cmd工作起来就像一个遥控数据的兼容层，不论数据的来
 
 此框架对单开发板/双开发板/多开发板的情况都提供了支持（多板一般只在工程机器人上出现，需要自己在robot_cmd和robot_def增加相应的条件编译选项，robot.c中也不要忘记增加初始化和任务运行函数），目前通过条件编译实现了对单双板的切换。使用双板时，主控板在云台上，连接遥控器和上位机；副板在底盘上，负责底盘的运动控制和与裁判系统的通信。
 
+当然，你可以为每台不同的机器人进行特化，因为本框架是针对步兵/英雄定制的。