Add ROS actions in SCXML

.github/workflows/lint.yml

@@ -71,7 +71,7 @@ jobs:
           use-pydocstyle: false
           extra-pylint-options: ""
           extra-pycodestyle-options: ""
-          extra-flake8-options: ""
+          extra-flake8-options: "--max-line-length=100"
           extra-black-options: ""
           extra-mypy-options: "--ignore-missing-imports"
           extra-isort-options: ""

as2fm_common/src/as2fm_common/common.py

@@ -17,22 +17,27 @@
 Common functionalities used throughout the toolchain.
 """
 
-from typing import Union
+from typing import List, Union
 
-ValidTypes = Union[bool, int, float]
-"""We define the basic types that are supported by the Jani language:
+"""
+Set of basic types that are supported by the Jani language.
 
-// Types
-// We cover only the most basic types at the moment.
-// In the remainder of the specification, all requirements like "y must be of type x" are to be interpreted
-// as "type x must be assignable from y's type".
+Basic types (from Jani docs):
+Types
+We cover only the most basic types at the moment.
+In the remainder of the specification, all requirements like "y must be of type x" are to be
+interpreted as "type x must be assignable from y's type".
 var BasicType = schema([
 "bool", // assignable from bool
 "int", // numeric; assignable from int and bounded int
 "real" // numeric; assignable from all numeric types
 ]);
 src https://docs.google.com/document/d/\
-    1BDQIzPBtscxJFFlDUEPIo8ivKHgXT8_X6hz5quq7jK0/edit"""
+    1BDQIzPBtscxJFFlDUEPIo8ivKHgXT8_X6hz5quq7jK0/edit
+
+Additionally, we support the array types from the array extension.
+"""
+ValidTypes = Union[bool, int, float, List[int], List[float]]
 
 
 def ros_type_name_to_python_type(type_str: str) -> type:
@@ -51,6 +56,10 @@
         return int
     if type_str in ['float32', 'float64']:
         return float
+    if type_str in ['sequence<int32>', 'sequence<int64>']:
+        return List[int]
+    if type_str in ['sequence<float32>', 'sequence<float64>']:
+        return List[float]
     raise NotImplementedError(f"Type {type_str} not supported.")
 
 
@@ -67,4 +76,4 @@
         tag_wo_ns = tag.split('}')[-1]
     else:
         tag_wo_ns = tag
-    return tag_wo_ns
+    return tag_wo_ns

docs/source/howto.rst

@@ -104,11 +104,14 @@ ROS Topics are used to publish (via a ROS Publisher) and receive (via a ROS Subs
 .. code-block:: xml
 
     <!-- ROS Topic Subscriber -->
-    <ros_topic_subscriber topic="/topic1" type="std_msgs/Bool" />
+    <ros_topic_subscriber name="bool_topic" topic="/topic1" type="std_msgs/Bool" />
     <!-- ROS Topic Publisher -->
-    <ros_topic_publisher topic="/topic2" type="std_msgs/Int32" />
+    <ros_topic_publisher name="int_topic" topic="/topic2" type="std_msgs/Int32" />
 
-Once created, subscribers and publishers can be referenced using the `topic` name, and can be used in the states to send messages and perform callbacks upon receiving messages:
+The two declarations above will create a ROS subscriber called `bool_topic` that reads messages of type `std_msgs/Bool` from the topic `/topic1` and a ROS publisher called `int_topic` that writes messages of type `std_msgs/Int32` on the topic `/topic2`.
+The `name` argument is optional, and if not provided, it will be set to the same value as the `topic` argument.
+
+Once created, subscribers and publishers can be referenced using their names (`bool_topic` and `int_topic`), and can be used in the states to send messages and perform callbacks upon receiving messages:
 
 .. code-block:: xml
 
@@ -117,19 +120,19 @@ Once created, subscribers and publishers can be referenced using the `topic` nam
     </datamodel>
 
     <state id="src_state">
-        <ros_topic_callback topic="/topic1" target="target_state">
+        <ros_topic_callback name="bool_topic" target="target_state">
             <assign location="internal_var" expr="_msg.data" />
         </ros_topic_callback>
     </state>
 
     <state id="target_state">
         <onentry>
             <if cond="internal_bool">
-                <ros_topic_publish topic="/topic2" >
+                <ros_topic_publish name="int_topic" >
                     <field name="data" expr="10">
                 </ros_topic_publish>
             <else />
-                <ros_topic_publish topic="/topic2" >
+                <ros_topic_publish name="int_topic" >
                     <field name="data" expr="20">
                 </ros_topic_publish>
             </if>
@@ -154,11 +157,11 @@ The declaration of a ROS Service server and the one of a client can be achieved
 .. code-block:: xml
 
     <!-- ROS Service Server -->
-    <ros_service_server service_name="/service1" type="std_srvs/SetBool" />
+    <ros_service_server name="the_srv" service_name="/service1" type="std_srvs/SetBool" />
     <!-- ROS Service Client -->
-    <ros_service_client service_name="/service2" type="std_srvs/Trigger" />
+    <ros_service_client name="the_client" service_name="/service2" type="std_srvs/Trigger" />
 
-Once created, servers and clients can be referenced using the `service_name` name, and can be used in the states of a SCXML model to provide and request services.
+Once created, servers and clients can be referenced using the provided `name` (i.e. `the_srv` and `the_client`), and can be used in the states of a SCXML model to provide and request services.
 In the following, an exemplary client is provided:
 
 .. code-block:: xml
@@ -169,16 +172,16 @@ In the following, an exemplary client is provided:
 
     <state id="send_req">
         <onentry>
-            <ros_service_send_request service_name="/service2">
+            <ros_service_send_request name="the_client">
             </ros_service_send_request>
         </onentry>
-        <ros_service_handle_response service_name="/service2" target="done">
+        <ros_service_handle_response name="the_client" target="done">
             <assign location="internal_bool" expr="_res.success" />
         </ros_service_handle_response>
     </state>
 
 To send a request, the `ros_service_send_request` can be used where any other executable content may be used.
-After the server has processed the service, `ros_service_handle_response`, can be used similarly to a SCXML transition and is triggered by the server.
+After the server has processed the service, `ros_service_handle_response`, can be used similarly to a SCXML transition and is triggered when a response from the server is received.
 The data of the request can be accessed with the `_res` field.
 
 And here, an example of a server:
@@ -190,9 +193,9 @@ And here, an example of a server:
     </datamodel>
 
     <state id="idle">
-        <ros_service_handle_request service_name="/service1" target="idle">
+        <ros_service_handle_request name="the_srv" target="idle">
             <assign location="temp_data" expr="_req.data" />
-            <ros_service_send_response service_name="/adder">
+            <ros_service_send_response name="the_srv">
                 <field name="success" expr="temp_data" />
             </ros_service_send_response>
         </ros_service_handle_request>
@@ -215,7 +218,60 @@ TODO
 Creating a SCXML model of a BT plugin
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-TODO
+SCXML models of BT plugins can be done similarly to the ones for ROS nodes. However, in BT plugins there are a few special functionalities that are provided:
+
+* :ref:`BT communication <bt_communication>`: A set of special events that are used in each BT plugins for starting a BT Node and provide results.
+* :ref:`BT Ports <bt_ports>`: A special BT interface to parametrize a specific plugin instance.
+
+
+.. _bt_communication:
+
+BT Communication
+_________________
+
+TODO: describe `bt_tick`, `bt_running`, `bt_success`, `bt_failure`.
+
+
+.. _bt_ports:
+
+BT Ports
+________
+
+Additionally, when loading a BT plugin in the BT XML Tree, it is possible to configure a specific plugin instance by means of the BT ports.
+
+As in the case of ROS functionalities, BT Ports need to be declared before being used, to provide the port name and expected type.
+
+.. code-block:: xml
+
+    <bt_port key="my_string_port" type="string" />
+    <bt_port key="start_value" type="int32">
+
+Once declared, it is possible to reference to the port in multiple SCXML entries.
+
+For example, we can use `my_string_port` to define the topic used by a ROS publisher.
+
+.. code-block:: xml
+
+    <ros_topic_publisher name="int_topic" type="std_msgs/Int32">
+        <topic>
+            <bt_get_input key="my_string_port" />
+        </topic>
+    </ros_topic_publisher>
+
+Or we can use `start_value` to define the initial value of a variable.
+
+.. code-block:: xml
+
+    <datamodel>
+        <data id="counter" type="int32">
+            <expr>
+                <bt_get_input key="start_value" />
+            </expr>
+        </data>
+    </datamodel>
+
+
+BT ports can also be linked to variables in the `BT Blackboard` by wrapping the variable name in curly braces in the BT xml file. However, this feature is not yet supported.
 
 
 .. _additional_params_howto:

jani_generator/src/jani_generator/convince_jani_helpers/convince_to_plain_jani.py

@@ -37,9 +37,9 @@
 
 
 def __convince_env_model_to_jani(base_model: JaniModel, env_model: dict):
-    """Add the converted entries from the convince environment model to the provided JaniModel object."""
+    """Add the converted entries from the convince environment model to the provided JaniModel."""
     # Check if the base_model is a JaniModel instance
     assert isinstance(base_model, JaniModel), "The base_model should be a JaniModel instance"
     # Check if the env_model is a dictionary
     assert isinstance(env_model, dict), "The env_model should be a dictionary"
     # Check if the env_model has the required keys
@@ -61,25 +61,32 @@
         # The robot pose should be stored using integers -> centimeters and degrees
         base_model.add_variable(f"robots.{robot_name}.pose.x_cm", int, to_cm(robot_pose["x"]))
         base_model.add_variable(f"robots.{robot_name}.pose.y_cm", int, to_cm(robot_pose["y"]))
-        base_model.add_variable(f"robots.{robot_name}.pose.theta_deg", int, to_deg(robot_pose["theta"]))
+        base_model.add_variable(f"robots.{robot_name}.pose.theta_deg", int,
+                                to_deg(robot_pose["theta"]))
         base_model.add_variable(f"robots.{robot_name}.pose.x", float, transient=True)
         base_model.add_variable(f"robots.{robot_name}.pose.y", float, transient=True)
         base_model.add_variable(f"robots.{robot_name}.pose.theta", float, transient=True)
         base_model.add_variable(f"robots.{robot_name}.goal.x", float, transient=True)
         base_model.add_variable(f"robots.{robot_name}.goal.y", float, transient=True)
         base_model.add_variable(f"robots.{robot_name}.goal.theta", float, transient=True)
         robot_shape = robot["shape"]
-        base_model.add_constant(f"robots.{robot_name}.shape.radius", float, float(robot_shape["radius"]))
-        base_model.add_constant(f"robots.{robot_name}.shape.height", float, float(robot_shape["height"]))
-        base_model.add_constant(f"robots.{robot_name}.linear_velocity", float, float(robot["linear_velocity"]))
-        base_model.add_constant(f"robots.{robot_name}.angular_velocity", float, float(robot["angular_velocity"]))
+        base_model.add_constant(f"robots.{robot_name}.shape.radius", float,
+                                float(robot_shape["radius"]))
+        base_model.add_constant(f"robots.{robot_name}.shape.height", float,
+                                float(robot_shape["height"]))
+        base_model.add_constant(f"robots.{robot_name}.linear_velocity", float,
+                                float(robot["linear_velocity"]))
+        base_model.add_constant(f"robots.{robot_name}.angular_velocity", float,
+                                float(robot["angular_velocity"]))
     if "obstacles" in env_model:
         # Extract the obstacles from the env_model
         # TODO
         pass
     # TODO: Discuss the perception part
-    # TODO: Discuss the possibility of generating a base automata for each robot + standard edges (i.e. switch_on/off, drive, rotate)
-    # This would make sense, allowing the definition of default mobile robots without the need of defining how they drive.
+    # TODO: Discuss the possibility of generating a base automata for each robot + standard edges
+    # (i.e. switch_on/off, drive, rotate)
+    # This would make sense, allowing the definition of default mobile robots without the need of
+    # defining how they drive.
     # By the way, keeping this out for now!
 
 
@@ -104,7 +111,8 @@
     assert isinstance(base_model, JaniModel), "The base_model should be a JaniModel instance"
     for property_dict in properties:
         assert isinstance(property_dict, dict), "The properties list should contain dictionaries"
-        base_model.add_jani_property(JaniProperty(property_dict["name"], property_dict["expression"]))
+        base_model.add_jani_property(JaniProperty(property_dict["name"],
+                                                  property_dict["expression"]))
 
 
 def convince_jani_parser(base_model: JaniModel, convince_jani_path: str):
@@ -119,7 +127,8 @@
     # ---- Metadata ----
     base_model.set_name(convince_jani_json["name"])
     # Make sure we are loading a convince-jani file
-    assert "features" in convince_jani_json and "convince_extensions" in convince_jani_json["features"], \
+    assert "features" in convince_jani_json and \
+        "convince_extensions" in convince_jani_json["features"], \
         "The provided file is not a convince-jani file (missing feature entry)"
     # Extract the environment model from the convince-jani file
     # ---- Environment Model ----

jani_generator/src/jani_generator/jani_entries/jani_automaton.py

@@ -22,6 +22,10 @@
 
 
 class JaniAutomaton:
+    @staticmethod
+    def from_dict(automaton_dict: dict) -> "JaniAutomaton":
+        return JaniAutomaton(automaton_dict=automaton_dict)
+
     def __init__(self, *, automaton_dict: Optional[Dict[str, Any]] = None):
         self._locations: Set[str] = set()
         self._initial_locations: Set[str] = set()
@@ -34,7 +38,7 @@ def __init__(self, *, automaton_dict: Optional[Dict[str, Any]] = None):
         self._name = automaton_dict["name"]
         self._generate_locations(
             automaton_dict["locations"], automaton_dict["initial-locations"])
-        self._generate_variables(automaton_dict["variables"])
+        self._generate_variables(automaton_dict.get("variables", []))
         self._generate_edges(automaton_dict["edges"])
 
     def get_name(self):
@@ -86,7 +90,8 @@ def remove_empty_self_loop_edges(self):
         """Remove all self-loop edges from the automaton."""
         self._edges = [edge for edge in self._edges if not edge.is_empty_self_loop()]
 
-    def _generate_locations(self, location_list: List[Dict[str, Any]], initial_locations: List[str]):
+    def _generate_locations(self,
+                            location_list: List[Dict[str, Any]], initial_locations: List[str]):
         for location in location_list:
             self._locations.add(location["name"])
         for init_location in initial_locations:
@@ -100,7 +105,7 @@ def _generate_variables(self, variable_list: List[dict]):
             is_transient = False
             if "transient" in variable:
                 is_transient = variable["transient"]
-            var_type = JaniVariable.jani_type_from_string(variable["type"])
+            var_type = JaniVariable.python_type_from_json(variable["type"])
             self._local_variables.update({variable["name"]: JaniVariable(
                 variable["name"], var_type, init_expr, is_transient)})
 

jani_generator/src/jani_generator/jani_entries/jani_composition.py

@@ -19,6 +19,10 @@
 
 
 class JaniComposition:
+    @staticmethod
+    def from_dict(composition_dict: dict) -> "JaniComposition":
+        return JaniComposition(composition_dict=composition_dict)
+
     def __init__(self, composition_dict: Optional[Dict[str, Any]] = None):
         if composition_dict is None:
             self._elements = []