search

ezWheelSAS / swd_ros_controllers

ROS nodes to control motors powered by the ez-Wheel Safety Wheel Drive (SWDยฎ) technology.
https://www.ez-wheel.com/
GNU Lesser General Public License v2.1
5 stars 3 forks source link

Increase speed in the backward direction. #12

Closed fig-shimooka closed 2 years ago

fig-shimooka commented 2 years ago

I want to increase the speed of the SWD Core in the back direction. Is there a way to do this?

ez-Support commented 2 years ago

As there is no laser scanner watching StarterKit's back, a SLS is acctivated when moving backward. You should increase the SLS speed in the commissioning script to do so (e.g. sls_vl_limit = 1000).

fig-shimooka commented 2 years ago

LaserScanner will be added behind SWD Core. In this case, will the speed increase without changing the SLS? Does it have the same speed as going forward?

ez-Support commented 2 years ago

No if you change the SLS speed in the commissioning, it will reduce it. The maximum speed of the SWD is 1800 RPM.

ez-Support commented 2 years ago

You have indeed in that case to modify the launch file of the swd_diff_drive_controller.launch, in the field : <rosparam param="have_backward_sls">false</rosparam> change false to true. You should then restart services (e.g. systemctl restart ezw-ros-bringup.service)

fig-shimooka commented 2 years ago

I want to go backwards at the same speed as forwards. If I set have_backward_sls to True, will my wish be fulfilled?

ez-Support commented 2 years ago

Yes !

fig-shimooka commented 2 years ago

Thank you! I'll try to follow your advice.

ez-Support commented 2 years ago

You can roscd swd_ros_controllers/launch/ to get directly to the directory ๐Ÿ‘

ez-Support commented 2 years ago

Did you successfully resolved the issue ?

fig-shimooka commented 2 years ago

Sorry for the late reply. I am now checking the SWDCore backward . Both forward and backward travel was at the same speed. However, if I back up with an obstacle behind me, it does not slow down when I get close to it. When moving forward, the vehicle decelerates when an obstacle is approaching.

starter_kit.launch

<?xml version="1.0"?>
<launch>
  <arg name="master_ip" value="192.168.0.1" />
  <arg name="laser1_sensor_ip" value="192.168.0.110" />
  <arg name="laser2_sensor_ip" value="192.168.0.111" />
  <arg name="laser1_prefix" value="laser_1" />
  <arg name="laser2_prefix" value="laser_2" />
  <arg name="joy_config" value="xbox" />

  <!-- EZW ROS Controllers (diff-drive) -->
  <include file="$(find swd_ros_controllers)/launch/swd_diff_drive_controller.launch"/>

  <!-- IDEC -->
  <node pkg="urg_node" name="urg_node_1" type="urg_node">
    <param name="ip_address" value="$(arg laser1_sensor_ip)" />
    <param name="frame_id" value="$(arg laser1_prefix)" />
    <param name="angle_min" value="-1.5707963"/>
    <param name="angle_max" value="1.5707963"/>
    <remap from="/scan" to="/$(arg laser1_prefix)/scan" />
  </node>

  <node pkg="urg_node" name="urg_node_2" type="urg_node">
    <param name="ip_address" value="$(arg laser2_sensor_ip)" />
    <param name="frame_id" value="$(arg laser2_prefix)" />
    <param name="angle_min" value="-1.5707963"/>
    <param name="angle_max" value="1.5707963"/>
    <remap from="/scan" to="/$(arg laser1_prefix)/scan" />
  </node>

  <!-- <node pkg="tf" type="static_transform_publisher" name="laser_broadcaster" args="0.04 0 0 0 0 0 base_link laser_1 100" /> -->
  <!-- /IDEC -->

  <!--
  <include file="$(dirname)/mapping_lama.launch"/>
  -->

  <!-- <include file="$(dirname)/mapping_hector.launch"/>
  -->
  <!--
  <node pkg="tf" type="static_transform_publisher" name="map_odom_broadcaster" args="0 0 0 0 0 0 odom base_link 100"/>
  -->

  <!-- Websocket bridge (for HMI) -->
  <!--
  <node pkg="rosbridge_server" name="rosbridge_websocket" type="rosbridge_websocket">
    <param name="address" value="$(arg master_ip)" />
    <param name="use_compression" value="true" />
  </node>
  -->
  <!--
  <node pkg="tf2_web_republisher" name="tf2_web_republisher" type="tf2_web_republisher" />
  -->

  <!-- Joystick + teleop -->
  <node pkg="joy" name="xbox_joystick" type="joy_node">
    <param name="autorepeat_rate" value="50" />
     <remap from="/joy" to="/joy/id0/joy" />
  </node>
