Project

# Title Team Members TA Documents Sponsor
37 Ant-Weight Battlebot - DC Hammer
 Carson Sprague
Gage Gathman
Ian Purkis
 Haocheng Bill Yang
# 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.

Remotely Controlled Self-balancing Mini Bike

Will Chen, Eric Tang, Jiaming Xu

Featured Project

# Remotely Controlled Self-balancing Mini Bike

Team Members:

- Will Chen hongyuc5

- Jiaming Xu jx30

- Eric Tang leweit2

# Problem

Bike Share and scooter share have become more popular all over the world these years. This mode of travel is gradually gaining recognition and support. Champaign also has a company that provides this service called Veo. Short-distance traveling with shared bikes between school buildings and bus stops is convenient. However, since they will be randomly parked around the entire city when we need to use them, we often need to look for where the bike is parked and walk to the bike's location. Some of the potential solutions are not ideal, for example: collecting and redistributing all of the bikes once in a while is going to be costly and inefficient; using enough bikes to saturate the region is also very cost inefficient.

# Solution

We think the best way to solve the above problem is to create a self-balancing and moving bike, which users can call bikes to self-drive to their location. To make this solution possible we first need to design a bike that can self-balance. After that, we will add a remote control feature to control the bike movement. Considering the possibilities for demonstration are complicated for a real bike, we will design a scaled-down mini bicycle to apply our self-balancing and remote control functions.

# Solution Components

## Subsystem 1: Self-balancing part

The self-balancing subsystem is the most important component of this project: it will use one reaction wheel with a Brushless DC motor to balance the bike based on reading from the accelerometer.

MPU-6050 Accelerometer gyroscope sensor: it will measure the velocity, acceleration, orientation, and displacement of the object it attaches to, and, with this information, we could implement the corresponding control algorithm on the reaction wheel to balance the bike.

Brushless DC motor: it will be used to rotate the reaction wheel. BLDC motors tend to have better efficiency and speed control than other motors.

Reaction wheel: we will design the reaction wheel by ourselves in Solidworks, and ask the ECE machine shop to help us machine the metal part.

Battery: it will be used to power the BLDC motor for the reaction wheel, the stepper motor for steering, and another BLDC motor for movement. We are considering using an 11.1 Volt LiPo battery.

Processor: we will use STM32F103C8T6 as the brain for this project to complete the application of control algorithms and the coordination between various subsystems.

## Subsystem 2: Bike movement, steering, and remote control

This subsystem will accomplish bike movement and steering with remote control.

Servo motor for movement: it will be used to rotate one of the wheels to achieve bike movement. Servo motors tend to have better efficiency and speed control than other motors.

Stepper motor for steering: in general, stepper motors have better precision and provide higher torque at low speeds than other motors, which makes them perfect for steering the handlebar.

ESP32 2.4GHz Dual-Core WiFi Bluetooth Processor: it has both WiFi and Bluetooth connectivity so it could be used for receiving messages from remote controllers such as Xbox controllers or mobile phones.

## Subsystem 3: Bike structure design

We plan to design the bike frame structure with Solidworks and have it printed out with a 3D printer. At least one of our team members has previous experience in Solidworks and 3D printing, and we have access to a 3D printer.

3D Printed parts: we plan to use PETG material to print all the bike structure parts. PETG is known to be stronger, more durable, and more heat resistant than PLA.

PCB: The PCB will contain several parts mentioned above such as ESP32, MPU6050, STM32, motor driver chips, and other electronic components

## Bonus Subsystem4: Collision check and obstacle avoidance

To detect the obstacles, we are considering using ultrasonic sensors HC-SR04

or cameras such as the OV7725 Camera function with stm32 with an obstacle detection algorithm. Based on the messages received from these sensors, the bicycle could turn left or right to avoid.

# Criterion For Success

The bike could be self-balanced.

The bike could recover from small external disturbances and maintain self-balancing.

The bike movement and steering could be remotely controlled by the user.

Project Videos