Fiducial sensor for ros implemented

[maxbader]

Hi

We enhanced the stage_ros pkg to publish fiducial sensor data.
In order to publish such data it was needed to add new messages the messages description is currently located within the stage_ros pkg. We are also in discussion with the common_msgs pkg maintainer to move the description into the sensor_msgs pkg (the brunch: without_stage_ros_messages implements this already).

I addtion we added a launch file for testing. Running:
roslaunch stage_ros world.launch world:=fiducial
should start a environment with fiducial.

We tested everything on Ubuntu 64bit 14.04 with ROS Jade, as well as on 16.04 with ROS Kinetic

We are looking forward to a merge

[maxbader]

At the moment there is a discussion to add the marker message to the common_msgs pkg.
ros/common_msgs#86

[wjwwood]

Ok, thanks for the pr. One of us will get to it as soon as we have time.

@gerkey FYI

[wjwwood]

@maxbader also, when the discussion on common_msgs reaches a conclusion, please let us know on this thread. Thanks again.

[maxbader]

Hi
We did now a lot of enhancements and code clean ups.

• The markers are working with a dependency to marker_msgs
• We added the possibility to define motion contains on a differential drive

[CodeFinder2]

Regardless of the PR's content (which is great, BTW), I would advise against using const_cast's, see (e.g.) 582784b#diff-85d0e0c7dc1f3bd834819d2137cba2c0R467

Instead, wouldn't is be possible to revisit the design of the stored member variables, possibly removing the const qualifier? Clearly, one would need to have a closer look at the impact. (I've done that in a completely modified/extended/refactored version of stage_ros and it seems fine, at least in my version.)

[wjwwood]

So is the conclusion to leave the marker messages out of common_msgs in favor of it's own package/repository?

That's fine, but we have to think carefully about adding this as a dependency of stage_ros, because stage_ros is part of what we call "desktop-full" and therefore is required to be released for any new ROS release's beta (like the upcoming ROS Lunar release) and so any dependencies of stage_ros also becomes part of that push. This just means that if we merge this and make marker_msgs a dependency of stage_ros then we are committing to ensuring it is released very early in the ROS distribution, and taking on responsibility for it if, in the future, you no longer have time to maintain that package. That's why it would have been nice to get it into common_msgs.

That being said, it's not a deal breaker, but it would make merging this an obvious decision.

[maxbader]

Hi,

I started a discussion on ros/common_msgs#86 without success, because of this i created a package containing the marker message. There exists also a rviz plugin to visualize this message called marker_rviz_plugin. Both pkgs are released and already available via the ros pakage server. I don't know maybe you have more influence on the ros comunity to move the message into the common msg pkg.
In order to ensure the maintains I can give you also the proper rights on the github repository but for the next years I am happy to keep the pkg maintained.

Greetings
Markus

PS.: George (@todorangrg) will target the design issue stated by CodeFinder2 with a new commit within the next hours.

[todorangrg]

Hi,

I removed the const qualifier from the StageRobot pointers (and also all the const_casts). If you think I could change something else, please let me know. Also sorry for placing two enchantments in one pull request :)

[wjwwood]

Sorry, I accidentally closed this when changing the branch layout of the repository. I've reopened it and updated the target base to be lunar-devel which is the new default branch. You can edit again to point at indigo-devel, which is what is used to release for ROS Indigo and Kinetic, if you like.