ros_canopen control Schneider Lexium motor (CiA 402)
I've mapped PDO's, initialised successfully, performed homing (set to current motor position) and obtained both position and velocity in my joint_states topic. My controllers are spawned and "running". However when I publish a float to the command topic, it just hangs and the packet dump shows no RPDO's being sent (and yet there are RPDO's sent to initialise the motor).
My question is predominantly around whether my command and logic to move the motor is correct and how I can debug better. The command I'm running is:
rostopic pub /canopen/positioner_controller/command std_msgs/Float64 "data: 1.0"
For debugging I understand I can change the logger level using rosservice call /my/service/set_logger_level and I can set the ROSCONSOLE_FORMAT to include more information but as of yet I haven't found a config which filters the messages down to the right area. Any advice or configurations to help me hone in on the error with my command publisher or ros_canopen subscriber?
ROSDISTRO: Noetic
Master OS: Ubuntu 20.04
Remote OS: Buster
Master PC: HP
Remote PC: RevPi Connect+ 32GB
Device: Schenider Lexium 28 Drive Controller (CiA 402)
Note: Line 417 of motor.cpp in canopen_402 is set to 0, because my motor will not enter or remain in an operating mode if a halt bit is set.
EDIT 3:
rosnode info canopen/positioner_driver shows that it subscribes to /canopen/positioner_controller_command but with [unknown type] at the end.
EDIT 2:
- My yaskawa robot joints are in every message of the joint_states topic whereas my positioner joint appears once in every 5 messages. I'm running the can interface at 10 ms and the positioner joint_state_controller at a publish rate of 10 or 300 it doesn't seem to make a difference.
- I get a [WARN] [/yaskawa/joint_state_publisher]: Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received. Please check sender for additional details. This warning appears when I echo the joint_state topic.
- I have a motion_streaming_interface for Yaskawa robot but can't see the hw_interface for my canopen positioner.
# Settings for ros_control hardware interface
hardware_interface:
joints:
- positioner_fixture_plate
sim_control_mode: 0
EDIT_1:
rosnode_list
amp01|aa-ipc-001@ros:~/checkout$ rosnode list
/canopen/positioner_controller_spawner
/canopen/positioner_driver
/canopen/robot_state_publisher
/easy_bag_recorder
/rosout
/rpi_io_server
/yaskawa/io_relay
/yaskawa/joint_state
/yaskawa/joint_state_publisher
/yaskawa/joint_trajectory_action
/yaskawa/motion_streaming_interface
/yaskawa/move_group
/yaskawa/robot_state_publisher
/yaskawa/rviz_aa_ipc_001_80_7661275130432046209
rostopic_list
amp01|aa-ipc-001@ros:~/checkout$ rostopic list
/canopen/joint_states
/canopen/positioner_controller/command
/diagnostics
/record/cancel
/record/feedback
/record/goal
/record/result
/record/status
/rosout
/rosout_agg
/tf
/tf_static
/yaskawa/attached_collision_object
/yaskawa/collision_object
/yaskawa/execute_trajectory/cancel
/yaskawa/execute_trajectory/feedback
/yaskawa/execute_trajectory/goal
/yaskawa/execute_trajectory/result
/yaskawa/execute_trajectory/status
/yaskawa/feedback_states
/yaskawa/joint_path_command
/yaskawa/joint_states
/yaskawa/joint_trajectory_action/cancel
/yaskawa/joint_trajectory_action/feedback
/yaskawa/joint_trajectory_action/goal
/yaskawa/joint_trajectory_action/result
/yaskawa/joint_trajectory_action/status
/yaskawa/move_group/cancel
/yaskawa/move_group/display_contacts
/yaskawa/move_group/display_planned_path
/yaskawa/move_group/feedback
/yaskawa/move_group/goal
/yaskawa/move_group/monitored_planning_scene
/yaskawa/move_group/plan_execution/parameter_descriptions
/yaskawa/move_group/plan_execution/parameter_updates
/yaskawa/move_group/planning_scene_monitor/parameter_descriptions
/yaskawa/move_group/planning_scene_monitor/parameter_updates
/yaskawa/move_group/result
/yaskawa/move_group/sense_for_plan ...
I'm sorry to have to do this for something so seemingly unimportant, but please don't post screenshots of terminal text in question on ROS Answers. It's all text, so there is no need. Just copy-paste the text from the terminal into your question text. Do make sure to format it properly by selecting the text and pressing
ctrl+k(or clicking the Preformatted Text button (the one with101010on it)).You don't need to post a new question, just edit your curent one. You can use the
editbutton/link for this.After you replace the screenshot with the text itself, we can re-open your question.
@gvdhoorn I've done as asked, but don't have enough points to reopen.
I've re-opened it for you.
Which side is running what?
Does regular publish-subscribe work on the different hosts?
I can confirm services work perfect. Regarding topics;
joint_state_publisheris subscribing successfully tocanopen/joint_states, published byros_canopenwhich is launched on the remote machine. Some information that may be relevant has been added as edit 2.that would seem strange to me: the JSP publishes
JointStatemsgs, it doesn't consume them. Unless you've configured it with asource_listparameter.If you run
rostopic echo /canopen/positioner_controller/commandon your Pi, androstopic publishon your desktop, does that result in your command gettingechod by therostopic echoon the Pi?that's nice, but not an answer to my question.
you also appear to have added some more information to your question, but I don't really understand how that relates to what your initial question was.
Apologies that was an obvious test to do. I'm learning, so forgive the oversight. To answer your question directly now:
Yes the
rostopic echoon the pi receives the message that was published to that topic.I am using
source_listparameter.The edit was information I perceived to be relevant but as I learn ros_control more I will understand what is relevant and what isn't. I have added one more edit which I believe is very relevant.
Please do all testing local on the Pi. At least that way we avoid any problems with ROS multi-machine setups.
Having written that: I seem to remember a comment by @Mathias Lüdtke (on your github issue) about
ros_canopennot allowingros_controlto control anything unless the drive is in the correct state. The fact you've still got something commented out inros_canopendoesn't make me confident things are working.If the controller you're trying to use has a
statetopic, you could check what it's trying to do (ie: whether it has received your setpoint and is trying to work towards that).If not, and the controller is in its
runningstate and you've sure there isn't something inros_canopenfiltering out commands as it's not in the correct state, you could add some debugprintf(..)s at strategic points in the controller ...(more)