<!-- 
  <node pkg="teleop_twist_joy" name="teleop_twist_joy"
  type="teleop_node">
    <param name="joy_config" value="$(arg joy_config)" />
    <param name="enable_button" value="5" />
    <param name="enable_turbo_button" value="6" />
    <param name="axis_linear" value="1" />
    <param name="axis_angular" value="3" />
    <param name="scale_linear" value="1.0" />
    <param name="scale_angular" value="0.7" />
    <param name="scale_linear_turbo" value="1.3" />
    <param name="scale_angular_turbo" value="1.4" />
     <remap from="/cmd_vel" to="/swd_diff_drive_controller/cmd_vel" />
  </node> -->

  <!-- Robot manager -->
  <!--
  <node pkg="swd_robot_manager" name="robot_manager" type="robot_manager" />
  -->
</launch>
ez-Support commented 2 years ago

So if I sum-up, you have 2 laser scanners. The 1st one is watching forward and the 2nd one backward. When an obstacle is detected forward, SLS is activated on the front laser scanner, and the robot reduces the speed. When an obstacle is detected backward, SLS is activated on the back scanner, but the robot does not reduces its speed.

Is that it ?

Then, I would suggest:

  1. Make sure, you have commissionned the SLS function on the SWD Core with the back scanner.
  1. When SLS-OSSD is active on the back scanner, what is the status of safety_limited_speed in the safety topic ? (e.g. rostopic echo /swd_diff_drive_controller/safety)
fig-shimooka commented 2 years ago

Yes, that is correct. Apparently the back scanner limits the speed in the forward direction when SLS is enabled. I would speculate that you may need to set which scanner is behind you.

When there are no obstacles

header: 
  seq: 8230
  stamp: 
    secs: 1649933155
    nsecs: 671764454
  frame_id: "base_footprint"
safe_torque_off: False
safe_brake_control: False
safety_limited_speed: True
safe_direction_indication_forward: False
safe_direction_indication_backward: False

When there is an obstacle behind you.

---
header: 
  seq: 7626
  stamp: 
    secs: 1649933034
    nsecs: 871452233
  frame_id: "base_footprint"
safe_torque_off: False
safe_brake_control: False
safety_limited_speed: True
safe_direction_indication_forward: True
safe_direction_indication_backward: False
fig-shimooka commented 2 years ago

SDI is also only applied in the forward direction.

ez-Support commented 2 years ago

You did configure a SDI on the SE2l back laser too? With the same configuration as the front laser ? If so, you need to configure it in the commissionning scripts:

    scw = SafetyControlWordId.SAFEIN_1
    scwMapping = [
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
    ]
    scwMapping[0] = SafetyFunctionId.STO
    scwMapping[1] = SafetyFunctionId.STO
    scwMapping[2] = SafetyFunctionId.SDIN_1
    scwMapping[3] = SafetyFunctionId.SDIN_1
    scwMapping[4] = SafetyFunctionId.SLS_1
    scwMapping[5] = SafetyFunctionId.SLS_1
fig-shimooka commented 2 years ago

COMMISSIONING was carried out with its contents. OSSD is no enabled and no back is possible at all. Do I need to configure the SE2L side to enable SLS and SDI on the SE2L behind? How can I do this if I need to?

header: 
  seq: 807
  stamp: 
    secs: 1650013151
    nsecs: 475671319
  frame_id: "base_footprint"
safe_torque_off: False
safe_brake_control: False
safety_limited_speed: True
safe_direction_indication_forward: False
safe_direction_indication_backward: True
ez-Support commented 2 years ago

I might have inverted SDIP_1 and SDIN_1 maybe. To configure the SE2L scanner you need to download SLS designer from IDEC website. You can download the configuring file (.hucx) from our github or you will also find it in the commissioning folder of the starter kit

fig-shimooka commented 2 years ago

SDIP_1 and SDIN_1 were swapped. As a result, now I cannot move forward, even though all OSSDs are not working.

I am also concerned that safety_limited_speed is always True.

There was only one SLS designer configuration file on github. How should I configure it if I want to attach it in the front/back direction . Currently, the forward SE2L is set to master and the number of slaves to 1 in the master-slave item of the SLS designer. The SE2L behind is set to slave 1.

