Previously, the electrical and code interface was implemented in Blocky. On the implementation side, the whole process was such that users will drag together blocks in the Blockly interface but no API are called. In the end, the output is a builderFile that can be run to create the RoCo component that user constructed in the UI. While this design works, it has shortcomings, such as not being able to get immediate feed back for entering an invalid constraint from RoCo backend.

For the electroprogrammatic interface (yeah, that's its new name!) in Blender RoCo, we plan to adopt the design that every operation that user does in the UI is mapped to a RoCo API call (e.g. addNode --> addSubcomponent, changeNodeSetting --> constrainParameter). However in order to do that, we have to make some changes to the existing implementations and the way code is generated.


  • We want the interface to be so that users specify what the system should do (declaratively). (e.g. motor control: user specifies a motor and wants it to run at 50% every half second, we would generate a setInterval-like code to do that) but also have code blocks for how these blocks will interact logically (imperatively). (e.g. if statement evaluating serial-in string with a string that user is looking for)
  • Evaluation of the RoCo Component should be purely functional, no states! (for hierarchical composition)
  • Electrical designs are generated implicitly given the specification of the user.


  • Change/add code components and maybe change how code is generated (might use existing code generation for the end-of-quarter project).
  • Generation of electrical designs implicitly

Lookahead: We plan to make a demo for the end of this quarter (something that resembles Google's paper signal).

Next Post Previous Post