I had a thought on our training protocol.
Perhaps we should approach the technical / engineering side of training (i.e., knowing how to build, program, and troubleshoot the copters) like a tradesperson would be trained. A car mechanic in training cannot possibly be taught the answer to every possible 'clunk' 'thunk' or 'bang', but by understanding the car as a system, they have the ability to troubleshoot and solve a broad range of issues.
The current challenge is to develop the knowledge of building and programming the copters for autonomous flying and in troubleshooting when things aren't working right. This has typically been hard-earned knowledge locked inside the brains of our engineering students.
One strategy has been to develop a Wiki, but the information is often so varied and problem-based (e.g., this part broke this time, why is that?) that a comprehensive Wiki seems like a daunting and nebulous task that would require constant updating. Also, I think a Wiki does not really reflect the troubleshooting knowledge that a flight technician requires. This knowledge is obtained by first understanding how the copters work, then spending time researching on wikis, blogs, and forums possible explanations for why something isn't working, and finally testing out those theories to resolve the issue.
I propose we develop a protocol for intentionally 'reseting' the Udrones Arducopters so that prospective Ecosynth users need to rebuild and reprogram from the beginning. How can someone possibly be an independent Ecosynth expert if they don't know what an 'ESC' is and why it is important?
Back to basics for us! As we prepare for our summer boot camp in the lab, day one could be spent in 'chalk talks' (I used to teach sailing) where we learn the parts of the copter, basics of the system, then how to get the device flying.