Mechanomy

Text to CAD?

2024-02-05T00:00:00Z

Zoo is an interesting startup building, essentially, a SAAS API for mechanical CAD operations, or as their website says "Zoo creates infrastructure for hardware design". In this post I'd like to talk through their text-to-CAD product which leverages that SAAS backend, and what this approach to design tooling means for hardware engineers.

What is Zoo's text-to-CAD application?

If I ask you to buy a 24 tooth spur gear, could you do it?

That depends on our shared context; you could buy some random gear by assuming the information that I didn't provide to you, or you could look at the project files and design analysis and select a sufficient gear for the project.

Asking Zoo's text-to-CAD application for a 24 tooth spur gear,

As entered into text-to-CAD.

yields STEP, glTF, and other formats of a 3D model:

Some quick takes:

this is a really cool capability shipped quickly by a small team.
the gear model is basically what I requested, having 24 teeth of apparently involute profile.

I was not asked for the design context or to supply some of the missing parameters, it just replied with a gear model, caveat emptor. (It should be said that it is not easy to communicate design context, intent, and risks within a team, so at the very least we should limit our expectations.)

It can also fail:

Struggling on universal joints.

So, what did text-to-CAD assume about gears, how did it generate the model, and is this a step towards the tools of tomorrow?

Is the model correct?

First, there are 24 teeth. The outer diameter measures 26mm with a 10mm bore and 10mm thickness. Comparing the Zoo model to this gear from SDP-SI, they are virtually identical.

The generated gear (green) is virtually identical to a stock gear from SDP-SI (red). Highlighted are some of the standard parameters that were assumed by the application.

Without any association to a physical gear, the generated model is only useful for virtual prototyping and 3D printing; purchasing would require specifying the additional details of material, availability, and pricing, in which case it would be better to use the supplier's model.

How does it work?

To start, I don't know and Zoo has not discussed it in sufficient detail; the current alpha is likely a few-shot approach to a large language model (LLM), where some examples of parts in the KittyCAD Modeling Language are added to your prompt, but this section is necessarily speculative and general.

This few-shot approach might look like:

The one-shot system prompt from BlenderGPT (see the video)

The one-shot system prompt from OpenOrion's CQAsk

In both cases, the design is to tell the LLM some basic information about the general task and operations to prepare it to receive and respond correctly to the user's input.

Returning to Zoo, the introductory blog post explains the difference here from other efforts:

There are lots of text-to-3d models that exist for gaming asset use cases but there are no Text-to-CAD models. The distinction being that we do not use point clouds, we generate B-Rep surfaces. So you can import a STEP file from Text-to-CAD into any existing CAD program and edit it. The existing text-to-3d models generate meshes so if you were to import that into an existing CAD program, it would just be one large amorphous blob and not editable in any useful way.

The focus on a boundary representation of surfaces (B-Reps) is a key differentiator from merely 3D point-based approaches. B-reps are actual equations that collectively describe surfaces and edges of a model, while the latter point/mesh approaches assume a spatial grid, with AI solving 'what color will make this pixel/voxel more likely to be described like the given text?' on each. This representation distinction is also why every CAD user has been frustrated with trying to work with point cloud data, say from a 3D scanner: 3D points lack the clean precision of objects created by math in the CAD kernel.

Continuing,

Generating CAD models is a lot different than generating images or video. Models generating 2D images, 2D video, and 3D point clouds are learning from datasets with dense, highly descriptive and strict representations of data that each have one and only one representation. In contrast, there are multiple valid feature trees for each CAD model, so training and validation are not straightforward.

Whereas an image is represented only by its matrix of pixel colors, the design concept embedded within a CAD model is encoded across several layers of intermediate representation via sketches and features which combine to form a 3D model of the concept. To take the example of a hole for a fastener, a series of extruded cuts or a single revolute cut can both produce the same 3D hole, but these are parameterized differently. These intermediate layers of representation allow complex features to be designed in multiple ways, providing flexibility but frustrating attempts to learn a single way to create a particular feature. In natural language, this would be like having words that are synonyms only in the context of certain subjects, a tedious and sometimes confusing state.

A few more details on the approach are given on their machine-learning api page, though it is not necessarily the case that these capabilities are active in the text-to-CAD application:

Starting with our Text-to-CAD endpoint, anyone can build prompt interfaces to generate starter CAD models. The machine learning behind ML-elephant is trained on our proprietary data sets, and uses our Design API to programmatically generate novel CAD files.

The infrastructure behind Text-to-CAD utilizes our Design API and Machine Learning API to programmatically analyze training data and generate CAD files.

By fine-tuning our machine learning models on your data, you can rapidly leverage your existing data to create specialized Text-to-CAD generators without building and maintaining infrastructure.

The overall architecture appears to be:

A guesstimate on the application architecture.

Starting in the upper left, the textbox input ("a 24 tooth spur gear") is fed into the LLM which produces a parametric description in the KittyCAD modeling language of the requested object, if within the database's training. This part description is processed by the modeling kernel into a 3D boundary representation which can then be rendered as 3D surfaces that are displayed in the text-to-CAD model viewer and downloaded by the user.

All of the parts in the diagram are required, but the novelty is due to the part database and the LLM trained on the database, and this is the part that they have not discussed publicly.

On learning CAD

In AI product development I said that:

...the advances in image generation are entirely the result of having large image databases of a wide variety of regular scenes with generally accurate and specific labels that describe the scene. In contrast to photo services like Getty, which hosts many professional photos with strong and unambiguous labels, sites like Thingiverse have many fewer 3D models and presently lack descriptions of form and function. Indeed, today's 3D platforms have an altogether different business model than the stock art services, focused on assets for 3D rendering and printing, and both of these are much smaller uses than the every-article-must-have-a-title-photo practice of digital publishing that tied stock art to the rise of online news and commentary. Lacking this database, you cannot train an AI to link feature descriptions to the 3D data that provides that feature.

I still think that a database of objects and descriptions is necessary for any AI tool actually be useful, but one of the advances in text LLMs is their ability to learn from their own predictions and self-correct,

Many early machine learning algorithms required training examples to be hand-labeled by human beings. For example, training data might have been photos of dogs or cats with a human-supplied label ("dog" or "cat") for each photo. The need for humans to label data made it difficult and expensive to create large enough data sets to train powerful models.

A key innovation of LLMs is that they don’t need explicitly labeled data. Instead, they learn by trying to predict the next word in ordinary passages of text. Almost any written material—from Wikipedia pages to news articles to computer code—is suitable for training these models.

For example, an LLM might be given the input "I like my coffee with cream and" and be supposed to predict "sugar" as the next word. A newly-initialized language model will be really bad at this because each of its weight parameters—175 billion of them in the most powerful version of GPT-3—will start off as an essentially random number.

But as the model sees many more examples—hundreds of billions of words—those weights are gradually adjusted to make better and better predictions.

The expectation is that, with a sufficiently large database, the LLM can learn the steps to create a model, reading between the lines to judge not just the final output but also that the steps in reaching that output are consistent with the good practice seen in the training set. Some of the ingredients for this database can be seen in McMaster-Carr's product catalog: of their 700,000 industrial products, 380,000 fasteners and machine parts have CAD-native 3D models:

The product page describes the bolt, while the Solidworks part file contains the sketches and operations to create the 3D geometry.

Downloading the Solidworks file, I can see all of the modeling operations that were performed to model this particular bolt. To change the bolt I need only to locate and edit the appropriate parameter. With thousands of slightly-differing bolts in their catalog, I should be able to learn what few numbers change between each and the connection between the product description, the sketches and features, and the resulting 3D model. But in studying the bolt models, I can also learn a modeling strategy of: start with the head, then make a cylinder, then put threads on the cylinder.

This modeling strategy is opinionated and does not identically apply to modeling other parts, like nuts or washers, but within the class of bolts following it should result in a correct bolt. The challenge of generative CAD is in generalizing beyond the training, of getting outside of the database of trained models and doing something new. This has been labeled

The creativity gap: In conventional [deep generative model] applications, the overarching goal is to mimic the training data and emulate existing designs. In engineering design, emulation of existing products is often undesirable. Designers typically aim to introduce products with novel features to target new market segments.

As most designers will attest, the creative act in modeling is in taking a mental concept and breaking that into primitive sketches and features that collectively realize that concept in a 3D model. We don't talk about this act, nor do our tools elicit this from us, we just do it and make a model. I argue that some of the key information in CAD modeling is not present in the existing databases, even when you have full access to the feature tree, and I am not yet persuaded that AI learning is as unbounded as human learning in this domain.

I would also argue that CAD 'languages' differ significantly from natural language, both in quantity of data to learn on and in the quality of the representation. In natural language we generally create conceptual precision by adding words: the quick brown fox is a fox, that happens to be brown and is also quick in its movements. Changing the adjectives changes the meaning, but increasing the precision of the adjectives, saying "#964B00" instead of brown, hasn't added useful meaning but erroneously constrained it. Our parametric CAD paradigm is rooted in real numbers, not additive grammar, and no amount of tweaking the color code or moving a point on a sketch will remedy this representational error.

While I can verbalize sketching

relative to the origin define a line making an angle of 45 degrees between a point on the X axis and a new point 300 mm from the origin

I'm not actually using language to describe design concepts. Describing a sketch relationally

create a six-sided polygon such that two opposing side are vertical in order to register on the fixed and moving vise jaw, another side is horizontal to provide locate the part vertically, with the remaining two sides vertically-symmetric about the center and making equal angles with their adjacent sides so as to center a cylindrical work piece placed between these two sides (describing a V-block)

is better but may quickly run into a challenge similar to that of defining what art or beauty is, of trying to correctly and exactly describe one version of a feature over another. This challenge is not uniquely found in GUI-based parametric CAD, as code-based modeling applications also rely on visual reasoning and mental tracking of the model state, arguably because both code and language lack the grammar to state intermediate concepts correctly. Already this is seen in the challenge of prompt writing, where the inability to uniquely describe the desired output results in a lengthy, textual search of the LLM for something approximating the imagined concept.

So, I don't think that it is or will be easy to construct or train on a CAD dataset, or that you can get away with a small number of models and reason out to general capability, at least under the present approaches in CAD and AI.

Towards the tools of tomorrow

Stepping back, does the correctness of the generated gear matter? Or what level of detail is required for a gear or any model to be 'correct', and when does this correctness matter? Already McMaster-Carr and other distributors disclaim the accuracy of their CAD models,

The 3-D CAD models and related information are provided for reference only. The CAD models do not contain any technical information other than what is readily observable, specified by industry standards or provided to us by our suppliers...The dimensions and other technical specifications of our products may vary from those shown in the CAD models...

To give an example, if I have 5 gears laid out in a line, my intent of forming a gear train is reasonably clear even if my gear selection is deficient. What the mechanism designer cares about is whether the gear transmission can transmit the power desired, and that its components are selected according to some metrics like availability, transmission efficiency, mean time between failure, factor of safety, backlash, inertia, etc. But not all of these can be determined a-priori when selecting a gear. Some, like backlash and inertia, require analyzing the entire transmission and often physical prototyping and testing. Others, related to purchasing, are frankly better chosen by a dedicated purchaser who is aware of the manufacturing schedule, than the original designer months ahead of production.

Right now we use standards to fix the engineering aspects of a design while leaving the sourcing and purchasing details for later: buy something meeting this specification and the product should work. But as manufacturing becomes more programmable and supply chains continue to be scrutinized, there will be increasing pressure to defer some of the engineering details for market or other business reasons.

Just as the best systems are robust to widely changing inputs and external disturbances, remaining performant and useful until they fail in a predictable and proportional manner, so too should robustness of the system design be valued -- design meaning the total collection of the engineering formulas, analyses, test results, architecture, subsystem divisions, material selections, interface technologies, tolerancing rationales, and all other choices made while designing the system. I would argue that we are stepping toward a more hierarchical and iterative approach to systems design, where general goals are stated and their implications rendered, evaluated, and used to organize the next level of detailed design work.

At the end of the day, I want to be able to optimize the overall system design for any variety of purposes, some of which, like market response, I cannot know during design but will dearly desire once the production clock starts ticking. In order to do this we need tools that allow specification of only the essential aspects of the design; the less I specify, the less the design will be constrained in some later stage. Imagining, then, a more general AI-powered design assistant, I would like to just request "a gear transmission transmitting 3N-mm of torque between shafts 83mm apart with a 2:1 transmission ratio" and receive something that looks like that, something that I can include in the design that is correct enough to be able to get onto the next subsystem. Then, having coarsely described the system end-to-end, my team and I can dive into modeling each subsystem to ensure their correctness, consistency, and performance within the context of the overall system design.

Text-to-CAD allows some simple parts at one level of a system to be specified briefly and textually, making very clear what the designer is and isn't intending to specify, if the prompt is maintained along with the model. This tool presently lacks a place in an overall design workflow, but it is a step in the right direction.

I hope designers and engineers are paying attention to these developments, not because they are ready or even capable of professional use, but because now is the time to push these capabilities in directions that actually improve productivity and design quality and away from marketing hype.

Mechanomy's Fifth Birthday

2024-01-16T00:00:00Z

See this post on Substack

Today, January 16th, is Mechanomy’s fifth birthday.

It’s hard to say more than that, not because there haven’t been ups and downs, but because so much remains pending, awaiting fuller realization. The best things have been getting prototype tools to work, often in some new language or library, which further proves my vision for Mechanomy and says, ‘well these parts are very close to ready’, that the capability is works and awaiting application and integration. On the negative side is the ‘weakness’ of the market, in that I’ve struggled mightily to find any overlap between what the market wants (is presently buying and is being advertised), what the market needs, and what I can offer:

The overlap of these three is where I should focus:

The problem is that market needs are only coarsely known; while market wants can be determined by what is currently being sold and bought, tomorrow’s needs has a very soft edge. This makes my product development choices risky.

It is straightforward to build a competitor to some existing capability, as solution and customer are both visible and the only question is whether your new solution is better than the existing. At my current size, engineer-focused website development is an obvious direction, where my wide familiarity with the industry would allow me to understand clients and their end customers better than less-focused webdevs. Parts of this can be seen in my design tools, which demonstrate capabilities that are straightforward yet widely absent on engineering services and manufacturer websites.

Developing the backend framework and competency over multiple clients spreads out the cost, while charging for the initial build and ongoing operation points the graph somewhat upward. Attention to detail in the construction of modern, customer-focused capabilities would, in some small way, make the end-customer more confident in their purchase decision, thereby advancing the interests of my clients, their customers, and our society broadly.

But as this would be targeted at the market’s existing wants rather than its needs, it can’t do much to improve the situation today. And I see a ton of things that want effort and improvement. Despite this, no one really knows the market’s needs; all anyone can do is build bridges from today to tomorrow.

These bridges vary widely; the most expensive are designed by teams of marketers and erected by sales staff and value-added-resellers. They’re expensive because the bridge generally works, it does get you from the previous version to the next, and you had a good idea of where you were going throughout. Other bridges are spendthrift, consisting of little more than some planks laid across a creek; dangerous when crossing a canyon but acceptable over shallow water. Their goal is merely informational: the new version has these capabilities, acquire it here. This is the norm for software and libraries distributed by GitHub and others, no frills, no expense.

The goal of this substack is to build bridges to the capabilities that I and other engineers want to use to build tomorrow. As much as I want to skip to building tools and capabilities, it’s become very apparent that I cannot do so at Mechanomy’s present scale.

Instead of directly building individual capabilities and then searching for users looking to solve only that single problem, I plan to take an iterative, outside-in approach, first describing how I understand various problems, what I make of the various solutions presently existing, then requesting information from readers to critique the various proposals. The hopeful result will be a more concrete understanding of a need and its possible solutions, some of which Mechanomy may be able to provide.

I like this approach because writing a post is cheaper than writing and releasing a library: in both cases I’d like to convince you that my approach is a good, or even better way to solve a problem, but the latter has the potential of wasting time on unnecessary functionalities and will still need and introduction and some promotion. This approach is similar in spirit to building-in-public, the idea that by openly journaling the development of some thing, that the thing will be better because of the public’s involvement (in some form) in the development.

