Integrated Codesign of Printable Robots

ion can allow an expert designer to implement a PCB composable to enable more complex electrical devices and circuits, at the expense of in-home fabricability for a casual user. 5.2.1 Information Flow. As in the mechanical layout, the sources and sinks of electrical information can reveal the underlying structure of the design. In the case of electrical signals, units such as sensors or communication modules can source electrical information, and devices such as servos or light-emitting diodes (LEDs) can sink electrical information. Note that the overall information flow does not necessarily start or stop at these devices, but the electrical information does—for example, a communication module may take in a conceptual value and convert it to electrical information, and the servo takes in electrical information and converts it to mechanical information. These devices may therefore serve as electrical sources while being sinks for other types of information, and vice versa. By only considering the electrical sources and sinks though, the electrical subdesign can be made apparent. Less informative ports such as power connections, and details such as particular pins used, are abstracted away from the user during the design process. At fabrication time, the system automatically creates power connections, chooses particular pins and pin types, and inserts devices such as microcontrollers or power converters if necessary so that only the informational flow needs to be considered during design. 5.2.2 Electrical Hardware Modules. The modularity and scalability of the electrical system are enhanced by plug-and-play hardware modules that serve as interfaces between electrical devices and the main controller. Each module uses an ATtiny85 microcontroller to drive three general ports, as shown in Fig. 5, which can be independently configured as digital outputs, PWM outputs, digital inputs, or analog inputs. Since these modules are designed to be plug-and-play, however, the code loaded on the modules does not change according to the robot design; on startup, the main controller sends the modules any necessary design-specific data such as what pin types to use. Communication is established between a module and the main controller via a one-wire serial protocol, and messages are then exchanged such that devices can be attached to the modules as if they were being attached to the main controller. Modules can also be chained together, in which case messages are passed along the chain until they reach the desired module. In this way, the number of possible devices is no longer limited by the number of pins on the main controller. This configuration also facilitates the physical distribution of devices across the robot while reducing the wiring complexity, thus allowing the electrical layout to more naturally mirror the mechanical layout. The flexible nature of the hardware modules can also be leveraged during automatic design, since the system can insert them where needed in order to join various devices together. 5.3 Software System. In general, electrical systems on a robot are controlled by processors such as microcontrollers, and thus the design of an electrical subsystem must directly interact with the design of a software subsystem. This subsystem includes driver firmware for controlling devices, higher level microcontroller code, UI generation, and the ability to automatically generate code for robot behaviors. Within this abstract subsystem, components may pass information such as a desired servo angle or a UI slider position as conceptual data values. Components contain software snippets written by experts which represent the code needed for the block to perform its required function and can contain code tags that reference design-specific information. At fabrication time, the data network can be analyzed and all of the software snippets can be pooled together to generate software which reflects the designed data flow. The collection of provided components allows users to design at an abstraction level with which they are comfortable; expert users can use low-level code directly, intermediate users can use automatically generated code libraries to aid the writing of custom code, and novice users can intuitively link ports to specify behaviors and generate a graphical UI. 5.3.1 Hardware Drivers. At the lowest level, code must be generated which allows the main controllers to directly interact with the electrical devices. Toward this end, components called drivers perform conversions between software, abstract data, and electrical signals; for example, a servo driver accepts as input a conceptual data value such as an angle, and outputs a software snippet representing the knowledge of how to realize that value as an electrical signal. This output can also adapt to the design topology through the use of parameters. Drivers are therefore sources for the software subsystem and sinks for abstract data—they serve as indirect interfaces between the conceptual software realm and the physical electrical realm. Such examples illustrate that the designed subsystems are not isolated from each other, but rather interact both through the types of information they process as well as through design parameters that affect how the information processing takes place. 5.3.2 UI Elements. While hardware drivers are necessary abstraction barriers between the software and electrical realms, they are often included at a low level of the design hierarchy and not made transparent to the novice user. Other data sources such as UI elements, however, can be intuitively included in higher level designs and allow for humans to become information sources. In this case, elements can represent UI elements such as joysticks, buttons, switches, or sliders. These then generate conceptual data values that can be processed by other software blocks and ultimately control actuators or otherwise affect the robot’s behavior. In this way, the UI can be designed in parallel with the robot itself, such that the design process for the robot subsystems can interact with the design process for its human interface. 5.3.3 Data Manipulation. Although drivers and UI elements serve as conceptual sources by translating data or human interaction into software and thereby allow for the direct control of various devices, a robot should also be able to perform some autonomous behavior. An intuitive way to design such behavior is to link data sources and sinks together—for example, linking a light sensor output to a servo angle input through some simple function can create a line-following robot. To facilitate such information flow, various library components can manipulate data within the conceptual realm. For example, such a block may take in data from a sensor and scale it to a value that is meaningful to a servo driver. By serving as an interface between sensors and actuators, this conversion enables autonomous behavior to be Fig. 5 Each electrical module features connections for an upstream and downstream module as well as three ports for connecting devices such as servos, LEDs, or digital and analog sensors. These modules are designed to be plug-and-play and do not require reprogramming based upon location or connected devices. 021015-6 / Vol. 7, MAY 2015 Transactions of the ASME Downloaded From: http://mechanismsrobotics.asmedigitalcollection.asme.org/ on 04/30/2015 Terms of Use: http://asme.org/terms easily described in the design environment. Similarly, data may be converted from a human-readable version to a machinereadable version, facilitating human interaction with the final design. Thus, the flow of conceptual data within the design largely describes the resulting behavior of the robot. 5.3.4 Programming Blocks. While the data manipulation components allow for the direct linking of devices throughout the design and the seamless integration of the conceptual and physical realms of the design, more advanced users may want to specify robot behaviors in a more arbitrary manner. Library components are therefore provided which allow for graphically writing arbitrary code. These blocks include if/else statements, loops, and the declaration and definition of variables or methods. Using these blocks, arbitrary code can be created to specify robot behavior. Such blocks also include data ports which allow the software to directly utilize the information flow of the design; for example, the block to set a variable may be connected to the output of a sensor. Details of how the data signals are converted into software (such as how the sensor is read) can be encapsulated lower in the hierarchy and thus abstracted away from the user. 5.3.5 Software Sinks. The various elements described above translate conceptual data into software to realize the abstract flow of data defined by the design. Ultimately, these software outputs must be processed and pooled together into a coherent library for a particular device. Toward this end, a microcontroller such as an ARDUINO may be a sink for the drivers’ software, or an Android device may be a sink for the UI software. The software snippets written by experts and included in the components can include various code tags that are processed once the design is complete. These may include pin numbers, device indices, counts of other devices in the design, device types, or other design parameters. These allow experts to write code snippets that are flexible and dependent upon the final design topology. In addition, they may write multiple code snippets and provide rules for choosing between them based upon design parameters—this allows the software sources to adjust their generated software according to the type of sink to which they are ultimately connected. Once the flow of software is well defined, the sinks can pool the code from all of the connected inputs into usable code. This includes processing the aforementioned code tags so that the code r