## Inspiration

The inspiration came from working with integrated BMCs on server motherboards. These devices are able to control servers remotely without the need of an operating system on the server. This is accomplished by streaming the servers' VGA input and attaching a keyboard via USB. The major pain points about BMCs are that they are normally embedded on the servers, the streamed keyboard input is prone to errors and that since the screen is streamed the screen is not interactable. Our prescriptive design was a small portable device that has the same functionality as the BMC while solving these pain points and adding smart home functionality features.

## Challenges we ran into

Originally, we planned to use the Raspberry Pi 3 because it had an onboard network module which eliminates one step in the integration process. Unfortunately, the Raspberry Pi 3 cannot emulate USB HID devices such as a keyboard, which made it infeasible to use. Once we switched to the Raspberry Pi Pico, which could emulate a keyboard but didn’t have WIFi, we had to integrate it with a network module ESP8266 or ESP32. We encountered difficulties powering the module through the RPI and later discovered that both require 5v while our RPI only provided 3.3v. Furthermore, the RPI Pico does not have USB ports to support the display capture feature we aimed to implement, instead we added additional features.

## What it does

Marcomancer main features are the following:

* Run Macros Remotely via USB Keyboard Emulation
* Programmable Smart Home Voice Activated Macros
* Robust Input Streaming via Web App
* Portable Plug and Play

These features solve two of the major BMC pain points of no portability and error prone input. The system also allows system administrators to reliably program macros to remote servers. Macromancer is not only for tech savvy individuals but also provides smart accessibility to anyone through voice control on their phones to communicate to their PC. As long as you can accomplish a task with just keyboard inputs, you can use Macromancer to send a macro from anywhere.

## How we built it

Hardware: The RPI Pico that waits for keycodes transmitted by the ESP32. ESP32 polls our cloud server for commands.

Software: Google Assistant sends predefined user commands to the cloud server webhook via IFTTT applets. Users can also use our Frontend Web App to manually queue command strings and macros for the ESP32 to poll via a GET API.

## Accomplishments that we're proud of

* Ability for users to add/delete any new commands
* Integrating with the network modules
* The minimum latency

## What we learned

* Flashing firmware on microprocessors
* Emulating keyboard through microprocessors (Adafruit)
* TCP and Checksum error detection
* Activating webhooks with Google Assistant
* How to communicate between microprocessors

## What's next for Macromancer

* Better security (encryption)
* RPI 4 (reduce hardware and allow display capture for text editing)
* Wake on LAN
## Inspiration

We wanted to make something that linked the virtual and real worlds, but in a quirky way. On our team we had people who wanted to build robots and people who wanted to make games, so we decided to combine the two.

## What it does

Our game portrays a robot (Todd) finding its way through obstacles that are only visible in one dimension of the game. It is a multiplayer endeavor where the first player is given the task to guide Todd remotely to his target. However, only the second player is aware of the various dangerous lava pits and moving hindrances that block Todd's path to his goal.

## How we built it

Todd was built with style, grace, but most of all an Arduino on top of a breadboard. On the underside of the breadboard, two continuous rotation servo motors & a USB battery allows Todd to travel in all directions.

Todd receives communications from a custom built Todd-Controller^TM that provides 4-way directional control via a pair of Bluetooth HC-05 Modules.

Our Todd-Controller^TM (built with another Arduino, four pull-down buttons, and a bluetooth module) then interfaces with Unity3D to move the virtual Todd around the game world.

## Challenges we ran into

The first challenge of the many that we ran into on this "arduinous" journey was having two arduinos send messages to each other via over the bluetooth wireless network. We had to manually configure the setting of the HC-05 modules by putting each into AT mode, setting one as the master and one as the slave, making sure the passwords and the default baud were the same, and then syncing the two with different code to echo messages back and forth.

The second challenge was to build Todd, the clean wiring of which proved to be rather difficult when trying to prevent the loose wires from hindering Todd's motion.

