simon-t4's profile - activity

Hi

after using colcon build to compile Autoware 1.12 on Ubuntu 16.04 with ros kinetic , some times when running the script

 source autoware_dir/install/setup.bash

I receive an error that the packages are not found, and of therefore roslaunch or rosrun fails to find any nodes in the packages. The error is:

 user@locahost:~/autoware.ai$ source install/setup.bash
 not found: "/home/user/autoware.ai/install/adi_driver
 autoware_bag_tools
 autoware_build_flags
 autoware_can_msgs
 ..."

It turns out the problem is the way bash script tokenizes string variables (see below). My question is regarding the likely cause of the problem.

Question

Is it a problem with my environment? I may have messed up some environment variable or installed the wrong version of something. I would think if it is a problem with the colcon scripts themselves many other people would have similar problems.

Does anyone have any suggestions about what might be wrong?

I List the out put of various version info below.

EDIT: bash IFS is being overwritten by rosrun autocomplete. See below.

Cause of Problem

The error occurs because the script file install/local_setup.bash generates a list of package names which is a string with package names separated by (I think) line breaks. When the script then tries to add a prefix (path) to each package name, it treats the list of names as one single string.and of course can't find the file named after all packages. The relevant part of the script (install/local_setup.bash, from line 93) is

# get all packages in topological order                                                            
_colcon_ordered_packages="$($_colcon_python_executable "$_colcon_prefix_bash_COLCON_CURRENT_PREFIX_local_setup_util.py")"                                                                           
unset _colcon_python_executable                                                                    

# source package specific scripts in topological order                                             
for _colcon_package_name in $_colcon_ordered_packages; do                                          
      # setting COLCON_CURRENT_PREFIX avoids relying on the build time prefix of the sourced script    
     COLCON_CURRENT_PREFIX="${_colcon_prefix_bash_COLCON_CURRENT_PREFIX}/${_colcon_package_name}"     
     _colcon_prefix_bash_source_script "$COLCON_CURRENT_PREFIX/share/${_colcon_package_name}/package.bash"                                                                                              
done

The ordered package string generated by the python script is iterated over in the for loop. In this case the string _colcon_ordered_packages is not tokenised and only one giant string is processed within the loop.

Work Around

By using a while read -r _colcon_package_name; do .... done <<< "$_colcon_ordered_packages to iterate the string can be successfully tokenised and then sourced using the appropriate package.bash script

# source package specific scripts in topological order                                             
while read -r _colcon_package_name; do                                                                                                 
      # setting COLCON_CURRENT_PREFIX avoids relying on the build time prefix of the sourced script    
      COLCON_CURRENT_PREFIX="${_colcon_prefix_bash_COLCON_CURRENT_PREFIX}/${_colcon_package_name}"     
      _colcon_prefix_bash_source_script "$COLCON_CURRENT_PREFIX/share/${_colcon_package_name}/package.bash"                                                                                              
done <<< "$_colcon_ordered_packages"

Edit: fixed quotation marks

Edit: add

Persistent Work Around

Using _colcon_pthon_executable variable in above script, to find out what version of python colcon is using (in my case python3), and depending on what shell you are using (bash) edit the file :

 /usr/lib/python3/dist-packages/colcon_bash/shell/template/prefix.bash.em

This file is used by the colcon python module to generate the relevant part of install/local_setup.bash. Making the same change to the string tokenizer as above results in a workaround that will be persistent between builds.

Note: line numbers are slightly different in the ... (more)