One parting motivation is that I do not know where design engineers hang out, where or even whether they grouse about the frustrations implicit in every engineering tool. These frustrations arise from negative externalities, the unintended consequences of decisions made elsewhere, yet if denied expression, will never be fixed. In this and many other aspects, community is a good thing and we will benefit from more of it.

Software engineers are conspicuous in their public advocations for their spiffy, new way of toggling bits, but mechanical engineers and product designers are not. From the outside, few appear proud of their work. In later posts I’ll go into some reasons for this and what I think we can do about them, but one basic point is that software is easier to copy than hardware, the result of which is that the traditional close-minded approach to what is assumed to be intellectual property is highly damaging to our work, companies, profession, and society and its past time that we advocated for ourselves.

I hope that this journey will be interesting and encouraging to my fellow design engineers, please subscribe, follow, comment, reply, or otherwise engage.

Timesaving Solidworks Macros

2023-10-23T00:00:00Z

CAD modeling involves many repeated commands, but in Solidworks these four operations were so annoying that we wrote some simple macros to automate them. Grab them from https://github.com/mechanomy/SolidworksScripts, being sure to add them to your macro file locations and mapping them to shortcut keys.

addAxesXYZ

When you make a new part or assembly, or load a part from a vendor, it frequently lacks axes aligned to the part's x,y,z coordinate system. In the case of a screw or bolt, having an axial axis makes mating just a bit more straightforward. This macro adds these canonical x,y,z axes to the open part/assembly at the intersections of the canonical planes.

export3mfStep

As 3D printing often requires multiple part iterations, this macro saves the current part in 3MF and STEP files. 3mf is a hands-down better format than STL and is accepted by all(?) modern slicers. The macro also saves the model as a STEP file as a way of noting the state of the model at the print time.

importProperties2Part

As Solidworks' Excel-based Design Tables are pretty poorly designed and implemented, this macro allows these to be avoided by directly importing variable names and values from a CSV file into the current part model. With this macro you can keep shared dimensions in a common, master file which is imported by all of the parts that need those dimensions. Any changes in the master file can be propagated to the parts by simply re-importing the file.

The CSV format is:

Optional reference path to file.csv or other comment, this first line is skipped when importing.
Default; secretText; text;  secret text string;
Default; bigLength; double; 60.00000;
specialConfig; configNum; double; 2.500000;
specialConfig; configText; text; specialest config;

The second column is the property name, the third is 'text' or 'double', and the fourth the property value. In the first column, 'Default' imports the 'secretText' property with value 'secret text string' as a Custom File Property, while 'specialConfig' or any other name creates a configuration with that property.

exportPartProperties

This macro exports the current part's properties to partName.csv, following the same format as importProperties2Part. Together, these import and export macros enable you to avoid Excel-based design tables when making variable parts.

We'd love to hear if you find these useful, and if you have ideas for other Solidworks macros send us an email or mention @mechanomy_ on Twitter/X or LinkedIn.

AI Product Development

2023-09-12T00:00:00Z

The past year's advances in image synthesis (DALL-E, MidJourney) and large language models (LLMs, ChatGPT) have been truly exciting and have given many the occasion to look towards the future in a new way. Not to be left out, many designers and engineers have asked how these advances will change the way we design, develop, and manufacture products, asking whether they will help us, pass us by, or obsolete us. At Mechanomy, we're in the former camp and in this post I'd like to elaborate why.

Before we get too far into it, I'd recommend this overview of the present moment, where Tim Lee gives a good overview of the recent advances in large language models (LLMs) behind ChatGPT.

First, it is clear that some of today's tasks are becoming vastly cheaper and will force career changes:

As a motivating example, let’s look at the simple task of creating an image. Currently, the image qualities produced by these models are on par with those produced by human artists and graphic designers, and we're approaching photorealism. As of this writing, the compute cost to create an image using a large image model is roughly $.001 and it takes around 1 second. Doing a similar task with a designer or a photographer would cost hundreds of dollars (minimum) and many hours or days (accounting for work time, as well as schedules). Even if, for simplicity’s sake, we underestimate the cost to be $100 and the time to be 1 hour, generative AI is 100,000 times cheaper and 3,600 times faster than the human alternative. a16z

I say that 'tasks' are becoming cheaper instead of 'jobs' because there is an important difference between havers-of-ideas and doers-of-things. A graphic artist's job is to communicate ideas visually; they do this through a number of tasks that create the graphic and it is a certain few of these tasks that are actually, if significantly, advanced by the AI generators. For instance, (if) in creating a graphic there are tasks: receiving the idea, elaborating emphases, designing the scene and variants, choosing colors, primary painting, layering, and finishing, only some of these are becoming faster while others are being sidestepped, rearranged, or skipped over. Primary painting appears to be well-performed by the image generators though having very little ability to specify small details like the brand on a soda can. The scene is also coherently composed by the generator, but only implicitly because scene design is not separated from painting; there is again very little ability to change specific aspects of the result, like shifting the position of a sofa. AI generation differs significantly from today's workflows which makes it necessary to understand why certain tasks are performed and whether they are essential and able to be performed under an AI workflow.

Prior to the image generators, the market for new graphic art was limited to those with the resources and need to commission new creations. Image generators have greatly lowered the crude cost of new art, but that lowering comes with costs to quality and customization that may or may not be acceptable.

I argue that as significant as these AI advances are for image generation and language tasks, product development is an altogether different domain that requires much more human consideration.

Designing a new product often feels like a race, not necessarily against formal competitors but against the speed of my own thought and experience. Once you start exploring an idea, the pace of your thought needs to be matched by the pace of your design work. There is a window of time when you most understand what is novel and are able to translate your thoughts into sketches, conversations, words, and other external representations. These actions fix certain aspects of the idea, freeing the mind to work on subsequent aspects. The goal of most design tools is to enable you to do this quickly, to help you move from vague to grounded concept as quickly and thoroughly as possible. If the design is driven too quickly, either by team members, opinionated software, or aggressive deadlines, it becomes hard to give each element sufficient attention. On the other hand, delay these expressions too long and the mind gets bored and frustrated, forced to break conceptual leaps into trivial steps.

If you accept this idealized drama of design, the question for any design tool is how it affects this process and the many tasks within it.

Where can LLMs, image generators, and other AI tools help design engineers?

The most immediate place is in explaining an idea to someone else. (Exaggerating for effect,) I find it laborious and sometimes challenging to codify all of the context about why I am excited for one idea and bored by another. One reason that it can be challenging to explain exciting ideas is that language requires both creativity and a degree of specificity. During the idea stage I devote much of my attention to imagination and observation while avoiding other, unrelated thought modes like diction. When surrounded by unknowns the last thing I want is to open the window to another swarm of unknowns, those of language.

Related to this is the elusive aspect of specificity. Words have particular meanings, and being forced to express a variably-known idea in words desires wording that respects what is known and unknown about the idea. Use too strong of a word, or one that your colleague has a more strict conception of than you, and suddenly a perhaps important aspect of the design has been specified, absent any direct consideration or process.

Expressing ideas with the help of a LLM can remove some of these negatives, freeing the designer from composing and iterating on an idea description, while also offering a conversation with a non-judgmental non-person, one who cannot be trapped in a flawed conception of the idea and is at any rate not going to participate in any latter phase of the development.

Combining concepts

Complementing LLMs is the ability of image generators to synthesize various combinations of concepts. While this is not relevant to every field, it has clear utility in communicating user stories by generating images of people in scenarios to guide development. This can be thought of as the synthesizing of an idea board, the ability to codify and communicate an aesthetic that can pull designers into a fruitful creative space. As this task is only coarsely defined, up until this point it has not made sense to task graphic artists with this creation, relying instead on the designer's sketching. This context communication is well-suited to image generators, as a tool to assist creation and an improvement on prior practices which hopefully results in more and better creation. (In some ways the many errors in generated scenes can reinforce the idea's ambiguity.)

Similarly, image generators can be used outside the development team to also develop customers and elicit their early feedback. Why press the dev team for an early render when user research can generate 10 coarse variants to ground differing use-cases? At least right now, a picture is worth a thousand words; this may change in time, but any improvement to idea communication will help user researchers and marketers.

These are only two aspects of product design - communicating ideas and idea boarding - that can be improved by recent advances, though there will be many more. (I'd especially like to hear from design firms how they're using AI today, leave a reply or email!)

So can AI design products?

In presenting first how AI can help designers and engineers in product development, I mean to illustrate how the tools we have right now can help us do our work more effectively. As with the graphic design example, no designer would describe themselves as an idea board builder; rather idea boarding is an task designers do in order to understand their users and ideas. Likewise no product developers are chiefly focused on elaborating ideas in text, as the ability to have or hold the idea is much more widely useful than its mere recitation in text.

What should be clear is that AI is not a totalizing, direct-to-user technology competitive with today's (or tomorrow's) product development processes. As ever, it is a new tool amenable to some tasks that makes developers more capable and productive. With that said, here are three major impediments to AI product development of any sort.

1: No database

First, there is no large database of 3D models with feature descriptions, making it hard to learn relationships between 3D features and their descriptions. As you may know, the advances in image generation are entirely the result of having large image databases of a wide variety of regular scenes with generally accurate and specific labels that describe the scene. In contrast to photo services like Getty, which hosts many professional photos with strong and unambiguous labels, sites like Thingiverse have many fewer 3D models and presently lack descriptions of form and function. Indeed, today's 3D platforms have an altogether different business model than the stock art services, focused on assets for 3D rendering and printing, and both of these are much smaller uses than the every-article-must-have-a-title-photo practice of digital publishing that tied stock art to the rise of online news and commentary. Lacking this database, you cannot train an AI to link feature descriptions to the 3D data that provides that feature.

2: No language

Second, if you had a database of 3D models and incorporated features, in the direction of services like TraceParts and distributors like McMaster-Carr, the relationship between product specification and geometric feature, as well as their function, are unknown. "What about this wheel makes it appropriate for a TV cart? Well, certainly its shape, which allows it to roll over the ground while bearing a load, but what do we mean by roll and bear? Well, to roll is to revolve about an axis which can be described mathematically... And to bear a load means here that some load elsewhere is prevented from falling while some other function occurs..."

Of course we can describe a cart with equations and we can apply various tests to the equations to ensure their correctness, but choosing these tests and determining whether they sufficiently and uniquely describe the cart is quite a bit of work. This work has not been done, not because it is impossible but because it has not been needed (yet?). Now, I argue that the advance of machine tools is making these technologies necessary, but we are still at the stage of building a language that describes existing systems and I at least do not see many shortcuts.

