IIWII Robotics
  • VEX Engineering Notebooks
    • Overview
    • Notebooking Best Practices
    • Understanding the Engineering Notebook Rubric
      • Engineering Notebook Scoring
      • Engineering Design Process Categories
        • Identify the Problem
        • Brainstorm, Diagram, or Prototype Solutions
        • Select Best Solution and Plan
        • Build and Program the Solution
        • Test Solution
        • Repeat Design Process
      • Additional Categories
        • Innovation/Originality
        • Usability and Completeness
        • Record of Team and Project Management
          • Time Management
          • Team Management
          • Resource Management
        • Notebook Format
    • Parts of a Notebook (Sections)
      • Cover Page
      • Team Overview / Introduction
      • Table of Contents (TOC)
      • Engineering Design Process (EDP)
      • Engineering Notebook Format
      • Game Overview / Analysis
      • Design Brief
      • Notebook Entries
        • General Entry
        • Team Meeting
        • Time Management
        • Resource Management
        • EDP Entries
          • Identify the Problem
          • Research
          • Brainstorm / Evaluation
          • Build / Program
          • Test
          • Repeat Design Process
      • Competition Writeup
      • Innovate Submission
      • Appendix
        • References
    • Engineering Notebook Resources
  • Interview
    • Overview
Powered by GitBook
On this page
  • Build
  • Program
  1. VEX Engineering Notebooks
  2. Understanding the Engineering Notebook Rubric
  3. Engineering Design Process Categories

Build and Program the Solution

PreviousSelect Best Solution and PlanNextTest Solution

Last updated 1 year ago

This criteria area has two subsections that some teams forget to take into consideration. The first is build which is the primary area teams focus upon. The second area, program, is where teams often fall short.

Build

When considering what to include in this area there are varieties of depths that a team can explore. It can be as simple as providing some images of a subsystem or completed solution or go as far as providing step by step instructions around how to put the solution together with a full parts list down to the screws and nuts being used.

When deciding what is enough detail to provide, consider what you would need if you had to rebuild/recreate your own solution. Would you need a few sentences describing a solution with accompanying sketches or detailed CAD with a full parts list and build instructions?

Program

For programming teams may vary from putting in a couple functions describing key features to placing their entire code. While the latter is nice, it may be overkill for what is needed from a recreation perspective.

What is a good approach to documenting a team’s code base?

  • Use Pseudocode to give the reader an understand of what is trying to be accomplished

  • Create path maps to go with the Pseudocode

  • Provide snippets of code and not an entire file

  • Comment code, not only is it a good practice but can help the reader understand what is taking place in a particular section of a code

One consideration to keep in mind is that many teams are starting to use coding templates. As the growth of these continues to be leveraged by more and more teams, the diversity in coding and showing/explaining what is being developed for use may shrink. To show how a team is using that code or any modification or unique approach it is worthwhile to comment as much as possible or even create markups that can go alongside the code in the notebook. Additionally it is also a good idea to provide credit to the author or team of the template.