AttendanceScanning
Problem
[edit | edit source]An engineering seminar is attended by over 70 students. The previous class exits 10 minutes before the next class enters. The room holds over 100 students. Calling out student names takes too much time. Asking students to find their name on a sheet and put a check by it works, but a line forms. Some students would rather find a seat near their friend than wait in line. They begin signing in for each other. And the slippery slope results in starting a seminar with a head count of 30, but 50 people signed in.
Conceive
[edit | edit source]Making seminar attendance part of one's grade is necessary to get community college students to attend. Otherwise, it becomes an optional club. Maybe in the future, the seminar will be so valued, that everyone will want to attend. But to get to that point, to figure out what works and doesn't work in the seminar means that students need additional motivation.
Design
[edit | edit source]Designs considered or tried
|
---|
|
Bar codes on Engineering Notebook Solution
|
---|
Print bar code labels for students. Put these labels on the back of their engineering notebooks in the second class before the first seminar. Expect that barcodes can be scanned almost as fast as people walk. This has the following benefit of being expanded to enabling a door to automatically unlock. |
User Interface Design
|
---|
![]() The goal is to be able to scan very quickly bar codes on the engineering notebooks. So there has to be a window that gives students feed back ... their name, date, time, event, activity in the event such as entering, leaving or asking question, successful secondary scan such as a clicker. The other goal is to administrate this successfully. Data should be saved after a period of inactivity, but in any case there should be a save button. Administrators are going to need to print bar codes, manually enter attendance, check names and faces, switch event activities and adjudicate questions. There are at least three ways to create the user interface:
G4P was choosen because of it's integration into the IDE and prior experience. G4P feels like the code way ahead of the documentation. ControlP5 looks better documented, but was last checked with Processing 2.0b7. The first user interface tried use one screen and became too messy. It was split into an instructor screen and student screen. The second user interface designed is presented in this video. See the operations user manual below for the final result. |
Attendance Information
|
---|
The goal is to focus on reliably accumulating attendance information, not analyzing it. It should be saved automatically, and be review-able at the end of an event. It should capture the following information:
|
Implement
[edit | edit source]Choosing Scanner
|
---|
![]() Purchased a TaoTronics TT-BS003 usb cabled scanner because was cheapest in Amazon at the time. Out of the box it registers as an input device as if it were a second keyboard. When aimed at any barcode, outputs text into what ever program typed characters would normally appear in. The trigger doesn't do much other than force the start of a scan. Can mount and then pass items with bar codes underneath it without touching the scanner video. Looks like this scanner cost about $50, a wireless version costs $80 and a version without the stand costs $30. |
Printing Bar Codes
|
---|
The next step was to figure out how to print unique bar codes for each student. There are lots of different formats, and lots of "free" software to print bar codes. Code 39 was settled upon because it exists as a true type font that can be downloaded. Text is then turned into a bar code by selecting the bar code font.
Testing on an inkjet printer showed it can scan fonts 10 point or larger. The bar code must begin with * and end with a * otherwise it will not scan. The font translates ! into a *. |
Printing bar code with processing
|
---|
This is the processing pde. It generates a file TestPrint.pdf in the sketch directory. If the file already exists, it fails. Delete the previous file first. Automatically printing the PDF can be done with FoxitReader which requires a DOS batch file to be written. The processing sketch silently starts this batch process which would delete the file when done. PFont font; // The font IDAutomationHC39M must be downloaded // in the operating system ... other programs must see it import processing.pdf.*; PFont myFont; void setup() { size (320,40, PDF, "TestPrint.pdf"); myFont = createFont("IDAutomationHC39M",12); fill(0); background(255); textFont(myFont); } void draw() { text("*FirstLast0123456789*", 15, 30); exit(); } |
CSV file processing
| ||
---|---|---|
![]() This program was built by looking through the processing.org. Started off with getting loadTable() to run. Biggest problem was figuring out that the csv file had to be in the data folder. Kept getting "null pointer" error messages when it was not. The next step was storing everything in a several string arrays. The array reference shows integer and number arrays, but not strings. But the description talks about string arrays so seemed possible. When the word string did not change color in the IDE, String was tried. Capitalizing S was the difference. Could not figure out how to find the number of students and then set the array size, so made 120 the max number of students ... arbitrarily. If the number is fewer, the program works. If roster.csv has more students in it, then probably will get an error message when it runs. just change the size in ScanGUI16 at the top where the variables are defined. Comparing strings was difficult. Tried == but didn't work. The .equals method is not on the reference page. The "while" command to pad the student id with leading 0's because they were lost in canvas worked correctly the first time. Tried saveStrings() to save the drop down list, but saved the word "null" for the 120-class size students. So had to go with PrintWrite which is more verbose. Had to add path to the data file so the actual file is created in the data directory where the GUI drop down will look for it.
|
Keyboard processing
|
---|
The function keyOrScanner is called by the instructors window through the gui tab through the process textWindowKey and called by the students window through the ScanGUI tab, keyTyped function. It has three main functions:
|
Emerging logic states
|
---|
The goal of object oriented programming is to discover re-usable chunks of code, name them, test them, document them and add them to one's personal and the worlds tool box. Programming then becomes more like decorating a room. The starting point for this analysis seems to be the main program, ScanGUI. Global Boolean data types seem to set up a subsystem of flags that interrupt normal operation flow. Next the gobal variables need to be examined. This is sort of like judging a mechanical assembly by counting it's moving parts, assembly steps or screws. Minimizing the numbers would seem to be the goal. Counting them would indicate the relative usefulness, health of the objects and yet at the same time a large number may indicate the birth of something new, .. something doesn't fit the world at the moment. The variables seem the most important to describe are associated with "states" within the program ... which evolved and need a work:
Initialized False in ScanGui. Looked at in ProcessEvent when activity is (arriving & clicker) to alternate between creating a student ID scanning event (is false) and clicker scanning event. The default value is "false." It is set "true" only after recording student ID in recordAttendance. Is set false recordClicker. Value can be "true" but never looked at because recordAttendance sets it "true" no matter what, yet only ProcessEvent activity (arriving & clicker) looks at it. All other activity ignores it.
Initialized "checking out" in ScanGui. Set to "checked out" and "checked back in" in processEvent. Turns into a boolean type flag in recordClicker to determine current state: "already checked out", or "never checked out." Primary use is to prevent the same clicker from being checked out to two different students. Can be checked back in multiple times ... so that an entire bag of clickers can be scanned again in case one was missed.
Contains clicker bar code number when scanned, otherwise is empty. Turns into a state variable that has to be reconstructed from past transactions with the current date in cvsProcess. Is used to determine which student is assigned to a clicker when clickers are returned without identifying the student. Just find this clicker number in the array and then the student is known since they share the same element number in the array. Is used to make the description of the transaction that appears on the student window.
Set to "arriving" in ScanGui. Set to "arrived" in recordAttendance. Is just text label and has nothing to do with a state.
Set initially to "not here" in cvsProcess .. or restored from the last mention in description column with today's date in the attendance.csv file. Used primarily to update display of student window. Used to determine "never here" when trying to mark "left" in processEvent or if scanning twice in recordAttendance.
Initially set to "hasn't arrived yet" in cvsProcess, or is restored from last mention in description column with today's date in attendance.csv file. Used primarily to update display of the student window in drawStudentWindow and processEvent.
Initially set to a space in cvsProcess or "Left" if a leaving activity was detected for the student in the attendance.csv file for the current date. Is set to "Left" in processEvent if the event activity is leaving. Primary use is to produce the error message "never arrived" when trying to leave. |
Transaction Processing
|
---|
A transaction causes a horizontal row in the output file. It is triggered by scanning something successfully, the "Manually record attendance" button on the instructor's window, or the "Grade Question" button on the instructors window. The tab "fileOutput" has four functions:
The saveTransaction function creates bunch of batch files because appending files and deleting files through processing/java was not figured out |
Operate
[edit | edit source]Taping Bar Codes to notebook
|
---|
|
Installation
|
---|
Dependent Software The following needs to be installed in order for the program to work:
Required Files There are a number of *.PDE files that need to be program folder. Within the program folder must be a data folder. In the data folder will need to be a G4P folder containing data associated with the user interface. An attendance folder needs to be created, but nothing should ever accumulate in there. It is used temporarily during the attendance recording process. Initially there have to be two files in the data folder:
Program Generated Files The program creates lots of files within data including:
|
Canvas Roster Extraction
|
---|
Processing programs are called *.pde files or "sketches". They are each stored ina a folder. The folder has to have the name of the main sketch, csvTest in this case. Each sketch folder has a data folder. This is were the sketches store files needed to start and work. If these files are missing, often the error message is "Null Pointer." The CSV file downloaded from the Canvas gradebook needs to be stored in the data folder with the name "roster.csv". It has to be there to start the program. It should not be edited in any way ... unless to remove columns that may contain student grade information. Processing writes by default in the sketch folder, not the sketch data folder. At startup this scanning program reproduces a new list of students called rosterList.txt from roster.csv every time it is launched. This is because students drop, add or move around sections. The goal is to have the most current list of students at the beginning of the attendance taking event. |
Stopping and Starting
|
---|
Most problems starting are associated with an external web cam not getting enough power through the USB port. Initializing causes the camera to reset and then ScanGui can hang or crash with a Java error message associated with "Null" or a blank Student Window. In these cases, terminate the program and start over again. ScanGui is ideally started at the beginning of an event and turned off at the end of the event. If is restarted during an event, it will search through previous transactions, restore the state (arrived but not left, clicker checked out but not back in, already arrived, already checked out, ...). However it only restores this data from events with the same date. This makes a single machine very robust at recovering all information necessary to record a single event. However there will be a problem when there are two attendance events for the same student on the same date. For example, if a student doesn't turn a clicker back in, they will not be able to check one out at the second event. (current feature) A student will not be able to leave twice because they "already left" the first time. (current failure) There are two solutions:
When attendance.csv is renamed, a new one will be built. Someone manually will have to keep track of all these csv files and process them through a separate program that applies a grading rubric. Pressing save is not necessary. Data is saved after 10 minutes of inactivity. Stopping is done by either clicking on the X or stop of the student window, or clicking on the square top button in the Processing IDE. |
Messages
|
---|
Messages appear on the student window bottom left and the instructor's window upper right. No messages should appear within the Processing IDE unless something is going wrong.
|
Analyzing attendance data
|
---|
The attendance.csv file is a single spreadsheet with the following columns:
This information should be enough to provide attendance data for any rubric. |
Demo
[edit | edit source]video
Next Steps
[edit | edit source]- Design state diagram for arriving, leaving and clicker status .. that meets expectations for all possible failure modes (program restarts forcing restore of state information) and multiple attendance events on the same day with the same machine. Currently same machine only works as expected through one attendance event per day. Multiple attendance events on the same day will cause previous event problems to impact current events ... such as not being able to arrive at a second event because already arrived at the first.
- Make fileOutput generic to all OS .. right now it has become windows specific through the use of batch files
- Add a leaving & barcode option to the event activity list and support this in processEvent and recordAttendance tabs
- Add students picture to the instructors window
- Figure out how to print directly to an OS printer from Processing/Java rather than use batch file and third party software
- Add code to list all webcam modes in a drop down box so that each can be tried by an end user rather than the programmer try "by hand" and enter hardware specific information into the code.