Project

# Title Team Members TA Documents Sponsor
11 Ant-weight Durian Battlebot
Matthew Jin
Timothy Fong
Ved Tiwari
Zhuoer Zhang design_document1.pdf
proposal1.docx
# Title
Ant-Weight Durian Battlebot
# TEAM MEMBERS:
- Matthew Jin (mj41)
- Tim Fong (tfong5)
- Ved Tiwari ( vedt2)
# PROBLEM
Want to design an Ant-weight Battlebot that can outlast and tactically out-compete other entries into the competition. Several restrictions/requisites (outlined by the National Robotics Challenge rulebook) are as follows:
- Robot must be under 2lb (we are not opting for a bipedal/quadpedal robot)
- Usage of an H-bridge motor system
- No metal components whatsoever
- Weaponry (either passive or active)
- Power delivery system (battery)
- Usage of sensors/actuators
- Must be 3D printed using one/multiple of 5 materials: PET, PETG, ABS, PLA, PLA+
- Custom PCB to house a microcontroller
- Microcontroller must have bluetooth or wifi capability to be controlled externally via a nearby PC/laptop
- Simple and complete manual shutdown (within 60s) without the usage of an RF link

# SOLUTION
Collaboratively decided on a Battlebot design with a passive/counter-type weapon, being spikes that cover the outer shell (resembles a Durian shell with rounded, shallower spikes). Numerous other countermeasures and engineering decisions have been culminated to account for tactics employed by other participating teams. Unlike other common approaches, the absence of an active weapon allows for weight to contribute toward other directions. With this passive weaponry, it falls down more toward microcontroller-initiated, driver assistance algorithms and the shell armor design to disarm/decommission the competition. You’re in trouble.
# SOLUTION COMPONENTS
## PASSIVE WEAPONRY
The shell spikes are intentionally shallow and rounded to prevent chipping, and to maximize structural integrity under impact. This will prove useful against many active weapon forms, namely the hammer and rotary-type Battlebots in head-on collisions.
## OUTER SHELL
Due to the absence of an active weapon, this gives more wiggle room to make the outer shell thicker. To counter Battlebots with forklift/door wedge armaments that aim to flip us over, we will intentionally minimize the clearance room between the bottom lip of the shell and the bottom of the wheels. Additionally, the shell will be thicker toward the middle/base (compared to the top) to create an even lower center of gravity. This shell will be 3D printed using the PETG material, given its functional robustness in the context of this Battlebot competition. It is durable, impact resistant, non-brittle, and warp-resistant during the printing process.
## ELECTRONICS
Preface: To include details regarding sensors, battery system, the microcontroller, AND the electronics + battery trays.

We decided to use an STM32 microcontroller compared to other popular microcontrollers (namely ESP32) due to its superior compute power. The STM32 provides us with a better ability to perform algorithmic computations on board from data collected from our sensors. An example use case of this might be to determine if and when the bot is close to flipping over. By calculating the y offset from the gyroscope and accelerometer on the IMU, we can send a signal to the wheels to spin it at a certain frequency to reduce the chances of flipping. Apart from this, the STM32 provides us with native Bluetooth and WIFI support out of the box, eliminating the need to configure separate chips to the microcontroller setup.

For the battery, we have chosen the 4S (14.8V) 750mAh LiPo battery, as it provides ample flexibility between power and charge capacity: both of which are important for a nimble Battlebot that can last the entire contest. This battery will be stored in a lower-level tray (to again, lower the center of gravity) to protect it. Additionally, a battery-health specialized transistor chip will be utilized. There will be a buck converter that will step down the 14.8v in order to power the microcontroller and other components at the correct voltages that require less voltage.

We are to use IMU and load sensors for the sake of creating 2 feedback systems. The first feedback system is between the microcontroller and the Battlebot’s localization. The second feedback system is between the microcontroller and the motor health/status. The goal of initializing these two systems is for the sake of ensuring the Battlebot’s movement is both accurate, and that its motors do not malfunction. Alongside the sensors, the microcontroller/PCB will be located in an upper-level tray above the battery tray.


## DRIVETRAIN
As outlined in Professor Gruev’s slides, we are to use an H-bridge system. We’ve opted for a multidirectional 4WD setup with the wheels being attached to the inner perimeter of the shell. With this approach, fluid motion exists while simultaneously shielding the wheels from external impacts. Wheels will be made of urethane, as they are heavy (contribute toward lowering the center of gravity), durable, have good grip, and less wear factor. Brushless DC motors will be used due to their incredibly high power-to-weight ratio and long lifespan (reliable).



# CRITERION FOR SUCCESS
- Battlebot electronics are well-protected, functional, and durable
- Outer shell does not break under expected impact
- Spikes do not chip and prove effective in using others’ active weapons against them
- Battlebot does not flip over during trial runs/competition scenario reenactments
- Battery lasts the entire combat duration

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*