Project

# Title Team Members TA Documents Sponsor
13 Invertible-Control Ant-Weight Battle Bot
Ben Goldman
Jack Moran
Haocheng Bill Yang design_document1.pdf
proposal1.pdf
**TEAM MEMBERS:**
- Jack Moran (jackm6)
- Ben Goldman (bg23)

**PROBLEM:**

The primary objective is to create a bot weighing under 2lbs to disable an opponent in an ant weight combat battle bots match in a confined space. Winning a match like this often requires a high skill level to pilot a robot, especially as they get flipped or lose control when other bots attack. Additionally, many bots may suffer from reliability issues as teams overcomplicate the robotics which leads to vulnerabilities. We need a solution to maximize weapon power while simplifying the driving experience for the operator so all they need to focus on is planning attacks against other opponent bots.

**SOLUTION:**

We propose a 2lb combat battle bot designed to deliver catastrophic blows to opponents using a double sided horizontal spinning bar with an easy to use control system to allow for efficient battle. The chassis will feature a large primary weapon consisting of a horizontal spinning bar capable of delivering powerful attacks after winding up due to high inertia. This primary weapon will stick out of the front. The sides and back of the bot will be rounded in shape with no sharp edges or corners in order to deflect attacks and prevent opponent's weapons from grabbing on.

For the controls and movement, the bot will feature two wheels to enable a tank like steering system. These wheels will be enclosed within the body of the bot so that only a small section, where it would contact the ground, protrudes from the top and bottom of the bot. There would be small skid sections to allow the remainder of the body to stay low to the ground while also moving easily when on smooth surfaces.

Since the bot will have a weapon, defense system, and wheels which can operate in either orientation, this bot will be capable of operating if flipped. However, whenever the bot is inverted, the steering and controls would be inverted making it hard to command. To combat this, we will include an IMU sensor to detect if the bot has been flipped. The controls would then be inverted so that the driver does not need to focus on the orientation of the robot and can focus on controlling the weapon towards opponents as controls would be reversed automatically. The bot would be controlled from the driver's laptop.

**SOLUTION COMPONENTS:**

**Subsystem 1: Mobility and Drive System**

This subsystem is responsible for the mobility and driving capabilities of our bot. The bot needs to be highly mobile and fast in order to evade and attack other bots. In addition, this system will need to be capable of operating no matter the orientation of the bot. Using two motors for mobility will allow the bot to be able to turn very efficiently using tank like steering.
- Drive type: Differential wheeled drive (two motors).
- Wheel placement: Wheels recessed inside the chassis to protect against direct impacts. Each wheel only slightly protrudes from top and bottom of the chassis.
- Motors: High-torque brushed DC gearmotors sized for ant-weight limits.
- Control: Independent left/right motor control via H-bridges on the custom PCB.

**Subsystem 2: Spinning Weapon System**

The main weapon of our battle bot is a horizontal spinning bar. This piece will be 3D printed in a manner such that it is very strong and will not break on impact. It will be driven by the bot's third motor. In addition, this weapon must comply with ant-weight regulations. Therefore, this weapon must stop completely within 60 seconds of shutoff. The weapon provides offensive capability while keeping mechanical complexity to a minimum.
- Weapon type: Horizontal spinning bar.
- Actuation: Brushed DC motor belt driven or directly driven.
- Safety: Software-controlled spin up sequence and current monitoring to prevent overcurrent or unsafe startup.

**Subsystem 3: Orientation Detection and Control Inversion**

The battle bot will feature the use of IMU sensors to help the driver control the bot. When flipped upside down by other bots, this bot will detect the inversion and be able to invert all controls. This allows for the driver to focus on attacking and evading other bots rather than wasting energy understanding how to control a bot when it is upside down using reversed controls.
- Sensor: 6-axis IMU (accelerometer + gyroscope). Potential option: MPU-6050
- Function: Detect robot orientation (upright vs inverted).
- Control logic: Automatically invert motor commands when inverted so “forward” and “turn” remain intuitive to the operator.

