Engineering Notebook - Best practices

I have been combing around looking for best practices for developing engineering notebooks for the team. My team needs a good swift kick to get them going, but on the other hand they need a good idea as to what to put in it. We made one but frankly I think it was horrible. 8th graders are not organized at all!!!:smiley:

Any advice?

That depends on how much time you put into it.

The key function of an engineering notebook is to demonstrate your complete design process. That is the very basics of how successful a notebook can be. Other additions are awesome, but the design process is the hard part.

People on the forum may have varied opinion regarding to a successful engineering notebook, including its importance in VRC overall. I personally prefer to perfect it by spending a large amount of time, but like I said, the design process is the key.

Document everything… hours worked, drawing, take photos, team roles, who did you help, who helped you… how did different ideas work, observations of other designs from competitions and how could you incorporate them into your own design.

As I was the captain of my team, I almost notice everything they have done to the team. They help each other, cooperate with each other. And I wish them to remember those times when the team fight for one destination.
I suggest you carry your notebook with you whenever and wherever you are. Write down everything you see and think. I hope this might help you.

The VRC Engineering Notebook that VEX offers now is a great guidepoint to use for your team’s engineering notebook.

Things that should be in it include your strategy breakdown of the game, design process for the beginning and ongoing, relevant equations and analysis (as a judge for local events and I have a friend that judged at Worlds multiple years they LOVE this).

Your community outreach as well and what you do to spread robotics is also important.

Also code, well-commented code that explains what it does should be included.

Those are some of the things a notebook should have.

1 Like
***and don’t slip up
or else you’ll end up like us at worlds

I’d include a copy of the game manual, team biographies, meeting logs, separate programming logs (this separates the great from the good notebooks), Table of contents, page numbers, Clearly tabbed milestones/Competition reflections/sections/favorite experiences, research, experiments, photos of the meeting(labeled), sketches(labeled), cad models(labeled), equations/math, science articles/applied science/borrowed concepts, Funny quotes page, future plans, driver tricks, building tricks, leadership tricks, community outreach,

Everything which traces the experiences of the team and captures the happiness, excitement, organization, and sorrow of the season

Because it’s such a tedious task at times, I would make a template for your team to fill out. Also, giving them a motivator like " imagine how much fun it’ll be when you can say you made it heavier than some a hanging robots". Do the logs daily, and before everyone leaves. You could also make it the better of two poisons like clean up, or do the log book. We also used google docs so multiple people can work on the notebook at the same time.

electronic version of our logs(does not include everything in our notebook):**

OscarNVCC… DUDE!!! That is AWESOME!!! I am going to look at the link and all soon, That is just awesome!
Bill R.

On our team, we find that the engineering notebook is crucial not only to show judges and other teams, but also so if someone misses a meeting or needs to refer back to something that happened a while back, we have quick and easy access. Design process notes, tournament notes, daily updates on what work was done: these are all crucial pieces of our design notebooks. We also find that when we format each entry in terms of a) the problem or task the team is addressing, b) the course of action taken to fix the problem, and then c) the result of that effort, we add context and depth to the notebook. We often print out pictures, gantt charts, relevant sources and tape them into our book too.

But probably most importantly, we feel that our documentation shouldn’t be restricted solely to the notebook. The notebook is crucial for keeping track of the general progression of the team, but our team makes sure to also produce requirements documents, design documents, one-page memos, code, and reference documents. Here we can be more specific about the goals and implementations of our designs.

These things might apply more to our team than yours, but hope they help nonetheless!

A good place to start is a journal. Just record everything possible, but keep it clean. Add all of your code as well, the judges like that :slight_smile: Keep it simple, clean, and professional.

Exactly what we are doing. We record everything related to the design process and are planning to re-organize a robot presentation section prior to each tournament so judges can easily find what they want.

Yes, keeping 7th and 8th graders organized is a real challenge. I give my guys a format to follow that I have been using since my BEST days. This gives them some guidance, but the rest is up to them. The hard part is getting them to buy into the fact that the notebook is just as important as the robot. It worked though. While we did not win a Design Award, the notebook was key to winning three Excellence Awards including at state. By the time World’s rolled around the boys were just as proud and took just as much care of the notebook as they did the robot. They each take a section to be in charge of, but everyone is still responsible for input on each section. They used Google Drive to work and edit most of the sections together. In the end they referred to it as a tool and not as a notebook. The majority of my teams notebook focused on brainstorming, the design process, and programming (print outs of the code). We always include an introduction as well that includes information about our school, team, a four to five page essay, and our past history. They keep a log and include lots of pictures to show both the good and bad ideas and how things were corrected. I make them keep time sheets as well. They made it personal and unique to their team as well. I would be glad to e-mail you the format we follow if you are interested in it to compare with others. Just let me know.

Not reallly part of the notebook but for getting judged awards. I have found 2 things that most teams over look.

Know what your talking about. If a person isn’t THE expert on something don’t let them talk about it. If there is a member of your team that doesn’t have something they totally own and could talk about for hours on end give them a new role. Going along with this. Watch karthik kanagasabapathy’s (yes its the karthik from the GDC I just wrote the last name so you can find it) ted talk on how enthusiasm on a project makes you perform better at it.

Stop scripting design interviews. Watch the judges and plan it out as you go. If you see the judge really loving an innovation then go into it a little more. If your programming is sounding boring or going over their head then don’t talk about it. If the judges are excited by everything you are saying they will stay longer. The roaming judges at worlds stayed at my pit 20 minutes longer than they were supposed to.

My team does large amounts of brainstorming, calculating, designing and commenting all of our code but rarely if ever do we combine it all into a formal design notebook. Even so we won the judges award at worlds and 3 seperate ( about half) of the judged awards at our state championship. The judges at regionals Said we deserved the design award but didn’t want to give it to the champion team. The reason I’m saying this is. Do the design notebook but consider it a reason you should get an award not THE reason.