You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following is a list of goals the software team tries to meet each year.
68
-
They inform decisions regarding our curriculum design and operating procedures.
69
-
</button>
70
-
<divclass="content">
71
-
<ul>
72
-
<li>Produce an effective product</li>
73
-
<li>Employ industry best practices</li>
74
-
<li>Expand our knowledge and capabilities</li>
75
-
<li>Involve less experienced team members</li>
76
-
<li>Find tasks requiring less experience</li>
77
-
<li>Create an autonomous software team / encourage learning</li>
78
-
<li>Provide access to resources for motivated students</li>
79
-
<li>Teach incoming members enough C++ to be useful</li>
80
-
<li>Integrate modern C++ development paradigms, tools, and practices</li>
81
-
</ul>
36
+
<divclass="Content">
37
+
<divclass="top">
38
+
</div>
39
+
<divclass="bottom">
40
+
</div>
41
+
<divclass="Footer">
42
+
<p>FRC 3512 2022</p>
82
43
</div>
83
-
</div>
84
-
</div>
85
-
<scriptsrc="../../Collapse.js"></script>
86
-
</body>
44
+
</body>
87
45
</html>
46
+
47
+
<!-- Goals
48
+
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.
49
+
50
+
Produce an effective product
51
+
Employ industry best practices
52
+
Expand our knowledge and capabilities
53
+
Involve less experienced team members
54
+
Find tasks requiring less experience
55
+
Create an autonomous software team / encourage learning
56
+
Provide access to resources for motivated students
57
+
Teach incoming members enough C++ to be useful
58
+
Integrate modern C++ development paradigms, tools, and practices.
59
+
60
+
Software shall meet embedded and real-time requirements.
61
+
62
+
Prepare students for Computer Science at university
63
+
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.
64
+
65
+
Teach an introduction to control theory for those interested
66
+
This is also needed for a reliable / maximally efficient robot and includes state machines, motion profiles, filters, and feedback/feedforward controllers.
67
+
Use graphical tools to gain insight
68
+
Basically, a picture or movie is worth a thousand words. The following are good examples of visualization tools.
69
+
70
+
Use industry standard tools to handle auxiliary tasks
71
+
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.
72
+
Lab design guidelines
73
+
Provide implementations for things unrelated to the lab's learning outcomes
74
+
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.
75
+
76
+
Assuming a few prerequisites is acceptable to enable showcasing a topic's utility
77
+
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.
78
+
79
+
Labs should encourage students to develop practical methods for solving problems
80
+
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.
<h3><ahref="nonSoftware.html">Software for not software</a></h3>
102
-
<p>What non-software team members should know about the software team</p>
35
+
</div>
36
+
<divclass="Content">
37
+
<divclass="top">
103
38
</div>
104
-
<divclass="Direct_links_1">
105
-
<h3><ahref="styleGuide.html">Style Guide</a></h3>
106
-
<p>Contains the software team style guide</p>
39
+
<divclass="bottom">
107
40
</div>
41
+
<divclass="Footer">
42
+
<p>FRC 3512 2022</p>
108
43
</div>
109
-
</div>
110
-
</div>
111
-
</body>
44
+
</body>
112
45
</html>
46
+
<!--
47
+
Administration
48
+
Student organizational structure
49
+
Since 3512 was founded, the software team has enjoyed a certain level of autonomy. With that, we've been free to establish our own internal leadership structure. Rather than a typical top-down leadership structure, we operate more like a "software committee". Everyone is equal and contributes to the code base on their own volition with mentors performing quality control. There is a software lead who handles meetings and shields the members from administrative stuff, but the title doesn't imply any superiority or power over the other members.
50
+
51
+
This works best when everyone is equal in skill level, so the mentors work hard to promote learning among rookies to raise their level of competency to that of their peers. We encourage collaboration with the other students to aid in this process.
52
+
53
+
Role of the mentor
54
+
Mentors teach rookies the basics of writing software and enough of the tools to make them productive contributors. The veterans already know how to write software, so the mentors can focus on actually teaching them software engineering. Ideally, the students contribute during the design process and are able to justify their design decisions.
55
+
56
+
The students learn the subject matter most efficiently with mentor guidance, so the mentors are fundamentally in a partnership with the students. While the students should do the work, the mentors should use their experience to inform the students of available tools and potential pitfalls so an informed design decision is made. In this sense, the mentors are primarily in an advisory role.
57
+
58
+
Furthermore, mentors should always provide an unbiased analysis. Transparency helps build trust, and specific solutions always have drawbacks. The mentor should be honest about them so the students develop a level-headed view of the world.
59
+
60
+
However, the mentors also possess the long-term vision for the team and should push the boundaries of the team's accomplishments each year to achieve it. To do this, the mentors may implement tricky bits of framework code, but the students should still understand what has been written and should be walked through it step-by-step if necessary. Remember that FIRST is a mentor-based program, but it is for the students; giving them a sense of accomplishment and ownership keeps them engaged and returning each year.
61
+
62
+
Learning versus reuse
63
+
I like to take the "add tools to the toolbox" approach with my software team. We try some random alternative to improve on previous architecture, and a student or two takes that on as an R&D project. They usually stabilize and end up on the robot by the time competition occurs. We've done probably four different approaches to state machines at this point, and our controls solutions have evolved a lot. Prefer evolution over revolution.
64
+
65
+
Goals
66
+
Contains our goals, curriculum design guidelines, and learning outcomes.
0 commit comments