08 Nov

#### Ensuring Stability in Roco's Electrical/Code Interface

Last week, I identified that the source of many problems for the composite component interface was the manual serilization of the Blockly workspace. In an effor to rectify this, I spent this week designing and implementing a JSON framework to handle the serialization and deserialization for us.

An outline of the framwork is given below:

out {
name: "supercomponent_name"
blocks: [
name: "subcomponent_name",
inputs: [
{
inherited: false,
name: "input_name",
source_name: "output_name",
source_comp: "output_component_name"
},
{
inherited: true,
name: "input_name",
source_name: "chosen_name",
source_comp: "subcomponent_name"
}
]
]
output: [
{
name: "output_name",
source_name: "source_output_name",
source_comp: "source_comp_name"
}
]
}

In order to create a builder file, the composite component interface needs to keep track of a few key things: the subcomponents used, the connections between each of the subcomponents, the interfaces the component will inherit from the subcomponent, and all of their names. Once this information is compiled, it is placed into a JSON file following the framework given above, and sent to the back end, where a builder file is created and the component is added to the library. A successfully created builder file for Jack's Andruino project built using RoCo is shown below: The above builder file is functionally identical to the one Jack wrote by hand.

Having stabilized the composite component interface in RoCo, I believe the Electrical and Code sides have all the required functionality to build the car. In order to actually build it though, various electrical components such as servo motors and LED's need to be migrated from the old library to the new one. My work in the upcoming week will focus on this.