ROS Control Computing Error Incorrectly with Negative Joint Limits on a Revolute Joint

edit

Hi,

I am attempting to use the ros_control effort_controllers/joint_position_controller to control a single revolute joint with limits in Gazebo 7. I am running Ubuntu16.04 with ROS Kinetic. What I noticed happening is immediately on unpausing the simulation, the controller outputs a maximum command.

The joint is defined as follows in the URDF:

<joint
name="joint1"
type="revolute">
<origin
  xyz="0 0 0.01"
  rpy="0 0 -1.5708" />
<parent
  link="base_link" />
<child
  link="link_1" />
<axis
  xyz="0 0 1" />
<limit
  lower="-3.6652"
  upper="3.6652"
  effort="10.0"
  velocity="0.5" />
<dynamics damping="0.1" friction="0.0"/></joint>

I looked at the controller state and noticed something very strange - the error was calculated as close to 2pi for a setpoint of 0.0 and a process-value of -1.09322889816e-05. This is not what I expected to occur.

Here is a snapshot of a controller state message:

header: 
  seq: 0
  stamp: 
    secs: 0
    nsecs:   2000000
  frame_id: ''
set_point: 0.0
process_value: -1.09322889816e-05
process_value_dot: -0.000142460010446
error: -6.28317437489
time_step: 0.001
command: -63460.0611864
p: 100.0
i: 0.01
d: 10.0
i_clamp: 0.0
antiwindup: False

What this results in is entirely unstable behavior - the link rotates and hits the limit very quickly. If I change the joint to be in entirely positive limits, then I do not have any such issues. Also, this does not occur if I change it to a continuous joint. Is the proper way to use these controllers to specify a continuous joint in the urdf and then specify the joint limits using the joint_limits_interface? I would appreciate an explanation for how to mitigate this without having to a) change joint limits and b) changing to a continuous joint (unless that is required).