ad astra per civitatem – to the stars through community
At Mach 30, you’ll often hear us use this take on the famous Latin motto, ad astra, because we want to enable the broadest range of people possible to be part of the spaceflight community and to contribute to our mission. A big, and sometimes insurmountable, barrier to entry for hardware project volunteers can be cost. If a user needs to pay tens or hundreds of thousands of dollars for engineering software licenses, you’ve just lost that volunteer. By utilizing open source tools, we ensure that everyone from the teenager with big dreams and a 3D printer to the retired aerospace engineer gets an equal chance to come alongside us.
Going hand-in-hand with open source software, is open standards and open data access. If Mach 30 can’t share things like CAD models, mathematical analyses, and research results with the broadest possible audience, we’re blunting the power of community. To see an illustration of this in action, see our recent blog post in which Mach 30 Reimagines The Martian with Open Source. By broadening access, we ensure that the weekend warrior working in her garage can reach us with her amazing ideas.
Up until recently, I had feared that Mach 30 was alone in thinking that the current set of open source CAD tools wouldn’t meet our needs. Then, I got an email announcing a new open source CAD discussion group organized by some members of MIT’s CSAIL lab.
Beyond just being impressed with the credentials of the attendees at the first video conference, I was struck by how dissatisfied the majority of them were with the current state of open source CAD as well. We certainly have a selection of open source CAD tools at our disposal (like CadQuery, FreeCAD, OpenSCAD, and BRL-CAD), which is great, but all of these tools seem to lack one or more fundamental components in the areas of stability, functionality, or UX (user experience).
If you don’t believe me, seat a CAD professional (on Solidworks, SolidEdge, Autodesk Inventor, etc.) in front of your choice of open source CAD tool. Even with training, you’ll see that they quickly become frustrated by the lack of what they consider basic functionality. I’ve gotten chuckles out of other CAD professionals before when I’ve mentioned my own efforts to use open source CAD for complex projects. Sure, there are individuals and small companies who use open source CAD, but I have yet to meet anyone who prefers the experience over a proprietary CAD package.
Modeling in CadQuery
When Mach 30 finds an area where the open source alternatives are lacking, we first look for a suitable existing project that we can contribute to. If we we’re unable to find anything, we’ll roll up our sleeves and build the tools ourselves. Currently, Mach 30 community members are direct contributors to the CadQuery CAD scripting framwork.
CadQuery has allowed us to do some very exciting things, such as driving the geometry for 3D models directly from the rocket science documented in our Mathematics Tool Kit (MTK). However, CadQuery is only part of the solution. We also need CAD and CAE (Computer-Aided Engineering) applications that are capable of things like assembly, interference detection, and analysis. Beyond just being capable, these applications need to empower the community member working with them to be productive so that their precious resource of time is used effectively and efficiently.
If we, as the broader Maker and Open Source Hardware communities, can hit the mark in the areas of affordability, data sharing, power, and usability with our open source engineering tools, we’ll increase participation and accelerate the already amazing pace with which open source software and hardware is changing the world.
So, what do you think? Are you happy with the state of Open Source CAD, depressed by it, or somewhere in-between? Are you able to make FreeCAD outperform SolidWorks or Autodesk Inventor? We’d love to hear from you about how you do it.
What’s wrong w/ NASA’s Vehicle Sketch Pad?
http://openvsp.org/
Thanks for bringing OpenVSP up William. That’s one software package that Mach 30 hasn’t been talking about, but should be.
I’m only marginally familiar with OpenVSP, but I believe it’s only designed for aircraft geometry and airfoils. It’s designed to allow you to create enough geometry to run simulations, but isn’t designed to give you manufacturable output. Please correct me if I’m wrong. If I’m right, that makes it non-ideal (or potentially unusable) for general CAD purposes. “General purpose CAD” in my mind means something like Solidworks (generate parts, constrained assemblies, dimensioned drawings, etc).
With that said, OpenVSP is a great tool that Mach 30 could be making use of in the future, and we didn’t have it in our original 3D CAD tools comparison chart. https://docs.google.com/spreadsheets/d/1LnicErJ5m22FS2-G0izdvBR0S_7_IFZKslYsM26Atw4/pubhtml
Jeremy, you have things about right regarding OpenVSP. I have used it at work. It is quite interesting, and I have been waiting for us to reach a point in our hardware work where we could apply it.
OpenVSP is a conceptual design tool used to visualize geometry and set up engineering analyses that need geometry as input. It is designed for aerospace projects (primarily aircraft, but I imagine it could be applied to rockets). However, you are correct, It is not designed to generate final engineering CAD models or the documentation one produces from them.
In many ways it is closer to Sketch Up than a CAD tool. It could be very useful during the early phases of design for future vehicles (or test artifacts) at Mach 30. It is uses parametric design, so it works well for rapidly generating and comparing geometries. But, we would still need a full featured CAD tool to move to higher fidelity analysis and to do detailed design.
While OpenVSP was intended for modeling aircraft OMLs, creative users have long used it for tasks far beyond anything the developers intended. OpenVSP was recently re-written and is dramatically more capable than before and progress remains fast. If you haven’t checked out v3, you should.
One key feature in v3 is user-defined components. OpenVSP now embeds a scripting language so users may develop their own component types described by their own parameters. So, it is certainly safe to say that OpenVSP isn’t just for airplanes anymore.
OpenVSP is really targeted at making it easy to build a conceptual design level model and connect that to engineering analysis. The models are parametric and everything is scriptable. If the models are appropriate for your use, then OpenVSP is going to be very difficult to beat. Models can be exported in STEP or IGES formats that any CAD program should be able to work from.
That said, if you’re concerned with fastener spacing, fillet radii, or the myriad of things that go into a detail design model for manufacturing, OpenVSP isn’t the tool for you.
The open source CAD offerings do need work. There are a bunch of separate efforts — so progress is diluted. Further, companies that rely on CAD to make money are generally satisfied with the options provided by commercial vendors.
OpenVSP has an advantage over open source CAD — we have a research and innovation mission to do things differently. We don’t want to be CAD. We aren’t competing with CAD. We think CAD sucks for the work we’re interested in doing.
Instead, though very different, OpenVSP is more a competitor to SketchUp, Blender, and a host of other innovative 3D modeling programs. The competition is to find better ways to do things than CAD can provide.
Thanks for the reply Rob.
I like the idea of taking a step back, and looking for better ways to do things. We shouldn’t alway keep doing the same thing simply because that’s the way we’ve always done it. At Mach 30, we’re very interested in better ways of doing things.
Mach 30 has to consider manufacturing in almost everything we do, so my thoughts naturally go to how you move a thing from design to manufacturing. I also have a design and manufacturing background, so it’s hard for me to think of not directly transitioning a model to manufacturing after analysis. That brings up several questions for me as a manufacturing person.
1. What’s the normal workflow with OpenVSP once you’ve found an optimal design and are ready to move towards the design being a physical thing? Does that never happen in your situation?
1.a. How do you hand that set of geometry off to another department who wants to do something else with the models (more analysis, refining/manufacturing prototypes, etc)? Do you just export STEP/IGES files for them?
2. Can’t things like fasteners and fillet radii have a large impact on certain types of analyses?
1. What’s the normal workflow with OpenVSP once you’ve found an optimal design and are ready to move towards the design being a physical thing? Does that never happen in your situation?
1.a. How do you hand that set of geometry off to another department who wants to do something else with the models (more analysis, refining/manufacturing prototypes, etc)? Do you just export STEP/IGES files for them?
‘Normal’ can vary from situation to situation. Certainly exporting STEP/IGES is a straightforward way. Something similar was done for the NASA GL-10 vehicle — back then we exported 3DM to Rhino which Bill converted to STEP or IGES to get to Pro/E. Detail design was completed in Pro/E and CNC molds were cut from the CAD.
http://openvsp.org/blogs/rob-mcdonald/2015/05/09/openvsp-put-to-good-work
On the other hand, importing STEP/IGES surfaces leaves them as non-parametric entities that are mathematically correct, but potentially not constructed the way a particular CAD user would have done it. So, it does not surprise me when organizations throw out models from one tool and rebuild from scratch when moving to the next tool in the chain.
2. Can’t things like fasteners and fillet radii have a large impact on certain types of analyses?
Sure, and some people spend a lot of time calculating intra-molecular forces. Did fastener spacing and fillet radii ever make a bad concept into a good one?
Should a launch vehicle use liquid, solid, or hybrid fuel? What should the length to diameter ratio of the vehicle be? How many stages should be used? Should the fuel tanks be stacked fuel on oxydizer, oxydizer on fuel, or nested within one another? Which components should be reusable? How should they return to earth (glide, vertical landing, splashdown)?
The output from a conceptual design process is not a design. The output from CD is a decision by management/customer whether to continue or cancel the project.
The GL-10 is amazing. I had not seen that post or video before. Thanks for sharing.
I think that distinction between “conceptual design” and “design” is important here. I had missed that in J’s comment above. I was coming at things in the post from more of a final design perspective, but as J mentioned, there will be a time when Mach 30 will need to utilize conceptual design tools.