## Inspiration

As a result of the pandemic, most of the electric labs are moved online. Currently, we have software such as Multisim that can stimulate the circuits and aid the labs. However, we want to find a way to make the labs more "real" by allowing us to build actual circuits on the breadboard and implement an automaker to help the labs getting marked.

## What it does

The user can firstly login into the system by pre-registered username and password. Then, there will be a list of tutorials, from which the user can select one and enter the corresponding section. A sketch of the circuit will appear on the screen and the user needs to build the circuit on the breadboard and plug the pin into the appropriate position. Then, the system can read from the pin and check the value read from the board against the expected outcome.

## How we built it

* Login system: allow users (teachers or students) to register and login, record the marks and analysis the trend of study

	+ For each student: must refer to a teacher, have username and password set
	+ For each teacher: have him/herself an account with username and password, have a list of students that is under the teacher’s name
* Prototype database: pre-draw circuits and record them. Setting solutions to be checked

	+ Main components of a circuit: battery, resistor, capacitor, potentiometer, thermistor
	+ Very simple and easy circuits
		- Parallel and serial connection of resistors
		- Estimate the resistance of a potentiometer
		- Design a specific current/resistance/voltage
* Hardware connection: read data from Arduino Uno and send it to the software.

	+ Check the answers to the solutions and reflect the result in the form of a mark.
	+ Collect the voltage/resistor/current from the breadboard and send them to the software
	+ Compare the results with the solution and provide a mark for the overall performance

## Challenges we ran into

**Communication**:

* The team members are located in two different time zones so that the collaboration becomes harder and there is a very limited period of time that members can work at the same time.
* Only one of the team members owns the hardware (including the board and other components). Therefore, only this person can work on the hardware part and solve related problems.

**Hardware**:

* The proposed project offers tutorials for both DC and AC circuits and that's why we have an oscilloscope in our project. However, the Arduino Uno board does not have the Digital-to-Analog transfer, meaning that we are unable to generate AC waves without a wave generator. We could only truncate the project and focus only on DC circuit tutorials.
* The electric circuit components we own are limited to a small range, we are unable to build complicated circuits and test them. Moreover, we don't have access to a real oscilloscope or multimeter so that we are unable to detect potential errors in the circuit. To prevent detrimental effects to the board and other components, we decided to only work on the simple circuits.

**Software**:

* We wanted to design an user-friendly interface that allows users to drag the circuit diagram, however, we failed to do so.

## Accomplishments that we're proud of

This is the first time we work on a project that involves both software and hardware. Even though this project looks a bit simple, we put effort into communication within the team and building connections between the software and hardware. There are limitations due to the hardware we own, but we tried our best to build a project based on what we have and the majority of the proposed project has been realized.

## What we learned

* building connections between the hardware and software
* working on the Arduino Uno board
* collaboration and problem-solving with teammates under the remote condition and different time zones

## What's next for How Circuits Work

* We are looking for a method to generate the AC waves by using either the wave generator or the op-amp (if we have a chance to purchase one). This will allow us to build more complex circuits and use the built-in oscilloscope in a better way.
* We want to make the user interface more organized and introduce a playground where the users can customize their circuits and test functionalities (similar to the Multisim).
## Inspiration

As an Econ major and Education minor, I'm really interested in development of new pathways that improve the education of future generations. I also like puns. By combining this background with a desire to do something more out-of-the-box, I knew I had to go Beyond the Pail.

## What it does

Beyond the Pail serves as a tech-enabled bundle of joy for the precocious and inquisitive child. With a focus on measurement technology (encompassing elementary lessons on weight and different measurement systems), this Pail helps target the K-5 demographic to develop their spatial-kinetic learning skills, which are often overlooked in our current test-focused and behavioral-dependent educational system.

Well, that's what I wanted it to do. During this hackathon, I managed to figure out how to jury-rig the Arduino and get the LCD to display "Beyond the Pail" on the side; that's about it.

## How I built it

I obtained an Arduino, breadboard panel, and LCD display from a friend. From there, I spent a few hours trying to figure out how to connect all the wires so that the LCD would actually display stuff (it turns out that I had two wires in the wrong spot, which, when corrected, finally made everything work).
After that, I spent some time learning how to code in Arduino, and created custom code to successfully change text on the bottom of the screen, but leave the top text the same.
Finally, I got my roll of duct tape and taped the Arduino board to a smiling Jack-O-Lantern bucket that was lying around.

## Challenges I ran into

I'm not a CS major. I'm not even an engineer! It was a steep learning curve to figure out how to actually put an Arduino together, especially since it's been a few years since I've played with electric circuits. After some trial-and-error, plus squinting at more than a few diagrams and online forums, I managed to make the LCD turn on. From there, I tackled the challenge of learning Arduino code (albeit a minor one - my CS106A knowledge came in handy!)

## Accomplishments that I'm proud of

I entered into this hackathon with very little development-focused coding background, and certainly no experience with "hardware hacks". Learning how to use Arduino to accomplish something on the hardware side was a really great accomplishment for me; it's something that I've wanted to do for years, but never had the impetus to do until now.

## What I learned

I learned how to build a functional Arduino circuit, troubleshoot physical and software-side bugs, and creatively imagine a better future through the EdTech space. I also learned that there are a lot of hardware-side ideas that are easy to create in theory, but hard to implement if you have no prior knowledge whatsoever on the hardware side.

## What's next for Beyond the Pail

Adding more features that help achieve the spatial-kinetic goals I have set, including a load cell connected to Arduino to measure weight real-time (which is what I originally wanted to try to create).
## Inspiration