(Let's say I was rather surprised to see this promotional animation from a company called ValiSpace. It's a nice vision and some aspects are technically possible today, but I've seen no proof that any of the groundwork has been laid to enable this, nor that one startup is capable of doing so, as they do not need AI to be able to begin utilizing the underlying capabilities.)

Lest I be too dismissive, I do think that it will soon be possible to extract the movement of mechanisms from videos of their action, and having those movements to search for some combination of first-principles models that might give rise to that motion and thereby 'discover' the recorded mechanism. Associating these extracted movements with the surrounding context of the video may enable the form and function database to be initially populated. There are obvious starting points in the structure from motion algorithm in photogrammetry and the techniques of mechanism synthesis, but I haven't heard of anyone working on this.

Again, I'll never argue that computation will always be too expensive, that brute-forcing all of this analysis will remain beyond us. But overfitting is a very real danger, and at some point it does not matter how the mechanism appears to move or that a derived simulation passes its checks, at some point you need to build the mechanism and determine whether it is behaving like the model, and even with lights-out machining this will still take time to produce and will still not be able to determine if a variant is useful.

3: No judgement

Third, we do not suffer from having too few ideas or options in designing a product. Rather, the real challenge is determining what is worth prototyping, developing, manufacturing, and bringing to market. Wherever there are unknowns, there is risk, risk is that is expensive and consuming of calendars. Design and development thus always entails judgment, judgments rooted in understandings of physical reality, user behavior, competitors, etc. These judgments only make sense from a human perspective; if you cannot imagine someone using your product, then you are not going to develop something that they will use. The converse also applies, that an AI's inability to imagine a product's use necessarily prevents it from making correct judgments on which products to develop and their features.

In the same way, a notional AI-developed product cannot be inventive. We can certainly use AI to invent something new, but the whole point of being new is that that new thing is not in the existing corpus of things that are generally known. Can I imagine asking AI to swap one feature for another or to combine several separate products into one, sure. And in so far as these alterations and combinations were included in a brute-force multiplexing-of-things because compute is cheap, well that's still not really novel.

All of that is moot until one user says: "I want that". That expression is quintessentially human, something that a computer cannot do because computers have no interests or desires and lack agency in any sense.

At the end of the day, engineers build and wield tools; new tools can only increase what we are able to do. The question of generative AI is actually the question of what we desire to invest ourselves in, how we can develop our abilities to help our neighbors; AI can never do this for you.

I'd love to hear your comments on Twitter or LinkedIn and be sure to subscribe.

Feeding the Machines

2023-09-11T00:00:00Z

One of the consistent themes of this new century is the pining for the yester-years, when problems were many, tools were accessible, and manufacturing and labor were cheap, resulting in manifold companies, patents, innovations, and rising standards of living. There are many reasons that we should not expect that to return; as Robert Gordon says: "The 1870-1970 century was unique: many of these inventions could only happen once, and others reached natural limits."

This pining can be useful when ruminating on the ingredients of tomorrow, as it suggests that futures that resemble today but just demand more of people -- spend more years in school, work harder and smarter, offshore production -- are largely incorrect, not because they can't be made to work but because they try to solve a new problem with old techniques and mindsets, with brute-force. Instead, we should want to build new technologies that allow us to express, reason over, and manage tomorrow's complexity.

Why will tomorrow be more complex than today? Simply because it can be; each day brings increasing mastery over or knowledge of all that surrounds us, leading, for lack of a better word, to boredom with the present and the hope of fixing small inconveniences and notable failures all around us. As an engineer I will never say that things are as good as they can get.

One vision in manufacturing is mass-markets of one, the idea that consumers would like to be able to buy individualized products at commoditized prices. Within this vision are the ideas of just-in-time, lean, local, and bespoke production, and this is very much not the reality of today. Some areas of the manufacturing stack -- the companies, people, processes, and technologies that manufacture a good -- are ready for this future. Machining centers don't really care if they make 10,000 identical parts or 10,000 unique ones, provided they are supplied with the required stock, fixturing, and toolpaths.

Now, there is clearly a difference between producing a simple part on a manual machine and doing the same on a CNC; the CNC machine is more complex itself and requires supporting technologies to allow it to produce even the simplest of parts. It may be a little more precise to say that while the overall complexity of machining a simple part is the same, where that complexity resides has shifted from the operator to the machine controller and supporting ecosystem. This shifted complexity enables the machine operator to be more distant from the process, no longer turning handwheels and listening to the tool but instead programming this and many other jobs in advance of the work and then setting up and monitoring the production. The resulting increased productivity significantly depends on the computer-aided-manufacturing (CAM) software that allows the machining operations to be described and executed by the machine. Working towards mass-markets of one, then, requires shifting more complexity from a formerly static process -- produce 10,000 identical parts -- to something that is more dynamic and able to internalize the differences between 10,000 individualized parts. Doing this will require a different relationship between CAD and CAM software.

In many ways CAM software is a mirror image of CAD software, with both producing a 3D part though through differing operations. CAD starts with nothing and iteratively adds features, while CAM starts with a block of stock and iteratively removes material through simulated machining operations. CAD gives the designer freedom to focus on a feature's design, while CAM assumes the feature and offers multiple methods for machining it. But when a CAD designer makes a change to a feature, it is not immediately obvious how significantly the CAM will need to change to realize it, as it is only on the CAM side that the machine, stock, and tool limits are represented.

Making individualized parts, then, will require much greater coordination between the CAD designer and CAM programmer. The designer communicates the feature change and performance added to the programmer who replies with the cost, schedule, and other production implications of that feature change. In contrast to the immediate, visual feedback both designer and programmer receive from their software, this communication is slow and error-prone. Indeed, Autodesk Fusion360 mostly side-steps this challenge by simply merging the roles of the designer and programmer, leaving the performance/production trade inside the user's brain. The problem is that this does not scale; rather than forcing complexity onto users, software tools need to give them the ability to communicate more and more accurately.

Now, I'm using the mass-markets of one vision to illustrate this scale limitation, but it's present in differing degrees in every manufacturing system. And many areas are worse-off; CAD+CAM-driven CNC machining is in many ways a leading domain, as there are many manufacturing and assembly processes that are not computer-controlled, modeled, or simulated but rather operated significantly on experience. So it is from the perspective of how much work needs to be done that I am writing this, as it pains me to see how much effort is invested in working through and around poor processes, while at the same time seeing how un-ambitious and under-responsive most new CAD/CAM/PLM software features are.

Of course, I'm also writing in anticipation of the design tools that Mechanomy is building, tools capable of designing 10,000 individualized parts that I fear will not be able to be manufactured. If you are also looking forward to the challenges and technologies of tomorrow, say hi, and, as always, comment on Twitter/LinkedIn.

Interested in Modelica animation?

2023-06-15T00:00:00Z

3D animation is an essential tool for developing and debugging physical systems because it allows developers to use their highly-trained eyes and experience of the physical world to look for modeling errors. Yet animation is overlooked by many Modelica tools; they may have a basic capability but most of their development/UX effort is elsewhere. The problem is twofold: experienced developers work on the needs of experienced users, and of the resources gap between solo/small team Modelica users and corporate / university research groups. Modelica By Example is a great resource, but only because Dr. Tiller decided to create it; it was not 'needed' or produced by any of the leading Modelica organizations, by those who determine tool development priorities.

I have been frustrated in making animations for the MonthlyMechanisms, dealing either with OMEdit's inability to display STLs and save animations (this was recorded by screencap) or the DLR's poor rendering. Other people have this problem as well.

What do you want in a Modelica animation tool?

My initial design is bare-bones: a post-simulation script taking the model and result files, producing an animation according to parameters. Rigid bodies will use the same shape= field to specify the shape, though allowing more advanced files like glTF. Initially, it will be restricted to models contained in a single file, as parsing a modelica package tree is tedious. Animation will be performed by three.js, with an optional output of the three.js scene JSON. The basic workflow will be an MIT-licensed Julia package, email me for translations into other languages.

How you can help:

what Modelica tool and scripting language do you prefer to use?
what systems are you modeling, can you send me an example link?
and, because the wheels need to turn, is your use commercial?

Please leave comments on GitHub.

Existing work:

I wrote an module for MAT.jl to read Modelica v4 .mat files
MeshCat.jl - focused on creating Three.js viewers from Julia processes
Modia3D - not there yet, cannot handle kinematic loops
?

Validating product interest

2023-06-13T00:00:00Z

How quickly can customers evaluate product suitability?

Suppose a potential customer visits a manufacturer's website, but they are unsure whether the products are suitable for their application. What can a manufacturer do to validate their interest, to reassure them that the manufacturer's website and products are worth evaluating and worth sharing with their development team? While that customer could call, chat, or email an application engineer, those portend tedious interactions that may or may not answer their questions.

Instead, here are three levels of interest validation you might incorporate into your website:

First: make information correct, consistent, and accessible

When sourcing products it is always annoying to have to push through the many different ways that manufacturers and industries represent the same product information. Is it backlash or relative position error? Measured in wavelength, frequency, or energy? These differences in convention are not solely a manufacturer's responsibility, but they are opportunities to reach out to customers and meet them in the framing they are familiar with.

Units are the most basic example of an area where industry and company norms vary widely, yet it is easy to offer information in whichever unit system your customer prefers.

Similarly, there are many good ways to show the differences between products, to provide simple tables that allow visitors to see how features vary across model numbers.

Relatedly, if the interpretation of a chart matters, then it is important for a manufacturer to take modest steps to make the chart readable and useful. Displaying a poorly-scanned chart from a print catalog undermines confidence in its application, while an interactive chart increases confidence.

Likewise, it is not difficult to display 3D models of products; frankly, the harder part is producing and correctly naming product variations.

Details matter in communication; providing these small UI features at the first interaction shows that manufacturers value clarity and accuracy, and will continue making the effort to understand and satisfy the customer's needs.

Second: standard use cases should sell themselves

What prevents a manufacturer from making buying guides for common applications? Make them exact, showing the calculations and their interpretations and where the remaining risks actually lie.

Customers are coming to a manufacturer because manufacturers should know how their products perform in the field. They are not expecting ideal performance, nor are they looking to become experts on the products themselves. Make content that tells them whether their use case is normal or risky in any way. Having done this initial, scoping evaluation, both manufacturer and customer will see the need for engaging an application engineer.

Mechanomy can help manufacturers create these interactive application guides and other forms of content, just send us a description or example to start a conversation.

Third: develop and release simulations of real conditions

Especially those that confirm or disturb mental models.

Simulations can be used to communicate edge cases and failure modes, creating a common palette of phenomena whose effects can be jointly considered. These explanatory simulations are akin to taking video of the specific phenomena, except that as simulations they allow full inspection of the system internals and linking to product parameters. The resulting simulations are useful both externally in sales and internally in design. Because these attempt to capture reality in a significant way, their development is more involved, and the result far more useful.

Say hi to explore what's easy, what's hard, and what we can do together.

In summary

When a potential customer visits your website, the first value you can provide to them is to show them that their interest is valid and worth spending additional time exploring your products.

Mechanomy authored these libraries to help manufacturers communicate with their customers. The pages linked above detail each and should provide you with everything you need to evaluate their functionality, but as general applications they are necessarily limited in how they can be customized to fit your website's existing theme and goals. If you would like us to tweak an application to better match your website, send us a quick description. We can also support specific interactions and add more advanced functions, reach out to start a conversation.

We also understand the common and usually warranted frustration with website investments, that visitors are few, brief, and overwhelmingly uninterested in your company's products. If you have some time to chat, we would enjoy sharing our analysis of the motivations of visitors to manufacturing websites and provide a couple suggestions for how you can better define and evaluate your website's performance. We believe that websites and other digital tools can be used to manufacture value, but like every physical tool they must be designed well and wielded correctly.

We'd love to help you.

Automate 2023

2023-05-23T00:00:00Z

I attended the 2023 Automate show this past Monday and again enjoyed seeing much of the automation industry condensed into one hall. Alongside IMTS, there really is no other US-based event that does as good of a job of showcasing the variety conveyance, industrial robot, vision, control, and service providers as this show. And while Mechanomy focuses on the design side of manufacturing, the increasing flexibility of production is central to many of my considerations. It's also just fun to go and see different machines, designed for needs that I only vaguely imagine. Here are some of the cooler things I saw:

The Archimedes differential traction transmission

I was really excited to come across Innovative Mechatronic Systems' Archimedes Drive, even if I initially mistook it for SRI's Abacus concept. This transmission appears similar to a planetary gearhead in that there is a central input (sun) which drives a ring of planets that roll between the sun and an outer ring. The picture becomes more complicated when you see that none of the elements have gear teeth and that the planets have two differing radii:

Focusing on a planet roller, see 0:48 above, it has two cylindrical sections of differing diameter. The first diameter rolls on fixed bore of the housing, akin to the ring of a planetary gear, while the second rolls inside the output annulus. When their diameters equal, nothing happens, but when the diameters differ, even slightly, a large transmission ratio is developed.

While this concept could be implemented with regular gear teeth, the integer number of gear teeth will discretize and constrain the possible transmission ratios. Removing the gear teeth and simply relying on the contact friction of the rollers and internal cylinders, infinitely-many ratios may be created. The overview video mentions up to 10,000:1 and an input speed of up to 8000 rpm.

Without teeth, what maintains the input/output relationship? That is, it is usually significantly easier to put an encoder on the motor than on the transmission's output, and this arrangement can be trusted because the designer assumes that the gears will not skip teeth outside of failure. In the Archimedes this is managed by preloading the planet rollers to ensure that their contact friction is (likely appreciably) greater than that arising from the transmitted torque. Which is to say that as long as the application stays within the drive's rated torque, the drive will not slip. That said, my hazy recollection of tribology raises a suspicion that the drive will display error over very long rotations, and that this error may have some dynamic dependency. I suspect that this and other common apprehensions will be directly addressed with continued development. Already, their registration-gated brochure claims better speed, backlash, and stiffness than strain wave and planetary gears.

Naively, I'd expect these drives to have similar failure modes as roller and ball bearings, with generally dependable performance as long as contamination and thermals are handled. Their materials do not list any lifetime expectations at this moment.

As this is just their third show, their product release has a long way to go to get into the market. While targeting pick-and-place robots, likely Deltas and SCARAs, use in serial manipulators may take longer to achieve due to their greater degree of integration complexity. These would appear suitable for robot drive mechanisms, as they already expect wheel slippage, though at present their precision grinding may obstruct this market. The similarity to roller bearings is again suggestive that they may be able to significantly reduce their cost in time, and in ways that are not accessible to planetary and strain-wave gears.

RB9

RB9 is doing it, building a spatial cable robot for accessing large workspaces in generally warehouse or hangar applications. I phrase it that way because I find cable robots to be too captivating: they have a pretty large design space and they really obviously exhibit a wide range of classical dynamics, yet they also appear within the capability of a small team to design and produce. While they left the overall system at their hangar headquarters, I appreciated the drive unit they brought to the show and the wide-ranging discussion with their founder.

Airskin for Kuka

If you take a standard, non-collaborative robot arm and add instrumented cushions, does that make it safe to work next to without a cage? That's what Airskin is asking by attaching soft panels to regular robotic arms, each instrumented to detect collisions with unknown operators.

Unfortunately, the only people who can answer this are regulators and I'm not sure how many were in attendance or how easily convinced they may be.

Autonox Robotics

If anything, the trend of the last several years in industrial equipment has been to greater consolidation of ecosystems across the industry - whether that is motor+drive, motor+drive+controller, or across machines - despite the ever increasing programmability and decreasing cost of those motor drives.

So I was surprised to stumble across Autonox's booth and hear that they have found a number of customers who appreciate their modular, un-bundled approach. They design and produce the manipulator's mechanics, you (your integrator) bolt on your actuators and end-effectors and integrate it into the larger system.

The Henry Ford

My wife and I visited the Henry Ford museums prior to the show, and I am super impressed with the main museum. From "the oldest surviving steam engine in the world", an original Newcomen built in 1760, to Watt's 1796 pumping engine, across many engines used to power machines and buildings, to the portable steam engine that Henry Ford fixed, operated, and which launched his career in engines, to steam tractors and rail engines, and then to a large history of Ford vehicles and several notable planes, they have an excellent collection. They also have a number of historic machine tools and textile machines that would support a number of narratives about the nature of innovation.

Two critiques: I would have liked the historical narratives to be much stronger and more personal, ideally through handouts of varying depth and focus. The majority of guests were clearly not understanding what they were seeing, and the overall exhibit could use much better signage to help you follow the progression. As it was, we started in the tractors and only slowly found the Newcomen at the rear of the exhibition. There was also no presentation of the motivating need for the various innovations, no attempt to show why these innovations were improvements on their predecessors. More than any specific invention, this desire to understand and solve needs is essential to any exploration of innovation.

Secondly, the museum only addressed Ford Motor Co and explicitly avoided the other car makers and broader industry. I found no mention of the significant resource booms Detroit set off in the Upper Peninsula and Minnesota. Similarly, while cursorily describing the assembly line the mechanical bits are frankly less innovative than the business and management systems that made them run. Including these would certainly expand the scope of the museum, but the hard part is the physical artifacts; everything else is just threading it together.

All-in-all, I'm looking forward to Automate 2024 in Chicago, hope to see you there!

Modeling Fireball's Vise Hammer

2023-01-16T00:00:00Z

Jason at Fireball Tool is a fabricator and a demanding tool user/builder; he's previously tested the failure modes of shop vises, which left him wanting a better shop vise, resulting in the HardTail vise. To show its capability, in this video he builds a vise torture test rig around a swinging hammer.

For this MonthlyMechanism I'll model the Vise Hammer in Modelica to estimate the impact energy applied to the tested vise.

Modeling

The Vise Hammer is inspired by his manual testing of shop vises, where he quickly tired from swinging 4 and 5 pound hammers, making his testing less consistent than desired. This experience gave him a starting point and a basic design objective of approximating a hammer swing while increasing the impact. For the hammer head, he found an old, 53lbf rock drill bit which he mounted on a 3ft arm swinging in a vertical plane. The basic design is then to raise the hammer head up and let its gravitational potential energy propel it into the vise under test.

While the shaft and pivot arms are readily approximated with simple shapes, I drew a quick, approximate model of the hammer head, shaft, and pivot arms in CAD by eyeing the dimensions and checking them against the approximate weights he gives. Of course, if you had access to the system you could take more detailed measurements but these will get us rolling.

The core of the model is the Modelica.Mechanics.Multibody.Parts.BodyShape, which allows arbitrary rigid bodies to be modeled from their moments of inertia. Vector $$r$$ locates frame_b with respect to frame_a and $$r_{CM}$$ similarly locates the center of mass with respect to frame_a. The inertia matrix is taken in frame_a for consistency.

BodyShape accepts custom moments of inertia.

Two revolute joints provide the driven and free rotations, one between the fixed world and pivot arms, and the second between the pivot arms and the hammer shaft. In order for the bodies to connect correctly to each other, I use explicit frame transformations instead of modifying their internal $$r$$ vectors. I added some light damping to the shaft's revolute joint to approximate the plain bearing he used.

One sore point of Modelica, and most physical modeling engines, is the challenge and computational cost of modeling contact. To raise the hammer the motor rotates the pivot arms until the hammer shaft contacts the second shaft on the pivot arms, preventing further rotation. I approximated this contact with a large backlash via the rotational ElastoBacklash2 element. In this, I defined a 20° sector where the shaft is in 'contact' with the second bar, leaving 340° of free rotation in the 'backlash' sector. The main implication of this is that the edges of 'contact' zone are softer than they are in the real system; I used a spring stiffness of 1e3N-m/rad and damping of 1e3N-m-s/rad.

This also means that I am not attempting to model the vise or the impact of the hammer on the vise, which prevents estimating the 'break' force of a particular vise. Calculating this maximal force is tricky because it requires some idea of the stiffness of the vise to understand how it will absorb the hammer's energy. While the hammer mechanism is pretty simple, the amount of contact between the various parts of the vise make it much more challenging to model off of eyeball measurements from a video.

Returning to the vise hammer, driving the pivot arms is a rotational speed source and an ideal gear with a 60:1 ratio. Neither of these matter, as their dynamics do not meaningfully affect the hammer's impact energy.

The resulting block diagram is pretty simple, with the fixed support located upper left and the hammer head lower right. BodyShape should be able to accept CAD files for animation of the CAD parts, but it or OpenModelica is having some unspecified error on *.dxf or *.stl files that I was not able to work around. Instead I used DLR's Visualization Library to render the CAD shapes in the (disappointingly poor) animation.

BlockDiagram of the Vise Hammer.

Results

The first result is the animation, which communicates the idea of the mechanism and suggests a couple areas for greater focus.

We clearly see the hammer rising under the rotational speed source and falling with gravity.

The next graph shows the rotation of the hammer shaft (revolute1.angle, red), kinetic energy of the hammer head and shaft (keImpact, blue), and the torque provided by the rotational speed source (revolute.tau, green).

Timeseries plot of the hammer shaft rotation (red), kinetic energy of the hammer head and shaft (blue), and torque on the rotational speed source (green).

We see that at impact the energy of the hammer head and shaft is 485J. As noted above how the vise absorbs the energy is the key to passing Jason's test. If the point of impact on the vise deflects by 1mm, the vise needs to withstand $$ 485J/1mm = 485kN = 109,000lbf $$ and that sounds expensive. Adding compliance to the vise so that it deflects by 1cm similarly reduces the force to a more manageable $$ 10,900lbf $$. Beyond these basic estimates, a FEA simulation of the vise body and part being struck by the 485J would more clearly show how the energy travels through the vise.

Returning to the graph, I'll close by pointing out the severity of the post-impact collisions between the hammer shaft and pivot arms, visible in the revolute.tau torque curve. Though reduced by the chain transmission from 1946Nm to 32Nm, the gears in the gearmotor may still be seeing a torque 6x larger than required to raise the hammer. If allowed to continue this would lead to failure in the gear teeth.

Files

I wrote this model in OpenModelica using the DLR Visualization Library. You can download the model file and CAD parts from Github.

Wrapping up

I love ad-hoc engineering and building, and it's pretty clear that Jason does too. It's fun to go straight from idea to prototype, but metal fabrication takes space, tools, and material, making it less accessible. It's also clear that today's software prototyping tools are not as capable, fast, or satisfying to use as those in physical prototyping; my hope is that we will soon get to a place where they are that capable. If you want to follow Mechanomy's efforts towards this, please subscribe to see next month's post and share and comment on Twitter or LinkedIn. And if you want to help, please say hi.

RapidSlide Adjustable Wrench

2022-12-12T00:00:00Z

With Christmas coming this Monthly Mechanism looks at a former gift to anticipate the challenge of shopping for and giving tools.

One of the perennial frustrations with a adjustable wrenches is dialing in the right jaw position so that you can snugly grip the bolt while also being able to index the wrench to the next face. Crescent's RapidSlide adjustable wrench attempted to solve this by using a lever to move the jaw:

As seen, the idea is that the sliding lever is an easier and faster way to move the jaw than the typical thumb screw adjuster. This wrench was handed down to me, so I don't know its history, but the absence of marring on the jaws suggest it's had an easy life. On use, however, the the lever barely slides and grinding can be felt and heard in the mechanism, preventing quick adjustment.

Disassembly

Removing the slide and jaw screws, where the standard wrench has four parts (body, upper jaw, thumbscrew, lock screw), this appears to have 19.

Crescent's RapidSlide: a sliding lever drives a high-angle helical screw to rotate a bevel gear which turns a screw to index the jaw.

Of these parts, most are poorly made, with surprisingly rough machining visible on the brass dust cover tube and slide drive screw. There is a significant burr on the dust tube which may be leftover from manufacturing or it may be created by the movement of the slider pin. This burr can be seen on both the outside and inside of the tube, with the inside burr potentially impairing the screw's opposing rotation.

Note the burr on both edges of the dust cover.

Reassembling the slider and screw, we can see that the screw is bent towards the gear, such that the slider pin engagement changes over its travel which causes the output gear to wobble. This wobbling significantly changes the engagement between the gears, leading to occasions of skipped teeth when the gears are too far apart. Opposite these disengagements, the gears may be too close, leading to over-engagement and jamming of the angled bevel gears. This is the grinding, binding feeling on the slider because when the screw cannot turn, the slider pin stops sliding in the screw slot. And once stopped, continued force on the slider pushes the pin into the wall of the screw channel, bending the screw shaft and possibly raising a burr on the edge.

The screw is bent, leading the output gear to wobble.

Design

Consistent with the manufacturing defects, the mechanism design is flawed. On this 1" wrench, the slider slides approximately 2.5" to move the jaw through 1" for a reduction ratio of 0.4. With this 0.4 ratio, we would normally expect that forces applied to the slider would increase by 1/0.4 = 2.5x at the jaw to give a reasonably strong grip on any bolt head.

Looking more closely, the slider screw has a pitch of approximately 0.545"/rev and a diameter of 0.25", for a helix angle of 34°. This means that less than half of the slider force is actually used to turn the screw, undermining any force gain. That is, the jaw force is less than is applied to the slider due to the screw's inefficiency as over half of the applied force is lost pushing against the screw's supports.

The slider screw has a pitch of approximately 0.545"/rev and the jaw 0.228"/rev, leading to a 0.4 reduction ratio.

Market Failure

Looking today, this tool is not mentioned on Crescent's website but it is being sold by their parent on Amazon. While manufacturing variations do occur, YouTube has a 6 year old review that shows the same construction and manufacturing defects, though with better operation. This wrench really feels like a one-off prototype, not a tool from a storied brand.

Discount Gifting?

So this holiday season, if you're giving or receiving an innovative-yet-bargain-aisle tool, be prepared for some sloppy manufacture, for good ideas poorly implemented. But before returning, take it apart so that we all can see what makes a good tool good and a bad tool disappointing. And if you have comments, experience with, or backstory on this RapidSlide wrench, share it on Twitter or LinkedIn, and be sure to subscribe to see next month's mechanism.

Compression Springs

2022-11-03T00:00:00Z

In this #monthlyMechanism we write a simple Julia package to model compressive springs. Springs, of course, are a fundamental machine component and they are well-explained by mechanics. I'm using Fundamentals of Machine Elements as a reference, but many others exist.

The material and shape of a spring completely describe its function, which is summarized by the spring stiffness constant (spring rate) and calculated by

$$ k = \frac{F}{\delta} = \frac{G d}{8 C^3 N_a (1 + \frac{1}{2C^2})} = \left[\frac{force}{distance}\right] $$

with $$F$$ being the applied force, $$\delta$$ deflection from the unloaded state, $$G$$ the material's shear modulus, $$d$$ the spring wire diameter, $$N_a$$ the number of free revolutions of the wire, spring index $$C = D/d$$, and $$D$$ the coil diameter.

In Julia we start with a struct to hold these parameters:

struct CompressionSpring
  G::Unitful.Pressure
  d::Unitful.Length
  D::Unitful.Length
  Na::Real
  l0::Unitful.Length
end

I'm using the Unitful package to add unit handling to the parameters, which means that when instantiated $$d$$ can be given any length, from Ångströms to yards to centimeters

julia> a = 1u"angstrom" + 2u"yd" + 3u"cm"
18588000001//10000000000 m

and, given the vastly differing scales, is internally stored as a fraction until needed.

The spring constant can then be calculated:

function springIndex(s::CompressionSpring)
  return s.D/s.d
end

function springConstant(s::CompressionSpring)
  C = springIndex(s)  
  return s.G * s.d / ( 8 * C^3 * s.Na * ( 1+1/2/C) )
end

The spring parameters are significantly independent; given the wide variety of wire materials and diameters, and the ability to control coil diameter and number of turns, many spring sizes and constants are available.

As a quick example, here's how to model spring number 184 from WB Jones.

function jones184()
  G = 11.5e6u"psi" #zinc-clad "music wire" taken to be ASTM A228 high-carbon steel
  d = 0.016u"inch"
  D = 0.125u"inch" - d #convert from outer diameter to mean diameter
  Na = 11.9 #number of 'active' coils
  l0 = 0.75u"inch"

  return Springs.CompressionSpring(G, d, D, Na, l0)
end

The jones184() function holds the same information as a datasheet, and whereas datasheets are intended to be read and referred to, jones184() is meant to be used in calculations. For instance, we can calculate the force at a given displacement,

"""
  Calculates the spring force when deflected a distance `l` from the unstretched length.
  By convention this force is positive for compression springs and negative for extensional springs in tension.
  This function will issue a warning if the spring is compressed more than 85% of its length, where plastic 
  deformation is likely, or less than 15% where the force may be slightly inaccurate.
"""
function forceAt(s::CompressionSpring, l::Unitful.Length)
  f = springConstant(s) .* (s.l0-l) #as per convention, l0-l results in a positive force resisting the compression

  # See Shigley1996's definition on pg24.17
  if l/s.l0 < 0.15
    @warn "Spring likely compressed beyond linear region" s.l0 l f
  end
  if l/s.l0 > 0.85
    @warn "Spring only slightly compressed, calculated force possibly inaccurate" s.l0 l f
  end

  return f
end

f33 = Springs.forceAt(cs184, 0.33u"inch")

or plot the force/displacement curve,

Spring force is linear at k=6.05lbf/in

whose slope is the spring constant $$k$$.

And that is it for this MonthlyMechanism. I didn't have time to get into spring non-linearities, plastic failure, resonances and surge, or selection criteria...maybe next month. Until then, share on Twitter or LinkedIn, and be sure to subscribe to see next month's mechanism.

Renishaw Equator

2022-10-04T00:00:00Z

One of the joys of attending trade shows is seeing machines in-person; at IMTS last month I spent a bit of time looking at the mechanical design of Renishaw's Equator gauging machine and want to share some observations for this MonthlyMechanism. As I have some experience in delta robot design, here are some highlights and conjectures on the design of the Renishaw Equator 300.

The Equator is a delta robot for automated gauging of machined parts. Gauging is the measuring and comparing of a part against a known or desired baseline, and the Equator is designed for rapid gauging of parts in order to quickly discover any deviations and institute process changes. In their press videos, Renishaw shows an Equator stationed next to a machining center to gauge a freshly-machined part. If the gauging discovers tool wear, a wear offset can be sent to the machine to correct the next part.

The Renishaw Equator 300 automated gauging machine with principal parts called out.

The basic task of the delta robot in the Equator is to move the probe around critical features of the part while measuring the deflection of the probe. Since any deviations between the commanded movement and the probe measurement will be attributed to machining errors on the part, the robot needs to be extremely precise while moving over a large volume. The designers, then, likely had design goals on probing accuracy and probing speed.

To achieve this, a delta mechanism is used. Delta machines are designed to guide a platform in pure 3D translation within some volume. Notice in the prior figure the light green polygon, which, in the absence of camera perspective distortion, would be a parallelogram, having two pairs of parallel sides. As the platform moves the angle of the parallelogram will change, but the stiffness of the four links ensures that a single angle can describe the entire linkage. When three of these parallelograms are placed around the moving platform, each parallelogram controls a degree of freedom. Before assembly the mobile platform has 3 translational and 3 rotational degrees of freedom; adding the parallelogram linkages remove these three rotational degrees while permitting the translational degrees.

Detail of the moving platform and probe.

Looking more closely at the moving platform, the construction of the spherical joints can be seen to be a cup element on the rod end which caps a spherical standoff on the platform. It should be clear that the rotation between the rod cup and spherical standoff is limited by when the cup runs into the edge of the standoff. The spring controls a rod's rotation about its axis, thereby keeping the rod cups approximately centered on their spherical standoffs. It also likely permits the spherical standoffs to escape the rod cups if the platform or probe runs into an unexpected obstacle or if either are bumped during part placement, possibly avoiding machine damage.

During operation, the brochure lists the 'comparison uncertainty' as ±2μm. I haven't found the definition of this term — I don't believe that it is the absolute positioning accuracy of the probe tip — but even if this is just the open-loop repeatability of the probe location to a prior run, that is an excellent achievement to holds over the entire workspace. If we take it as the feature size that can be detected by the Equator with a suitable scanning probe, we might infer the blue triangle drawn in the figure. In order to be able to detect ±2μm translational movement at the probe tip, the angular deviation of the platform must be significantly less than 1e-3° while moving. That is, its movement is rock solid under the small probe contact loads and repeatable after gross translations while under large acceleration forces. I'd really like to see a technical presentation on the mechanism dynamics.

In normal operation the robot moves the probe about the part's critical features, comparing the deflection of the present part against the reference. This movement is driven by three actuators which are positioned between the parallelograms. This is the most striking design decision because it increases the part count and, at first glance, does not clearly improve the machine's performance. With a little time I've thought of a couple of possible benefits, but it is hard to gauge how much of an improvement any of these may make.

First, actuator forces are applied inside the spherical standoffs of the parallelogram linkages. Directed this way, the actuators have a smaller moment arm by which they may induce platform rotation, thereby permitting greater accelerations. Additionally, with the actuators split from the parallelograms, their forces are inherently shared between parallelograms, improving platform stability.

Second, while introducing additional mechanism complexity, separating actuation from guidance may permit larger spherical joints to be used on the platform and base than if their operations were combined, again improving stiffness and permitting greater speed.

A third benefit to this separation may be that it enables the use of linear actuators which give more uniform movement and better position sensing than traditional architectures. The actuators feature a motor and transmission driving a U-shaped bar through what may be an Omega belt drive. Though difficult to see, the bar holds a Renishaw linear encoder strip to provide position feedback of the bar's position. The actuator housing is gimbaled to rotate about a single point on the base, and the connection to the moving platform likewise has a spherical connection (approximated by two intersecting revolute joints). This second significant design decision to use gimbaled, linear actuators was likely made in order to have better encoder accuracy over the workspace, as rotational encoders on rotating arms can have a double sine loss in accuracy over the workspace. This approach does require some clearance above the machine, as the the orange safety bumpers on the ends of the actuator bars move about, but that likely isn't a large concern when placed next to a machining center.

I'm still puzzling over one last feature which I haven't found a good video or diagram to illustrate, which is the rotation of the orange-capped upper arms to which the delta parallelograms attach. In the first figure, it is not the camera's perspective but the left shoulder/arm is actually at a steeper angle than the front. Now, as long as the parallelograms stay the same length and the shoulder blade movement plane is perpendicular to the original base plane, the mobile platform will continue to move without rotation. But shoulder blade movement shifts the delta robot workspace, increasing the total volume. I suspect that the shoulder blades are unactuated but spring assisted, so that when the commanded position is within the delta's workspace, only the parallelograms move, but on reaching the edge one or more of the shoulder blades will deflect to permit extra workspace. If it can be assumed that the delta linkages are at the edge of their workspace, then the same linear actuator encoders should also be able to calculate the shoulder blade deflection. That said, nothing about this design suggests sensitivity to cost and the shoulder blades may be individually actuated and measured.

Renishaw made a number of significant design decisions in their Equator 300 and 500, all of which are outside of typical delta robot designs. I've tried to collect a couple of reasons for these, but it would be great to have a Renishaw engineer explain their design goals and particular solutions. Moreover, the complexity and interrelated-ness of delta robots make them a really interesting system for design optimization, one we may return to in the future. Until then, I look forward to any comment on Twitter or LinkedIn, and be sure to subscribe to see next month's mechanism.

Both figures modified from these originals.

Announcing Composer

2022-09-09T00:00:00Z

When I first began Mechanomy I spent some time building composer.mechanomy.com, a web-based environment for simulating Modelica models. I've just turned it on again and invite you to try it, though it's still very alpha.

I thought that few engineers knew that tools like Modelica existed, and that if there were an easy introduction it would be a great point to start talking about how engineers use tools and what new ones are needed or possible. I still think that, but in developing Composer I came to see that the task was much larger than expected. This was made worse by the high quality of most engineering software, making it hard to provide enough value while bootstrapping.

Modelica is a challenging language to learn. Its development is driven by large industry and academics, with developers focused on simulation accuracy and scalability to very large problems to the detriment of usability and wider reach. For instance, one of the first steps in simulating a model is to collapse all of the equations into a minimal subset by removing intermediate variables. Most errors are discovered after this step, at which point it is very difficult to understand what equation(s) are incorrect and how they should be fixed. As far as I know all of the Modelica tools operate in this same way, because they are operated by engineers and researchers who have the ability to understand, avoid, and work through the originating errors. But speedbumps for some users are mountains for others. The more I worked on Composer and worked with Modelica, the more it became clear that it was going to be too difficult to get new users up the mountain. This left Composer alpha-quality and without a plan to provide value to users.

It (still) does work: you can write and edit Modelica models, save them to your profile, simulate them, plot their results, and create links to models. For instance, July's TensegrityTable model can be simulated in Composer, generating both timeseries and xy spatial graphs. (It may take some minutes to solve on the server, and there is a hard limit on the result size.) You can even download a CSV of the results for additional analysis.

But the use case fell apart during development and so I've left the Composer on pause for three years, working in Julia to build tools and libraries that allow early system exploration, trading Modelica's accuracy for Julia's ease and flexibility. I still see a need for greater use of Modelica in engineering, and it's been heartening to see other efforts at web-based Modelica, but more groundwork needs to be performed before that track can be laid. For now, let me reiterate my hope for the convergence of Modelica and Julia.

I'd love to hear any thoughts on Composer or what tools you hope for in the future. As always, please share and comment on Twitter or LinkedIn, and subscribe for future posts.

The value of intermediate sketching

2022-09-07T00:00:00Z

What tools do engineers have to explore new ideas?

That is, once you have an idea in your head, what tools do you use to evaluate it? Most hardware engineers turn to sketching and CAD. Sketching (on paper, whiteboards, in CAD) fixes basic concepts and relationships, allowing engineers to focus on particular details, often those required to create a conceptual CAD model. However created, the first conceptual CAD model often becomes the basis for subsequent work, appearing more professional than hand sketches while better communicating the idea to diverse teams. This leads to a problem in that the CAD model has fixed a variety details that have not actually been decided by the development process; while the key ideas are in the originating sketches, at this early stage everything beyond these in the model is mere consequence.

Mechanomy believes that if engineers had additional and better tools for intermediate system sketching and analysis, developments would proceed more quickly while also generating artifacts (plots, models, etc) that contain only the key information that has actually been considered by the development team.

As needed by Moover

The Moover project is an example: at the core of each variant is a fundamental design sketch which contains the central design trade. These master sketches were drawn in CAD only because of the lack of other tools (our Geometry2D and BeltTransmission are first steps towards remedying this particular case). Moover was chosen for development because of this simplicity. Not many systems are reducible to a single sketch, but it can be said that a major objective of development is to identify the design kernel and understand its properties.

Section of the CylindricalTwisted variant at the carriage midplane, looking from the return pulley towards the drive. The section bisects the larger and smaller coupled pulleys. Silhouettes of the idler pulleys are overlaid, with the return pulley over these. The belt segments have vertical cross-sections at the return pulley, twisting 30° counter-clockwise to meet their respective idler pulleys. The idler pulleys position the belt to engage the smaller and larger coupled pulleys to form the differential belt transmission.

The sketch above is the kernel of the CylindricalTwisting variant, it contains the essential geometric relationships that communicate the belt between the horizontally-oriented drive and return pulleys, and the inclined coupled pulleys and idlers. Transmission performance, belt engagement, pulley sizing, belt life, all are implicit in this sketch...but the CAD sketcher lacks any ability to provide data to subsequent analyses, instead every iteration must be manually checked for consistency and the results hand-copied into downstream processes.

New tools are needed

Stepping back, the virtue of sketching concepts is the ability to fix certain elements to communicate them to team members and free your mind to consider other aspects of the system. Hand-sketching is quick but hard to change, often serving as a canvas for imagining functions that are too challenging or tedious to draw out. Just as sketching a belt system by hand is made easier and clearer if you have a compass, libraries like BeltTransmission can enable the quick expression of new ideas, if they are available and known.

We're working on more tools that assist the early exploration of system designs, say hi if you'd like to hear more. While a CAD-like sketcher is not on our plan right now, I'd love to hear of any interest or motivating applications. As always, please share and comment on Twitter or LinkedIn, and subscribe to future articles.

Sketching Involutes

2022-09-01T00:00:00Z

Gears are foundational to many mechanisms, and it is the involute curve that is responsible for many of their capabilities. In this MonthlyMechanism we're calculating and sketching the involute curve.

Many references describe involute curves by analogy to a taut string unwrapping from a cylinder, and some depict a mechanical curve generator. But these physical approaches do not translate into CAD, often forcing designers to find a commercial gear for basic design work. This post derives the involute function from a circle, explains the geometry, presents a function to calculate a gear tooth involute, and compares this to a commercially-available gear.

Deriving the involute of a circle

Involutes are typically described as the points that a string traces when it is unwrapped from a circle or other curve. More useful is the property that every point on the involute is tangent to the involute and tangent to some ray of the generating circle. This can be seen graphically as:

As $$\theta$$ varies, points on the involute are mutually tangent to the circle.

Involutes are expressed mathematically as

$$\vec{I}_{\alpha}(\theta) = \vec{c}(\theta) - { \frac{ \vec{c}^\prime(\theta)}{|\vec{c}^\prime (\theta)|}} \int _{\alpha}^{\theta} | \vec{c}^\prime(w)| dw $$

with $$\vec{c}(\theta)$$ being a curve parameterized by $$\theta$$. In spur gearing the curve is a circle and $$\vec{c}(\theta) = [ r\cos(\theta), r\sin(\theta) ]$$.

Taking the derivative of $$\vec{c}(\theta)$$ with respect to $$\theta$$ gives

$$\vec{c}^\prime(\theta)=[-r\sin\theta, r\cos\theta]$$.

The magnitude of $$\vec{c}^\prime(\theta)$$ simplifies to $$|\vec{c}^\prime(\theta)|=r$$.

Putting those into the expression of the involute, integrating from $$\alpha$$ to $$\theta$$, and simplifying gives an equation for the involute of a circle in [x, y]:

$$ \vec{I}(\theta) = [ r\cos\theta + r(\theta-\alpha)\sin\theta, r\sin\theta - r(\theta-\alpha)\cos\theta ]$$

Plotting this while varying $$\theta$$ traces the involute, while changing $$\alpha$$ moves the root of the involute.

Varying $$\theta$$ generates the involute curve, while $$\alpha$$ positions the root of the curve around the gear.

Sketching

While the equation for an involute is essential, we need some geometry to apply it to gear teeth. Gear teeth are symmetric, often described as having a width and height, and arranged at regular angles.

Let $$\gamma$$ define the angle of the symmetric axis and thereby the overall angular location of the tooth about the gear, $$\delta$$ the angular width, and $$r$$ the radius of the circle at the involute's base. With these, the root angles of the two involutes that form the gear tooth are $$\alpha = \gamma - \delta/2$$ and $$\beta = \gamma + \delta/2$$:

The tooth will be formed from two involutes, one for each flank, and so we need to calculate the starting and stopping angles for each involute equation. The starting angles are $$\alpha$$ and $$\beta$$, but the stopping angles depend on the tooth height, as measured along the symmetry axis. Calculating a $$\theta$$ that leads to a particular tooth height requires a bit of geometry, here's the basic setup:

We are trying to find $$\theta$$, knowing $$r$$, $$\gamma$$, $$\alpha$$, and the desired tooth height $$h_{tooth}$$. To do this we equate the radial distance of the top land of the tooth from the known $$r$$ and $$h_{tooth}$$ to the sum of the sides of the green and orange triangles.

The result is

$$h_{tooth} = r ( \cos(\theta-\gamma) + (\theta-\alpha)\sin(\theta-\gamma) - 1 ) $$

for the flank rooted at $$\alpha$$ or

$$h_{tooth} = r ( \cos(\theta-\gamma) + (\theta-\beta)\sin(\theta-\gamma) - 1 ) $$

for the other flank. To actually find $$\theta$$ from these, use a 1-dimensional solver (find_zero, fzero) with an objective function comparing the desired tooth height and that resulting from a particular $$\theta$$ guess.

At this point, we have $$I(\theta)$$ giving the x,y equations for the involute as a function of $$\alpha$$ and $$\theta$$, the starting angle $$\alpha$$ as a function of $$\gamma$$ and $$\delta$$, and a 1d optimization to find the stopping angle $$\theta$$.

Into CAD

The last step is to express these in a form that CAD can accept. CAD packages vary greatly in how they implement particular features, here I'll use Solidworks 2022.

Our target is the equation-driven curve feature, which accepts curves in $$x$$, $$y$$ parameterized by a variable $$t$$ ranging from $$t_1$$ to $$t_2$$. This function has a major limitation in not being able to use file properties, instead these need to be attached to geometry within the sketch and then referenced through the dimension name ("al@Sketch1"). Angles are given in radians for $$\cos$$ and $$\sin$$, and you can see that I specified $$\alpha$$ in radians as a linear dimension to avoid a unit error. Also, despite exactly specifying x,y, the equation curve is interpreted relative to one of the curve endpoints and not relative to the sketch origin.

With those caveats, we have the ability to enter the involute into Solidworks and generate a 3D gear tooth.

The solid line of an involute rooted at $$\alpha = 17^\circ$$ leads off the circle, following the parametric curve $$x_t$$, $$y_t$$ between $$t_1$$ and $$t_2$$. Giving a construction line the length of 'al' in radians avoids a unit error in the equation curve, an intermediary step that enables part properties to drive the curve. The curve specified by $$x_t$$, $$y_t$$ is not fixed to the sketch origin, requiring coincident and tangent constraints.

The preceding figures of involutes were exaggerated to better show any geometry or plotting errors; more reasonable is a 32 tooth module 2 gear like this one from SDP-SI. For a metric gear described by module, number of teeth, and pressure angle, we can calculate the equation curve in Julia by:

using Roots
function calcThetaHeight(; r, gm, al, ht)
  htal(th) = r * ( cos(th-gm) + (th-al)*sin(th-gm) - 1 )
  fal(th) = ht - htal(th) #the objective function
  return find_zero(fal, gm + (gm-al)*2)
end

function printEquationCurve( gearModule, nTeeth, gamma=π/2, pressureAngle=deg2rad(20) )
  addendum = gearModule
  dedendum = 1.25*gearModule
  pitchD = gearModule * nTeeth
  r = (pitchD - 2*dedendum)/2

  toothThick = gearModule * pi/2

  delta = 2*asin( toothThick / 2/r)
  alpha = gamma - delta/2

  toothHeight = addendum + dedendum
  # p = InvoluteTooth.plotTooth( r=r, gm=gamma, dl=delta, ht=toothHeight )
  # display(p)

  thal = calcThetaHeight(r=r, gm=gamma, al=alpha, ht=toothHeight) #the find_zero function

  println("Equation Curve with r=$r and δ=$delta for a $nTeeth module $gearModule gear: ")
  println("xt = $r*cos(t) + $r*(t-$alpha)*sin(t)")
  println("yt = $r*sin(t) - $r*(t-$alpha)*cos(t)")
  println("t1 = $alpha")
  println("t2 = $thal")
end

Equation Curve with r=29.5 and δ=0.1065 for a 32 module 2 gear:
xt = 29.5 * cos(t) + 29.5 * (t-1.5175) * sin(t)
yt = 29.5 * sin(t) - 29.5 * (t-1.5175) * cos(t)
t1 = 1.5175
t2 = 2.0905

Excepting Solidworks' curve approximations, the resulting half-tooth, blue, is close to the manufacturer's model through the flank. They appear to use a smaller tooth height than calculated by the standard, but gearing is full of optimizations. The many textbook-quality descriptions of gearing are enough to produce a basic gear, but greater accuracy requires consulting industry standards. While the comparison to the manufacturer's model is favorable, the model should only be treated as an approximate representation of the real part.

The rear half of the tooth, in blue, was calculated and drawn from the equation curve output above. Ignoring Solidworks' curve approximation artifacts, the flanks match well while the calculated tooth height exceeds that of the manufacturer's model.

Wrapping up

Despite the many references that discuss gearing, all that I have seen gloss over the drawing of the tooth involutes by computer or in CAD. This presentation was brief but linked the basic equation of an involute to its use in generating gear teeth. The plots here were generated by my InvoluteTooth module and plotted via Plots.jl. Real gears have many additional features that were not modeled here, but I hope this post provides a quick starting point to drawing involute gears. If this left you wanting a more thorough treatment, reach out so that I know what to expand.

As always, comment on Twitter or LinkedIn, and subscribe to see next month's mechanism.

Moover Linear Stage Variations

2022-08-01T00:00:00Z

Two months ago I described the differential belt transmission in general terms; this month revisits it in our Moover linear stage project. This project explored several design questions through conceptual prototypes, each varying an aspect of the differential belt transmission. See the Moover project page for detail and video of each stage variant. After that, maybe have a look at our updated design tools and services pages?

As always, comment on Twitter or LinkedIn, and subscribe to see next month's mechanism.

A cross-section of the CylindricalTwisted variant, showing the significant belt twist after the drive pulley.

The Tensegrity Table

2022-07-01T00:00:00Z

For July's #MonthlyMechanism, we're modeling a tensegrity table in Modelica:

A tensegrity table made by Sphidget, click through to see a can displacing the table.

The tensegrity mechanism

'Tensegrity' is bit of a portmanteau implying the significant or novel use of tensile elements in some structure, they being essential to its structural integrity. I'd recommend clicking through to the tweet to see how placing a soda can on the top causes the structure to move.

Before jumping into Modelica, let's talk through what's going on in the above figure. Three ball-chains connect the corners of the triangular platforms, and in the center are two opposing arms joined by a fourth chain. The weight of the upper platform is borne by the two arms and connecting chain, with the outer chains keeping the platforms aligned through their tension.

If the tension in the center chain is increased, that increase is evenly divided between the outer chains. Similarly, increasing the tension in any of the outer chains will load the arms and center chain, and it will slightly affect the alignment of the platforms. As the loading on the top platform increases, so too does the tension in the center chain, and as long as the load is placed centrally the table should be able to support it. Off-center or moving loads challenge the mechanism and can lead it to adopt an alternate, non-table-like configuration. Describing these load limits and the zone of stability for a given table design and loading are some of the questions that a dynamic system model should be able to answer.

Modelica model elements

We're going to use elements from the MultiBody Dynamics package of the Modelica Standard Library 4.0 and simulated by OpenModelica 1.19.2. The ball chains will be treated as springs, with initial lengths and spring constants eye-balled to approximate the stiffness of a small ball-chain. The platforms and arms will be taken as separate rigid bodies.

Note that, at least for now, the use of rigid, non-beam elements in the platforms and arms prevents considering their contribution to the system dynamics. Thinking about the apparent stiffness of the upper platform to loads placed on it, I wouldn't be surprised if the center chain is responsible for 70% of the platform compliance and the two arms for the remainder. But other configurations are quite possible, with greater arm deformation and a stout center chain or with an even weaker central link.

We'll take the overall table height to be 100mm, the radius of the tip chains from the center to be 50mm, and the thickness of the platforms and arms to be 5mm. The upper and lower platforms are modeled as solid discs and the arms as opposing L-shapes, such that the center chain is 30mm in length.

To exercise the model, I apply an increasing force to the center of the upper platform, directed downward, with sinusoidal horizontal components. Many other loadings can be considered with a little fiddling to ensure they're applied to the platform as intended, but this is sufficient for now.

Block diagram

Modelica models can often be expressed graphically, especially at the system level. The graphic isn't quite complete, as a couple parameters are defined only in-text, but see the attached model text if you want to explore and simulate it yourself.

The block diagram of the tensegrity table model. The blocks are arranged somewhat like the mechanism, with the upper and lower platforms joined by the upper and lower rigid arms and central spring. The outer springs are located by rigid translations from the centers of each platform. Parallel spring-dampers are used to approximate the ball-chains. The loading is developed at the top-left into three world-forces applied to the center of the upper platform.

Simulation results

Graphically, the loading is:

The table is unloaded for the first 5sec, then Y adds an increasing vertical load while X and Z apply a rotating force to the platform center.

The table is initially unloaded, showing a jump to the initial solution and basic stability, followed by increasing motion and eventually a drastic reconfiguration.

The reconfiguration is quite telling, if you watch a couple times around t=38, the upper platform displays a significant rotational motion around the Y-axis, this is distinct from the circular translation from the XZ loading. This rotation grows until t=42, when the rotation of upper platform becomes too large for the outer springs to counteract, leading to the reconfiguration. (Note the video time is a little slower than the simulation time.)

Looking at the motion of the upper platform with time shows the jump to the initial solution and circular, horizontal motion, and then the reconfiguration to a lower-energy state at t=31.204s and vertical load of 338N (76lbs).

In the model's coordinate system, [1] = X, [3] = Z, and [2] = Y = vertical.

The load is applied at 5sec, with the vertical component loading the structure and the sinusoidal X and Z components inducing a circular translation in the platform (no torque is applied by the load). While the table hardly displaces vertically, the same load directed horizontally quickly leads to large motion, indicating that the table is susceptible to horizontal motions.

The springs show extension from the loading around their unstretched lengths...

The ball-chains are approximated with parallel spring-dampers, hence 'spd' for the center and outer 0, 120, and 240 degree elements.

...which result in spring/damper forces:

Note here a modeling error: the springs are exerting compressive (negative) forces while a correct model of the ball-chains would load them only in tension. If this were fixed the reconfiguration would likely occur earlier, as the table's rotation would not be resisted by the spring(s) in compression, nor would a spring resist the platform's eventual translation in its direction.

While we can see the moment of reconfiguration in all of these graphs, the design question is "how can I influence when failure occurs relative to the needs of my application?" This can be challenging to draw out though simple video or timeseries graph inspection.

A slight improvement is a spatial graph comparing simulations with different design parameters. In the next figure, the length of the center spring is varied by ±5mm, which has the effect of slightly changing how quickly the spring's force increases with the horizontal displacement.

XZ-plane trajectories of the center of the upper platform for three different center gaps.

Increasing the center distance reduces the horizontal stiffness, leading the 35mm to depart at a lower load than the 30 and 25mm spacings. This is also shown in the larger diameter trajectory of the larger center spacing, with the 35mm completing 26 revolutions to the 30 and 25's 27 revolutions.

Summing up

The above graphs agree with and bolster first-hand experience with this mechanism, but the larger value of system modeling is to have a ready-resource for what-if analyses, to have something at-hand that allows ideas to be quickly specified and tested to, at least, a first degree. For many systems, a simulation can be run faster than prototypes created or experiments conducted, augmenting a designer's intuition while encouraging better communication and system documentation.

While this system is simple enough that it could have been derived by hand, which would grant access to the algebraic equation of motion and enable classical dynamics, vibrations, and control analyses, physics-based modeling in Modelica extends to very large systems with thousands of degrees of freedom in a way that hand-derivation does not. Modeling physical systems involves many choices and approximations, understanding these and verifying their consequences are the kinds of tedious tasks that prevent more systems from being modeled. We're working on some solutions here, say hi or subscribe to keep in touch. And please share and comment on Twitter or LinkedIn as you prefer.

New Work-in-Process Packages

2022-06-22T00:00:00Z

One of the major annoyances of the startup stage is the need to focus narrowly, starting projects to satisfy an immediate need without a timeline for their completion. The following projects are already useful, yet their development and conceptual completion are unfortunately subject to the needs of our other projects.

Describing them here and developing them publicly on GitHub is a small way of sharing our work with the community of engineers looking for new tools. Pull requests welcome, but even more than that if you share our befuddlement that these sorts of basic packages do not exist already, say hi...

Geometry2D.jl

Provides structures and functions for basic planar geometry operations and shapes. The aim is to provide literal, descriptive functions that clarify the many, simple geometric analyses that occur in spatial designs.

Mechanics.jl

Structures and functions for Eulerian rods and beams, and basic energy analyses. These equations are not very challenging, but the repeated copying of equations from references introduces error and destroys analytical context. Hence the literal, descriptive function naming and abundance of types.

Materials.jl

Structures and functions for retrieving material properties for use in Mechanics.jl and elsewhere.

Again, these are very much work-in-process, any releases will be noted here in due course.

Differential Belt Transmission

2022-06-01T00:00:00Z

The differential screw and differential winch Monthly Mechanisms are relatively well and widely known but this month's mechanism is rarely seen: let's look at the differential belt transmission.

As conceived by Drachman, rotating the handle clockwise (in Fig1) lowers the x-ray imager.

Myron Drachman's 1943 patent appears to be the first description of the idea, wherein a closed chain engages two coupled sprockets on a carriage moving between two fixed, freely-rotating sprockets. The coupled sprockets differ in their number of teeth, and hence radii, such that their rotation causes the carriage to move.

As depicted, the larger sprocket has 15 teeth and the smaller 10, leading to a transmission ratio of 0.2. With this ratio, rotating the handle clockwise one revolution would lower the imager a distance equivalent to the radius of the smaller sprocket. In contrast, if the chain were fixed and engaged only with the larger sprocket, the carriage would move 3/5ths the distance between the upper and lower sprockets. Using a differential chain mechanism increases the vertical position resolution of the imager while decreasing the force required move it.

Analysis

To see this calculation, let's simplify the system to the two fixed, freely-rotating pulleys, and the two coupled pulleys of differing radii. The coupled pulleys and any necessary idlers are free to translate between the fixed pulleys, and all pulleys engage the same closed belt without slip.

Graphical derivation of the transmission ratio via instant centers.

The transmission ratio can be derived and visualized via the method of instantaneous centers: If we apply a translational belt velocity $$v_{belt}$$ to all pulleys and assume no belt slippage, the belt will make the larger pulley rotate with a velocity of $$v_{belt}*r_{larger}$$ and the smaller $$v_{belt}*r_{smaller}$$. As these rotational velocities differ, for the larger and smaller pulleys to remain coupled the carriage must move in the direction and speed indicated by $$v_{carriage}$$, or the belt must stop moving, break, or slip on one of the pulleys. This is depicted graphically by connecting the tips of the velocity vectors of the coupled pulleys and drawing a vector from the pulleys' center of rotation horizontally to the line.

From this, the transmission ratio is

$$ k = -\frac{r_{larger} - r_{smaller}}{ r_{larger}+r_{smaller}} $$

which can be used to find the carriage velocity

$$ v_{carriage} = k v_{belt} = k r_{drive} \omega_{drive} $$

and position

$$ x_{carriage} = k r_{drive} \theta_{drive} $$.

The leading negative sign in the transmission ratio indicates that the carriage moves oppositely to the belt segment engaged with the larger pulley.

Like the differential screw and winch, the transmission ratio goes to zero as the coupled pulley radii approach equality, but unlike those mechanism the closed belt or chain can be circulated infinitely many times, allowing very large ratios to be realized without limiting travel.

As with any belt, chain, or cable system, engagement of the belt with the pulleys is essential to the performance of the mechanism, as any slippage between the belt and pulleys shows up as unwanted carriage movement or lack of movement. As drawn, any loads on the carriage are borne by two segments of the belt to one of the rotatably fixed pulleys. The benefit is that $$F_{applied}$$ is divided between the two segments, allowing larger loads to be moved or doubling the carriage stiffness relative to a typical belt linear actuator.

In Use

Aside from a few citing patents, the differential belt mechanism does not appear to be used commercially in any machine. Why is this? Have you seen one in use? I'd really appreciate if you shared any sightings, take a picture and tag @mechanomy_ or send it our way.

The primary limitation appears to arise from the coupled pulleys, that a belt or chain engaging these must translate out of the plane defined by the fixed pulleys. In Drachman, above, the chain needs to translate towards the viewer to engage the smaller coupled sprocket and then translate away to meet the larger sprocket. While chains and belts are not designed for this binormal (perpendicular to the 2D plane of motion) bending and translation, round belts and cables are certainly capable of bending on arbitrary axes and would seem applicable to this mechanism.

Moreover, mechanism design is the process of understanding and making tradeoffs. The question isn't whether a belt or cable is designed for binormal bending but how the performance of the mechanism changes from this atypical operation; is the belt or chain's life reduced by 2 or 30% for a given system design? Later this month I'll introduce our Moover linear stage project which raises many design questions and sketches some answers, please stay tuned.

As always, comment on Twitter or LinkedIn, and subscribe to see next month's mechanism.

Differential Winch

2022-05-01T00:00:00Z

Continuing our MonthlyMechanism series, let's look at the differential winch.

The differential winch uses two reels of differing diameter and a pulley to create a large mechanical advantage.

At its core are two reels of differing diameter on the same shaft, with the ends of a single cable attached to each. Between the reels the cable circuits a pulley, onto which a load is hung. Note that reels are wound in the same direction: the cable winding on the larger reel lies on the opposite side of the shaft from the cable unwinding from the smaller reel. Turning the reels by their common shaft leads to the simultaneous winding and unwinding of cable from the reels, though at differing rates from their differing diameters. These differing rates slowly change the length of cable between the reels, raising the load if the loop length is decreasing or lowering it when increasing.

The differential winch uses two reels of differing diameter and a pulley to create a large mechanical advantage.

Taking the end-view and summing moments about the shaft, the radii of the larger and smaller reels can be used to find the torque-load relationship as:

$$ T_{applied} = \frac{F_{load}}{2} (r_{outer} - r_{inner}) $$

Also needed is the change in load height per crank revolution:

$$ \frac{\Delta h }{\theta} = ro - ri $$

Users generally want to know how 'hard' it will be to raise a given load, and as designers we want to understand how a differential winch compares to other options. Assuming crank operation, how hard to raise a load can be expressed as the ratio between the force applied to the crank handle and the weight of the load, with lower ratios being easier:

$$ \frac{F_{applied}}{F_{load}} = \frac{r_{outer} - r_{inner}}{2r_{handle}} $$

If we take the outer and handle radii to be 1, we can compare several winches:

Comparing the mechanical advantage for several winch arrangements as a function of the reel radius. Winch names are taken from Wikipedia.

While decreasing the reel radius of the straight winch can yield significant advantage, it requires decreasing the reel and shaft diameters and hence their stiffness in torque and bending, increasing the likelihood that the shaft will break under a load. The differential winch, because it operates on the difference between the reel radii, can be used with arbitrarily large shafts and thereby avoid shaft breakage.

In Use

One significant limitation of the differential winch is seen in the first picture, where the cable is shown as a single layer on the reel. In this design the distance the load may be lifted is limited by how much cable can fit on the reel before it is forced upon itself into a second layer. Additional layers away from the reel surface change the effective reel radius, thereby changing the reel radius.

A potentially larger problem from layering occurs in natural ropes and other cables with soft cross-sections, where layering rope upon itself under tension can lead to wedging between layers. This wedging, where an upper segment of rope is pulled between lower segments, can lead to irregular unwinding, especially at higher speeds. It can also disrupt subsequent layers, leading to greater wedging or to rope-crossing.

Have you seen or used a differential winch in-the-field? Take a picture and tag @mechanomy_ or send it our way. As always, comment on Twitter or LinkedIn, and subscribe to see next month's mechanism.

Following Mechanomy

2022-04-27T00:00:00Z

While bookmarks are reliable, we'd love it if you would follow Mechanomy on Twitter, LinkedIn, or via RSS feed. We post the same basic content to each: Twitter gets a post's headline, LinkedIn receives the headline and intro, and RSS distributes the full post.

Twitter

RSS

Monthly Mechanism: Differential Screws

2022-04-01T00:00:00Z

What happens if you put a screw inside a screw?

Today we're kicking off a regular series on interesting mechanisms, starting with the differential screw; a very compact mechanism for generating very fine motions. Their small size makes them a bit hard to spot in-the-wild, but these are commonly seen in precise positioners, able to scale finger-knob rotations down to nanometer displacements. For instance, ThorLab's nanoMax stages uses 3 differential screws to drive a kinematic stage with nanometer precision.

Differential screws are mechanically simple and very compact for their mechanical advantage, consisting of three parts related through two threads. They are usually seen in two primary configurations:

Parts A, B, and C interface through thread pitches tp1 and tp2 to form a differential screw.

In the left configuration, the internally threaded part A is assumed fixed, dual-threaded part B is rotated by some user, while externally-threaded part C is free to translate while prevented from rotation. The right configuration merely gives C the internal thread and B two external threads; other permutations are possible but often more challenging to produce. Parts A and B interface through thread pitch 1 (tp1), and B and C through thread pitch 2 (tp2).

Calculating travel

Converting threads per inch into length per radian, $$ p = 1 /(2\pi tpi) $$, rotating B causes it to translate with

$$ x_1 = \theta / tp_1 = \theta p_1$$.

As C can only translate, B's rotation also causes a displacement between B and C of

$$ x_2 - x_1 = \theta / tp_2 = \theta p_2 $$.

Rearranging we find

$$ x_2 = \theta (p_1 + p_2) = \theta p_{eff} $$.

This is rather hum-drum; where it gets more interesting is in the choice of the thread pitches. The 'differential' screw refers to the common case where tp1 and tp2 differ in their handedness, say tp1 = 24 threads per inch right-handed, and tp2 = 28 threads per inch left-handed. Representing right handed threading as positive and left as negative, converting units

$$ p_1 = 1/(2*\pi*24) = 1/150.7 in/rad $$

and

$$ p_2 = 1/(2*\pi*-28) = -1/175.9 in/rad $$.

Giving $$ x_2 = \theta (1/150.7 - 1/175.9 ) = \theta * 9.51e-4 in/rad $$, which for a full turn $$ x_2 = 5.598e-3 in = 0.151mm $$, all with two common threads.

Physically, we would see that turning B to the right (positive) causes it to translate to the right, while the left-handed threads on C would cause it to screw into B. If instead we had made tp2 right-handed and tp1 left, this would have produced a negative effective pitch, causing B to translate left and C to emerge from B. As it is only the thread difference that matters, it is trivial to make a table of common thread pitches and resulting, effective pitch:

Given right- and left-handed threads, the effective differential thread is calculated.

On the diagonal, right and left threads of the same pitch produce null motion: between endstops C will not move. Not shown is that differing threads of the same handedness will cause their 'addition', making C move faster than B.

In use

The long engaged length and typically fine thread pitch prefer lower viscosity lubricants than would be expected for a leadscrew. Backlash is less of a concern given the fine pitch, lubricant, and tens of engaged turns, but it still shows up directly on the output, as do any thread errors. The main design challenge is ensuring the guidance of the moving parts, that the coaxial alignment is maintained throughout the range without impinging the thread.

Comments? Find Mechanomy on Twitter, and send us suggestions for future monthly mechanisms!

Modeling Ideas

2022-03-29T00:00:00Z

Engineers don't often talk about why they do what they do. For instance, the heavy preference for wanting to see something work, whether that be physically in a prototype or virtually in a CAD model. What's obvious but unstated is that this preference is the most direct way to communicate a mental model of a potential system from one person to another. That is, mechanical design engineers are very visual, preferring to think in those terms so much so that communicating certain ideas non-visually is a significant challenge.

When I'm modeling something new, I have an idea in my mind that I think will work. This idea is not fully formed, I generally frame it as a suspicion which needs to be fleshed-out. I typically explain this as a balance; for my mind to be able to imagine something new I have to ignore certain obvious constraints, like the precise form of parts or their exact connections. Modeling, in the generic sense, is where I get to express these constraints because a sketch or computer can remember them and make them available to me for further mental simulation.

On the first pass I try to get the most basic parts of the idea down, typically the novel part of a mechanism or a graph I think is true. As soon as I'm able to see some representation of the idea, my mind jumps to imagining the mechanism in motion or the implications of the graph. I usually have a palpable sense that possibilities have been lost in this first expression, necessitating further takes. The challenge is that these later sketches are adding details to the preceding attempts, judged both by their consistency with the other sketches and by their honesty/truthfulness to the original, fading idea. Too often I have to include details that are incompatible with the original idea and preceding representations.

The resulting model is one of notions and compromises, it is always afflicted with a sense of loss, that this is only a crude representation of my first idea whose possibilities have been tempered by my instantiation. And I generally blame its crudity on my tools, my sketching or software. CAD software is especially though necessarily limiting here and only works one way: the holes line up or they don't. This forces engineers to waste time on trivial things like mates and fasteners rather than at some more abstract level. Hence the continued utility of sketching.

Breaking a complex problem into pieces is an essential skill, but engineers need help expressing the non-visual aspects of their ideas, especially when the idea is on the border of their understanding and experience. They need to write something down, but need to do so in a sufficient form that allows the idea to be communicated and explored by others with differing experiences without getting bogged down in irrelevant details.

And this is where our ideal2real modeling approach comes in, that in both Modelica and Julia we employ hierarchical modeling techniques that allow ideal models to be added and used to quickly get a first graph of the imagined performance, then for these to be replaced with more physically-realistic models that further develop the idea. We're looking forward to sharing more details on our approach and how it influences the design of some upcoming libraries...stay tuned. And please discuss on twitter or email.

Thoughts on Credible Modelica Models

2021-12-04T00:00:00Z

Today I want to share some thoughts on Leo Gall's talk from Day 3 of the Modelica Conference, on the "Continuous Development and Management of Credible Modelica Models" with abstract:

Modeling and simulation is more and more used in the design process in a wide area of applications. Rising demands and the complexity of modern products also increases the need for models and tools capable to cover areas such as virtual testing, design-space exploration or digital twins, and to provide measures of the quality of the models and the achieved results. In this article, we try to summarize the state-of-the-art and best-practice from the viewpoint of a Modelica language user, based on the experience gained in projects in which Modelica models have been utilized in the design process. Furthermore, missing features and gaps in the used processes are identified.

This paper is built on the SET Level project report Credible Simulation Process[pdf], which provides a hierarchical process description for what makes a simulation credible when used in virtual prototyping and in self-driving vehicle system design. I won't review either document here. The basic concern of the papers is how to communicate simulation context, its conditions and limitations, to a broader development process. For this they prescribe a hierarchical process that is generally well thought-out and appears to encompass many of the historical and expected challenges in simulation-heavy workflows.

I think the philosophical error is to treat things like simulation correctness and confidence bounds as things that need to be assigned from the outside, when in reality these are properties and results from the simulation. That is, if I'm simulating an electric motor, the terminal voltage is not ordained by metadata on the model input, but is instead determined by the thermal dynamics of the windings and other electrical connectors. My motor model is incomplete if these dynamics are not present, something that will become quite clear in the real when too large of a voltage is applied, and should too when simulated. But the power of simulation is that these effects can be turned off, according to the needs of the including model. For instance many models in the MSL multibody library have an optional heat port, where the model's thermal losses are summed and may be used to influence other processes. But the heat output can also be ignored, and that consequence is up to the user. How the model presents that consequence to the user is important; while I should see decreased motor performance above its critical temperature, a warning message or other auditable check may suffice, particularly if such a message describes its magnitude and thereby importance.

An electric motor is not at all on the same scale as a simulation framework for automated driving, and there are distinct benefits to identifying simulation limitations and assumptions from a hierarchical, simulation-agnostic perspective. More work is needed here, do say hi to discuss further.

Julia at the 2021 Modelica Conference

2021-09-20T00:00:00Z

Mechanomy develops physical systems models in Modelica, with Julia increasingly providing the pre- and post-simulation calculation and analysis (in place of Matlab or Python). We do the simple math and basic checks in Julia's fast and responsive environment in order to justify and focus model development in Modelica.

Coming into the 2021 Modelica conference, then, I was particularly interested to see a dedicated Julia session, one that I hoped would explain the relationship between these languages and show some examples of how the communities communities were benefitting each other. Let me sketch here what I think is emerging and where we're going to be putting some resources.

Modia & ModelingToolkit

The conference continued to dance around the question of how acausal Modelica models might be included in or at least run from Julia's scripting environment. I'll try to briefly describe the issue, but it's necessarily ill-defined and softly political. In emerging languages and voluntary communities, participants' good will motivates them to collaborate and produce compatible contributions, whereas more mature ecosystems tend to negotiate new features and improvements through deliberative processess like standards and steering committees. This necessarily limits coordination in favor of variety, permitting a vibrant, try-everything attitude while prolonging user questions of where to focus application development efforts.

One big focus from the Julia world is on the Modeling Toolkit (MTK), a set of packages that enable the modular, symbolic construction of partial/ordinary/etc differential equations into system models, their transformation between various forms, and their numerical solution via a leading number of differential equation algorithms. It uses some of the best ideas of the Julia language to deliver exceptional performance in a very easy to use environment, at least when it comes to differential equations packages. This performance and solver variety makes MTK an attractive basis for modeling physical systems, but so far MTK has not occasioned modeling libraries designed in familiar physics-based topologies.

This matters because while the original strength of Modelica was its acausal language and fast solvers, strengths that earned it a strong place in industry, today it has an inertia that will be hard to overcome directly. Julia and MTK improve on basically every technical strength, but to become trusted by engineers and industry they will have to tactfully and accurately outreach to the Modelica users to explain and substantiate Julia's capabilities and minimize the pain of switching to a new ecosystem. My off-hand estimate is that 70%[1] of Modelica users are using and developing it in the course of their regular job, which means that they find it productive and useful; at present there is far less value in the Julia community, but the energy is encouraging.

Modia.jl

The session got under way with Dr. Hildig Elmqvist's talk on Modia[pdf]. Hildig is known across the Modelica world as it was his Doctoral work that became the Modelica language and Dymola model simulation tool and has spent his career nurturing the Modelica ecosystem. He remains interested in the fundamental language design, and I'd say sees in Julia the chance to reconceive some of the core choices of Modelica. His and colleagues' work on Modia boils down to the creation of a domain-specific language (DSL) that allows Modelica-like grammar to be written natively in Julia. The Modia package converts this familiar interface into symbolic equations for ModelingToolkit's methods and algorithms. As a DSL, Modia can focus on the language design and leave the many, many details of creating and running the simulation to other packages.

The limitation is that existing Modelica models and libraries need to be translated into Modia, a simple process for simple models and an impossible process for complex ones, as Modelica has accumulated language features that Modia (and MTK) has not or perhaps cannot implement. That said, Modia includes a translator for Modelica models but its limitations are not recounted in the paper and will have to wait for a followup post.

The power of the DSL approach is really shown in sections 5.3 and 5.4 of the paper, where the authors describe use of the Measurements.jl package, which models measurement accuracy, and MonteCarloMeasurements.jl, which facilitates MonteCarlo analysis of complex systems, within a model that is familiar to Modelica users. As said in the paper, "Usage of the Measurements.jl package is attractive because, with very small effort, uncertainties of many variables can be defined and the propagated uncertainties of all variables computed in a reasonably efficient way." And likewise, "Usage of the MonteCarloMeasurements.jl package is attractive because, with very small effort, uncertainties of a reasonable amount of variables with large uncertainties can be defined for a large variety of probability distributions and the nonlinear propagation of these distributions is computed in an efficient way." That is to say that using Measurements.jl or MonteCarloMeasurements.jl allows the user to apply a known parameter distribution or to evaluate the effect of unknown parameter distributions on the model, operations that other Modelica systems are forced to execute in separate or external modules.

OpenModelica.jl

A more modest but more immediately useful effort was John Tinnerholm's presentation of OpenModelica's work rewriting the OpenModelica compiler in Julia, with MTK providing the interface to the equation solvers. As compared to OMJulia.jl, which is a simple Julia scripting frontend to a standard OpenModelica installation, OpenModelica.jl is essentially writing a Julia parser for the MetaModelica specification of the OpenModelica compiler.

The result is a Modelica compiler and simulation runtime that written in (autogenerated) Julia, instead of C, with MTK providing the interface to the differential equation solvers, instead of linking to their C binaries directly. This project is narrowly designed to allow Modelica users to run Modelica models in a Julia ecosystem, an approach that should allow maximum usage of existing Modelica resources, while gaining the speed and variety of MTK's solvers, and returning simulation data in Julia datatypes for subsequent analysis.

ModelingToolkit & JuliaSIM

Whereas the prior projects are directly addressed to Modelica users, Chris Rackauckas' technical talk, Composing Modeling and Simulation with Machine Learning in Julia[pdf] focused on Julia Computing's work enabling faster system designs via approximate system models, with no particular emphasis on Modelica. The talk had two aims: describe the continuous-time echo-state network (CTESN) approach to model approximation, and introduce JuliaSim, a cloud-computing product that features trained surrogates for a variety of models in a cloud environment facilitating immediate commissioning of cloud resources to simulate models in parallel.

CTESN's are an interesting way to solve one of the core challenges in physical system modeling, that of stiff systems which have events that occur at vastly different time scales (eg a microsecond impulse separated by weeks) or experience effects of greatly differing magnitude (eg a solenoid valve controlling a large hydraulic flow). Employing this approach on a building HVAC simulation, where an individual heater may be on for short bursts over the course of a year, the paper demonstrated large decreases in simulation time with very small reductions in accuracy; ie the CTESN approximation of the actual system equations is valid and useful.

Takeaways

The JuliaSim talk didn't really acknowledge or address the topic of Modelica model solving in Julia like the Modia and OpenModelica talks, a disappointing omission. One explanation is that the JuliaSim folks have come to the conclusion that the modeling and simulation of real, physical systems all but requires a massively parallel approach, with the implication that composing and running simulations on individual workstations is an inherently-limited activity.

Chris has sort-of said this, in response to a question on whether there will be a Modelica Standard Library for MTK:

The JuliaSim component library is a cloud computing product, and its curated model library will not be FOSS [free and open-source]. However, it is built using a lot of open source tools, and this tooling (ModelingToolkit.jl, Symbolics.jl, etc.) will continue to be open source. This includes a lot of model importers. For example, CellMLToolkit.jl, the work going on with SBML readers, etc. will continue to be available. And then there's a bunch of domain-specific academic component libraries in power systems, neuroscience models, etc. which are being built as open source.

With these tools we are scouring all of the academic and industry work we can find to generate a model library where everything is already converted to documentation Julia packages and a distribution network for handling the thousands of models, along with pre-trained machine learning accelerated versions of the models. That is JuliaSim, and of course that then becomes of a product given the compute and manpower required to maintain such a library, and hopefully that provides a value to the industry users who tend to be most in need of the pre-made models. That said, this does not preclude other standard libraries popping up, even in SciML, for specific domains and uses and all of that. In fact, we encourage the larger community to keep building open tools around the open tools.

--source--

If this is the argument, well this would have made a very interesting keynote. If that isn't the argument, then we'll just have to wait for the direction of these projects to become more clear. I do think the industry players are quite aware of what they need and are giving feedback (and funding) to all involved.

I am not too familiar with MTK but understand that it currently lacks the ability to model hybrid systems, those containing flow logic like for(), if(), when(), etc. This is a significant limitation by itself, but it was not mentioned by any of the talks as preventing general applicability, sounding more like a temporary impediment.

With all of that said, I'm looking forward to testing OpenModelica.jl and Modia.jl and watching their progress. I also need to do a deeper dive through MTK and to understand how its modeling approach and Julia's multiple-dispatch design may enable more flexible system models. One of the great possible benefits of moving to MTK for compiling and simulation is the chance to debug models more thoroughly, especially as failures in model translation are hard to connect to the originating modeling error.

Finally, though it was not a focus of the talks, Julia's git-based package system is really great; I'm hopeful OpenModelica's upcoming package manager

Comments, thoughts? Reply on twitter or email

[1]: Seriously off-hand: 70% feels right, but I would love for anyone with the real number to send it my way.

Tradeshows: Fabtech and Motion Power Technology Expo

2021-09-13T00:00:00Z

It was a joy to (safely) attend the Fabtech and Motion Power Technology shows after too many months of COVID. Attendance was a little depressed from two years ago, but I think the manifest supply-chain challenges of the recent past contribute to a feeling of urgency among manufacturers.

The big booths seemed bigger, with a greater variety of machines and capabilities on display that perhaps evinces the move to more integrated production environments and that the software ecosystems driving the machines are a greater source of differentiation than previously.

It also seemed that there was less emphasis on Industry 4.0 and internet-of-things than in 2019. While this is obviously due to the absence of the Automate tradeshow from this year's event, I'd venture that it also marks the slow maturation of these trends, that instead of being new they're becoming useful, no longer standalone but integrated into machines and processes.

The biggest omission of both shows may be the absence of CAM and other process modeling solutions, as I don't recall seeing any of the big or niche names. That is, I find it surprising that technologies that assist production staff and manage shop floor knowledge were not really present, as these have the potential of addressing some of the ongoing workforce challenges. It has been shown that processes are what separate leading from trailing firms, and with today's software technologies even small manufacturers realize the benefit of in-house software process development; I expected to see more recognition of this and more solutions.

I'm going to try to attend the Assembly and Wisconsin Manufacturing and Technology shows next month, we'll see if anything stands out.

Open Ventilator Design and Production

2020-05-29T00:00:00Z

One of the very interesting things about our response to covid19 has been to watch who responded, who felt both the need and the capability to help. Now, I don’t want to discount the admirable efforts of the formal healthcare system and its many practitioners, but I want to focus here on people that changed what they were doing and attempted to expand the capability of our society to respond to this pandemic. Seeing Dave Franchino’s post on open hardware design this past week, I’d like to express a few observations, to enumerate some of the breakdowns I saw and preview how my company Mechanomy is working to fix these issues for the next supply chain emergency.

Mid-March, I gave some thought to the improvised/open ventilator efforts and covid, looking to see if I and Mechanomy could help in a way that wasn’t nakedly marketing. I was quickly dissuaded by the disparity between the predictions of impending tragedy in mass media, necessitating significant action, and the lack of any formal engagement from healthcare providers and manufacturers. Locally, I saw a job posting as GE Healthcare stood up 2nd and 3rd shifts, but they were not seeking engineers or really attempting to change their product or design around supply chain shortfalls. Likewise there were no anesthesiologists or other practitioners explaining to the broader world what a ventilator needed to do, what features they can do without, and how they would vet or come to trust non-name-brand solutions.

(Of course it’s possible that both device manufacturers and health practitioners lacked the tools or institutional wherewithal to make a competent outreach to local communities, even the wide-scale donation of masks and protective equipment has been met by inflexible protocols[1]. It's also possible that they've done incredible, agile work in responding to this challenge and just haven't had time to tell the wider world how they've changed their work to respond to this unique situation.)

There were clearly public health reasons for strong messaging, but given the lack of understanding of the virus, its spread, and its effects in patients I think many stories reached for a simplified narrative: "Covid patients require ventilators and we simply don’t have enough, so STAY INSIDE and help save your neighbors." In this sense the number of ventilators and their supply is extraneous to the objective of encouraging people to take the precautions seriously and self-isolate. But incorrectly characterizing covid as a device design and manufacturing problem motivated the maker community to 'fix covid.'

The question that many makers, inventors, and entrepreneurs asked is: do we need to wait for our global supply chains to reopen or retool to the present need, or can we do something to lessen the impact of this pandemic? In most cases these creators had no relevant experience in healthcare, artificial ventilation, or professional product development, but they do have respect for the institution of healthcare and take it at its word: if the media says ventilators are needed, and ventilators are electro-mechanical-pneumatic machines, and I can make machines, then the only outstanding task is to get from the medical community the precise settings that they need. Voila, the ventilator shortage can be solved via off-the shelf and 3D printed parts assembled in my garage[2].

These efforts, organized through shared documents, forums, and hasty websites provide a fascinating but uncompelling look into the state of bootstrapped collective workflows. The Ambu bag efforts proceeded directly, drawing almost entirely from the participants' existing knowledge: knowledge of how to hack together simple machines and the awareness that manual respirators exist and are readily available. The primary ignorance was on the operation of the device, what air pressures at what rate need to be supplied to a covid patient. While these pressures are displayed on many ventilators, this clinical knowledge is not easily found outside hospitals or medical schools. That is, the healthcare institution controls access to information, dispensing it only to certain people in formal medical education and practice contexts. This approach differs significantly from the open access to information assumed and expected by ventilator #makers. There is no 'open medicine' movement to complement open hardware, or open software. This absence is dearly felt, responsible for the high cost of care in normal times and the recent failure to enlist local communities in responding to covid.

From a broader social/cultural lens, the ventilator shortage appeared to many open hardware makers to offer a chance at legitimacy, to show spouses/friends/communities/academia/media that clairvoyant makers and the open source ethos can help society. The high idealism of open source has sustained many projects but it hasn’t made the true believers wealthy or otherwise shown that open developments are superior at creating societal value. I am quite sympathetic to the argument and agree that an open ventilator would have been a good win for those suffering covid and for the movement, especially when compared to the recalcitrant approach of device manufacturers. But here too the open hardware approach has been stymied, quickly assembling devices that no practitioner is willing to use.

Medtronic’s release of drawings and bills of materials for their PB560 ventilator is insufficient, appearing mostly as an exercise in placatory PR. Drawings and bills of material tell you what to build and how to assemble it. Assuming you can purchase all of the subcomponents and custom machined parts, you can assemble and program your replica ventilator. But the limiting element of the ventilator supply chain is quite likely not in final assembly but upstream in the sourcing, production, and delivery of the 3rd party subcomponents. Global production has been severely impacted by the covid cessations, and because few of these suppliers are obviously or exclusively supplying the ventilation industry, may not have the supply chain transparency to see that their parts are essential for the covid response. (This is frankly the most important thing to know, where is the traditional ventilator supply chain limited and how can we overcome this?) Competing with supply chain ignorance, any awareness of covid-utility may be enough to prevent parts from leaving the producing country, in case that country is short of that particular element. Either way, no parts are incoming for the foreseeable future, no mater how many organizations attempt to produce a Medtronic replica.

Out of fairness to Medtronic, they simply can’t distribute their ventilator design. A product design cannot be pointed at, it is not a thing. Product designs do entail physical and digital documents, but an apocryphal 63% of the design heads home each evening. What Medtronic and the other ventilator companies could have done, were ventilators an actual problem that they desired to help, future sales notwithstanding, is (re)design a ventilator to be hardware-store producible. That is to employ their employees to design a new product that is maximally producible while still meeting the ventilation requirements. (Whether this is possible is the point of the effort.) The distinction is that a ventilator design is a series of choices made under particular requirements and certain supplier or manufacturing constraints that are eventually distilled into design documents and physical assemblies. The documents Medtronic released are useless because only Medtronic is able to use them to produce a ventilator. The design documents do not contain the series of choices and supporting context that is required to modify the ventilator design to use widely available machine parts. Now, engineers can review these documents and produce a mental model of the system function but, fundamentally, they do not know why the system was designed as it was and cannot be certain that matching the subcomponent specifications will produce an acceptable ventilator.

Mechanomy is a solution to the general problem of reusable system design, applicable here and in many other product engineering domains. From my vantage as founder, the open hardware community needs to move up the value chain to modeling the functions of ventilator systems. Modeling what a pump must do is inherently more valuable than modeling a particular pump; the first allows many pumps to be considered while the second cannot explain why it was chosen, only that it works. Especially in open developments, where team members may come and go and the development is not tied to the commercial success of a product, it is essential to have development systems that enable contributors to make the largest contribution they can. Sadly, today’s tools are insufficient to this task, costing too much to install and use while locking work product away in proprietary formats and brittle workflows. We are working to upgrade systems design and will have quite a bit more to say as our tools mature; say hi and we'll keep you in the loop.

There is much to be commended in the open hardware response to covid19, that thousands of people felt the need and ability to help respond to covid is a great cultural statement. It is also a watershed, showing how our ossified, fragile approaches to healthcare, engineering, manufacturing, and business need to improve to be able to robustly deal with the challenges and opportunities of tomorrow.

1] Hospitals haven’t shown much ability to adapt their protocols to meet the situation, e.g. retaining and cleaning disposable masks or inverting patients for gravity draining. There have been some stories but if they have adapted they’ve done a poor job explaining it to the wider world. Obviously they’ve been busy so I look forward to reading more.

