Dokumentation

The robotics is very fast growing and developing interdisciplinary branch of engineering. It is very important that robots can move and execute tasks safely, without damaging themselves and the others, self-collision is one of the crucial parts of this problem. A collision is highly complex event by itself and depends on geometry, composition and the dynamics of colliding objects. So we need to find a very easy and feasible approach within the internship. 

1. Intro

2. Set up 

     2.1  Python

     2.2 ROS

     2.3 Simulators

           2.3.1 Gazebo

           2.3.2 V-Rep

           2.3.3 Gaming Engines

3. Conclusion

4. See Also

1. Intro 

Robot Control Systems Generally

Here is an image of Roboto Control Systems formulated roughly. Our task is somewhere between Kinematics and Sensors. But Poppy doesn't have any sensors, but the angles of the motors, so we have to work only with the Kinematics. Collision detection is only a part of the motion planning so we need some kind of development set up that can help and fit with the others control modules like sensors and communication.  Since I only know the python and it is "the language of the machine learning" and there are a lot of frameworks like TensorFlow it makes sence to make it our primal development language. We need some kind of "glue" that can put our modules together and it is ROS. Robot Operating System is robotics middleware. Although ROS is not an operating system, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management. It is very handy and powerfull tool for us, but it requires, a lot knowledge about itself, that does not bring you closer to the problem solving. We need some simalating software as well. Within the internship I've tried out V-Rep, Gazebo couple of Gaming engines. 

2. Set Up

Read Poppy's software quickstart guide. Maybe your problem is already solved there. Install all the required packages from the guide.

2.1 Python

Python Installation: 

1.  Install python3.

2. Install pip.  pip is a package management system used to install and manage software packages written in Python.

3. Install venv.

Tip: If you use conda, delete it and use normal python, it won't work with ROS.

Tip: Change python2 to python3. 

1. $ alias python=python3

   
   

2. $ source ~/.bash_aliases or source ~/.bashrc

   
   

3. Installing UE4 here 

2.2 ROS 

Robot Operating System is robotics middleware. Although ROS is not an operating system, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management.

1. Install 
2. Tutorial 
3. RVIZ Tutorials. RVIz is a 3D visualizer for displaying sensor data and state information from ROS. Using rviz, you can visualize Baxter's current configuration on a virtual model of the robot. (Please watch the video on the website. It helps to understand how helpfull this tool is.)
4. Make familiar with the ft.
5. ETHZürich ROS course
   
   

This information can be usefull: 

Everytime you start the terminal:

$ cd ~/<your_working_space>
$ source devel/setup.bash
$ roscd <working_folder>

ROS Packages

For rosbuild, see: rosbuild/Packages

Software in ROS is organized in packages. A package might contain ROS nodes, a ROS-independent library, a dataset, configuration files, a third-party piece of software, or anything else that logically constitutes a useful module. The goal of these packages it to provide this useful functionality in an easy-to-consume manner so that software can be easily reused. In general, ROS packages follow a "Goldilocks" principle: enough functionality to be useful, but not too much that the package is heavyweight and difficult to use from other software.

Packages are easy to create by hand or with tools like catkin_create_pkg. A ROS package is simply a directory descended from ROS_PACKAGE_PATH (see ROS Environment Variables) that has a package.xml file in it. Packages are the most atomic unit of build and the unit of release. This means that a package is the smallest individual thing you can build in ROS and it is the way software is bundled for release (meaning, for example, there is one debian package for each ROS package), respectively.

Command line tools

Packages are a very central concept to how files in ROS are organized, so there are quite a few tools in ROS that help you manage them. This includes:

• rospack: find and retrieve information about packages

• catkin_create_pkg: create a new package

• catkin_make: build a workspace of packages

• rosdep: install system dependencies of a package

• rqt: In rqt there is a plugin called "Introspection/Package Graph", which visualizes package dependencies as a graph

There are also extensions to common Unix shells that provide additional functionality to help you navigate and use packages. The most commonly used of these is rosbash, which provides ROS-variants of common Unix shell commands. The most commonly used of these is roscd, which performs a cd to the directory of a package, e.g.

roscore 

