What are the stages and tricks of robot design?

[EyupAkgun]

Hi everyone. I am dealing with some robot designs. I can design but I don’t take some things into account when designing a complete robot and it takes longer to complete the design. What stages do you go through when designing robots and do you have any tricks you can suggest to me?

[CuteRedpandas]

although i’m relatively new to robot CADing,

1. i’ll usually CAD the concepts of each mechanism
2. figure out how to implement each one onto a chassis
3. add electronics to figure out how they fit on the chassis

and something i wish i had done this year is cadded each bolt hole on the robot to allow for quick machining.

[candleman587]

the very big problem my team had this year is, Cading after the parts of the robot were already made. you never want your CAD to go behind the production of the robot. also you need to heavily communicate with your CAD team and your Fabrication team, there can be no details missing.

one huge tip i can give is, make a personal binder or CAD journal, right down tips, questions, concepts, ideas, etc…

but our stages are

1. Chassie (make sure everything is flush and perfectly dimensioned)

2. we then put our main design on top of it for example an arm or some shooter mechanism

3. we put in the electronic boards

4. if we had any last-minute things we wanted to add make sure you make the cad for those things FAST

(PS: I can’t stress this enough but, MAKE SURE EVERYTHING IS APPROVED BY YOUR LEAD CAD MENTOR OR CAPTIAN!)

Cad has a huge learning curve to it. the more you do it the much easery it become. don’t stress your self on one part because in time you will find out the answer to your problems with more experience.

i made my own personal cad account for tests, designs, and just dumb stuff, that may also help you.

• That One Hat Guy

[RCJW3000]

The biggest thing I can stress is approval and peer checks. This year our team started using a new type of sign-off where each design member had to make drawings for their parts (for machinists) and get it signed by 1) a design peer 2) an assembly member 3) machinist and 4) either a mentor or a CAD lead (me for our elevator or the other lead for wrist/intake).

Even though each iteration took slightly longer, when we did make things they generally worked with less small mistakes (missing holes, clearance, etc) with some even working first time off the bat.

In terms of flushing out designs quickly, just prototype everything. Last season our team went through at least 6 types of hoods/shooters in one week. Go broad and try a lot at the beginning of the season, and then focus in after the first couple of weeks to make sure you catch (most of) the mistakes in CAD.

Lastly, I would advise against making major functional changes (arm to elevator, roller intake to claw, etc) once you’re a few weeks out from comp. If you look at Champs, there are robots on Einstein with almost every type of design you can think of; it’s not your design that wins, it’s your execution. Focus on tuning and improving in small ways rather than pivoting to something completely new, 9 times out of 10 you’ll end up with a better product.

[yadin]

A thing I sometimes do to make sure everything makes sense is start with were the actuator is and follow the power transmission through the system, while checking that evrything makes sense(no missing bearings center to center distances that make sense, clearance/access checks, etc). For mechanisms that involve some more complicated geometry I usually move stuff around and than compare my finished assembly with my sketch and make sure the mechanism moves how I expect it to.
when doing whole robots a thing that can help you is to make a “blockbot”, which is a rough assembly that should represent the finished robot with each system as a block that defines the amount of space that system is allowed to take. You can also include electronics in there(or at least make sure you leave enough space for them)

[JRumple]

Stick to your Engineering Design Process: Identify, Design, Create, Iterate, Communicate (https://firstinspiresst01.blob.core.windows.net/first-energize/fll-challenge/fll-challenge-superpowered-engineering-design-process.pdf).

I’ve seen too many teams and too many professional engineers rush through the Identify step because they have an idea and want to dive into he detailed design quickly. They get into the Create step and find that things aren’t working as they expected, but have spent so much time and money cutting parts and building mechanisms that there is no opportunity to walk away from their first idea which has become their baseline.

This is easier said than done. It really cuts against our instinct, particularly when we’re under a six-week schedule. It is because of this schedule pressure that doing a good job at the Identify step is so important. We don’t have time to build every idea, so we need a way to compare and evaluate concepts before we start cutting metal.

I mentor teams to consider the following three Pillars of Success:

• Strategy
• Robot
• Execution

Teams need to balance these three things. Consider auto racing. If a team has the best car on the field and the worst driver, they won’t win races. The best driver can take an average car with a good strategy and win. You may need to design a sub-optimal robot to give your drivers time to practice and refine their strategy.

Admittedly, we do a poor job at mentoring teams on how to do the Identify step effectively. My meager contribution to help with this is a game analysis document. I’m still refining my Charged Up document (FRC 2023 Charged Up Game Analysis - Google Docs) and have started cleaning out a document for Crescendo (FRC 2024 Crescendo Game Analysis - Google Docs). These are a look inside my head as I’m reviewing the Game Manual and working out strategies.

[JRumple]

Start a Mentor Recruiting program today.

We spend a lot of time recruiting new students to the team. We spend a lot of effort reaching out to local companies to raise funds. We need to spend time recruiting Mentors.

When I started mentoring several team members told me the team would perform better if they had more students on the team. Others told me the team would perform better if they had more money to spend. I finally put it to the test and did my own pit scouting and asked teams how many students they had and what their annual budget was. Then I went back and looked at team rankings for the event. Neither of these factors correlated to higher rankings. There are small teams that perform well. There is a threshold after which more money doesn’t correspond to better robot performance.

My current theory is that one of the key drivers to team performance is their mentors. Teams need mentors working in industry to share industry practices and work shoulder to shoulder with the students through the challenges they face.

Parent Mentors are great. They bring a breadth of experience from technical and non-technical industries that are necessary to run a successful team. Teams should also be seeking mentors from community companies who can also share their experiences with the team.

The Fundraising group builds a Needs List. This is a list of the materials or other expenses that the team has and where they would spend sponsorship money. It is easier to ask a local business to sponsor the team for one of the items on their Needs List. it reassures the business that the team has thought through their budget and made choices on where the money would be most effective.

I recommend that teams also build a Help List. This is a list of the various skills (technical and non-technical) that the team would like mentorship on. The list should have things like Mechanical Engineering, Software Development, Welding, and Wiring. It should also have things like Project Management, Finances, Video Production, Sales, Interviewing, and Marketing.

If you want to know what to add to the Help List to get help with the Identify step, well, it is Systems Engineering. If you’re not sure what businesses in your area have Systems Engineers, look for a local chapter of INCOSE (https://www.incose.org).

A Systems Engineer will help you see the whole robot as a system and help balance the design of individual mechanisms to make them all work together. A Systems Engineer can also provide insight into your robot in the context of an Alliance. This can help you develop match strategies that leverage your strengths and help bring in the strengths of your Alliance Partners for better match performance.

[rZhov]

What things do you find yourself missing which result in longer design timelines?

Providing some examples can help the community provide more specific suggestions for your unique challenges.

[chrisrin]

Caveat: I’ve been helping mentor robot design/CAD for just 2 to 3 years, and I’m still learning a ton every single year. Others are far more experienced, but I am glad to share what I’ve gleaned so far… As far as “stages and tricks”…

1. Knowing the rules and having a strategy is prerequisite. What ways to score or defend does the robot NEED to be able to execute? What other ones do you WANT? What basic capabilities (drive, intake from a certain place, lift a game piece a certain height…) are required for those NEEDS and WANTS.
2. We usually do 2D CAD sketches of the game pieces, field elements (or just lines or shapes that serve as proxies), key spacings and dimensions of the field. And then we 2D sketch multiple chasses with different primary mechanism options or game piece path-through-the-robot options. The goal of the 2D work is to assess geometry and feel out what design options seem most promising in that context. I have to say a LOT gets figured out all the way back at this stage, and not doing something like this can cause problems and time-consuming rework.
3. Continuing the work of step 2, we’ll shift to 3 dimensions, but in a fairly crude way with analyzing geometry still being the focus. Search for Crayola CAD; you’ll find some interesting discussions.
4. Maybe in parallel, prototyping of some of the clear mechanism contenders begins. We don’t get as much shop time as some teams, so we have to prioritize what we do. We’ve also been trying to actually design/CAD prototypes. I mean… Early ones can be thrown together to gain basic game piece insights fast, but soon enough it helps to invest time into designing a prototype that can be adjusted (e.g. change a dimension / ball compression) to learn more from it. I bet you’d find some interesting ideas if you searched for configurable, adjustable, flexible prototyping.
   Quick comment: I think some teams have lots of time to do steps 1-4 (or similar) but other teams don’t. We’re more the latter; we have to go fast with the time we have. Definitely do what is within your team’s abilities and constraints.
5. An important thing during these stages: Don’t be too inwardly focused… Look around at robot in 3 days teams, look at the fast-moving #openalliance teams generously posting every day… And look at robots from similar past games for inspiration. Don’t hesitate to borrow and adapt design ideas others have shared. Open source mentality applies to FRC hardware design.
6. For us, out of all this work, 2 or 3 overall robot concept options usually emerge… Maybe once we just landed on 1 concept everyone liked, but usually not. Often people will do white board sketches or maybe more of the crude CAD, but at this point we’ll develop those concepts more and turn up the strategy scrutiny. And then…
7. We used to vote, including whole team freshmen through seniors + mentors. We don’t do that anymore. A core group of experienced student leaders + mentors hashes it out and arrives at a consensus about which concept we’ll pursue.
8. And then we organize our design group and effort around that decision. The personnel on hand during the particular year is a major factor. One year, a single student designed most of the robot. An earlier year, we were less good at CAD, so prototyping evolved into an integrated robot “design” without much CAD’ing, and then a CAD was done after more to document what we did. (We would not do this now, but it worked for us then - one of our best years.) And one year, we had no student CAD skills due to a huge group who graduated the year before, and mentors needed to help a lot more with design/CAD. The point is, again, think about what’s going to work for your team.
9. From there, as I saw someone mention, we start with the chassis. We decide on chassis type and dimensions and get that CAD done.
10. And then, it just sort of depends on the personnel we have and the mechanisms that need to be designed & how they interact. If the robot concept lends itself well to a modular approach & if we have several capable designers, we might do a space allocation, where we box out the volumes of robot space allocated to each mechanism, and each mechanism designer has to stay in those constraints or negotiate to get more space (or sometimes free up unneeded space). Or if there is just one person interested / capable enough, then that person decides the sequence they’ll do things in. I suspect the fastest initial whole-robot designs are produced by single designers who are deeply experienced. Collaboration is a great way to go too & a good experience, but it takes time.
11. The overall robot integration, connecting all the modules together, incorporating electronics, resolving unexpected interferences, etc. can end up being tricky. Designing 2 or 3 full robots (maybe do some CAD-athons) before build season to practice seems like the best way to prepare. If you aren’t able to do that, then just be prepared to make mistakes and fix them, and sometimes the mistakes can be pretty horrible and time-consuming to fix (I have been there for sure). If you just get stuck, come back here and ask for help. This community is really amazing at helping people trying to learn and who are encountering problems.

If you’re using Onshape, I recommend searching for CD discussions and other content teams have shared about how to organize your robot document(s). Getting organized from the start can help avoid problems and save a lot of time. Good luck!