The bar inventory system was an interesting project, because it involved both hardware and software together, since we are comprised of one analog designer and one computer programmer, both of whom are alcoholics. On the hardware side, there are sensors and wireless communication, and on the software side, there is data encoding and clever data manipulation.
Also, it was an excuse for us to drink for class, and not because of class.
High Level Design
Rationale for Project Idea
The project idea sprang from the concept of smart refrigerators that keep an inventory of their contents. However, we feel that alcohol is more important than food, so we wanted to make sure we didn�t run low at any time. Therefore, slowly the project morphed into an inventory system for commercial use in a bar. The project was intended to be adjustable and convenient for any bar.
Background Math
Some background math was necessary, because we wanted the system to be practical. It is not practical for users of the system to know the exact mass of a liquor bottle, so a scheme was developed that would require just an empty bottle and a full bottle to calculate both a minimum and maximum �weight� for the bottles. The weights were actually just the values obtained from the ADC, since actual mass units were not necessary. These extrema allowed us to calculate percentages:
Note: The force sensor decreases resistance with increased force, and thus the MinWeight is larger than the MaxWeight.
Hardware/Software Tradeoffs
One hardware tradeoff dealt with using the UART on the ATMEL Mega16L microcontroller on the receiver side. The UART had to be reserved for serial communication with a HyperTerminal, so it could not be used to aid in the wireless communication. This also affected the software, because the necessary code for RF transmission became rather tedious and extremely specialized.
The largest tradeoff we had involved communication with a television display. Initially we wanted to be able to display the inventory status on a TV screen, but there were so many synchronization issues involving the RF transmission (which itself had its own timing issues because it was transmitting two different pieces of information) and the serial communication. The main problem was that since we couldn’t use UART for wireless transmission, we needed to manually transmit bits on the order of 1 per millisecond, which is much faster than the clock used for the TV. So, to implement both the wireless and the TV, we would need two timer interrupts: one for the TV and one for wireless. This turns out to be impossible at the level of accuracy required for both of these devices, since multiple interrupts cannot be processed at the same time. It also would affect our budget since we would be required to use a Mega32 as opposed to a cheaper Mega16. Finally, we decided that the output could just easily be outputted onto HyperTerminal without really taking away from the visual experience, because it was primarily a text display.
The final project block diagram can be found in Appendix B.
For more detail: Bar Inventory System: Drinking for Class Instead of Because of Class
