Yanzhen Wang | 20 Oct 07:33 2014
Picon

"Getting Started"-like documentation of LibEDM (a machine learning library)

Hi all,

Following our previous post (http://lists.ros.org/lurker/message/20140918.082108.a9bffe51.en.html) and the feedback we received, we created a "Getting Started"-like documentation for the LibEDM library, which is an open source machine learning library written in C++. You can find the documentation here:
http://micros.nudt.edu.cn/ros/forums/5/memos/409
We hope it can let you have a taste of LibEDM.

And the library itself can be obtained from either GitHub (https://github.com/Qiangli-Zhao/LibEDM) or the link below.
http://micros.nudt.edu.cn/ros/attachments/download/6456/LibEDM.tar.gz

We would be very grateful if you can try it out and let us know your opinions.

Best regards,
Yanzhen
------------------------------------------------------------------------------------
micROS Group
<div><div dir="ltr">Hi all,<br><br>Following our previous post (<a href="http://lists.ros.org/lurker/message/20140918.082108.a9bffe51.en.html">http://lists.ros.org/lurker/message/20140918.082108.a9bffe51.en.html</a>) and the feedback we received, we created a "Getting Started"-like documentation for the LibEDM library, which is an open source machine learning library written in C++. You can find the documentation here:<br><a href="http://micros.nudt.edu.cn/ros/forums/5/memos/409" target="_blank">http://micros.nudt.edu.cn/ros/forums/5/memos/409</a><br>We hope it can let you have a taste of LibEDM.<br><br>And the library itself can be obtained from either GitHub (<a href="https://github.com/Qiangli-Zhao/LibEDM%22%3E%3Ca%20href=%27%3Ca%20href=%27https://github.com/Qiangli-Zhao/LibEDM">https://github.com/Qiangli-Zhao/LibEDM</a>) or the link below.<br><a href="http://micros.nudt.edu.cn/ros/attachments/download/6456/LibEDM.tar.gz" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6456/LibEDM.tar.gz</a><br><br>We would be very grateful if you can try it out and let us know your opinions.<br><br>Best regards,<div>Yanzhen</div>
<div>------------------------------------------------------------------------------------</div>micROS Group<br>
</div></div>
Felipe Roman | 18 Oct 20:38 2014
Picon

Monitoring /diagnostics and /diagnostics_agg topics

Hi All,

I am working on a monitoring tool for monitor multiple robots running ROS. The tool is working fine and I already tested using two real turtlebot robots.

The next step I am planning to do is to monitor a large number of robots.

I tried to use gazebo for simulate robots and it worked. I tested all avaiable robots on gazebo and the only one that publishes information on the  /diagnostics and /diagnostics_agg topics was the PR2. 
Also gazebo requires a lot of computer resources to simulate each robot.

Has anyone have any idea how to simulate more robots publishing diagnostic information ?

I am wondering if create a python script for publish "random" information on the /diagnostics and /diagnostics_agg topics is a good solution or there is other ways to do the same.

I am looking few examples on how to publish on diagnostic topic in python


Thanks in advance, 

--
Best Regards,
Felipe Roman
Phone 55 51 8454 8110
LinkedIn http://au.linkedin.com/in/feliperoman
<div><div dir="ltr">
<span>Hi All,</span><div><br></div>
<div>I am working on a monitoring tool for monitor multiple robots running ROS. The tool is working fine and I already tested using two real turtlebot robots.</div>
<div><br></div>
<div>The next step I am planning to do is to monitor a large number of robots.</div>
<div><br></div>
<div>I tried to use gazebo for simulate robots and it worked. I tested all avaiable robots on gazebo and the only one that publishes information on the&nbsp;&nbsp;/diagnostics and /diagnostics_agg topics was the PR2.&nbsp;</div>
<div>Also gazebo requires a lot of computer resources to simulate each robot.</div>
<div><br></div>
<div>Has anyone have any idea how to simulate more robots publishing diagnostic information ?</div>
<div><br></div>
<div>I am wondering if create a python script for publish "random" information on the /diagnostics and /diagnostics_agg topics is a good solution or there is other ways to do the same.</div>
<div><br></div>
<div>I am looking few examples on how to publish on diagnostic topic in python</div>
<div><br></div>
<div>
<a href="http://docs.ros.org/hydro/api/diagnostic_updater/html/" target="_blank">http://docs.ros.org/hydro/api/diagnostic_updater/html/</a><br>
</div>
<div><br></div>
<div>Thanks in advance,&nbsp;</div>
<div><br></div>-- <br>Best Regards,<br>Felipe Roman<br>Phone 55 51 8454 8110<br>LinkedIn <a href="http://au.linkedin.com/in/feliperoman" target="_blank">http://au.linkedin.com/in/feliperoman</a>
</div></div>
Kei Okada | 18 Oct 12:08 2014
Picon

propose to add new message generator for EusLisp language.

Dear all

I'd like to propose to add new message generator[1] for EusLisp[2]
language as a default. This means you'll have share/euslisp directory
as well as share/common-lisp directory and that'll consume ~7M for all
existing message, which is 1/2 of common-lisp message.

- The package name will be 'geneuslisp'
- The message generator will create files under share/euslisp
- Dirk proposed to release new generator on indigo or Jade, but I'd
like to also release this generator on Hydro if possible.

Any feedback, comment, suggestions are welcome.

Best
Kei Okada

[1] The implementation of EusLisp message generator can be seen at
https://github.com/jsk-ros-pkg/geneuslisp, which only depends on
genmsg package.

[2] The EusLisp language is a yet another dialect of Lisp language,
specially designed for manipulating 3D geometry and robot kinematics
models, mainly used in JSK lab at U-Tokyo.

[3] Original discussion is at https://github.com/ros/message_generation/issues/2

===

Since adding a new message generator is not a very small change to ROS
we think that you should write an email to ros-users <at>  to propose
adding this message generator as a default and ask for feedback from
the community.

It will be important to not introduce any dependencies which might
lead to problems when building for different platforms like ARM.

Before actually adding it the following tasks need to happen:

rename the "new" message generator package since it collides with an
already release packagegeneus, we would propose geneuslisp
release the new package geneuslisp - likely into Indigo only -
eventually even only into the upcomingJade depending on the discussion
update the message_generation package to list the new generator as a dependency

It should also be checked before that all packages in the targeted ROS
distro can be rebuild from source with the new generator in place to
avoid running into issues when it is released to the buildfarm.

What are the dependencies of the client library using the newly
generated code? Do you intent to also include that into desktop /
desktop_full?
Picon

ROSTest: Verify Publications

I have several pieces of software in ROS, all of which are pretty thoroughly unit and integration tested.
However, there's one aspect of testing within ROS that I have yet to accomplish with much success:
Verifying publications.

Note that I'm still stuck in the dark ages of Fuerte, but I believe my question is relevant to more recent
releases as well.

I currently have several tests within rostest, which looks like this in my CMakeLists.txt:

    rosbuild_add_executable(my_tests EXCLUDE_FROM_ALL ${MY_TESTS})
    rosbuild_add_gtest_build_flags(my_tests)
    rosbuild_add_rostest(${PROJECT_SOURCE_DIR}/test/node/node.test)

Running this with `make test` also runs a roscore (since node.test is a launch file), so these tests can make
use of classes that require a connection to roscore. I'd like to use this to verify publications, but it's
not working reliably, which makes me think I'm doing something wrong. As an example:

class TestSubscriber
{
    public:
        TestSubscriber() : receivedMessage(false) {}

        void callback(const std_msgs::Int32ConstPtr &newMessage)
        {
            receivedMessage = true;
            message = newMessage;
        }

        bool receivedMessage;
        std_msgs::Int32ConstPtr message;
}

TEST(MyTest, TestPublication)
{
    // This class is the one that will publish on the "output" topic. It will create a node handle
    // and advertise in its constructor.
    MyPublishingClass publishingClass;

    ros::NodeHandle nodeHandle;

    TestSubscriber subscriber;
    ros::Subscriber rosSubscriber = nodeHandle.subscribe("output", 1, &TestSubscriber::callback, &subscriber);
    ASSERT_EQ(1, rosSubscriber.getNumPublishers()); // This passes

    publishingClass.publishMessage();

    ros::spinOnce(); // Spin so that publication can get to subscription

    EXPECT_TRUE(subscriber.receivedMessage); // This may or may not be true
}

Depending on how the MyPublishingClass is written, this test may pass or fail due to that last line. To give a
specific example, I have a class that reads through a bagfile and publishes specific topics. If that class
publishes topics with:

    publisher.publish(rosBagViewIterator->instantiate<std_msgs::Int32>());

the test passes. If instead the class publishes with:

    publisher.publish(*rosBagViewIterator);

the test fails (even though the node still runs normally outside of the test, so I know that publication is
actually happening). I have more examples of similar weirdness, but I'm hoping this is enough to describe
my problem.

So, down to my questions:

1) Why is this so finicky? I realize that it's basically a node subscribing to its own publication, but that
shouldn't be a problem. Should it?
2) Am I doing this wrong? Is there a better way to test ROS publications? Note that the class in question is
_not_ a complete ROS node, and cannot be tested as such.

Thank you for your help!

--------------------
Kyle Fazzari
Computer Engineer
kyle.fazzari@...

Attachment (smime.p7s): application/pkcs7-signature, 7583 bytes
I have several pieces of software in ROS, all of which are pretty thoroughly unit and integration tested.
However, there's one aspect of testing within ROS that I have yet to accomplish with much success:
Verifying publications.

Note that I'm still stuck in the dark ages of Fuerte, but I believe my question is relevant to more recent
releases as well.

I currently have several tests within rostest, which looks like this in my CMakeLists.txt:

    rosbuild_add_executable(my_tests EXCLUDE_FROM_ALL ${MY_TESTS})
    rosbuild_add_gtest_build_flags(my_tests)
    rosbuild_add_rostest(${PROJECT_SOURCE_DIR}/test/node/node.test)

Running this with `make test` also runs a roscore (since node.test is a launch file), so these tests can make
use of classes that require a connection to roscore. I'd like to use this to verify publications, but it's
not working reliably, which makes me think I'm doing something wrong. As an example:

class TestSubscriber
{
    public:
        TestSubscriber() : receivedMessage(false) {}

        void callback(const std_msgs::Int32ConstPtr &newMessage)
        {
            receivedMessage = true;
            message = newMessage;
        }

        bool receivedMessage;
        std_msgs::Int32ConstPtr message;
}

TEST(MyTest, TestPublication)
{
    // This class is the one that will publish on the "output" topic. It will create a node handle
    // and advertise in its constructor.
    MyPublishingClass publishingClass;

    ros::NodeHandle nodeHandle;

    TestSubscriber subscriber;
    ros::Subscriber rosSubscriber = nodeHandle.subscribe("output", 1, &TestSubscriber::callback, &subscriber);
    ASSERT_EQ(1, rosSubscriber.getNumPublishers()); // This passes

    publishingClass.publishMessage();

    ros::spinOnce(); // Spin so that publication can get to subscription

    EXPECT_TRUE(subscriber.receivedMessage); // This may or may not be true
}

Depending on how the MyPublishingClass is written, this test may pass or fail due to that last line. To give a
specific example, I have a class that reads through a bagfile and publishes specific topics. If that class
publishes topics with:

    publisher.publish(rosBagViewIterator->instantiate<std_msgs::Int32>());

the test passes. If instead the class publishes with:

    publisher.publish(*rosBagViewIterator);

the test fails (even though the node still runs normally outside of the test, so I know that publication is
actually happening). I have more examples of similar weirdness, but I'm hoping this is enough to describe
my problem.

So, down to my questions:

1) Why is this so finicky? I realize that it's basically a node subscribing to its own publication, but that
shouldn't be a problem. Should it?
2) Am I doing this wrong? Is there a better way to test ROS publications? Note that the class in question is
_not_ a complete ROS node, and cannot be tested as such.

