On Sun, Aug 8, 2010 at 12:30 AM, 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!!" > Subject: Re: [ros-users] Collisions Outside the Bounding Box > (planning_environment) > To: ros-users@code.ros.org > Message-ID: > > 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 > Subject: Re: [ros-users] Collisions Outside the Bounding Box > (planning_environment) > To: ros-users@code.ros.org > Message-ID: > > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Aug 6, 2010 at 1:26 PM, David Lu!! 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 > Subject: Re: [ros-users] Arm Core Performance > To: > 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 > Subject: Re: [ros-users] The Limitations of URDF > To: ros-users@code.ros.org > Message-ID: > > 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!! 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. > > > > > 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!!" > Subject: Re: [ros-users] The Limitations of URDF > To: ros-users@code.ros.org > Message-ID: > > > > 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 > 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::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 > Subject: Re: [ros-users] The Limitations of URDF > To: "ros-users@code.ros.org" > Message-ID: > 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 > Tel: +32 16 328056 > EURON Coordinator (European Robotics Research Network) < > http://www.euron.org> > Open Realtime Control Services > Associate Editor JOSER , IJRR > > > ------------------------------ > > Message: 8 > Date: Sat, 7 Aug 2010 10:54:20 -0700 (PDT) > From: nitinDhiman > 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 > *************************************** >