Current status of Android and Ros communication
Because Ros officially supports voice bindings that are only C + + and Python, Android now wants to communicate with Ros by using a semi-official Rosjava package, and the Rosjava is too heavy because it is a full-featured Ros binding like C++/python, It means that you can create master node on the Java (Android) platform, and then other Node (C++/python) can connect to this master for distributed communication! This may be acceptable for desktop Java, but it's too complex for Android.
In addition, Rosjava's gradle script is too complex, requires a deep gradle knowledge to integrate it into their Android project, many companies (such as our-_-!) bother to import the Rosjava demo project directly, and then add their own code in, If there are new people in the team, then we have to rebuild a rosjava environment, too much trouble.
Rosbridge protocol
Many people think that the mobile platform or embedded system to achieve the distributed communication with Ros cost is too high, we thought that the C/s architecture may be more in line with the needs of mobile platform, so proposed the Rosbridge protocol, the basic idea of the protocol is to connect the distributed communication between the nodes, To the client node and a proxy node for C/S communication, then the agent node then forwarded the request to the server node, so that the mobile side does not need to implement the entire Ros platform, only need to communicate with the agent node.
This is a comparison of Rosjava and rosbridge the merits of the PDF, simply speaking, is the mobile platform to sacrifice the cost of doing server nodes, in exchange for the ability of lightweight Ros interaction. However, in special cases rosjava is useful, such as the robot's chassis to invoke the service of the robotic arm, if the picker only supports Rosbridge, then the call is not possible-but this situation through the pub/sub should also be resolved.
Rosbridgeclient Library
To enable Android to send and receive Rosbridge messages, first of all to support websocket this special transmission channel to enable Android to receive the Ros end publish (push) over the message, most of the current implementation WebSocket focus on desktop Java, such as jetty, Netty, and so on, where jetty because some Dalvik VMs are not supported by the Java class and can not be used on Android. In addition to Android's own WebView to WebSocket support later, can not guarantee the full-model coverage, so java-websocket this Java.nio in the class implementation of the WebSocket will stand out.
With the transmission channel, the rest is how the packet is sent, the library not only to convert the sent Java type to a language-independent Ros message type (and vice versa), but also to the Ros operation (subscription, release, call service, Broadcast topic, etc.) into the JSON string specified in Rosbridge, after evaluating the Java_rosbridge library and Rosbridgeclient Library, I chose the latter, because the former is smaller, but Jetty is used to achieve websocket communication, Can't run on Android.
Add the message type in the STD_MSGS package
In the process of trial Rosbridgeclient Library, I found that the author even std_msgs in the message type-for example, string--is not implemented, but instead, is a clever annotation plus reflection mechanism implementation of the meta message type, to expand very simple, See the repo I fork out
In the process of groping std_msgs, I figured out a mechanism: the built-in type of ROS does not actually exist, it must correspond to the built-in type of the specific language, so in order to communicate across languages, all message can only use the wrapper type, which explains why Std_ Msgs a bunch of wrapper in the bag, because the built-in type (such as String) in each msg file is nonexistent and must correspond to a Java string, or Python's str, or C + + std::string, Only a string that does not correspond to Ros, because Ros is not a language.
[Go] using the Rosbridge protocol to decouple Android from Ros