2] This criticism extends to many manufacturers who also made Ambu bag ventilators. The point of being a product manufacturer is not that you manufacture random things, it is that you make what people need and want. In this case Dyson, Virgin, and others issued press releases and videos without studying their intended customer, producing only a flash of PR.

SodaShield

2020-04-17T00:00:00Z

Two liter soda bottles are made of clear plastic to show off the product. They're pretty robust, surviving shipping while internally pressurized to ~30psi with very few scratches, and are readily available in convenience and grocery stores.

Given reports of ongoing shortages of face-shields for personal protection, I realized that a clear 2L bottle could be adapted into a face shield in ~10 minutes; see my design at GitHub and below. Now, I have no particular competency at designing face shields but if anyone is facing a need for a face shield, this design is highly accessible.

The key feature is the use of the bottle's curvature to grip the forehead and to close the mask below the chin, as below. It lies close to the face, with room for a close-fitting mask, but larger respirators are unlikely to fit. As I've worn it air is limited to flow only around the chin, the close-pressing sides and complete forehead contact prevent flow through the top or sides of the shield. Visual distortion is noticeable below the waist-level, anything held chest-level and above will be clear.

Ben wearing the SodaShield

I would appreciate feedback or commentary from practitioners and would love Pepsi, Coke, or independent bottlers to join in meeting this need. If you know people in the medical community that may not have sufficient protection, send them a link. Stay safe everyone.