SE2L_HUCX_CONFIG_v2.zip

SE2L

header:
  seq: 2250
  stamp:
    secs: 1650243261
    nsecs: 905151305

  frame_id: "base_footprint"
safe_torque_off: False
safe_brake_control: False
safety_limited_speed: True
safe_direction_indication_forward: True
safe_direction_indication_backward: False
fig-shimooka commented 2 years ago

I do not connect the slave OSSD terminals to run the SE2L as a master-slave. Is this the cause? Screenshot 2022-04-18 at 15-23-49 SE2L๏พ•๏ฝฐ๏ฝป๏พž๏ฝฐ๏ฝฝ๏พž๏พ๏พ†๏ฝญ๏ฝฑ๏พ™ - B-1866-7-J pdf

ez-Support commented 2 years ago

The SE2L configuration should be the same on the front and the back scanners. You should not use the master/slave functionality, as only one scanner talks to one motor, and are not using the same OSSD signals. The architecture should be like the following: image You might need to use a 'Y connector' on the CAN/IO of SWD Core's right connector, to plug the back SE2L on it.

fig-shimooka commented 2 years ago

Thank you. I will look into the possibility of modifying the electronic circuit.

For example. Is it possible to use a master-slave to apply SLS,SDI to both forward and backward when the OSSD of the SE2L behind or in front responds? It means applying SDI and SLS without identifying the two forward and backward

ez-Support commented 2 years ago

To apply SLS yes without problem. For the SDI, if you activate SDI in both directions, it is the same as an STO signal actually. Thus, the robot will remain blocked until the object/obstacle is removed.

hiroyuki-s1 commented 2 years ago

In this case, if one of the two SE2Ls is OSSD (1/2/3/4) enabled, I do not see a problem with the AMR status being STO. How can I accomplish this with a master-slave?

ez-Support commented 2 years ago

Ok, then you should commission the motors with the following mappings:

Then, you have to set-up the SE2L scanner for interconnected them, using RS-485 for master/slave operation. Thus, you should obtain this behaviour: image

fig-shimooka commented 2 years ago

Thank you. I have achieved what I wanted to do.

fig-shimooka commented 2 years ago

Can OSSD signals and emergency switch signals be differentiated and passed on to the ROS message? I would like to distinguish whether it is an STO due to OSSD1/2 or an STO due to an emergency switch.

ez-Support commented 2 years ago

You can retrieve the information from the safeIN controlword. Which is send on the CAN bus with SRDO messages. According to the commissionning scripts, from swd_left on COB-ID 0x160, and on swd_right on COB-ID 0x109. The emergency signals are mapped to the first 2 bits of it. So I might suggest, that you read the values of the messages on the can bus, and conclude whether Emergency button is active or not.

Example: COB-ID ------ DLC ---- Data 0x160 -------- 1 ------ C3 ---->No mergency button on swd left 0x160 -------- 1 ------ C0 ----> Emergency button on swd left

0x109 -------- 1 ------ C3 ----> No mergency button on swd right 0x109 -------- 1 ------ C0 ----> Emergency button on swd right

You can see that the values of the 1st two bits change if the emergency is active or not.

To read messages on CAN bus, you should have to import the can library: e.g.import can Initialize the bus, e.g. bus = can.Bus(channel='can0', interface='socketcan') And maybe use a filter to only get those two messages, e.g. : bus.set_filters([{"can_id":0x109, "can_mask": 0xFFF, "extended":False}, {"can_id":0x160, "can_mask": 0xFFF, "extended":False}, ])

And finally get the data, e.g. data = bus.recv(2)

fig-shimooka commented 2 years ago

Thank you. Data obtained.

fig-shimooka commented 2 years ago

When the emergency switch is pressed, publish message of swd_diff_drive_controller/safety messages stops for a certain period of time. Is this a specification?

fig-shimooka commented 2 years ago

I would also like to know information on OSSD signals (SDI, SLS). Can this be obtained from the CAN bus?

ez-Support commented 2 years ago

Yes the data within the SRDO should change when OSSD signals is changing.

