motoman_driver accepting joint_states that are not from the robot arm controller #326
Comments
|
So I believe the reason this is not such an issue (or at least not in the systems I use this driver with) is that I typically remap This connects to a larger design discussion about whether consumers should be capable of dealing with "any" incoming message (of the same type) and be responsible for picking out the parts they are interested in, or whether by configuration (by an external entity) they should be able to rely on receiving only messages meant for them specifically. See gavanderhoorn#1 (comment) for an earlier discussion I've had about this. gavanderhoorn@e369ddc would be a fix for what you describe I believe. I'm still not happy with having to do that here in this driver, but it does help make things more robust, so a PR with that change ported to current |
|
@MarqRazz: would you have any updates? There appears to be quite some activity in your fork, is any of that related to this issue? |
gavanderhoorn
added
the
more-info-needed
|
@gavanderhoorn I have been adding new robots to my repo (I am planning on making PR's for each bot after everything is working and verified). When I run on hardware I add this fix... So this is still an issue for me but I am assuming that we can get this change permanently added to the repo, I just haven't had time to make a PR. |
|
We just had the same issue and I feel dump for not reading this here ... |
…s or number of joints fixes ros-industrial#326 based on gavanderhoorn@e369ddc
…s or number of joints fixes ros-industrial#326 based on gavanderhoorn@e369ddc
…s or number of joints fixes ros-industrial#326 based on gavanderhoorn@e369ddc
…s or number of joints fixes ros-industrial#326 based on gavanderhoorn@e369ddc
…s or number of joints fixes ros-industrial#326 based on gavanderhoorn@e369ddc
…s or number of joints fixes ros-industrial#326 based on gavanderhoorn@e369ddc
…s or number of joints fixes ros-industrial#326 based on gavanderhoorn@e369ddc
On my robot I have a gripper that is publishing its joint_states on the topic /my_gripper/joint_states and this information is relayed down the the /joint_states topic. I have recently found that I am randomly receiving errors from the industrial_robot_client stating:
isWithinRange::Key vectors are not similarand my trajectory being rejected.
I did some digging and found that in joint_trajectory_interface.cpp in the jointStateCB the software blindly accepts the incoming message on the /joint_states topic as the robots
cur_joint_pos_. I added a simple checkif(this->all_joint_names_.size() != msg->position.size())then just return from the callback without updating the robots
cur_joint_pos_and it fixed my errors.I am happy to put in a pull request with a fix for this error but wanted to get your guy's feedback on how you would like to ensure the received JointState message is for the robot arm we are connected to.
Should we check to make sure that all of the names in the
all_joint_names_variable are included in themsg->namelist? Should we check to make sure that the JointState message includes some minimum level of information (i.e. the name, position and velocity vectors all have the same length)? Anything else you would like it to check?Another option would be to launch the node in a namespace and we would get /motoman/joint_states but users would be required to relay that topic down to /joint_states for the PlanningSceneMonitor and RobotStatePublisher.
The text was updated successfully, but these errors were encountered: