Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor vehicle_cmd_gate #9235

Open
3 of 19 tasks
isamu-takagi opened this issue Nov 5, 2024 · 1 comment
Open
3 of 19 tasks

Refactor vehicle_cmd_gate #9235

isamu-takagi opened this issue Nov 5, 2024 · 1 comment
Assignees
Labels
component:control Vehicle control algorithms and mechanisms. (auto-assigned) component:interfaces Communication protocols, interfaces and messages. component:system System design and integration. (auto-assigned) type:improvement Proposed enhancement

Comments

@isamu-takagi
Copy link
Contributor

isamu-takagi commented Nov 5, 2024

Checklist

  • I've read the contribution guidelines.
  • I've searched other issues and no duplicate issues were found.
  • I've agreed with the maintainers that I can plan this task.

Description

The vehicle_cmd_gate was originally a simple node that filtered out abnormal values ​​in control commands, but repeated modifications have made its functionality more complex. In addition, since there is some overlap with newly added functions such as command selection and MRM, we will reorganize these functions and rearrange them.

Most of these changes will be made by adding new packages, so the current vehicle_cmd_gate can continue to be used. We will evaluate it and switch over when it is complete.

Purpose

Clarify the functions of the following existing nodes and divide them appropriately.

  • vehicle_cmd_gate
  • operation_mode_transition_manager
  • mrm_handler
  • mrm_emergency_stop_operator
  • mrm_comfortable_stop_operator
  • external_cmd_selector
  • external_cmd_converter

Possible approaches

Diagram

The rectangles are the nodes or functions and the ellipses are the interfaces (topic or service).

new
vehicle-cmd-gate-new

old
vehicle-cmd-gate-old

Changes (states)

  • As before, the operation mode and MRM will be managed separately.
    • Operation mode (stop, autonomous, local. remote)
    • MRM (emergency_stop, comfortable_stop, pull_over, moderate_stop)
  • From an interface perspective, they will be unified so that they can be treated the same.
  • Each operation mode and each MRM generates a command to be input to the vehicle_cmd_gate.
  • Some operation mode (such as remote mode by a driver) may take priority over some MRM,.

Changes (interfaces)

  • Each operation mode and MRM will have its own control, gear, turn_indicators, and hazard_lights commands.
    • Currently, other than control commands, there are only two types: normal and emergency.
  • For implementation reasons, pull-over and comfortable stop share the same topic as autonomous, but are treated separately in terms of design.

Changes (nodes)

  • vehicle_cmd_gate (control_cmd_gate)
    • Create a new one as control_cmd_gate. This is to make it possible to use both during migration and to clarify that it is a control component node.
    • Separate moderate stop. Moderate stop is a gradual stop that does not depend on planning components and is considered to be one of the MRMs.
    • Separate adapi pause. This is because the mode to be applied depends on the system design and should be processed before the gate.
    • Separate mode transition filter. This is because the mode to be applied depends on the system design and should be processed before the gate.
    • Separate external emergency stop. This should be managed within the MRM framework.
    • Separate stop mode command. Until now, this was used in conjunction with the built-in emergency stop command, but this is to leave room for expansion, such as a gradual stop during the stop transition.
    • The command selection function will be maintained (we are considering sending multiple candidates in order of priority).
    • The command timeout detection function will be maintained (this will be executed for each command entered).
    • The command anomaly detection function will be maintained.
    • The built-in emergency stop command generation will be maintained.
      • It will be used when the specified command input is not available.
      • It can also be explicitly selected in the command selection function.
    • Autoware engage will be clearly divided into two types.
      • One is autonomous stop hold (tentative name).
        • A temporary stop of autonomous driving, such as stopping at a bus stop, will be treated as stop mode, and will be realized by switching with the command selection function.
        • Stop mode may be automatically operated by the application.
        • Stop mode may be overwritten by MRM.
        • It will be considered that the vehicle is stopped by the control of autonomous driving.
      • Another is force stop (tentative name).
        • It will always output a command equivalent to the built-in emergency stop.
        • This function is intended to completely stop the vehicle.
        • Switching should be tied to direct human operation, not automatic operation.
        • It will not be overwritten by MRM.
        • It will be considered that the vehicle is stopped by the manual driving.
  • external_cmd_selector
    • Removed. All command selection functions will be unified into control_cmd_gate.
  • external_cmd_converter
    • Applies to each external command (remote, local) as necessary (if both are used, launch for each).
  • operation_mode_transition_manager
    • For the mode transition availability determination function, separate each condition into a node that outputs it as a diagnostic. The transition conditions can be customized in the diagnostic graph settings.
    • For the mode transition completion confirmation function, integrate it into operation_mode_decider.
    • For the mode change function, integrate it into operation_mode_decider along with the MRM selection.
  • mrm_handler
    • For the MRM selection function, integrate it into operation_mode_decider along with the mode selection.
  • mrm_operator
    • For the MRM activation function, integrate it into the operation_mode_decider plugin.
  • operation_mode_decider (or command_source_decider)
    • All operation modes and MRMs are treated uniformly, and the selection status of each command is managed.
    • This is because remote operation modes, etc., may have a higher priority than some MRMs.
    • Command source switching is implemented by a plugin, which has the following interface:
      • Request (enable, disable)
      • State (enable requested, enable completed, disabled)
  • Other newly created nodes (separated functions)
    • generate stop mode command
    • generate moderate stop command
    • adapi pause
    • mode transition filter
    • external emergency stop (Manual MRM activation)
    • mode transition availability determination function in operation_mode_transition_manager

Definition of done

  • Create control_cmd_gate node
  • Remove external_cmd_selector
  • Move operation_mode_transition_manager functions.
    • Move transition availability determination function
    • Move mode transition completion confirmation function.
    • Move mode change function
  • Create operation_mode_decider (or command_source_decider)
    • Move mrm_handler function
    • Move mrm_emergency_stop_operator function
    • Move mrm_comfortable_stop_operator function
  • Move vehicle_cmd_gate functions
    • Move function to generate autonomous stop hold mode command
    • Move function to generate moderate stop command
    • Move adapi pause
    • Move mode transition filter
    • Move external emergency stop (Manual MRM activation)
@isamu-takagi isamu-takagi added component:control Vehicle control algorithms and mechanisms. (auto-assigned) component:system System design and integration. (auto-assigned) labels Nov 5, 2024
@isamu-takagi isamu-takagi self-assigned this Nov 5, 2024
@isamu-takagi isamu-takagi added type:improvement Proposed enhancement component:interfaces Communication protocols, interfaces and messages. labels Nov 5, 2024
@isamu-takagi
Copy link
Contributor Author

If there are no concerns about the changes, we plan to work on December.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:control Vehicle control algorithms and mechanisms. (auto-assigned) component:interfaces Communication protocols, interfaces and messages. component:system System design and integration. (auto-assigned) type:improvement Proposed enhancement
Projects
None yet
Development

No branches or pull requests

1 participant