gmane.science.robotics.ros.user

ROS on MetraLabs Scitos robots (metralabs_ros packagerework announcement)

Felix Kolbe — 2013-06-18T18:09:39

Hello to anyone using ROS on a Scitos robot from MetraLabs [0],

you hopefully know the metralabs_ros package [1] from Chris Burbridge'
original repository uuisrc-ros-pkg [2] or my fork.

We will rework the package on the inside and outside, aiming for robot
instance flexibility and compatibility, round feature set, ROS
standards, catkin compatibility and eventually an announced release.

Therefore the package has been extracted to a separate repository [3],
deprecating the old location.

If you are using our package or just ROS on a Scitos in another way
we'd like to hear from you!  If you have any issues or feature
requests please file them in the new repo [3].

0: http://www.metralabs.com/
1: http://ros.org/wiki/metralabs_ros
2: https://github.com/cburbridge/uuisrc-ros-pkg
3: https://github.com/cburbridge/scitos

Happy coding
Felix

Re: ROS Release Timeline

William Woodall — 2013-06-18T17:01:57

There is a vast amount of ROS that is regularly used on workstations (off
robot), and beginners will often pick the default Ubuntu. So as long as we
aren't talking about only supporting 32-bit, I don't see the controversy.


On Tue, Jun 18, 2013 at 9:58 AM, Pavel Kirienko <
pavel.kirienko.list-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: ROS Release Timeline

Pavel Kirienko — 2013-06-18T16:58:33

However, they recommend 64-bit for Ubuntu Server (
http://www.ubuntu.com/download/server), so this is controversial: shouldn't
ROS be mainly targeted for embedded systems, where Ubuntu Server seems more
relevant?

Regards,
Pavel Kirienko.


On Tue, Jun 18, 2013 at 8:51 PM, William Woodall
<william-GsQoM64suCGGJGYlWa3Ukdi2O/JbrIOy< at >public.gmane.org>wrote:

Re: ROS Release Timeline

William Woodall — 2013-06-18T16:51:18

They recently discussed dropping 32-bit support for PCL on the
pcl-developer's list, but I'll point out what I said to them, which is that
ubuntu.com still recommends 32-bit for their desktop default download. So
at least for now, I think 32-bit support should stay.


On Tue, Jun 18, 2013 at 9:18 AM, Jack O'Quin <jack.oquin-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: ROS Release Timeline

Piyush — 2013-06-18T16:32:24

+1 for the new plan as well. Was there some consensus for the Hydro release
date?

Thanks!
Piyush


On Tue, Jun 18, 2013 at 11:18 AM, Jack O'Quin <jack.oquin-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: ROS Release Timeline

Jack O'Quin — 2013-06-18T16:18:57

+1



Looking forward, I suspect most PC users will be 64-bit, and the main
32-bit platform will be ARM. That may be true already. Perhaps people would
favor substituting some common ARM platform for i386.



+1 It's a good plan, balancing a great many divergent needs.

Re: ROS Release Timeline

Marcus Liebhardt — 2013-06-18T05:10:05


Looks good to me. So, when can we expect Hydro for Precise? :-)

Marcus

Re: ROS Release Timeline

Tully Foote — 2013-06-18T01:23:26

Hi Everyone,

Thank you for taking the time to fill out the survey. You can download the
the pdf summary of the results from:
https://docs.google.com/file/d/0BzNmzxy4pVGMNDdxNFNDblJTN1k/edit?usp=sharing

Based on the above discussion and the survey results. We'd like to propose
the following solution. Dirk's made another nice svg which is attached for
visualization.

From the survey there is very strong support for an long term support of
ROS(ROS going forward) in sync with Ubuntu LTS(LTS going forward), so we
will start with that as a premis of this proposal. And we believe that we
have built a consensus about a one year release cycle which would make the
ROS+1 release on LTS+2. Now to fill in the gaps before ROS+2 (the next
long term support) we will need to be able to build more than 6 months
ahead in our 1 year cycle, so we would plan to use LTS+3 as a beta build
ground for ROS+2. And to prepare for ROS+1 we need to be able to build
early enough that we will beta build on LTS+1. And as there is strong
support for multiple ROS distributions available on LTS, we will also
backport ROS+1 to the LTS.

