ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

mklingen's profile - activity

2018-03-14 11:17:02 -0500 received badge  Famous Question (source)
2018-01-24 09:24:15 -0500 received badge  Taxonomist
2015-06-03 11:27:27 -0500 received badge  Notable Question (source)
2015-05-20 11:24:53 -0500 received badge  Famous Question (source)
2015-03-16 13:05:21 -0500 commented answer ros_control behaves differently for continuous joint robot between hydro and indigo

I am not using MoveIt to construct trajectories. I am sending a hard-coded trajectory message. The problem isn't in trajectory construction but in controlling the robot.

2015-03-16 11:46:39 -0500 commented answer ros_control behaves differently for continuous joint robot between hydro and indigo

Thank you. I updated my URDF to contain this, but unfortunately it did not help. The issue appears to be something along the lines of, the robot will oscillate around the target, the oscillations get bigger and bigger, rather than smaller and smaller. It's almost like the goal conditions are wrong.

2015-03-16 11:23:18 -0500 received badge  Student (source)
2015-03-16 09:08:02 -0500 commented answer ros_control behaves differently for continuous joint robot between hydro and indigo

Are transmissions now required? As in, you added a transmission interface where there wasn't one before?

2015-03-15 20:03:00 -0500 received badge  Notable Question (source)
2015-03-14 05:19:17 -0500 received badge  Popular Question (source)
2015-03-13 12:17:49 -0500 asked a question ros_control behaves differently for continuous joint robot between hydro and indigo

I am trying to upgrade from ros hydro to ros indigo; and everything has been going fine aside from ros_control. It seems there has been some change that breaks the velocity trajectory controller for my continuous joint robot. The velocity controller seems to go the wrong direction when trying to execute a simple trajectory. I have verified that the problem does not exist in hydro by setting my ros master to an external machine that is running ros_control in hydro, and sending the command from my indigo machine.

Here's a screenshot of the joint errors reported by the joint_trajectory_controller shooting off. For joint 3, you see desired and actual starting out the same, then a small control error of ~0.3 is applied to make it follow a trajectory. The controller just shoots off to infinity. Note the same controller works in hydro, but not in indigo.

image description

And here's the state of the controller manager:

image description

I tried downgrading my ros_control, and ros_controllers to the versions found in the ros-hydro-ros-control debian, but this did not fix the issue. I had to build these from source, and it required changing the urdfdom version referenced by ros_control to the one locally installed by indigo (which could be a clue).

Here are the contents of my URDF.

Has anything changed in the parsing of URDF files, or in joint_trajectory_controller that might have caused this issue?

2015-02-10 10:48:40 -0500 received badge  Popular Question (source)
2015-02-09 16:41:11 -0500 commented answer Copying Files into Devel Space?

Thank you, I simply used ros::package::getPath to find the files in the source space instead

2015-02-09 16:40:54 -0500 received badge  Scholar (source)
2015-02-09 16:40:53 -0500 received badge  Supporter (source)
2015-02-09 16:28:33 -0500 commented answer Copying Files into Devel Space?

I see. So I should, for instance, use roslib itself to find the files in source space?

2015-02-09 15:52:45 -0500 asked a question Copying Files into Devel Space?

My ROS node has some data files (specifically, GLSL shaders), that it needs to run. How can I configure catkin to copy these files over to the devel space from src, so that when rosrun or roslaunch is called, the files are in the proper place?

EDIT: Let me clarify. I have a couple of files in my src directory. My executable is assuming that these files are going to be in some path relative to itself (in this case, it is in the devel) directory. i.e, I have "./some_path_to_file" in places in my code. Right now, I manually copy these files into the devel space so the executable can access them. What are better alternatives to this?

2014-10-26 16:14:05 -0500 received badge  Famous Question (source)
2014-04-30 02:31:21 -0500 received badge  Famous Question (source)
2014-04-01 08:45:54 -0500 received badge  Notable Question (source)
2013-11-29 02:22:23 -0500 received badge  Popular Question (source)
2013-11-14 11:02:47 -0500 received badge  Notable Question (source)
2013-10-28 06:14:29 -0500 received badge  Popular Question (source)
2013-10-23 06:25:04 -0500 asked a question [RVIZ] Interactive marker client threading issues

So, I have an interactive marker server, and RVIZ as an interactive marker client (in Fuerte). I also have several threaded nodes running which are calling ros::SpinOnce() in different threads. It seems that the interactive marker client in RVIZ is just using the global callback queue to handle its updates, rather than keeping its own callback queue.

