During the last half of the 20th Century, and beginning of the 21st, robots have permeated into many aspects of our daily lives. Any modern product that we may consume today has been manipulated by automated machines in some kind of manufacturing process: cars, furniture, food, electronics… virtually all objects that surround us have been touched by robots. More recently, we are witnessing an increasing presence of these machines outside industry, in our domestic environments: from automated vacuum cleaners in our homes to assistive devices for impaired individuals, and very soon, delivery drones and autonomous vehicles. Robots are following a similar path to that of computers: from large and expensive machines only accessible to researchers and industry, to smaller personal versions to assist us in our daily duties. But just like it happened with desktop computers, if robots are to truly permeate into our daily lives, their programming and control should be accessible to not just the highly trained, but rather to the general user.
But first of all, what is a robot? This question is usually the subject of endless philosophical debate, ranging from simple definitions such as “a machine capable of automatically carrying out a complex series of movements, especially one which is programmable ,” to increasingly ontological queries on their nature: “a robot is a constructed system that displays both physical and mental agency, but is not alive in the biological sense .” In any case, most authors agree that a robot is essentially constituted of two parts: a physical manifestation that actuates and/or senses its environment, and a logic system that drives its behavior. And while the former, hardware design, involves a whole set of challenges on its own, the project described in this paper tries to address the challenges present in the latter: the creation of the software mechanisms to program and control robotic devices.
One of the first challenges in this field is the significant lack of universality in robot control systems. In industry, robot manufacturers usually provide highly proprietary software environments that require the use of custom programming languages, and it is fairly common for vendors to offer their own authored tools for programming and simulating their products. For example, ABB  offers their licensed RobotStudio  platform to program robot cells in the RAPID language ; KUKA  provides KUKA.Sim  to simulate programs written in Kuka Robot Language ; and Universal Robots  uses the URScript  language to drive six-axis robotic arms through URSim . Different robot brands requiring different programming languages is the first entry barrier to robotics, tying the initial learning process to the products of a particular company. However, the kinematic similarities between six-axis robotic arms, and the universal nature of spatial dynamics, make it possible to abstract many of the principles behind motion planning into higher-level interfaces, which can then be post-processed into device-specific languages. This is the core principle behind third-party robot programming environments such as RoboDK  or Visual Components . But in any case, all these tools are still closed source tools, with usage often restricted to the acquisition of expensive licenses, becoming an additional entry barrier for novice users to the field of robotics.
An additional problem with these industrial robot programming tools is that they often require significant domain expertise from the user. They are designed for engineers, integrators and implementers, and assume their users are familiar with notions such as forward and inverse kinematics, spatial transformations, robot mechanics and computer programming. The Robot Operating System (ROS)  is notorious for the depth of possibilities it allows, its modularity, openness and extensibility, but also for its complexity, steep learning curve and difficulty to set up, resulting in a reduced community of power users formed by academics and research labs. There is an abundance of highly specialized robot programming tools for highly skilled individuals, although without the proper training and time investment, robotics are hardly accessible to more general audiences.
The recent democratization of digital fabrication tools has sparked renewed interest in the field of robotics from more creative communities. The increasing availability of 3D printers, laser cutters or Computer Numeric Control (CNC) routers has given designers, architects and artists tools for rapid prototyping, and with the growth of Fab Labs  and maker culture , larger communities are becoming empowered with the production means to make almost anything . The Arduino open-source platform  stands as a great example of a system that integrates a physical sensing/actuating device with a simple and intuitive development environment, designed to introduce novice makers to electronic prototyping. Personal fabrication  projects such as RoMA  demonstrate the potential of robot integration in ad hoc design-while-making systems. Robotic fabrication in architecture has also seen a tremendous development in the last decade, with many architecture schools incorporating robotics as part of their curricula, and dedicated conferences promoting research in the field [20, 21, 22, 23]. Projects such as Flowing Matter  and the CEVISAMA pavilions  explore the promising possibilities that design to robotic fabrication workflows may open up for innovative building structures. Additionally, art projects such as Mimic  and Mimus  demonstrate the expressive potential that six-axis robotic arms have beyond their mere utilitarian implementations.
While industrial robotic arms are commonly used in these kinds of projects, they are seldom implemented or controlled via the software tools that their vendors provide. There are multiple reasons for this: in addition to the complexity and steep learning curves already discussed, these tools offer poor integration with common Computer Aided Design (CAD) and Manufacturing (CAM) environments typically used by these audiences. The recent popularity of visual programming languages for CAD like Grasshopper3D  led to a bloom of robot-oriented plug-ins, such as HAL , KukaPRC , Taco ABB  or Scorpion , which allow for the compilation of robot programs in native languages directly from the CAD environment. And while these tools offer a smoother learning curve and easier CAD to CAM workflows, they are still in many cases vendor specific and closed source, making it very hard to extend or customize for novice uses.
Moreover, industrial robots, and the environments designed to control them, are heavily biased towards the offline programming model. In this scenario, all motion planning, logic and instructions are pre-defined inside the programming environment, become post-processed into a program in the device’s native language, separately loaded to its controller and executed offline, without connection to the tool from which it was created; this is for instance the typical use case for any common 3D printing operation. Such paradigm is well suited for highly calibrated and predictable environments, where precise assumptions about their state can be done a priori. However, it is particularly inadequate for systems with elevated degrees of uncertainty, and where robot behavior is driven reactively by mutating conditions around it. This is particularly the case of robotic systems based on sensory input, environmental feedback, material properties, interactive installations, human-robot collaboration, etc. Projects willing to explore these features must often develop their own ad hoc robot control tools, usually relying on tricks and hacks, and thus requiring significant programming experience and robot control knowledge–yet another barrier to innovative robotic exploration.
From an engineering perspective, we have gotten quite good at making machines that are precise, reliable, and fast, and that allow us to make further things with them. However, for non-power users, they can be notoriously hard to use and extend . Therefore, while further research will continue to improve the hardware side of industrial robots, it could be argued that the big challenge for their mass adoption remains the software tools available to program them. For industrial robots to permeate further into non-industrial contexts, the tools used to control them should also address the qualities and needs of the new people who will use them. Training the general public in the skills of industrial robots is unrealistic, and for further progress to be made in fields such as design robotics  or personal fabrication , the next frontier of research should be the design of appropriate robotic software interfaces catered to their needs.
This paper presents Machina, a .NET library for programming and real-time control of industrial robots. It features a high-level, unitary, simple and human-relatable Application Programming Interface (API) of actions to describe spatial motion, which can then be post-processed into a program in the device’s native language. Its design follows the principles of the Enactive Robotics model , providing a more suitable cognitive model for beginners, while providing a deeper spectrum of possibilities to advanced users. Even though it can be used for classical offline programming, the main emphasis of the project is real-time communication and control of robotic devices. The library defines classes with protocols for hardware drivers, low-level communication, instruction buffering, and machine state representations, which can then be extended to the particularities of any specific machine. An additional API of asynchronous events tied to execution tracking allows for programming styles that are reactive to concurrent execution by the machine at run time. While the main focus of the library are six-axis industrial robotic arms, it can (and hopefully will) be easily extended to drive any mechanical device that can sense or be actuated in three-dimensional space, such as 3D printers, CNC machines, Arduino boards, mobile robots, drones, etc.
The target audience of this project are individuals without engineering backgrounds who want to use robots for creative projects outside industry, such as designers, artists, architects, makers and creative coders. The library is designed to be immediate and intuitive to use, foster interactivity, provide constant feedback and allow concurrency, with less emphasis on other qualities such as performance or feature-fullness. The goal of this effort is to provide an entry point for non-experts to the field of robotics, open it up to research speculation, experimentation and creative inquiry, and make robotics more accessible to wider audiences.
A simple application in C# built with Machina could look like Code Sample 1:
In this example, the sequence of actions is as follows:
The result of the execution of this program on an ABB IRB 1200 robot is illustrated in Figure 1.
Machina is designed to program machines that perform motion in three-dimensional space. It features a high-level API of instructions to describe kinematic transformations, composed of simple English verbs that denote calls to action. Its interaction model is highly influenced by the cognitive principles behind the Logo programming language  and its popular application to turtle graphics. Some of its syntactical flavor and state-based settings are influenced by the Processing programming language .
The Robot class is the main public interface with the library. It features methods such as Move, Rotate and Transform to request kinematic transformations, Speed and Precision to request changes in motion properties, or Connect and ControlMode as management methods. A program can be created by the simple concatenation of a sequence of actions, and running it will result in either the buffered execution of those actions on the connected device, or the offline compilation of that same program into the device’s native language.
Where applicable, most of the API methods have two syntactical flavors: the function name with the To suffix, and the plain version. This denotes the difference between absolute and relative action requests respectively. Relative actions build on top of the current state of the robot, while absolute actions set those values independently of former states. For example, a MoveTo(400, 300, 500) call will set the position of the robot’s Tool Center Point (TCP) to XYZ (400, 300, 500) mm, regardless of its previous position. If followed by a relative Move(0, 0, 250) call, the resulting absolute position of the robot would be (400, 300, 750). This applies to TCP location, orientation, and robot axes values, but also to internal robot motion properties such as speed, acceleration, precision, analog out values, etc.
|Move/To||Change the position of the TCP maintaining its orientation.||ActionTranslation|
|Rotate/To||Change the orientation of the TCP maintaining it position.||ActionRotation|
|Transform/To||Change the position and orientation of the TCP.||ActionTransformation|
|Axes/To||Change the rotational values of the robot’s axes.||ActionAxes|
|ExternalAxis/To||Change the values of one the external axis attached to the robot.||ActionExternalAxis|
|Wait||Halt program execution for an amount of time.||ActionWait|
|DefineTool||Define Tool properties on the robot.||ActionDefineTool|
|Attach||Attach a Tool to the robot’s flange.||ActionAttach|
|Detach||Detach all tools from the robot.||ActionDetach|
|WriteDigital||Writes a value to a digital out.||ActionIODigital|
|WriteAnalog||Writes a value to an analog out.||ActionIOAnalog|
|Extrude||Turns extrusion on/off in 3D printers.||ActionExtrude|
|Message||Display a message on the device’s screen.||ActionMessage|
|Comment||Insert a custom comment on a compiled program.||ActionComment|
|CustomCode||Insert a custom line of code on a compiled program.||ActionCustomCode|
|Do||Applies an Action object to the Robot.||N/A|
|MotionMode||Set the motion type for future motion Actions, like linear or joint.||ActionMotion|
|Speed/To||Change the TCP speed value new Actions will be executed at.||ActionSpeed|
|Acceleration/To||Change the TCP acceleration value new Actions will be executed at.||ActionAcceleration|
|Precision/To||Change the TCP smoothing radius value new Actions will be executed at.||ActionPrecision|
|Temperature/To||Change the working temperature of one of the device’s parts.||ActionTemperature|
|ExtrusionRate/To||Change the extrusion rate of filament for 3D printers.||ActionExtrusionRate|
|PushSettings||Buffers current state settings.||ActionPushPop|
|PopSettings||Reverts the settings to the previous state buffered by PushSettings.||ActionPushPop|
|Robot.Create||Create a new instance of a Robot object.||N/A|
|ControlMode||Sets the control type the robot will operate under, like offline or online.||N/A|
|ConnectionManager||Defines who is responsible for setting up the controller for connection, Machina or the user.||N/A|
|Connect||Connects to a remote controller.||N/A|
|Compile||Create a program in the device’s native language with all the buffered Actions.||N/A|
The internal programming and control model of Machina is based on the atomic form of Action objects. Actions are the basic units of interaction with the machine, and follow the principles of the Enactive Robotics model for concurrent machine control . An Action is defined as a change in some of the properties that define the state of a robot. For example, this can mean to perform some kind of spatial motion (Move, Rotate), change the execution properties of forthcoming actions (Speed, MotionMode), hold execution for a certain amount of time (Wait), change the IO values (WriteDigital, WriteAnalog), etc.
Tables 1 and 2 denote a loose correlation between Robot methods and Action types. This is not coincidental, as most API calls are basically thin wrappers that create an Action object internally and issue a request to the core Control class to execute that action Figure 2. This pattern presents a clear mental model to the user, who can easily relate the statement arm.Move(0, 0, 250) to the meaning “ask the robot to move up 250 mm,” and doesn’t need to care about the internal representation of such actions. It also helps maintain the modularity of the library and simplifies the extension of its functionality.
Actions are platform-agnostic. They are objects which store values for the state properties they are meant to modify, but do not need information on their target machine in order to exist–even if they are created through the Robot class. This means that programs are created internally as lists of Action objects, but that these actions have no real meaning until they are applied to a particular device. Depending on its nature, such a device may or may not be able to accommodate those changes; it is the responsibility of the developer who extends the library for a new machine type to decide which actions have effects on it and what their effects are. This means that calling the bot.ExtrusionRateTo(100) method on a non 3D printer is a valid operation, but will have no effect on the machine when executed online or compiled offline, beyond a warning message. This allows to maintain the cross-compatibility of the same API between different types of robots. However, it is important to note that the philosophy of the library is to provide a high-level programming language as constant in behavior as possible across different machine types. While developers are welcome to contribute to the project with extensions for new machine types, only those who maintain the library’s consistency will be accepted to the main project.
Machina can be extended with new actions by inheriting from the main Action class, and adding corresponding methods to the Robot class. Child actions must implement the ToString() method with a human-readable representation of the effect of the action; this helps the user understand the abstractions behind them. Child actions must also implement the ToInstruction() method to return a string mirroring the necessary API call to create such Action. This is extremely useful as a form of serialization, and provides a way to marshal actions when transferring programs between different implementations of the Machina framework, either through different programming languages or communication protocols. Code Samples 2 and 3 show examples of this behavior for the action in our Hello Robot program (Code Sample 1).
Machina can be used for offline programming. In this scenario, the library works by buffering all actions into a program, which can then be compiled into the device’s native language, manually loaded and ran on it. This is very similar to the typical way Arduino boards are programmed .
Code Sample 4 shows the Hello Robot example rewritten to work in offline mode. In this case, program contains a string representation of the Machina actions post-processed into ABB’s native RAPID language (Code Sample 5). The same program, compiled in Universal Robots’ URScript language is shown on Code Sample 6.
Note how, by default, Machina inserts comments throughout the program with human-readable descriptions of the code. This helps novice users understand the correlation between native instructions and the original Machina actions, facilitating debugging and serving as an entry point to native robot programming. This behavior can be customized through the overloads in Compile().
When working in online mode, Machina is intended to be used in control applications running on a host on the same network as the controlled device. In this scenario, the device’s controller must be running an instance of a custom Machina driver module written in the device’s language. Depending on the device, the driver may automatically be deployed by the application, or should be manually set up by the user. The driver module allows the Machina application to exchange information with the device via whichever communication protocol the device accepts. Following the Arduino analogy, this would be akin to interfacing with the board via the Firmata protocol .
Figure 3 describes a high-level representation of a sample communication scheme between a Machina host application and the driver. In this example:
In the example, communication with ABB devices works by running a driver module that creates a TCP server on the device, accepting incoming socket connections. On successful connection, the client receives string state messages in the format >21 X Y Z QW QX QY QZ; and >22 J1 J2 J3 J4 J5 J6; with the values for the current Cartesian and joint poses respectively. A request to transform linearly to a Cartesian pose can be sent as @ID 1 X Y Z QW QX QY QZ;, and upon completion of this request, the driver will send an acknowledgment message @ID 1; including the id value of the completed action. If capable of, the driver may also send state messages periodically, to keep the client updated on the motion state of the device.
However, Machina doesn’t impose a particular specification on how drivers for new robots should be implemented. Due to the lack of universality in firmware applications, and the variability of technologies available on back-end interfaces, different devices may require different communication protocols, connection schemes, and/or message formatting. Developers willing to extend Machina for new machines are welcome to choose how to develop their own driver modules, and which technology stack to implement in order to interface with them. The only requirement is to maintain the updating logic of the robot cursors that represent the asynchronous state of the system (see State Model section).
When using software applications to control hardware devices, there is a tremendous mismatch between the execution time frames of both parties: a large program may execute in a handful of milliseconds on the digital side, but may require several minutes, if not hours, to complete on its analog counterpart. For this reason, there is an inherent challenge in coordinating the elements of a system whose parts work at such different time scales.
Machina approaches this problem by implementing a system of layered machine state representations named cursors. A Cursor is a virtual representation of the state of the robot, defined as the values of all possible properties a particular device may exhibit at a certain stage of the robot’s execution timeline. These may include position, orientation, IO values, temperature, etc., properties which are particular to the device’s capabilities. A simple extension of the Cursor object for a six-axis robotic arm could implement properties such as Position vector, an Orientation quaternion or an array of angular values for the Axes, whereas a cursor representing a conventional 3D printer may implement Position and Temperature, but not require Orientation.
Since Actions are platform-agnostic, their effect depends on the state of the device at the time of execution. An Action is said to be applied to a Cursor when the cursor representing that state changes its properties based on the nature of the Action. An example of this would be the Position of the cursor changing from (400, 300, 500) to (400, 300, 750) after a Move(0, 0, 250) action has been applied to it. This model is particularly helpful when controlling machines that do not natively accept motion instructions in relative form, since the absolute values for low-level instructions are always available application-side through the Cursor representation of the robot. It is also useful when switching between actions defined in Cartesian and joint coordinates, as the state can be maintained in parallel on both spaces, with translations between them updated through forward and inverse kinematic equations.
The asynchronous differences between the host application run time and the robot operation timeline are tracked through a set of cursors representing the different stages of program execution. To better understand this architecture, it will be useful to break down the different stages in the execution cycle of an Action Figure 4:
Figure 5 is an example diagram of the different cursor representations of the execution timeline in our initial Hello Robot program. Assuming that the initial position of the robot is (400, 200, 500), and that Machina is set to stream to the controller in blocks of six actions, this would be the state of the cursors after three seconds of execution:
Machina tries to foster programming styles that are reactive to, rather than prescriptive about, the robot execution state, with interactivity, system input and on-the-fly decision making being at the forefront of real-time robotic applications.
The library exposes a collection of Events linked to changes in the Cursors. These notify the subscribers of the nature of the changes and other useful information. ActionIssued, ActionReleased and ActionExecuted are raised throughout the different stages of the action execution cycle (see State Model), while MotionUpdate is raised anytime real-time information on the state of the robot is received from the controller.
Code Sample 7 shows a small program that starts by issuing motion in a horizontal square 50 × 50 mm loop. Whenever the robot has finished executing an action, ActionExecuted is raised. If no actions are pending to be executed, then a new loop is issued, hence creating an infinite loop that can only be interrupted by user input.
Machina is designed as an introductory platform to real-time robotics for non-experts; in a way, it is like the 21st century Logo turtle of industrial robots. As such, many of the design decisions made during its development were oriented towards fostering simplicity, intuitiveness, safety and getting applications working right away with minimal setup.
The complete .NET library, as well as other related projects, is fully open source . The aim of this is to open up the field of robotics to curious individuals and power users, either for educational, participation or customization purposes. Furthermore, special consideration is given to thoroughly commenting the source code, to facilitate usage and extensibility of the library.
Additionally, the library has no significant dependencies. It features a full set of custom geometry and robot-related data types, and only references members from the .NET framework. Currently, the only exception is a dependency on the Robot Communication Runtime by ABB Robotics , used to interface with ABB controllers and automatically run driver modules in the controller. This dependency is scheduled for deprecation in the nearby future.
Machina.NET is the core library of the Robot Ex Machina project , an ecosystem of libraries and applications designed around the same core Enactive Robotics principles , and designed to provide access to real-time robot programming and control from a variety of different platforms. The name is a made-up pseudo Latin expression meaning robot from the machine, and it evokes this project’s spirit of infusing agency and responsiveness into otherwise passive machines.
The Machina project is currently under active development, and significant efforts are being made to improve its functionality across wider range of devices, and make it safer and more robust to use. In particular, current development is focusing mainly on the following aspects:
It is very important to note that industrial robots can pose a serious safety threat to humans working around them. Robotic actuators are very powerful machines but, for the most part, extremely unaware of their environment; they may not be aware when hitting an object, and continue execution uninterrupted with fatal consequences. Therefore, special attention must be given to the safety of the humans working or interacting with robots, especially if the audience of this project is users who are new to robotics.
In particular, individuals working with real-time robot control should pay special attention to the following measures:
These guidelines are offered as recommendations, but ultimately, users should follow the protocols in place by their robot/shop managers.
Machina.NET is under active development, and while it will yield warning and error messages on ill-defined actions, due to the current limitations it may not prevent users from executing them. The software is provided “as is,” without warranty of any kind, and the author/s should not be liable for any claim or damage arising from its use.
Machina has been tested mainly by groups of architecture students and computational design researchers in academic environments. Many of these testers include residents at the Autodesk’s BUILD Space in Boston, and participants at teaching-oriented events co-led by the author, such as:
User observation, feedback, bug reports and feature requests have been crucial in the development of the library and the current level of stability.
The project incorporates a full set of unit tests developed in Visual Studio’s UnitTestFramework. These tests focus mainly on validity checks for the Geometry data types, especially for the conversions between them.
Machina has been tested on Windows 7, 8.1 and 10.
C# and the .NET framework v4.6.1.
As of current version, Machina is compatible with the following devices:
|Zmorph 3D Printer||Yes||No|
For online mode, a host computer running a Machina-powered application should be able to establish successful connection with a physical device running a driver module. Simulation tools such as RobotStudio  can be used to test Machina with virtual devices.
See “Other Features”.
Machina was created and is maintained by Jose Luis García del Castillo y López.
Machina can be used by makers, designers, artists and engineers to create applications that maximize the potential of controlling robots in real-time. Early implementations show the potential of incorporating live feedback in classical one-directional processes, such as 3D printing. The Spatial Print Trajectory project [45, 46] used Machina to stream the print toolpaths of a spatial lattice of 3D printed clay, drive a distance sensor attached to the end effector to measure local deformations on the fresh mixture, and generate the toolpath of the next layer compensating for them. Similar ideas could be implemented for human-robot collaboration in construction, personal fabrication projects, interactive art installations, etc. The author believes that this novel paradigm will open new avenues of research and creative exploration for any individual trying to make things with robots.
Machina is designed for extensibility. The action model ensures that programs can be created in a platform-agnostic way and, by extending the classes that carry device-specific functionality, applied to new robot types beyond the ones available in the library. Documentation on how to do this is maintained in the main repository’s wiki, as well as basic use manuals and walkthroughs. Bugs and feature requests can be reported through the repository’s issue tracker.
I would like to thank Autodesk Inc., the Generative Design Group, the BUILD Space, and in special to Matt Jezyk for his continuous support of this project.
Special gratitude also goes to all the early adopters of Machina whose valuable feedback, input, and very often patience, made this project worthy of sharing with the rest of the world. A special mention to Nono Martínez Alonso for being part of this journey since its very early days.
My acknowledgements to Jonathan Grinham, Saurabh Mhatre, Scott Mitchell and Nate Peters for their time and suggestions at the early stages of this paper.
The author has no competing interests to declare.
Richards, N M and Smart, W D 2013 How should the law think about robots? DOI: https://doi.org/10.2139/ssrn.2263363
Baudisch, P and Mueller, S 2017 Personal fabrication. Foundations and Trends in Human–Computer Interaction, 10(3–4): 165–293. DOI: https://doi.org/10.1561/1100000055
Peng, H, Briggs, J, Wang, C Y, Guo, K, Kider, J, Mueller, S, Baudisch, P and Guimbretière, F 2018 April RoMA: Interactive Fabrication with Augmented Reality and a Robotic 3D Printer. In Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems (p. 579). ACM.
Brell-Cokcan, S and Braumann, J (eds.) 2013 Rob|Arch 2012: Robotic Fabrication in Architecture, Art and Design. Springer. DOI: https://doi.org/10.1007/978-3-7091-1465-0
Reinhardt, D, Saunders, R and Burry, J (eds.) 2016 Robotic Fabrication in Architecture, Art and Design 2016. Springer. DOI: https://doi.org/10.1007/978-3-319-26378-6
Willman, J, Block, P, Hutter, M, Byrne, K and Schork, T (eds.) 2018 Robotic Fabrication in Architecture, Art and Design 2018. Springer. DOI: https://doi.org/10.1007/978-3-319-92294-2
Andreani, S, Garcia del Castillo y López, J L, Jyoti, A, King, N and Bechthold, M 2012 Flowing matter: Robotic fabrication of complex ceramic systems. In ISARC. Proceedings of the International Symposium on Automation and Robotics in Construction (Vol. 29, p. 1). Vilnius Gediminas Technical University, Department of Construction Economics & Property.
Seibold, Z, Hinz, K, García del Castillo y López, J L, Martínez Alonso, N and Bechthold, M 2018 Ceramic Morphologies, Precision and Control in Paste-Based Additive Manufacturing. In Proceedings of the 38th Annual Conference of the Association for Computer-Aided Design in Architecture (ACADIA). Universidad Iberoamericana.
Schwartz, T 2013 HAL. In Rob|Arch 2012 (pp. 92–101). Vienna: Springer. DOI: https://doi.org/10.1007/978-3-7091-1465-0_8
Braumann, J and Brell-Cokcan, S 2011 “Parametric Robot Control, Integrated CAD/CAM for Architectural Design.” In Proceedings of the 31th Annual Conference of the Association for Computer Aided Design in Architecture. 242–51.
Elashry, K and Glynn, R 2014 An Approach To Automated Construction Using Adaptive Programing. In Robotic Fabrication in Architecture, Art and Design 2014 (pp. 51–66). Cham: Springer. DOI: https://doi.org/10.1007/978-3-319-04663-1_4
Bechthold, M 2010 The return of the future: a second go at robotic construction. Architectural Design, 80(4): 116–121. DOI: https://doi.org/10.1002/ad.1115
Landay, J A 2009 Technical perspective Design tools for the rest of us. Communications of the ACM, 52(12): 80–80. DOI: https://doi.org/10.1145/1610252.1610274
Wijnen, B, Anzalone, G C, Haselhuhn, A S, Sanders, P G and Pearce, J M 2016 Free and open-source control software for 3-D motion and processing. Journal of Open Research Software, 4(1). DOI: https://doi.org/10.5334/jors.78
https://robotstudio.azureedge.net/install/RobotWare_Tools_And_Utilities_6.07.01.zip. Accessed 23 August 2018.
https://www.gsd.harvard.edu/course/material-systems-digital-design-and-fabrication-fall-2017/. Accessed 23 August 2018.
https://www.smartgeometry.org/mind-ex-machina/. Accessed 23 August 2018.
http://www.robarch2018.org/tight-squeeze-automated-assembly-spatial-structures-constrained-sites/. Accessed 23 August 2018.
http://2018.acadia.org/workshops.html. Accessed 23 August 2018.
AlOthman, S, Im, H C, Jung, F and Bechthold, M 2018 Spatial Print Trajectory: Controlling Material Behavior with Print Speed, Feed Rate, and Complex Print Path. In Robotic Fabrication in Architecture, Art and Design (Rob|Arch). Springer. DOI: https://doi.org/10.1007/978-3-319-92294-2_13
Im, H C, AlOthman, S and García del Castillo y López, J L 2018 Responsive Spatial Print: Clay 3D Printing of Spatial Lattices Using Real-Time Model Recalibration. In Proceedings of the 38th Annual Conference of the Association for Computer-Aided Design in Architecture (ACADIA). Universidad Iberoamericana.
https://github.com/RobotExMachina. Accessed 23 August 2018.
Garcia del Castillo y López, J L 2019 Enactive Robotics: An Action-State Model for Concurrent Machine Control (D.Des. Dissertation, Harvard University). http://nrs.harvard.edu/urn-3:HUL.InstRepos:41021631.
García del Castillo y López, J L 2019 Robot Ex Machina: A Framework for Real-Time Robot Programming and Control. In Ubiquity and Autonomy, Proceedings of the 39th Annual Conference of the Association for Computer-Aided Design in Architecture (ACADIA). University of Texas.