An all too common issue at Dave’s house.
I’ve been with Autodesk for a bit over 2 years now, and one of the biggest benefits of working here is that if we can carve out the time to do so, we can experiment on some pretty cool stuff, and are given the tools to do so. One such example is MADCON, the “Make Anything Design CONtest”, where teams from our Global Product Support organization compete to… well design and make anything. There are some constraints and such that I won’t go into here, but it’s a cool opportunity.
Last fall I was approached by a good friend and coworker – Dave Lawrence – to join a team consisting of 5 other individuals from the Americas based Premium Support Services team. They wanted to address a common problem for disabled individuals which is often overlooked: getting the ‘mobility aid’ into the car. This was close to home for me as my grandparents both have walkers now, and a few friends have had chairs over the years. However, it is even closer to home for Dave, whose mobility aid is so difficult to lift that it limits him being able to take his son places after school. A lift would solve that problem, but the solutions on the market are all very costly, and often require significant modifications to the vehicle (which further adds to the cost while reducing resale value). The hope was that the team (bios are at the end) could ‘design’ a workflow to ‘design and make’ a chair lift from readily available parts.
We knew we needed a real-world case to work out the process on, so we set about gathering some basic info from Dave’s car and chair. This included a 3D scan of his trunk, a model of the car, some dimensions of the chair when collapsed, the weight of the chair, and a few catalogs of readily available parts and other bits of info. From there we abstracted the model down to a lowest degree of complexity we could for discussion purposes – limiting it to just a ‘S’ shape of sorts, where the chair would have to be lifted up over the rear bumper and dropped onto the avoid the ceiling, and land on the middle portion. That sounds easy, but the hard part is doing this with as few ‘moving parts’ as possible.
After several lively debate sessions among the team, we finally settled on a mechanism which is like a drawer that rotates, allowing gravity to do the work of ‘lowering’ the chair, and relying on a single wench to pull the chair up and into the cargo hold. In Dave’s case this is ok as pulling is easy for him and his family, the lifting is the difficult part. Other individuals might want to consider an alternative design such as the ‘boom arm’ or a fold out track.
The concept in action.
With our design settled upon, we started to refine our ‘sketch’ into a workable diagram. The design consists of a ‘sled’ which sits on a pivoting ‘L’. An electric winch will pull the vertical leg of the L, pivoting the assembly at the end of the horizontal leg of the L. This assembly sounds simple enough – three parts (winch location, vertical leg, horizontal leg, and a sled), with minimal variables on each (length of vertical leg, length of horizontal leg, slide distance, location of winch from the pivot). Piece of cake, right? Just build a digital model in Fusion 360, set the values, test it, observe the results, and find that happy medium where the materials are minimized, and the effective force maximized to ensure the design requires the lowest cost motor with the functions we need, and the result is as ‘low in the trunk’ as possible to maximize visibility.
Optimizing those variables is difficult, and for a team who hasn’t taken a physics or trigonometry class in years (too much of which I slept through) it’s likely even more difficult. If only we had a tool which could perform a series of tests on a parametric model to find the optimum values for us… It was about this point when the team looked directly at me and said, “you’re the generative design guy – can you solve this.” Mechanical designs are a bit outside my usual routines of space planning or automation, but I set about the task all the same.
The resulting graph.
First, I built a digital facsimile of the ‘car’, using simplified geometry. I created this as a single mass from a Fusion 360 file Dave shared, containing a 3D scan of his car. Then I exported the first STL file. This was imported into Dynamo, and I quickly deemed it ‘overly complex.’ Even after tweaking it slightly in Fusion 360 to remove detail (the goal being to simplify things for quicker computation in Dynamo), there was a scaling issue with the export. So I did a few more tweaks in a clean Dynamo graph by importing the STL, scaling it, adding a bit more mass to the roof, cutting half the model away (if it clears the roof on the left side it’ll clear on the right too as the car is effectively symmetrical), positioned it so the bumper would be in the negative Y quadrants, and saved it as a new STL.
Then I started my main graph; first up, I imported the cleaned-up STL and set up the visualization (edges as solid black and the geometry as a translucent grey). Then I created a cuboid for the chair using dimensions from Dave’s setup at home, giving myself an extra inch on the X axis so that we’d be able to set up the vertical portion of the sled as. I leveraged simplified 3D geometry as it’d be easier for Dynamo to compute, with only 6 sides vs 20 sides on the wheels alone. Geometric complexity can slow things down immensely. The cuboid was set in place at the ‘starting’ position, about 3” outside the back bumper. I then modeled a series of cylinders to represent the L bracket, with number sliders acting as inputs for the length of the horizontal and vertical legs of the L and put them in place. Next, I set up a series of coordinate systems, rotating from the origin coordinate system to the end coordinate system by 1 degree until I hit an upper limit, which I constrained to a number slider (because who knows how far this should rotate – I certainly don’t). I used this list of coordinate systems to transform the chair and lifting mechanism into place for the study of the rotating portion of the geometry. I then took the Z axis from the last coordinate system and used it to shift the chair at 1-unit intervals along the slide length.
With all the geometry in place and parametrically controlled, I was able to set any variable to a desired value and see if the geometry intersected the ‘no fly zone’ of the car geometry by use of a ‘Geometry.DoesIntersect’ node across each of the geometries in position. I also summed the length of both legs of the L to get a ‘total framing length’, and I grabbed the ‘final’ position from which I pulled the Z value of the maximum point of the geometry to get a ‘height once placed’ which serves as an abstracted means of evaluating the impact on driver visibility. With my basic geometry evaluations done, it was time to tackle the calculation of force required to lift the chair.
Since we have a lever, the force to move the object is equal to the product of the weight of the object and the distance from the object to the fulcrum, divided by the distance from the applied force to the fulcrum, or F2 = (F1*D1)/D2. This is complicated by the fact that our effective force from our winch is not consistent, as the location of the winch is static while the lever rotates about the fulcrum, so the effective force will be different at every moment of the rotation. To get around this I once again allowed Dynamo to simply calculate the force at each degree of rotation (so 110 or so values) and pulled the maximum value from that list. While there is likely a more effective means to computing this, I hadn’t used that type of math in 20+ years and was pressed for time, besides my graph was quite efficient to this point so I had the computational power to spare on a ‘brute force’ method like this. The resulting value allowed me to pull the ‘moment in rotation’ when the winch would be least effective (not shockingly, this was typically while the chair was on the ground or on the trunk, with very little variation due to the geometric constraints). I placed and renamed some watch nodes for my metrics, double checked for bad graph organization, constrained and double checked my inputs, flexed everything as much as I could, and exported the result to Refinery.
The results in Refinery
My first run was a randomization run, to test if the model is flexing well. This is where I discovered that I hadn’t put a test on the winch to confirm the wire didn’t sit somewhere in the middle of the engine block. A few graph modifications and a new export later I was ready to try an optimization run. A 20×10 optimization study ran quickly (less than 5 minutes) and gave me some promising results (albeit with most wrecking the roof of the car or the back seat), so I kicked off a bigger study of 100 generations with a population of 100 with a constraint to pass the intersection test. My graph running 6x at a time, and my CPU maxed out at 100% I went through my emails, messages, read the forum posts, and stepped out of the office for fika hoping I’d have some good results waiting for me when I returned.
About 30 minutes later I was 75% of the way through the run with great results indicating that we can configure the system to use a motor that is 1/3 of the size we’d budgeted for, while reducing the total length of framing to under 114 inches and sitting less than 15” above the deck of the car.
The MADCon project continues, with some further studies being done for adding an additional joint into the design. The team is also looking at production of the working prototype which I’m not as actively involved with, as the Build Space is a bit far from our end user, but parts are on the way and I’m excited to see how it turns out.
The final rendering.
Along the way I had a few ‘lessons learned’ which I thought I’d share:
- Build a plan before you begin. Sadly, my whiteboard with my ‘map’ was cleaned while I was at AU so I don’t have that work to share, suffice to say it was a live document which was updated as I went. This helps keep you on track as you go and will help you ‘pick up where you left off’ when the inevitable interruption occurs.
- Clean up, annotate, group and document your graph as you go. These basic best practices will not only help you progress and keep your logic clean and focused, but they will also make it easier to explain the ‘how’ and ‘what’ of your graph after your done and you need someone to check your math.
- Find someone to check your formulas before you place a single node – that might be as difficult a task as writing the graph itself.
- While Design Script is nice for calculating formulas, be sure to watch your units closely as they don’t go into or out of the equations.
- Data translation between applications always sounds easy but scale can be an issue – having a 10×10 cube in a 2nd import can help ensure all data was translated correctly.
Special thanks to the Wheels of Fire team for everyone’s contribution, the Dynamo and Refinery development teams for providing such wonderful tools, and the Global Product Support leadership who gave us the opportunity to work on the problem.
- Dave Lawrence: Designated Support Specialist out of Phoenix who focuses on our infrastructure products and has a knack for finding that ‘perfect workflow’ in the vast sea of interoperability.
- Viveka Devadas: Premium Support Specialist out of Boston who focuses on our building design products and is a thought leader for AR/VR in AEC.
- Louisa Holland: Designated Support Specialist out of San Francisco, who focuses on our infrastructure products and has literally written the book on mastering Civil 3D.
- Jeff Miles: Designated Support Specialist out of Novi who focuses on our manufacturing products and knows a ton about going from idea to built product in the best way possible.
- Jacob Small: Designated Support Specialist out of Boston who focuses on Generative Design and BIM, and does his best to read all the forum posts.