FabCache: a Modular, Scalable, and Traceable Locker System

This project is done by students from Singapore Polytechnic. The project group is comprised of: William Tan and Fong Jia Yi with Mr Teo Shin Jen as our project supervisor.

The Idea:

FabCache is a locker system that is modular, scalable and with an integrated data logging function that is suitable for deployment in the various labs in SP such as the FabLab, TechShop, or MakerSpace.

As its primary intended place of usage would be the FabLab in SP, its name is a portmanteau of the word 'Fab' from 'Fablab', and 'Cache' from the idea of a storage space.

The FabCache is scalable, as more units can be added as the need arises, through the use of the I2C standard. This is a standard feature across all units. The modular design allows for units to be added or removed according to demand.

FabCache offers a temporary, secure, and traceable storage solution for asset/materials with minimal value in public spaces where such storage is required.

Items needed:

-Acrylic pieces

-Servo Motor

-Wires

-Veroboard

-Arduino Uno

-Hinges for locker door

-Keypad and LCD unit

The locker's physical shell is comprised of several laser cut acrylic pieces:

1. 2 pieces which form the cross-section, forming the 4 compartments for item storage.

2. 6 pieces which form the outer case of the locker unit.

Apart from that, an acrylic piece with suitable cut-outs for the keypad and LCD is also used, protecting their electrical contacts.

Please refer to the attached file for the templates which our team used in the process of laser-cutting.

In order to connect the acrylic pieces together, several 90 degree adapters are used. These align with holes near the edge of each of the outer pieces of the acrylic sheets, and are used to provide structural rigidity to the unit.

Future Iterations:

We are exploring an alternate design with interlocking pieces. These can be fabricated easily with a laser cutter. Naturally, in the interest of security, this alternate incarnation of FabCache will come with its edges glued together.

Step 3: Cut out an arm for the servo motor and also design a locker catch to form the basic locking mechanism.

Future Iterations:

The current design of locking mechanism requires a servo to rotate an acrylic arm. We are also exploring different designs which employ solenoids instead of servo motors, as the former may yield a more secure design.

The laser-cutting template includes doors by default. Attach these to the front piece of the unit with hinges.

Future Iteration:

We have noticed that the width of the door is limited, and plan to expand it to allow users to place items of larger dimensions in our locker. This would greatly improve its versatility, as a locker which can only store small items is of limited use.

In the case of our project, due to the fact that this is a prototype, we have opted to create a cover for our locker. Simply put, this upper partition is a cavity created above the storage compartment by putting a lid over it. For our prototype, we have used it to store the power supply board and micro-controller boards.

Future Iteration:

The next version of FabCache, we will be incorporate the circuitry within the body of the locker itself. As opposed to the tangle of wires currently residing in the upper partition, we are planning to use a Rainbow wire for the connections to the LCD, and the keypad.

In order to create a quick and easy way of powering our components, we have created a simple power supply board, with multiple 2-pin molex header, with each header being linked to the others. This provides us with a simple solution to supply power to the Arduino Unos, and the servo motors.

Future Iteration:

In a future iteration, we plan to design our own PCB in Fritzing in order to create a more elegant solution. That costs more though, and we prefer to perfect our design before doing so. Fail often, fail early - it would be costly if we made a mistake at a late juncture in the process of improving FabCache.

With the number of individual cables needed for connecting the LCD and keypad to the Arduino Uno residing in the master unit, we decided to solder these cables directly to a stripboard, which we then plug into the Arduino via use of headers with long legs.

This is our crude, homemade version of an Arduino shield. Although it isn't exactly a sight to behold, going down this route saved us much time in connecting the components together when we had to troubleshoot things.

Please refer to the following for the schematic diagram of FabCache.

In our project, we have created 2 versions of our code for the lockers.

TL;DR:

If you want to skip the technical explanation, here's what to do:

1. Upload the master code to the unit with a keypad and LCD connected. The file for this is "Master.ino".

2. Upload the slave code to the slave unit. The file for this is "Slave.ino".

Technical Explanation:

For the master unit, the coding got a little complicated. For the benefit of those viewing this Instructable, here's a brief explanation on how the code works.

1. Obtaining data from the keypad:

- Now, this project was originally intended for the PIC 18 microcontroller used in Singapore Polytechnic, but as we found that the Serial Monitor function which the Arduino platform provided was easier for exporting data than the former, we thus opted to go with the latter for our project.

- This means that we have a dilemma: The keypad which the school provided to us uses the 74C922 decoder, which means that we had to do some reverse engineering to make it work with the Uno. This is worth the trouble though, as it saves us 2 pins over the 7 pins required by default in the Keypad Library. In essence, the keypad has 5 outputs - a data available output, which goes HIGH whenever a key is pressed, and D, C, B, A bits, which make up a 4 bit representation of whichever key was pressed.

Hence, the initial portion of the code works by reading the outputs of the keypad decoder only when the Data Available pin goes high, but remember this - the digitalRead function is matched with one variable, and with 4 data bits, this means that we have 4 variables. This is fine, but all of them are in the LSB position!

