Week 3 - New BT Studio Frontend, proper code execution and more
This week I finished the new frontend, moving it to the definitive repositories and fixing some bugs in the style. Another objective was to remove all aplication dependecies that were found inside the visualization part of the RAM (Robotics Application Manager), and lastly remove the src code from the xml when executing inside the docker.
Separating the frontend into packages
I continued developing the frontend in their temporary repos until the result was what I expected, and after talking with the mentors we decided that it was time to moved them to their final destinations, inside the JdeRobots organization in GitHub.
This will reduce the amount of code in BT Studio and maybe in the future will also be the frontend for other projects such as Robotics Academy.
For now, the only issue remaining is to delete the npm packages for testing, that were uploading by my account, and upload the new ones with the organization npm account. This will take a couple of days because of the npm policies.
Fixing bugs in the frontend style
After separating all of the frontend into the 2 packages explained above, there was still some issues with the new frontend because of the change from css to styled components.
The most annoying one of the bunch was that the svg icons used had their view box dissapear. This made me change all of the icons so they had the same size 20x20px. After that was unsuccesfull, I had to put the corresponding viewbox each time an icon appeared, and that finally fixed all the issues.
Improving the tools in the Robotics Application Manager
The objective here was to replace the visualization part of the RAM that was responsible of setting up the VNC displays and extra servers, with an improved approached, that we defined as tools, that would not have to change depending on the calling application.
To detail this last part a bit more, with the old approach, if the calling app was Robotics Academy, the RAM launched the webGui server that was needed in order to comunicate with the exercise frontend in RA, and if it was BT Studio instead of the webGui server, it launched a watchdog to retransmit the state of the Behavior Tree.
So to solve this the new approach is as follows:
- Replaced the visualization step with the tools step
- Replaced the visualization type (gazebo_rae, gzsim_rae, bt_studio …) that had inside the configuration of the VNC viewers with a list of tools: console (VNC viewer), gazebo (VNC viewer), gzsim (VNC viewer), web_gui, state_monitor.
- Replaced the visualization_config_path (config file for gazebo Harmonic) with a dictionary that can handle the config for each of the tools.
Executing code from python and xml instead of only xml
This was an old temporary way of handling the applications, that now made no sense to have. What we had previously was that the xml were the behavior tree was defined also contained a tag that had all of the source code for the actions.
Now the new approach, is to leave the actions source files in the same directory, that now will be sent to the docker container, and change our utilities for generating the final tree inside the docker, called tree_factory.py, to read the files from the actions directory instead of the xml. This creates a simpler way of handling the code and also easier to understand and debug.