Project

# Title Team Members TA Documents Sponsor
9 Automated Cocktail/Mocktail Maker
Benjamin Kotlarski
Dominic Andrejek
Nick Kubiak
Wesley Pang design_document1.pdf
proposal1.pdf
# Automated Cocktail/Mocktail Maker

Team Members:
- Dominic Andrejek (da24)
- Benjamin Kotlarski (bkotl2)
- Nick Kubiak (nkubi2)

# Problem

Making cocktails or mocktails can be a tricky situation at times. You have many different ingredients that you must accurately measure and are very prone to human error. In social settings this can also be a somewhat time-consuming and inconvenient process. While some automatic drink dispensers already exist, most are expensive, very large, and have many limitations.

# Solution

An automated cocktail and mocktail mixing machine can fix this. Based on a user's input, the system will dispense a precise amount of the specific liquids needed to make that drink. There will be a sensor to check for cup presence so liquid is not spilled everywhere and user input will be done through either buttons, a small graphical UI or potential voice. The system will contain multiple containers to hold liquids with pumps or solenoids to connect them to the cup that is controlled by the microcontroller. Some type of weight sensors will also be implemented to make sure the correct amount of each liquid is dispensed. For use, if a cup is present and a user gives a recognizable command from the pre-defined recipes the microcontroller will start activating the appropriate pumps/solenoids to drive the correct ingredients to the cup to make the desired drink. Our design will be a more affordable solution (using much cheaper materials) that more residential users will be able to use and enjoy the precision and luxury of properly measured out drinks without needing external and premade pods or absurd prices.

# Solution Components

## Subsystem 1 - User Interface (UI)

Initially it will be a simple push button, in the future potentially expand or rework into a more complex screen based UI after expanding the pump system so that there are more options with potentially more ingredients to them too. Expansion to multiple buttons for multiple drinks is also a simpler option for expansion once we get an initial drink working. Here is an initial button we can use ​​16mm Panel Mount Momentary Pushbutton - Red Product ID: 1445


## Subsystem 2 - Stirring Mechanism

Since these drinks are being produced by two different liquids, they are naturally required to be mixed by some means. Thus, the purpose of this subsystem is to automate the drinks stirring process. To do so, it will require two different motors connecting back to the systems microcontroller. The first motor will be in charge of controlling the height of the stirring arm so that it can be lowered into and out of the cup, while the second motor would be in charge of actually rotating the stirrer to mix the drink. In terms of the potential motors which would be able to do this, we found that the linear up/down motion could be handled with a dfrobot fit0806, while the rotational motion can be done with an adafruit 3777. These are both DC powered thus we will use batteries to power our system and if we find issues with either running through batteries very fast or requiring higher power outputs then we will implement an AC to DC converter to allow us to use wall power.

## Subsystem 3 - Pumps and Plumbing

This system will be in charge of transporting the liquid from our housing containers to the central cup. Upon the signal from the microcontroller, the pumps will turn on transporting the liquid from the housing container to the liquid through small tubes. Once one pump finishes dispensing the liquid and is verified as correct, the next pump will turn on in charge of the next liquid and dispense into the central cup. For the tubing we will use small plastic tubing 1/6 in. I.D. x 1/4 in. O.D. Clear Vinyl Tubing. The pumps we will use to control the liquid flow is the Adafruit 1150.

## Subsystem 4 - Intercomponent Communication System

Microcontroller system to communicate between all of the systems. For example sending on a user input the microcontroller will tell the pumps to start taking liquid from the housing containers to the central cup. This also includes various colored LED’s to note the status of each step or whether something might potentially be wrong. This will tell the pump if/when to dispense, how much to dispense, and how the motors should be moving. We will use an ESP32 microcontroller along with our custom PCB.

## Subsystem 5 - Functionality and Weight Verification System