e.g. on SAFEIN controlword, according to the mapping in the commissioning scwMapping[0] = SafetyFunctionId.STO scwMapping[1] = SafetyFunctionId.STO scwMapping[2] = SafetyFunctionId.SDIN_1 scwMapping[3] = SafetyFunctionId.SDIN_1 scwMapping[4] = SafetyFunctionId.SLS_1 scwMapping[5] = SafetyFunctionId.SLS_1 STO --> Bit 0 and 1 SDI --> Bit 2 and 3 SLS --> Bit 4 and 5

ez-Support commented 2 years ago

For both wheels, you have to look on the mapping of the SAFEIN controlword

fig-shimooka commented 2 years ago

Thank you. I will verify this tomorrow. If I set it up that way, which CAN ID should I look at?

fig-shimooka commented 2 years ago

Using this setting, if an obstacle is detected, the status is set to STO. When the obstacle is remove, STO is automatically cancelled, but you do not want to cancel it. When an obstacle is detected, I want to cancel STO with something like a reset signal. I want to hold the STO until a reset signal is sent.

Is this possible?

    swd_left_4_commissioning.py:

    # mapping parameters
    scw = SafetyControlWordId.SAFEIN_1
    scwMapping = [
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
    ]

    scwMapping[0] = SafetyFunctionId.STO
    scwMapping[1] = SafetyFunctionId.STO
    scwMapping[2] = SafetyFunctionId.STO
    scwMapping[3] = SafetyFunctionId.STO
    scwMapping[4] = SafetyFunctionId.SLS_1
    scwMapping[5] = SafetyFunctionId.SLS_1

    swd_right_5_commissioning.py

    # mapping parameters
    scw = SafetyControlWordId.CAN_2
    scwMapping = [
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
        SafetyFunctionId.NONE,
    ]

    scwMapping[0] = SafetyFunctionId.STO
    scwMapping[1] = SafetyFunctionId.STO
    scwMapping[2] = SafetyFunctionId.STO
    scwMapping[3] = SafetyFunctionId.STO
    scwMapping[4] = SafetyFunctionId.SLS_1
    scwMapping[5] = SafetyFunctionId.SLS_1
ez-Support commented 2 years ago

According to this commissioning, for the left wheel: on COB-ID 0x160

    # SRDO_16
    # communication parameters (TX)
    srdoParam = SRDOParameters()
    srdoParam.can_id1 = 0x160
    srdoParam.can_id2 = 0x161
    srdoParam.valid = 1
    srdoParam.sct = 50
    srdoParam.srvt = 20
    error = commissioning.srdo_client.setSRDOParameters(SRDOId.SRDO_16, srdoParam)
    commissioning.check("setSRDOParameters(SRDOId.SRDO_16)", error)

    # mapping parameters
    scw = SafetyControlWordId.SAFEIN_1

And for the right wheel, according to this commissioning script, on COB-ID 0x109:

    # SRDO 16
    # communication parameters (TX)
    srdoParam = SRDOParameters()
    srdoParam.can_id1 = 0x109
    srdoParam.can_id2 = 0x10A
    srdoParam.valid = 1
    srdoParam.sct = 50
    srdoParam.srvt = 20
    error = commissioning.srdo_client.setSRDOParameters(SRDOId.SRDO_16, srdoParam)
    commissioning.check("setSRDOParameters(SRDOId.SRDO_16)", error)

    # mapping parameters
    scw = SafetyControlWordId.SAFEIN_1
ez-Support commented 2 years ago

If you want to hold the STO until a reset signal is sent, you have to set to Truethe value restart_acknowledge_behavior, in the commissioning script of each wheel.

fig-shimooka commented 2 years ago

How can a reset signal be sent?

ez-Support commented 2 years ago

As explained in the SWD Core User manual, you have to plug a Button on IO input of the wheel. image But this requires an additional OSSD input pairs.

fig-shimooka commented 2 years ago

swd This is how I am structured now. INSafe_1/INSafe_2 is connected to OSSD1/OSSD2 of SE2L and if it becomes STO, the STO is released by the OSSD signal of SE2L. restart_acknowledge_behaviour is set to True. When the obstacle was remove, the STO was not released even if 24 V was applied to INSafe_1/2 by OSSD1/2. This is INSafe_1/INSafe_2 in SWD2 of SWD2 is caused by the reset signal not being sent to INSafe_1/INSafe_2 of SWD2?

What I would like to do is. If the STO is applied by SE2L in this configuration, the STO should be retained even if the obstacle is removed. The STO should be released by a reset signal other than INSafe1/2 or by a message on the CAN.

fig-shimooka commented 2 years ago

