[ros-users] Arm Core Performance

siva shankar sivasankar.robot at gmail.com
Sun Aug 8 16:38:21 UTC 2010


On Sun, Aug 8, 2010 at 12:30 AM, <ros-users-request at code.ros.org> wrote:

> Send ros-users mailing list submissions to
>        ros-users at 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 at code.ros.org
>
> You can reach the person managing the list at
>        ros-users-owner at 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 at gmail.com>
> Subject: Re: [ros-users] Collisions Outside the Bounding Box
>        (planning_environment)
> To: ros-users at code.ros.org
> Message-ID:
>        <AANLkTinDqbhEbt1J6VNLHvzWcaVYAUYq8Qtv6DWy_dn4 at 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 at willowgarage.com>
> Subject: Re: [ros-users] Collisions Outside the Bounding Box
>        (planning_environment)
> To: ros-users at code.ros.org
> Message-ID:
>        <AANLkTi=RUSrLPuX1x=ZY5+rgEu1RMO1TOfs6297s2kT9 at mail.gmail.com<ZY5%2BrgEu1RMO1TOfs6297s2kT9 at mail.gmail.com>
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Aug 6, 2010 at 1:26 PM, David Lu!! <davidvlu at 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 at 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 at mavt.ethz.ch>
> Subject: Re: [ros-users] Arm Core Performance
> To: <ros-users at code.ros.org>
> Message-ID: <4C5C7B91.6010309 at 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 at willowgarage.com>
> Subject: Re: [ros-users] The Limitations of URDF
> To: ros-users at code.ros.org
> Message-ID:
>        <AANLkTinuZZg2DstoFU9E-cuo4d6NnCdfFfwP8iV3pOTe at 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 at 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 at 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 at gmail.com>
> Subject: Re: [ros-users] The Limitations of URDF
> To: ros-users at code.ros.org
> Message-ID:
>        <AANLkTim9oHu=hUs+cOQ_vKv-fv--zFt7AvfkqqbLJvuo at mail.gmail.com<hUs%2BcOQ_vKv-fv--zFt7AvfkqqbLJvuo at 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 at MIT.EDU>
> Subject: [ros-users] cv::Canny() error
> To: ros-users at code.ros.org
> Message-ID: <20100806180910.g8iii27pi8kk84go at 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 at mech.kuleuven.be>
> Subject: Re: [ros-users] The Limitations of URDF
> To: "ros-users at code.ros.org" <ros-users at code.ros.org>
> Message-ID: <alpine.DEB.2.00.1008071406410.11988 at 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 at gmail.com>
> Subject: Re: [ros-users] karto package launch problems
> To: ros-users at lists.sourceforge.net
> Message-ID: <1281203660540-1036483.post at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ros-users
>
>
> ------------------------------
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
> End of ros-users Digest, Vol 6, Issue 8
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100808/29bc26e2/attachment-0003.html>


More information about the ros-users mailing list