3.31-ROS study notes - primary

• data
• Several books now, no data
• Chinese version of the primary help documentation
• Official website information it
• First Chinese primary help document read, read "ROS study notes - the primary"
• ROS installed in /opt/ROS
  
• echo this is the roscore and any other name
• Based on the turtlesim connected roscore xmlrpc
• XML-RPC stands for XML Remote Procedure Call, i.e. the XML ( Standard Generalized Markup Language a subset of the) remote method invocation. It is a set of allowed to run on different operating systems, different environmental norms and procedures to achieve the realization of a series of Internet-based procedure call. This remote procedure calls using http as transport protocol , XML as the encoding format to transmit information. Xml-Rpc defined kept simple as possible, but can be transmitted, the process returns to complex data structures.
• sudo apt-get install ros-indigo-rqt
• sudo apt-get install ros-indigo-rqt-common-plugins 
• How to view the source code of the existing package?
• How do I know how news release? How do I know how to accept the message, how to respond to the message?
• sudo apt-get install vim
• Modify the default editor
• export EDITOR='sublime'
• Two windows running a copy of the code
• File--->New View into File
• Make this shortcut?
• After a new message, modify the configuration file, recompile, then need to re-look at the profile source
• export ROS_PACKAGE_PATH=~/Documents/zsProjects/zsP3AT/zsROS_ws/:${ROS_PACKAGE_PATH}
• export ROS_WORKSPACE=~/Documents/zsProjects/zsP3AT/zsROS_ws/
• Catkin keeps the concept of overlays utilizing these environment setup files. However, there is a subtle difference from rosbuild -- when a catkin environment setup file is sourced, it overwrites instead of extending existing environment variables. You may then be asking how chaining can work. Simply put, catkin generates lots of setup files in different contexts that chain multiple environments together with a single setup file. When you build code within your workspace, setup files are generated within the "devel space". When these are sourced, any setup files from other workspaces that were used at build time are automatically sourced. For example, if you source /opt/ros/groovy/setup.bash then build your workspace, sourcing the setup.bash file in the devel space will automatically pull in /opt/ros/groovy/setup.bash. Likewise if you install your workspace, the install space will contain a setup.bash file as well that will overlay the install space on top of any workspaces that were used to build that workspace.
• After creating the talker and listener
• add_dependencies(talker zsbegin_generate_messages_cpp)
• add_dependencies(listener zsbegin_generate_messages_cpp)
• source ${ROS_WORKSPACE}/devel/setup.bash
• Create a service program ( Service has been established, and publish it in ROS )
• Compilation system automatically based on file should srv srv file we created earlier generation of header files
• Since the service call is modal process (a process called when occupancy prevent the execution of other code), once the call is completed, the results will return the call. If the service call is successful, call () function returns true, srv.response inside the values ​​are legal values. If the call fails, call () function returns false, srv.response inside the value would be illegal.
  
• Then "ROS Robot Programming" chapter "ROS system architecture and an example of" learning again
• Look ROSARIA official aid operation, the ability to ROSARIA investigation, consider using this in the end is still ARIA
• Use CLion project development!