Feature: Vehicle Interface

[HaoruXue]

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

Provide a vehicle_interface package that aligns with the architechture proposal.

Purpose

• Provide an extendable vehicle interface model and ROS2 node
• Support various vehicle platform needs (F1TENTH vehicle to begin with)

The vehicle_interface is responsible for bridging Autoware and a specific vehicle. It converts Autoware control commands and vehicle commands to vehicle-specific messages, and convert the vehicle status (steering angle report, headlight state, etc.) to Autoware messages.

While the Autoware side speaks ROS2 messages, the vehicle side of the interface could be in many forms. In most cases the vehicle interface simply publishes a different set of messages to a vehicle ROS2 driver, who then handles the communication with the actual vehicle via CAN, TCP/IP, USB, etc. In a few cases, the vehicle interface itself may include an instance of the vehicle platform's C++ API, who then communicates directly with the vehicle without a separate ROS2 driver. All these situations require a versatile design on the vehicle interface base class.

Possible approaches

Analysis of Autoware.Auto approach

A potential implementation may be very similar to the Autoware.Auto vehicle_interface where the user needs to subclass platform_interface to implement callbacks linked to receiving Autoware commands, or queried to report vehicle status.

Some issue with the design:

1. The boundary between vehicle_interface_node and platform_interface is not clear. in ssc_interface and vesc_interface, parameter declaration happens in the node while publishers and subscribers are created in the platform_interface subclass.
2. The platform_interface, seemingly separated from ROS, is not ROS-agnostic. In many use cases the user needs to pass in their own subclassed node when constructing the platform_interface who would then declare additional publishers and subscribers.
3. The subclassed nodes, such as VescInterfaceNode and SscInterfaceNode, are useless other than declaring parameters for the underlying platform_interface subclass.

Improvement on the Autoware.Auto approach

I can see two way of resolving the issue:

1. Have vehicle_interface_node subclass base_interface (aka platform_interface). This way the user needs to only implement interface callbacks in their own subclass of vehicle_interface_node directly.
   

2. When making new interfaces, no need to subclass vehicle_interface_node. Make base_interface a ROS2 plugin. The users now implement the functions in their own package which only contains their own plugin (e.g. VESC plugin, simulator plugin). The plugin would also have access to a ROS2 node for declaring additional pubs, subs and parameters. At launching, the user launches the vehicle_interface_node and provide it with a parameter to load the user-made plugin. The vehicle_interface_node will pass itself to the plugin. This design also decouples the dependencies.
   

Method 1 essentially adds all base_interface functions to the ROS2 node directly, eliminating the need to let the custom_interface declare ROS2 pubs, subs and params for the node. Method 2 does the exact opposite by letting the custom_interface itself handle any additional ROS2 operations it needs.

Method 1 violates the design principle of abstracting node functionalities into a separate model class. Method 2 violates the design principle of not exposing ROS2 operations to the underlying model class.

Method 1 creates a clear chain of inheritance for user to quickly start implement their own interface. Method 2 decouples the custom interface's dependency on the Autoware vehiclel_interface_node and has benifits described in ROS pluginlib wiki.

Definition of done

• Provide vehicle_interface base package
• Provide testing interface node
• Aftering merging, create issue for porting VESC interface.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.