**Subsystem 4: Control Electronics and Custom PCB**

The PCB and control electronics are responsible for the main control and communication of our robot. Our microcontroller will be our central controller receiving operator commands and translating them into control signals. This will interface with the IMU to determine the robot’s orientation and apply the correct control logic accordingly. This subsystem also monitors our safety conditions. It will kill all motors and enforce failsafe behavior for our weaponry if communication is lost or there is a fault.
- Microcontroller: ESP32 (Wi-Fi or Bluetooth control). Potential option: ESP32-WROOM-32E
- Wireless control: PC-based controller via Wi-Fi/BLE. This is included in the ESP32
- Motor drivers: Custom H-bridge circuits for left drive, right drive, and weapon motor.
- Power management: LiPo battery. Potential option: Turnigy Nano-Tech 3S LiPo. Would include voltage regulation for logic (3.3V) and current sensing for protection.
- Safety features: Hardware kill switch. Automatic shutdown on RF link loss

**Subsystem 5: Mechanical Design and Fabrication**

The body of the bot will be primarily 3D printed and will adhere to all requirements of an ant-weight battle bot. Primarily, this means that the bot will measure in under 2lbs for competition. The chassis will be able to be opened in order to properly build and work on the bot including access to the PCB, microcontroller, battery, and motors. This chassis will also provide all primary defense systems by being smooth and rounded everywhere other than at the front where the weapon protrudes. This prevents attacks from spinning weapons or claw like devices to do damage. In addition, weight distribution will be optimized to keep the center of mass low and stable.
- Materials: PLA+, PETG, or ABS.
- Weight limit: ≤ 2 lb total robot mass.
- Manufacturing: Fully 3D-printed chassis with modular access to electronics.

**CRITERIA FOR SUCCESS:**

**Mobility and Drive System**
- The robot remains fully drivable when inverted.
- The robot contains two wheels directly driven by motors such that front, back, and sides of each wheel are protected by the chassis.

**Spinning Weapon System**
- Uninterrupted high speed 360 degree rotation possible in both directions.
- After impact, the spinning weapon immediately starts to spin up again.
- The control system has an operational killswitch which shuts down all operations of the bot.
- Weapon comes to a complete stop within 60 seconds after shutoff.

**Orientation Detection and Control Inversion**
- Sensors detect both upright and inverted positions which are displayed on the laptop controlling the bot.
- Controls get inverted when the bot is upside down and return to normal when upright based on the use of the IMU.
- Controls invert within 300ms after bot flips.

**Control Electronics and Custom PCB**
- The robot passes all safety shutdown tests required in ant-weight battle bot rules.
- Custom PCB operates reliably without overheating or brownouts. This means it remains operational for ten or more minutes.

**Mechanical Design and Fabrication**
- The chassis of the battle bot weights in under 2lbs.
- The chassis of the battle bot is smooth and curved with no sharp corners other than on the main spinning weapon.
- The robot is competition-ready and able to participate in the ECE 445 ant-weight battle bot event.

CHARM: CHeap Accessible Resilient Mesh for Remote Locations and Disaster Relief

Martin Michalski, Melissa Pai, Trevor Wong

Featured Project

# CHARM: CHeap Accessible Resilient Mesh for Remote Locations and Disaster Relief

Team Members:

- Martin Michalski (martinm6)

- Trevor Wong (txwong2)

- Melissa Pai (mepai2)

# Problem

There are many situations in which it is difficult to access communicative networks. In disaster areas, internet connectivity is critical for communication and organization of rescue efforts. In remote areas, a single internet connection point often does not cover an area large enough to be of practical use for institutions such as schools and large businesses.

# Solution

To solve these problems, we would like to create a set of meshing, cheap, lightweight, and self-contained wireless access points, deployable via drone. After being placed by drone or administrator, these access points form a WiFi network, usable by rescuers, survivors, and civilians. Our network will have QoS features to prioritize network traffic originating from rescuers. Having nodes/access points deployable by drone ensures we are able to establish timely connectivity in areas where search and rescue operations are still unable to reach.