Some weight sensors which verify the amounts/presence of liquids, and also verify that there is a cup present. Each Container (both liquid housing and the central cup) will have a weight sensor below them. The weight sensor below the central cup will have two purposes. The first is that the microcontroller must read a non zero/small value from it along with a user input to start dispensing liquid. Then it will also make sure that the amount of liquid lost from the liquid housing (based on weight lost) is then regained in the central cup so we know all liquid is fully transferred and is not stuck in the tubing. The weight sensors can either have the numbers adafruit 4540, sparkfun tal220, and adafruit 454. This decision will be based on the weight limit we will determine necessary for our application in the design phase. Regardless of which one is chosen, however, all of these require the addition of an amplifier to function. The code for that is hx711.

# Criterion For Success

In its most fundamental and basic form, our project must be able to successfully produce at least one simple stirred cocktail upon a user's input. This must effectively include the following functions. First is the ability to check whether a cup is present before pouring any liquids, as well as check if there is the right amount of the necessary liquids before pouring. Once that is complete, the stirring and pouring mechanisms should move down into place, and the different liquids get individually poured into the cup. The amounts of each liquid should be measured via the weight sensor below the cup so that each time the drink is produced the portions remain consistent. After each respective liquid is poured into the cup, the stirring device should clearly activate, and whenever it finishes the stirring and pouring mechanisms should move back up to their starting positions, with a green LED indicating that the process was completed.

If time permits, however, we hope to be able to expand our goals a bit more in three different ways. The first way was to expand the selection of drinks by having multiple different options available to choose from. An additional and slightly different approach to expanding the drink selections would be to incorporate more complex options as well that would require multiple different ingredients instead. The final goal which we hope to achieve/reach would be to incorporate a more complex and visually appealing UI so that users can easily select between and see different drink options on a screen.

# Alternatives

There are three different categories of alternatives which currently exist relating to our proposed project. The first is a coaster looking device which connects to a phone app via bluetooth to weigh the amounts of liquid you add to your cup and guides you in making your drinks. This product, while the least expensive of all other options, is by far the most simple and the least automated. The next alternative was a fully automated drink creator which worked by having users input a flavor pod for their desired drink, and mixing it with the correct liquor. While this one got closer to performing the same function as our idea, its price went drastically up and it required users to purchase or own the company's specific flavor pods. Finally, the alternative which is most similar to our design is the Barsys 360 Cocktail Maker Machine, which also takes in various liquids and dispenses them accordingly for whatever mixed drink one desires, but that's where its functionality ends. Therefore, besides the fact that it once again has a very large price tag, it also does not have the same functionality of actually automatically stirring the drinks for a user. Important to mention too is that there do exist commercial grade versions of this type of machine, but these ones jump in price even further up to around three thousand dollars.

WHEELED-LEGGED BALANCING ROBOT

Gabriel Gao, Jerry Wang, Zehao Yuan

WHEELED-LEGGED BALANCING ROBOT

Featured Project

# WHEELED-LEGGED BALANCING ROBOT

## Team Members:

- Gabriel Gao (ngao4)

- Zehao Yuan (zehaoy2)

- Jerry Wang (runxuan6)

# Problem

The motivation for this project arises from the limitations inherent in conventional wheeled delivery robots, which predominantly feature a four-wheel chassis. This design restricts their ability to navigate terrains with obstacles, bumps, and stairs—common features in urban environments. A wheel-legged balancing robot, on the other hand, can effortlessly overcome such challenges, making it a particularly promising solution for delivery services.

# Solution

The primary objective of this phase of the project is to demonstrate that a single leg of the robot can successfully bear weight and function as an electronic suspension system. Achieving this will lay the foundation for the subsequent development of the full robot.

# Solution Components

## Subsystem 1. Hybrid Mobility Module:

Actuated Legs: Four actuator motors (DM-J4310-2EC) power the legged system, enabling the robot to navigate uneven surfaces, obstacles, and stairs. The legs also functions as an advanced electromagnetic suspension system, quickly adjusting damping and stiffness to ensure a stable and level platform.

