Skip to content

Latest commit

 

History

History
350 lines (224 loc) · 10.5 KB

W1-ROS-Essentials.md

File metadata and controls

350 lines (224 loc) · 10.5 KB
Raw

Week 1 - ROS Essentials

Setup ROS Environment

$ source <path_to_ROS_workspace>/devel/setup.bash

or we can add the syntax to ~/.bashrc, so we dont neet to source every terminal.

ROS Node

Publish data or subsribe data or both of them.

List currenty running nodes

$ rosnode list

Visual representation of the ROS "node graph"

$ rqt_graph

Node spesific information

$ rosnode info /<node_name>

Question

Are sensors an example of a ROS node, or ROS topic?

Think of the block diagram from the lecture video!

Answer : Node

This is correct, because a sensor processes information and then provides data. It does not transport it between nodes.

ROS Topic

Transport information between nodes.

List all topics

 $ rostopic list

Get spesific topic information

 $ rostopic info /<topic_name>

Get running message in topic

 $ rostopic echo /<topic_name>

Question

Nodes and topics together form the backbone of any ROS application. It is important to know how they work together!

How many nodes can publish to a single topic? Answer : Any number of nodes can publish, as long as the message has the right type.

ROS application introduction

There are four fundamental types of ROS nodes that can be used to build a ROS application:

  • Publishers
  • Subscribers
  • Services
  • Actions

Please keep in mind, that here we refer to Services and Actions as fundamental types of nodes. That is, we are referring to nodes that use services and actions for communication. Publishers, Subscribers, Services and Actions are used by ROS nodes to communicate between each other.

Publisher Node

Publish processed information to a topic.

# define publisher
pub = rospy.Publish(<topic_name>, <msg_type>, queue_size=10)

# send msg using that publihser
pub.publish(<msg_data>)

Subscriber Node

Subscribe to information in a topic.

uses "topic callbacks function" to process received information.

rospy.Subscribe(<topic_name>, <msg_type>, callback_function)

ROS File system

ROS workspace - catkin workspace

is a folder to organize ROS project files

catkin : a build toll that compiles source files to binaries in ROS workspace

  • src : our codes goes here, user playground
  • devel : setup files for ROS environment, generated by catkin
  • build : binary files that complies, generated by catkin
  • logs : logs files - debug

Catkin Command for build catkin workspace

caktin build

Warning!

If you independently follow the tutorials on ROS Wiki, you might come across the command catkin_make. That is different to what we use in our course which is catkin. Don't try and mix the two! They are not compatible.

how to install catkin build in ros noetic, as its just use catkin_make

$ sudo apt-get install python3-osrf-pycommon python3-catkin-tools

Create new catkin workspace

let say we need to create new workspace in ~/ros/new_ros_ws

make new folder

$ mkdir -p ~/ros/new_ros_ws/src

go to directory

$ cd ~/ros/new_ros_ws

source the ros setup, for example I use melodic,

$ source /opt/ros/melodic/setup.sh

init catkin

$ catkin init

build workspace

$ catkin build

source the setup.bash to the terminal or edit ~/.bashrc

$ source ~/ros/new_ros_ws/devel/setup.bash

Question

We will provide you with four statements. Please select the following statements that are TRUE.

There are two correct statements.

  1. A ROS workspace can be located anywhere in your home folder.
  2. A ROS workspace which uses catkin as its build tool is called a catkin workspace.

Correct:

A ROS workspace is just a folder on your Linux installation. The concept of a workspace is to only organize your ROS application development in one location. But, the workspace itself can reside anywhere in your home folder. When you use catkin as the build tool for your ROS workspace, it is called a catkin workspace. So, in essence a catkin workspace and ROS workspace are pretty much the same, just that catkin workspace is a bit explicit in saying what build tool you are using for the ROS workspace.

ROS Package

ROS packages reside in the "src" space.

Remember : only put ROS packages in the source space, if we are modifiying it. Not everything we need goes in a source space. let say we need a package, and just install the binary from apt-get install package-name.

What inside the package

.
├── CMakeLists.txt          # Indicate what folder we are in a ROS package
├── package.xml             # Indicate what folder we are in a ROS package
├── scripts                 # contains all Python scripts
├── src                     # contains all C++ source files
└── README.md

Create new ROS package in the source space

# move to src, create package.
$ catkin_create_pkg <new_package_name> <package_deps>

# example
$ catkin_create_pkg my_new_ros_package std_msgs

Install package dependencies

$ cd <path_to_folder_with_ROS_package(s)>
$ rosdep install <package_name>

We can also install all ROS package dependencies in one command:

