velocity control with simple_message protocol

[GoogleCodeExporter]

The current simple_message only allows for position-based control via the 
StandardMsgTypes.

To allow velocity-based control, the Universal Robot SIG would like to propose 
new MsgTypes for velocity based control similar to the current JOINT_TRAJ_PT 
and JOINT_TRAJ used for position-based control.

The implementation should be pretty straight forward; just add JOINT_VEL_PT and 
JOINT_VEL in the enumeration near line 65 in simple_message.h

Best regards

Thomas Andersen

Original issue reported on code.google.com by thomas.t...@gmail.com on 15 May 2013 at 3:00

[GoogleCodeExporter]

Thomas, we have a new joint trajectory FULL point that is basically a copy of 
the ROS message type 
(https://code.google.com/p/swri-ros-pkg/source/browse/branches/fs100_dev/industr
ial_core/simple_message/include/simple_message/joint_traj_pt_full.h ).  The new 
motoman driver uses this message and eventually we will port all clients to 
this type.  This new message type may be appropriate for you, assuming that the 
higher level ROS message JointTrajectoryPoint encodes enough information for 
your velocity control.  We can merge this change to the trunk/groovy_dev if you 
want.

I assume that the path that gets executed is more or less the same as the path 
under position control.  This begs the question, why use velocity control.  My 
understanding is that this velocity control will drift from traditional 
position control over the length of the path.  This is probably not desired for 
the majority of applications, but I may be mistaken.  I know this is a 
fundamental difference between our (SwRI) approach and Fraunhofer's approach.  
I think it's worth having this discussion.

Original comment by shaun.ed...@gmail.com on 15 May 2013 at 10:50

[GoogleCodeExporter]

In general, velocity-based control is preferable with sensor-based control, as 
it can yield much smoother trajectories. Just imagine a position controller 
that has overshot an intermediate target on a path and thus the joint is 
already at the position that you've commanded it to. It will then probably try 
to make a full stop for one control cycle, before speeding off to the next 
intermediate point.
A velocity controller would just descrease the speed slightly until the desired 
and actual positions align again.

If you need to follow a specific path in your workspace, then position control 
is usually better, especially for a robot with a lot of revolute joints. But if 
you image a robot with mainly prismatic joints (i.e. a typical X-Y table), then 
drifting won't be a problem with velocity-based control, but position-based 
control might give you jagged trajectories. 
It all comes down to using the right tool for the job, and while position-based 
control is good for a lot of robot application, for some it just doesn't cut 
it. I see no reason not to support velocity-based control in ROS, even if it is 
only a small selection of tasks where it is useful.

Specific for the Universal Robot, we also need velocity messages for 
initializing the joints to find their actual position, so the alternative could 
be vendor-specific messages. 

It looks like the new joint trajectory full point can give us what we want, by 
just setting the position ValidFieldType to false, so if you could merge that 
change to the trunk/groovy_dev, then it would be great. It makes no sense to 
change the old simple_message, if this is soon deprecated anyway.

Original comment by thomas.t...@gmail.com on 16 May 2013 at 10:00

[GoogleCodeExporter]

I understand the justification for velocity-based control, as an application 
demands.

I think using the new JointTrajPtFull message to pass this velocity data the 
robot makes sense, rather than creating a new message type.  However, I don't 
know that this requires any changes to the "validFields" flag.  The ROS client 
should transparently pass through data to the UR server, using the validFields 
flag to indicate when ROS sends empty arrays for one of the 
position/velocity/acceleration fields.  The robot client can simply ignore the 
position fields if it is planning to use pure velocity-based control.  Or, in 
the scenario you describe above, the robot can monitor the position error to 
use as an input to the velocity-control loop.  In either case, I don't know 
that there is a need for the ROS client to strip the position data out of the 
trajectory data.

Also, I don't think the old "JointTrajPt" simple_message is planned to be 
deprecated.  Some robots will require the simplified single-velocity command 
format, and this calculation is often more easily performed on the PC than the 
robot controller.  Instead, we may see each specific robot client choose to 
send either the simplified JointTrajPt comand message or the complete 
JointTrajPtFull message, depending on the needs of the robot-side driver.  Note 
that the fs100_dev branch also includes modifications to the 
industrial_robot_client library to support this increased flexibility in 
simple_message types.  This may allow you to use the standard 
industrial_robot_client (or an adapted version of it) for the ROS-side client, 
if this meets your needs.

One final thought: You may consider whether the robot-side server should 
provide modes for both position-based control and velocity-based control.  This 
would add complexity, but would also allow users to choose the appropriate 
server for their application.  Ideally, this would be a single package that is 
installed on the robot, with some sort of mechanism to switch between control 
modes.  Another approach would be to provide separate drivers for each mode, 
but this might complicate the installation / deployment / maintenance process.  
Just something you might consider when developing your new interface.

Original comment by jz...@swri.org on 16 May 2013 at 1:03

[GoogleCodeExporter]

I didn't mean to suggest that any changes was needed to the JointTrajPtFull 
message, I was just speculating out loud as to how I saw it used (which is the 
same as you suggest).

I think we will use the JointTrajPtFull for communication and consider this 
"issue" solved :)

Original comment by thomas.t...@gmail.com on 17 May 2013 at 9:06

[GoogleCodeExporter]

Jeremy, I'll assign the bug to you to merge in the changes from the FS100 
branch.  

I think the discussion about changing control modes is also important.  
Currently such functionality is not included in the spec.  In order to simplify 
development and allow us to support as many robot platforms as we could with 
limited effort, we chose to ignore this limitation.  I have included this 
discussion on the industrial robot driver spec future wishlist. 
http://ros.org/wiki/Industrial/Industrial_Robot_Driver_Spec/future

Original comment by shaun.ed...@gmail.com on 17 May 2013 at 2:24

[GoogleCodeExporter]

Fixed in r1349.  JointTrajPtFull and JointFeedback messages added to 
simple_message.

Original comment by jz...@swri.org on 17 May 2013 at 9:19

• Changed state: Fixed