Week 1 and 0 - Improving BT Studio Frontend
What is BT Studio?
BT Studio is an open-source web IDE for the development of robotic applications. Its allows for quick deployment of behavior tree-based robotic applications within ROS 2. In BT Studio, a robotic app is defined as an graphical tree coupled with actions scripted in Python, which the tool then translates into a ROS 2 package. This process circumvents the unnecessary complexities often associated with ROS-specific configurations, offering developers a more streamlined approach.
My GSoC Project: BT-Studio: a tool for programming robots with Behavior Trees
The primary objective of this project is to enhance BT Studio’s capabilities by upgrading the library of behavior trees and composition tools. Currently, BT Studio BT library is simple, really overcomplicated and buggy which makes reusing behaviors trees from the library difficult. This update aims to simplify and improve this tools and to increase the amount of entries in the library. Also it will improve other features of BT Studio such as the custom universes, making them fully functional and with all the features of the already existing ones inside the Robotics Backend, the docker execution enviroment for robotics applications. All of this changes would enable users to test applications across a wider range of scenarios, thereby enhancing debugging and solution robustness.
Changes to the schedule
The changes that have been done are the following:
-
During the community bonding period I started working on adding the additional infrastructure needed for the custom universes. This implied working on the RAM and in the frontend interface of BT Studio. Also during this time, as suggested by José María Cañas, I also worked in simplifying the backend API to reduce the number of duplicated lines.
-
Moved to the first 2 weeks the improvements to the UI as suggested by the mentors.
| Schedule | Changes |
|---|---|
| Community Bonding Period: May 8 - June 1 | Extend the RAM functionality for the custom universe and add it to the UI. Also simplify the backend API |
| Week 1-2: June 1 - June 15 | Improve the frontend UI and infrastructure |
| Week 3-4: June 16 - June 29 | Add the improvements to the library and test it |
| Week 5: June 30 - July 6 | Identify commonly used BTs and prepare them |
| Week 6-7: July 7 - July 20 | Code the identified BTs |
| Week 8: July 21 - July 27 | More testing of the library feature |
| Week 9: July 28 - August 3 | Implement any remaining identified features from previous weeks |
| Week 10: August 4 - August 10 | Final bug-fixing and report |
Week 1: Working on the new UI
This first week and the end of the community bonding period I focused on designing a more modular and cleaner UI using as a base the design of Overleaf.
The new design will have 3 different collapsable columns:
- The leftmost one: The file explorers for both the code and the universes
- The middle one: The editors, the text editor (Monaco) and the behaviour tree editor (as seen in image 2)
- The rightost one: The execution visualizers, for example, the behaviour tree status monitor and the VNC viewers
And also the status bar from the last UI remains almost unchanged, the only difference is the removal of the 2 VNC viewers buttons.
In addition to the new UI components, it was also needed to update the CommsManager.
CommsManager
This is a communication manager, developed in TypeScript, that handles the websocket communication with the Robotics Application Manager (RAM) inside the docker.
The RAM is designed as a Finite State Machine with a couple of states to represent the state of the application and the conexion. Before this state was not stored in the CommsManager, making handling the state in the frontend quite complicated.
To solve this, now we store this value and also the introspection data from the host (the device that launches the docker and also the docker information) as a static variable inside the CommsManager class.