Rethinking Disposables

2020-03-19T00:00:00Z

One of the core motivations for our work at Mechanomy is the belief that many of today's systems are too complex. While complexity is inherent in every system, a significant portion is incidental to the core problem, added to the system by inefficient business, development, and production processes.

And it is this incidental complexity that the ongoing COVID2019 pandemic is particularly revealing: anecdotes abound of situations that, while defensible in normal times, appear unwise under today's more trying circumstances.

Take, for instance, CDC's notice that some 'expired' N95 masks remain usable. While only the manufacturer and the CDC know what actually limits the usability of a mask, it is likely not the critical element of the filter, but rather that the rubber gasket becomes less soft with age and seals less effectively. Sealing is a critical aspect of a mask, but it is one that might be remedied by tightening the face straps, etc.

When we look at the requirement to wear masks, then, we see that the requirement's sensitivity is not expressed, modeled, or known (publicly). We don't appear to know how the masks' effectiveness degrades with time: I would expect that, when new, a N95 mask (95% of particles are filtered out) actually filters, say, 98.5% of particles and that the 95% is only reached at the designated expiration date (the design life of the mask). That's a slow degradation curve, 3.5% reduction over, say, 3 years; if the alternative is no mask at all, that expired mask is still useful.

These are my conjectures; who actually knows this? Is this kind of information communicated on the product packaging or is it withheld so as to guarantee compliance with the manufacturer's directions and the maintenance of a particular standard-of-care?

