Technology

Spirit Guide uses various pieces of technology.

A general diagram of the system.

Java

Java was chosen for the backend of the system for its power and platform independence (we were not sure whether it would be running on Linux, Windows, or Mac).

The server was developed using Eclipse and tested on Linux and Windows. It is multithreaded and allows for as many connections as needed. This was done to allow the arduino to have a connection to the server that was independent of the GUI.

The server accepts the following commands:

• getBottleList - Returns the list of bottles that the bar has in stock.
• getBottleListWithLevels - Returns the list of bottles that the bar has in stock along with their actual stock levels and capacity.
• getDrinks slot - Returns the list of drinks that can be made from the alcohol in the given slot along with some information for displaying the drinks (ice, glass type, colour, etc).
• getDrinkInfo drinkname - Returns all of the information for a given drink.
• removeShot slot - Removes a shot from the bottle in the given slot.

MySQL

MySQL was chosen for the database. An Entity Relationship diagram was drawn up to better visualise the required database.

The ER diagram for the database.

The ER diagram was then mapped into relational schema:

The database was tweaked a little further as the project progressed.

Arduino

An arduino was used as the microcontroller for the bar. It was meant to handle shot dispensings by the user.

Flash

Flash was used for the GUI because of its ease of creating animations. XML Sockets were used to allow the GUI to connect to the server. The GUI was developed by Rob.

Timeline

The project loosely followed this timeline:

Skills

Although the skills sessions were generally interesting, they were only useful for one thing: we learned that Arduinos could connect via sockets.

Most of the skills that I needed for this project were learnt outside of any of the skills sessions. I already knew Java so writing the server was just a cycle of code/test/revise. Having worked with databases several times before, the database was a matter of drawing up an Entity Relationship diagram. The ER could then be mapped to a Schema and turned into the database definition.

Some useful advice came when we attempted to connect the arduino to the server. It would not connect via the usual socket way (whereas the Flash interface worked fine). We were helped out by Dekker and Doug and got it connecting, albeit not reliably.

Process

A long time ago in a wiki far far away...

We originally had the idea of a complete shopping system but after hearing another group with a similar idea we decided to make the alcoholic equivalent.

We began researching some of the technologies we might use and drawing up a rough development timeline. We found that we had a choice for the micro controller between an arduino and a phidget. Tyson constructed a 3D model of the intended bar to get a feel for what was needed and where things would go.

A rough sketch and Tysons 3D model of the bar.

Nathan researched the feasibility of using one micro controller over the other and designed the posters to present at the crit.

We presented our idea and the project was given the green light for production. After the planning phase we had to find another group member. Luckily Rob was keen to join the project.

We started brainstorming some ideas for bringing the project from an idea into reality. We realised that making the shot dispensing mechanism from parts might be a bit too hard so we decided to just use a pre-made shot dispenser and just record when a shot is requested. This would also make it easier for the arduino because it would not need an output as we wouldn't be using motors any more.

The old dispensing idea with motors and the new dispensers.

We then brainstormed ways of implementing an interface. We looked at using Director but quickly disregarded it because we had more experience using Flash and preferred using it to Director. So we made the decision to use Flash for the GUI and have it talking to a Java back end.

Rob started the interface with a simple test reading from xml files just to get some dynamic-ish content happening while the actual server was being written.

Nathan started the server by making a really simple Java app to handle a client connection and just print to the screen when one had connected. This worked fine so he made the server a little more useful by adding a bit more functionality. Nathan also changed it to be multi threaded because it would not only need to handle a connection from the GUI but it would also need to receive messages from the arduino.

Screenshots of the server (and test client) performing some basic commands.

Once Nathan had finished a basic server we tested it to see if the GUI would work yet. It connected... it sent a message to the server.... but failed to listen for the response. We tried a few variations of the code in an attempt to find the solution. After a few failed tests we found another possible solution... and it worked! Turned out the only reason Flash wasn't receiving a reply was because it didn't know the reply was finished sending. We added a '\0' (null/EOF character) to the end of each message and finally the GUI was able to communicate fully with the server.

We did not end up using the breathalyser.

We decided not going to use the breathalyser and buy a kit for J.R. but started to run out of time and the idea has been put on hold till the main part of the assignment is finished. With any luck we will still be able to add it to the final product.

The major problem with the keypad is that if it were to get wet then it might not work properly. We have decided to put a waterproof protection over the top to solve this. The idea we are running with at the moment is dissecting a rubber dish glove and using that because of it's water tight, and slightly elastic.

