I want to create a ROS publisher node outside a catkin workspace.
Can it be created?
Of course you can. Treat ROS like any other cpp library or python package.
In python you have to keep PYTHONPATH environment variable pointing to ros packages in /opt/ros/kinetic/lib/python2.7/dist-packages.
In cpp you have to tell compiler where to look for includes (/opt/ros/kinetic/include), libraries (/opt/ros/kinetic/lib) and which library to import. For the simplest application -lroscpp -lrostime -lrosconsole should be sufficient. Ex:
g++ node.cpp -o node -I/opt/ros/kinetic/include -L/opt/ros/kinetic/lib -lroscpp -lrostime -lrosconsole
Remember that you still need ros environment variables like ROS_MASTER_URI.
However, I don't know if there is an easy way to generate custom ros messages without using catkin_make and cmake files.
Yes, in Python, you can write ROS nodes outside your catkin workspace.
Launch your roscore and then run the Python script in a new terminal normally like python filename and it runs as it would if you had placed in inside your catkin workspace and built and sourced it.
I have successfully created subscriber and publisher nodes and run them on an actual TurtleBot2 without the nodes being inside the catkin workspace.
I don't think the method I have described works for C++. It only works for Python. In C++ you will have to link the libraries while compiling. So, check that. For example, we do g++ filename.cpp -lm, where -lm links the math library to be used in the filename.cpp, so you might need to check how to do that. On the other hand, it is easier to just add the file in your catkin workspace or just shift to Python.
You have to include ros/ros.h and std_msgs/message_name.h where message_name is replaced by whatever message you're using in code. You might find these files somewhere or you can get the source code of the files online by searching.
Related
I need to use bazel to manage our the source dependencies such that the final build product is purely a function of the toolchain, a vanishingly small number of files from the linux-distribution, and the source code itself. This means building things like libz, libssl, libcrypto, libcurl...
These dependences depend on each other
They have their own native (mostly autotools based) build systems, based on something like ./configure --prefix=foo && make -j && make install.
It seems to me that Bazel is not well suited to this use case. In particular, we need to manually recreate the make install step for each library, in order to copy make install artifacts out of execroot. It's unclear to me how the next dependency reuses the products. So, for example, when building zlib, we produce libz.a, and a bunch of header files. Then, when building libcrypto.a, we need to modify CPPFLAGS and LDFLAGS to point to the zlib "installation".
This strikes me as so pedantic that it's begging for code generation to generate the BUILD files.
Is there an alternative approach that doesn't require bespoke copying the "make install" logic into a genrule?
Take a look at rules_foreign_cc (https://github.com/bazelbuild/rules_foreign_cc). This contains rules for integrating with foreign build systems (make, autotools+make, cmake, etc.).
py_binary finally generates an executable file or an alias for a py script? What are its benefits? If it is an executable file, it will lose the meaning of python.
Making something executable can be just adding a chmod +x and slapping a #!/foo/bar line on top, the thing itself is still whatever interpreter code it was before.
In the case of bazel, it will add a wrapper script that will set up an execution environment before dispatching to the Python code. Consider e.g. Bazel's runfiles, but also other py_library targets.
In addition, you can use the target in places where an executable is required as attribute for another target. A single Python file doesn't have any dependencies Bazel knows about, so that would technically fit there but would not integrate well with Bazel.
I have made a ROS workspace and inside a package.
I did catkin_make and everything is working well.
I would like to give this package (or should I give the entire workspace?) to another person.
I am thinking to give him a zip file of the files and folders (it contains launch files, python scripts, rviz files etc) so I am expecting he will unzip it in his machine
I would like he can run the launch files without problems
What is what he needs to do for this? (of course he will have ROS installed, that is no problem)
I am thinking perhaps he should do source devel/setup.bash but is this enough?
When sharing a workspace with somebody only the source space src has to be shared. It should contain all our packages with their launch files (*.launch), Python (*.py) and C++ nodes (*.cpp, *.hpp), YAML configuration files (*.yaml), RViz configurations (*.rviz), robot descriptions (*.urdf, *.xacro) and describe how each node should be compiled in a CMakeLists.txt. Additionally you are supposed to keep track of all the Debian packages you install inside the package.xml file of each package.
If for some obscure reason there are things that I have to do that can't be accommodated in the standard installation instructions given above, I will actually write a bash script that performs these steps for me and add it either to the package itself or the workspace. This way I can automate also more complex steps such as installing OpenCV or modifying the .bashrc. Here a small example of what such a minimal script (I generally name them install_dependencies.sh) might look like:
#!/bin/bash
# Get current workspace
WS_DIR="$(dirname "$(dirname "$(readlink -fm "$0")")")"
# Check if script is run as root '$ sudo ...'
if ["$EUID" -ne 0]
then
echo "Error: This script has to be run as root '$ sudo ./install_dependencies.sh'
exit 1
fi
echo "Installing dependencies..."
# Modify .bashrc
echo "- Modifying '~/.bashrc'..."
echo "source ${WS_DIR}/devel/setup.bash" >> ~/.bashrc
echo ""
echo "Dependencies installed."
If for some reason even that is not possible I make always sure to document it properly either in a Markdown *.md read-me either in a /doc folder inside your package, in the read-me.md inside the base folder of your repository or inside the root folder of your workspace.
The receiver then only has to
Create a new workspace
Copy or clone the package files to its src folder
Install all the Debian package dependencies listed in the package.xml files with $ rosdep install
(If any: Execute the bash scripts I created by hand $ sudo ./install_dependencies.sh or perform the steps given in the documentation)
Build the workspace with $ catkin_make or $ catkin build from catkin-tools
Source the current environment variables with $ source devel/setup.bash
Make sure that the Python nodes are executable either by $ chmod +x <filename> or right-clicking the corresponding Python nodes (located in src or scripts of your package), selecting Properties/Permissions and enabling Allow executing file as program.
Run the desired Python or C++ nodes ($ rosrun <package_name> <executable_name>) and launch files ($ roslaunch <package_name> <launch_file_name>)
It is up to you to share the code as a compressed file, in form of a Git repository or a more advanced way (see below) but I will introduce some best practices in the following paragraphs that will pay off in the long run with larger packages.
Sharing a package or sharing a workspace?
One can either share a single package or an entire workspace. I personally think that most of the time one should share the entire workspace instead of the package alone even if you only cloned the other packages from a public Github repo. This might save the receiver a lot of headache e.g. when checking out the wrong branch.
Version control with Git
Arguably the best way to arrange your packages is by using Git. I'd actually make a repository for every package you create (if a couple of packages are virtually inseparable you can also bundled them to a single Git repo or better use metapackages). Then create an additional repository for your workspace and include your own packages and packages from other sources as submodules. This allows your code to be modular and re-usable: You can share only a package or the entire workspace!
As a first step I always add a .gitignore file to each package repository which excludes *.pyc files and another one to the workspace repository that ignores the build, devel and install folders.
You can add a particular repository as submodule to your workspace Git repository by opening a console inside the src folder of your workspace repository and typing
$ git submodule add -b <branch_name> <git_url_to_package> <optional_directory_rename>
Note that you can actually track a particular branch of a repository that you include as a submodule. In case you need a submodule at some point follow this guide.
If you share the workspace repository with someone they will have to have access to each individual submodule repository and they will have to not only pull the repository but also update the submodules with
$ git clone --recurse-submodules <git_url_to_workspace_repository>
and potentially update them to the latest commit with
$ git submodule update --remote
After these two steps they should have a full version of the repository with submodules and they should be able to progress with the steps listed in the section above.
1.1 Unit-testing and continuous integration
Before sharing a repository you will have to verify that everything is working correctly. This can take a decent amount of time, in particular if the code base is large and you are modifying it frequently. In the ideal case you would have to install it on a brand new machine or inside a virtual box in order to make sure that the set-up works which would take quite some time. This is where unit testing comes into play: For every class and function you program you will write a test. This way you can simply run these tests and make sure everything is working correctly. Generally these unit tests will be performed automatically and the working branches merged continuously. Generally the test routines are written with the libraries Boost::Test (C++), GoogleTest (generally used in ROS with C++), unittest (for Python) and QtTest (for GUIs). For ROS launch files there is additionally rostest. How this can be done in ROS is described here and here.
ROSjects
If you do not even want the person you are sending the code to to go through the hassle to set it up you might consider sending them a ROSject. A ROSject is an online virtual ROS environment (by the guys behind The Construct, the main source of ROS courses and of ROS tutorials on Youtube) that can be created and shared very easily from your existing Git repository as can be seen here. The simulation runs entirely in the cloud on a virtual machine. This way the potential of failure is very low but it is not a choice if your code is supposed to run on hardware and not only in simulation.
Docker
If your installation procedure is complex you might as well use a container such as a Docker.
More information about using Docker in combination with ROS can be found here. The Docker container might introduce though a bit of overhead and it is probably no choice for code which should have real-time priority in combination with a real-time patched operating system.
Debian or snap package
Another way of sending somebody a ROS package is by packing it into a Debian or snap package. This process takes a while and is in particular favourable if you want to give your code to a large number of users that should use the code out of the box. Instructions on how this can be done for Debian packages can be found here and here, while a guide for snap can be found here.
I am new to ROS, now I am taking over one old ROS workspace which is really disordered, it is almost impossilbe for me to fix all compile errors in short time, so I created one new ROS workspace, then copy some related packages(folders) from old ROS workspace to my new workspace as a baseline. then I did below steps:
1, source /opt/ros/$version/setup.bash
2, then echo $ROS_PACKAGE_PATH. --it is so good, only /opt/ros/$version some built-in packages are involved in ROS_PACKAGE_PATH
3，in my new workspace/devel, run source setup.bash. --now something I am not sure/understand happens
after step #3, ROS_PACKAGE_PATH included ROS build-in pacakge, old workspace and my new workspace, and when I type 'catkin build $nodename' in my new workspace, some dependencies from old workspace involved
and still causing issue. my way of copying ROS node is OK or not? what is proper way to create my subset workspace. really appreciate
It is related to workspace overlaying. Here it goes an official reference: (http://wiki.ros.org/catkin/Tutorials/workspace_overlaying)
Why does it happen?
The thing is that, as #JWCS mentioned, you might have the old workspace in your ~/.bashrc file at the moment you have compiled the new_workspace. (Check item 3 of the reference: Chaining catkin workspaces)
How to get rid of it?
Even if you remove it from ~/.bashrc it will keep appearing on $ROS_PACKAGE_PATH, because you have compiled your new_workspace with the old_workspace on the $ROS_PACKAGE_PATH.
The compilation process takes the current $ROS_PACKAEGE_PATH into account and "attach" it to the workspace you are compiling.
Solution
Go to your new_workspace: cd ~/new_workspace
Remove build and devel folders: rm -rf build devel
Source only the ROS installation folder: source /opt/ros/<distro>/setup.bash
Check your $ROS_PACKAGE_PATH, it will contain only the ROS distro installation path
Recompile your new workspace: catkin_make
Source your new workspace: source ~/new_workspace/devel/setup.bash
Check your $ROS_PACKAGE_PATH, it will contain /opt/ros/<distro> + new_workspace
About ~/.bashrc
You can keep the old_workspace source, since you have the new_workspace source just after that. It will not consider the old anymore. But for the sake of simplicity and organization, I recommend you to keep in your .bashrc file only the workspaces you are working on.
Hope it can help you!
Regards
Two things to check. First of all, make sure that you're not sourcing the old repo in your ~/.bashrc. It's common practice to source /opt/ros/VERSION/setup.bash in the bashrc, and when you only have one workspace, to also source ~/MY_WS/devel/setup.bash.
Second, if you already sourced the old workspace, you should just close the terminal before sourcing the new one, otherwise the old one will show up.
As for your method, of cleaning up a workspace, that's a good method. I would start moving one package at a time from the old workspace to the new one, and building everything each time. If you look at the package CMakeLists.txt/package.xml, all the dependencies should be listed. Make sure, if they're from the old workspace, that you copy them over. That should reduce your problems. If there is a package that is truly broken, you'll be able to find and isolate it quickly.
As suggested by JWCS, the best thing you can do is to move one package at a time from the old workspace to the new workspace and recompile it every time, and verify if your CMakelist is the same as the old one.
As for the third step I will use catkin_make to compile the packages.
I'm using a CMake build in a Jenkins environment and want to build the protobuf compiler from source.
This all works but in the next step I'm trying to use the compiler to translate my proto files which doesn't work, cause it cannot find it's own shared objects. I've tried defining the search path in the CMakeLists.txt file but it won't detect the shared object location in my repository tree $PRJ_MIDDLEWARE/protobuf/lib. I've tried telling cmake or the system where to search by defining:
set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "$ENV{PRJ_MIDDLEWARE}/protobuf/lib")
set(ENV{LD_LIBRARY_PATH} "$ENV{PRJ_MIDDLEWARE}/protobuf/lib:$ENV{LD_LIBRARY_PATH}")
But it always fails when trying to invoke the protoc compiler I just build. I tried invoking ´´ldconfig´´ from CMake but that doesn't work cause the jenkins user doesn't have the right to do this. Currently my only solution is to login to the build server an do this manually as root. But that is not how I want to do this... the next release moves to a new directory—this has to be done again. Do I have other options? Preferably directly from CMake, from Jenkins or maybe even Protocol Buffers?
Thank you
Two ideas come to mind:
Build protobuf compiler as a static binary (I don't know if that's possible but it usually is.)
Set LD_LIBRARY_PATH environment variable before invoking cmake to point to the location of protoc shared libraries.