search

ros-industrial-attic / swri-ros-pkg

Automatically exported from code.google.com/p/swri-ros-pkg
7 stars 9 forks source link

Motion job fails to start when outputs are forced #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Force an output on the motoman controller (ex. Pendant: IN/OUT->External 
Output).  Make certain the output is either unused or it is safe to actuate 
whatever the output is linked to
2. Bring up the arm navigation warehouse for the motoman arm (ex. roslauch 
sia10d_arm_navigation planning_scene_warehouse_viewer_sia10d_mesh_real.launch)
3. Plan and execute a move.

What is the expected output? What do you see instead?

The controller should turn on and begin to execute the motion.  Instead, the 
controller will turn on and a message will appear on the pendant requesting an 
OK to move with simulated outputs.  Indicating it is OK and pressing the START 
button does not allow motion.  Sending another motion request will start 
motion.  The resulting motion is both trajectories, one after the other.

Original issue reported on code.google.com by shaun.ed...@gmail.com on 20 Dec 2011 at 1:43

GoogleCodeExporter commented 9 years ago 
The solution to this problem is most likely to determine how to tell that IO is 
simulated from the motoman API.  In cases where it is, the status of the motion 
program should be checked over a longer time.  What it appears is happening is 
that motion is enabled successfully and then disabled a short time later by the 
controller.  However, by that point the motoplus applicaiton has assumed that 
the motion was enabled and remains enabled.

Original comment by shaun.ed...@gmail.com on 20 Dec 2011 at 1:45

GoogleCodeExporter commented 9 years ago 
Another work around has been found where instead of forcing IO, the Universal 
IO (which is mapped to the network IO) can be set.  This is not the same as 
forcing since the robot program can reset these IO.  Also, it was found that 
pressing the START button will resume/start motion.

Original comment by shaun.ed...@gmail.com on 16 Jan 2012 at 10:16

GoogleCodeExporter commented 9 years ago 
The priority of this bug was changed to low since a workaround was found (see 
comment 2).  However this bug is still important as in an actual application, 
IO forcing could be used.

Original comment by shaun.ed...@gmail.com on 4 Mar 2012 at 1:59

GoogleCodeExporter commented 9 years ago 
These issues have been corrected or made obsolete with the backporting of the 
fs100 driver to the dx100.  See here: 
https://github.com/ros-industrial/motoman/pull/14

Original comment by shaun.ed...@gmail.com on 6 Sep 2013 at 2:43