Over the course of the semester, we will produce a couple of prototypes of these network nodes, with built in power management and environmental sensing. We aim to demonstrate our limited network’s mesh capabilities by setting up a mock network on one of the campus quads, and connecting at various locations.

# Solution Components

## Router and Wireless Access Point

Wireless Access for users and traffic routing will be the responsibility of an Omega2 board, with onboard Mediatek MT7688 CPU. For increased signal strength, the board will connect to a RP-SMA antenna via U.FL connector.

The Omega2 will be running OpenWRT, an Linux-based OS for routing devices. We will develop processes for the Omega2 to support our desired QoS features.

## Battery Management System

This module is responsible for charging the lithium-ion battery and ensuring battery health. Specifically, we will ensure the battery management system has the following features:

- Short circuit and overcurrent protection

- Over- and under-voltage protection

- An ADC to provide battery status data to the microcontroller

- 3.3v voltage regulation for the microcontroller and other sensors

In addition to miscellaneous capacitors and resistors, we intend to use the following components to implement the battery management system:

- The MT2492 step-down converter will be used to step down the output voltage of the battery to 3.3 volts. Between the GPS and extra power the microcontroller might consume with an upgraded Wifi antenna, low-dropout regulators would not provide sufficient power in an efficient manner. Instead, we will implement a 2 amp buck converter to improve efficiency and ensure there are no current bottlenecks.

- We will utilize two button-top protected 18650 3400 mAh lithium ion batteries in series to power each node. Placing two of these batteries in series will ensure their combined voltage never falls below the minimum voltage input of the buck converter, and accounting for the buck converter’s inefficiency these batteries should give us about 21 Wh of capacity. The cells we plan on using include a Ricoh R5478N101CD protection IC that provides over-voltage, under-voltage, and over-current protection. Using a standard battery form factor will make them easy to replace in the future as needed.

- A USB-C port with two pulldown resistors will provide 5 volt charging input with up to 3 amps of current, depending on the charger.

- The MT3608 step-up converter will boost the input voltage from the usb-c port and feed it into the charging controller.

- The MCP73844 Charge Management Controller will be used to charge the batteries. This controller supports CC/CV charging and a configurable current limit for safe and effective battery charging.

- The TI ADS1115 ADC will be used for battery voltage monitoring. This chip is used in the official Omega2 expansion board, so it should be easy to integrate in software. We will use a voltage divider to reduce the battery voltage to a range this chip can measure, and this chip will communicate over an I2C bus.

## Sensor Suite

Each node will have a battery voltage sensor and GPS sensor, providing the system with health information for each node. On top of the Wifi-connectivity, each module would have a series of sensors to detect the status of the physical node and helpful environment variables. This sensor suit will have the following features and components to implement it

- Ultimate GPS Module PA1616D will be used for positioning information. This chip utilizes 3.3V which is supplied through our battery management system.

Battery Voltage Monitor

- The TI ADS1115 ADC (mentioned in the BMS section) is for battery voltage monitoring. It interfaces via I2C to the Omega2.

## System Monitor

A system monitor which provides visibility of the overall system status for deployed network nodes. Information that we will show includes: last known location, battery health, and network statistics (e.g. packets per second) from the physical devices.

We plan on using React to provide an intuitive UI, using google-map-react and other React packages to create an interactive map showing the last known location and status of each node.

The backend will be hosted on a server in the cloud. Nodes will continually update the server with their status via POST requests.

# Criterion For Success

We aim to achieve the following performance metrics:

- 1.5 kg maximum mass

- Cover 7500 m^2 (North Quad) with 4 nodes

- Display the last known location, time connected, and battery voltage for all nodes via our system monitor

- 3 hour battery life

- 5 Mb/s WiFi available to laptops and smartphones in the coverage area

[*Link*](https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=71252) *to assciated WebBoard discussion*