On Sun, Aug 8, 2010 at 12:30 AM,
<ros-users-request@code.ros.org> wrote:
Send ros-users mailing list submissions to
ros-users@code.ros.org
To subscribe or unsubscribe via the World Wide Web, visit
https://code.ros.org/mailman/listinfo/ros-users
or, via email, send a message with subject or body 'help' to
ros-users-request@code.ros.org
You can reach the person managing the list at
ros-users-owner@code.ros.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ros-users digest..."
Today's Topics:
1. Re: Collisions Outside the Bounding Box
(planning_environment) (David Lu!!)
2. Re: Collisions Outside the Bounding Box
(planning_environment) (Sachin Chitta)
3. Re: Arm Core Performance (Cedric Pradalier)
4. Re: The Limitations of URDF (John Hsu)
5. Re: The Limitations of URDF (David Lu!!)
6. cv::Canny() error (Jared Marshall Glover)
7. Re: The Limitations of URDF (Herman Bruyninckx)
8. Re: karto package launch problems (nitinDhiman)
----------------------------------------------------------------------
Message: 1
Date: Fri, 6 Aug 2010 13:26:01 -0700
From: "David Lu!!" <davidvlu@gmail.com>
Subject: Re: [ros-users] Collisions Outside the Bounding Box
(planning_environment)
To: ros-users@code.ros.org
Message-ID:
<AANLkTinDqbhEbt1J6VNLHvzWcaVYAUYq8Qtv6DWy_dn4@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
>
> (1) This is difficult to debug without more information. One thing you
> could do is display the pose of the robot corresponding to the last
> collision in rviz. This tutorial -
> http://www.ros.org/wiki/motion_planning_environment/Tutorials/Tutorial%20B
> - helps you do that.
>
> I've been running off of
http://www.ros.org/wiki/motion_planning_environment/Tutorials/Tutorial%20A,
except with my own robot and no laser data, so I know exactly what pose the
collisions are happening in.
> (2) Also, using the rviz "select" button, you can click on the markers
> and they will give you more information on what is colliding.
>
> Good to know.
> (3) Are you moving the base of the robot around? We are working
> towards a release that handles motion of the robot base properly - the
> current collision environment is not yet fully tested for motion of
> the base.
>
> No. I'm only running GetStateValidity with one static pose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /discuss/ros-users/attachments/20100806/2caf5d3e/attachment.html
------------------------------
Message: 2
Date: Fri, 6 Aug 2010 13:52:15 -0700
From: Sachin Chitta <sachinc@willowgarage.com>
Subject: Re: [ros-users] Collisions Outside the Bounding Box
(planning_environment)
To: ros-users@code.ros.org
Message-ID:
<AANLkTi=RUSrLPuX1x=ZY5+rgEu1RMO1TOfs6297s2kT9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 6, 2010 at 1:26 PM, David Lu!! <davidvlu@gmail.com> wrote:
>> (1) This is difficult to debug without more information. One thing you
>> could do is display the pose of the robot corresponding to the last
>> collision in rviz. This tutorial -
>> http://www.ros.org/wiki/motion_planning_environment/Tutorials/Tutorial%20B
>> - helps you do that.
>>
> I've been running off
> of?http://www.ros.org/wiki/motion_planning_environment/Tutorials/Tutorial%20A,
> except with my own robot and no laser data, so I know exactly what pose the
> collisions are happening in.
True, but the pose that the planning_environment is checking
collisions for might not represent the one you are sending in. Doing
this will show you where the collision environment thinks the robot is
- if there's a potential bug here we might catch it this way.
Can you send me a snapshot in rviz with collision display enabled. It
looks like (from the marker message), PIECE1 is colliding with PIECE2
in BASE_FRAME. Where is BASE_FRAME defined with respect to PIECE1 and
PIECE2 - maybe send me a urdf as well?
Sachin
>
>>
>> (2) Also, using the rviz "select" button, you can click on the markers
>> and they will give you more information on what is colliding.
>>
> Good to know.
>
>>
>> (3) Are you moving the base of the robot around? We are working
>> towards a release that handles motion of the robot base properly - the
>> current collision environment is not yet fully tested for motion of
>> the base.
>>
> No. I'm only running GetStateValidity with one static pose.
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
--
Sachin Chitta
Research Scientist
Willow Garage
------------------------------
Message: 3
Date: Fri, 6 Aug 2010 23:16:01 +0200
From: Cedric Pradalier <cedric.pradalier@mavt.ethz.ch>
Subject: Re: [ros-users] Arm Core Performance
To: <ros-users@code.ros.org>
Message-ID: <4C5C7B91.6010309@mavt.ethz.ch>
Content-Type: text/plain; charset="UTF-8"; format=flowed
On 08/06/10 09:08, Daniel Stonier wrote:
>
> Ok, applied cedric's patches and the rpc outgoing request is down from
> an average of about 98ms to 56ms, also the returning response is down
> to an average of 3ms. Which is starting to seem reasonable.
>
> About 40-45ms of that outgoing time is spent in the
> xmlrpcclient->execute call in master::execute (when contacting the
> master to initialise an rpc link). I didn't bury down any further into
> the xmlrpc library.
>
> With cedric's patches too, the msg latency dropped to about 6ms, which
> is getting close to the raw tcp/ip socket times I tested. So its
> starting to seem reasonable.
>
> Nice analysis on the timers cedric! And thank you everyone for the
> input and pointers. Now we've just one alignment trap issue to worry
> about.
>
>
Thanks.
I was helped a lot by VirtualBox somehow highlighting these problems
much more than they actually occurs on my system.
Cheers
--
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp
------------------------------
Message: 4
Date: Fri, 6 Aug 2010 14:36:41 -0700
From: John Hsu <johnhsu@willowgarage.com>
Subject: Re: [ros-users] The Limitations of URDF
To: ros-users@code.ros.org
Message-ID:
<AANLkTinuZZg2DstoFU9E-cuo4d6NnCdfFfwP8iV3pOTe@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi David!!!
I've answered inline:
On Fri, Aug 6, 2010 at 11:44 AM, David Lu!! <davidlu@wustl.edu> wrote:
> Hey ROS-community,
> I've been working with URDF extensively for awhile, and am wondering what
> the future is for its development. Specifically, whether the format will be
> extended at all to address what I perceive to be some of its limitations.
>
> I think the biggest limitation is the lack of graph support, which relates
> a link to two or more parent links (as opposed to the current tree
> structure). I believe this problem stems from KDL supporting only chains,
> and not graphs, but there are a number of situations where a graph structure
> is called for. The simplest example is a four bar linkage, which, as it
> stands, cannot be easily model led in URDF.
>
>
Thanks for the feedback. We have started thinking about some of the
potential improvements to URDF and ticketed them on trac
https://code.ros.org/trac/ros-pkg/search?q=urdf-2.0
please feel free to contribute your comments there. When creating
additional feature requests please put "urdf-2.0" in the "Keywords" field
for now.
One step toward fixing the problem could involve making some joints
> dependent on other joints. For the case of a parallelogram-shaped 4 bar,
> three of the joints could depend on one joint, but there is currently no
> support for that either. A similar situation involves gears/pulleys and
> other motion transferring mechanisms, i.e. two gears, each connected to a
> base with a continuous joint, and the angle of joint for the second gear is
> 4 times the angle for the first.
>
I've added your comments to this
ticket<https://code.ros.org/trac/ros-pkg/ticket/4263>.
> Having now tried to get collision detection working as well, it seems odd
> to have three different structures to specify the hierarchy of the machine.
> Its specified once in the URDF, and then separate groups are defined via
> parameters to define groups. Some of these groups coincide with whole xacro
> macros too. While I see that these distinctions may often need to be
> customized, it seems like it would be easier to do the customization via
> parameter, and not use the parameters to redefine everything again.
>
Maybe someone more familiar with the collision groups can answer this one?
>
> The last thing that concerns me is the PR2 specific extensions. I'm not
> exactly clear what they lend to the PR2, but I'm also not clear why they
> wouldn't apply to other robots.
>
can you please clarify your concern? (e.g. package/stack names? etc.)
In general, a lot of the software packages may work their way into
non-PR2-specific status after proving its usefulness first as a PR2 specific
utility.
>
> [As an aside, does anyone know where the xml schema are for urdf? The PR2
> file links to http://playerstage.sourceforge.net/gazebo/xmlschema/, but
> there's nothing there.]
>
https://code.ros.org/trac/ros-pkg/ticket/4328
>
> What I'm wondering is whether any of these issues are currently being
> addressed, or whether I should work around them (either in my own code or in
> the ROS repository). Hopefully this will spark a discussion on any other
> hurdles people are having with URDF.
>
Thanks again for the feedbacks!
John
>
>
> Thanks,
> David!!
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /discuss/ros-users/attachments/20100806/538fc4e6/attachment-0001.htm
------------------------------
Message: 5
Date: Fri, 6 Aug 2010 14:53:23 -0700
From: "David Lu!!" <davidvlu@gmail.com>
Subject: Re: [ros-users] The Limitations of URDF
To: ros-users@code.ros.org
Message-ID:
<AANLkTim9oHu=hUs+cOQ_vKv-fv--zFt7AvfkqqbLJvuo@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for the reply John. Clarification inline...
The last thing that concerns me is the PR2 specific extensions. I'm not
>> exactly clear what they lend to the PR2, but I'm also not clear why they
>> wouldn't apply to other robots.
>>
>
> can you please clarify your concern? (e.g. package/stack names? etc.)
> In general, a lot of the software packages may work their way into
> non-PR2-specific status after proving its usefulness first as a PR2 specific
> utility.
>
>
Basically, I was trying to figure out whether I could/should use them in my
model, but I was unsure how to use it due to the lack of documentation, and
wasn't sure why it was PR2 only, but you just clarified that part. I guess
that's just the nature of the developing packages.
Thanks again,
David!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /discuss/ros-users/attachments/20100806/ba95c1a8/attachment-0001.htm
------------------------------
Message: 6
Date: Fri, 06 Aug 2010 18:09:10 -0400
From: Jared Marshall Glover <jglov@MIT.EDU>
Subject: [ros-users] cv::Canny() error
To: ros-users@code.ros.org
Message-ID: <20100806180910.g8iii27pi8kk84go@webmail.mit.edu>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I'm not sure if this should go to ros-users or the opencv mailing list, but I'm
getting a runtime error in cv::Canny():
OpenCV Error: Unsupported format or combination of formats () in cvCanny, file
/opt/ros/cturtle/stack/vision_opencv/opencv2/build/opencv-svn/modules/imgproc/src/canny.cpp,
line 66
terminate called after throwing an instance of 'cv::Exception'
Here's my code:
Mat1b I2, E;
I = 256*I; // I is a Mat1d
I.assignTo(I2, DataType<uchar>::type);
I = I/256;
E.create(I2.size());
Canny(I2,E,100,240);
I'm also getting some warnings during compilation about the opencv headers:
In file included from /u/jglov/lis/bookbot/src/bookFinder.cpp:2:
/opt/ros/cturtle/stacks/vision_opencv/opencv2/opencv/include/opencv/cv.h:47:2:
warning: #warning "This is a deprecated opencv header provided for
compatibility. Please include a header from a corresponding opencv module"
In file included from
/opt/ros/cturtle/stacks/vision_opencv/opencv2/opencv/include/opencv/cv.h:64,
from /u/jglov/lis/bookbot/src/bookFinder.cpp:2:
/opt/ros/cturtle/stacks/vision_opencv/opencv2/opencv/include/opencv2/core/internal.hpp:297:1:
warning: "CV_IMPL" redefined
In file included from /u/jglov/lis/bookbot/src/bookFinder.cpp:2:
/opt/ros/cturtle/stacks/vision_opencv/opencv2/opencv/include/opencv/cv.h:60:1:
warning: this is the location of the previous definition
/opt/ros/cturtle/stacks/vision_opencv/opencv2/opencv/include/opencv/cv.h:67:8:
warning: extra tokens at end of #endif directive
I've attached the manifest.xml and CMakeLists.txt of the project for reference.
Thanks,
Jared
-------------- next part --------------
cmake_minimum_required(VERSION 2.4.6)
include($ENV{ROS_ROOT}/core/rosbuild/rosbuild.cmake)
# Set the build type. Options are:
# Coverage : w/ debug symbols, w/o optimization, w/ code-coverage
# Debug : w/ debug symbols, w/o optimization
# Release : w/o debug symbols, w/ optimization
# RelWithDebInfo : w/ debug symbols, w/ optimization
# MinSizeRel : w/o debug symbols, w/ optimization, stripped binaries
#set(ROS_BUILD_TYPE RelWithDebInfo)
rosbuild_init()
#set the default path for built executables to the "bin" directory
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)
#set the default path for built libraries to the "lib" directory
set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)
#uncomment if you have defined messages
rosbuild_genmsg()
#uncomment if you have defined services
#rosbuild_gensrv()
#common commands for building c++ executables and libraries
#rosbuild_add_library(${PROJECT_NAME} src/example.cpp)
#target_link_libraries(${PROJECT_NAME} another_library)
#rosbuild_add_boost_directories()
#rosbuild_link_boost(${PROJECT_NAME} thread)
#rosbuild_add_executable(example examples/example.cpp)
#target_link_libraries(example ${PROJECT_NAME})
rosbuild_add_executable(transformer src/transformer.cpp)
rosbuild_add_executable(tableFilter src/tableFilter.cpp)
rosbuild_add_executable(driver src/driver.cpp)
rosbuild_add_executable(bookGrabber src/bookGrabber.cpp)
rosbuild_add_executable(bookPlacer src/bookPlacer.cpp)
#rosbuild_add_executable(testFunction src/testFunction.cpp src/lib/angle_diff.cpp src/lib/angle_mean.cpp src/lib/book_edge_dist.cpp src/lib/edge2polar.cpp src/lib/line_clip.cpp src/lib/line_point_dist.cpp)
#rosbuild_add_executable(tableFilter src/tableFilter.cpp)
rosbuild_add_executable(bookFinder src/bookFinder.cpp src/util.cpp)
#include_directories(bookFinder `pkg-config opencv --cflags`)
#include_directories(/usr/local/include/opencv)
target_link_libraries(bookFinder cv)
#rosbuild_add_executable(testing src/testroutine.cpp)
#rosbuild_add_executable(testFunction src/testFunction.cpp src/lib/angle_diff.cpp src/lib/angle_mean.cpp src/lib/book_edge_dist.cpp src/lib/edge2polar.cpp src/lib/line_clip.cpp src/lib/line_point_dist.cpp)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: manifest.xml
Type: text/xml
Size: 633 bytes
Desc: not available
Url : /discuss/ros-users/attachments/20100806/504d6428/attachment-0001.bin
------------------------------
Message: 7
Date: Sat, 7 Aug 2010 14:08:08 +0200 (CEST)
From: Herman Bruyninckx <Herman.Bruyninckx@mech.kuleuven.be>
Subject: Re: [ros-users] The Limitations of URDF
To: "ros-users@code.ros.org" <ros-users@code.ros.org>
Message-ID: <alpine.DEB.2.00.1008071406410.11988@roble>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, 6 Aug 2010, David Lu!! wrote:
> Hey ROS-community,I've been working with URDF extensively for awhile, and am
> wondering what the future is for its development. Specifically, whether the
> format will be extended at all to address what I?perceive?to be some of its
> limitations.?
>
> I think the biggest limitation is the lack of graph support, which relates a
> link to two or more parent links (as opposed to the current tree structure). I
> believe this problem stems from KDL supporting only chains, and not graphs, but
> there are a number of?situations?where a graph structure is called for. The
> simplest example is a four bar linkage, which, as it stands, cannot be
> easily?model led?in URDF.?
COLLADA seems to be the future: it allows to model graphs, for example; it
is a real international standard; there are already ROS initiatives working
in this direction.
KDL is also going to adopt COLLADA, in the coming year or so.
Best regards,
Herman Bruyninckx
>
> One step toward fixing the problem could involve making some joints dependent on
> other joints. For the case of a parallelogram-shaped 4 bar, three of the joints
> could depend on one joint, but there is currently no support for that either. A
> similar situation involves gears/pulleys and other motion transferring
> mechanisms, i.e. two gears, each connected to a base with a continuous joint,
> and the angle of joint for the second gear is 4 times the angle for the first.?
>
> Having now tried to get collision detection working as well, it seems odd to
> have three different structures to specify the hierarchy of the machine. Its
> specified once in the URDF, and then separate groups are defined via parameters
> to define groups. Some of these groups coincide with whole xacro macros too.
> While I see that these distinctions may often need to be customized, it seems
> like it would be easier to do the customization via parameter, and not use the
> parameters to redefine everything again.?
>
> The last thing that concerns me is the PR2 specific extensions. I'm not exactly
> clear what they lend to the PR2, but I'm also not clear why they wouldn't apply
> to other robots.?
>
> [As an aside, does anyone know where the xml schema are for urdf? The PR2 file
> links to?http://playerstage.sourceforge.net/gazebo/xmlschema/, but there's
> nothing there.]
>
> What I'm wondering is whether any of these issues are currently being addressed,
> or whether I should work around them (either in my own code or in the ROS
> repository). Hopefully this will spark a discussion on any other hurdles people
> are having with URDF.?
>
> Thanks,
> David!!
>
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
------------------------------
Message: 8
Date: Sat, 7 Aug 2010 10:54:20 -0700 (PDT)
From: nitinDhiman <nitinkdhiman@gmail.com>
Subject: Re: [ros-users] karto package launch problems
To: ros-users@lists.sourceforge.net
Message-ID: <1281203660540-1036483.post@n3.nabble.com>
Content-Type: text/plain; charset="us-ascii"
Thanks Tully and Bhaskara,
This info will be very useful.
nitin
--
View this message in context: http://ros-users.122217.n3.nabble.com/karto-package-launch-problems-tp1025328p1036483.html
Sent from the ROS-Users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
ros-users mailing list
ros-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ros-users
------------------------------
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users
End of ros-users Digest, Vol 6, Issue 8
***************************************