This would be okay, except for the fact that interactive markers make liberal use of the openGL context to create and destroy openGL texture data (particularly for labels). So, this results in segfaults all the time when OpenGL context is being used, and multiple threads are calling ros::SpinOnce. Since I don't own the library calling SpinOnce, what are my options to prevent such segfaults?

This is the offending stack trace, btw, when a marker is getting deleted by the marker server:

#0  0x00007fffd1166949 in glDeleteBuffersARB () from /usr/lib/nvidia-304/libGL.so.1
#1  0x00007fff6d3ca388 in Ogre::GLHardwareVertexBuffer::~GLHardwareVertexBuffer (this=0x7fff6deaad78, __in_chrg=<optimized out>)
    at /tmp/buildd/ros-fuerte-visualization-common-1.8.4/debian/ros-fuerte-visualization-common/opt/ros/fuerte/stacks/visualization_common/ogre/build/ogre_src_v1-7-3/RenderSystems/GL/src/OgreGLHardwareVertexBuffer.cpp:60
#2  0x00007fff6d3ca3b9 in Ogre::GLHardwareVertexBuffer::~GLHardwareVertexBuffer (this=0x7fff6deaad78, __in_chrg=<optimized out>)
    at /tmp/buildd/ros-fuerte-visualization-common-1.8.4/debian/ros-fuerte-visualization-common/opt/ros/fuerte/stacks/visualization_common/ogre/build/ogre_src_v1-7-3/RenderSystems/GL/src/OgreGLHardwareVertexBuffer.cpp:61
#3  0x00007fffd346678f in Ogre::SharedPtr<Ogre::HardwareVertexBuffer>::destroy (this=0x7fff6ddb6f20)
    at /tmp/buildd/ros-fuerte-visualization-common-1.8.4/debian/ros-fuerte-visualization-common/opt/ros/fuerte/stacks/visualization_common/ogre/build/ogre_src_v1-7-3/OgreMain/include/OgreSharedPtr.h:232
#4  0x00007fffd34fecc0 in release (this=0x7fff6ddb6f20)
    at /tmp/buildd/ros-fuerte-visualization-common-1.8.4/debian/ros-fuerte-visualization-common/opt/ros/fuerte/stacks/visualization_common/ogre/build/ogre_src_v1-7-3/OgreMain/include/OgreSharedPtr.h:218
#5  ~SharedPtr (this=0x7fff6ddb6f20, __in_chrg=<optimized out>)
    at /tmp/buildd/ros-fuerte-visualization-common-1.8.4/debian/ros-fuerte-visualization-common/opt/ros/fuerte/stacks/visualization_common/ogre/build/ogre_src_v1-7-3/OgreMain/include/OgreSharedPtr.h:155
#6  ~HardwareVertexBufferSharedPtr (this=0x7fff6ddb6f20, __in_chrg=<optimized out>)
    at /tmp/buildd/ros-fuerte-visualization-common-1.8.4/debian/ros-fuerte-visualization-common/opt/ros/fuerte/stacks/visualization_common/ogre/build/ogre_src_v1-7-3/OgreMain/include/OgreHardwareVertexBuffer.h:74
#7  ~pair (this=0x7fff6ddb6f18, __in_chrg=<optimized out>) at /usr/include/c++/4.6/bits/stl_pair.h:87
#8  destroy (p=0x7fff6ddb6f18, this=<optimized out>)
    at /tmp/buildd/ros-fuerte-visualization-common-1.8.4/debian/ros-fuerte-visualization-common/opt/ros/fuerte/stacks/visualization_common/ogre/build/ogre_src_v1-7-3/OgreMain/include/OgreMemorySTLAllocator.h:169
#9  _M_destroy_node (__p=0x7fff6ddb6ef8, this=<optimized out>) at /usr/include/c++/4.6/bits/stl_tree.h:394
#10 std::_Rb_tree<unsigned short, std::pair<unsigned short const, Ogre::HardwareVertexBufferSharedPtr>, std::_Select1st<std::pair<unsigned short const, Ogre::HardwareVertexBufferSharedPtr> >, std::less<unsigned short>, Ogre::STLAllocator<std::pair<unsigned short const, Ogre::HardwareVertexBufferSharedPtr>, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > >::_M_erase (
    this=0x7fff6ddb6de0, __x=0x7fff6ddb6ef8) at /usr/include/c++/4.6/bits/stl_tree.h:1076
