Hm -- what kind of planning issues were you seeing, and have you tested these new numbers thoroughly?

We originally made the joint limits conservative to (a) prevent the joints from hyperextending and (b) prevent plans being made past our "soft stops" (we apply a reverse torque when a joint is too close to its limit).

Not sure if these are actual issues, but I'm a bit worried about the consequences of making these joint limits more generous than our softstop limits, which are currently in the robot parameter yaml files in blue_bringup (though they should probably be calculated from values read from the URDF).

Oh, the conservative joint limits just makes moveit take a lot of weird trajectories as opposed to when they're more accurate.

Also, since my helper pickup ready position commander script sets the joint positions beyond those limits, moveit refuses to plan since it thinks the arm is in an invalid state.

I didn't take into account the soft stops since the moveit implementation is using a ros_control controller instead though..