The net result is as follows:
Ubuntu LTS supports ROS, ROS+1
LTS+1 supports ROS+1 Beta
LTS+2 supports ROS+1
LTS+3 supports ROS+2 Beta
...
LTS2 supports ROS+2, ROS+3

This proposal provides the large userbase who will just use the Ubuntu LTS
releases with two releases. The other set of users who would like to use
the latest version of Ubuntu are following an aggressive cycle set by
Ubuntu. For them we can make sure there's at least one version of ROS or
the Beta release of ROS which should be in the soak period before the next
release.

With regards to not tying ROS to Ubuntu only we will also definitely see to
support other platforms. Right now we do not have the resources or
expertise to support other platforms. We expect each ROS release to accept
patches for support on other platforms. This also holds true for other
arches such as arm, which is strongly supported in Q5 of the recent survey.

Related to this it has been suggested to me that we could setup a
bidding/kickstarter style campaign for different platform or arch support.
If people are interested we could estimate what it would take to support
builds on extra arch/platform combinations for the duration of a release.
And if there is enough community support to fund the project we can turn
on specific architectures. Also we are currently building i386 and amd64,
we could consider dropping i386 on some platforms to save resources.

Please take a look at the results of both surveys and the above proposal
and give your feedback.

Tully

On Sun, Jun 2, 2013 at 9:27 AM, Jack O'Quin <jack.oquin-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Iwaki interaction and dialogue manager

Maxim Makatchev — 2013-06-17T21:50:49

Announcing the release of

Iwaki interaction and dialogue manager library and its ROS wrapper:
https://github.com/maxipesfix/iwaki-ros-pkg

Iwaki interaction manager is currently used to manage both
conversational (verbal and non-verbal) and task-related interactions
for two social robots at Carnegie Mellon University. The task-related
interactions include:
- information retrieval requests for a new version of Hala, the
bilingual robot receptionist at CMU Qatar,
- table-game playing interactions for an upcoming robot at CMU.

Iwaki includes a production system, inspired by COLLAGEN's plan tree
[Rich and Sidner, 1998], that interprets rules (recipes) stored in
XML. The production system approach allows creating interactions with
aspects of finite-state, frame/script, and information-state-based
dialogue management. The distribution includes examples and a manual
(under development).

Cheers,
Maxim Makatchev

New Packages in Hydro

Tully Foote — 2013-06-14T17:19:50

Hi Everyone,

Thanks to all the maintainers for their releases into the Hydro Alpha.  We
have almost 90 packages  updated in this release including 20 new packages.
 For a detailed listing see below.

You ROS Release Team


Packages Added:
ros-hydro-concert-conductor : 0.5.2
ros-hydro-concert-msgs : 0.5.1
ros-hydro-concert-orchestra : 0.5.2
ros-hydro-gateway-msgs : 0.5.1
ros-hydro-redis : 0.5.2
ros-hydro-rocon-app-manager : 0.5.1
ros-hydro-rocon-app-manager-msgs : 0.5.1
ros-hydro-rocon-app-platform : 0.5.1
ros-hydro-rocon-apps : 0.5.1
ros-hydro-rocon-concert : 0.5.2
ros-hydro-rocon-gateway : 0.5.2
ros-hydro-rocon-gateway-graph : 0.5.1
ros-hydro-rocon-gateway-tests : 0.5.2
ros-hydro-rocon-hub : 0.5.2
ros-hydro-rocon-hub-client : 0.5.2
ros-hydro-rocon-msgs : 0.5.1
ros-hydro-rocon-multimaster : 0.5.2
ros-hydro-rocon-rqt-plugins : 0.5.1
ros-hydro-rocon-test : 0.5.2
ros-hydro-rocon-tf-reconstructor : 0.5.2
ros-hydro-rocon-unreliable-experiments : 0.5.2
ros-hydro-rocon-utilities : 0.5.2
ros-hydro-zeroconf-avahi : 0.2.3
ros-hydro-zeroconf-avahi-demos : 0.2.3
ros-hydro-zeroconf-avahi-suite : 0.2.3
ros-hydro-zeroconf-msgs : 0.2.1