In this case, a little rudimentary knowledge of programming helps - enter the bitwise shifting function. By making use of the bitwise shifting function, we are able to restore the 4 bit data output which the decoder provides. As bit D is the MSB, we perform a left bitwise shift, shifting it by 3 positions, C by 2 positions, and B by 1 position.

In essence, here's what happens:

Legend:

|3|2|1|0| = Refers to the individual bit positions in the binary data. |3| refers to bit 3, or the fourth position. |0| refers to bit 0, or the first position.

Original input:

|3|2|1|0|

|NIL|NIL|NIL|D,C,B,A| (As you can see, bits D, C, B, and A are all in the bit 0 position, which is incorrect!)

After bitwise shifting:

|3|2|1|0|

|D|C|B|A|

(This is the original form of the data, and this means that we can now make use of this to read from the keypad!)

Now, notice that our keypad is arranged in the following format:

1, 2, 3, F,

4, 5, 6, E

7, 8, 9, D

A, 0, B, C

What this means is that we have to arrange these into a pattern which we can use to match the unique 4 bit number generated by the decoder for each key to the actual key.

Hence, using a character array, we have

char charSet[17]="123F456E789DA0BC"

(this is extracted from the code)

What this means is that when the key '1' is pressed, the decoder returns the 4 bit value "0000", which corresponds to position 0 in the character array, which is '1'. If 'C' is pressed, the decoder returns '1111', which corresponds to position 16 in the character array, which is 'C'. If you happen to notice that our character array is 1 digit higher than it needs to be if this were done in C++, fret not, as this is part of the syntax in the Arduino IDE.

Congrats for making it to here! You have now understood the method behind interfacing with a keypad using a 74C922 Keypad Decoder!

2. Making use of the entered Data
- Now, if some thought is given, you would realise that we have run into another predicament, which the method by which we would make use of the entered data. At the moment, all we have is the individual characters which is returned whenever a key is pressed - not very useful on its own, isn't it? Now, we move on to the next step, which is joining the data together.

Notice that when we press a key on the keypad, it is received by the software as a character variable. The beauty of using a character variable is that we can use concatenation to join up these individual characters, much like writing consecutive letters to form a word. Now, in our case, as the administration number in SP is 7 digits long, we will concatenate 7 characters until we reach the desired length.

However, before we proceed to manually concatenate the 7 characters individually, we can make use of a for loop to make things easier for us!

Here is the sample code for the for loop

for (int i=0;i<7;i++) // Using a for loop to concatenate the array
{ xa += String (adminnumber[i]); //xa is the string which represents the admin number }

Now that that's done, let's store this value as an integer. Note that in the program, we use the long integer variable (which is declared as long adminno in the program). This allows us to store the 7 digit administration number properly.

Similarly, for the locker's ID and locker unit number, the concatenation method is used to store the information which the user enters.

Now that we have the user's administration number, Locker ID, and Locker Unit, we can allow the user to use the system for real!

Here's a general description on how the program works.

The moment where the user finishes entering his administration number, it will be transmitted to the datalogger unit, which has an i2c address number, (In this case, 100 is used) and the Serial Monitor respectively.

This is followed by the locker ID, which is sent to the various logging devices. The variable which represents the specific partition which the user wishes to access is sent over the i2c bus, which unlocks it.

Why the use of the I2C standard? Simply put, it's readily available in the form of the Wire.h Arduino library. The pins required to make use of this already exist on the Arduino Unos which form the backbone of our project (pins A4 and A5). What's more - no extra hardware is required for communication between devices over short distances, short of a few simple resistors.

Units needed:
- FabCache Master unit

- FabCache Slave unit

Note though, that a unique for each servo motor which functions as the lock. In our case, we achieved this by using the switch function, and assigning a unique code to each lock.

Also, all the units are interconnected via the I2C bus.

Future Iterations:

The downside of using I2C bus is that it has a limited bus length of approximately 1m, and requires a repeater (purpose built IC chip for I2C) to amplify the signal over longer distances. The maximum devices supported on I2C bus is 112 at a time.

http://www.esacademy.com/en/library/technical-arti...

Here's a rough outline of how the user uses FabCache:

1. User enters his administration number to help the Technical Officers identify which students accessed the system

2. User enters the address of the compartment to retrieve a part.

3. The specific compartment is unlocked

4. User collect the part

5. Compartment must be locked by pressing 'C' on the keypad

6. All these information (Admin number, Locker Details) is then sent to a logging device, such as a PC. This information can be accessed via Serial Monitor, which can then be copy-pasted for storage.

Future Iterations:

1. Password to lock/unlock

2. Distribution method of aforementioned password to lock/unlock (e.g. One-time password)

3. Saving information directly to a text file, makes logistics easier!

Check out our video in the link below:

https://www.youtube.com/watch?v=fNWq4qG2A2k&feature=youtu.be