Project

# Title Team Members TA Documents Sponsor
37 BattleBot
Deepika Agrawal
Ishanvi Lakhani
Megha Esturi
 Surya Vasanth design_document2.pdf
final_paper1.pdf
other1.pdf
photo1.pdf
presentation1.pdf
proposal2.pdf
video
Team Members

- Megha Esturi (mesturi2)
- Deepika Agarwal (deepika7)
- Ishanvi Lakhani (ishanvi2)


Problem Statement

According to the guidelines PDF, we must ensure that the robot adheres to several key requirements. The robot must weigh no more than 2lbs and be constructed using 3D-printed thermoplastics. It should also feature a locomotion system and a fighting tool, with wireless control enabled via WiFi. The main goal of the competition is to design a Battlebot capable of disrupting the functionality of opponents' robots using its fighting tool while maintaining its own operational integrity.

SOLUTION

We plan to create a Battlebot using 3D-printed components, equipped with two omni wheels that will enable the robot to move in any direction. The Battlebot itself will spin like a beyblade, powered by brushless motors for smooth and efficient control. Additionally, we aim to incorporate a flipping mechanism, which will be driven by a combination of a spring and motor. A sliding plate, attached to a motor, will allow the plate to maneuver under the opponent’s robot. Once in position, the spring will activate, flipping the opposing robot to disrupt its functionality. The ESC will serve as the central control system for the robot, managing the motor's speed and direction. Additionally, communication with the bot will be established via WiFi, allowing us to remotely control its movements and operations during the competition.

SUBSYSTEMS

Power Module

We would be using LiPo batteries in our battlebot. As of now, we plan to use 16V batteries but we may consider using slightly lighter batteries or batteries of lower voltage as we need to ensure that the weight of all components combined is less than 2lbs and so that all our hardware pieces can handle the voltage level.

WiFi Controller

We will use the ESP-32 to enable communication between the robot and a PC via WiFi. Our plan is to program the ESP-32 to create a wireless connection, allowing the robot to send and receive commands from the PC. The controller will manage the rotation and directional changes of the wheels, allowing the Battlebot to navigate effectively. Additionally, the controller will feature buttons to extend and retract the slate based on user input. Another button will trigger the slate to lift and flip the opposing robot during battle. All of these motions will be triggered by keyboard inputs.

Driving System

The battlebot will have DC motors connected to 4-6 wheels (still deciding) to control movement. The wheels will be omnidirectional wheels to allow for the robot to turn in place and move with ease. However, there is a concern that the bot might be able to be pushed around easily, so if time permits we will install a locking mechanism or mix the type of wheels that we use, such as adding grip wheels.

Spring System and Flipping Motion

The flipping mechanism will feature a high-torque DC motor to control the extension and retraction of a sliding slate, allowing it to move outward and inward beneath the opponent's robot. A compression spring will be released when triggered to execute a powerful flipping motion. Together, the motor and compression spring will provide precise control over the slate's movement and a strong, reliable flipping action. This will happen when the user presses the button on the PC control.

Rotating System

The T-Motor MN2212 Brushless Motor is a lightweight and efficient motor and we plan to use it for our rotating motion. It provides a good balance of torque and RPM, making it ideal for a small that needs to be less than 2lbs. Its durability and precise performance allow for smooth rotational motion, which is crucial for agile and responsive movements in competitive settings. The motor will be connected to the main part of the bot only allowing for the main shell to spin.

Criterion for Success

We would consider our project a success if we can establish effective communication between the PC and the various motors, particularly for the extending and retracting of the slates and the flipping mechanism. Since the opponent's Battlebot will also weigh 2 lbs, it is crucial that the slate has enough strength to lift this weight during the flipping action. For this project to succeed, obtaining this degree of authority and control will be essential.

Covert Communication Device

Ahmad Abuisneineh, Srivardhan Sajja, Braeden Smith

Covert Communication Device

Featured Project

**Partners (seeking one additional partner)**: Braeden Smith (braeden2), Srivardhan Sajja (sajja3)

**Problem**: We imagine this product would have a primary use in military/law enforcement application -- especially in dangerous, high risk missions. During a house raid or other sensitive mission, maintaining a quiet profile and also having good situational awareness is essential. That mean's that normal two way radios can't work. And alternatives, like in-ear radios act as outside->in communication only and also reduce the ability to hear your surroundings.

**Solution**: We would provide a series of small pocketable devices with long battery that would use LoRa radios to provide a range of 1-5 miles. They would be rechargeable and have a single recessed soft-touch button that would allow someone to find it inside of pockets and tap it easily. The taps would be sent in real-time to all other devices, where they would be translated into silent but noticeable vibrations. (Every device can obviously TX/RX).

Essentially a team could use a set of predetermined signals or even morse code, to quickly and without loss of situational awareness communicate movements/instructions to others who are not within line-of-sight.

The following we would not consider part of the basic requirements for success, but additional goals if we are ahead of schedule:

We could also imagine a base-station which would allow someone using a computer to type simple text that would be sent out as morse code or other predetermined patterns. Additionally this base station would be able to record and monitor the traffic over the LoRa channels (including sender).

**Solutions Components**:

- **Charging and power systems**: the device would have a single USB-C/Microusb port that would connect to charging circuitry for the small Lithium-ion battery (150-500mAh). This USB port would also connect to the MCU. The subsystem would also be responsible to dropping the lion (3.7-4.2V to a stable 3.3V logic level). and providing power to the vibration motor.

- **RF Communications**: we would rely on externally produced RF transceivers that we would integrate into our PCB -- DLP-RFS1280, https://www.sparkfun.com/products/16871, https://www.adafruit.com/product/3073, .

-**Vibration**: We would have to research and source durable quiet, vibration motors that might even be adjustable in intensity

- **MCU**: We are likely to use the STM32 series of MCU's. We need it to communicate with the transceiver (probably SPI) and also control the vibration motor (by driving some transistor). The packets that we send would need to be encrypted (probably with AES). We would also need it to communicate to a host computer for programming via the same port.

- **Structural**: For this prototype, we'd imagine that a simple 3d printed case would be appropriate. We'd have to design something small and relatively ergonomic. We would have a single recessed location for the soft-touch button, that'd be easy to find by feel.

**Basic criterion for success:** We have at least two wireless devices that can reliably and quickly transfer button-presses to vibrations on the other device. It should operate at at *least* 1km LOS. It should be programmable + chargeable via USB. It should also be relatively compact in size and quiet to use.

**Additional Success Criterion:** we would have a separate, 3rd device that can stay permanently connected to a computer. It would provide some software that would be able to send and receive from the LoRa radio, especially ASCII -> morse code.