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