Packages Removed:
ros-hydro-urdf-parser : 1.10.9

Packages Updated:
ros-hydro-actionlib : 1.10.0 -> 1.10.1
ros-hydro-bond : 1.7.11 -> 1.7.12
ros-hydro-bond-core : 1.7.11 -> 1.7.12
ros-hydro-bondcpp : 1.7.11 -> 1.7.12
ros-hydro-bondpy : 1.7.11 -> 1.7.12
ros-hydro-camera1394 : 1.9.2 -> 1.9.3
ros-hydro-catkin : 0.5.65 -> 0.5.66
ros-hydro-class-loader : 0.2.0 -> 0.2.1
ros-hydro-cpp-common : 0.3.14 -> 0.3.15
ros-hydro-genmsg : 0.4.18 -> 0.4.19
ros-hydro-libsegwayrmp : 0.2.8 -> 0.2.9
ros-hydro-message-filters : 1.9.44 -> 1.9.45
ros-hydro-mk : 1.10.0 -> 1.10.1
ros-hydro-python-qt-binding : 0.2.8 -> 0.2.10
ros-hydro-qt-dotgraph : 0.2.14 -> 0.2.16
ros-hydro-qt-gui : 0.2.14 -> 0.2.16
ros-hydro-qt-gui-app : 0.2.14 -> 0.2.16
ros-hydro-qt-gui-core : 0.2.14 -> 0.2.16
ros-hydro-qt-gui-cpp : 0.2.14 -> 0.2.16
ros-hydro-qt-gui-py-common : 0.2.14 -> 0.2.16
ros-hydro-ros : 1.10.0 -> 1.10.1
ros-hydro-ros-comm : 1.9.44 -> 1.9.45
ros-hydro-rosbag : 1.9.44 -> 1.9.45
ros-hydro-rosbash : 1.10.0 -> 1.10.1
ros-hydro-rosboost-cfg : 1.10.0 -> 1.10.1
ros-hydro-rosbuild : 1.10.0 -> 1.10.1
ros-hydro-rosclean : 1.10.0 -> 1.10.1
ros-hydro-rosconsole : 1.9.44 -> 1.9.45
ros-hydro-roscpp : 1.9.44 -> 1.9.45
ros-hydro-roscpp-core : 0.3.14 -> 0.3.15
ros-hydro-roscpp-serialization : 0.3.14 -> 0.3.15
ros-hydro-roscpp-traits : 0.3.14 -> 0.3.15
ros-hydro-roscreate : 1.10.0 -> 1.10.1
ros-hydro-rosgraph : 1.9.44 -> 1.9.45
ros-hydro-rosgraph-msgs : 1.9.44 -> 1.9.45
ros-hydro-rosjava-tools : 0.1.3 -> 0.1.5
ros-hydro-roslang : 1.10.0 -> 1.10.1
ros-hydro-roslaunch : 1.9.44 -> 1.9.45
ros-hydro-roslib : 1.10.0 -> 1.10.1
ros-hydro-rosmake : 1.10.0 -> 1.10.1
ros-hydro-rosmaster : 1.9.44 -> 1.9.45
ros-hydro-rosmsg : 1.9.44 -> 1.9.45
ros-hydro-rosnode : 1.9.44 -> 1.9.45
ros-hydro-rosout : 1.9.44 -> 1.9.45
ros-hydro-rospack : 2.1.18 -> 2.1.19
ros-hydro-rosparam : 1.9.44 -> 1.9.45
ros-hydro-rospy : 1.9.44 -> 1.9.45
ros-hydro-rosservice : 1.9.44 -> 1.9.45
ros-hydro-rostest : 1.9.44 -> 1.9.45
ros-hydro-rostime : 0.3.14 -> 0.3.15
ros-hydro-rostopic : 1.9.44 -> 1.9.45
ros-hydro-rosunit : 1.10.0 -> 1.10.1
ros-hydro-roswtf : 1.9.44 -> 1.9.45
ros-hydro-rqt : 0.2.8 -> 0.2.9
ros-hydro-rqt-gui : 0.2.8 -> 0.2.9
ros-hydro-rqt-gui-cpp : 0.2.8 -> 0.2.9
ros-hydro-rqt-gui-py : 0.2.8 -> 0.2.9
ros-hydro-smclib : 1.7.11 -> 1.7.12
ros-hydro-std-srvs : 1.9.44 -> 1.9.45
ros-hydro-topic-tools : 1.9.44 -> 1.9.45
ros-hydro-xmlrpcpp : 1.9.44 -> 1.9.45