The keypad would need a waterproof disguise.

Construction of the bar began with Tyson combing the isles of Bunnings for several hours looking at anything that might be of some use to help with construction. Originally the wood that shelved the bottle was from a old desk, it looked to be large enough but once we tried to put bottles inside we found that it was too small. The original design for the bottle holder had a piece of wood running horizontally like a spin, but we found that some bottles where too wide were no longer able to be strapped down. This lead us too our current design. After another 4 or 5 trips to Bunnings we eventually got all the bits and pieces we needed and the real fun began.

The bar was made up of 2 normal desks that had had their tops removed and replaced with the bar top. The bar was then surrounded by lino (conveniently with a wood pattern on it). The wood was varnished and the bar was ready to be wired.

When it came time to connect the arduino to the system we encountered a problem - the arudino did not like connecting to the server using a normal socket connection. We had found examples of arduinos working with Flash so we decided to just make a work-around involving a seperate Flash file whose sole purpose was to listen to the arduino for dispenser requests.

We wrote the sketch to be run on the arduino and after some testing and altering of the program we got the code to compile. When we tried to upload the program to the arduino we kept getting an error stating that the 'programmer was not responding'. We tried it on a different computer and it uploaded fine. We did some initial testing to see if the buttons would show a shot being dispensed. They did. So we hooked everything up to the bar only to find that it no longer worked. After testing and rewiring and testing and rewiring we could not get the arduino to work the way it had before.

The bar.

Problems/Solutions

#	Problem	Solution Ideas
1	Shot measuring mechanism might be too difficult to make from scratch.	Get a premade shot dispenser and rig it to register when a shot is poured.
2	GUI should have animation (Java animation is time consuming)	Make GUI in flash and use XMLSockets to communicate with Java backend
3	Once we cut the hole in the bench top for the monitor we will have to cut a 5mm deep and wide groove to try and make the perspex flush with the bench.	Im thinking of doing it one of two ways. the first is to be really careful and use a hammer and chisel and hope i can keep a straight line. and the second is find out if you can set a jigsaw to a certain depth to do the top cut then chissel the other.
4	Removing and extending the screen from the breatherlizer. Also changing the power from 2 AAA batteries to DC power.	Any Suggestions anyone ????????????????
5	Fitting the wood into the car to get it back to uni.	Wood was in small enough pieces to fit into car.
6	Attaching lino onto metal legs	Glue bits of wood onto the legs then staple the lino onto the wood
7	Keypad getting wet and not working	waterproof covering that still allows the keys to be pressed down easily
8	Masking the ugly cut for the monitor window	bits of tape around the outside as a border
9	The CRT is too big and heavy to be a practical visual display unit	Rob has an LCD we can use.

Exhibition

Exhibition made for an interesting night. Unfortunately, the bar was still not working the way it was meant to and, once again, it was an arduino problem. Even though we did not get the bar working fully we still had a fair amount of interest from people over the course of the night. The one thing I believe was stopping people from actively engaging with the bar more was that they felt intimidated. They were intimidated by the fact that their 'playing' with the bar would have a lasting impact on the status of the bar. For example, when a user watches a movie project they do not change the movie in any way and it is exactly the same for anyone who sees it. However, for the bar, any time a user came and tested the dispenser they were using up a resource (taking liquid from the bottle) and I believe that people generally did not like the idea of changing the project in this way.

The bar on the night.

Reflection

This project furthered my dislike for working with hardware. I am more of a software orientated person so I prefer to write the code than wire the hardware. After a few hiccups along the way the software side of the project was working fine. Too bad the same could not be said for the hardware. I believe the arduino only worked once, annoyingly only when it was not connected to the actual bar. However, I believe most of the reason we had problems with the hardware can be credited to dodgy wiring; I am sure there was something simple that we kept missing that was causing the problems. More time may have lead to us solving the problem.

If I was to do the project again, I would probably opt to use phidgets. Our initial intention to use arduinos came from the idea that phidgets would be too popular and would be booked out. We were also swayed by the lower price tag (just in case we did need to buy anything ourselves). In hindsight, the sheer simplicity of using the phidgets should have been the entire basis of our decision but at least we have learned for next time.

Even with the fact that the bar never worked to its full intentions I thoroughly enjoyed working on the project. I liked the challenges the project presented and I believe that we worked hard in trying to overcome them. I especially liked using the wiki to document the project. It gave us a central place to document our work that any of us could edit at any time.