It is simply amazing how many single-use disposable implements are employed in modern medicine. We have an open-loop system (meaning that it is trust-based, that there is no measurement of the result): implements are produced with a particular quality and as long as their packaging is intact, they're stored correctly, and they are used within their stated lifetime, they will remain in the expected or usable condition.

This pandemic is showing two key weaknesses of this usage model. First, the end-user is not able to verify the integrity of the implement; normally this is not an issue but when the supply is threatened the user cannot determine when something has expired. In the case of masks, there are reports of practitioners wearing disposable masks for multiple days, yet certainly the mask was designed for only x hours of use, meaning approximately x*b breaths and a total flow of x*b*f through the filter. As more flow through the filter will tend to erode the filtering medium, creating larger air channels, the mask's effectiveness should be expected to degrade...but what is this limit? CDC has some guidelines, but these do not appear exact. Instead of relying on infinite resupply, it would be really cool to have a smell-based mask-checker: the idea being to introduce an odorous substance into a controlled volume, so that if the mask wearer smelt the substance they would know that their mask is compromised. Filtration is more complex than this, but many odors are available [PDF]. In preferring an open-loop, disposal-first usage model, we have avoided developing or fielding mask verification tools.

The second weakness of the disposal model is that it is entirely opposed to reuse. In the case of COVID, how long do the particles remain active in a mask? Is it possible to clean the mask without damaging it or to wait, say, 7 days until the substances have died and then re-wear? When will the non-COVID contaminants become inert? Again, the disposal-first usage assumption resists this question and course of action.

