[Migrated issue | sirius_signal_lights_driver] Separate Code for Controlling Signal Lights and Deducting Robot Status

Wihmajster commented 6 months ago

This is a migrated issue and refers only to sirius_signal_lights_driver package

Deducting robot status seems to be a universal task, not limited to signal lights. Consider creating a dedicated node in the sirius_control package within the sirius_common repository that will generate the RobotStatus message. This message is designed for robotic manipulators using the ROS industrial ecosystem, but we can adapt it for our robot without losing its semantic meaning. The only exception would be the RobotMode field, where "Auto" also refers to teleoperation. In our case, "manual" mode would represent teleoperation and "auto" would represent autonomous mode. Although this is a misuse of the message, clarifying it in the documentation should prevent misunderstandings. This can serve as a good starting point, and we can improve or potentially create our own message for mobile robots in the future.

The RobotStatus message could then be used by the web interface and signal lights. Since signal lights can already be controlled by ROS messages via the socketcan_bridge package, there is no need to create an additional interface. Therefore, a node controlling the lights would directly subscribe to the RobotStatus message and send appropriate CAN messages based on user configuration. An optimal format for user configuration could look like this:

blue: # Autonomous mode
    status: # Light will be enabled when robot status matches this configuration
        mode: auto
        e_stopped: false
        # other settings are not declared if their value does not matter for this light
    some_other_important_settings_if_any: some important value 
red: # Motors powered
    status:
        e_stopped: false
        drives_powered: true
yellow: # Teleoperation
    status:
        mode: manual
        e_stopped: false
        motion_possible: true

If this version suits you, I also recommend renaming the package for controlling the signal lights to "sirius_signal_lights_driver" or "sirius_indicator_driver." The "sirius" prefix and "driver" suffix would better match the REP 144 recommendations.

Wihmajster commented 5 months ago

I've reviewed ISO 10218-1 (though I only have partial access) and its guidelines on the safe design of industrial robots, which helped me better understand the RobotStatus message. Here’s my interpretation of specific fields within this message:

Mode: Manual

Manual mode refers to the manual control of the robot. For industrial manipulator robots, this usually means using a Teach Pendant, a handheld control panel (wired or wireless).

Mode: Auto

According to the message description:

When in manual, remote motion is not possible.

This suggests that Auto mode refers to remote motion. However, the exact definition of remote operation is not provided. Auto mode typically means the robot performs programmed tasks autonomously. In this context, remote operation likely means that the robot is controlled by ROS, which usually involves advanced autonomous tasks utilizing machine vision. For our robot, which operates natively on ROS, whether controlled manually or autonomously, we should interpret manual and auto modes directly as manual or autonomous control without overcomplicating the definitions.

e_stopped

This state indicates when the user has initiated an emergency stop or when the robot itself detects a critical failure. After entering this state and resolving the emergency, the user must manually exit this state. The procedure for exiting this state should be clearly signaled to avoid unexpected actions. Immediate control should not be possible; clearing the e-stop must be a separate action performed by the user.

Drives Powered

Indicates whether the motors are powered.

Motion Possible

Shows whether robot motion is currently possible and not prevented by other protective measures. Unlike e_stopped, this state does not need to be cleared. It mainly pertains to situations where automatic safeguards prevent robot motion, such as a light curtain breach in industrial robots. In our case, dealing with a relatively light and slow mobile robot, we won’t have many such safeguards. One example could be the REQ-OPS-070 requirement from ERC, where we need to wait 5 seconds after signaling robot activity using a light indicator.

In Motion

Indicates whether the robot is moving or stationary. This is different from drives_powered, as the robot can hold its position (not moving) on a steep terrain with powered wheel motors to prevent rolling down.

Currently, we don't have any safeguards implemented (including the one from the REQ-OPS-070 ERC requirement), so motion_possible will always be true and won’t currently be used.

The same applies to e_stopped. Our emergency stop currently shuts down everything, including the PC running ROS, so in practice, e_stopped will always be false. In the future, we could implement a software-triggered e-stop where only the motors are shut down, but for now, this field will not be used in practice.

We should also review this design against ARC, ERC, and URC competition rules to ensure all requirements are covered with the described setup.

KlaNiedz commented 5 months ago

Taking into consideration colors of the lamps, there are different requirements in every competition.

ERC: There are no specific colors assigned to certain state. It is only emphasized that indicator lamps shall inform the user about the state of the rover, e.g. standby, working, in autonomous mode. However, there is mentioned that the indicator lamp shall emit visible signals at least 5 seconds prior to any planned rover activity and continue to emit visible signals until all rover activities are finished. What is more, the rover shall not perform any activity within first 5 seconds of the indicator lamp emitting visible signals.

ARC: Green - remotely controlled, Yellow - autonomous control, Red - indicate disarm,

URC: LED indicator on the back of the rover must be visible in bright daylight. Red - autonomous operation, Blue - manually driving, Flashing Green - successful arrival at a location,

SKA-Robotics / sirius_robot