For the past two quarters, the Robot Compiler (roco) team has been working on improving the roco codebase, cleaning up and documenting the code. As mentioned in my previous blog post, we set out with the goal of creating a codebase that was more easily understandable, extensible, and usable. Now, as the school year comes to a close we look at how well we were able to accomplish those goals.
Improvements
The roco team recently finished the clean up and move of the python library code, which can be viewed on the UCLA lemur git. The code is now well documented, allowing new users to learn about the functionality of the various roco modules much quicker than before. Also, the roco repository now has support for the creation of Sphinx style documentation pages, which will hopefully be hosted on the website soon, and will allow for quick lookup and browsing of the documentation. In addition to being documented, the code is also much cleaner now. Once two separate libraries, the code for creating mechanical, electrical, and code components now exists all within this single repository, with a much more clearly defined class structure. Large parts of the code were also rewritten or removed to created more streamlined and less redundant code. For example, the function to convert mechanical structures into 2D printable drawings was completely rewritten. Code was rearranged to provide a more logical flow, redundant or deprecated snippets we're removed, ambiguous variable names were changed to reflect there actual uses, and comments were added to explain more complicated operations. Changes like this throughout the code make it much more accessible to new users. Given the already big changes happening with the code, the roco team also took this chance to rethink so of the API functionality for the library, in order to make the interface more useful and intuitive. This involved first ensuring that the naming and behavior of similar functions was consistent across classes, and generally making sure that the functionality of the code matched the users expectations and needs. Serveral other more specific changes were made to extend the functionality of the API in ways we thought would be helpful. We added the ability to name constraints, providing the users with a way to remove previously added constraints. We created a new variable class to serve as the underlying representation for parameters, adding and removing behavior to better suit our needs.
Setbacks
As with any large project, there was plenty of setbacks along the way. The biggest challenge throughout this process was likely managing the sheer size of the code base. With thousands of lines of code to go through, documentation and code cleanup did not always go as fast as we would have hoped. Also, with the incredible amount of functionality present in the library, testing all those features proved to be a challenge. We did begin to develop automatic test scripts, however many of roco's functions produce qualitative or behind the scenes output, making them hard to test. Because of this, many bugs we're discovered along the way.
Looking Ahead
While the code migration is nearing the end, the true test of it's effectiveness will occur in the coming months. We started out on this endeavor with the motivation to make roco more accessible to new users, so that anyone could use, improve, and add to the project. As various members of our lab have started or plan to start on new exciting projects involving roco (such as an Android phone powered robot made in our web application, and wooden furniture automatically designed using roco), we will be able to get feedback on how well our changes have manged to improve roco.
-Christian