What is the weight of CAD team?

FIRST
#1

Hey, so I’ve been a CAD subteam head for 2 years, and 2022 was the first time I got to participate in a build season. I always wanted to bring the best results out of my subteam and help a bunch in the season but in the season I found out my team had little need in CAD, since they only needed us for quick sketching to measure general dimensions for the subsystems, and the rest of the planning and decisions was made by the mechanics subteam as they were building, and we weren’t involved. I imagined my subteam would help more in prototyping the systems and checking the ideas initially before they’re built, and later making an exact model of the whole robot which shows how the parts connect, and my subteam is trained enough to do so. I guess what I’m saying is I’m trying to find a good purpose for my team, but those things aren’t really requirements since we can still do very well without them. So should I just accept the weight of the CAD team is that small? Or are we just not using the subteam’s ability right?

furthermore, the people in my subteam also feel the CAD team is not as meaningful, so they don’t have enough motivation when they’re working.

Any suggestions or examples from your own teams would help. :pray:

4 Likes
#2

It can vary a lot between teams. I’ve seen team design process models that vary from entirely CAD free, to physical construction and back CADing only, all the way to full robot CAD being done and the robot being manufactured only after that happens. It really depends, and there are a lot of right ways to make a robot.

That said, your team will probably have more success making cohesive designs if your design team is a little more involved with mechanical. The people doing the CAD should have a fundamental understanding of the robot and it’s mechanisms. Your members will also probably have a better time and feel more engaged if you can set this up.

One suggestion I’ve got is to set up a buddy system of sorts, where design team members work closely with mechanical members in groups, especially during the prototyping process (CAD of prototypes with specific testing options is great!). Idk what the ratio of design/mechanical is on your team, but usually it pans out to around 1:4 for us. These groups can then work together and move more cohesively through the brainstorming, design, and build processes. It also helps a lot to have leading members who know both sets of skills, which is not always possible, but super cool when you can make it happen.

6 Likes
#3

I feel like my team has been on both sides of the spectrum, in 2019 and before my team rarely used CAD, and in 2020 the robot wasn’t really CADed until after it was built, then in 2022 we had almost the entire robot designed in CAD before it was built, and the quality of the robot that was designed in CAD was substantially better than the robots that were not. So for my team at least I feel that the utility of CAD is made much more clear.

Additionally you mentioned the problem of mechanical members making decisions without the CAD team present, this is not so much an issue on my team because we are a relatively small team so most of the CAD team are more just mechanical members who know CAD, but I’m aware that that wouldn’t work as well on larger teams, so I’m not sure how you would approach that issue.

1 Like
#4

I took a look at the pictures of your robot on The Blue Alliance. It looks like you have a turret. I don’t recognize it as one of the COTS turrets. It also looks like your shooter side plates are CNC-cut. If these guesses are true, how did your team manufacture those components? It seems hard to imagine manufacturing turret parts without CAD driving a CNC router or mill and possibly a 3D printer. There is some chance that the shooter sides could be manually fabricated, but it seems more likely that the cutting was driven by a CAD model.

I looked at video of a few of your matches from DCMP. I did not see your team climb at all. From the look of your climber, it looks like it was designed to get to the mid level only. Designing a traversal climber is a place where CAD can shine. While it might be possible to get component lengths, angles, and mounting positions right with manual calculations, the efficiency of CAD would be a game-changer.

Your team did well with Rapid React, but there was plenty of room to have done better. Sometimes good is the enemy of great and there is complacency after some amount of success. Whether designing subsystems with higher complexity and capability, designing everything more rapidly, or opening up precision advanced manufacturing, CAD is an integral part of the build process of the highest-performing teams.

2 Likes
#5

As others had said, having your CAD members be part of or know some mechanical things (and electrical, that can be important when mounting things or leaving space).

In my view, CAD is important in designing a strong, functional robot. Not only does it give one the chance to accurately measure and machine parts, you can visualize designs, or even make whole new designs on CAD without having to pick up a bolt in the real world. Of course, nothing beats physical testing, but even just having the ability to rapidly make new designs, especially in the prototype stage, is extremely useful. And for final assembly, having the whole robot in CAD allows one to first see the robot as a whole, see how everything moitns on together, and it gives the mechanical team a visual interactive design for them to follow when actually building the robot.

4 Likes
#6

While CAD has become very important for our team (we mostly fall into the “CAD it first” school these days) we don’t actually have a separate CAD sub-team. Members of the mechanical and electrical teams do the CAD work. That way, not only are we keeping the design process spread around to as much of the team as possible (and even those who don’t CAD have a part in that, we’re pretty much a democracy when it comes to design) but those who are doing the CAD work are also those who have the most intimate knowledge of what it will be used for and the responsibility of executing the finished design. It’s a process that works well for us, but we’re still not a huge team (about 35-40 active members across all sub-teams) so we can use that kind of democratic process without it becoming bogged down.

4 Likes
#7

330 operated with the CAD team running the show for the majority of the season. Strategy informs overall design…but then mechanical constraints inform us what the actual strategy will have to be.
CAD team determined what gets prototyped and when, what gets purchased vs manually machined or CNC’d, what previous robots will get cannibalized, what parts of the practice field need to be built more accurately, etc. All informed by how the overall robot CAD was progressing.

It seems like your team positions CADers more like drafters, which is pretty big Boomer Aerospace Company energy. FRC teams tend to work best when students are regularly working between subteams, and/or when subteams are minimized. Having a group of mechanical people not working together with CAD is IMO about the worst way you can build a robot.

I’ll take 100% CAD and no CAD at all over the situation you’ve described.

16 Likes
#8

Slightly snarky response:
It depends on what’s you’re feeding your CAD team, could be as low as a robot or so but as high as a few elephants.
Actual response:
I’m used to CADding a mockup, then creating a prototype based on that mockup, then using the lessons from the prototype to CAD the final mechanism, making any necessary modifications.
With 1-2 CAD people, generally CAD runs the entire season. Seems like that’s true for any less than 5-6 CAD people though? Not entirely sure what the limit is.

3 Likes
#9

CAD is ideally design. The fabrication team should not be making design modifications ‘on the fly’.

Imagine if Boeing did that for a 777.

No, if the part is correct in CAD it is correct on the bot. I think your mentors and leadership need to rethink the process of design and fabrication.

4 Likes
#10

I am sorry you feel undervalued.

Our team used to be a sketch cad then mechanical adapted type team. Some of that still happens but we now have a mentor who does a lot of CAD professionally and has instructed our team on some better practices. We are trying to be better with CAD. You will find that if you have more advanced manufacturing you will NEED CAD to take advantage of it. By that I mean CNC or 3d printing. IF the team uses more custom parts manufactured that way the CAD team will be indispensable.

It is also worth while to back CAD if the mechanical team makes adjustments or new parts you hadn’t done on CAD. This is for clarity of documentation which helps when presenting to judges for engineering awards.

I know that wanting to contribute to the team’s success is a powerful driver for a lot of students but there is one more benefit of doing the CAD and back CAD (if needed) that you may be missing. The educational value. A team may be able to make a working and successful robot without good CAD, or sometimes any CAD at all but no real world engineering shop will tolerate that kind of folk engineering. The CAD skill is vital for collegiate and professional success in mechanical engineering.

7 Likes
#11

@Shirziv could you describe what your team used as your design guide for your robot? You mention your team used CAD mainly to check general dimensions and the rest happened during the build. Was the robot built organically or was one CAD model, or separate CAD models, updated as things were getting built? What was the mechanics team using to guide how it all came together?

I’d recommend trying to collaborate more. Get the mechanics leaders involved more in the modeling and get the design leaders more hands on in the build/decisions. Maybe your mechanical teams see the software as challenging and don’t see how it can save you time and drive decisions. Maybe your team thinks the design team doesn’t have as much FRC knowledge/engineering experience as the mechanics leaders so they are leaning on them to make the key decisions that could be design led.

What has worked for us is moving kids familiar with mechanics into CAD in their second season, or when they are ready, to start learning design. This naturally makes the design team the top-level team to have more input on where the direction of the robot goes and how it comes together. It’s hard to be a good CAD designer without a good grasp on the mechanics and it’s hard to be a leader in mechanics without understanding how to plan and design systems. You can operate with a mix of both and we have in the past. Hasn’t always worked the best. I think @troy_dietz really summarized it well: working design secondary in the background sounds more like a drafting mentality.

5 Likes
#12

CAD being useful and important is driven by need (we need a CAD model to CNC this cool part) or culture (we see the value in planning out parts of the robot to an appropriate detail before we build it).

If the culture isn’t there, need can drive that change. For us, getting a CNC router in-house was probably the biggest driver in creating a sustainable core of CAD experience— when that’s how the robot gets made, anyone who wants to be involved with the robot learns at least a little CAD.

