|
48 | 48 | </ul> |
49 | 49 | </div> |
50 | 50 | <div class="body"> |
51 | | - <h1>Goals</h1> |
52 | | - <p>The following is a list of goals the software team tries to meet each |
53 | | - year. They inform decisions regarding our curriculum design and operating |
54 | | - procedures.</p> |
55 | | - <ul> |
56 | | - <li>Produce an effective product</li> |
57 | | - <li>Employ industry best practices</li> |
58 | | - <li>Expand our knowledge and capabilities</li> |
59 | | - <li>Involve less experienced team members</li> |
60 | | - <li style="list-style: none; display: inline"> |
61 | | - <ul> |
62 | | - <li>Find tasks requiring less experience</li> |
63 | | - </ul> |
64 | | - </li> |
65 | | - <li>Create an autonomous software team / encourage learning</li> |
66 | | - <li style="list-style: none; display: inline"> |
67 | | - <ul> |
68 | | - <li>Provide access to resources for motivated students</li> |
69 | | - </ul> |
70 | | - </li> |
71 | | - </ul> |
72 | | - <h2 id="Curriculum_design_guidelines">Curriculum design guidelines</h2> |
73 | | - <ol> |
74 | | - <li> |
75 | | - <b>Teach incoming members enough C++ to be useful</b> |
76 | | - <p>Integrate modern C++ development paradigms, tools, and practices. |
77 | | - The C++ language has improved a lot since 2003; we don't need to |
78 | | - program in the dark ages anymore.</p> |
79 | | - </li> |
80 | | - <li> |
81 | | - <b>Teach a set of skills motivated by industry best practices</b> |
82 | | - <p>By industry best practices, we don't mean extremely conservative, |
83 | | - waterfall model practices. We're more focused on breaking down and |
84 | | - solving problems using industry standard tools. We emphasize |
85 | | - reliability, but reliability and innovation aren't mutually |
86 | | - exclusive.</p> |
87 | | - <p>Software shall meet embedded and <a href= |
88 | | - "https://en.wikipedia.org/wiki/Real-time_computing">real-time</a> |
89 | | - requirements.</p> |
90 | | - </li> |
91 | | - <li> |
92 | | - <b>Prepare students for Computer Science at university</b> |
93 | | - <p>The focus should be on "Design before build". That is, developing a |
94 | | - specification for behavior before implementing it. Teach common |
95 | | - development practices like Git and code review.</p> |
96 | | - </li> |
97 | | - <li> |
98 | | - <b>Teach an introduction to control theory for those interested</b> |
99 | | - <p>This is also needed for a reliable / maximally efficient robot and |
100 | | - includes state machines, motion profiles, filters, and |
101 | | - feedback/feedforward controllers.</p> |
102 | | - </li> |
103 | | - </ol> |
104 | | - <h2 id="Lab_design_guidelines">Lab design guidelines</h2> |
105 | | - <ol> |
106 | | - <li> |
107 | | - <b>Provide implementations for things unrelated to the lab's learning |
108 | | - outcomes</b> |
109 | | - <p>The student shouldn't get bogged down in setting up infrastructure |
110 | | - for their solution if the lab is intended to teach something specific. |
111 | | - For example, the state machine lab <a href= |
112 | | - "../../ci/state-machines/state-machine/">here</a> provides a template |
113 | | - with all the subsystems necessary to implement a robot's state machine. |
114 | | - The comments tell the student where to insert their state machine |
115 | | - logic, as practicing writing state machine logic is the purpose of the |
116 | | - lab.</p> |
117 | | - </li> |
118 | | - <li> |
119 | | - <b>Assuming a few prerequisites is acceptable to enable showcasing a |
120 | | - topic's utility</b> |
121 | | - <p>By showcasing advanced topics in an approachable, introductory way, |
122 | | - students can appreciate the breadth of knowledge they can and will |
123 | | - learn. If prerequisites are skipped, the lab should provide requisite |
124 | | - knowledge as it is needed to understand or implement dependent |
125 | | - concepts.</p> |
126 | | - </li> |
127 | | - <li> |
128 | | - <b>Labs should encourage students to develop practical methods for |
129 | | - solving problems</b> |
130 | | - <p>Labs exist to provide hands-on experience with a topic. They should |
131 | | - supplement the theoretical material covered in lecture to foster |
132 | | - practical or intuitive understanding. After finishing a module and its |
133 | | - labs, students should be capable of applying topics initially |
134 | | - introduced in lecture.</p> |
135 | | - </li> |
136 | | - <li> |
137 | | - <b>Use graphical tools to gain insight</b> |
138 | | - <p>Basically, a picture or movie is worth a thousand words. The |
139 | | - following are good examples of visualization tools.</p> |
140 | | - <ul> |
141 | | - <li> |
142 | | - <a href="https://github.com/frc3512/LiveGrapher">LiveGrapher</a> |
143 | | - allows visualizing physical phenomena in real time. |
144 | | - </li> |
145 | | - <li><i>rltool</i> from MATLAB aids in students' intuitive |
146 | | - understanding of how root locus plots represent a system's response |
147 | | - and how the pole and zero locations affect the plot.</li> |
148 | | - <li>GRIP facilitates experimentation with complex image processing |
149 | | - operations via an easy-to-use package.</li> |
150 | | - </ul><br> |
151 | | - </li> |
152 | | - <li> |
153 | | - <b>Common wisdom imparted through lectures should be motivated in labs |
154 | | - with data</b> |
155 | | - <p>For example, it is understood that mutexes are preferred over |
156 | | - lock-free data structures unless there are scalability requirements for |
157 | | - distributed, concurrent accesses. A lab requiring the implementation of |
158 | | - an atomic data structure may motivate the exercise by making a mutex |
159 | | - implementation first, then benchmarking both. (This would be a good |
160 | | - opportunity to show the utility of and best practices for benchmarking |
161 | | - software, by the way.)</p> |
162 | | - </li> |
163 | | - <li> |
164 | | - <b>Use industry standard tools to handle auxiliary tasks</b> |
165 | | - <p>Students should be able to leverage existing tools to make their |
166 | | - jobs as software developers easier. Labs are encouraged to use tooling |
167 | | - if it doesn't automate what the student is intended to learn through |
168 | | - practice.</p> |
169 | | - <p>In the previous example, Clang's thread sanitizer tool may be used |
170 | | - to verify correctness of the data structures' synchronization.</p> |
171 | | - </li> |
172 | | - </ol> |
173 | | - <h2 id="Learning_outcomes">Learning outcomes</h2> |
174 | | - <p>This is a list of topics we hope to teach software team members |
175 | | - throughout their membership. These may not all be accomplished in one |
176 | | - season. They are mainly structured in a way for which we can test |
177 | | - competence.</p> |
178 | | - <p>They include programming-specific topics such as C++, program planning |
179 | | - and implementation, testing and debugging, version control, and |
180 | | - robot-specific topics including control theory. Inter-team communication is |
181 | | - important for most of these.</p> |
182 | | - <h3 id="C.2B.2B_programming_language">C++ programming language</h3> |
183 | | - <p>The list of topics below is largely based on part 1 of <i>Programming: |
184 | | - Principles and Practice Using C++ (2<sup>nd</sup> edition)</i>.</p> |
185 | | - <ol class="sub"> |
186 | | - <li>Can build and run programs |
187 | | - <ol class="sub"> |
188 | | - <li>"Hello World!"</li> |
189 | | - <li>Understands the building/linking process</li> |
190 | | - </ol> |
191 | | - </li> |
192 | | - <li>Can declare, initialize, and assign variables</li> |
193 | | - <li>Can perform input/output operations (std::cin, std::cout)</li> |
194 | | - <li>Understands the various commonly used types |
195 | | - <ol class="sub"> |
196 | | - <li>Signed and unsigned integer</li> |
197 | | - <li>float and double</li> |
198 | | - <li>std::string</li> |
199 | | - </ol> |
200 | | - </li> |
201 | | - <li>Understands expressions and statements |
202 | | - <ol class="sub"> |
203 | | - <li>Are "i++", "3 + 2", and "int i = 0;" each an expression or |
204 | | - statement?</li> |
205 | | - </ol> |
206 | | - </li> |
207 | | - <li>Understands implicit/explicit (casting) conventions</li> |
208 | | - <li>Understands loops/iteration (counters, range-based, iterators)</li> |
209 | | - <li>Can prototype, define, and call a function |
210 | | - <ol class="sub"> |
211 | | - <li>With a return type of void</li> |
212 | | - <li>With a return type of int</li> |
213 | | - <li>Can return a value which is used by the caller</li> |
214 | | - </ol> |
215 | | - </li> |
216 | | - <li>Can instantiate a std::vector |
217 | | - <ol class="sub"> |
218 | | - <li>Add elements</li> |
219 | | - <li>Index into vector</li> |
220 | | - </ol> |
221 | | - </li> |
222 | | - <li>Understand different kinds of errors and how to deal with them |
223 | | - <ol class="sub"> |
224 | | - <li>Compile time errors</li> |
225 | | - <li>Run time errors (extremely important to handle properly)</li> |
226 | | - <li>Exceptions thrown by standard containers, etc.</li> |
227 | | - </ol> |
228 | | - </li> |
229 | | - <li>Knows when to utilize functions to deduplicate behavior and manage |
230 | | - complexity</li> |
231 | | - <li>Can define a class |
232 | | - <ol class="sub"> |
233 | | - <li>Contains member variables and functions</li> |
234 | | - <li>Contains a constructor and destructor</li> |
235 | | - <li>Uses the default constructor or "= default" for empty |
236 | | - implementations</li> |
237 | | - <li>Includes static member functions |
238 | | - <ol class="sub"> |
239 | | - <li>Understands the significance of static member functions</li> |
240 | | - </ol> |
241 | | - </li> |
242 | | - <li>Creates appropriate files (ClassName.hpp, ClassName.cpp)</li> |
243 | | - <li>Defines class in header with include guards</li> |
244 | | - <li>Includes header in source file</li> |
245 | | - <li>Writes implementation in source file</li> |
246 | | - </ol> |
247 | | - </li> |
248 | | - <li>Understands the uses of public, protected, and private class |
249 | | - membership</li> |
250 | | - </ol> |
251 | | - <h3 id="Constructing_a_Program">Constructing a Program</h3> |
252 | | - <ol class="sub"> |
253 | | - <li>Makes effective use of language features</li> |
254 | | - <li>Follows commonly accepted best practices</li> |
255 | | - <li>Uses proper format/style</li> |
256 | | - <li>Follows an appropriate problem solving process |
257 | | - <ol class="sub"> |
258 | | - <li>Understand the problem</li> |
259 | | - <li>Formulate a design</li> |
260 | | - <li>Implement the design</li> |
261 | | - <li>Test the design</li> |
262 | | - </ol> |
263 | | - </li> |
264 | | - </ol> |
265 | | - <h3 id="Testing_and_Debugging">Testing and Debugging</h3> |
266 | | - <ol class="sub"> |
267 | | - <li>Can effectively debug a program through analysis of its behavior via |
268 | | - a debugger or print statements</li> |
269 | | - <li>Knows how to thoroughly test one's code to ensure a quality |
270 | | - product</li> |
271 | | - <li>Consistently delivers well-tested software</li> |
272 | | - <li>Can use Google as an aid in solving one's problem</li> |
273 | | - </ol> |
274 | | - <h3 id="Git">Git</h3> |
275 | | - <ol class="sub"> |
276 | | - <li>Can create a new Git repository</li> |
277 | | - <li>Can make commits in separate branches</li> |
278 | | - <li>Gerrit |
279 | | - <ol class="sub"> |
280 | | - <li>Can push branches to Gerrit for review and provide feedback to |
281 | | - others |
282 | | - <ol class="sub"> |
283 | | - <li>Knows how to rebase patches to push them for review</li> |
284 | | - </ol> |
285 | | - </li> |
286 | | - <li>Can fetch changes from Gerrit</li> |
287 | | - <li>Can resolve conflicts when merging or rebasing</li> |
288 | | - <li>Understands the value of code review in quality assurance</li> |
289 | | - </ol> |
290 | | - </li> |
291 | | - </ol> |
292 | | - <h3 id="Robot">Robot</h3> |
293 | | - <ol class="sub"> |
294 | | - <li>WPILib |
295 | | - <ol class="sub"> |
296 | | - <li>Can write code to control a simple two-wheeled robot |
297 | | - <ol class="sub"> |
298 | | - <li>Two joysticks: one for forward speed; one for turning</li> |
299 | | - <li>DifferentialDrive</li> |
300 | | - </ol> |
301 | | - </li> |
302 | | - <li>Can interface with various sensors (encoders, limit switches, |
303 | | - gyroscopes) and perform actions based on their outputs</li> |
304 | | - </ol> |
305 | | - </li> |
306 | | - <li>Embedded systems |
307 | | - <ol class="sub"> |
308 | | - <li>Understands the tenets of event-driven design |
309 | | - <ol class="sub"> |
310 | | - <li>What is an event?</li> |
311 | | - <li>How are they used in state machines?</li> |
312 | | - </ol> |
313 | | - </li> |
314 | | - <li>Can design a state machine to model the desired actions of a |
315 | | - robot when completing a task</li> |
316 | | - </ol> |
317 | | - </li> |
318 | | - <li>Control Theory |
319 | | - <ol class="sub"> |
320 | | - <li>Knows the dynamics of a PID controller, its limitations, and how |
321 | | - to tune one</li> |
322 | | - <li>Knows how to use motion profiles with feedback controllers and |
323 | | - the importance of feedforwards</li> |
324 | | - <li>Can apply filters when necessary to obtain better estimates of |
325 | | - system outputs</li> |
326 | | - <li>If students have time, they can learn feedback controller design |
327 | | - (more feedback controllers exist besides PID)</li> |
328 | | - </ol> |
329 | | - </li> |
330 | | - </ol> |
331 | | - <h3 id="Slack">Slack</h3> |
332 | | - <ol class="sub"> |
333 | | - <li>Is a member of frc3512.slack.com</li> |
334 | | - <li>Can effectively explain one's problem when asking for help |
335 | | - <ol class="sub"> |
336 | | - <li>Can use <a href="https://www.google.com/">Google</a> first |
337 | | - </li> |
338 | | - <li> |
339 | | - <a href= |
340 | | - "https://web.archive.org/web/20201203051626/http://www.catb.org/esr/faqs/smart-questions.html#before"> |
341 | | - How to Ask Questions the Smart Way</a> |
342 | | - </li> |
343 | | - </ol> |
344 | | - </li> |
345 | | - </ol> |
346 | | - <h3 id="Veterans">Veterans</h3> |
347 | | - <p>Us mentors assume you already know how to write software. Software |
348 | | - engineering is what we really want to teach you. If you can explain this |
349 | | - year's robot code and why you designed it <i>that</i> way versus the other |
350 | | - possible designs, you have succeeded and have likely earned a <a href= |
351 | | - "../varsity/">varsity letter</a>. It shows you contributed in the design |
352 | | - phase and know the trade-offs (engineering is essentially the process of |
353 | | - choosing the least bad design based on some criteria and justifying that |
354 | | - choice). Our role as mentors is to show you what tools are available in the |
355 | | - C++ language so you can make an informed design decision.</p> |
356 | 51 | </div> |
357 | 52 | </body> |
358 | 53 | </html> |
0 commit comments