Wheeled Drive: Two direct drive BLDC (M3508) motors propel the wheels, enabling efficient travel on flat terrains.

**Note: 4xDM4310s and 2xM3508 motor can be borrow from RSO: Illini Robomaster** - [Image of Motors on campus](https://github.com/ngao4/Wheel_Legged_Robot/blob/main/image/motors.jpg)

The DM4310 has a built in ESC with CAN bus and double absolute encoder, able to provide 4 nm continuous torque. This torque allows the robot or the leg system to act as suspension system and carry enough weight for further application. M3508 also has ESC available in the lab, it is an FOC ESC with CAN bus communication. So in this project we are not focusing on motor driver parts. The motors would communicate with STM32 through CAN bus with about 1 kHz rate.

## Subsystem 2. Central Control Unit and PCB:

An STM32F103 microcontroller acts as the brain of the robot, processing input from the IMU through SPI signal, directing the motors through CAN bus. The pcb includes STM32F103 chip, BMI088 imu, power supply parts and also sbus remote control signal inverter.

Might further upgrade to STM32F407 if needed.

Attitude Sensing: A 6-axis IMU (BMI088) continuously monitors the robot's orientation and motion, facilitating real-time adjustments to ensure stability and correct navigation. The BMI088 would be part of the PCB component.

## Subsystem 3. Testing Platform

The leg will be connected to a harness as shown in this [sketch](https://github.com/ngao4/Wheel_Legged_Robot/blob/main/image/sketch.jpg). The harness simplifies the model by restricting the robot’s motion in the Y-axis, while retaining the freedom for the robot to move on the X-axis and jump in the Z-axis. The harness also guarantees safety as it prevents the robot from moving outside its limit.

## Subsystem 4. Payload Compartment (3D-printed):

A designated section to securely hold and transport items, ensuring that they are protected from disturbances during transit. We will add weights to test the maximum payload of the robot.

## Subsystem 5. Remote Controller:

A 2.4 GHz RC sbus remote controller will be used to control the robot. This hand-held device provides real-time control, making it simple for us to operate the robot at various distances. Safety is ensured as we can set a switch as a kill switch to shutdown the robot in emergency conditions.

**Note: Remote controller model: DJI DT7, can be borrow from RSO: Illini Robomaster**

The remote controller set comes with a receiver, the output is sbus signal which is commonly used in RC control. We would add an inverter circuit on pcb allowing the sbus signal to be read by STM32.

Note: When only demoing the leg function, the RC controller may not be used.

## Subsystem 6. Power System

We are considering a 6s (24V) Lithium Battery to power the robot. An alternative solution is to power the robot through a power supply using a pair of long wires.

# Criterion For Success

**Stable Balancing:** The robot (leg) should maintain its balance in a variety of situations, both static (when stationary) and dynamic (when moving).

**Cargo Carriage:** The robot(leg) can be able to carry a specified weight (like 1lb) without compromising its balance or ability to move.

_________________________________________________________________________

**If we are able to test the leg and function normally before midterm, we would try to build the whole wheel legged balancing robot out. It would be able to complete the following :**

**Directional Movement:** Via remote control, the robot should move precisely in the desired direction(up and down), showcasing smooth accelerations, decelerations, and turns.

**Platform Leveling:** Even when navigating slopes or uneven terrains, the robot should consistently ensure that its platform remains flat, preserving the integrity of the cargo it carries. Any tilt should be minimized, ideally maintaining a platform angle variation within a range of 10 degrees or less from the horizontal.

**Position Retention:** In the event of disruptions like pushes or kicks, the robot should make efforts to return to its original location or at least resist being moved too far off its original position.

**Safety:** During its operations, the robot should not pose a danger to its surroundings, ensuring controlled movements, especially when correcting its balance or position. The robot should be able to shut down (safety mode) by remote control.

Project Videos