roscore is a collection of nodes and programs that are pre-requisites of a ROS-based system. You must have a roscore running in order for ROS nodes to communicate. It is launched using the roscore command.

NOTE: If you use roslaunch, it will automatically start roscore if it detects that it is not already running.

roscore will start up:

• a ROS Master

• a ROS Parameter Server

• a rosout logging node

ROS Nodes

A node is a process that performs computation. Nodes are combined together into a graph and communicate with one another using streaming topics, RPC services, and the Parameter Server. These nodes are meant to operate at a fine-grained scale; a robot control system will usually comprise many nodes. For example, one node controls a laser range-finder, one Node controls the robot's wheel motors, one node performs localization, one node performs path planning, one node provide a graphical view of the system, and so on.

The use of nodes in ROS provides several benefits to the overall system. There is additional fault tolerance as crashes are isolated to individual nodes. Code complexity is reduced in comparison to monolithic systems. Implementation details are also well hidden as the nodes expose a minimal API to the rest of the graph and alternate implementations, even in other programming languages, can easily be substituted.

All running nodes have a graph resource name that uniquely identifies them to the rest of the system. For example, /hokuyo_node could be the name of a Hokuyo driver broadcasting laser scans. Nodes also have a node type, that simplifies the process of referring to a node executable on the fileystem. These node types are package resource nameswith the name of the node's package and the name of the node executable file. In order to resolve a node type, ROS searches for all executables in the package with the specified name and chooses the first that it finds. As such, you need to be careful and not produce different executables with the same name in the same package.

$ rosnode ping <node name>

to make node executable: 

$ chmod +x listener.py

to show see the active nodes list: 

$ rosnode list

$ roslaunch 

roslaunch is a tool for easily launching multiple ROS nodes locally and remotely via SSH, as well as setting parameters on the Parameter Server. It includes options to automatically respawn processes that have already died. roslaunch takes in one or more XML configuration files (with the .launch extension) that specify the parameters to set and nodes to launch, as well as the machines that they should be run on.

ROS Messages

 Nodes communicate with each other by publishing messages to topics. 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).

There are two file types: 

msg: msg files are simple text files that describe the fields of a ROS message. They are used to generate source code for messages in different languages.

srv: an srv file describes a service. It is composed of two parts: a request and a response.

rosmsg is a command-line tool for displaying information about ROS Message types.

to see the topics message: 

$ rostopic echo <topic>

rosmsg show Show message description
rosmsg info Alias for rosmsg show
rosmsg list List all messages
rosmsg md5 Display message md5sum
rosmsg package List messages in a package
rosmsg packages List packages that contain messages

ROS Parameter Server

A parameter server is a shared, multi-variate dictionary that is accessible via network APIs. Nodes use this server to store and retrieve parameters at runtime. As it is not designed for high-performance, it is best used for static, non-binary data such as configuration parameters.

rosparam allows you to store and manipulate data on the ROS Parameter Server.

rosparam set            set parameter
rosparam get            get parameter
rosparam load           load parameters from file
rosparam dump           dump parameters to file
rosparam delete         delete parameter
rosparam list           list parameter names

ROS Topics & rostopic

Topics are named buses over which nodes exchange messages. Topics have anonymous publish/subscribe semantics, which decouples the production of information from its consumption. In general, nodes are not aware of who they are communicating with. Instead, nodes that are interested in data subscribe to the relevant topic; nodes that generate data publish to the relevant topic. There can be multiple publishers and subscribers to a topic.

rostopic contains the rostopic command-line tool for displaying debug information about ROS Topics, including publishers, subscribers, publishing rate, and ROS Messages. It also contains an experimental Python library for getting information about and interacting with topics dynamically. This library is for internal-use only as the code API may change, though it does provide examples of how to implement dynamic subscription and publication behaviors in ROS.

This is the current list of supported commands:

If you type  $ rostopic -h this will come up: 

rostopic bw     display bandwidth used by topic
rostopic delay display delay for topic which has header
rostopic echo   print messages to screen
rostopic find   find topics by type
rostopic hz     display publishing rate of topic
rostopic info   print information about active topic
rostopic list   print information about active topics
rostopic pub    publish data to topic
rostopic type   print topic type