Thank you for your help!

--------------------
Kyle Fazzari
Computer Engineer
kyle.fazzari@...

Kai von Szadkowski | 14 Oct 16:12 2014
Picon
Picon

Phobos: 3D robot modelling with Blender

Hi everyone,

I'm working with the University of Bremen and the German Research Center for Artificial Intelligence (DFKI). We've recently decided to switch from our own data format to using URDF for the kinematic descriptions of our robots.

We already used the 3D modelling software Blender to create our models, exporting them using a bunch of python scripts as we didn't fancy creating models by hand. Building on these scripts, we have started to develop a full-blown add-on for Blender designed for simplifying robot model editing. It's called 'Phobos' and can be found on GitHub: https://github.com/rock-simulation/phobos

I haven't been able to track down anything comparable in the ROS and Gazebo world and figured this might be interesting for some people here. There's an overview in the README file on github and already some documentation explaining the overall concepts and how to get started. We're certainly far from delivering a bug-free "consumer product", but if somebody is interested and finds the time to take a glance, we're very happy for any feedback.

Cheers,

Kai
-- Kai von Szadkowski (M.Sc.) Space Robotics Universität Bremen FB 3 - Mathematik und Informatik AG Robotik Robert-Hooke-Straße 1 28359 Bremen, Germany Zentrale: +49 421 178 45-6611 Besuchsadresse der Nebengeschäftstelle: Robert-Hooke-Straße 5 28359 Bremen, Germany Tel.: +49 421 178 45-6646 Empfang: +49 421 178 45-6600 Fax: +49 421 178 45-4150 E-Mail: kai.von-szadkowski-5o+NnrIaK5YUtdQbppsyvg@public.gmane.org Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
<div>
    Hi everyone,<br><br>I'm working with the University of Bremen and the
      German Research Center for Artificial Intelligence (DFKI). We've
      recently decided to switch from our own data format to using URDF
      for the kinematic descriptions of our robots.<br><br>
      We already used the 3D modelling software Blender to create our
      models, exporting them using a bunch of python scripts as we
      didn't fancy creating models by hand. Building on these scripts,
      we have started to develop a full-blown add-on for Blender
      designed for simplifying robot model editing. It's called 'Phobos'
      and can be found on GitHub: <a href="https://github.com/rock-simulation/phobos" target="_blank">https://github.com/rock-simulation/phobos</a><br><br>
      I haven't been able to track down anything comparable in the ROS
      and Gazebo world and figured this might be interesting for some
      people here. There's an overview in the README file on github and
      already some documentation explaining the overall concepts and how
      to get started. We're certainly far from delivering a bug-free
      "consumer product", but if somebody is interested and finds the
      time to take a glance, we're very happy for any feedback.<br><br>
      Cheers,<br><br>
      Kai<br>
    -- 
 Kai von Szadkowski (M.Sc.)
 Space Robotics

 Universit&auml;t Bremen
 FB 3 - Mathematik und Informatik
 AG Robotik
 Robert-Hooke-Stra&szlig;e 1
 28359 Bremen, Germany

 Zentrale: +49 421 178 45-6611

 Besuchsadresse der Nebengesch&auml;ftstelle: 
 Robert-Hooke-Stra&szlig;e 5
 28359 Bremen, Germany

 Tel.:    +49 421 178 45-6646
 Empfang: +49 421 178 45-6600
 Fax:     +49 421 178 45-4150
 E-Mail:   <a class="moz-txt-link-abbreviated" href="mailto:kai.von-szadkowski@...">kai.von-szadkowski@...</a>

 Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.informatik.uni-bremen.de/robotik">http://www.informatik.uni-bremen.de/robotik</a>

  </div>