$ cd <path_to_ros_ws>/src
$ rosdep install --from-paths . --ignore-src -y

Question

1/1 point (ungraded)

It is not mandatory to create a folder inside the "src" space of your catkin workspace which in turn contains all your ROS packages. For example, new_ros_ws/src/hrwros/hrwros_week1 where, only hrwros_week1 is the ROS package

Answer

Correct: Having a separate folder inside the src space is only for file organization sanity. It is not mandatory to create a "top-level" folder inside your catkin workspace that contains all your ROS packages. But, it is recommended practice.

ROS Message Types

In ROS, we can abstract these data structures as ROS message types. Common data structures in ROS are for example floats, integers, and strings.

to represent a position in 3D space we will need 3 floating point values: X, Y and Z. The derived message type will then be a struct of three floating point numbers:

{float x, float y, float z}.

there are common_msgs in ROS

  • Point message type
    • float x
    • float y
    • float z
  • PointStamped message type
    • time stamp
    • string reference_frame
    • float x
    • float y
    • float z
  • Pose message type
    • position
      • float x
      • float y
      • floatt z
    • orientation
      • float x
      • float y
      • float z
      • float w

How to make custom ROS message

Messages are defined in message files of a ROS application.

Messages files typically exist in a ROS package with the following name convention

<ros_package_name>/msg/<NewMessageType>.msg

Example: Ultrasound distance sensor.

We want to construct a new message type called UltrasonicSensor. It should contain:

A ROS message type for interfacing with distance sensors
A string containing the manufacturer name
An unsigned integer containing the sensor part number

We would create the following file: $HOME/hrwros_ws/src/hrwros/hrwros_msgs/msg/UltrasonicSensor.msg.

It will contain the following:

sensor_msgs/Range sensor_data
string maker_name
string sensor_type
uint32 part_number

We can see something really interesting here: We use an already derived message, sensor_msgs/Range, and simply add a string and an integer to it. So we can create new message types using already existing derived message types!

This idea of stacking is really useful in ROS, since you can easily re-use what already exists. So in the above example, the sensor_msgs/Range already contains everything we need from the range sensor itself, and we only add the maker name and the part number.

dont forget in CMakeLists.txt add the file name, in

add_message_files(
    ....
    UltrasonicSensor
)

ROS Services

ROS services implement these request-response type of communications. They consist of two message types: Example

# One for requesting data, and one for the response
# hrwros_msgs/srv/ConvertMetresToFeet.srv 

float64 measurement_metres # Request field
---                        # Demarcation between request and response
float64 measurement_feet   # Response field
bool succes

Services are defined in the same package as messages, in their own /srv folder.

Attention :

  • ROS services block the program flow.
  • Useful for designing sequential behaviors.
  • Desirable to have quickly executing computations in service callback.
  • No going back after a service call and wait until it's complete.

How to make Simple Service

Let's begin by sourcing our setup files, and navigate to our workspace msgs folder:

$ source $HOME/hrwros_ws/devel/setup.bash
$ roscd hrwros_msgs/

We can see the msg/ folder, but we just learned services are defined in the srv/ folder. So let's create that, and create our service file:

$ mkdir srv
$ cd srv
$ touch myConvertMetresToFeet.srv

Now our service file is created, we can start editing it. Remember, we first want the request message type, then a demarcation of three dashes, and then a response message type:

float64 distance_in_metres_req  # Request message: Distance in (m) to be converted to (ft)
---                             # Demarcation
float64 distance_in_feet_res    # Response message: Distance in (ft) after conversion
bool success_res                # Response message: Success or failure of conversion

Now, just like we did for messages, we add our new service to the CMakeLists.txt file in the hrwros_msgs/ folder. Note that services have their own section, after messages. Add the name of our new service definition file after the FILES entry. Don't forget the .srv file extension.

add_service_files(DIRECTORY srv
    FILES
    ConvertMetresToFeet.srv
    myConvertMetresToFeet.srv
)

Finish by building our service by running the

$ catkin build

Check service

$ rossrv show hrwros_msgs/myConvertMetresToFeet
$ rossrv show hrwros_msgs/myConvertMetresToFeet -r

Question

1/1 point (ungraded)

One place we can find client-server interactions is in the kitchen of a busy restaurant. The waiter will place the order with the kitchen, and after some time, the kitchen will provide the server with the requested dish.

Answer Correct:

  • A: This is true, because the waiter asks the kitchen to give him the correct dish.
  • C: This is true, because the waiter requests the correct dish with his order paper.
  • F: This is true, because the kitchen provides the waiter with the correct dish after the order is placed.