Retaining Information

Im a graduating senior. My team has a lot of graduating seniors. One thing that is on our minds is how can we effectively retain our information as part of the team’s collective experience. I’ve been working on an advice handbook containing a lot of our information, but my main question is how do other teams do it? Because we were the students who went through two styles of our team, the 2012-2018 version and the 2019+ version, and still have much of the knowledge the old team has. I know mentors are a big thing, and likely many of us will be back to mentor, but even that information can be forgotten. How do teams with many years of experience maintain the knowledge of the students before? Do you use advice handbooks and documentation or is there something else? Or a combination of it?


One thing our team has started is a write up of the year and what was good and bad along with the lessons learned. It really helps because the examples reinforce the important ideas. For example “don’t do swerve unless you are completely ready and have done it in the offseason”. If anyone on our team brings up doing it in the future they can look back on 2018 and see that it was a complete bust and that they should be cautious about implementing it.

1 Like

In terms of student information. My team uses GrizzlyTime. A flexible time-logger and statistic tracker. Otherwise our chairmen’s documentation is more than enough tracking as our growth as a team.

1 Like

We do this also - a “lessons learned” is usually made for each year by the build team leader (not sure what will happen this year because we didn’t have a lot of time to learn things. It will probably just be shorter.)

Alongside that we have a group of resources that is available to team members. Included in this are documents from other teams and also documents we have made. An example of one of our documents is our build manual. We created a “build manual” that is 75+ pages long and teaches all of the technical knowledge we have, from the basics like “what is a bearing” to the higher level things like “variable based parametric cad” or “shape optimization in Fusion 360” etc. If someone wants to learn about something specific, they can look at the build manual. It is also used as a guide when teaching freshmen in summer classes - it makes sure nothing is forgotten when teaching.

Two mentors who were around a long time ago, seem to be the only way we have of retaining information. And both of us have less than perfect memories, unfortunately. So, we let students teach us the same lessons over and over every year!

1 Like

Google Docs. Lots and lots of Google docs, which the mentors have access to for sharing later.

1 Like

It’s not a system that my team uses, but I would imagine that technical binders are a great way to pass down information. We tend to look at previous years for ideas on how to play the game, but it’d be stellar to be able to look back at literal ideas that our team has implemented to jump start the prototyping phase.

Do you have any advice on where to start if another team wanted to start making their own build manual?

“How do you get to Carnegie hall?”

“Documentation. Documentation. Documentation.” —-Marshallbraham Licolnacorn

The where doesn’t matter so long as people have access to it. GitHub and Markdown are awesome. Google docs is epic. Notebooks and paper work if that’s what you’ve got.

DIMFD - Documentation Is… you know the rest.

1 Like

It is probably a little late to start, but the best way is mentorship. You can try to write it all down in some form or another, but having the younger students learning side by side with the more experienced students is always the best way to pass on knowledge.

Short of mentorship, classes (camps) are also a good way. Camps run by the senior students teaching the more junior students always work better than mentors teaching. Camps can be run during the summer before the seniors go off to college, or in the fall if the seniors are attending colleges close by and willing to come home on weekends to teach.

Yes. I was the initial creator of the build manual and have written ~75% of it so after hundreds of hours working on it I know a bit about how to do it.

First, identify the areas you want to cover. For some manuals you want to start from the basics, some you want to start at a relatively high level. For our build manual we wanted to have both the basics and high level areas. It currently covers has these topics

  • What you need to start (other resources, suppliers, team mottos/"rules to live by, mechanical calculators etc)
  • Mechanical basics (types of mechanisms, engineering notebook, prototyping etc)
  • Game analysis
  • build materials (tube, gusset, polycarbonate, fasteners etc)
  • basics of motor systems (bearings, bushings, motors, motor controllers, chain& sprocket, basics of what a gearbox does, basics of sensors etc)
  • Motor systems in depth (electric motors EE basics/ calculations, gearing decisions (motor calculators), types of gearboxes, shifting etc)
  • Full walk through of choosing a motor system (empty at the moment, you can probably figure out what it would be)
  • Types of actuators
  • pneumatic systems (calculators, force calculations, the whole system and what the parts do)
  • Electrical system overview (wires, battery, components, sensors in depth, etc) - needs work
  • onshape (part studios, assemblies, Onshape 101, organization and standard naming system etc)
  • Fusion 360 CAM (what is it, how to do it etc)
  • CNC machine: Velox 5050 (all of the parts and how to use it)
  • Mach 3

Those are the topics we have right now, we also have a page of topics we want to do in the future: CAD standard dimensions, 3d printing how to, more on the game analysis, shop rules, hand tools, Lathe and more how to-s on the machines like the band saw or arbor press or drill press etc.

Ultimately if you want to make something similar, ask yourself what questions you want to answer and that will be your guide. After you have a goal, get your topics and start filling it out. Include pictures and explain things as best you can. Add to it whenever you can. Get peers and mentors to read it and help you improve it. Ask others, who might have a different area of expertise, to add to it. Ask those who have similar areas of expertise to go over the parts you have written and add what they have to say (people have different ways of looking at things… take advantage of that). Google docs is the best way to do it IMO. By the end you will have a document which (hopefully) will last longer than your short 4 years on the team.


This is really helpful, thank you!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.