ROS2 interface for the RoadNetwork

[agalbachicar]

Desired behavior

Provide a ROS2 interface for the maliput::api::RoadNetwork.

The following is a list of characteristics we want:

• It must be a query - response via ROS2 services.
• It must be able to load RoadNetworks by means of ROS parameters (YAML description) or via a service call as well.
• It must be a component, and provide some launchfiles for easy use and integration into other systems.
• There must be an executable to trigger with ros2 run
• A data translation layer is desired to make this query entity as reusable as possible for future integrations.

Implementation suggestion

The following suggests a feature complete list of tasks.

• Create a package for messages in which we start by migrating the maliput types into it. Create a message package #2
  • Types for RoadGeometry, BranchPoint, Junction, Segment and Lane queries. Adds geometric descriptions and a few basic requests for the entities. #3
  • Types for RoadRulebook and RuleRegistry.
  • Types for Phases and friends.
  • Types for Intersections.
  • Types for other misc. entities (object API and so on).
• Create the translation layer: from maliput types into ros messages and vice versa.
  • Translate types for RoadGeometry, BranchPoint, Junction, Segment and Lane queries. Starts with the translation interface for geometric types. #4 Complete tests for geometric type translations #5 Completes documentation #6
  • Translate types for RoadRulebook and RuleRegistry.
  • Translate types for Phases and friends.
  • Translate types for Intersections.
  • Translate types for other misc. entities (object API and so on).
• Load a RoadNetwork from a set of parameters
  • Build a Node that parses the arguments and loads a RoadNetworkPlugin. Create maliput_ros package #7 Create maliput ros node #8
  • Provide a lauchfile and a few yaml sample configurations. Create maliput ros node #8
  • Provide a ROS2 executable.
• Provide API coverage:
  • Provide coverage to the RoadGeometry and other friend entities. Create maliput ros node #8 Add tests to ROS node #10 Add get junction service #14 Add get segment service #15 Adds lane service #16 Adds branch point service #17 Refactor tests to scale build time #18 Road position services #19 Routing service #20 Sample lane s route #21
  • Provide coverage to the RoadRulebook and RuleRegistry, and other friend entities.
  • Provide coverage to the Phases and other friend entities.
  • Provide coverage to the Intersections.
  • Provide coverage to other misc. entities (object API and so on).

Additional context

This is a required interface to enable multi-agent simulation with ROS2 based systems that will help to spread the use of maliput with other development environments.

[francocipollone]

It must be able to load RoadNetworks by means of ROS parameters (YAML description) or via a service call as well.

As the ROS parameters will be variable: (It will depend on each backend): I imagine a couple of options:

A: Follow a nomenclature:

ros2_maliput:
    ros__parameters:
        maliput_backend: "maliput_malidrive"
        number_of_parameters: 2
        parameter_1:
          key: linear_tolerance
          value: 1
        parameter_2:
          key: angular_tolerance
          value: 1

B: Pass a path to the yaml file where the parameters are later on loaded:

ros2_maliput:
    ros__parameters:
        maliput_backend: "maliput_malidrive"  // Could be omitted if added in next file.
        configuration_path: "my_parameters.yaml"

And this will be loaded using yaml-cpp lib, not using ROS parameters interface.

my_parameters.yaml:

ros2_maliput:
    maliput_backend: "maliput_malidrive"  // Could be omitted if added in ros_param
    parameters:
         <key_1>: <value_1>
         <key_2>: <value_2>
          ...
         <key_N>: <value_N>

[agalbachicar]

Some design comments after talking with @francocipollone :

• To load RoadNetworks, use CreateRoadNetwork() function from the plugin interface as it hides all the unnecessary complexity.
• To load the parameters that will end up being a std::map<string,string> as a second argument of the aforementioned function, the best thing is to clone the recent implementation from maliput_viz.
• We should better keep two entities separated:
  • MaliputQuery which is a class that will manage the direct and high level queries to the RoadNetwork.
  • MaliputRosNode which is a proper ROS2 node that will follow the style of ROS2 in terms of API, lifecycle and error management and reporting. Initially, we will inject a MaliputQuery into a MaliputRosNode. We will manage the impendance mismatch between the maliput and the ROS2 world within the node class.

[agalbachicar]

MaliputRosNode must subclass rclcpp_lifecycle::LifecycleNode to properly manage initialization and further node management as a component. Some links for future reference:

• http://design.ros2.org/articles/node_lifecycle.html
• https://docs.ros.org/en/galactic/Concepts/About-Composition.html
• https://docs.ros.org/en/galactic/How-To-Guides/Launching-composable-nodes.html

[agalbachicar]

I think this first milestone of having the RoadGeometry and some basic routing support is enough to test it with some integration examples with agents before proceeding and iterating on something more complex with the rules.