Ask Your Question
0

ros_canopen control Schneider Lexium motor (CiA 402)

asked 2021-05-03 16:23:21 -0500

robertjbush gravatar image

updated 2021-05-05 01:58:30 -0500

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 ...
(more)
edit retag flag offensive close merge delete

Comments

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 with 101010 on it)).

You don't need to post a new question, just edit your curent one. You can use the edit button/link for this.

After you replace the screenshot with the text itself, we can re-open your question.

gvdhoorn gravatar image gvdhoorn  ( 2021-05-04 04:58:14 -0500 )edit

@gvdhoorn I've done as asked, but don't have enough points to reopen.

robertjbush gravatar image robertjbush  ( 2021-05-04 06:00:06 -0500 )edit

I've re-opened it for you.

gvdhoorn gravatar image gvdhoorn  ( 2021-05-04 06:06:07 -0500 )edit

Which side is running what?

Does regular publish-subscribe work on the different hosts?

gvdhoorn gravatar image gvdhoorn  ( 2021-05-04 06:07:15 -0500 )edit

I can confirm services work perfect. Regarding topics; joint_state_publisher is subscribing successfully to canopen/joint_states, published by ros_canopen which is launched on the remote machine. Some information that may be relevant has been added as edit 2.

robertjbush gravatar image robertjbush  ( 2021-05-04 06:49:53 -0500 )edit

joint_state_publisher is subscribing successfully to canopen/joint_states, published by ros_canopen which is launched on the remote machine.

that would seem strange to me: the JSP publishesJointState msgs, it doesn't consume them. Unless you've configured it with a source_list parameter.

If you run rostopic echo /canopen/positioner_controller/command on your Pi, and rostopic publish on your desktop, does that result in your command getting echod by the rostopic echo on the Pi?

I can confirm services work perfect.

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.

gvdhoorn gravatar image gvdhoorn  ( 2021-05-04 06:57:00 -0500 )edit

Apologies that was an obvious test to do. I'm learning, so forgive the oversight. To answer your question directly now:
Yes the rostopic echo on the pi receives the message that was published to that topic.
I am using source_list parameter.
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.

robertjbush gravatar image robertjbush  ( 2021-05-04 07:22:54 -0500 )edit

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_canopen not allowing ros_control to control anything unless the drive is in the correct state. The fact you've still got something commented out in ros_canopen doesn't make me confident things are working.

If the controller you're trying to use has a state topic, 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 running state and you've sure there isn't something in ros_canopen filtering out commands as it's not in the correct state, you could add some debug printf(..)s at strategic points in the controller ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2021-05-04 07:55:05 -0500 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2021-05-04 12:52:35 -0500

robertjbush gravatar image

updated 2021-05-05 01:55:27 -0500

Solution:
For those with a Schneider Lexium motor you will need to set the target position profile velocity object key. This can be done using your .yaml's dcf_overlay by setting "6081": "{velocity}". I set it to 10,000.

Don't forget to set motor current limits to not burn out motor windings.

EDIT...
Debugging:

I used env-loader to set ROSCONSOLE_CONFIG_FILE. This is useful for filtering out messages from the master PC and focus only on the remote machine. Wireshark decoding as canopen is essential, and the CiA 402 and 301 standards for decoding messages. If all looks good then its likely to be a vendor specific issue and that needs a bit intuition and the vendors manual.

edit flag offensive delete link more

Comments

Could you perhaps add some words on how you discovered this? What the "velocity object key" does and why it makes things suddenly work?

gvdhoorn gravatar image gvdhoorn  ( 2021-05-04 13:46:33 -0500 )edit

The Lexium manual states a list of CANopen object dictionary keys. One of them is called the above and is set to 0 by default. I tried changing it and it worked. It would have been nice if they'd stated that clearly in the manual but alas that would be asking way too much. The velocity key sets a profile velocity during the position based move and this is handled internally by the Lexium controller. It can be changed at runtime using ros_canopen's set_object service.

robertjbush gravatar image robertjbush  ( 2021-05-04 14:35:42 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

3 followers

Stats

Asked: 2021-05-03 16:23:21 -0500

Seen: 87 times

Last updated: May 05