flexbe_states: create symlink to behavior and state sources in installed package path
I had to add this cmake snippet to the flexbe_states package and also to all our custom state and behavior packages to fix an error message in the FlexBE App when running from install-space:
Setting up ROS connection...
Checking 257 ROS packages for states and behaviors...
ROS connection running!
Parsing sourcecode...
Code parsing completed.
Building behavior state machine...
Unable to find state definition for: CheckConditionState
Please check your workspace settings.
Unable to find state definition for: CalculationState
Please check your workspace settings.
Unable to find state definition for: FlexibleServiceCallerState
Please check your workspace settings.
Another alternative is to always install an additional copy of the src folder to the package dir (${CATKIN_PACKAGE_SHARE_DESTINATION}), independent of the files installed to lib/.
A better approach would be to patch the FlexBE App such that it can find the source code using python:
$ python -c 'import flexbe_states; print(flexbe_states.__path__)'
['/path/to/install/space/lib/python2.7/dist-packages/flexbe_states']
or relative to the package path:
$ echo $(rospack find flexbe_states)/../../lib/python2.7/dist-packages/flexbe_states
/path/to/install/space/share/flexbe_states/../../lib/python2.7/dist-packages/flexbe_states
But I don't know enough about JavaScript and the underlying mechanics to propose such a patch. The relevant code seems to be in src/io/io_packageparser.js.
It does not make sense to modify behaviors in an install-space or if the sources are not writable by the current user, e.g. because they are owned by root. But I assume the FlexBE App would still need to find the sources in order to only run a behavior. It would be a nice-to-have that the respective controls ("Statemachine Editor", "Save Behavior", ...) are disabled in those cases.
Thank you for looking into this!
I will check what to do best from the flexbe_app side to handle the case of installed packages.
I stumbled across the same problem just last week without seeing your bug report. I fixed it in our branch using a similar solution in the two commits: https://github.com/team-vigir/flexbe_behavior_engine/commit/5f89d83da708526e33efade9639ef093b8ffb01d https://github.com/team-vigir/flexbe_behavior_engine/commit/540b313b0960193999d28faeb2b25041ae622b42
PR for flexbe_app now also submitted: https://github.com/FlexBE/flexbe_app/pull/20
Thank you Dorian! I actually started an implementation of this in parallel last weekend. I will merge the two versions next weekend and then test everything together.
As suggested in the original PR, the following features have been added:
A better approach would be to patch the FlexBE App such that it can find the source code using python
It would be a nice-to-have that the respective controls ("Statemachine Editor", "Save Behavior", ...) are disabled in those cases.
@meyerj and @DorianScholz can you check flexbe_app@feature/install_support whether this addresses your requirements appropriately before I close this PR?
@meyerj and @DorianScholz can you check flexbe_app@feature/install_support whether this addresses your requirements appropriately before I close this PR?
Sorry, I am not using FlexBe at the moment and have no time to test the branch. I assume that you or @DorianScholz actually tested the approach, but I fear that catkin's special behavior to "link" Python packages to the devel-space using exec(fh.read()) in devel/lib/python2.7/dist-packages/<pkg>/__init__.py (created from init.py.in) could invalidate the approach of getPackagePythonPath() in ros.js. It always returns the package's Python folder in devel-space, but not the actual source-space that contains the editable source files:
$ python -c 'import imp; print(imp.find_module("my_python_pkg")[1])
/path/to/devel/lib/python2.7/dist-packages/my_python_pkg
instead of
/path/to/src/my_python_pkg/src/my_python_pkg
AFAIK there is no built-in way of finding back the actual source folder of a Python package from devel-space. What might work is to:
- import the module and check the value of
<module>.__path__, where the source-folder has been added to by catkin's init.py.in) - search for a line
__extended_path = '...'in<module>.__file__ - lookup the package path using
rospack find, relying on the fact that the Python and ROS package names are typically identical by convention - create a marker file pointing to the source path of the package in
${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_PYTHON_DESTINATION}(the virtual package path in devel-space)
We still cannot launch a behavior from install-space using the approach described at Running Behaviors Without Operator without this patch. I assume the be_launcher script still tries to find Python sources in the ROS_PACKAGE_PATH because it uses rospkg internally.
Probably that is what has been fixed by @DorianScholz in the patches referenced in https://github.com/team-vigir/flexbe_behavior_engine/pull/56#issuecomment-401634688?
In general I agree that patching flexbe_app and flexbe_onboard to not use the ROS_PACKAGE_PATH to locate package sources is much better than this symlink "hack".
@pschillinger What is the status of this issue in the ROS 1 at this point in time? Did this get resolved by other means?