using CSP mode, would move to position 0 when launch #125
Comments
|
For me this only happens if the controller starts to quickly.. If i remember correctly this is something that is known: I've temporary fixed this by first starting the ros2 control node, which starts ethercat, then add a timeout afterwards the other controllers are started: from launch.actions import RegisterEventHandler, TimerAction
...
[ros2_control_node]
+ [
RegisterEventHandler(
event_handler=OnProcessStart(
target_action=ros2_control_node,
on_start=[
TimerAction(
period=(
45.0
),
actions=load_controllers,
),
],
)
)
] |
|
Hi JensVanhooydonck, It opens a problem with ros2 control: if on_activate takes time, what should be the read and the write values during the on_activate function call ? If the 2 problems are indeed related, that is a very good catch !
|
Thank you for your advise, I tried your way , but it did not work. ` from launch import LaunchDescription from launch_ros.actions import Node from launch import LaunchDescription def generate_launch_description(): ` here is the whole output:
|
Thank you for your reply , the PR did not solve the problem. during my work , I found these codes may to do with the problem: the override_command attribute , if I changed it to true , the motor will not crush to position 0 when start up, but it would not move if I send another command , like the topic below I used to test: If I changed it to false, the motor will crush to position 0 during start up. the start up command I used is : |
For CSP mode the overwride_command should not be set.. Can you share your yaml-config file? What i have seen and strugled with, is that the Mode of operation needs to be set in the config file as well. Only in the ros2_control.xacro.urdf file is not enough to always have the correct mode settings.. |
I am wei1224hf 's another account, void ec_update(uint8_t * domain_address) I found that this did not work: |
|
|
Are you sure there isn't just a 0 command on the command interface? Can you give the yaml-config file? You did set default to .nan ? And do you have a and a |
|
|
Yes , I have set .nan to position command interface, ` - {index: 0x60C2, sub_index: 1, type: int8, value: 10} # Set interpolation time for cyclic modes to 10 ms- {index: 0x60C2, sub_index: 2, type: int8, value: -3} # Set base 10-3srpdo: # RxPDO = receive PDO Mapping
|
You should try to add the 0x6060 and the 0x6061 Because all these features use the mode_of_operation_display_ which is set by reading from 0x6061 Here some features are set: I think this would also be solved if we add an extra line here: mode_of_operation_display_ = std::stod(paramters_["mode_of_operation"]);
|
|
@JensVanhooydonck Thanks for your proposal and your PR.
mode_of_operation_display_ = std::stod(paramters_["default_mode_of_operation_display"]);
And to be user friendly, we should report the possible problem of initialization when mode_of_operation_display tpdo is not defined.
is not defined in the config file as well as one of Position, Velocity and Torque with matching rpdo and tpdo. My opinion is that a failure to launch would be preferable (we could however make that failure optional with an advanced parameter to ON for user wanting to experiment with exotic drive loosely following CiA402 norm). |
This is indeed the best solution. That's also the reason i asked if the Also failing to launch if Maybe we could create |
|
@JensVanhooydonck, your question about 0x6061 was indeed crucial and I would like to know from @wei1224hf, if this is possible for wei1224hf's system to read it. I have another use case and solution from P. Zanne, a colleague who takes part of the development of the driver: The use case would be a system with many motors (like many, many motors) and we would like to avoid having the mode_of_operation_display_ (as well as the mode_of_operation) polluting the frame. Indeed, mode_of_operation and mode_of_operation_display data are only necessary in case of errors and when a switch of mode is required (like at start) or when a switch of mode of control is required. The solution P. Zanne suggested, in this case, is to use SDOs to asynchronously interrogate the drives when an error occurs or before and after a switch of mode is required. |
I'm wei1224hf's another account, |
|
From your code it is clear that command_interface_ptr_->at(interface_index) is 0, so it means that either initialization should be nan or that the command is really 0. |
|
I definitely confirm that the problem comes from the mode of operation_display or 0x6061 being not read and triggering the whole chain of consequences. TEST_F(EcCiA402DriveTest, EcWriteDefaultTargetPosition) in file test_generic_ec_cia402_drive.cppCan you add 0x6061 : mode_of_operation_display and 0x6060 : mode_of_operation in your config file and make a test ? I make better documentation of that test for a next PR, you can have a look at that link: You can run the test and verify that indeed, correct setting of the target_position is made if the command is NaN. I have seen that we had another problem (not related to yours though). If you look at the branch (yguel-humble-cia402-checks) in my fork: https://github.com/yguel/ethercat_driver_ros2/tree/yguel-humble-cia402-checks, in the commit: 8455eda That will go into a PR. |
I tried , it did not work ,here is the yaml: vendor_id: 0x00100000
product_id: 0x000c010d
assign_activate: 0x0300 # DC Synch register
auto_fault_reset: false # true = automatic fault reset, false = fault reset on rising edge command interface "reset_fault"
rpdo: # RxPDO = receive PDO Mapping
- index: 0x1600
channels:
- {index: 0x6040, sub_index: 0, type: uint16, default: 0} # Control word
- {index: 0x607a, sub_index: 0, type: int32, command_interface: position, default: .nan} # Target position
- {index: 0x60ff, sub_index: 0, type: int32, command_interface: velocity, default: .nan} # Target velocity
- {index: 0x6071, sub_index: 0, type: int16, command_interface: effort, default: .nan} # Target torque
- {index: 0x6060, sub_index: 0, type: int8, default: 8 ,command_interface: mode_of_operation} # Mode of operation
tpdo: # TxPDO = transmit PDO Mapping
- index: 0x1a00
channels:
- {index: 0x6041, sub_index: 0, type: uint16} # Status word
- {index: 0x6064, sub_index: 0, type: int32, state_interface: position} # Position actual value
- {index: 0x606c, sub_index: 0, type: int32, state_interface: velocity} # Velocity actual value
- {index: 0x6077, sub_index: 0, type: int16, state_interface: effort} # Torque actual value
- {index: 0x6061, sub_index: 0, type: int8, state_interface: mode_of_operation} # Mode of operation displaychage to mode_of_operation_display , not work too |
|
I'm using the main branch. my ros is ros2-humble , but I'm not using the humble branch , |
And your ros_control looks something like this: <joint name="${prefix}vertical_slider">
<command_interface name="position" />
<state_interface name="position" />
<state_interface name="velocity" />
<state_interface name="effort" />
<state_interface name="status_word"/>
<command_interface name="control_word"/>
<state_interface name="mode_of_operation"/>
<command_interface name="mode_of_operation"/>
<state_interface name="reset_fault"/>
<command_interface name="reset_fault"/>
<ec_module name="Inovance_sv660_fry">
<plugin>ethercat_generic_plugins/EcCiA402Drive</plugin>
<param name="alias">1001</param>
<param name="position">0</param>
<param name="mode_of_operation">8</param>
<param name="slave_config">$(find config)/ethercat/slave_config_vertical.yaml</param>
</ec_module>
</joint> |
I did not add the mode_of_operation state nor command interface , should I add these? |
|
thank you for your help , @JensVanhooydonck motor will go to position 0 during startup |
|
I did have something simular. It got better after i altered this: JensVanhooydonck@e452211 This still not fixes it 100% of the time, that's why i use a delay on startup (I have 32 connected & configured ethercat-slaves, so startup takes some time) |
32 motors, that's a lot , are you making a humnoid robot？ my robot has 12 for legs, 14 for amrs, 3 for waist, 3 for head , 34 in total , |
|
I reopen this issue, since there is obviously still a problem. |
using this launch code:
ros2 launch ethercat_motor_drive motor_drive.launch.pymy servo motor eanbled ,
but when it's enabled, the motor would shock, if it's not in position 0 ,
seems that it would send position 0 when it start up,
how to make it stay at where it stay during starting up?
the start up script I used:
ros2 launch ethercat_motor_drive motor_drive.launch.pythe script I used to test move:
''ros2 topic pub -r 0.2 /trajectory_controller/joint_trajectory trajectory_msgs/msg/JointTrajectory '{header: {stamp: {sec: 0, nanosec: 0}, frame_id: ""}, joint_names: ["joint_1"], points: [{positions: [100.0], velocities: [0.0], accelerations: [0.0], time_from_start: {sec: 1, nanosec: 0}},{positions: [10000.0], velocities: [0.0], accelerations: [0.0],time_from_start: {sec: 5, nanosec: 0}}]}'
I found this poblem has something to do with override_command attribute:
The text was updated successfully, but these errors were encountered: