ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org
Ask Your Question

andsok75's profile - activity

2018-06-29 11:48:22 -0600 received badge  Famous Question (source)
2015-07-09 10:40:03 -0600 received badge  Famous Question (source)
2015-07-01 17:27:44 -0600 received badge  Notable Question (source)
2015-05-27 09:54:43 -0600 received badge  Student (source)
2015-04-24 02:33:35 -0600 received badge  Notable Question (source)
2015-04-24 02:33:35 -0600 received badge  Famous Question (source)
2015-04-24 02:33:35 -0600 received badge  Popular Question (source)
2015-03-23 11:51:24 -0600 received badge  Notable Question (source)
2015-03-16 13:26:46 -0600 received badge  Popular Question (source)
2015-02-24 02:12:33 -0600 received badge  Popular Question (source)
2015-01-11 22:05:51 -0600 asked a question how to publish current scene in c++

If I launch rviz with

roslaunch ur5_moveit_config demo.launch limited:=true

I can then open 'Scene Object' tab and import a file with a constraint object. After that I can go back to the Context tab and publish the current scene by pressing a button. How do I achieve the same effect in a c++ code?

2015-01-08 21:27:12 -0600 received badge  Editor (source)
2015-01-08 21:26:30 -0600 asked a question a moveit pr2 tutorial terminates with a mutex_lock error

I run a moveit pr2 tutorial like so:

roslaunch pr2_moveit_tutorials move_group_interface_tutorial.launch

and it runs through different motions fine but at the end it shows an error and then just hangs. Is this an expected behaviour. What should I do to get rid of this error message and have the program finish cleanly? The error message looks like this:

move_group_interface_tutorial: /usr/include/boost/thread/pthread/recursive_mutex.hpp:110: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
[move_group_interface_tutorial-7] process has died [pid 13649, exit code -6, cmd /home/andrey/misc/ros/devel/lib/pr2_moveit_tutorials/move_group_interface_tutorial __name:=move_group_interface_tutorial __log:=/home/andrey/.ros/log/dbebe4c8-97ad-11e4-ba0e-90b11c98a3ed/move_group_interface_tutorial-7.log].
log file: /home/andrey/.ros/log/dbebe4c8-97ad-11e4-ba0e-90b11c98a3ed/move_group_interface_tutorial-7*.log

moveit_pr2 and the necessary pr2 modules are compiled and installed with catkin_make from source (indigo).

I also had a look at master.log and it shows the following error (not sure if it's relevant):

[rosmaster.threadpool][ERROR] 2015-01-09 14:49:10,269: Traceback (most recent call last):
 File "/opt/ros/indigo/lib/python2.7/dist-packages/rosmaster/threadpool.py", line 218, in run
result = cmd(*args)
File "/opt/ros/indigo/lib/python2.7/dist-packages/rosmaster/master_api.py", line 208, in publisher_update_task
xmlrpcapi(api).publisherUpdate('/master', topic, pub_uris)
File "/usr/lib/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.7/xmlrpclib.py", line 1578, in __request
verbose=self.__verbose
File "/usr/lib/python2.7/xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python2.7/xmlrpclib.py", line 1297, in single_request
return self.parse_response(response)
File "/usr/lib/python2.7/xmlrpclib.py", line 1473, in parse_response
return u.close()
File "/usr/lib/python2.7/xmlrpclib.py", line 793, in close
raise Fault(**self._stack[0])
Fault: <Fault -1: 'publisherUpdate: unknown method name'>
2015-01-08 00:47:08 -0600 asked a question moveit path planning ignores constraints

I'm using moveit planning pipeline (indigo-devel) to generate a path for ur5 with some obstacles in the environment, but the generated path goes through the obstacles. The obstacles are represented by a mesh, which defines a collision object imported into the planning scene like this

planning_scene->processCollisionObjectMsg( collision_object );

When I publish the planning scene, I can see the obstacles in rviz. A path is then generated with

planning_pipeline->generatePlan( planning_scene, request, response );

which uses the planning scene with the defined constraints. However, the path visualised in rviz goes right through the obstacles as if they were not there. ROS outputs the following

[ INFO] [1420698166.546178298]: Planner configuration 'manipulator[ESTkConfigDefault]' will use planner 'geometric::EST'. Additional configuration parameters will be set when the planner is constructed.
[ INFO] [1420698166.546475384]: manipulator[ESTkConfigDefault]: Attempting to use default projection.
[ INFO] [1420698166.549255239]: manipulator[ESTkConfigDefault]: Starting with 1 states
[ INFO] [1420698166.689949799]: manipulator[ESTkConfigDefault]: Created 3 states in 3 cells
[ INFO] [1420698166.690029336]: Solution found in 0.143339 seconds
[ INFO] [1420698166.690206928]: Path simplification took 0.000054 seconds
[ERROR] [1420698166.708755458]: Computed path is not valid. Invalid states at index locations: [ 4 5 ] out of 10. Explanations follow in command line. Contacts are published on /path_planning/display_contacts
[ INFO] [1420698166.710135263]: Found a contact between 'obstacle' (type 'Object') and 'wrist_2_link' (type 'Robot link'), which constitutes a collision. Contact information is not stored.
[ INFO] [1420698166.710176768]: Collision checking is considered complete (collision was found and 0 contacts are stored)
[ INFO] [1420698166.713790237]: Found a contact between 'obstacle' (type 'Object') and 'wrist_2_link' (type 'Robot link'), which constitutes a collision. Contact information is not stored.
[ INFO] [1420698166.713845565]: Collision checking is considered complete (collision was found and 0 contacts are stored)
[ERROR] [1420698166.716069182]: Completed listing of explanations for invalid states.

So, collision checking works fine and reports a collision. But the same obstacles are ignored by the path planning algorithm. What am I missing? What else do I need to do to make path planning take my collision objects into account? I was under the impression that just importing a collision object into the planning scene is sufficient. Obviously, something else needs to be done.