Introduction
The Juicer is a wirelessly controlled, programmable juice maker which will mix each ingredient of a recipe to the exact proportions every time.
The Juicer will take a recipe selection serially via either the keyboard or the wireless remote and dispense the juices into the cup below. Force and Photo sensors are incorporated to control the precise pouring. Wireless communication is controlled with two microcontrollers operating at a frequency of 433 MHz. All of this is housed by a big red frame custom made from 4130 steel.
High Level Design
Imagine hosting a dinner party where you’ll never have to get up and get drinks for your guests. The guests can simply enter their choice at the Juicer base station or you could wirelessly send their selection and have it ready for them to pick up.
The creation of the Juicer came from a combination of things.
We wanted:
• To create something that we will use after the course is over
• Something that would entertain and impress friends when they saw it
• To create a project that blends electronics and mechanics
• To apply our engineering skills while having some fun
Tradeoffs
There were some trade offs we had to make. We elected to use the proto-board rather than the STK500 so we could keep our project in complete working form after we finished. Although it took more effort to assemble the proto-board, it allowed us to satisfy one of the key goals of this project. Moreover, it cost less and allowed us to spend more of the allotted budget on making the frame structure more aesthetically pleasing to the eye.
We also decided to use RS232 communications and a computer for the user interface. We initial thought of using a keypad and LCD but elected not to in an effort to reduce costs. The complexity between using serial communications and a keypad and LCD is minimal. But by using the serial interface, we were able to easily incorporate the wireless RF communications at the last stages because it also worked serially. This tradeoff we made actually made our project more scalable for things such as the wireless RF remote control.
Another trade off was sampling inexpensive force sensors where resistance changes with change in force applied. The resistance however was not linear to the amount of force placed on the sensor and thus require software computations to interpret the output.
Moreover, we had to decrease the baud rate of the serial connection to 4800 baud to accommodate the wireless communications. The wireless transmission seemed to be unreliable at 9600 baud. By reducing the baud rate, we slowed down the software’s ability to input and output serial data. However, this was not a crucial problem since the Juicer received only short input strings.
Standards and Trademarks
The Juicer is in compliance with FCC rules concerning Radio Frequency Devices located in Part 15 of Title 47 of the Code of Federal Regulations. We operate at a frequency of 433 MHz and transmissions are in bursts less 10% duty cycle.
We used Poland Spring 2.5 gallon spring water containers to hold our juices. We understand that they hold the patents and trademarks associated with their bottled water.
We also use solenoids and force sensors which are patented by Guardian Electronics and CUI respectively.
The Juicer is created for private personal use only and will in no way be commercialized and thus, should not infringe on existing patents.
Design
Overview
Our initial vision was to have the microcontroller control the opening and closing of three containers. The duration of the opening would simply be timed assuming a constant flow. After further thought, we concluded that this was inadequate and simple feedback was essential for a true working model which we could keep and use in the future. Further, we wanted to challenge ourselves by creating the metal frame entirely from scratch and also incorporate a wireless remote control to the control the Juicer from anywhere with the wireless range.
Juice Dispensing
Our initial consideration and one of the early challenges was coming up with a good inexpensive way of dispense the liquids. Our main concerns were that the containers must hold a lot of juice and that the dispensing mechanism needed to be cheap so we could stay within budget. Ideas ranging from pumps, solenoid valves, stepper motors finally concluded with pull solenoids controlling a modified Poland Springs 2.5 gallon spring water container that was spring loaded and naturally returned back to the closed position.
Software
The software is essentially one giant statemachine that is broken down into smaller ones for the ease of debugging and readability. We begin here with at top level design diagram.
From the stationary Juicer, the user will have the choice of making a selection, programming a new recipe, or show all the recipes. Each of these second level states will also branch into their own state machines which we will describe more in detail below.
From the remote control, the user will only be allowed to select from the first three recipes in the database. No programming or showing of the database is allowed since we wanted to make the remote compact and thus only mounted three control buttons.
After each command is complete, it will return back to the main menu and await the next selection by the user.
The pouring or opening of the solenoid controlled valves are controlled by the pouring routine. This routine will start with the first container and check the database to see how much to pour. The amount that is poured is determined by the force sensor that is placed below the cup. When that calculated amount is reached, it starts pouring the next container. This is repeated until all three containers are cycled through.
The initial weight of the cup is recorded before each drink is poured. We subtract out the initial weight of the cup so we can measure only the amount of fluids we dispensed. This allows us the versatility to use different cups of varying weights.
One main difficulty encounter in this step was the non linearity of the force sensor. The resistance of the force sensor did not increase linearly with the amount of force applied. This forced us to make a linear interpretation of the output of the force sensor which is not as accurate as we would have liked. Also, the placement location of the cup on the metal platform also changed the force sensors reading introducing yet another variable.
Note that the photo resistor sensor can be placed near the top of the cup to detect if the fluid is at that level. While pouring the drink, if the software detects that there is enough change in light from the photo sensor, it immediately stops the pouring cycle. The photo resistor is currently mounted on the frame and used as an emergency stop button. Simply place your finger over the sensor and pouring will stop.
The show recipe routine simply cycles through the entire database and displays the proportions of each ingredient. This consisted of a simple loop through all of the possible entries.
The programming of new recipes was achieved by taking user inputs from the keyboard. A display shows the user the format in which the program expects the inputs. The user simply enters the proportions of each ingredient.
Since our Juicer is programmable, the database is saved even if the power is switched off. We used the EEPROM feature of the Atmel Mega32 chip for the storing of the recipe data.
RF Wireless
The RF wireless portion consisted of software that went on the transmitter and also software that went to the receiver. The receiver software was integrated with the software that runs on the base station, while the transmitter software was placed on a microcontroller solely dedicated to transmitting the user’s remote selection.
The RF wireless operated at a frequency of 433 MHz. Since these devices are not unique in their frequencies and that many other groups used the same devices, we needed to devise a method to guarantee reliable communication in an air space polluted with noise. This was another difficulty that we encounter. Our solution was to transmit our packets using a unique pin that only our receiver would know. The transmitter would begin by sending a series of DC balanced characters followed by our unique pin character, followed by the command then followed by our pin again. This surrounded our command with a header and footer pin that was unique. And only when we received the data in this sequence did we process the command and begin to pour. This reduces the possibility mistaking noise, or other group’s transmission, for the real thing.
At first, we attempted to transmit some DC balanced characters followed immediately by our command. This did not work reliability since many other groups were initiating their sequence with DC balanced characters also.
We also attempted to communicate at 9600 baud but found that 4800 baud was more reliable. At the higher speed, we were unable to sustain repeatability and thus chose to use the slower but steady 4800.
Hardware
One of the microcontrollers is used to control all of the functions of the base station and also receive RF transmission while the other microcontroller is used to transmit data only.
The microcontroller on the base integrates a multiplexer onboard to control input from the keyboard or from the RF wireless input. The selector of the mux is a jumper which either takes its signal from ground or from the 5 volt vcc. This selector signal is also polled by the microcontroller so it knows what data to expect. So changing the jumper setting will set the mux input as well as inform the software which mode it should be in. Note that the jumper must always be in one of the two positions. Floating inputs may not achieve the desired results.
In summary, the function of this main microcontroller is to poll for input (wireless or keyboard) and control the dispensing of the drinks based on the feedback it gets from the sensors.
Solenoid and Sensor Control
To control the solenoid motors, we elected to use optoisolators. The control pins of the MCU were attached to the optoisolators which turns on and off the solenoid by controlling a TIP31 transistor. The TIP31 serves as an on/off switch for the solenoid. The optoisolators (4N35) were needed so that the MCU was completely isolated from the circuit. This protected the MCU because there were no physical connection between the MCU and the power supply. The 4N35 works by using a phototransistor that senses LEDS when the device is turned on.
Parts list:
| Quantity | Item | price/unit | Total Price | Comment |
| 2 | protoboard | 5 | 10 | |
| 1 | rs232 connector | 2 | 2 | |
| 1 | max233CPP | 0 | 0 | sampled maxim-ic |
| 2 | mega32 | 8 | 16 | |
| 2 | wireless | 4 | 8 | transmitter and receiver |
| 3 | solenoid | 3.5 | 10.5 | all electronics |
| 1 | force sensor | 0 | 0 | sampled |
| 1 | photoresistor | 0 | 0 | from bruce |
| 1 | mux max4053 | 0 | 0 | another group |
| 1 | netgear ac/dc | 0 | 0 | had |
| 1 | frame metal | 0 | 0 | scrap |
| 1 | white board | 0 | 0 | had |
| 3 | poland spring jugs | 0 | 0 | had |
| 1 | paint | 2 | 2 | home depot |
| 1 | strap | 0 | 0 | had |
| ? | resistors and electronics | 0 | 0 | lab supplies |
| Total | 48.5 | 1.50 to spare |
For more detail: The Big Red Juicer