Have you ever finished up ECE lab or a small project like a PennApps hardware project and found that there were all of these screws, nuts, and resistors lying around everywhere? Or maybe you're just a hardware enthusiast but hate keeping track of all of your stuff (we like to do the old-fashioned way: the "hardware pile.")
With InvenTeX, there is finally an easy solution to inventory maintenance. Gone are the days of hoping you have quarter inch threads and settling for glue, or even having to remember the resistor color code. InvenTeX does all for your inventory, so you can focus your all on your hardware.

## What it does

InvenTeX identifies objects you want to keep in your inventory and helps you track them in groups so you don't have to.
The workflow of InvenTeX is simple.
When you first launch the app, you can choose to see what is in your inventory (at this point, nothing) and to insert something into the InvenTeX.

#### Taking a 100-ohm resistor as an example:

To insert, all you need to do is press the button on the app and take a picture of your resistor. It will then be identified and you can drop it and any other 100-ohm resistors into the loading bin. If you already have 100-ohm resistors stored in InvenTeX, your new resistor will be placed with the ones you already have in store.
To retrieve, you start from the drop down menu inside the app. There it will show everything that you have stored in InvenTeX. Pick the item you want to retrieve and InvenTeX will pop out the drawer with it. And once you're done grabbing what you need, the drawer will pull itself back in and you don't even need to remember where you got it from.

## How we built it

Initially, we wanted to use 3D printed parts for the hard to craft pieces of the enclosure and internal hardware. However, after finding out that we had access to laser cutters and an almost infinite supply of acrylic, we changed up our modeling plans and building timeline completely. We also initially intended on using a standard android app and using Bluetooth as the connection interface between it and the Raspberry Pi. And again, all plans changed with the introduction of Expo.io into the hack.

### Hardware

The entire enclosure and all of the internal structure is made with laser cut acrylic (1/8" and 1/4" black acrylic). We are also using two stepper motors to drive the belts and two servo motors to actuate the trap door (for part insertion) and magnetic arm (part retrieval).

### Controller

The Arduino Mega 2560 is the brain of the controls. The Arduino is only controlling movement and waiting for communication from the Raspberry Pi through I2C protocol. We are using an Adafruit Motor Shield (V2.3) for easy stepper and servo motor control with its built in stepper classes and PWM control for the servos. Everything draws power through a 5V external power source.

### Software

**Vision Processing**
Due to the Raspberry Pi camera not being clear enough to detect color bands of resistors, we switched over to phone cameras that had greater resolution (but also came with some other issues of connectivity, see below).
We started with simple color detection, differentiating between LEDs of different colors. Then moving on to shape and color detection, differentiating between different nuts and bolts. Finally moving on to pattern recognition and orientation detection, differentiating between resistors with different color bands.

**Communication**
Since we had replaced the Rapsberry Pi camera with the phone camera, we needed to transfer the image to the Raspberry Pi for vision processing. HTTP requests to send the image from the phone to the Raspberry Pi. HTTP requests to send retrieval signals to the Raspberry Pi.

## Challenges we ran into

### Software

**Vision processing:** Raspberry Pi camera is difficult to focus without a specialized tool. Resistor color codes had to be fine-tuned (HSV values). Resistor colors were also difficult to differentiate from each other and from the resistor itself, being heavily influenced by the color of the light source.

**Phone-to-Pi Communication:** We had to determine a system to send information to pi and get information back. We considered using bluetooth and an online database but ultimately decided to use HTTP protocols. Considerable thought went into organizing into which device ran what kind of processes and how to share information between the phone and pi.

**Expo Development:** No experience with React-Native. Rendering code changes would sometimes hang, so app development was not as ideally productive.

### Hardware

**Fitting Components:** Because all of the internal components of the enclosure must have slots and notches on the outer in order to fit properly, many of the internal structures that had to be swapped or structures that needed to be added in later for internal support had to be glued in making some areas less structurally stable than we would like.

**Stepper Motor Belt Tension:** The tension required for the stepper belts to drive properly was actually a bit too much for our structure to handle and some internal pieces broke off from the main frame due to tension forces. We fixed this by using zip ties instead of glue for a much stronger belt support structure.

## Accomplishments that we're proud of

**Integration:** We really had to utilize every possible piece of knowledge of every team member in order to fully integrate this project. There was (albeit simple) wiring to do be done with the microcontrollers, all the way up to implementing two different servers. In terms of code we wrote code in C, Python, and Javascript. We had to be able to pass information between all of our systems through wired and wireless connections. This extremely wide range of integration is not something we have ever done in so little time as a team and we're really excited that we pulled it off.

**Fully Assembled CAD Model:** We needed to know all of the tolerances in the system before printing or cutting any piece of it. In order to have everything fitted together as seamlessly as possible, we generated a fully assembled CAD model of every single component in the hack and cut almost every piece in one go. If we had completed the project by designing and cutting chunks at a time, without taking some time to look at the whole picture (literally) then there definitely would have been some more trips to the laser cutting room. We're glad that we took the time to fully CAD everything so that we could have all of the measurements and designs happening simultaneously between two CAD designers be integrated with each other.

## What we learned

## What's next for ToolHub

Bigger == Better. We want to try to use stronger materials with a stiffer frame that will not break down on us. We will also perform some stress analysis before redesigning some of the internal bracing in order for the structure to hold under the stepper torque.
The vision processing algorithms and implementation could also always be snappier and more robust.