Teaching DAQ to FIRST teams

[DonRotolo]

Team 1676 is planning on introducing the concept of design verification and validation, using the principles of data acquisition (DAQ). We have formed a testing & integration team for this purpose, and in the weeks leading up to kickoff we are covering the basics of DAQ, using classroom instruction and the 2005 robot to provide some hands-on experience. (The Robot Controller has limited A/D capabilities, and the Operator Interface "Dashboard" would be a good display for simple virtual instruments)

One of the mentors has developed a lesson plan, shown below. There is a lot of material behind this simple outline, probably about 8 hours at least. As the build season starts, and the students are sensoring and measuring the subsystems and, eventually, the whole robot, we'll be there to finish the rest of the teaching on a more practical level.

What I am interested in is, in the outline below what topics are missing, or could be covered more thoroughly or differently, or particular issues within a topic that are important? Also, any ideas for some of the topics, such as particularly effective demonstrations or useful 'labs' to use, would be greatly appreciated. While many of the mentors and coaches have some experience with DAQ, surely there are people who live in this world who can share some of their expertise.

Any and all advice would be most welcome.

Don

======================
DAQ course outline

What good is DAQ?
Systems and interrelationships
Natural DAQ systems (seat of the pants)
Feedback systems, open & closed
Problem solving
Design processes
Gathering & interpreting real-time data

Sensors
Analog
Digital
Signal conditioning & buffering
Sensor calibration & scaling

DAQ hardware
Sampling rate, resolution, scaling, aliasing, dynamic range
Data accuracy & precision
Differential & single-ended inputs, input impedance
Grounding & ground reference, isolation

DAQ software
Simple data collection, file management
Data interpretation
Real-time data streams
Virtual instruments
Counters
Programming

Outputs
Digital
Analog
Triggers & events
=====================

[Jeff Pahl]

It looks very comprehensive and well thought out. The only thing that comes to mind after looking at it is to make sure to cover the concept of "noise". The inside of a FIRST robot is not as noisy as under the hood of a car, but there are motors with chopper PWM drives, and relays and solenoids firing. All of these can corrupt the measurements. Make sure to cover when and where it is prudent or necessary to use shielded wiring on the sensors, and possibly some filtering.

The rest of these are things you have listed, but the things I see most often with new engineers and data acquisition are:

The difference between precision and accuracy. Just because the display has 8 decimal places doesn't mean that they are all real.
Sampling rate. Just because you can record data at 25 kHz doesn't mean that you should. Stress the importance of matching the sampling rate to the parameter being measured. One problem I run into now is that computers have made it so easy to capture huge amounts of data, that people are going ahead and doing it. Then you have to do something with it. Where years ago we would just right down one value from the instrument display, now we are saving hundreds of points of trace data.
File management and data interpretation or visualization. Teach them to know before they capture the data what they are planning on doing with it, and then store it accordingly. I frequently have engineers come into my office who have stored little bits of data into hundreds of Excel files, because it was easy when they were programming it, who want to know if I can somehow magically get it all into one file so they can compare or plot it. There are ways, but it's much easier to get them to put a little effort into storing it properly to start with.

Best of luck with your teaching. I hope you will come back here later and let us know how it goes (and some of the class materials might make a good whitepaper).