When regulating the function of various systems, some regulations are essential to the proper use of the system -- how to adjust the mask to your face -- while others address externalities -- a new mask shall be used for each unique patient -- whose relevance can only be known by those in a particular situation. This demonstrates why it is important to model requirements, and particularly their sensitivity to various forcing functions in the course of designing a system AND to express that modeling to the end user so that they can understand when the context has changed. Inasmuch as the manufacturer's intended use case motivates the original requirements, truly robust designs tolerate off-nominal conditions in predictable ways.

Do hospitals and regulatory agencies model their requirements? Do they understand how these requirements constitute their standard-of-care and how do they determine when particular conditions can be relaxed to accommodate demanding situations? What conversations can the systems engineering community have with the healthcare industry to build more known and robust health systems?

Our mission at Mechanomy is to create known systems; while most of our time is spent in mechanical systems, our tools and approaches generalize to any complex system. We're happy to chat if you want to know more. Also, I would be very interested to hear if anyone has any anecdotes, @mechanomy_ or ben AT mechanomy.com.

Thanks to all on the front lines and, to everyone else, keep your distance!

Development Trends Survey

2020-01-15T00:00:00Z

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!

Telling the Future: Frank

2020-01-09T00:00:00Z

I appreciated Oleg Shilovitsky's vignettes on the future of system development and use; at Mechanomy we are also trying to enable this future of mass personalization and programmatic manufacturing. In turn, I'd like to tell you the story of Frank.

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.

