Robot system interface

[hellantos]

This system interface implementation uses the perform switch function to directly switch the CANopen controlled robot into operation enable state and the appropriate operation mode, depending on the command interfaces claimed by controllers.

An appropriate ros2_control xacro yould look like this.

<?xml version="1.0"?>
<robot xmlns:xacro="http://www.ros.org/wiki/xacro">

    <xacro:macro name="prbt_ros2_control" params="
      name
      prefix
      bus_config
      master_config
      can_interface_name
      master_bin">

        <ros2_control name="${name}" type="system">
            <hardware>
                <plugin>canopen_ros2_control/RobotSystem</plugin>
                <param name="bus_config">${bus_config}</param>
                <param name="master_config">${master_config}</param>
                <param name="can_interface_name">${can_interface_name}</param>
                <param name="master_bin">"${master_bin}"</param>
            </hardware>
            <joint name="${prefix}joint_1">
                <param name="device_name">prbt_joint_1</param>
            </joint>
            <joint name="${prefix}joint_2">
                <param name="device_name">prbt_joint_2</param>
            </joint>
            <joint name="${prefix}joint_3">
                <param name="device_name">prbt_joint_3</param>
            </joint>
            <joint name="${prefix}joint_4">
                <param name="device_name">prbt_joint_4</param>
            </joint>
            <joint name="${prefix}joint_5">
                <param name="device_name">prbt_joint_5</param>
            </joint>
            <joint name="${prefix}joint_6">
                <param name="device_name">prbt_joint_6</param>
            </joint>
        </ros2_control>

    </xacro:macro>

</robot>

The bus configuration file can contain the following:

joint_1:
  node_id: 2
  dcf: "cia402_slave.eds"
  driver: "ros2_canopen::Cia402Driver"
  package: "canopen_402_driver"
  period: 10
  position_mode: 1     # Operation mode for position control, only required when used
  velocity_mode: 3     # Operation mode for velocity control, only required when used
  effort_mode: 4         # Operation mode for effort control, only required when used
  switching_state: 2    # 402 state in which the device has to be to switch operation mode.

This supersedes #102. It dependes on #110

[hellantos]

@ipa-vsp can you test this on the PRBT robot? I have made the necessary changes to work with fake slaves see https://github.com/ipa-cmh/prbt_robot/pull/4

To test you can run:

ros2 launch prbt_robot_support prbt_ros2_control.launch.py

[ipa-vsp]

Improvements:

• Controller update: 50 Hz
• Sync: 10ms
• Interpolated time period: 15 ms

Result:

• Old interface:
  • Mean time difference: 13.076 ms
  • Total number of time skips for more than 15ms: 628
  • Max time difference: 26.16 ms
• New Interface:
  • Mean time difference: 10.0001 ms
  • Total number of time skips for more the 15ms: 0
  • Max time difference: 11.1755 ms

Used ros2_tracing to record the timestamp when joint TPDO is sent and recorded over 5000 values.

[hellantos]

Great,I think if we want to get better than that, we would probably need to have an RT patched kernel. I take it we have succeeded in eliminating vibrations?

[ipa-vsp]

Yes, I have noticed that the vibration is mostly eliminated when running the robot at normal velocity and acceleration scaling (0.2). However, when attempting to run it at higher levels, I have found that there is still a small amount of vibration present.

[jclinton830]

@ipa-cmh @ipa-vsp when will you be merging this with the master? Is there more testing that needs to happen?

[hellantos]

Yes we will be merging it for the next beta release. I just have to find the time to resolve the conflicts. I hope to do it this week. There are still one issues to be aware of when using. The problem is, that mode switching in ros2_control is done in the realtime loop. Our experience is, that mode switching in canopen cia402 is not really deterministic and would block the realtime loop. Consequently, we detach the mode switching function into a thread but this means we do not exactly know when switching is finished. So after activation of a controller, we currently do not know when the right operation mode is actually available.