Luc Fabresse | 13 Oct 23:41 2014
Picon

Run a simple navigation demo (static map+amcl) on an out-of-the-box Groovy-based PR2

Hi all,

I try to execute a standard navigation demo on PR2 using a map already built with gmapping and amcl. 

In short: if someone can point me to *working* launch files it would be perfect.

****************
In details, What I do:
 
1) on the c1 machine of the PR2: 

roslaunch pr2_fcfm nav.launch

------ nav.launch -----
<launch>  
  <node name="robot_state_publisher" pkg="robot_state_publisher" type="state_publisher"/> 
  <node name="map_server" pkg="map_server" type="map_server" args="$(find pr2_fcfm)/maps/lptvMapCleaned.yaml"/>
  <include file="$(find pr2_navigation_global)/amcl_node.xml" />
  <include file="$(find pr2_navigation_global)/move_base.xml" />
</launch>
----------------------------

2) Then, on a remote machine, I launch rviz like that:

roslaunch pr2_navigation_global rviz/rviz_move_base.launch

*********
But my problems are: 

A) the floor_scan in rviz display the /base_scan_throttled topic by default and I cannot see the white dots. If I replace it by /base_scan, I then can see the white dots but it sometimes rviz sporadically display a tf error because /base_scan cannot be transformed to /map. So it does not fully work... Any idea?

B) If I set a pose estimation and then a goal in Rviz, I can see the computed displayed but the robot does not move. I tried to directly publish a move command:

rostopic pub /navigation/cmd_vel geometry_msgs/Twist ...

But the robot still does not move.
And yes, the default move_base launch file seems to remap  /cmd_vel to /navigation/cmd_vel 

Any idea?

#Luc
<div><div dir="ltr">
<div>Hi all,</div>
<div><br></div>
<div>I try to execute a standard navigation demo on PR2 using a map already built with gmapping and amcl.&nbsp;</div>
<div><br></div>
<div>In short: if someone can point me to *working* launch files it would be perfect.</div>
<div><br></div>
<div>****************</div>
<div>In details, What I do:</div>
<div>&nbsp;</div>
<div>1) on the c1 machine of the PR2:&nbsp;</div>
<div><br></div>
<div>roslaunch pr2_fcfm nav.launch</div>
<div><br></div>
<div>------ nav.launch -----</div>
<div>&lt;launch&gt; &nbsp;</div>
<div>&nbsp; &lt;node name="robot_state_publisher" pkg="robot_state_publisher" type="state_publisher"/&gt;&nbsp;</div>
<div>&nbsp; &lt;node name="map_server" pkg="map_server" type="map_server" args="$(find pr2_fcfm)/maps/lptvMapCleaned.yaml"/&gt;</div>
<div>&nbsp; &lt;include file="$(find pr2_navigation_global)/amcl_node.xml" /&gt;</div>
<div>&nbsp; &lt;include file="$(find pr2_navigation_global)/move_base.xml" /&gt;</div>
<div>&lt;/launch&gt;</div>
<div>----------------------------</div>
<div><br></div>
<div>2) Then, on a remote machine, I launch rviz like that:</div>
<div><br></div>
<div>roslaunch pr2_navigation_global rviz/rviz_move_base.launch</div>
<div><br></div>
<div>*********</div>
<div>But my problems are:&nbsp;</div>
<div><br></div>
<div>A) the floor_scan in rviz display the /base_scan_throttled topic by default and I cannot see the white dots. If I replace it by /base_scan, I then can see the white dots but it sometimes rviz sporadically display a tf error because /base_scan cannot be transformed to /map. So it does not fully work... Any idea?</div>
<div><br></div>
<div>B) If I set a pose estimation and then a goal in Rviz, I can see the computed displayed but the robot does not move. I tried to directly publish a move command:</div>
<div><br></div>
<div>rostopic pub /navigation/cmd_vel geometry_msgs/Twist ...</div>
<div><br></div>
<div>But the robot still does not move.</div>
<div>And yes, the default move_base launch file seems to remap &nbsp;/cmd_vel to /navigation/cmd_vel&nbsp;</div>
<div><br></div>
<div>Any idea?</div>
<div>
<br>#Luc<br>
</div>
</div></div>
Yanzhen Wang | 12 Oct 15:37 2014
Picon