Takeaways:

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 digital rights management 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!

Solving Modelica Models

2020-01-08T00:00:00Z

Continuing our tour, let's take a quick dive through the steps required to solve a Modelica model and simulate the system it describes.

First is the model text, the Modelica code you write to describe elements of your system and their interaction. Avoiding ambiguity requires strict adherence to the Modelica language specification, which in turn is developed by the Modelica Association to be able to model many different systems. The language has strengths and weaknesses, as do the standard model libraries, but the important part is that the language is standardized and versioned, allowing models to be written without strict dependence on the software tool used for writing them. And even when the model is primarily composed through a graphical layer, the underlying file format is text based and easily human readable.

To simulate a given model file, the tool will first check the syntax for adherence to the language specification, no rule-breaking allowed. If the text is syntactically correct, the next major step is to perform a symbolic simplification of the system. This step combines the equations in your model file and any referenced libraries into a single mathematical description of the system. This description often contains redundancies, that is trivial equations that can be removed for faster simulation. For instance, if a variable is initialized to zero and never modified, every occurrence of that variable can be eliminated from the other equations, and likewise for constant parameters. Removing these permits the identification of the number of unknown variables and the number of equations that may be solved to determine the unknown variables. These must equal; if there are too many unknown variables the system cannot be solved exactly, while too many equations implies an over-determined system, one that is trying to be in two places at once.

Fixing these modeling errors can take time, as it requires a lot of thought about the system and the implications of various modeling choices. One of the main limitations of computational modeling is that it doesn't produce the same sort of system knowledge that paper-based approaches tend to; a Modelica tool will not give you a free-body diagram. Instead, iterative model development and thoughtful system consideration is a dependable method to modeling many systems.

Continuing, correct model syntax and sufficient variables and equations produces a system of equations that can be solved to simulate your system. These equations can be solved exactly only very rarely, and only for the simplest of systems, to the point that Modelica tools do not include algebraic solution methods. Instead, as we are almost always simulating dynamic systems, numerical methods are applied that, essentially, solve the system incrementally at small time increments and thereby piece together the system dynamics over the desired time domain. These solvers use properties of the system equations to choose timesteps that are smaller than the modeled phenomena to try to capture all of the relevant behavior. Small timesteps, though, require many solutions of the system which each take a certain amount of time to solve. These add up and can lead to long simulation times and large simulation data files^[1].

Some systems will solve nicely and robustly, but more common are systems that have certain configurations where the solver is unable to find a unique solution. Typically referred to as singularities, there are a variety of reasons a set of equations may fail to solve under certain conditions. The common example is asking a robot arm to reach some point beyond its workspace; the finite length of the arm segments prevent solution of the equations, even though they can be solved for other tasks. These conditions are not always easy to identify, especially for non-physical models and current tools do little to explain this to the user. This also supports an incremental and iterative model development strategy.

Once these stages have been worked through, interpreting the results requires careful consideration. The best case is when you have data from a real-world system that you can use to validate and understand the simulation. But this is a bit like putting the cart before the horse, as much of our interest in simulating systems is to guide later development activities. Hypothetical system simulation is challenging because the results are highly dependent on the modeler's initial assumptions for important parameters like friction and the values of stiffness, mass, or other system parameters. We tend to start with the obvious: like making sure that system energy is constant (if frictionless) or decreasing, and that the general directions of motion are correct. The first timestep can be taken as a quasistatic solution; graphing this is often helpful for checking that the modeler's system conception is consistent. Beyond these cursory checks plotting or animating the simulation results allows exploration of the system behavior and evaluation of the system's suitability to the intended task.

More than this is up to the user. One of our common interests is evaluating bearing forces over the course of system movement, to check whether the intended bearing is sufficient to the task. These dynamic loads are only the start of a bearing analysis, but it is a good starting spot. Many more effects may be explored through any set of results, and it is also often interesting to explore how performance changes in response to slight parameter changes.

The non-physicality of simulations makes their creation and use in product development and system analysis challenging, with success or failure highly dependent on problem formulation and modeling strategy. That said, when done well a simulated system can provide a common reference to guide later development activities, allowing teams to see around certain corners and explore paths before investing in whole-system prototyping. As always, we're happy to help you save time by simulating systems, say hi to start a conversation.

The canonical example is on the heating and cooling of a building, where you may want to simulate building operation over the four seasons but individual heaters and air conditioners may only be active for minutes at a time. With 525,600 minutes in a year, if a solver solves the system once every minute using standard 8byte double variables, each variable will have a size of 4.2MB. With buildings often involving thousands of variables, result files quickly measure in the Gigabytes. ↩︎

About the name Mechanomy

2019-10-16T00:00:00Z

Mechanomy.

Mechanomy. Mechanics + -nomy, the system of rules, laws, or knowledge.

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.

A good name communicates the core of an entity; and at the center of our activities and interests is this pursuit of the knowledge of mechanical systems, recorded in forms that are maximally useful to the user, the designer, the engineer. We're not an academic journal, rather we think that too many development teams are swamped by complexity and the unintended consequences of previous decisions. We have some ideas about taming these challenges, say hi and stay tuned.

A Tour of Modelica

2019-10-14T00:00:00Z

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:

Wikipedia
Modelica By Example
OpenModelica and their overview slides and paper
Dymola

Merry Christmas

2018-12-21T00:00:00Z

We're just getting rolling, but are already looking forward to sharing our ideas and work in the new year. If you want to be kept up-to-date, say hi.

Mechanomy

Text to CAD?

What is Zoo's text-to-CAD application? #

Is the model correct? #

How does it work? #

On learning CAD #

Towards the tools of tomorrow #

Mechanomy's Fifth Birthday

Timesaving Solidworks Macros

addAxesXYZ #

export3mfStep #

importProperties2Part #

exportPartProperties #

AI Product Development

Where can LLMs, image generators, and other AI tools help design engineers? #

Combining concepts #

So can AI design products? #

1: No database #

2: No language #

3: No judgement #

#

Feeding the Machines

Interested in Modelica animation?

How you can help: #

Existing work: #

Validating product interest

How quickly can customers evaluate product suitability? #

First: make information correct, consistent, and accessible #

Second: standard use cases should sell themselves #

Third: develop and release simulations of real conditions #

In summary #

Automate 2023

The Archimedes differential traction transmission #

RB9 #

Airskin for Kuka #

Autonox Robotics #

The Henry Ford #

Modeling Fireball's Vise Hammer

Modeling #

Results #

Files #

Wrapping up #

RapidSlide Adjustable Wrench

Disassembly #

Design #

Market Failure #

Discount Gifting? #

Compression Springs

Renishaw Equator

Announcing Composer

The value of intermediate sketching

As needed by Moover #

New tools are needed #

Sketching Involutes

Deriving the involute of a circle #

Sketching #

Into CAD #

Wrapping up #

Moover Linear Stage Variations

The Tensegrity Table

The tensegrity mechanism #

Modelica model elements #

Block diagram #

Simulation results #

Summing up #

New Work-in-Process Packages

Geometry2D.jl #

Mechanics.jl #

Materials.jl #

Differential Belt Transmission

Analysis #

In Use #

Differential Winch

In Use #

Following Mechanomy

Monthly Mechanism: Differential Screws

Calculating travel #

In use #

Modeling Ideas

Thoughts on Credible Modelica Models

What is Zoo's text-to-CAD application?

Is the model correct?

How does it work?

On learning CAD

Towards the tools of tomorrow

addAxesXYZ

export3mfStep

importProperties2Part

exportPartProperties

Where can LLMs, image generators, and other AI tools help design engineers?

Combining concepts

So can AI design products?

1: No database

2: No language

3: No judgement

How you can help:

Existing work:

How quickly can customers evaluate product suitability?

First: make information correct, consistent, and accessible

Second: standard use cases should sell themselves

Third: develop and release simulations of real conditions

In summary

The Archimedes differential traction transmission

RB9

Airskin for Kuka

Autonox Robotics

The Henry Ford

Modeling

Results

Files

Wrapping up

Disassembly

Design

Market Failure

Discount Gifting?

As needed by Moover

New tools are needed

Deriving the involute of a circle

Sketching

Into CAD

Wrapping up

The tensegrity mechanism

Modelica model elements

Block diagram

Simulation results

Summing up

Geometry2D.jl

Mechanics.jl

Materials.jl

Analysis

In Use

In Use

Calculating travel

In use

Modia & ModelingToolkit

Modia.jl

OpenModelica.jl

ModelingToolkit & JuliaSIM

Takeaways