8 Future Work
Each chapter contains notes on future work that relate directly to those topics, in systems 2.9, motion 4.9, 3D printing 5.12, and machining 6.5. The topics below relate across components.
8.1 Developing A Spec for Machine Digital Twins
One of the ideas that developed as I was working on these controllers is that of interfacing the (already software-based) controller to a “digital twin” of the whole machine. I think the most productive version of this idea is to use the digital twin as an interface between the machine designers’ understanding of their hardware’s kinematics and the controller.
For example, we can take for granted that a machine designer will have a mostly complete CAD model of their output. Those CAD models are normally assembled using constraints that generate mechanisms: linear slides, rotary joints, etc. — everything we need for a rigid body simulation. A hope had been that we could develop a representation of these assemblies that could be exported from a CAD tool and plugged directly into the planner: it could then run and visualize the machine virtually to ensure that the designer’s idea of how the machine was going to move matched to reality. Data from motors could be used to verify and improve these alignments in all the ways I’ve discussed previously. This representation could be as simple as a set of .stl or .step of the rigid bodies, and some .xml or .json outlining their relations to one another (joint types, etc.), as well as linkages to actuators.
The goal of this tool would be to enable machine designers to quickly bring their machines to life, using a representation and interface (their CAD model) that they are already familiar with. Some such projects exist [1]. Done well, the tool could also help machine designers learn about their designs’ performance before they build it, e.g. that a motor should be made more or less powerful, or a transmission element made stiffer, or that their mechanism could be improved to increase the machine’s range of motion, etc.
8.1.1 Discovering Kinematics
There is a lot that I didn’t get to on the topic of motion control. Probably the most frustrating of which is the task of more generally fitting kinematic models from motion data, which could be done separately or alongside the digital twin specification I just described. The idea here would be that we could develop well known motor models, attach those to new machines, and automatically discover how they are configured vis-à-vis the machine’s transmission elements and mechanisms. This would be invaluable to machine builders because working out kinematic models is cumbersome first in getting configurations correct (motor offsets, transmission ratios), and then for refining those models: machines never go together exactly the way they are planned (no two lines are completely parallel, etc.), and to achieve real precision we often need to fit kinematic models to data. For example the simple task of figuring out a machine’s exact working volume is normally done with simple trial and error.
In some proposed schemes, we could develop a library of possible kinematic arrangements, attach an accelerometer to the end effector (as I have done here to work out resonances), and learn how each actuator’s acceleration corresponds to end effector motion. Backing out linear transforms is presumably as easy as filling in the matrix that relates one system to the other, but nonlinear transforms would also require that we guess the composition of the transform function and its inverse. Imprecise models like neural networks might get close in this regard, but are probably too much of a black-box to be truly suitable to the task: in machine design and control, it is invaluable to have precise definitions of our core systems. New approaches are emerging that use regression to find sparse representations for nonlinear systems [2], those may be the right vein of techniques to start with.
Adding computer vision to learn kinematic models more concretely is another proposal (or hybrids of each), and my colleague Quentin Bolsée is working on this currently at the CBA. There are a litany of other data collection approaches for this task: probing known geometries (like the method outlined for bed leveling in this work) is a common one, and could be extended to correct for XY kinematics as well as in Z (as is in fact common on some 3D printers).
8.2 End-to-End Fitting of Models
Although building models piecewise is a valuable capability during systems assembly, once machines are together it can be more productive to fit models in a more-end-to-end manner.
For example, in Section 4.3, I estimate parameters for motor models and frictions separately, and measure inertias by hand. It would be ideal if we could update estimate more of these parameters without disassembling the hardware, e.g. fitting motor model parameters, kinematic parameters, and friction parameters all from the same datasets, using limited prior information. This also would be important for retrofitting unknown equipment and for improving models over time using data generated during normal operation.
For a simple example, the motor encoder calibration from Section 4.4 is sometimes imperfect and results small oscillations that are visible under certain conditions in time-series data. Fixing these calibrations manually would require disassembling machines to decouple the rotor. But those oscillations show up exactly at the frequency of the motor’s rotor, so we should be able to isolate those errors and correct them using “generic” machine data, i.e. the type that it produces during everyday operation. But in other cases the isolation is not as simple; for example when a motor rotor is connected only to one other mass it is difficult to ascertain from motion data alone if the overall inertia is attached to the rotor shaft or to the linear axis that it drives; we need a spare state to differentiate the two.
However, model components often lie in the same axes of our systems’ state space. For example a friction term applied to the motor rotor and a friction term applied to the sliding axis of one of the CNC machine’s axes are degenerate. We could increase one, or the other, to net the same new estimate for the machine’s behaviors because they are linearly coupled. I discussed this at more length with regard to printers in particular in Section 5.12.2, but the ambition applies across machine types.
8.3 An Open Ecosystem for Machine Control
I have mentioned in a few places how other researchers work is limited by closed motion control systems; Sections 4.2.8 and 5.2.4 both contain some examples; there is much work in modelling and sensor integration at a hardware level, but researchers cannot readily combine their contributions with their machine’s existing controllers. Where they do, systems are surprisingly complex (Section 2.6.2). In particular, the velocity planners present issues to these researchers because they cause their test path velocities to deviate in ways that are difficult to predict. This means that time-series data are difficult to reconcile with the toolpath geometry, which makes all subsequent modelling steps more challenging. It also prevents them from easily integrating new online control strategies.
This is true in other domains where machines need to be “hacked” and in mechatronics integration in general, for the assembly of all manner of automation equipment. I discussed the economic partitioning problem directly in Section 1.4.1 because I think that this existing arrangement is what really fundamentally limits our progress in the development of new and better machine and manufacturing systems. Those are always deeply interdependent on one another, and in the state-of-the-art there is often simply not enough information provided by certain core components to rapidly build new types of systems that push the envelope of what is possible.
The clear next step for the work in this thesis is to continue developing the controllers into an ecosystem that other researchers, machine builders and users can easily integrate into.
I originally developed OSAP, and then PIPES with this outcome in mind: the results for improvements to machine control were secondary. Section 7.2.5 already explained why I think the contributions there are valuable in this regard. Applications of the same principles (modularization, new systems assembly tools, portability) have driven the runaway success of open source software efforts as explored in [3] and [4], who note that the modular ecosystems that enable distributed collaboration on open source software are themselves modular, performant and extensible. That is, the systems that we use to compose systems are themselves composable and inspectable etc; they are open.
There are clear technical improvements to make, but the real remaining challenge is to understand how an organization can make and maintain the required standards for this type of system while also surviving as an entity. There are some good examples in open source software of organizations (like Mozilla from 1.4.1) that have pulled this off, but software does not have incremental costs to manufacture. I do not think that it has to be a charity, in fact most of the modern world is engineered against standards that are maintained by private organizations [5]. It is not either that these standards do not exist in industrial control already: EtherCAT, ProfiNET, CANBus etc are all maintained in this way. But they are perhaps too slow.
In open software, standards emerge in a body of practice that is shared amongst a community of practitioners; maybe we need guilds for machine control who make and maintain a set of tools for their own use. On that topic, I found [6] to be extremely informative: the simple sharing of ideas and methods by practitioners (in this case, early steam engine designers) led to incredibly impactful improvements to performance. Those drove the First Industrial Revolution. Rather than focussing on technology itself, the people and the practice may be the place to start. They are enabled by explainable, inspectable technologies.