works like: 

$rostopic bw /<topic_name>

$ rostopic -v    shows the topics and their type 

ROS Services

Services are another way that nodes can communicate with each other. Services allow nodes to send a request and receive a response.

rosservice list         print information about active services
rosservice call         call the service with the provided args
rosservice type         print service type
rosservice find         find services by service type
rosservice uri          print service ROSRPC uri

Topics vs. Services vs. Actionlib

• Topics are for continuous data flow. Data might be published and subscribed at any time independent of any senders/receivers. Many to many connection. Callbacks receive data once it is available. The publisher decides when data is sent.
• Services should be used for remote procedure calls that terminate quickly, for querying the state of a node or doing a quick calculation such as IK. Simple blocking call. Mostly used for comparably fast tasks as requesting specific data. Semantically for processing requests.

$ rosbag (To record your data)

$ rosbag record -a

to record data in a bagfiles folder in a bag file  from all published topics   (-a is for all topics)

$  rosbag info <your bagfile>

this command checks the contents of the bag file without playing it back.

$ rosbag play <your bagfile>

this command replays what you have recorded in a bagfiles

$ roscd

$roswtf to checkl everything

Other usefull commands: 

$ rosrun 

rosrun allows you to run an executable in an arbitrary package from anywhere without having to give its full path or cd/roscd there first.

$ rosrun <package> <executable>

$ rosrun rqt_graph rqt_graph

to see the graphical representation of subscriber and publisher nodes and the topic they communicate through 

$ rosed [package_name] [filename]

to edit the files, it will use vim, 

Install vim .

2.3 Simulators

We need a simulator to test our code and run the scenes. During my internship I've tested two simulators: Vrep and Gazebo. You can get the detailed comparison of these two simulators here. Here is the different physics engine comparison.

2.3.1 Gazebo

Gazebo has very good step by step tutorials that very important to understamding ROS nodes controll over the simulation. You can use Python or C++.

The problem is that you can't manipulate the meshes, software makes PC very hot and it freezes. Even if you run the empty world it takes a lot of computational power. 

To install Gazebo. Gazebo Tutorials.

2.3.2 V-REP

V-Rep is theoretically compatible with ROS, but not all versions. My version on ubntu LTS 16 and ROS kinetic wasn't.  Here is the V-Rep manual.

1. Download the V-REP simulator EDU version.
2. To start V-Rep: got to the vrep folder and then: $ ./vrep.sh
3. How to connect ROS and V-Rep:
   

   1. $ sudo apt-get install ros-kinetic-brics-actuator
      $ sudo apt-get install ros-kinetic-pointcloud-to-laserscan

      $ sudo apt-get install xsltproc

      3.1.Install ROS kinetic and the V-Rep Stubs generator's required software:

      $ sudo apt-get install -y ros-kinetic-desktop-full git cmake python-tempita python-catkin-tools python-lxml

      3.2.Clone the V-REP Stubs generator repository in the directory of your choice

      $ git clone -q https://github.com/CoppeliaRobotics/v_repStubsGen.git

      3.3. Add its path to the search path for importing python modules

      $ export  PYTHONPATH=$PYTHONPATH:$PWD

      3.4.Create a temporary catking workspace 

      $ mkdir -p /tmp/quickstart_ws/src

      3.5.Initialize this workspace 

      $ cd /tmp/quickstart_ws

      $catkin init

      3.6.Clone & build the ROSInterface in this workspace

      $ cd src/

      $ git clone https://github.com/CoppeliaRobotics/v_repExtRosInterface.git

      $ git clone https://github.com/CoppeliaRobotics/vrep_skeleton_msg_and_srv.git

      $ git clone https://github.com/CoppeliaRobotics/vrep_plugin_skeleton.git
      

      $ catkin build 

      At this point you may get some issueses with the packages. just install them. 

      And you may get this problem: 

      Cannot find V-REP installation. Please set the VREP_ROOT environment
      variable to point to the root of your V-REP installation.

      go to your .bashrc file  

      $ gedit .bashrc

      and paste :                  export VREP_ROOT="home/<username>/<yourpathtothevarepfolder>/<nameofyourvrepfolder>"

      you can check if the VREP_ROOT has the right path with command:

      $ echo VREP_ROOT

      after all of this steps try to: 

      $ catkin build 

      3.7. now we have "plugins" for the V-REP

      3.8.Check that the resulting vrep-ros library is in the devel folder 

      $ cd ../devel/lib/

      $ ls 

      You should see a liabrary called "libv_repExtRosInterface.so" and libv_repExtRosSkeleton.so

      3.9.Source the workspace

      $ cd ../..

      $ source devel/setup.bash 

      3.10. Copy your liabraries in your V-REP installation folder:

      $ cp -iv devel/lib/libv_repExtRosInterface.so "$VREP_ROOT/"

      $ cp -iv devel/lib/libv_repExtRosSkeleton.so "$VREP_ROOT/"

      3.11. Now it you can try: 

      $ roscore 

      in new terminal open V-REP folder: 

      $ ./vrep.sh 

      you can check that with: 

      $ rostopic list 

      or 

      $ rosrun rqt_graph rqt_graph 
      
      

