Project

# Title Team Members TA Documents Sponsor
37 Ant-Weight Battlebot - DC Hammer
 Carson Sprague
Gage Gathman
Ian Purkis
 Haocheng Bill Yang design_document1.pdf
final_paper1.pdf
other1.pdf
photo1.png
photo2.png
photo3.png
presentation1.pptx
proposal1.docx
proposal2.pdf
video
# Ant-Weight Battlebot - DC Hammer

Team Members:
- Ian Purkis (ipurkis2)
- Carson Sprague (cs104)
- Gage Gathman (gagemg2)
# Problem Statement
Many battlebot designs struggle with balancing movement control, durability, offense, and defense within the limitations of competition regulations. We need to design a robust and versatile battlebot while following competition requirements (namely weight requirements) that can outlast and subdue a variety of competitors. Primary design challenges for most battlebots stem from the diversity of opponent designs and abilities, often leaning on a particular design element to win. Our bot must be able to remain competitive throughout the full match regardless of the opponent or sustained damage.
# Solution
Our proposed solution/design will take a well-rounded approach to offense and defense, ensuring that our bot can sustain damage and last the full length of the match. Our primary offensive tool will be a motor-powered, sensor-enabled hammer and wedge attachment allowing for multiple methods of opponent submission by housing two “attack modes”, allowing the driver to adapt attack strategy depending on the design of opposing bots. Our design also includes a significant defensive tool in inversion adjustment, by utilizing sensors and physical shape to prevent knockouts via flips. Our bot will remain functional even if fully inverted. Physical components, especially the hammer, must be modular for quick replacement between matches if damage is taken. This well-rounded design will enable the driver’s creativity during the match by automating the offensive tool (hammer/wedge) and defensive tool (flip adjustment), providing the bot significant competitive advantage against all types of opposing bots.
# Solution Components
## Subsytem 1 - Ultrasonic Sensor Enabled Hammer/Wedge Attachment (Attack Arm)
We will embed an ultrasonic sensor into the front of our bot. The sensor will be used as a proximity detector to activate the attack arm motion. The attack arm will have two default configurations for either orientation of the bot. A low position, running near parallel to the arena surface will be used for the wedge attack, upon sensor OR driver input an upward swing will execute, effectively flipping objects in front of the bot. The other arm resting position will stick upward, perpendicular to the ground and upon sensor or driver input perform a downward swing to strike objects in front of the robot.
- Ultrasonic Sensor;
If we can use a pre-emplemented sensor - Adafruit 4007 (https://www.digikey.com/en/products/detail/adafruit-industries-llc/4007/9857020).
If we cannot, alternatively, an infrared LED/detector combo could be used
- Motor (Weapon)
TBD, but something of the sort as follows, primary characteristic is a high torque motor for flipping/smashing
12V 50RPM 694 oz-in Brushed DC Motor (210 grams)
(https://www.robotshop.com/products/12v-50rpm-694-oz-in-brushed-dc-motor)
- Microcontroller Unit
ESP32-S3-WROOM-1 (not dev board, just chip + antenna)

## Subsystem 2 - Gyroscopic Sensor Enabled Control Inversion
We will embed a gyroscopic sensor inside the body of the robot. This will allow the software responsible for translating driver input into motor movement to adjust based on the orientation of the bot. If the bot is flipped over, left turns become right turns and vice versa, which would be a challenge for the driver to quickly adjust. This feature/subsystem will allow the software to make the appropriate adjustments to maintain driver input continuity. Additionally, the orientation measured by the gyroscopic sensor will modify the resting/default positions of the attack arm to continue operation (resting positions and rotation direction must be inverted to continue operation).
- Gyroscopic Sensor
(Potential alternate sensor - Accelerometer - something like MC3416 would do, this should be able to detect orientation satisfactorily)
(https://www.digikey.com/en/products/detail/memsic-inc/MC3416/15292804)
- Microcontroller Unit - ESP32-S3 see above

## Subsystem 3 - Wireless Control/Driver Input + Steering and Wheel Configuration
Our driver will utilize a keyboard for robot control and steering. The W and S keys will control forward and backward motion with A and D controlling left and right rotation. We will also program the F key to switch attack modes between the hammer and wedge and the Space bar as an alternative manual attack trigger. These inputs will be wirelessly communicated to the onboard PCB and microcontroller via bluetooth and translated to the appropriate motors. To enable the tank-turning we will use 4 wheel drive as each wheel/motor will require isolated control. The height of the robot’s body will be thinner than the diameter of the wheels, with the wheels’ axles fixed at the midpoint relative to the thickness of the body. This will allow all four wheels to make contact with the ground regardless of orientation, and maintain drivability.
- Microcontroller Unit - ESP32-S3 see above
- Keyboard (Simply from a laptop, Laptop will also run the “server” that communicates with the MCU/PCB)
- Drive Motors
12mm Diameter 50:1 Micro Metal Gearmotor 12V 600RPM (2 x 10 grams)
(https://www.robotshop.com/products/dyna-engine-12mm-diameter-501-micro-metal-gearmotor-12v-600rpm)
## Subsystem 4 - Battery/Power
Onboard power source for sensors/controllers/motors as well as components to regulate and distribute power.
- Battery
3S (11.1 V) around 500 mAH battery (starting point estimation)
(https://hobbyking.com/en_us/turnigy-nano-tech-450mah-3s-45c-lipo-pack-w-xt30)
- Control Circuit Regulator
AZ1117CH-3.3TRG1 - 3.3 V w/ 18 V max input, output current is 1.7 mA min, and 1 A max, well within range
(https://www.digikey.com/en/products/detail/diodes-incorporated/AZ1117CH-3-3TRG1/4470985)
- Gate Drivers
DGD0211C - 3.3v to 12 v gate drivers, plenty of overhead in ability
(https://www.digikey.com/en/products/detail/diodes-incorporated/DGD0211CWT-7/12702560)
- H-Bridge MOSFETs
FDC655BN - 30v, 6.3 A NMOSfets
(https://www.digikey.com/en/products/detail/onsemi/FDC655BN/979810)

# Criteria for Success
- Ultrasonic sensor accurately triggers attack arm when an object comes into close proximity
- Gyroscopic sensor accurately registers when robot has been flipped and inverts controls
- Microcontroller takes in driver keyboard inputs for fluid steering
- Attack arm’s default position changes based on driver input (horizontal for wedge, vertical for hammer)
- Attack arm’s default position changes based on gyroscopic sensor input (default position adjusts to bot’s orientation)
- Tank turning and wheel alignment allows for 360 degree rotation
- Robot movements follow driver input: i.e. forward/backward motion, turns etc.

Iron Man Mouse

Jeff Chang, Yayati Pahuja, Zhiyuan Yang

Featured Project

# Problem:

Being an ECE student means that there is a high chance we are gonna sit in front of a computer for the majority of the day, especially during COVID times. This situation may lead to neck and lower back issues due to a long time of sedentary lifestyle. Therefore, it would be beneficial for us to get up and stretch for a while every now and then. However, exercising for a bit may distract us from working or studying and it might take some time to refocus. To control mice using our arm movements or hand gestures would be a way to enable us to get up and work at the same time. It is similar to the movie Iron Man when Tony Stark is working but without the hologram.

# Solution Overview:

The device would have a wrist band portion that acts as the tracker of the mouse pointer (implemented by accelerometer and perhaps optical sensors). A set of 3 finger cots with gyroscope or accelerometer are attached to the wrist band. These sensors as a whole would send data to a black box device (connected to the computer by USB) via bluetooth. The box would contain circuits to compute these translational/rotational data to imitate a mouse or trackpad movements with possible custom operation. Alternatively, we could have the wristband connected to a PC by bluetooth. In this case, a device driver on the OS is needed for the project to work.

# Solution Components:

Sensors (finger cots and wrist band):

1. 3-axis accelerometer attached to the wrist band portion of the device to collect translational movement (for mouse cursor tracking)

2. gyroscope attached to 3 finger cots portion to collect angular motion when user bend their fingers in different angles (for different clicking/zoom-in/etc operations)

3. (optional) optical sensors to help with accuracy if the accelerometer is not accurate enough. We could have infrared emitters set up around the screen and optical sensors on the wristband to help pinpoint cursor location.

4. (optional) flex sensors could also be used for finger cots to perform clicks in case the gyroscope proves to be inaccurate.

Power:

Lithium-ion battery with USB charging

Transmitter component:

1. A microcontroller to pre-process the data received from the 4 sensors. It can sort of integrate and synchronize the data before transmitting it.

2. A bluetooth chip that transmits the data to either the blackbox or the PC directly.

Receiver component:

1. Plan A: A box plugged into USB-A on PC. It has a bluetooth chip to receive data from the wristband, and a microcontroller to process the data into USB human interface device signals.

2. Plan B: the wristband is directly connected to the PC and we develop a device driver on the PC to process the data.

# Criterion for Success:

1. Basic Functionalities supported (left click, right click, scroll, cursor movement)

2. Advanced Functionalities supported(zoom in/out, custom operations eg. volume control)

3. Performance (accuracy & response time)

4. Physical qualities (easy to wear, durable, and battery life)