Re: OS Usage Survey

Tully Foote — 2013-06-14T02:48:40

Hi,

Jut a quick reminder that the survey closes tomorrow.  If you want to get
your input in please do so before the end of the day tomorrow.

Thank you to everyone who has already filled it out.

Tully


On Tue, Jun 11, 2013 at 8:25 PM, Tully Foote <tfoote-GsQoM64suCGGJGYlWa3Ukdi2O/JbrIOy< at >public.gmane.org>wrote:

Re: missing generated lisp-messages in debian packages for groovy

Dirk Thomas — 2013-06-13T23:20:57

The only option is to add roslisp as a dependency of ros_comm.
ros_comm is the only package dry packages with messages have to depend on.
I ticketed and already committed the patch (https://github.com/ros/ros_comm/issues/240).
But this will require a new version 1.9.46 of ros_comm which will take some time to be build on the farm...
(Let's hope we don't find another lisp issue afterwards.)

- Dirk

Re: missing generated lisp-messages in debian packages for groovy

Dirk Thomas — 2013-06-13T22:57:49

Well, I see why it will work in your from-source-build.
You do have roslisp installed.

The buildfarm will only install dependencies explicitly stated by the package when building and packaging it.
So dry packages lack a dependency on roslisp if lisp messages should be generated for them.
I will see how we can work around that - since roslisp is not part of ros_comm anymore since Lorenz extracted it into a separate repo end of last year.

- Dirk

Re: missing generated lisp-messages in debian packages for groovy

Dirk Thomas — 2013-06-13T22:03:17

Well, I can confirm that it is the case for arm-navigation (even from shadow-fixed).
Than I guess that is the third issue we are facing since other Debian packages include the lisp files correctly (e.g. std_msgs, actionlib_msgs, turtlesim).
It could be generally the case for dry packages since on a first look I only see lisp files of wet stuff being installed from Debians.



But even when building a dry package with messages from source I don't get any lisp files.
So I would suspect that your workaround to build from source does not work for dry stuff.
Can you confirm that?
Above it sounds like a build from source would work for you.
Is that also true for dry stuff?

- Dirk

Re: missing generated lisp-messages in debian packages for groovy

Georg Bartels — 2013-06-13T20:12:07

Hi Dirk,



Thanks for the clarification. I was not fully aware of that. However, 
see below...


... I just installed the debian package ros-groovy-arm-navigation. It's 
a stack also containing arm_navigation_msgs which I can find using roscd 
--msg-defintions and generated cpp-code all there. If I now cd to 
/opt/ros/groovy/share/common-lisp/ros I do not find a sub-dir 
arm_navigation_msgs. I hope I'm not overlooking something extremely 
obvious here because then it's a bit embarrasing...



To me, that is different issue, i.e. present lisp-messages with 
possibly broken asd-files. And I'm super grateful for the patch which 
has already been provided. :)


Yup. I can confirm that this current fix is working. :)

Cheers,
Georg.

answers.ros.org batched emails reenabled

Tully Foote — 2013-06-13T17:58:50

Hi Everyone,

I have a quick update on answers.ros.org.  We found out that the batched
emails have not been being serviced. Daily and weekly, were not being
processed.  They have been turned on now.

Also in this fix, we have turned on reminders to accept answers to your
questions.  Please do make an effort to accept questions so that others
know that they have solutions.  This is better for our community in that
they both do not spend time trying to help someone with a solution already,
and for other people with the same problem they know that this thread has
been solved before they read it through.