Debian packages facilitating installation of linux-rt kernel [UPDATE: test&result]

Hi all,

Following our previous posts (http://lists.ros.org/lurker/message/20140918.011916.e0e9cd9e.en.html and http://lists.ros.org/lurker/message/20140929.022230.7c75e176.en.html) , again we are posting some updates here in a separate thread.

We did some tests to demonstrate the effectiveness of the PREEMPT_RT patched Linux kernel, compared with the vanilla kernel coming with Ubuntu. To be more specific, jitters in ROS message communications (both topic- and service-based) upon the non-real-time and real-time kernels are recorded, while the source code of the test tries to maintain a fixed communication rate (10kHz in our case). The source code can be downloaded from:

And the results are shown in the charts below:

The test environment is described below:
OS: Ubuntu 12.04 32-bit
Vanilla kernel version: 3.8.0
Real-time kernel version: linux-3.8.13-rt16
ROS version: Groovy

Best regards,
Yanzhen

<div><div dir="ltr">Hi all,<div><br></div>
<div>Following our previous posts (<a href="http://lists.ros.org/lurker/message/20140918.011916.e0e9cd9e.en.html" target="_blank">http://lists.ros.org/lurker/message/20140918.011916.e0e9cd9e.en.html</a>&nbsp;and&nbsp;<a href="http://lists.ros.org/lurker/message/20140929.022230.7c75e176.en.html" target="_blank">http://lists.ros.org/lurker/message/20140929.022230.7c75e176.en.html</a>) , again we are posting some updates here in a separate thread.</div>
<div><br></div>
<div>We did some tests to demonstrate the effectiveness of the PREEMPT_RT patched Linux kernel, compared with the vanilla kernel coming with Ubuntu. To be more specific, jitters in ROS message communications (both topic- and service-based) upon the non-real-time and real-time kernels are recorded, while the source code of the test tries to maintain a fixed communication rate (10kHz in our case). The source code can be downloaded from:</div>
<div><a href="http://micros.nudt.edu.cn/ros/attachments/download/6440/ros_rt_test_src.tar.gz" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6440/ros_rt_test_src.tar.gz</a></div>
<div><br></div>
<div>And the results are shown in the charts below:</div>
<div><a href="http://micros.nudt.edu.cn/ros/attachments/download/6435/topic_one_subscriber.png" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6435/topic_one_subscriber.png</a></div>
<div><a href="http://micros.nudt.edu.cn/ros/attachments/download/6436/topic_two_subscriber.png" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6436/topic_two_subscriber.png</a></div>
<div><a href="http://micros.nudt.edu.cn/ros/attachments/download/6437/topic_four_subscriber.png" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6437/topic_four_subscriber.png</a></div>
<div><a href="http://micros.nudt.edu.cn/ros/attachments/download/6438/topic_eight_subscriber.png" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6438/topic_eight_subscriber.png</a></div>
<div><a href="http://micros.nudt.edu.cn/ros/attachments/download/6439/service.png" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6439/service.png</a></div>
<div><br></div>
<div>The test environment is described below:</div>
<div>OS: Ubuntu 12.04 32-bit</div>
<div>Vanilla kernel version: 3.8.0</div>
<div>Real-time kernel version: linux-3.8.13-rt16</div>
<div>ROS version: Groovy</div>
<div><div>
<br>Best regards,<div>Yanzhen</div>
<div><br></div>
</div></div> 		 	   		  </div></div>
Tully Foote | 11 Oct 12:41 2014

Groovy EOL Complete

Hi Everyone, 

I'm writing to highlight another milestone. As we have have now released indigo and are looking forward to Jade, it is time to retire Groovy. 

Groovy was first officially released at the end of 2012, but work toward the release had been started in early 2012.[1] During it's life cycle Groovy almost double the number of packages released reaching a maximum of 900. 

Reviewing the history of the rosdistro repository which contains the release metadata reveals that there was 2912 commits from 127 contributors over the history of the Groovy release. This represents the maintainers making the releases and does not count the many more contributors to the source code of the individual packages. There were commits on 612 different days over the 794 days tracked in this repository. This means on average there were releases of groovy packages more than 5 days per week. For a quick visualization of the activity on the repository we've put together a rendering of commits to the groovy subdirectory: https://vimeo.com/108642560 (These statistics only count catkin based releases, not the 178 rosbuild packages indexed separately.) 

As you may have already noticed, last week we disabled all the groovy jobs on the farm. We have kept them there for reference but do not intend to reenable them. Along those same lines, we can accept pull-requests to keep source builds working on groovy(such as  if a repository is relocated to a new host), but cannot accept pull-requests for new groovy releases. 

As always we'd like to pay trubute to the hundreds of people who put the time in to make groovy happen. It would not have happened without your efforts. 

You ROS Release Team



<div><div dir="ltr">Hi Everyone,&nbsp;<div><br></div>
<div>I'm writing to highlight another milestone. As we have have now released indigo and are looking forward to Jade, it is time to retire Groovy.&nbsp;</div>
<div><br></div>
<div>Groovy was first officially released at the end of 2012, but work toward the release had been started in early 2012.[1] During it's life cycle Groovy almost double the number of packages released reaching a maximum of 900.&nbsp;</div>
<div><br></div>
<div>Reviewing the history of the rosdistro repository which contains the release metadata reveals that there was 2912 commits from 127 contributors over the history of the Groovy release. This represents the maintainers making the releases and does not count the many more contributors to the source code of the individual packages. There were commits on 612 different days over the 794 days tracked in this repository. This means on average there were releases of groovy packages more than 5 days per week. For a quick visualization of the activity on the repository we've put together a rendering of commits to the groovy subdirectory:&nbsp;<a href="https://vimeo.com/108642560">https://vimeo.com/108642560</a> (These statistics only count catkin based releases, not the 178 rosbuild packages indexed separately.)&nbsp;</div>
<div><br></div>
<div>As you may have already noticed, last week we disabled all the groovy jobs on the farm. We have kept them there for reference but do not intend to reenable them. Along those same lines, we can accept pull-requests to keep source builds working on groovy(such as &nbsp;if a repository is relocated to a new host), but cannot accept pull-requests for new groovy releases.&nbsp;</div>
<div><br></div>
<div>As always we'd like to pay trubute to the hundreds of people who put the time in to make groovy happen. It would not have happened without your efforts.&nbsp;</div>
<div><br></div>
<div>You ROS Release Team</div>
<div><br></div>
<div>[1]&nbsp;<a href="http://www.ros.org/news/2012/12/ros-groovy-galapagos-released.html">http://www.ros.org/news/2012/12/ros-groovy-galapagos-released.html</a>
</div>
<div><br></div>
<div><br></div>
</div></div>
Risto Kojcev | 10 Oct 18:36 2014
Picon

Re: Cartesian Path Planner Plug-In for MoveIt

Hi Frantisek,

Sorry for the late reply, I didnt catch this message until now.
Thank you very much for trying out the plugin. I am very happy that you find it useful for your applications.

Regarding the issue you have unfortunately during the development process I haven't considered the possibility of using this plugin in dual arm configurations. The MoveIt group name, which is currently set as "manipulator" is hard coded in the current version of the plugin.

I think expanding the plugin would be very useful, but it could take some time. I am willing and would be happy to take a look at that and I have few design suggestions which I would like to propose in order to proceed with this expansion and of course hear community's opinion about them.
   1. We could consider each arm to have the same features as the current plugin but in the same time we have to provide separate Way-Point add/substract  for each arm(different color coding and labeling as well as when they are outside each corresponding arm IK solution). For example in a dual arm configuration we could have two user interaction markers which could be labeled corresponding to the name set during the MoveIt configuration of the package.
   2. All the way points corresponding to one robot arm should be devised into groups in the TreeView.
   3. We should generate Cartesian paths that avoid collision between the two robots and also let the user know when a certain way point from the first robot collides with the Cartesian path of the other robot arm.
   4. Execution of Cartesian paths. We should also consider at what point should each arm Cartesian path should be executed. For example different applications might not require simultaneous execution of the both arms during the Cartesian path. For simplicity I would propose the first development goal to be simultanious execution of both Cartesian path for the two arms.

These are some of the things I could quickly think about and it would be great to hear the opinions of the community and open a discussion.

If there is an interested in proceeding with this I would be happy to do it, also some points to some dual arm MoveIt configuration packages would be useful in order to develop and test this expansion.

Thanks a lot.

Risto

On Tuesday, October 7, 2014 2:19:13 PM UTC+2, Hammer987 wrote:
Hi Risto

Great job with your Cartesian Planner plugin, it is exactly the tool I was missing in RViz. I have tested it a little bit and found one issue I would like to ask you.

Your plugin works fine but only with planning group "manipulator". Is there any way how to use your plugin for dual arm robots ( for instance "r1" and "r2" groups)  or it is strictly limited to single arm configurations?

Thanks

Frantisek Durovsky





<div><div dir="ltr">Hi&nbsp;Frantisek,<div><br></div>
<div>Sorry for the late reply, I didnt catch this message until now.</div>
<div>Thank you very much for trying out the plugin. I am very happy that you find it useful for your applications.</div>
<div><br></div>
<div>Regarding the issue you have unfortunately during the development process I haven't considered the possibility of using this plugin in dual arm configurations. The MoveIt group name, which is currently set as "manipulator" is hard coded in the current version of the plugin.</div>
<div><br></div>
<div>I think expanding the plugin would be very useful, but it could take some time. I am willing and would be happy to take a look at that and I have few design suggestions which I would like to propose in order to proceed with this expansion and of course hear community's opinion about them.</div>
<div>&nbsp; &nbsp;1. We could consider each arm to have the same features as the current plugin but in the same time we have to provide separate Way-Point add/substract &nbsp;for each arm(different color coding and labeling as well as when they are outside each corresponding arm IK solution). For example in a dual arm configuration we could have two user interaction markers which could be labeled corresponding to the name set during the MoveIt configuration of the package.</div>
<div>&nbsp; &nbsp;2. All the way points corresponding to one robot arm should be devised into groups in the TreeView.</div>
<div>&nbsp; &nbsp;3. We should generate Cartesian paths that avoid collision between the two robots and also let the user know when a certain way point from the first robot collides with the Cartesian path of the other robot arm.</div>
<div>&nbsp; &nbsp;4. Execution of Cartesian paths. We should also consider at what point should each arm Cartesian path should be executed. For example different applications might not require simultaneous execution of the both arms during the Cartesian path. For simplicity I would propose the first development goal to be simultanious execution of both Cartesian path for the two arms.</div>
<div><br></div>
<div>These are some of the things I could quickly think about and it would be great to hear the opinions of the community and open a discussion.</div>
<div><br></div>
<div>If there is an interested in proceeding with this I would be happy to do it, also some points to some dual arm MoveIt configuration packages would be useful in order to develop and test this expansion.</div>
<div><br></div>
<div>Thanks a lot.</div>
<div><br></div>
<div>Risto<br><br>On Tuesday, October 7, 2014 2:19:13 PM UTC+2, Hammer987 wrote:<blockquote class="gmail_quote"><div dir="ltr">Hi Risto<br><br>Great job with your Cartesian Planner plugin, it is exactly the tool I was missing in RViz. I have tested it a little bit and found one issue I would like to ask you.<br><br>Your plugin works fine but only with planning group "manipulator". Is there any way how to use your plugin for dual arm robots ( for instance "r1" and "r2" groups)&nbsp; or it is strictly limited to single arm configurations?<br><br>Thanks<br><br>Frantisek Durovsky<br><br><br><br><br><br>
</div></blockquote>
</div>
</div></div>
Tully Foote | 8 Oct 02:17 2014

ROSCon 2015 Location and Timing Survey

Hi Everyone, 

We had a great time at ROSCon 2014! (if you missed it we've posted videos of all the presentations online now at http://roscon.ros.org/2014/program/ )

Although it's a long way off still we need to look forward to when and where to hold the next instance. To help facilitate that process we'd like the communities feedback on what times and locations would best fit into their schedules. Please take a minute to let us know where you would be able to join us for our next event.  


There is a place for your name and email, but it's not required. 

Thanks, 
Your future ROSCon 2015 Organizing Committee


<div><div dir="ltr">Hi Everyone,&nbsp;<div><br></div>
<div>We had a great time at ROSCon 2014! (if you missed it we've posted videos of all the presentations online now at&nbsp;<a href="http://roscon.ros.org/2014/program/" target="_blank">http://roscon.ros.org/2014/program/</a> )</div>
<div><br></div>
<div>Although it's a long way off still we need to look forward to when and where to hold the next instance. To help facilitate that process we'd like the communities feedback on what times and locations would best fit into their schedules. Please take a minute to let us know where you would be able to join us for our next event. &nbsp;</div>
<div><br></div>
<div>
<a href="https://events.osrfoundation.org/?page=CiviCRM&amp;q=civicrm/petition/sign&amp;sid=3&amp;reset=1" target="_blank">https://events.osrfoundation.org/?page=CiviCRM&amp;q=civicrm/petition/sign&amp;sid=3&amp;reset=1</a><br>
</div>
<div><br></div>
<div>There is a place for your name and email, but it's not required.&nbsp;<br>
</div>
<div><br></div>
<div>Thanks,&nbsp;</div>
<div>Your future ROSCon 2015 Organizing Committee</div>
<div><br></div>
<div><br></div>
</div></div>
Kefei Zeng | 7 Oct 21:51 2014
Picon
Picon

Updates for "image_transport" Tutorials?

I'm trying to get image_transport working by following the instructions in this link (

http://wiki.ros.org/image_transport/Tutorials) but noticed that the tutorial is still using roscreate-pkg instead of catkin. I'm sure there have been other complaints regarding how outdated the instructions were, as evidenced by the complete lack of catkin_instructions. Is it possible to write a new set of tutorials for the people who are used to catkin?

<div>
<p>I'm trying to get image_transport working by following the instructions in this link (</p>
<p><a href="http://wiki.ros.org/image_transport/Tutorials">http://wiki.ros.org/image_transport/Tutorials</a>) but noticed that the tutorial is still using roscreate-pkg instead of catkin. I'm sure there have been other complaints regarding how
 outdated the instructions were, as evidenced by the complete lack of catkin_instructions. Is it possible to write a new set of tutorials for the people who are used to catkin?<br></p>
</div>

Gmane