Week 5 - New approach
Summary
In the previous week, I achieved a ROS 2 package with full port and decorator support. This package is called py_gardener and allows for tree creation in almost the same way as BT.cpp.
Development
A new approach
Currently, the package can only be used within a ROS 2 workspace. This is useful as it is, but since the main objective of my TFG is to create a Web Frontend for tree creation using the RADI of Robotics Academy, the generation of trees should be ROS-agnostic.
To achieve this, I have begun restructuring the package so the parser is independent from ROS 2 execution. The ultimate goal of the package is to generate a self-contained ROS 2 package that can be executed at a later time.”
Of course, py_gardener will be stored for later publishing.
A new python module
I spent a great part of this learning how to create an independent python package using Hatch, a dependency manager.
I try diferent modules configurations: initially, all the functionality (parser, translator and tools) were encapsulated into a new python package, tree_gardener.
New organization
However, I soon realized, as explained above, that the separation which made more sense was:
However, as I soon realized and explained above, the separation that made the most sense is as follows:
-
ROS Execution Dependencies: These include the tree_factory and the tree_tools, which provide the tools necessary for using trees within ROS.
-
ROS Package Generation: This comprises the tree_generator, which prepares a self-contained tree with all the user actions, and the app_generator, which creates a fully usable ROS 2 package.
This structure aligns better with the usage steps: first comes creation, and then comes execution. first creation and then execution.