answers.ros.org has become a great resource for the community.  Thank you
all for participating. We've passed 11 thousand questions asked and have
73% with accepted answers.

Tully

Re: missing generated lisp-messages in debian packages for groovy

Dirk Thomas — 2013-06-13T17:00:48

The current Debian packages do include generated lisp files for messages.
But they are not located in the message folder but under share/common-lisp/ros/*.

The problem with the current available packages in the public repository is that they contain invalid code which makes them not loadable.
This has been addressed in https://github.com/ros/genmsg/pull/27
The new packages are already built but until now only in the shadow-fix repository.

It will take some more days / weeks until they will be synced to public.

The temporary fix to check them out and build them locally works since the issue has been fixed in the source repositories.

- Dirk



On 13.06.2013 04:00, Jan Winkler wrote:

Re: missing generated lisp-messages in debian packages for groovy

Jan Winkler — 2013-06-13T11:00:17

Hi,

I can confirm this issue and ran into the same problem.
The *_msgs-msg and *_msgs-srv ASDF systems are not loadable (because not 
present).

A temporary fix is to check out the *_msgs-packages and build them from 
source inside an overlay workspace. One then gets the generated 
lisp-msg-files.

So it seems the message files are just not shipped with the debian packages.

Best,
Jan


Am 13.06.2013 11:39, schrieb Georg Bartels:

missing generated lisp-messages in debian packages forgroovy

Georg Bartels — 2013-06-13T09:39:42

Hi all,

when installing debian msg-packages under groovy, e.g. 
arm_navigation_msgs or pr2_msgs, they only contain the generated 
cpp-files, while the lisp-msgs are missing.

Example:
Under fuerte: /opt/ros/fuerte/stacks/pr2_common/pr2_msgs/msg_gen 
contains both cpp and lisp directories.
Under groovy: /opt/ros/groovy/stacks/pr2_common/pr2_msgs/msg_gen 
contains only a cpp directory.

This leads to compilation error of lisp packages that depend on these 
message packages under groovy. I think this is a bug. Could anybody 
please confirm this bug? Also, if it is indeed a bug, could someone 
please point me to the right place to file a ticket? Thanks a lot.

Cheers,
Georg.

Translations of the Wiki

Fabian Saccilotto — 2013-06-12T07:29:07

Hi everyone,

some time ago, I made a german translation of the ROS wiki. The issue of 
seeing translated pages directly was disussed here: 
https://github.com/ros-infrastructure/roswiki/issues/31. I tested the 
use of LanguageDict pages but without success.

To make the translations available and visible to others - especially 
newcomers - I made links to the translated main wiki pages.
I hope you can agree with this change. Nevertheless I would prefer if 
someone with knowledge of moinmoin could have a look at it to make the 
translations visible on the specific pages directly.

Kind regards

Fabian Saccilotto

Re: OS Usage Survey

Tully Foote — 2013-06-12T04:58:30

Hi Thomas,

Thanks for the feedback.

On Tue, Jun 11, 2013 at 9:23 PM, Thomas Moulard <thomas.moulard-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:


Do your best to answer the questions in their strictest form.  The
questions are not necessarily mutually exclusive, and are really targeted
at helping decide which versions of Ubuntu to build binary packages for
going forward.



I've reworded it to just say packages built.



We understand, that's why we threw in this question.  It's not completely
relevant to the current discussion, and I don't expect to switch our main
packaging efforts in the short term.  But looking out a little bit farther
knowing what platforms are of the higher interest will be most valuable.

In our recent infrastructure upgrades we have done our best to make the
infrastructure extendable to other distros. If you or anyone else is
interested in working on supporting binary packages for Fedora or another
platform send us an email on the ros-sig-buildsystem mailing list.  In
particular bloom has been designed to support plugging in new package
generators.  We can help provide guidance on where to get started. Knowing
what distro is of highest interest to the community might help catalyze
progress in this area.

And beyond packaging we are also working hard to make it easier to compile
from source on any platform.  We've made great strides in that direction
and hope to keep improving.

Tully