The third challenge was building the Unity app itself. Collision detection was an issue at times because if movements were imprecise or we were colliding at a weird corner our object would fly up in the air and cause very weird behavior. So, we resorted to restraining the movement of the player to certain axes. Additionally, making sure the scene looked nice by having good lighting and a pleasant camera view. We had to try out many different combinations until we decided that a top down view of the scene was the optimal choice. Because of the limited time, and we wanted the game to look good, we resorted to looking into free assets (models and textures only) and using them to our advantage.

The fourth challenge was establishing a clear communication between Unity and Arduino. We resorted to an interface that used the serial port of the computer to connect the controller Arduino with the unity engine. The challenge was the fact that Unity and the controller had to communicate strings by putting them through the same serial port. It was as if two people were using the same phone line for different calls. We had to make sure that when one was talking, the other one was listening and vice versa.

## Accomplishments that we're proud of

The biggest accomplishment from this project in our eyes, was the fact that, when virtual Todd encounters an object (such as a wall) in the virtual game world, real Todd stops.

Additionally, the fact that the margin of error between the real and virtual Todd's movements was lower than 3% significantly surpassed our original expectations of this project's accuracy and goes to show that our vision of having a real game with virtual obstacles .

## What we learned

We learned how complex integration is. It's easy to build self-sufficient parts, but their interactions introduce exponentially more problems. Communicating via Bluetooth between Arduino's and having Unity talk to a microcontroller via serial was a very educational experience.

## What's next for Todd: The Inter-dimensional Bot

Todd? When Todd escapes from this limiting world, he will enter a Hackathon and program his own Unity/Arduino-based mastery.
## Inspiration

As students with busy lives, it's difficult to remember to water your plants especially when you're constantly thinking about more important matters. So as solution we thought it would be best to have an app that centralizes, monitors, and notifies users on the health of your plants.

## What it does

The system is setup with 2 main components hardware and software. On the hardware side, we have multiple sensors placed around the plant that provide input on various parameters (i.e. moisture, temperature, etc.). Once extracted, the data is then relayed to an online database (in our case Google Firebase) where it's then taken from our front end system; an android app. The app currently allows user authentication and the ability to add and delete plants.

## How we built it

**The Hardware**:
The Hardware setup for this hack was reiterated multiple times through the hacking phase due to setbacks of the hardware given. Originally we planned on using the Dragonboard 410c as a central hub for all the sensory input before transmitting it via wifi. However, the Dragonboard taken by the hardware lab had a corrupted version of windows iot which meant we had to flash the entire device before starting. After flashing, we learned that dragonboards (and raspberry Pi's) lack the support for analog input meaning the circuit required some sort of ADC (analog to digital converter). Afterwards, we decided to use the ESP-8266 wifi boards to send data as it better reflected the form factor of a realistic prototype and because the board itself supports analog input. In addition we used an Arduino UNO to power the moisture sensor because it required 5V and the esp outputs 3.3V (Arduino acts as a 5v regulator).

**The Software**:
The app was made in Android studios and was built with user interaction in mind by having users authenticate themselves and add their corresponding plants which in the future would each have sensors. The app is built with scalability in mind as it uses Google Firebase for user authentication, sensor datalogging,

## Challenges we ran into

The lack of support for the Dragonboard left us with many setbacks; endless boot cycles, lack of IO support, flashing multiple OSs on the device. What put us off the most was having people tell us not to use it because of its difficultly. However, we still wanted to incorporate in some way.

## Accomplishments that we're proud of

* Flashing the Dragonboard and booting it with Windows IOT core
* a working hardware/software setup that tracks the life of a plant using sensory input.

## What we learned

* learned how to program the dragonboard (in both linux and windows)
* learning how to incorporate Firebase into our hack

## What's next for Dew Drop

* Take it to the garden world where users can track multiple plants at once and even support a self watering system