4. Controlling the model. You can controll scenes through ROS nodes or Remote API using the lagnuages as:  Lua, Matlab, Java, C/C++ and Python. As you know from the Poppy's software guide there already exists PyPot package. With Pypots help you can run simulation from the Rest API in V-Rep, running python script. You only need  this in your python script. 

   Controlling V-REP through python script Quelle erweitern

   import pypot.vrep
   
   poppy = pypot.vrep.from_vrep(config, vrep_host, vrep_port, vrep_scene)
   
   poppy.walk.start()

   
   This will start the Poppy Simulation scene. 
   I've tried to upload the URDF file directly, unfortunately the meshes load is  incorrect.(I've asked the coppelia robotics directly they don't have any solutions fdor that. They said that they will fix it in future versions.) The possible solution could be that we change the format from the URDF to SDF.  So it is not quet possible to controll the model from the ROS nodes.
   
   

      5. The Collision detection. 

       As shown above you can controll the Robot using the python script.  The collision detection dialog is part of the calculation module properties dialog, which is located at [Menu bar --> Tools --> Calculation module properties]. You can also open the dialog with a click on its toolbarbutton. There you can choose the links that you want to check for collision. In the same calculation modules you          can check for the minimum distance calculation.  You can also choose the specific colour. Now I did not figure out how to retrieve this data from the simulator.  

2.3.3 Gaming Engines 

WIthin the internship I've got the question "Why we can't use the gaming engines as the simulators?". The physics engines are "good enough". I've tried Unity, it is not easy to install to Linux, so I've moved on to Unreal Engine 4. Here is the detailed guide how to download, install and run the UE4 on Ubuntu. Theoretically you can build the worlds using gaming engines, and the future of the robot simulation not going to use only robots and the simple objects and their interaction, but the robot-world interaction. Here is the guide and github of UE4 and the ROS connection. It should connect ROS and UE4 through the rosbridge. At the end you should be able to connect the UE4 where you add ROS plugin. The problem is that you can't use Python, C++ only. Theoretically you can add the Python plugin, but it won't interact with our ROS plugin. 

The UE4 has very interesting plugin as UnrealCV. It is real time computer-vision liabrary, that has object recognition. Theoretically it can be the gamechanger. 

Here is some pictures todemonstrate of what they capable of.

The picture above is the result of UE4 and ROS from Google Summer of code.

3. Conclusion

In the end we didn't use the ROS, but  I think it is the future of the project since it has very helpfull packages for each modules listed above. We need to come to this project with more systematic approach, so all the old and the future Poppy projects at the university can be connected. The goal is that the robot can move and train in the simulation using ros, rviz and using detailed SDF model, knowing it actual  global and relative position using inverse and forward Kinematics. The gaming engines could become the future, but now they aren't so handy as the robotics simulators.

4. See Also

NVIDIA Research papers.

ETHZürich AnyMal Project

Kinematik und Robotik 1997 - Manfred Hust, Adolf Karger, Hans Sachs, Waldermar Steinhilper

Dateien

Schriftliche Ausarbeitung, Präsentation usw.