Module VI: ROS and Robot Programming PDF

Module VI Programming of Robots Prepared by Dr.R.Priyadarshini  Syllabus Introduction to robot control, Robot programming and Languages- Introduction to ROS, Languages, software's and Ros, ROS1, ROS2, GAZEEBO, Architecture Diagram, Characteristics of ROS...

Module VI Programming of Robots Prepared by Dr.R.Priyadarshini  Syllabus Introduction to robot control, Robot programming and Languages- Introduction to ROS, Languages, software's and Ros, ROS1, ROS2, GAZEEBO, Architecture Diagram, Characteristics of ROS.  Classification of Robot Languages Robot languages can be grouped broadly in to three major classes – First generation language – Second generation language – World modelling and task-oriented object language  General Requirements of a Language for Robot Control 1) Geometric and kinematic calculations: functions and data types to allow the compact and efficient expression of coordinate systems in homogeneous coordinates and their transforms (matrix arithmetic); perhaps even very high level operations such as solving the kinematic equations. 2) World modelling: the ability to define objects by, for example, the space enclosed by a set of intersecting surfaces, to manipulate such objects as a whole, to 'attach' objects(including parts of the robot) so that the system knows that if one object moves then any attached objects also move, and to test for collisions. Other functions can be imagined. World modelling is related to simulation and computer-aided design.  General Requirements of a Language for Robot Control 3) Motion specification: the ability to do the things described in the section on specifying trajectories. This implies functions such as linear interpolation, finding the equation of a circle from points on it, fitting curves through a series of points and so on. It may also be useful to specify sawtooth weaving, as used in arc welding, speed and acceleration, and the direction of approach to a certain point (important for assembly). 4) The use of sensing for program branching and servo control.  General Requirements of a Language for Robot Control 5) Teaching: the ability to accept path points taught by leading or walking through. This is perhaps an aspect of trajectory generation. 6) Communication with other machines. 7) Vision and other complex sensing (such as tactile imaging). Although it is more usual for such processing to be done in a separate system which feeds a simple result such as object orientation to the robot control system, there may be a place for these capabilities within the language itself.  Robot Languages The earliest was MIT's language MHI in 1960. Its main robot-specific constructs are moves and sensor tests. A more general purpose language was WAVE, developed at Stanford in the early 1970s. It introduced the description of positions by Cartesian coordinates, coordinated joint motions and compliance by letting certain joints move freely under external loads. An influential language, which is still being extended, is AL. This provides Cartesian specification of motions, compliance, the data ,types and control structures of an Algollike language, support for world modelling (such as attachment) and the concurrent execution of processes.  Versatile Assembly Language (VAL) It is a popular textual robot language developed by Unimation Inc. for the PUMA series of robots Victor Sheinman developed VAL language It is very user friendly WAIT and SIGNAL commands can be given to implement a specific task The commands are subroutines written in BASIC and translated with the aid of an interpreter Compiled BASIC has more flexibility It provides arm movement in joint, world and tool coordinates Gripping Speed control  Robot configuration control RIGHTY changes the robot configuration to resemble a right human arm LEFTY change the robot configuration to resemble a left human arm ABOVE makes the elbow of the robot to point up BELOW makes the elbow of the robot to point down  Motion control MOVE moves the robot to a specific location MOVES moves the robot in a straight line path DRAW moves the robot along a straight line through specified distances In X,Y and Z directions APPRO moves the robot to a location which is at an offset (along tool Z-axis) from a specified point DEPART moves the tool along the current tool Z- axis APPROS or DEPARTS do the same as APPRO or DEPART instruction, but along straight line paths CIRCLE moves the robot through circular interpolation via three specified point location  Hand control OPEN and CLOSE indicates respectively the opening and closing of the gripper during the next instruction OPENI and CLOSEI carry on the same functions, but immediately GRASP indicates the gripper to close MOVEST PART indicates that the servo controller end effector causes a straight line motion to a point defined by PART MOVET PART causes the gripper to move to position by joint-interpolated motion  Location Assignment and modification SET HERE  Program control, interlock commands and input/output controls SETI sets the value of an integer variable to the result of an expression TYPEI displays the name and value of an integer variable PROMPT GOTO performs an unconditional branch to the program step identified by a given level GOSUB and RETURN are necessary to transfer control to a subroutine and back to the calling program respectively IF…THEN ELSE END transfers control to a program step depending on a relationship being true or false  Cont.. PROCEED resumed from the point SIGNAL turns the signals ON or OFF at the specified output channels IFSIG and WAIT test the states of one or more external signals RESET turns OFF all external output signals REACT indicates that the reactions REACTI interrupts robot motion immediately IOPUT and IOGET are the commands that are used either to send or receive output respectively to a digital I/O module ADC and DAC Simple VAL program Program DEMO. A 1. APPRO PART, 50 2. MOVES PART 3. CLOSEI 4. DEPARTS 150 5. APPROS BOX, 200 6. MOVE BOX 7. OPENI 8. DEPART 75 END  Meaning of the program The name of the program is DEMO. A 1. Move to a location, 50mm above the location PART (PART is a location to be defined) 2. Move along a straight line to PART 3. Close the gripper jaws to grip the object immediately 4. Withdraw 150mm from PART along a straight line path 5. Approach along a straight line to a location 200mm above the location, BOX (BOX is to be defined later) 6. Move to BOX 7. Open the hand (and drop the object) 8. Withdraw 75mm from Box  Step 1, 6 & 7 are examples of joint- interpolated motions Steps 2, 4, & 5 are examples of straight line motion Step 3 & 7 contain hand control instruction However, an optional level may be given, such as “10 APPRO PART, 50” Go back to the same instruction  ROBOT KINEMATICS It is assumed that a robot can be regarded as a chain of rigid links connected by revolute or prismatic joints at which actuators, regarded as torque or force generators. The control of flexible structures is in its infancy and will not be discussed. With this assumption, there is a set of important problems in analysis and control, and most of the literature on robot control addresses one or other of these. Some have accepted solutions; others are the subject of research.  ROBOT KINEMATICS They are as follows: 1) formulating the kinematic equations (joint coordinates to world coordinates) ; 2) solving the kinematic equations (world coordinates to joint coordinates); 3) the forward problem of dynamics - finding the motions resulting from joint torques; 4) the inverse problem of dynamics - finding the torques needed to produce a given motion; 5) specifying a trajectory between target points on the path; 6) actuator servo control - for a single actuator, how to drive it so as to produce a specified position, velocity or torque.  Forward Kinematics It is a scheme to determine joint angles of a robot by knowing its position in the world coordinate system. For a manipulator, the position and orientation of the end-effector are derived from the given joint angles and link parameters, the scheme is called the forward kinematics problem.  Reverse Kinematics It is a scheme to determine the position of the robot in the world coordinate system by knowing the joint angles and the link parameters of the robot. If, the joint angles and the different configuration of the manipulator are derived from the position and orientation of the end effector , the scheme is called the reverse kinematics problem.  Introduction to ROS ROS is an open-source robot operating system A set of software libraries and tools that help you build robot applications that work across a wide variety of robotic platforms Originally developed in 2007 at the Stanford Artificial Intelligence Laboratory and development continued at Willow Garage Since 2013 managed by OSRF (Open Source Robotics Foundation)  ROS has two "sides" The operating system side, which provides standard operating system services such as: hardware abstraction low-level device control implementation of commonly used functionality message- passing between processes package management A suite of user contributed packages that implement common robot functionality such as SLAM, planning, perception, vision, manipulation, etc. What is ROS? ROS is an open-source, meta-operating system for your robot. It provides the services you would expect from an operating system, including hardware abstraction, low-level device control, implementation of commonly-used functionality, message-passing between processes, and package management. It also provides tools and libraries for obtaining, building, writing, and running code across multiple computers. ROS is similar in some respects to 'robot frameworks, such as Player, YARP, Orocos, CARMEN, Orca, MOOS, and Microsoft Robotics Studio.  The ROS Equation The ROS project can be defined in a single equation 1. Plumbing: ROS provides publish-subscribe messaging infrastructure designed to support the quick and easy construction of distributed computing systems. 2. Tools: ROS provides an extensive set of tools for configuring, starting, introspecting, debugging, visualizing, logging, testing, and stopping distributed computing systems. 3. Capabilities: ROS provides a broad collection of libraries that implement useful robot functionality, with a focus on mobility, manipulation, and perception. 4. Ecosystem: ROS is supported and improved by a large community, with a strong focus on integration and documentation. ros.org is a one-stop-shop for finding and learning about the thousands of ROS packages that are available from developers around the world.  Characteristics of ROS Distributed process: It is programmed in the form of nodes, the smallest units of executable processes. Each node runs independently and systematically exchanges data. Package management: Multiple processes with the same goal are managed as a package, making it simple to use and develop and share, modify, and redistribute. Public repository: Each package is published to the developer’s preferred public repository (e.g., GitHub) and attached a license. API: When creating a program with ROS, it is designed to call an API and easily insert it into the code. You’ll notice that ROS programming is similar to C++ and Python in the source code. Supporting various programming languages: The ROS program includes a client library that can be used with various programming languages. The library can be used with popular robotics programming languages like Python, C++, and Lisp and languages like JAVA, C#, Lua, and Ruby. Put another way, you can write a ROS program in any programming language you want.  Components of ROS ROS consists of a client library to support various programming languages, a hardware interface for hardware control, communication for data transmission and reception, The Robotics Application Framework to help create various Robotics Applications. Framework, Simulation tools which can control the robot in a virtual space, and Software Development Tools  Key Components of ROS Understanding the architecture of ROS involves recognizing the roles of its key components. These components are designed to work together seamlessly: Nodes: Independent processes that represent software programs performing specific tasks in ROS. Messages: Data exchanged between nodes. This could be sensor information or control inputs. Services: Defined locations in the code where functions can be called remotely. Topics: Established channels for nodes to send and receive messages asynchronously. Packages: Organizational unit for ROS code, containing nodes, configuration files, and sometimes datasets or libraries. These components together facilitate communication and coordination for robot tasks, enhancing functionality and ease of development.  Core Elements of ROS Architecture The architecture of ROS is designed to be robust and adaptable. Here are the principal elements that make up ROS: Nodes: These are the fundamental processing units in ROS. Each node is a standalone process that performs computation. Master: The node that manages communication among other nodes. It keeps track of all the active nodes and facilitates message passing. Messages: Defined data structures used by nodes to communicate. Topics: These are named buses over which nodes exchange messages. Services: Synchronous communication channels provided by nodes. These components work together to enable distributed and parallel processing in robotic applications. Example Imagine developing a simple robot application where one node controls the motor speed while another node processes sensor input. In ROS, you could separate these tasks into distinct nodes, using topics to exchange messages regarding motor speed adjustments and sensor data. This separation of functionalities allows for better modularity and maintainability. Three level ROS Architecture ROS architecture with robots, sensors, controllers and the central computer. ROS 2 Architecture  Benefits of Open Source ROS Collaboration: Developers around the globe can contribute to and benefit from the work of others, fostering rapid innovation. Cost-effectiveness: Free access to robust software libraries allows you to save on development costs. Adaptability: Open source enables customization and extension to meet specific requirements. Community Support: Access to a vast community means help is readily available through forums and shared documentation. These advantages make ROS an ideal choice for projects that require flexibility, efficiency, and continual improvement. Using open source ROS, suppose you want to create a robot that can autonomously navigate through a home. You can utilize existing open source packages like the Navigation Stack, which provides capabilities for localization, path planning, and collision avoidance. By tapping into the shared knowledge base, you can significantly reduce development time and focus on unique customizations. ROS Architecture ROS Architecture concept involves Graph Resource Names in the strategy. These are a fundamental piece of the ROS naming system, providing a way to globally reference nodes, topics, and services. The use of Graph Resource Names allows for a consistent and organized structure within the ROS framework, enabling complex robot applications to be developed with ease. This system is hierarchical and supports namespaces, making it possible to avoid naming collisions. By leveraging this naming convention, you can help ensure clarity and organization in larger projects that employ multiple modules and processes.  Why ROS? Free and open source robotics software framework Message passing interface between processes Operating system–like features. High-level programming language support and tools. Availability of third-party libraries. Off-the-shelf algorithms. Ease in prototyping Ecosystem/community support. Extensive tools and simulators  Robot operating systems - Examples Different versions of the Robot Operating System provide varying functions suitable for specific tasks and research. ROS Noetic: A stable version often used for research and academic purposes. ROS 2: An evolution of ROS 1, designed with improved support for real-time systems, multi-robot systems, and enhanced security. Micro-ROS: Targeted for embedded systems with limited resources, making it ideal for small robots. These different versions cater to the diverse needs of robotic applications. They allow you to select the most appropriate tool based on the specific requirements of your project. ROS contains many open source implementations of common robotics functionality and algorithms. These open source implementations are organized into "packages". Many packages are included as part of ROS distributions, while others may be developed by individuals and distributed through code sharing sites such as GitHub. Some packages of note include: Motion Mapping and planning localization Navigation Perception Coordinate frame Simulation representatio n ROS Robots https://robots.ros.org/  When to use ROS?! 1- The robot contains many different sensors and actuators. ROS will help you create a distributed system for all those components, instead of having one big monolith code base that will be hard to maintain and scale. 2- For Education Purposes. ROS helps students see the full picture of robotics applications. 3- For Research Purposes. Prevents re-inventing the wheel. 4- For Fast Prototyping Why might ROS be not preferable?! Difficulty in learning: Difficulties in starting with ROS can be difficult to learn. It simulation: has a steep learning curve and The toughness of learning developers should become simulation using Gazebo and familiar with many new concepts ROS is a reason for not using it to get benefits from the ROS in projects. framework. Difficulties in robot Potential limitations: modeling: 1- complexity to implement Learning to model a robot in ROS robust multi-robot distributed will take a lot of time, and applications. building using URDF tags is also 2- There is a lack of a native time-consuming compared to real-time application other simulators. development support ROS Concepts There are mainly three levels of ROS: The ROS file system The ROS Computation Graph The ROS community ROS filesystem Package Manifests: Metapackag Message Packages: es: (msg) types: Service (srv) types: ROS filesystem ROS packages are the main unit of an ROS software framework. A ROS package may Metapackag Packages: contain executables, es: ROS-dependent library, configuration files, and so on. ROS packages can be reused and shared. ROS filesystem The manifests (package.xml) file will have all the details of the Package Manifests: packages, including name, description, license, and dependencies. Message descriptions are stored in the msg folder in a package. ROS messages are data structures for Metapackages: Packages: Message (msg) sending data through ROS. types: Message definitions are stored in a file with the.msg extension. Service descriptions are stored in the srv folder with Service (srv) the.srv extension. The srv files define the request types: and response data structure for service in ROS. ROS Computatio MASTER NODES PARAMETER LEVEL MESSAGES n Graph Level The ROS Computation Graph is the peer-to-peer network of the ROS process that TOPICS SERVICES BAGS processes data together. The following are the basic concepts of ROS CGL: Communication Tools  A node really isn't much more than an executable file within a ROS package. ROS nodes use a ROS client ROS Nodes library to communicate with other nodes. Nodes can publish or subscribe to a Topic. Nodes can also provide or use a Service.  A node can be A node is a launched ROS program independently that uses of other nodes ROS’s and in any middleware for order among communicatio launches of ns. other nodes. ROS Nodes Many nodes A node is can run on the useful only if it same can computer, or communicate nodes may be with other distributed nodes and across a ultimately with network of sensors and computers. actuators.  ROS topics are Named buses in which ROS ROS Topics nodes can send a message. A node can publish or subscribe any number of topics. ROS Topics A topic may be introduced, and various publishers may take turns publishing to that topic. Publishers and subscribers are anonymous. A publishers only knows it is publishing to a topic, and a subscriber only knows it is subscribing to a topic. Nothing else. A topic has a message type. All publishers and subscribers on this topic must use the message type associated with the topic. ROS Messages A message is a simple data structure, comprising typed fields. Standard primitive types (integer, floating point, Boolean, etc.) are supported, as are arrays of primitive types. Messages can include arbitrarily nested structures and arrays (much like C structs). The messages are basically going through the topic. Creating the Messages ROS SERVICES We have already seen ROS Topics, which is having publishing and subscribing mechanism. The ROS Service has Request/Reply mechanism. A service call is a function, which can call whenever a client node sends a request. The node who create a service call is called Server node and who call the service is called client node. ROS Parameters ROS parameter server is a program that normally runs along with the ROS master. The user can store various parameters or values on this server and all the nodes can access it. The user can set privacy of the parameter too. If it is a public parameter, all the nodes have access; if it is private, only a specific node can access the parameter. ROS Bags Data logging is a vital debugging tool. It is common in ROS systems to log data to file for later analysis and playback. Data logging works as you might expect subscribe to the topic(s) that you want to log, and then write incoming messages to disk. In fact, you could easily write your own node to log data for your application. However, you shouldn’t write your own logger, because ROS provides a powerful, general logging tool called rosbag. The rosbag tool is able to log data of any type from any ROS topic, all to a single file. By convention, the resulting log files have the extension.bag and are referred to as “ROS bags,” or simply, “bags.”  ROS Master: An intermediate program that connects ROS nodes. When a node wants to publish something, it will inform the ROS ROS Master master. When another node wants to subscribe to a topic, it will ask the ROS master from where it can get the data. You can see the ROS master as a DNS server for nodes to find where to communicate. Creating ROS Applications How to create: 1. ROS workspace. 2. ROS package. 3. ROS nodes. ROS Build System : CATKIN catkin is a build system for compiling ROS packages. (http://wiki.ros.org/catkin). catkin is a custom build system made from the CMake build system and Python scripting. ROS Workspace ROS Workspace 1. The first step in ROS development is the creation of the ROS workspace, which is where ROS packages are kept. We can create new packages, install existing packages, build and create new executables. 2. A workspace is simply a set of directories in which a related set of ROS code lives.  ROS Workspace src build devel folder folder folder  src folder build folder devel folder The src folder is The catkin tool All the executable the place where creates some build files results from you can create, files and intermediate building the or clone, new cache CMake files packages is inside the build stored inside the packages from folder. devel folder, repositories. NOTE: ROS packages only These cache files which has shell build and create an help prevent from script files to add executable when it is in the src folder rebuilding all the the current packages when workspace to the running the ROS workspace catkin_make path. command. Here’s A typical workspace layout  Create a folder for your workspace Create ( give your folder a name representable of your application ) So How to Create Create another folder inside the first name and give it the name "src" create a ROS Initialize the workspace using the Workspace? Initialize command catkin_init_workspce ! Go back to the main folder and build Go back your workspace using catkin_make Add the workspace environment. i.e. you must set the workspace path so Add that the packages inside the workspace become accessible and visible. $ mkdir ~//src $ cd ~//src $ catkin_init_workspace $ cd.. $ catkin_make $ source ~//devel/setup.bash ROS Packages What is ROS ROS software is organized into packages, each of which contains packages?! some combination of code, data, and documentation. The ROS package is where ROS nodes are organized—libraries and so forth How to create a ROS package?! $ catkin_create_pkg ros_package_name package_dependencies Note make sure you are at the source file when you creating your packages So what is the purpose of these files?! has all the commands to build the ROS CMakeLists.tx source code inside the package and t: create the executable. An XML file mainly contains the package package.xml: dependencies, information,..etc. src: Contains the source code of ROS package. include: contains the package header files. ROS Client Libraries  The ROS client libraries are a collection of code with functions to implement ROS concepts. We can simply include these library functions in our code to make it a ROS node. What are The client library saves development ROS Client time because it provides the built-in functions to make a ROS application. libraries Think of it as c++ libraries that you include using the command #include at the beginning of your source code to use c++ functions such cout and cin  1 Roscp ROS client library for C++. It is widely used for developing ROS : p: applications because of its high performance. Main ROS 2 Rospy the ROS client library for Python Advantages: Saving development time. Client ideal for quick prototyping Library : : applications Disadvantage: performance is weaker than with roscpp 3 the ROS client library of the Roslis Lisp language. It is mainly used in motion planning : p: libraries on ROS it is not as popular as roscpp and rospy.  Include the header files and modules used in ROS nodes. Creating How to initialize a ROS ROS Nodes node. How to publish and to subscribe a topic. 1: Header Files and C++THE FIRST PYTHON  THE FIRST ROS SECTION INCLUDES SECTION IMPORTS THE HEADER FILES PYTHON MODULES Modules Example: To create a ROS In Python, we have to C++ node, we have to import modules to create include the following a ROS node. The ROS header files. module that we need to #include "ros/ros.h" import is: The ros.h has all the import rospy headers required to implement ROS functionalities.  ROS Header files and Modules ROS message header: std_msgs: is a ROS Package that has a message definition of standard data types, such as int, float, string, and so forth. #include "std_msgs/String.h" # include "std_msgs/Int32.h" # include "std_msgs/Int64.h" If there is a custom message type, we can call it with the following syntax: # include "msg_pkg_name/message_name.h" NOTE: The complete list of message types inside the std_msgs package is at http://wiki.ros.org/std_msgs. For python: rospy has all the important ROS functions. To import a message type, we must import the specific modules, like we did in C++. The following is an example of importing a string message type in Python. from std_msgs.msg import String 2: Initializing a ROS Node This is a mandatory step in any ROS node. In C++, we initialize using the following line of code: int main(int argc, char **argv) { ros::init(argc, argv, "name_of_node")..................... } Meanwhile In Python, we use the following line of code: rospy.init_node('name_of_node', anonymous=True); Printing Messages in a ROS Node ROS_INFO(string_msg,args): Logging the information of node ROS_WARN(string_msg,args): Logging warning of the node ROS_DEBUG(string_msg ,args): Logging debug messages ROS_ERROR(string_msg ,args): Logging error messages ROS_FATAL(string_msg ,args): Logging Fatal messages Ex: ROS_DEBUG("Hello %s","World"); Creating ROS Node Handler After initializing the node, we have to create a NodeHandle instance that starts the ROS node and other operations, like publishing/subscribing a topic. We are using the ros::NodeHandle instance to create those operations. In C++, the following shows how to create an instance of ros::NodeHandle. ros::NodeHandle nh; The rest of the operations in the node use the nh instance. In Python, we don’t need to create a handle; the rospy module internally handles it. Hello World Example Steps to build the program I. Creating the workspace II. Creating a hello_world Package III. Creating a ROS C++ Node IV. Editing the CMakeLists.txt File V. Building C++ Nodes VI. Executing C++ Nodes 1. Creating the workspace $mkdir –p ~/myHello/src $cd ~/myHello/src $catkin_init_workspace $cd.. $catkin_make 2. Creating a hello_world Package $ cd ~/myHello/src $ myHello/src $ catkin_create_package hello_world roscpp rospy std_msgs Package.xml is package.xml. As discussed, this file has information about the package and its dependencies You can edit this file and add dependencies, package information, and other information to the package CMakeLists.txt The find_package() finds the necessary dependencies of this package. If these packages are not available, we can’t able to build this package. The catkin_package() is a catkin- provide CMake macro used for specifying catkin-specific information to the build system. 3. Creating a ROS C++ Node The application can be divided into two nodes. The first Node Is the talker node which is responsible of creating the message “Hello World” The second node is the listener node which will subscribe to the talker topic and thus receive the messages sent by the talker node through it Creating a ROS C++ Node | Publisher Node Go to the src node and create a C++ file name it “talker.cpp” #include "ros/ros.h" with the followingwhile code:(ros::ok()) { #include "std_msgs/String.h" std_msgs::String msg; #include std::stringstream ss; int main(int argc, char **argv) ss