There is another point of concern. When the emergency switch is pressed, the 0x160 or 0x10A CAN messages may stop for a certain period of time. I would like to immediately display that status on the interface when the emergency switch is pressed, but because of this problem this is not feasible. Is this a specification?

candump can0 |grep 10A results recorded. The emergency switch (actually a bumper sensor) is pressed at around 20 seconds. However, the can message has stopped and the current state cannot be retrieved.

https://user-images.githubusercontent.com/72783232/166086429-c9ec308b-2de0-4b71-8b3c-d19d513bcaca.mp4

fig-shimooka commented 2 years ago

ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€ใ€€After the emergency switch is deactivated, it will be inoperative for approx. 10 seconds. Is this also a specification(Sending cmd_vel does not work).? Can this waiting time be changed?

ez-Support commented 2 years ago

For the SRDO messages which looks like they stop, I would say it is only on the Linux that it appears. Can you have a look on the remote.py for smc_left and smc_right, and to the emergency logs. Make sure there is no new sct timeout.

ez-Support commented 2 years ago

I think that the 10seconds are due to the ROS applicative layer, as the SWD Core can restart instantly after the emergency signal was released.

ez-Support commented 2 years ago

For a restart after a STO signal, for now instead of applying a STO acknowledgment you can reset the node (cf. in remote.py), so that, you do not have to mind about SAFE IN signal to acknowledge. I'll come to you later with a solution with an input signal.

fig-shimooka commented 2 years ago

This is the state of swd_right when the emergency switch is pressed. What I find puzzling is that sometimes the state of the emergency stop cannot be retrieved for a certain period of time, and sometimes it can be retrieved immediately. When it cannot be retrieved, you have to wait about 10 seconds before you can retrieve the current state from the CAN message.

When I press the emergency switch, I want the interface to display it immediately.

DBUS Instance        : swd_right .................................................................... [OK]
Node ID              : 0x5 .......................................................................... [OK]
Vendor-Id            : 0x515 ........................................................................ [OK]
Product code         : 0x10001 ...................................................................... [OK]
Serial number        : 724434946 .................................................................... [OK]
Revision number      : 4 ............................................................................ [OK]
SWVersion            : 1.0.1 ........................................................................ [OK]
HWVersion            : 3.0.0 ........................................................................ [OK]
Calibrated           : True ......................................................................... [OK]
SRDO validity        : True ......................................................................... [OK]
NMT State            : PREOP  ....................................................................... [OK]
PDS State            : FAULT  ....................................................................... [OK]
NbError              : 9 ............................................................................ [OK]
LastError            : 800E : FAULT_ALIM_EXT ........................................................ [OK]
SystemError          : EZW_PROTECT_BRAKE_CC_PROTECT EZW_PROTECT_BRAKE_CC_PROTECT  ................... [OK]
SSW CAN1             : True, False, False, False, False, False, False, False  ....................... [OK]
SSW CAN2             : False, False, False, False, False, False, False, False  ...................... [OK]
SSW CAN3             : False, False, False, False, False, False, False, False  ...................... [OK]
SSW CAN4             : False, False, False, False, False, False, False, False  ...................... [OK]
SSW CAN5             : False, False, False, False, False, False, False, False  ...................... [OK]
SSW CAN6             : False, False, False, False, False, False, False, False  ...................... [OK]
SSW CAN7             : False, False, False, False, False, False, False, False  ...................... [OK]
SSW CAN8             : False, False, False, False, False, False, False, False  ...................... [OK]
SSW SAFEOUT          : False, False, False, False, False, False, False, False  ...................... [OK]
SCW SAFEIN_1         : False, False, False, False, False, False, True, True  ........................ [OK]
Peripheral           : True, True, True, False, True, True  ......................................... [OK]
VelocityModeSW       : internal_limit_active: False ................................................. [OK]
VelocityModeCW       : enable_ramp: False, unlock_ramp: False, reference_ramp: False, halt: False ... [OK]
Polarity             : velocity_polarity: False, position_polarity: False ........................... [OK]
TargetVelocity       : 0 ............................................................................ [OK]
VelocityDemand       : 0 ............................................................................ [OK]
VelocityActualValue  : 0 ............................................................................ [OK]
PositionValue        : -47 .......................................................................... [OK]
OdometryValue        : -45 .......................................................................... [OK]
fig-shimooka commented 2 years ago