As Troy said, a firm split is also not going to be helping matters… it might be time for your CAD subteam to merge with mechanical if you can impact how things are done better there. Really at the end of the day, your team is building a (or a couple) robots. If you can demonstrate the value of full CAD on a subsystem, for example, that can be leveraged into more interest and faith in using it. Don’t be afraid to mess with the playbook.

Good luck, CAD is an awesome tool!

7 Likes
#13

Well yes I preferred not to mention, our turret was made in CAD, but still my team’s influence was just the initial shape and overall size, while the rest of the modifications and details was done by our mentor. I guess because it was our first season and we couldn’t be trusted enough with the CNC made parts. But I see now that’s one of our main problems since we really didn’t have enough understanding and experience in designing to such degree so that’s something we’ll need to improve before we can be more useful. Same reason why we couldn’t design a better climbing system, we didn’t have enough time to try design something that complex so we just reconstructed the climber we had for 2020.

#14

the weight of the CAD team depends on the team’s material property settings

17 Likes
#15

So the actual design was made based on the fact that the 2022 game had very similar tasks to 2020, since our team is low on budget and also not very experienced yet the plan was to reuse as many systems as possible from 2020, still we had to plan how to adjust to cargo, and that’s where the planning was done on the go.

Our mentors heavily guided the decisions since our team still has much to learn, and they didn’t really need cad to guide them.
So yeah I see how that would be a problem.
My main mistake up until now was thinking the CAD team should only know how to CAD, and instead of planning stuff ourselves we would have other subteams guide us what they needed a model of, but in reality there’s not enough time for that.

Thanks for advice, it is obvious now I should reshape my teaching program to develop my team’s designing skills and mechanical knowledge, as well as cooperation with the mechanics team.

#16

Thank you all so much!!! your replies are incredibly helpful, I got way more useful information and advice than what I was expecting which I can show my team to help us make better preparations for the next season.

As many here have pointed out, it is an important advantage to have CAD members understanding mechanical theory and design, my subteam still has little to none of that which must be why our mentors couldn’t trust us enough with all the planning and crucial details, our only advantage was experience with the software and geometrical thinking which I guess by itself isn’t much.
But still our communication with the mechanical team and mentors was weak.
I’m convinced now this is something worth awareness since we could play a big role in making a great robot if we construct our team strategy right.

My team is full of people who are still fresh to the scene and require more experience so all this information from the replies would help us grow in the future :+1:

1 Like
#17

Rephrasing a lot of what others have said already, with some of our own team experience:

CAD and “Coding” are both tools to implement a design. The actual exercise of doing the design, in theory, has nothing to do with the tool itself.

Design has to happen in order for an engineered product to get out the door. The tools used to bring the product from idea to design are often necessary in some regards, but strictly speaking aren’t really… required. A product can still go to market without using one particular set of tools.

In big engineering teams, you’ll get folks who start to specialize, even to the extent of being experts in taking the ideas of a design, and describing them using a tool. This has value, especially when doing manufacturing or design “at scale”. But for FRC purposes… the more useful thing is having the design skill, and letting the expression of the design through a tool be secondary.

In any case… if you have the ability… see about reorganizing or shifting the mindsets of folks into understanding their primary role is to design something good. As a secondary responsibility, you use a CAD tool to express your design in a way that can be manufactured.

I bring up “coding” because I see it as the same thing. The real important steps are doing the design of what your control logic needs to do - what autonomous routines need be had, how the drivetrain has to move, how the robot responds to inputs… you design all that (including an electrical system to support it), lay out a way to describe that control in software… but the actual act of typing software is nothing more than describing your design in a way that a computer can understand and execute. This is a key thing I try to teach my students: there’s a difference between being just a “coder” and doing the engineering work of software or controls design.

As an appendix: A few folks have called out the usage of the word “weight” in the title. For US english speakers, it’s a bit of an odd word (Like, I think I know what you mean - weight implying “impact” or “influence”… as in the idiom “throwing your weight around”). But I’m extremely curious what the word you were thinking of was - in whatever language is the one your brain primarily works in (guessing Hebrew or Arabic by your team number?). I know very little about other languages, but love learning the idioms and implications of other words, and how people express themselves. … sorry I’m rambling. If you have the original wording I am 100% down to dig into it because I think there is gonna be some fun linguistics here.

3 Likes
#18

Yeah I saw the title and was gonna say it’s about 900lbs because we have 7 people before realizing

#19

3000lbs. Wait, I think the bumpers are made of solid aluminum again, sigh.

This has happened way too many times.

5 Likes