How do you intergrate CAD more into the design process? Currently in the team I am on despite having a dedicated cad team (3-6 people) we can never seem to CAD before the build team actually builds. In a few situations, it ends up we have a design and the build team takes some inspiration from it, rarely do we design something that the build team actually uses, and most of the time we end up cadding after they build. I think I have come up with a list of problems:
How do we divide the CAD work up? It seems like a few of us do all the cadding and then put it together. How do we divide the work up more evenly so the work gets done faster and more efficiently?
How do we work with the build team more? Currently, the build team is not very interested in what we are doing and spends a lot of time prototyping on their own. How do we get them more involved in what we’re doing?
How do we get ready for the season? Is there any precadding the team can do to get ready?
And to a much lesser extent, how do we get acess to CNC machines? I feel that if we’re able to have use of those machines, mechanical will pay attention to us more.
edited for adding a new question.
It does not sound like your team is using resources intelligently. Do you have adult mentors on your team, one for CAD and one for Build? Is your team student run with no engineers involved? A team that is made up of students only can still be successful but there needs to be a project manager in charge of the overall project. The whole team should decide what the robot should do, not the build team. I think your team needs to define roles and responsibilites of all sub-groups. The CAD team’s job is to transform the design concept the team agreed on into a working robot on the computer through detailed design of its components. The build team’s job is just to fabricate parts and assemble based on the CAD model that has been virtually checked for interference, kinematics, weight, center of gravity etc.
We CAD our robot 100% before we make parts, usually around Week 3.
Early in the process, once you’re beyond the whiteboard sketch stage, break the robot down into sections (gearbox, drivetrain, arm, endeffector, etc.), and assign people (or small groups of people) to each one. Do a ROUGH model of the robot first, with lumps of material representing the space each mechanism will take up. Agree not to intrude into the space of other parts. Even if you don’t know all the details yet, you should have a basic idea of how each part will be constructed and structured. Then, quickly add detail where each subsystem intersects. This can be as involved as modeling the parts that connect them together, but often you can get away with simply specifying a bolt hole pattern. Once you’ve taken care of these intersection points, groups can branch off and independantly do detailed design for each subsystem. Inevitably, sometimes one or two of the connection systems you agreed on won’t work out. But as long as the appropriate people are alerted when this happens, this method will save you a lot of time, and allow a lot more people to get involved.
Another approach, more appropriate for managing multiple people working on a single subsystem is a “feeder” system. One lead designer is in charge of the assembly, and gives out requests for parts to be modeled. The lead designer then integrates everything into the assembly file, and requests small changes as necessary.
It sounds like your build team sees CAD as an “extra thing to do.” Make sure they understand the power of laying everything out on the computer, and making sure it’ll fit. Implement a (somewhat bendable) rule that parts that do not get CADded should not get built (though inevitably exceptions will and should get made.) Getting access to better machining helps with this…once kids see CNC’d parts, they never look back to bandsaws and drill presses. Short of that, be more dilligent about creating dimensioned drawings…They will not only get the robot built according to the CAD, they’ll get more people involved on the build team…it’s easier to hand a dimensioned drawing to a freshman and say “build this” than to say “Can you make the arm bracket?” “I wasn’t there for that, how’s that go again” “Well, we have two holes supporting the arm, and a bend kind of like…nevermind I’'ll do it.”
As far as prototyping, prototyping needs to drive your CAD. There should be a constant back-and-forth, with the build team updating you on discoveries made by their prototypes. They should be able to figure out key dimensions, such as wheel placement, shooter compression, linkage geometry, etc, from their prototypes. These dimensions can be fed right into the CAD, and implemented into the final design. If you make it clear to them that prototyping must drive CAD, but that CAD must drive fabrication, you will go far.
If you have people in mechanical who are dedicated, have aptitude for designing, and ignore you because they think their way is better…don’t fight them, get them to join CAD. It’s better for them in the long run to learn to use CAD if they plan to go into engineering, and it’ll give them a more effective way to channel their creativity.
You are not supposed to do any detailed design work intended for the robot pre-kickoff. However, that doesn’t mean you can’t use this time wisely. First and foremost, practice! Get faster and better at CAD, so you can keep pace with the demands of build season. Also, it’s good to develop a library of parts. Agree on standardization of things like bearings and fasteners, and create a library of COTs parts. For example, if your team uses a lot of a particular aluminum extrusion, create a template file for this extrusion, which can be quickly modified for your needs when you need the file during build season.
I would argue on the contrary to this point. I think many teams have plenty of members who have no business deciding what the robot should do. Getting the whole team involved seems like a good way to throw your efficiency out the window, and end up with a result that doesn’t please anyone.
I’m reminded of two things here
In a thread about a year ago, JVN said something to the effect of “We will never vote on a design. Voting is not an engineering decision making process.”
The new Dodge Dart commercials - there’s one line that says “Kick out the committees”
I do agree with the idea of “It doesn’t get made without a CAD model first.” That’s how real engineering is done. The machinist doesn’t just make it up on the fly.
When I said the whole team should decide, I never said it is by voting. I am talking about at the stage discussing strategy, what the robot should do. This is the time where we do not talk about design. Everyone on the team can contribute to this. You don’t need to know CAD or pneumatics or electrical or how to use power tools to discuss what kind of things you want your robot to do well and how to play the game.
The problem with only involving the build team or CAD team to decide what the robot should do is you will usually end up with something they have done or seen which is familiar to them. I see so many teams end up with designs that is not optimal for the game because it was “borrowed” from some previous years’ games. If you want a chance to have out of the box ideas, involve other people on the team.
I think we are talking about the same thing. It is probably just because of the words I use, so I am not disagreeing with you. I am just clarifying.
Here’s the deal – in the ‘real world,’ increasingly, the role of CAD team is played by the engineers responsible for the design of a product or system. It’s becoming harder to find places that have dedicated drafters that have design dictated to them by someone else.
If your team wants to mimic an environment where the engineers are also documenting their design with CAD tools, then it is imperative that your drafters know what they’re doing when it comes to mechanical design, design for manufacturability, etc. The ‘build team’ then builds what the designers have dictated.
If you want for the ‘build team’ to dictate design to the CAD team, they need to provide sufficient detail to the drafters so they can accurately reflect the build team’s intent. This is only useful is CAD tools offer something useful for implementation – drawings for machining, cutting, assembly, etc. Otherwise, using CAD to document a robot that was built off the cuff is worthless, in my opinion. Anytime you document a part after it’s been manufactured, your process has failed.
On my team, I’ve been nearly single-handedly responsible for all CAD drafting for the last seven years. Sometimes, others will draw simple parts for our laser cutter, but many of those parts are represented first in my CAD model.
I use CAD to examine more detailed problems than prototyping practically can manage – working out geometry of moving parts, packaging of things so everything fits in a place, minimizing part count by integrating functions and systems together in a way that makes the most sense, etc. CAD isn’t useful for determining how a foam basketball behaves when flung by a spinning wheel, for example, so physical prototyping is very useful there. Once the effectiveness of an idea is demonstrated, though, it is turned over to me to iron out all of its implementation details. An important part of that process is being able to identify which characteristics of the prototype are important to emulate and which can be changed to accommodate other features and needs. Actually – in reality, I am often designing a more complete version of whatever prototype my intuition tells me will be most successful concurrently to the physical prototyping. When I get it right, we save a lot of time; when I don’t, I just start over. No big deal.