We confirmed that it is possible to stop and release the system using reset node and start all. Does reset node mean pause? From the name, we feel that all states are reset.

ez-Support commented 2 years ago

Actually, it resets the CANopnen dictionnary settings from the saved configuration and restarts the node. It also restarts the CiA PDS FSA state machine. I'm not sure what you mean by 'pause'.

ez-Support commented 2 years ago

Can you have a look on your CPU load (htop), it think that it is overrun. Can you try your candump without the ROS applicative running, and tell me if the problem remains ? Have you opened the remote and see the errors list? Is there any new timeout appearing ?

fig-shimooka commented 2 years ago

The CPU maintained 50%. We assume that overrun is not the cause. The following error occurred in ezw-ros-bringup. We assume this is the cause.

May 06 17:12:55 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824775.095426867]: PDS state machine is not OK.
May 06 17:12:56 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824776.097909078]: Failed to set PDS state for right motor, EZW_ERR: SMCService : Controller::enterInOperationEnabledState() return error code : 6
May 06 17:12:56 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824776.097983811]: PDS state machine is not OK.
May 06 17:12:57 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824777.102076421]: Failed to set PDS state for right motor, EZW_ERR: SMCService : Controller::enterInOperationEnabledState() return error code : 6
May 06 17:12:57 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824777.102477338]: PDS state machine is not OK.
May 06 17:12:58 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824778.092524383]: Failed to set PDS state for right motor, EZW_ERR: SMCService : Controller::enterInOperationEnabledState() return error code : 6
May 06 17:12:58 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824778.092598338]: PDS state machine is not OK.
May 06 17:12:59 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824779.822460125]: PDS state machine is not OK.
May 06 17:13:03 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824783.728520309]: Inconsistant STO for left and right motors, left=1, right=0.
May 06 17:13:03 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824783.931550699]: Inconsistant STO for left and right motors, left=1, right=0.
May 06 17:13:04 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824784.133573422]: Inconsistant STO for left and right motors, left=1, right=0.
May 06 17:13:04 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824784.331084064]: Inconsistant STO for left and right motors, left=1, right=0.
May 06 17:13:04 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824784.554057072]: Inconsistant STO for left and right motors, left=1, right=0.
May 06 17:13:04 x86 sce-ros-bringup.sh[6365]: [ERROR] [1651824784.729913377]: Inconsistant STO for left and right motors, left=1, right=0.
May 06 17:13:04 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824784.822732054]: NMT state machine is not OK.
May 06 17:13:04 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824784.822854842]: PDS state machine is not OK.
May 06 17:13:04 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824784.896652345]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:05 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824785.096752039]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:05 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824785.296896447]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:05 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824785.496766609]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:05 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824785.696676565]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:05 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824785.804030112]: NMT state machine is not OK.
May 06 17:13:05 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824785.804107743]: PDS state machine is not OK.
May 06 17:13:05 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824785.896866286]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:06 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824786.096733380]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:06 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824786.296655478]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:06 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824786.496618095]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:06 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824786.696773819]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:06 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824786.805344539]: NMT state machine is not OK.
May 06 17:13:06 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824786.805414909]: PDS state machine is not OK.
May 06 17:13:06 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824786.896601728]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:07 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824787.096866888]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:07 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824787.297141015]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:07 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824787.496831536]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:07 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824787.696955049]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:07 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824787.806724860]: NMT state machine is not OK.
May 06 17:13:07 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824787.806841662]: PDS state machine is not OK.
May 06 17:13:07 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824787.896636993]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:08 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824788.096590215]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:08 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824788.296640155]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:08 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824788.496665224]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:08 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824788.696796375]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:08 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824788.810091573]: NMT state machine is not OK.
May 06 17:13:08 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824788.810214000]: PDS state machine is not OK.
May 06 17:13:08 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824788.896595582]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824789.096693659]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824789.296938776]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824789.496631424]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: [ WARN] [1651824789.696621170]: NMT state machine is not OK, no valid SafetyFunctions message to publish
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: roller;Check READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:55;;SMCDS;INFO;enterInOperationEnabledState;603;Controller;Check SWITCHED_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:55;;SMCDS;INFO;enterInOperationEnabledState;623;Controller;Check OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:55;;SMCDS;ERROR;enterInOperationEnabledState;632;Controller;Not in OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:55;;SMCDS;INFO;enterInOperationEnabledState;515;Controller;Check NOT_READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:55;;SMCDS;INFO;enterInOperationEnabledState;535;Controller;Check FAULT;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:55;;SMCDS;INFO;enterInOperationEnabledState;544;Controller;FAULT detected;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:56;;SMCDS;INFO;enterInOperationEnabledState;562;Controller;Check SWITCH_ON_DISABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:56;;SMCDS;INFO;enterInOperationEnabledState;582;Controller;Check READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:56;;SMCDS;INFO;enterInOperationEnabledState;603;Controller;Check SWITCHED_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:56;;SMCDS;INFO;enterInOperationEnabledState;623;Controller;Check OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:56;;SMCDS;ERROR;enterInOperationEnabledState;632;Controller;Not in OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:56;;SMCDS;INFO;enterInOperationEnabledState;515;Controller;Check NOT_READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:56;;SMCDS;INFO;enterInOperationEnabledState;535;Controller;Check FAULT;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:56;;SMCDS;INFO;enterInOperationEnabledState;544;Controller;FAULT detected;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:57;;SMCDS;INFO;enterInOperationEnabledState;562;Controller;Check SWITCH_ON_DISABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:57;;SMCDS;INFO;enterInOperationEnabledState;582;Controller;Check READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:57;;SMCDS;INFO;enterInOperationEnabledState;603;Controller;Check SWITCHED_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:57;;SMCDS;INFO;enterInOperationEnabledState;623;Controller;Check OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:57;;SMCDS;ERROR;enterInOperationEnabledState;632;Controller;Not in OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:57;;SMCDS;INFO;enterInOperationEnabledState;515;Controller;Check NOT_READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:57;;SMCDS;INFO;enterInOperationEnabledState;535;Controller;Check FAULT;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:57;;SMCDS;INFO;enterInOperationEnabledState;544;Controller;FAULT detected;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:58;;SMCDS;INFO;enterInOperationEnabledState;562;Controller;Check SWITCH_ON_DISABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:58;;SMCDS;INFO;enterInOperationEnabledState;582;Controller;Check READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:58;;SMCDS;INFO;enterInOperationEnabledState;603;Controller;Check SWITCHED_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:58;;SMCDS;INFO;enterInOperationEnabledState;623;Controller;Check OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:58;;SMCDS;ERROR;enterInOperationEnabledState;632;Controller;Not in OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:58;;SMCDS;INFO;enterInOperationEnabledState;515;Controller;Check NOT_READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:58;;SMCDS;INFO;enterInOperationEnabledState;535;Controller;Check FAULT;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:58;;SMCDS;INFO;enterInOperationEnabledState;544;Controller;FAULT detected;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:59;;SMCDS;INFO;enterInOperationEnabledState;562;Controller;Check SWITCH_ON_DISABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:59;;SMCDS;INFO;enterInOperationEnabledState;571;Controller;SWITCH_ON_DISABLED detected;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:59;;SMCDS;INFO;enterInOperationEnabledState;582;Controller;Check READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:59;;SMCDS;INFO;enterInOperationEnabledState;591;Controller;READY_TO_SWITCH_ON detected;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:59;;SMCDS;INFO;enterInOperationEnabledState;603;Controller;Check SWITCHED_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:59;;SMCDS;INFO;enterInOperationEnabledState;612;Controller;SWITCHED_ON detected;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:59;;SMCDS;INFO;enterInOperationEnabledState;623;Controller;Check OPERATION_ENABLED;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:12:59;;SMCDS;INFO;enterInOperationEnabledState;636;Controller;OPERATION_ENABLED detected;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:13:9;;SMCDS;INFO;enterInOperationEnabledState;515;Controller;Check NOT_READY_TO_SWITCH_ON;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:13:9;;SMCDS;INFO;enterInOperationEnabledState;535;Controller;Check FAULT;
May 06 17:13:09 x86 sce-ros-bringup.sh[6365]: 2022-5-6 17:13:9;;SMCDS;INFO;enterInOperationEnabledState;562;Controller;Check SWITCH_ON_DISABLED;
fig-shimooka commented 2 years ago

This was achieved by changing the SE2L interlock release conditions to manual. This matter has been resolved. https://github.com/ezWheelSAS/swd_ros_controllers/issues/12#issuecomment-1111980453

ez-Support commented 2 years ago

Can you please send us the EMCY list, from the remote.py The CiA 402 PDS FSA state machine fails to start, it seems that input signal from STO is not valid.