Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install libmav_msgs.so #506

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

sloretz
Copy link

@sloretz sloretz commented Jun 20, 2018

All of the gazebo plugin targets depend on libmav_msgs.so. This PR makes sure that library gets installed so the gazebo plugins work from the install space.

Without this PR running roslaunch rotors_gazebo three_multicopters_hovering_example.launch with the install space sourced results in:

[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_multirotor_base_plugin.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_motor_model.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_motor_model.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_motor_model.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_motor_model.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_controller_interface.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_imu_plugin.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_imu_plugin.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_odometry_plugin.so: libmav_msgs.so: cannot open shared object file: No such file or directory
[Err] [Plugin.hh:180] Failed to load plugin librotors_gazebo_odometry_plugin.so: libmav_msgs.so: cannot open shared object 
file: No such file or directory

@ethzasl-jenkins
Copy link

Can one of the admins verify this patch?

@ffurrer
Copy link
Contributor

ffurrer commented Aug 28, 2018

ok to test

@ffurrer
Copy link
Contributor

ffurrer commented Aug 28, 2018

Should this not be fixed in mav_msgs?

@aeudes
Copy link

aeudes commented Apr 10, 2019

The last merge in master did not correct the #556 issue. @ffurrer or @michaelpantic could you consider merging this PR ? It's really annoying to not be able to use the package from the melodic ROS depot.

Thanks a lot.

@sloretz
Copy link
Author

sloretz commented Apr 10, 2019

Should this not be fixed in mav_msgs?

@ffurrer I don't think so. The library target is named mav_msgs, but does not come from mav_comm/mav_msgs. It is created here:

# Create a shared library of protobuf messages (.so extension on Linux platforms)
add_library(mav_msgs SHARED ${PROTO_SRCS})
target_link_libraries(mav_msgs ${PROTOBUF_LIBRARY} gazebo_msgs)
# This causes mav_msgs to be linked with every created library in this file from this
# point forward.
# NOTE: This is deprecated, should be using target_link_libraries instead
link_libraries(mav_msgs)

@michaelpantic
Copy link
Member

@aeudes Hm, are we talking about a build from source or a installation using apt-get here?

If its installed from source I can't really reproduce the problem (were having plenty of people running melodic and rotors). If its installed using apt-get, that will take some time to debug, and release.
The current melodic packages are still in a devel state, so I recommend you just use the source build.

@michaelpantic
Copy link
Member

Also, the ros melodic packages are not updated nearly as often as the source master.
E.g. the current ros melodic packages in the ros.org repos were built last time sometime in january.

@sloretz
Copy link
Author

sloretz commented Apr 10, 2019

If its installed from source I can't really reproduce the problem (were having plenty of people running melodic and rotors)

@michaelpantic I don't have a workspace at the moment, but when I faced this I was building from source. The problem happens when using the install space instead of devel space. Hopefully these commands are close to copy/pastable for you.

cd ~/my_catkin_ws
catkin_make_isolated --install-space ./install --install

then in another terminal

. ~/my_catkin_ws/install/setup.bash
roslaunch rotors_gazebo three_multicopters_hovering_example.launch

@michaelpantic
Copy link
Member

michaelpantic commented Apr 10, 2019

@sloretz Thanks a lot for that info! We actually never use the install space feature (or I never came across someone using it), that's why we never had that issue.

Before I merge this into master I'd like to test if it has any side effects in the updated build configuration for the different gazebo versions (we're supporting quite a few in parallel, which sometimes causes simple changes to break lots of builds), so that will take some time.
In any case I'll try to include that in an upcoming release, as it seems to be needed anyway. It might take quite some time to run through all the process and testing to get it running, so again, can't promise a timeline for when this actually finds its way into the binary ros packages that are easy to install.

@aeudes
Copy link

aeudes commented Apr 10, 2019

This issue is not visible if you built by source or if you install package on a machine where it was also compile by source. But on machine with only package, a library is missing. This library, contain the protobuf message that are used by rotors_gazebo_plugin and it is build in rotors gazebo plugin but not mark for installation.
To convince yourself that this PR is needing you could check that any gazebo plugin is linked to libmav_msgs.so :

ldd librotors_gazebo_motor_model.so
libmav_msgs.so => not found

and the lib is not present in install space (I am pretty sure that it is not present in devel space neither but only in build space but i have not a workspace right now) and it is not export to the package (you could check on the install file list of the package).

I don't have any problem with more testing/caution, and I aware for release cycle/delay on package. I just want to be sure that this issue is not ignored as it make the package unusable and it is not trivial to detect (worked if source are built on the machine and gazebo silently failed but did not load plugins).
You did a great worked by releasing the ROS package and it makes rotors installation painless for user that did not need to develop on rotors and it's that a pity if it is not usable. And at the moment, at our lab, we use packages and install by hand the missing library.

Let me know if I could provide more information or help.

@idlebear
Copy link

Hi there -- I had this problem as well when working from the install space. Either manually copying the library to ./install/lib or adding

list(APPEND targets_to_install mav_msgs)

appears to resolve it. For reference, I'm using the following to build/run:

catkin config --install
catkin build
source ./install/setup.bash
roslaunch rotors_gazebo three_multicopters_hovering_example.launch

@sloretz
Copy link
Author

sloretz commented Aug 28, 2019

Friendly poke, are there any changes that need to be made to this PR before it can be merged?

@gsilano
Copy link

gsilano commented Dec 17, 2019

Hi all! I'm working to make compatible my two ROS packages, CrazyS and BebopS (they use RotorS as a basis), with Gazebo 9 and ROS Kinetic (here #586 the previous discussion). Although I spent a lot of time to solve compiling issues (I will publish the instructions list as soon as possible), when I start the simulation any feedback comes from Gazebo. Thus, the drone does not take off.

I tried what was suggested in this discussion, but it does not work for me (with and without install). Any suggestion on how to handle the problem is welcomed.

gsilano added a commit to gsilano/CrazyS that referenced this pull request Dec 17, 2019
gsilano added a commit to gsilano/BebopS that referenced this pull request Dec 27, 2019
@gsilano
Copy link

gsilano commented Dec 28, 2019

Hi all! As you can see from the references above, I solved the problem (at least in my case). Please, take a look at my CrazyS and BebopS repositories.

@aeudes
Copy link

aeudes commented Aug 14, 2020

Bump @maxb91 @rikba ?
maybe this one could finally be merged as #626 show that is it still relevant and gsilano/CrazyS@86d80d3 integration prove no catastrophic failure.

@sloretz
Copy link
Author

sloretz commented Oct 19, 2020

Friendly ping :)

@michaelpantic
Copy link
Member

well, this got forgotten quit a bit. I'll run it again through our buildfarm and if it builds we'll just merge it.

@michaelpantic
Copy link
Member

test this please

@michaelpantic
Copy link
Member

@sloretz can you merge in current master? It changed quite a bit build wise /dependency wise. just to make sure we're not breaking things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants