Robotics notebook diagrams

Hey all. I’m a notebooker for my team and was wondering how to best utilize diagrams? My team won judges award at our previous competition and I was told that that means my notebook was “basically third place.” I’m not sure of the validity of that, but either way I still want to improve the notebook.

Could I get tips on when to use diagrams, and what options there are for diagrams? The only things that come to the top of my head are pros and cons lists, trial and error charts, and bullet points.

Have you gone to

The judges awarded isn’t third place. It’s more like your team did something that the judges really liked and gave you an award.

  • Judges Award - Given to a team that the judges deem worthy of special recognition.

You may want to search through the forum for similar threads - they are numerous.

Here is one to get you started:


Check out


for digital tools

Check out or

in general, you can find lots of resources at or


Diagrams are great for prototypes and potential ideas. When you are documenting any brainstorming processes in your notebook, having diagrams to allow the judges to picture what you are talking about is great!

Once an idea gets more concrete (designed in CAD, small scale model built, mechanism constructed, etc.) its nice to include photos/screenshots too. This doesn’t mean diagrames are only for brainstorming, rather that at this state it would be helpful to also see how said mechanism will fit on your robot.

As far as charts go, I recommend using decision matrices for all major brainstorming processes (deciding the initial robot design, changing to a different shooter type, etc.), and pros/cons charts for less important ones (lift motor overheats too often, last part of programming skills run is not 100% accurate, etc.). Charts are great for any time you are testing something, whether it be an autonomous run, a subsystem on your robot, or a change made to a particular mechanism. This will allow judges to see that you are understanding and properly interpreting your testing data and using it to guide your design decisions, Note that these are just recommendations, and that every team dos things differently (in fact, the judge’s guide does not mention an “end all be all” way for proper problem solving documentation, but that the engineering notebook rubric should set the bounds for how you document it).

Here is an example from my team’s engineering notebook this season: