In today’s video we’re going to see what is tf view_frame and how it works.
Step 0. Create a project in Robot Ignite Academy(RIA)
We have the best online ROS course available in RIA. It helps you learn ROS in the easiest way without setting up ROS environment locally. The only thing you need is a browser! Create an account here and start to browse the trial course for free now! We’ll use the TF ROS 101 unit 4 as an example today.
Step 1. TF
To publish tf topic, you have to execute the following command in this example.
roslaunch pi_robot_pkg pi_robot_control.launch
Then check it with
rostopic echo /tf -n1
It will public all the coordinate frame available in the simulation, but it’s a mass.
We can also use RViz to visualize the TF by launching
rosrun rviz rviz
But it also looks not so nice.
It turns out the tf put the coordinate frames in a tree structure. You can run the following command to plot the tree.
rosrun tf view_frames
If you open the .pdf file it generated, you all see all the frames in tf and their relationship.
Want to learn more?
If you are new to ROS, I highly recommend you to take any of the following courses on Robot Ignite Academy:
In today’s video we’re going to see what is rqt_graph and how to use it.
Step 0. Create a project in Robot Ignite Academy(RIA)
We have the best online ROS course available in RIA. It helps you learn ROS in the easiest way without setting up ROS environment locally. The only thing you need is a browser! Create an account here and start to browse the trial course for free now! We’ll use the ROS in 5 Days unit 9 as an example today.
Step 1. rqt_graph
The rqt_graph is a debugging tool in ROS. To show how it works, we’ll create some node first. Please type the following command to create a publisher
This command will create a publisher node named new_pub which publishes the string type message: Welcome to ROSCon 2018 to the topic called /news.
Then we create a subscriber node named news_sub subscribes to the topic news
rostopic echo /news __name:=news_sub
You should see the subscriber prints out the message published by the news_pub node.
If you have some problem and you want to debug, then you can use the following tools:
rosnode list
This command prints out the name of all nodes.
You can see more detailed information with
rosnode info /news_sub
This command will show not only the name of the node but also the topic published of subscribed by this node.
The last one is
rqt_graph
This tool will plot the relationship between each node and the topics that they communicated with. In this example, if you’ve done correctly, you should see the /news_pub and /news_sub nodes and in between is the /news topic on the arrow.
Want to learn more?
If you are new to ROS, I highly recommend you to take any of the following courses on Robot Ignite Academy:
In this video, we’ll see what the roswtf tool is. We’ll also see how and why this tool is used in ROS.
Let’s go!
Step 0. Create a project in Robot Ignite Academy(RIA)
We have the best online ROS course available in RIA. It helps you learn ROS in the easiest way without setting up ROS environment locally. The only thing you need is a browser! Create an account here and start to browse the trial course for free now! We’ll use the TF ROS 101 unit 4 as an example today.
Step 1. roswtf
The roswtf is a debugging tool in ROS which helps you to find the problem in your simulation.
Let’s have some examples. In the terminal, please type
ROS_IP= roswtf
The roswtf will check the system statically and dynamically. The static errors(e.g. the compilation error) will be shown in the static checks summary part. The dynamic checks summary shows the error found while running the ROS graph with ROS master. Here you can see that the roswtf found that the ROS_IP is invalid because it’s an empty string!
Let’s try it one more time with
ROS_MASTER_URI=127.1.1.1 roswtf
This time you will get an error shows that the 127.1.1.1 is not a valid url.
In conclusion, the roswtf is a powerful debugging tool to help you debugging your ROS program.
Want to learn more?
If you are a ROS beginner and want to learn ROS basics fast, we recommend you take any of the following courses on Robot Ignite Academy:
In this post, we will see what the ROS workspace directories src, build and devel contain. We’ll also see how these directories are used in ROS workspace management.
Head to http://rosds.online and create a project called “ros workspace” (or whatever you wish). Please ensure you select “Ubuntu 16.04 + ROS Kinetic + Gazebo 7” under “Configuration”. Once done with that, open up the project by clicking on “Open ROSject”.
Step 2: Check out what we have in the catkin_ws workspace and save its current state in git
Pick a Shell tool from the Tools menu and locate the catkin_ws directory.
user:~$ cd catkin_ws/
user:~/catkin_ws$ ll
total 24
drwxrwxr-x 5 user user 4096 Jun 11 2018 ./
drwxrwxrwx 10 user user 4096 Dec 2 12:16 ../
-rw-rw-r-- 1 user user 98 Nov 17 2017 .catkin_workspace
drwxrwxr-x 7 user user 4096 Jun 11 2018 build/
drwxrwxr-x 3 user user 4096 Jun 11 2018 devel/
drwxrwxr-x 2 user user 4096 Nov 17 2017 src/
So we see that we have three subfolders in the workspace: src, build and devel. Now we are going to save the current state of that directory before we make further changes:
user:~/catkin_ws$ git init
Initialized empty Git repository in /home/user/catkin_ws/.git/
user:~/catkin_ws$ git add .
user:~/catkin_ws$ git commit -m "Initial workspace state"
[master (root-commit) d18311c] Initial workspace state
112 files changed, 7467 insertions(+)
create mode 100644 .catkin_workspace
...# truncated messages
user:~/catkin_ws$ git status
On branch master
nothing to commit, working tree clean
Step 3: Create a new package in the workspace and observe the changes
Take note that only the src folder has been changed here.
# We change the workspace's src folder and create a package.
user:~/catkin_ws$ cd src
user:~/catkin_ws/src$ catkin_create_pkg test_package rospy
Created file test_package/package.xml
Created file test_package/CMakeLists.txt
Created folder test_package/src
Successfully created files in /home/user/catkin_ws/src/test_package. Please adjust the values in package.xml.
# We change back to the workspace (catkin_ws) directory and see that we have new untracked files and directories.
# We commit them to git.
user:~/catkin_ws/src$ cd ..
user:~/catkin_ws$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
src/test_package/
nothing added to commit but untracked files present (use "git add" to track)
user:~/catkin_ws$ git add src/test_package/
user:~/catkin_ws$ git commit -m "Create a test package"
[master 13e3e91] Create a test package
2 files changed, 266 insertions(+)
create mode 100644 src/test_package/CMakeLists.txt
create mode 100644 src/test_package/package.xml
# We check the workspace folder again in git and see that it's "clean"
user:~/catkin_ws$ git status
On branch master
nothing to commit, working tree clean
user:~/catkin_ws$
Step 4: Compile the workspace and observe the changes
Now we will compile the workspace and see what happens.
# COMPILE THE WORKSPACE
user:~/catkin_ws$ catkin_make
Base path: /home/user/catkin_ws
Source space: /home/user/catkin_ws/src
Build space: /home/user/catkin_ws/build
Devel space: /home/user/catkin_ws/devel
Install space: /home/user/catkin_ws/install
####
#### Running command: "cmake /home/user/catkin_ws/src -DCATKIN_DEVEL_PREFIX=/home/user/catkin_ws/devel -DCMAKE_INSTALL_PREFIX=/home/user/catkin_ws/install -G Unix Makefiles" in "/home/user/catkin_ws/build"
####
#...lots of truncated messages
# CHECK THE WORKSPACE IN GIT
user:~/catkin_ws$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: build/CMakeCache.txt
modified: build/CMakeFiles/Makefile.cmake
modified: build/CMakeFiles/Makefile2
modified: build/CMakeFiles/TargetDirectories.txt
modified: build/CTestTestfile.cmake
modified: build/Makefile
modified: build/catkin/catkin_generated/version/package.cmake
modified: build/catkin_generated/generate_cached_setup.py
modified: build/catkin_generated/installspace/_setup_util.py
modified: build/catkin_generated/installspace/setup.sh
modified: build/catkin_generated/order_packages.cmake
modified: build/catkin_generated/order_packages.py
modified: build/catkin_generated/setup_cached.sh
modified: build/catkin_generated/stamps/Project/_setup_util.py.stamp
modified: build/catkin_generated/stamps/Project/package.xml.stamp
modified: build/catkin_make.cache
modified: build/cmake_install.cmake
modified: devel/_setup_util.py
modified: devel/setup.sh
Untracked files:
(use "git add <file>..." to include in what will be committed)
build/CTestConfiguration.ini
build/CTestCustom.cmake
build/atomic_configure/
build/catkin_generated/installspace/local_setup.bash
build/catkin_generated/installspace/local_setup.sh
build/catkin_generated/installspace/local_setup.zsh
build/test_package/
devel/cmake.lock
devel/lib/
devel/local_setup.bash
devel/local_setup.sh
devel/local_setup.zsh
devel/share/
no changes added to commit (use "git add" and/or "git commit -a")
Now we see that there a lot of modified and new files in both build and devel, (no) thanks to the command we just ran.
Let’s put it all together in the next step.
Step 5: Put it all together – translate the action into words
I strongly believe you already got some hints about the src, build and devel directories from the commands we ran in the steps above. Now let’s consolidate those hints:
src contains the source files for packages created. That’s why we created a package in this folder in Step 3.
we run cmake from build to build the packages in src. You can call it cmake‘s working directory. You’ll also notice that the bulk of modified files are in this direction after we ran catkin_make.
ROS places built files of the package in devel for development/testing. Yep, and that’s why most of the files in this directory after catkin_make are new.
Extra:install – this folder will be created if you compile with the command catkin_make install. Try it out!
And…that was it!
Extra: Video
Prefer to listen to the “sights and sounds” version of this post? We have one for you below; happy watching!
Further Learning
If you are a ROS beginner and want to learn ROS basics fast, we recommend you take any of the following courses on Robot Ignite Academy:
In order to work properly, ROS uses the setup.bash files, but what are those files? In today’s post, we’re going to learn what are setup.bash (or setup.sh) files, where are they located and how to use them.
Before we start, if you are new to ROS, I highly recommend you taking any of the following courses on Robot Ignite Academy:
Where the setup.bash and setup.sh files are located
In this post, we are going to use Robot Ignite Academy, but the commands used here could be executed in your own computer if you have ROS installed.
When you open a course on Robot Ignite Academy, you have among other things, the web shell, which we use to run our commands. By running ls ~/catkin_ws/devel/ we can see that among other files, we have setup.bash and setup.sh:
user:~$ ls ~/catkin_ws/devel/
_setup_util.py env.sh lib setup.bash setup.sh setup.zsh
Files with the same name can be found on /opt/ros/kinetic/ and /usr/share/gazebo-7 as can be seen with the commands ls /opt/ros/kinetic and ls /usr/share/gazebo-7.
user:~$ ls /opt/ros/kinetic/
_setup_util.py bin env.sh etc include lib setup.bash setup.sh setup.zsh share
user:~$
user:~$ ls /usr/share/gazebo-7/
media models setup.sh worlds
How the setup.bash files are used
The main function of these files is to set environment variables used by ROS and by the Gazebo simulator. If we look for variables with the ROS prefix with the command env | grep ROS, we will find them:
The ROS_PACKAGE_PATH variable, for example, is used by ROS to find ROS Packages. If we unset it with unset ROS_PACKAGE_PATH and try to enter to the image_common package with roscd image_common, for example, we will have an error message saying that the package was not found:
user:~$ roscd image_common
roscd: No such package/stack 'image_common'
If we source our setup.bash files again with source ~/catkin_ws/devel/setup.bash, we will be able to navigate to the image_common package because the ROS_PACKAGE_PATH will be set:
Just to make clear that the setup.bash and setup.sh files define variables used by ROS and Gazebo, let’s unset all variables with ROS and GAZEBO prefix with the commands below:
for var in $(env | grep ^GAZEBO| cut -d'=' -f1); do unset $var; done
for var in $(env | grep ^ROS| cut -d'=' -f1); do unset $var; done
We can confirm the variables were removed with the commands env | grep ^ROS and env | grep ^GAZEBO.
If we now source ~/catkin_ws/devel/setup.bash and source /usr/share/gazebo/setup.sh and check the variables again, we will see they were correctly set.
So, that is the post of today. Remember that below we also have a video showing everything described here. If you liked the post or the video, please leave your thoughts on the comments section of the video.