The following is a list of goals the software team tries to meet each year. They inform decisions regarding our curriculum design and operating procedures.

Curriculum design guidelines

  1. Teach incoming members enough C++ to be useful

    Integrate modern C++ development paradigms, tools, and practices. The C++ language has improved a lot since 2003; we don't need to program in the dark ages anymore.

  2. Teach a set of skills motivated by industry best practices

    By industry best practices, we don't mean extremely conservative, waterfall model practices. We're more focused on breaking down and solving problems using industry standard tools. We emphasize reliability, but reliability and innovation aren't mutually exclusive.

    Software shall meet embedded and real-time requirements.

  3. Prepare students for Computer Science at university

    The focus should be on "Design before build". That is, developing a specification for behavior before implementing it. Teach common development practices like Git and code review.

  4. Teach an introduction to control theory for those interested

    This is also needed for a reliable / maximally efficient robot and includes state machines, motion profiles, filters, and feedback/feedforward controllers.

Lab design guidelines

  1. Provide implementations for things unrelated to the lab's learning outcomes

    The student shouldn't get bogged down in setting up infrastructure for their solution if the lab is intended to teach something specific. For example, the state machine lab here provides a template with all the subsystems necessary to implement a robot's state machine. The comments tell the student where to insert their state machine logic, as practicing writing state machine logic is the purpose of the lab.

  2. Assuming a few prerequisites is acceptable to enable showcasing a topic's utility

    By showcasing advanced topics in an approachable, introductory way, students can appreciate the breadth of knowledge they can and will learn. If prerequisites are skipped, the lab should provide requisite knowledge as it is needed to understand or implement dependent concepts.

  3. Labs should encourage students to develop practical methods for solving problems

    Labs exist to provide hands-on experience with a topic. They should supplement the theoretical material covered in lecture to foster practical or intuitive understanding. After finishing a module and its labs, students should be capable of applying topics initially introduced in lecture.

  4. Use graphical tools to gain insight

    Basically, a picture or movie is worth a thousand words. The following are good examples of visualization tools.

    • LiveGrapher allows visualizing physical phenomena in real time.
    • rltool from MATLAB aids in students' intuitive understanding of how root locus plots represent a system's response and how the pole and zero locations affect the plot.
    • GRIP facilitates experimentation with complex image processing operations via an easy-to-use package.

  5. Common wisdom imparted through lectures should be motivated in labs with data

    For example, it is understood that mutexes are preferred over lock-free data structures unless there are scalability requirements for distributed, concurrent accesses. A lab requiring the implementation of an atomic data structure may motivate the exercise by making a mutex implementation first, then benchmarking both. (This would be a good opportunity to show the utility of and best practices for benchmarking software, by the way.)

  6. Use industry standard tools to handle auxiliary tasks

    Students should be able to leverage existing tools to make their jobs as software developers easier. Labs are encouraged to use tooling if it doesn't automate what the student is intended to learn through practice.

    In the previous example, Clang's thread sanitizer tool may be used to verify correctness of the data structures' synchronization.

Learning outcomes

This is a list of topics we hope to teach software team members throughout their membership. These may not all be accomplished in one season. They are mainly structured in a way for which we can test competence.

They include programming-specific topics such as C++, program planning and implementation, testing and debugging, version control, and robot-specific topics including control theory. Inter-team communication is important for most of these.

C++ programming language

The list of topics below is largely based on part 1 of Programming: Principles and Practice Using C++ (2nd edition).

  1. Can build and run programs
    1. "Hello World!"
    2. Understands the building/linking process
  2. Can declare, initialize, and assign variables
  3. Can perform input/output operations (std::cin, std::cout)
  4. Understands the various commonly used types
    1. Signed and unsigned integer
    2. float and double
    3. std::string
  5. Understands expressions and statements
    1. Are "i++", "3 + 2", and "int i = 0;" each an expression or statement?
  6. Understands implicit/explicit (casting) conventions
  7. Understands loops/iteration (counters, range-based, iterators)
  8. Can prototype, define, and call a function
    1. With a return type of void
    2. With a return type of int
    3. Can return a value which is used by the caller
  9. Can instantiate a std::vector
    1. Add elements
    2. Index into vector
  10. Understand different kinds of errors and how to deal with them
    1. Compile time errors
    2. Run time errors (extremely important to handle properly)
    3. Exceptions thrown by standard containers, etc.
  11. Knows when to utilize functions to deduplicate behavior and manage complexity
  12. Can define a class
    1. Contains member variables and functions
    2. Contains a constructor and destructor
    3. Uses the default constructor or "= default" for empty implementations
    4. Includes static member functions
      1. Understands the significance of static member functions
    5. Creates appropriate files (ClassName.hpp, ClassName.cpp)
    6. Defines class in header with include guards
    7. Includes header in source file
    8. Writes implementation in source file
  13. Understands the uses of public, protected, and private class membership

Constructing a Program

  1. Makes effective use of language features
  2. Follows commonly accepted best practices
  3. Uses proper format/style
  4. Follows an appropriate problem solving process
    1. Understand the problem
    2. Formulate a design
    3. Implement the design
    4. Test the design

Testing and Debugging

  1. Can effectively debug a program through analysis of its behavior via a debugger or print statements
  2. Knows how to thoroughly test one's code to ensure a quality product
  3. Consistently delivers well-tested software
  4. Can use Google as an aid in solving one's problem


  1. Can create a new Git repository
  2. Can make commits in separate branches
  3. Gerrit
    1. Can push branches to Gerrit for review and provide feedback to others
      1. Knows how to rebase patches to push them for review
    2. Can fetch changes from Gerrit
    3. Can resolve conflicts when merging or rebasing
    4. Understands the value of code review in quality assurance


  1. WPILib
    1. Can write code to control a simple two-wheeled robot
      1. Two joysticks: one for forward speed; one for turning
      2. DifferentialDrive
    2. Can interface with various sensors (encoders, limit switches, gyroscopes) and perform actions based on their outputs
  2. Embedded systems
    1. Understands the tenets of event-driven design
      1. What is an event?
      2. How are they used in state machines?
    2. Can design a state machine to model the desired actions of a robot when completing a task
  3. Control Theory
    1. Knows the dynamics of a PID controller, its limitations, and how to tune one
    2. Knows how to use motion profiles with feedback controllers and the importance of feedforwards
    3. Can apply filters when necessary to obtain better estimates of system outputs
    4. If students have time, they can learn feedback controller design (more feedback controllers exist besides PID)


  1. Is a member of frc3512.slack.com
  2. Can effectively explain one's problem when asking for help
    1. Can use Google first
    2. How to Ask Questions the Smart Way


Us mentors assume you already know how to write software. Software engineering is what we really want to teach you. If you can explain this year's robot code and why you designed it that way versus the other possible designs, you have succeeded and have likely earned a varsity letter. It shows you contributed in the design phase and know the trade-offs (engineering is essentially the process of choosing the least bad design based on some criteria and justifying that choice). Our role as mentors is to show you what tools are available in the C++ language so you can make an informed design decision.