#11 0x00007fffd34fece8 in std::_Rb_tree<unsigned short, std::pair<unsigned short const, Ogre::HardwareVertexBufferSharedPtr>, std::_Select1st<std::pair<unsigned short const, Ogre::HardwareVertexBufferSharedPtr> >, std::less<unsigned short>, Ogre::STLAllocator<std::pair<unsigned short const, Ogre::HardwareVertexBufferSharedPtr>, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > >::_M_erase (this=0x7fff6ddb6de0, __x=0x7fff6ddb6e68) at /usr/include/c++/4.6 ...
(more)
2013-10-10 06:32:54 -0500 answered a question [RVIZ bug] STL Gouraud/Phong/Smooth Shading

Oops, I've forgotten that STL files actually don't even have index data. That's too bad. I will have to fake it by deleting repeated vertices.

2013-10-09 06:28:56 -0500 received badge  Editor (source)
2013-10-09 06:25:59 -0500 asked a question [RVIZ bug] STL Gouraud/Phong/Smooth Shading

Hi guys,

I'm trying to write an OpenRAVE visualizer based on librivz in Fuerte. As part of this, I need to load and display various kinds of models, but for now I am assuming just the model types RVIZ already supports (assimp, Collada, STL, and ogre .mesh).

I have noticed that no matter what indices/normals are defined in the STL files, and no matter what I set the shader to (Gourand/Phong/whatever), RVIZ, without fail, renders the model as flat shaded. I have narrowed down the problem to an offending function in rviz' STL loader, which simply throws away index buffer information and repeats vertices. That is here:

Ogre::MeshPtr STLLoader::toMesh(const std::string& name)
00166 {
00167   Ogre::ManualObject* object = new Ogre::ManualObject( "the one and only" );
00168   object->begin( "BaseWhiteNoLighting", Ogre::RenderOperation::OT_TRIANGLE_LIST );
00169 
00170   unsigned int vertexCount = 0;
00171   V_Triangle::const_iterator it = triangles_.begin();
00172   V_Triangle::const_iterator end = triangles_.end();
00173   for (; it != end; ++it )
00174   {
00175     if( vertexCount >= 2004 )
00176     {
00177       // Subdivide large meshes into submeshes with at most 2004
00178       // vertices to prevent problems on some graphics cards.
00179       object->end();
00180       object->begin( "BaseWhiteNoLighting", Ogre::RenderOperation::OT_TRIANGLE_LIST );
00181       vertexCount = 0;
00182     }
00183 
00184     const STLLoader::Triangle& tri = *it;
00185 
00186     float u, v;
00187     u = v = 0.0f;
00188     object->position( tri.vertices_[0] );
00189     object->normal( tri.normal_);
00190     calculateUV( tri.vertices_[0], u, v );
00191     object->textureCoord( u, v );
00192 
00193     object->position( tri.vertices_[1] );
00194     object->normal( tri.normal_);
00195     calculateUV( tri.vertices_[1], u, v );
00196     object->textureCoord( u, v );
00197 
00198     object->position( tri.vertices_[2] );
00199     object->normal( tri.normal_);
00200     calculateUV( tri.vertices_[2], u, v );
00201     object->textureCoord( u, v );
00202 
00203     object->triangle( vertexCount + 0, vertexCount + 1, vertexCount + 2 );
00204 
00205     vertexCount += 3;
00206   }
00207 
00208   object->end();
00209 
00210   Ogre::MeshPtr mesh = object->convertToMesh( name, Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME );
00211   mesh->buildEdgeList();
00212 
00213   delete object;
00214 
00215   return mesh;
00216 }

Basically, what's wrong with this code is that it's iterating through the triangles of the mesh, rather than the vertices, and thus repeats vertices. This throws away index buffer information, which Ogre needs to render meshes properly. (unless I'm mistaken, and "buildEdgeList" takes care of this).

Can anyone shed light on this problem?

2013-09-27 18:49:50 -0500 received badge  Teacher (source)
2013-09-27 18:49:50 -0500 received badge  Necromancer (source)
2013-09-27 08:36:25 -0500 answered a question How to correctly compile a C# package?

I fixed the problem!!

Surprising nobody has gotten around to compiling a C# package in almost a year. The answer is this:

Add <depend package="std_msgs"/>

To your manifest.xml. Those messages will magically get compiled and put into your lib directory.