{"action":"created","issue":{"url":"https://api.github.com/repos/ipa320/schunk_robots/issues/59","labels_url":"https://api.github.com/repos/ipa320/schunk_robots/issues/59/labels{/name}","comments_url":"https://api.github.com/repos/ipa320/schunk_robots/issues/59/comments","events_url":"https://api.github.com/repos/ipa320/schunk_robots/issues/59/events","html_url":"https://github.com/ipa320/schunk_robots/issues/59","id":113601257,"number":59,"title":"Errors 'CAN not ready' when init Schunk lwa4p in Indigo","user":{"login":"Zunchao","id":14214267,"avatar_url":"https://avatars.githubusercontent.com/u/14214267?v=3","gravatar_id":"","url":"https://api.github.com/users/Zunchao","html_url":"https://github.com/Zunchao","followers_url":"https://api.github.com/users/Zunchao/followers","following_url":"https://api.github.com/users/Zunchao/following{/other_user}","gists_url":"https://api.github.com/users/Zunchao/gists{/gist_id}","starred_url":"https://api.github.com/users/Zunchao/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Zunchao/subscriptions","organizations_url":"https://api.github.com/users/Zunchao/orgs","repos_url":"https://api.github.com/users/Zunchao/repos","events_url":"https://api.github.com/users/Zunchao/events{/privacy}","received_events_url":"https://api.github.com/users/Zunchao/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2015-10-27T14:46:44Z","updated_at":"2015-11-04T12:45:52Z","closed_at":null,"body":"Hi, \r\nI am trying to move the schunk lwa4p arm using the package of indigo version. But errors like 'CAN not ready' 'message: cannot reset node ' '' frequently appear when I call the service /arm/driver/init.\r\n\r\nThe configuration status is:\r\n>    -Ubuntu 14.04  64-bit\r\n    -ROS-Indigo (the most recent update)\r\n    -SocketCAN(peak_usb)\r\n    -The schunk_robots and ros_canopen repositories are the most recent ones.\r\n\r\nThe program running order:\r\n>    rosrun canopen_test_utils prepare.sh;\r\n    roslaunch schunk_lwa4p robot.launch;\r\n    rosservice call /arm/driver/init(OR roslaunch schunk_lwa4p dashboard.launch).\r\n\r\nI considered it as an issue of time sequence, as I found that the Sync, SDO and PDO running simutaneously like chaos. So I delayed the sync starting time after the SDO initialization finished(not completely, except the last node), by adding a conditional flag in the function of switchState() in the [node.cpp](https://github.com/ros-industrial/ros_canopen/blob/indigo-devel/canopen_master/src/node.cpp) in the package of canopen_master, as follows:\r\n>......\r\nint delay_flag=0;\r\n......\r\ncase Operational:\r\n            delay_flag++;\r\n            if (delay_flag==6) {\r\n                delay_flag=0;\r\n            if(changed && sync_) sync_->addNode(this);}\r\n            break;\r\n......\r\n\r\nThe current status is: as long as I have tested, it fails at the first one or two tries(relaunch the robot node) every time I restart the arm, but after that it works stably(no errors and can move the arm).\r\n\r\nErrors in  the first one or two tries:\r\n>......\r\ncore service [/rosout] found\r\nprocess[arm/robot_state_publisher-1]: started with pid [14627]\r\nprocess[arm/driver-2]: started with pid [14652]\r\nprocess[arm/arm_controller_spawner-3]: started with pid [14687]\r\nprocess[arm/cob_control_mode_adapter_node-4]: started with pid [14700]\r\n[ INFO] [1445943599.536288009]: waitForService: Service [/arm/controller_manager/load_controller] has not been advertised, waiting...\r\nprocess[arm/joint_states_relay-5]: started with pid [14722]\r\n[ INFO] [1445943604.536369237]: waitForService: Service [/arm/controller_manager/load_controller] has not been advertised, waiting...\r\n[ INFO] [1445943604.598089341]: Initializing XXX\r\n[ INFO] [1445943604.598304076]: Current state: 1 device error: system:0 internal_error: 0 (OK)\r\n[ INFO] [1445943604.598407122]: Current state: 2 device error: system:0 internal_error: 0 (OK)\r\n[ INFO] [1445943609.557082529]: waitForService: Service [/arm/controller_manager/load_controller] has not been advertised, waiting...\r\n[ INFO] [1445943614.558829524]: waitForService: Service [/arm/controller_manager/load_controller] has not been advertised, waiting...\r\n[ INFO] [1445943617.524258383]: waitForService: Service [/arm/controller_manager/load_controller] is now available.\r\n[ INFO] [1445943617.609265224]: joint_trajectory_controller loaded\r\n[ INFO] [1445943617.659285657]: joint_group_position_controller loaded\r\n[ INFO] [1445943617.669156610]: joint_group_interpol_position_controller loaded\r\n[ INFO] [1445943617.719205008]: joint_group_velocity_controller loaded\r\nLoaded joint_state_controller\r\n[ INFO] [1445943617.779181358]: Switched Controllers. From no_stop_controller_defined to joint_trajectory_controller\r\nStarted ['joint_state_controller'] successfully\r\n[ INFO] [1445943618.011741385]: advertised as /joint_states\r\n\r\n>[arm/arm_controller_spawner-3] process has finished cleanly\r\nlog file: /home/zheng/.ros/log/68412552-7c99-11e5-955b-901b0e5c82f2/arm-arm_controller_spawner-3*.log\r\nerror: 4\r\n[ INFO] [1445943618.682338510]: Current state: 2 device error: system:0 internal_error: 4 (controller problems;)\r\n[ INFO] [1445943618.682366799]: Current state: 1 device error: system:0 internal_error: 4 (controller problems;)\r\nID: 4\r\n[ERROR] [1445943618.689081715]: CAN not ready; CAN not ready\r\nDid not receivce a response message\r\nDid not receivce a response message\r\n......\r\n\r\n\r\n\r\nThe question here is: I am not sure whether what I have understood and changed is reasonable or not. The fact is it truly increases the probability of successful initialization. Could anyone give me some instructions about it? Or any other method to solve it? Thanks very much.\r\n"},"comment":{"url":"https://api.github.com/repos/ipa320/schunk_robots/issues/comments/153710677","html_url":"https://github.com/ipa320/schunk_robots/issues/59#issuecomment-153710677","issue_url":"https://api.github.com/repos/ipa320/schunk_robots/issues/59","id":153710677,"user":{"login":"ipa-mdl","id":727227,"avatar_url":"https://avatars.githubusercontent.com/u/727227?v=3","gravatar_id":"","url":"https://api.github.com/users/ipa-mdl","html_url":"https://github.com/ipa-mdl","followers_url":"https://api.github.com/users/ipa-mdl/followers","following_url":"https://api.github.com/users/ipa-mdl/following{/other_user}","gists_url":"https://api.github.com/users/ipa-mdl/gists{/gist_id}","starred_url":"https://api.github.com/users/ipa-mdl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ipa-mdl/subscriptions","organizations_url":"https://api.github.com/users/ipa-mdl/orgs","repos_url":"https://api.github.com/users/ipa-mdl/repos","events_url":"https://api.github.com/users/ipa-mdl/events{/privacy}","received_events_url":"https://api.github.com/users/ipa-mdl/received_events","type":"User","site_admin":false},"created_at":"2015-11-04T12:45:52Z","updated_at":"2015-11-04T12:45:52Z","body":"> why is the state UNKNOWN but not UP?\r\n\r\nThis relates to the kernel driver. `UNKNOWN` seems to be okay..\r\n\r\n> The thing is when you relaunch the robot node, it works well. But if you restart the arm, same results: first init fails, after that no errors.\r\n\r\nCan explain this a little more?\r\nDo you restart the arm while the driver is running?\r\n\r\n> I am still not clearly understanding the mechanism of the initialization. For a clearer view, I postponed(deleted) the sync and PDO parts, data as in candump-2015-11-04_093045.log. For example, from Line 475 to Line 499, it's a switch state process, the former node (node 7) goes to 'operational', then a two-stage follows (stage one: Line 476 ~ Line 483; stage two: Line 484 ~ Line 499), the first stage finishes the former five operational nodes? The second stage seems to start the bootup of the next node and reset the former five nodes? Is that right? If it is, can we bootup the new node directly, without reset the former nodes? Because it seems the messages in the 1st stage duplicated again in the 2nd stage.\r\n\r\nI guess you mix some things up.\r\nLines 475 too 499are fine.\r\n`(1446625856.848025) can0 000#0107` starts node 7\r\n\r\n```\r\n(1446625857.765490) can0 603#4001100000000000\r\n(1446625857.766446) can0 583#4F01100000000000\r\n```\r\nDoes not belong to the initialization. This is part of the asynchonous diagnostics job that polls the error register of all initialized nodes.\r\n\r\n```\r\n(1446625858.848137) can0 607#2F03100000000000 # SDO write\r\n(1446625858.848290) can0 603#4001100000000000 \r\n(1446625858.849317) can0 087#0000000000000000 # error reset\r\n(1446625858.849593) can0 583#4F01100000000000\r\n(1446625858.849765) can0 604#4001100000000000\r\n(1446625858.849836) can0 587#6003100000000000 # SDO ack\r\n```\r\nResets the error counter for node 7."}}