At Mechanomy, we are building tools for the future of product design; as a researcher, designer, developer, manufacturer, seller, user, or supporter, this is your future. Technology does not improve by itself; tomorrow is only better if we work to make it so, and this work is efficient when we can separate real frustrations and limitations from hearsay and imaginings.
As we’ve approached Mechanomy, one of the key challenges has been testing our intuitions about customer pains and applying these to make the correct product decisions. For a wide variety of reasons, the business processes (design, development, manufacturing, and sales) used to create products are not discussed publicly, nor are they readily discernible from examining the final products. These processes are rightly regarded as competitive advantages, but this prevents hardware developers from drawing inspiration from their peers, and it limits our ability to discover and improve today’s workflows.
Today, we’re launching our first Development Trends survey at https://mechanomy.com/survey/index.php/956145?lang=en. We intend this survey to be a semiannual snapshot of the state, hopes, and pains of product development. Some questions are directly relevant to products we are building or considering, but more than that we feel it is important for the broader hardware design, development, and manufacturing community to regularly examine our tools and workflows, to seek to improve the ways that we build systems.
We would greatly appreciate your participation and candor in the survey, particularly if you feel we’ve overlooked some important aspect of your experience. After the survey closes on March 31st we’ll tally and publish the results and our observations. Please share this survey with your colleagues and friends and, as always, if you want to stay apprised of our efforts, say hi!
Frank has a problem. As he was leaving the worksite last Friday he noticed an old, battered satellite core. Frank’s predecessors had long since harvested its solar arrays and antenna for their readily accessible constituents, but they left the core to be buried behind other assets. Now that the backlog has been cleared it’s his job to ensure that the core has been safed and to classify it for materials recapture.
Looking up the core by its spatial hash, the it has been regularly noted in the quarterly inventories but no one has yet appraised it. There’s nothing like a mystery for a Monday morning. Approaching the core with the bay manipulator, he is surprised by the lack of any standard grapple fixtures; even the propellant and electrical interfaces are ancient and inaccessible. Lacking these, he switches to the deformable jamming end-effector, grabs the remnants of the antenna trunnion, and moves the core to the inspection array. Initiating the full diagnosis provides an ample coffee break.
Returning to the cabin, the analysis computer is having a hard time identifying the satellite bus structure, composition, and fastener locations. Knowing that structural junctions are often free of interior components and fixtures, he drills an inspection hole and inserts the tendril probe. Guided by the t-ray density map, the tendril keeps to the open spaces and eventually records enough perspectives for the 3D reconstruction to converge. It’s clear now why Frank’s predecessors, being closer to this level of technology, avoided this particular core. But once inside, even Frank can recognize the tank configuration suggesting hydrazine propellants. Stuff was so toxic back then…
Removing the core from the inspection array to the multimanipulator, Frank starts the multispectral recorder and deploys a containment tent around the core. Removing the multilayer insulation exposes the wall panels and many of the external fasteners. Rather than hunting for or fabricating the correct socket he drills the fasteners, since, at this point they’re likely corroded, and all chips are good chips if you’re a beam printer.
With the wall panels out of the way the innards make a bit more sense, the better access provides higher confidence that the tanks are metallic and not some arcane composite. Applying EM breaching tubes to each of tanks and sealing the containment tent, he incrementally punctures the tanks and starts the decon fluids a-flowing. Since the core reached its end-of-life years ago the tanks are mostly empty of their original contents, though still filled with their inert pressurization gas. The last tank is a bit suspect, as only cables appear to enter/exit the tank, but breaching it confirms that this was the satellite’s battery.
Pumping the tanks and tubes with the decon fluid, Frank seals the tank breaches and disconnects the breaching tubes. After affixing a datapod of his safing actions to the core structure and cleaning and removing his manipulators from the containment tent, he finally seals tent queues it for automated disassembly and recapture overnight. The computer’s saying 50kg titanium, 2kg Nickel in that battery, 30kg copper, 40kg various polymers. Pure substances…that’s one benefit of being produced on Earth.
And, since his company was contracted to dispose of this section of geostationary orbit, he tags his scans and the disassembly log to the historical service. Maybe the formerly advanced gizmos in this likely classified core are interesting to someone…time for lunch.
Design data is very helpful for operational safety, reuse, and recycling. But access to the original data is only useful if it can be interpreted by modern systems. Walled gardens and proprietary interfaces are in principle opposed to independent intelligibility, so it is important to resist DRM when applied to anything that is toxic or dangerous, anything that might have utility beyond tomorrow. If something is unknown it is unusable.
The ability to destructure assemblies from scans requires multispectral sensor fusion, advanced shape analysis, and the ability to evaluate subassembly candidates…all domains of machine learning. What sort of datasets do we need to learn these capabilities?
In space, commodities are distinguished by their location and ability to be fashioned into what is needed. As the extent of space structures may be a few orders larger than practical on Earth, material availability, not gravity, is the primary limit. This means that designs need to be able to be realized with multiple, differing materials, with the design fixed only at the build site.
The difference between a 3D printer and a programmable builder is that, in addition to the ability to create arbitrary structures, the builder is able to determine whether the design requirements have been met. It is a closed loop, changing the internal aspects of the structure according to its constraints, while still ensuring the resulting object will perform correctly. Can your Swiss-style mill do this? Can your 3D printer? What is needed from our design workflows to enable these capabilities?
Does tomorrow look like today? When do the capabilities of tomorrow appear, where do they come from, and how do we come to learn and use them?
Please think about tomorrow and help us all discover how to make it great. Have a great 2020!
Mechanics + -nomy, the system of rules, laws, or knowledge. So in the name Mechanomy, we are interested in the system of rules, laws, or knowledge of mechanical systems. This is the same construction as taxomomy, astronomy, etc. and is pronounced similarly: meh-kan-o-mie.
This is the first of a recurring series touring the capabilities and features of Modelica, a systems modeling language that we have great hopes for.
Where to begin?
At its core, Modelica is a programming language that allows users to write down equations that describe the behavior of some system. In this usage, system refers to some group of things that interact according to identifiable rules. A robot arm is a ready example as it is composed of multiple motors, transmissions, sensors, and rigid structures. The interactions of these elements are described by equations that convert the user’s digital command signals into electrical currents that spin motors whose torques are modified by transmissions and applied to the arm’s rigid structures. Taken together, the Modelica model of the robot arm allows the user to predict how the arm will move for given commands, allowing the arm’s suitability for the user’s application to be evaluated digitally.
This level of analysis is within the technical capability of most engineers, but performing it by hand or in some general purpose programming environment is often too much work. Using Modelica, the engineer can describe the system and let the computer do the math to solve the thousands of equations encountered in everyday systems.
Today, Modelica is most commonly encountered in the automotive and aerospace industries, where it allows simulation engineers to test a wider variety of situations than is feasible for the prototype car on the test track…such as “Can an F1 car drive on the ceiling?“. This approach also allows the internal conditions of subsystems to be estimated from other sensor sources. For instance, it is challenging to measure the internal temperature of an internal combustion engine because of the high temperature, high pressure, and fast progress of the combustion event, but it can be estimated to a good degree by measuring the piston position, air and fuel volumes, valve timing, chamber size, and exhaust products.
In these uses, the Modelica model is not concerned with the physical dimensions of the parts — the domain of Computer Aided Design (CAD) packages like Solidworks, Creo, and many others — but rather how they function and perform.
Future installments will delve deeper into Modelica and how it can be used to support manufacturers and engineers, but if you want to read more now check out: