| 2016-09-14 12:10:23 -0500 | received badge | ● Nice Answer
(source)
|
| 2015-06-22 00:15:40 -0500 | marked best answer | arm_navigation stack I used the Planning Description Configuration Wizard and autogenerated the proper files. I then chose world as my base link and end_effector as the tip link. when I roslaunch al5b_arm_navigation.launch and rosrun the initialisation node at the bottom of this post for my joint_states topic, I get the output [ WARN] [1338200653.324212205]: Got joint state update but did not update some joints for more than 1 second. Turn on DEBUG for more info
This is the Urdf <?xml version="1.0" ?>
<!-- =================================================================================== -->
<!-- | This document was autogenerated by xacro from /home/oliver/ros_workspace/scanner_3d/robot/al5b.urdf.xacro | -->
<!-- | EDITING THIS FILE BY HAND IS NOT RECOMMENDED | -->
<!-- =================================================================================== -->
<robot name="al5b">
<link name="world">
<inertial>
<mass value="0.05"/>
<origin xyz="-0.0 0.0 -10.0"/>
<inertia ixx="1.0" ixy="0.0" ixz="0.0" iyy="1.0" iyz="0.0" izz="1.0"/>
</inertial>
<collision>
<origin rpy="0 0 0" xyz="0 0 0.15"/>
<geometry>
<box size="0.4 0.4 0.3"/>
</geometry>
</collision>
</link>
<joint name="base_joint" type="fixed">
<parent link="world"/>
<child link="shoulder_roll_link"/>
</joint>
<link name="shoulder_roll_link">
<collision>
<origin rpy="0 0 0" xyz="0 0 0.85"/>
<geometry>
<box size="3.8 3.8 1.9"/>
</geometry>
</collision>
</link>
<joint name="shoulder_roll_joint" type="revolute">
<parent link="shoulder_roll_link"/>
<child link="shoulder_flex_link"/>
<origin rpy="0 0 0" xyz="0 0 1.725"/>
<axis xyz="0 0 1"/>
<limit effort="30" lower="-1.57" upper="1.57" velocity="1.0"/>
</joint>
<link name="shoulder_flex_link"/>
<joint name="shoulder_lift_joint" type="revolute">
<parent link="shoulder_flex_link"/>
<child link="upperarm_link"/>
<origin rpy="-1.57 -1.57 0" xyz="0 0 0.9"/>
<axis xyz="0 0 1"/>
<limit effort="30" lower="-1.57" upper="1.57" velocity="1.0"/>
</joint>
<link name="upperarm_link">
<collision>
<origin rpy="0 0 0" xyz="1.5 0 0"/>
<geometry>
<box size="3.00 0.9825 2.622"/>
</geometry>
</collision>
</link>
<joint name="elbow_flex_joint" type="revolute">
<parent link="upperarm_link"/>
<child link="forearm_link"/>
<origin rpy="0 0 0" xyz="4.75 0 0"/>
<axis xyz="0 0 1"/>
<limit effort="30" lower="-1.57" upper="1.57" velocity="1.0"/>
</joint>
<link name="forearm_link">
<collision>
<origin rpy="0 0 0" xyz="1.66 0 0"/>
<geometry>
<box size="6.16 1.1 1.62"/>
</geometry>
</collision>
</link>
<joint name="wrist_flex_joint" type="revolute">
<parent link="forearm_link"/>
<child link="wrist_flex_link"/>
<origin rpy="0 0 0" xyz="5.00 0 0"/>
<axis xyz="0 0 1"/>
<limit effort="30" lower="-1.57" upper="1.57" velocity="1.0"/>
</joint>
<link name="wrist_flex_link">
<collision>
<origin rpy="0 0 0" xyz="1.33 0 -0.805"/>
<geometry>
<box size="0.575 1.61 3.22"/>
</geometry>
</collision>
</link>
<joint name="wrist_roll_joint" type="revolute">
<parent link="wrist_flex_link"/>
<child link="end_effector"/>
<origin rpy="1.57 0 1.57" xyz="1.64 0 0"/>
<axis xyz="0 0 1"/>
<limit effort="30" lower="-1.57" upper="1.57" velocity="1.0"/>
</joint>
<link name="end_effector">
<collision>
<origin rpy="0 0 0" xyz="0.52 0 1 ...
(more) |
| 2014-09-24 09:05:20 -0500 | received badge | ● Famous Question
(source)
|
| 2014-01-28 17:25:56 -0500 | marked best answer | remapping with robot_state_publisher I am using the arm_navigation stack and can't seem to remap a published sensor_msgs/JointState topic through the robot_state_publisher generic launch file. The remapping and tf file is: <launch>
<node pkg="robot_state_publisher" type="state_publisher" name="rob_st_pub" >
<remap from="joint_states_tf" to="joint_states" />
</node>
</launch>
The topic is published correctly (verified with rostopic echo) under "/joint_states_tf" through this node #include <ros/ros.h>
#include <stdio.h>
#include <string>
#include <iostream>
#include <sensor_msgs/JointState.h>
int main(int argc, char **argv){
ros::init(argc,argv,"state_publisher");
ros::NodeHandle nh;
ros::Publisher pub = nh.advertise<sensor_msgs::JointState>("joint_states_tf",1000);
ros::Rate lr(10);
sensor_msgs::JointState msg;
msg.name.push_back("tip_joint");
msg.name.push_back("wrist_roll_joint");
msg.name.push_back("wrist_flex_joint");
msg.name.push_back("wrist_roll_joint");
msg.name.push_back("elbow_flex_joint");
msg.name.push_back("shoulder_lift_joint");
msg.name.push_back("shoulder_roll_joint");
msg.name.push_back("base_joint");
for (int i = 0; i < 8; i++){
msg.position.push_back(0.0);
msg.velocity.push_back(0.0);
msg.effort.push_back(0.0);
}
while(ros::ok()){
msg.header.stamp = ros::Time::now();
pub.publish(msg);
ros::spinOnce();
}
}
yet the output when using rostopic echo /joint_states
is null and but the /tf topic is published correctly. |
| 2014-01-28 17:25:54 -0500 | marked best answer | move_arm_warehouse package I've rebuilt ros from sources completely and I don't think it's my installation, but the python script in the move_arm_warehouse package <move_arm_warehouse>./scripts/create_launch_files.py
uses the following code directoryName = roslib.packages.is_pkg_dir(robotName + "_arm_navigation")
which gives the following error Traceback (most recent call last):
File "./scripts/create_launch_files.py", line 16, in <module>
if(not roslib.packages.is_pkg_dir(directoryName)):
AttributeError: 'module' object has no attribute 'is_pkg_dir'
anyone else had this problem? is the stack arm_navigation_experimental depreciated to something or not yet updated... or have I don't something wrong? |
| 2014-01-28 17:25:50 -0500 | marked best answer | arm_navigation stack I'm fairly new to ROS and especially the arm_navigation stack and was just wondering if there's a simpler method to determine the inverse kinematics of a custom/undefined manipulator than described in the Running arm navigation on non-PR2 arm, which describes altering the pr2_arm_kinematics stack's services and source to suit a custom manipulator.
I followed the arm_navigation tutorials and in the inverse kinematics tutorial the source requires services "pr2_right_arm_kinematics/get_ik_solver_info" and "pr2_right_arm_kinematics/get_ik", which I'm sure are only relevant to the pr2 - as is in the description of the pr2_arm_kinematics stack. Likewise with the iROS tutorial and all other's I've found. Thanks in advance EDIT: The reason I am not a fan of this method is than I have a 5 DOF robot, not 7. meaning I would have to go through several ~500 line source code files to adapt the code. Or I could go the ineloquent task of added 2 fixed joints and nonexistant links |
| 2013-10-16 20:00:09 -0500 | marked best answer | robot_state_publisher Is there a reason why the robot_state_publisher is publishing joints at different time stamps? I'm new to using this system and need some help with it. My launch file is <launch>
<include file="$(find hokuyo_node)/hokuyo_test.launch"/>
<node pkg="robot_state_publisher" type="state_publisher" name="rob_st_pub" >
<param name="publish_frequency" value="2"/>
<remap from="joint_states" to="al5b_joint_states" />
</node>
<param name="use_rep_117" value="true" />
</launch>
And the publisher node is publishing at 100 Hz to try and send the data. I've varied both frequencies in case the node publisher could not catch up but that doesn't seem to be the case. Are there extra parameters to set to get the tf to sample all links in the tree at the same time? EDIT: I Attempted publishing and publish_frequency frequencies across the board - I understand this was just the latest attempt. |
| 2013-01-28 20:37:02 -0500 | received badge | ● Famous Question
(source)
|
| 2013-01-05 19:33:40 -0500 | received badge | ● Necromancer
(source)
|
| 2013-01-04 14:24:59 -0500 | answered a question | Tutorial Building a ROS Package: "Rosdep experienced an internal error: 'NoneType' object has no attribute 'copy'" There's a lot here so I don't know whether you've got your answer yet or not, but I don't think anyone has said these steps explicitly. The installation requires you to uninstall the pip version if you're running Ubuntu (and trying to install ros-groovy). So follow the installation guide normally up to this step $ rosdep update
Then if you get the error again after reinstalling Ubuntu (which you said you're doing in your final edit, however that should not affect anything), call: $ sudo pip uninstall rosdep
to remove the pip version, then try again with $ sudo rm /etc/ros/rosdep/sources.list.d/20-default.list
$ sudo rosdep init
$ rosdep update
Hope that works |
| 2012-11-23 18:59:15 -0500 | marked best answer | ROS rl (texplore) package Hello, I understand that the rl texplore stack has the ability to model a continuous state environment. I'm having some trouble running the agent/environment packages in a unique environment for the package given my problem is modelled with an 'infinitely' large state-space. Is this possible, or is there a known workaround? Or will I have to cut my losses and discretize the state-space? Thanks for any knowledge on this area. Regards, Oliver |
| 2012-11-11 11:40:45 -0500 | received badge | ● Famous Question
(source)
|
| 2012-10-23 13:47:34 -0500 | received badge | ● Favorite Question
(source)
|
| 2012-10-23 13:47:20 -0500 | received badge | ● Good Question
(source)
|
| 2012-10-05 05:19:10 -0500 | received badge | ● Notable Question
(source)
|
| 2012-10-04 22:30:27 -0500 | commented answer | cv_bridge memory issues Hmm, that did seem to be the problem, but I thought I had done that in the past. As a side, do you know why it takes a while to process the point cloud from the openni package? between any other callback and a callback involving sensor_msgs::PointCloud2 there is a significant delay |
| 2012-10-04 00:03:52 -0500 | commented answer | cv_bridge memory issues The segmentation fault actually occurs after the callback scope. It seems like, inside the function, I free 921,624 bytes of image data. And after the function boost, ROS and OpenCV processes release memory 0, 12 and 921,616 bytes into that free'd memory block, respectively. Any ideas? |
| 2012-10-03 06:52:35 -0500 | received badge | ● Popular Question
(source)
|
| 2012-10-02 19:23:51 -0500 | commented answer | cv_bridge memory issues Already tried that, I get a segmentation fault so I removed it - the cv_ptr->image cannot be released apparently. |
| 2012-10-02 04:05:07 -0500 | asked a question | cv_bridge memory issues I'm having problems with memory when it comes to using the cv_ptr->image from this tutorial. How would I copy the image to use it as an IplImage* for the rest of the program so that I can release all data at the end? This is my latest attempt - imageBGR is for altering, imageRaw is the raw image to be sent around to a few functions/callbacks etc. void ImageCb(const sensor_msgs::ImageConstPtr &msg)
{
cv_bridge::CvImagePtr cv_ptr;
try {
cv_ptr = cv_bridge::toCvCopy(msg, enc::BGR8);
}
catch (cv_bridge::Exception& e){
ROS_ERROR("cv_bridge exception: %s", e.what());
return;
}
IplImage* imageRaw, *imageBGR;
imageRaw = cvCreateImage( cvSize(640,480) ,IPL_DEPTH_8U,3);
*imageRaw = cv_ptr->image;
imageBGR = cvCloneImage( imageRaw );
//do stuff
cvReleaseImage( &imageBGR );
}
I can't use CvMat because I'm using an obsolete package that takes in IplImage*. I get the following error after running the code above for a bit terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted (core dumped)
If I release the imageRaw image, then I get a segmentation fault and this output from valgrind ==11677== Invalid read of size 4
==11677== at 0x4229CD6: boost::detail::sp_counted_impl_pd<cv_bridge::CvImage*, boost::detail::sp_ms_deleter<cv_bridge::CvImage> >::dispose() (mat.hpp:366)
==11677== by 0x807781D: boost::detail::shared_count::~shared_count() (shared_count.hpp:217)
==11677== by 0x80787FF: boost::shared_ptr<cv_bridge::CvImage>::~shared_ptr() (shared_ptr.hpp:168)
==11677== by 0x8073D99: ImageCb(boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&) (state_sensor.cpp:173)
==11677== by 0x807DCA8: boost::detail::function::void_function_invoker1<void (*)(boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&), void, boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&>::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&) (function_template.hpp:112)
==11677== by 0x4759603: image_transport::RawSubscriber::internalCallback(boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&, boost::function<void ()(boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&)> const&) (function_template.hpp:1013)
==11677== by 0x4756802: boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf2<void, image_transport::SimpleSubscriberPlugin<sensor_msgs::Image_<std::allocator<void> > >, boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&, boost::function<void ()(boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&)> const&>, boost::_bi::list3<boost::_bi::value<image_transport::SimpleSubscriberPlugin<sensor_msgs::Image_<std::allocator<void> > >*>, boost::arg<1>, boost::_bi::value<boost::function<void ()(boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&)> > > >, void, boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&>::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&) (mem_fn_template.hpp:280)
==11677== by 0x474C965: boost::detail::function::void_function_obj_invoker1<boost::function<void ()(boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&)>, void, boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> >::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const>) (function_template.hpp:1013)
==11677== by 0x475FBFE: ros::SubscriptionCallbackHelperT<boost::shared_ptr<sensor_msgs::Image_<std::allocator<void> > const> const&, void>::call(ros::SubscriptionCallbackHelperCallParams&) (function_template.hpp:1013)
==11677== by 0x4128C06: ros::SubscriptionQueue::call() (in /opt/ros/fuerte/lib/libroscpp.so)
==11677== by 0x40D8A86: ros::CallbackQueue::callOneCB(ros::CallbackQueue ...
(more) |
| 2012-10-01 06:51:39 -0500 | received badge | ● Famous Question
(source)
|
| 2012-10-01 03:14:07 -0500 | received badge | ● Nice Question
(source)
|
| 2012-09-30 17:15:26 -0500 | commented question | OpenNI Subscription can subscribe to more than one at a time, but when you un-subscribe, then re-subscribe, the error happens again. |
| 2012-09-27 09:22:49 -0500 | received badge | ● Notable Question
(source)
|
| 2012-09-27 06:30:08 -0500 | commented question | OpenNI Subscription On a related topic, what is this 'nodelet' thing? When I instantiate new blob tracker's the nodelet cpu usage skyrockets |
| 2012-09-26 22:00:10 -0500 | received badge | ● Popular Question
(source)
|
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.