Project

# Title Team Members TA Documents Sponsor
79 SUPERCAPACITOR MODULE FOR ILLINI-ROBOMASTER ROBOT
 Haoyuan You
Shaurya Grover
 Matthew Qi design_document2.pdf
final_paper1.pdf
photo1.jpg
photo2.jpg
presentation1.pptx
proposal1.pdf
SUPERCAPACITOR MODULE FOR ILLINI-ROBOMASTER ROBOT

Team Members:

- You, Haoyuan (hy19)
- Grover, Shaurya (sgrover4)

PROBLEM

Illini-Robomaster (iRM) is an RSO at UIUC competing in the Robomaster robotics competition. During a match, robots will be punished when exceeding the power limit (80W), but the monitoring system (referee system) is only checking the power output from the battery. To maximize available power for the motors and achieve greater mobility, we need a device to store and release energy. Existing solutions are either prohibited by the competition rules, too large to fit in our mobile robot, or sold at an unacceptable price by our competitor universities.

SOLUTION

We propose a supercapacitor module to supply power in addition to the battery. It should be capable to store energy from the battery when the robot is running on low power and release energy when the robot needs it. Thus, we have more power available. The supercapacitor module should be controlled by the master MCU on the robot and when additional power is needed, the master MCU can control the MCU on the module to release the power.

We propose two solutions:

1. The capacitor sits between the battery and the rest of the robot’s power bus. The robot is powered entirely by the capacitor and the battery only charges the capacitor. The battery, capacitor, and the robot’s power bus are interconnected with DC-DC converters.
Battery = DC-DC = Capacitor = DC-DC = Motors (Robot)

“=” stands for power connection

2. The battery directly connects to the power bus and the capacitor is connected to the power bus with a bi-directional DC-DC converter. DC-DC converter charges the capacitor when the battery has extra power and reverts the direction of current when the robot needs extra power. We think this is a similar case to a redundant power supply design.
Battery = Motors (Robot) = DC-DC (Bidirectional) = Capacitor

“=” stands for power connection

We think there are advantages to the second design due to one more DC-DC in the first design introduces extra power loss. Moreover, if the capacitor module breaks in the second design the rest of the robot is left unaffected. Yet we also think the second design is more challenging to implement.

SOLUTION COMPONENTS

CONTROL UNIT (SAME FOR BOTH DESIGNS)

MCU
Control the Power unit and communicate with the master MCU on the robot through CAN or UART. Either Atmega328 or STM32F103 depending on prototype performance.

Voltage and current sensor
Measure the voltage and current of the capacitor to estimate the power output and report to the master MCU

POWER UNIT

Capacitor array (Same for both designs)
The game rule restricts the maximum energy storage to be 2000J and the max voltage on the power bus is 30V, so the max capacitance is around 4.4F. We might choose a smaller value for safety concerns. There is also an unused capacitor array in the RSO, we might consider integrating it into the module to reduce cost.

Design 1: {

Supercapacitor charging control module
Charging of the capacitor from the battery, controlled by the MCU. This might be a DC-DC converter or off-the-shelf capacitor charging control module (like BQ24640)

DC-DC module
Convert the output voltage to the same voltage as the power bus (24V). Consider using a buck-boost converter.

}

Design 2: {

Bi-directional DC-DC converter
Convert the voltage from the power bus to the capacitor during charging and convert the capacitor's voltage to the power bus's during discharging. Controlled by the MCU to switch between two directions.

}

INTERFACES ON THE TARGETING ROBOT

These are not part of the module but will be integrated with the module during the competition this June:

24V M3508 motors and C620 motor speed controllers.

24V battery

The module should be able to sustain the induced current from the motors and not break any device powered by it.

CRITERION FOR SUCCESS

- Criterion 1: The supercapacitor module must be able to store a certain amount of energy
- Criterion 2: The supercapacitor module must be able to release energy
- Criterion 3: The supercapacitor module can be controlled by the master MCU

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.