Skip to content
This repository has been archived by the owner on Dec 6, 2023. It is now read-only.

[BLO-91] ROS 2 [RFC]: Initialization and Shutdown of libraries and framework #30

Open
IsabelParedes opened this issue Nov 16, 2023 · 0 comments
Assignees
Labels
Improvement Created by Linear-GitHub Sync

Comments

@IsabelParedes
Copy link
Member

Context

Some frameworks and libraries need to be explicitly initialized and shutdown.

For instance, ROS 2 application typically have several phases as described in the documentation of [rclpy](https://github.com/ros2/rclpy), ROS Client for Python¹:

A typical ROS program consists of the following operations:

  • Initialization
  • Create one or more ROS nodes
  • Process node callbacks
  • Shutdown

It might also be the case for other workflow which needs explicit setup and teardown of resources (e.g. access to files, connection to database, authentication to a service, etc.)

Problem

Currently, the setup and teardown of the framework has to be defined into a Flojoy Block.

This creates two issues:

  • Firstly, defining (potentially repeatedly) the setup and the teardown of frameworks used by Block, opacifies their logic and creates maitainance cost of supplementary (duplicated) logic.
  • Secondly, it might cause inefficiency or even failure during the execution.
    • For instance, if Blocks using ROS were to define ROS client lifetime via [rclpy.init](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.init), [rclpy.shutdown](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.shutdown) or even [rclpy.spin{,\_once,\_until_future_complete}](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.spin) and were to be used in the same application, this might create alternations of connections and disconnections. This would definitely come with slowness or inefficiencies or even failures due to the [rclpy.Context](https://github.com/ros2/rclpy/blob/b4b4702ecffd923548eadac6d35f3d90d2eb6f91/rclpy/rclpy/context.py#L59-L90)'s client inconsistent state since it is a Singleton.

Proposed Solution

Get some inspiration from Python context-manager but for Flojoy:

  • have the user specify a context (or specify it for them) conditionally to the use of some framework to perform the setup when the application enters the context (in the spirit of __enter__) and when it exit it (in the spirit of __exit__)
  • encapsulate several blocks' logic (or the application's) within a (global) context which the application will enter when it starts and exist when it stops.

The user must not know that such a context exist, but we must have a way to know that they need one so that we can setup the required logic.

Design plan:

  • identify frameworks and libraries which need specific initialization and teardown (for instance ROS 2)
  • design an abstract Context which would be subclassed for each framework
  • introduce a decorator for each framework requiring a context
  • decorate relevant Blocks accordingly
  • for a Flojoy application:
    • before starting the application, register the framework's Context if at least one Block decorator for the framework is used
    • enter Contexts at the start of Flojoy application
    • exit Contexts at the end of Flojoy application

References

1: https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html

From SyncLinear.com | BLO-91

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Improvement Created by Linear-GitHub Sync
Projects
None yet
Development

No branches or pull requests

1 participant