Category: Weekly Report

This is Thor here! I am working with the CATS device over the summer as a job and somewhat of an internship! When we left off during the spring semester, the device was able to scan in IDs and log people in who were in the system. We spent a couple of late nights working to assemble the devices for a “Maker Day” event where we and other creative inquiries showed our projects to curious students.

This is Owen with two safety goggles on helping me strip ethernet wire. We used this wire because it is eight wires wrapped together and we needed eight wires for our keypad. We have a couple hundred feet of it in a box so I think we are good for the remainder of the CATS CI. We decided to crimp our own wires and put them into housings to connect to our wire-to-board connectors on the PCB. The pre-crimped wires we found were individual and would have to be wrapped to stay together, and we could not find ribbon cables that would work. Crimping wires is very difficult starting out, but Brice, Maurice, and myself were able to crimp the wires we needed.

The Maker Day event was really fun because not only was our device working for others to see, but we also got to see other inspiring projects. 3-D printed stands were made for our devices to give them a more professional look for the event, and they looked really good!

This is Giandre demonstrating the devices. We could scan our IDs and the relay light came on to show that power was running through the relay.

Here is a close up of the device. We had three boxes with different designs on them. The purple has a Clemson logo, the brown has cats (CATS) all over it, and there was one more with a honeycomb pattern on it, which had a glow-in-the-dark trim around the front edge.

That event was close to the time that exams were coming up, so that was the last time we really worked on it for the semester. I was hired for the summer and have continued to work on the CATS device since around mid May.

There were a few problems that we had during the spring semester. We were not able to implement the cheaper card scanner that we were hoping for, and there was a problem with driving our Neopixel LED, piezo buzzer, and keypad. The keypad entry was being interrupted by the blinking light and beeping from the buzzer. We decided to add a second microcontroller to help with driving these components. I have been working on implementing the second microcontroller since I started working for the summer.

This is an Arduino Uno connected to a breadboard with an ATTiny microcontroller. The Arduino’s microcontroller (an ATMega328P) has multiple PWM pins which are digital pins acting as analog signals which can drive the Neopixel and the piezo buzzer. The Raspberry Pi only had one PWM pin so it was used for the Neopixel and the piezo buzzer and keypad were connected to regular digital pins. With multiple PWM pins, the ATMega328P would help control the light and sound. We would just need to control that microcontroller through serial communication with the Pi. I was testing serial communication between the Arduino Uno and the ATTiny in the picture above.

This is my precious. Owen named it “Frankenpixel”. Because the neopixel is a surface mount device, I could not test it on a breadboard by itself. So, I soldered some jumper wires to the pads and have been using them to stick into the breadboard. It works how I need it to, and I can play the end part of the treasure chest sound in the Legend of Zelda games while a green light blinks to indicate a successful login.

I decided to stop testing the serial communication from the Arduino to the ATTiny because I needed to edit the PCB and get it on GitHub. I plugged the Arduino to the Pi through USB and was able to have the Pi send the serial string “login” to the Arduino after 5 seconds. The Arduino would read that string in and if it read in “login”, it would play the sound and blink the green light. It worked beautifully. I then edited the PCB to include an ATMega328P-AUR chip which is the surface mount version of the Arduino Uno’s microcontroller.

This is the new PCB as of right now. The ATMega chip is in the middle and I changed the keypad header to an ethernet port so it is easier to plug into the board. Owen is reviewing it for me and hopefully it works so that we can order them and assemble them quickly. That is about all that has happened since the last post, and I will continue to post throughout the summer about how this job is coming along.

Until next time!

 

 

Although this week wasn’t busy for the CATS team, some big stuff happened.  The hardware team’s work began to come together this week.

Thanks to Thor’s hard work, the brand new PCB design was finalized!  We will order the new PCBs as soon as a new Mr. Bill of Materials is completed so that we can also order the new components we’ve picked out.  In addition, the funding for our project was finally approved.  This means that we can finally order a new RFID scanner for Maurice to play around with implementing.  The new housing design was completed ahead of schedule by Stefan and Josh.  We made an attempt to 3D print the housing but unfortunately our print failed after only a few hours.

The hardware team should be pretty busy over the next few weeks.  Once the new PCBs arrive we will have to learn how to solder surface mount components and someone will be tasked with programming the EEPROM we implemented in order for our PCB to be called a PiHat.  If we can order the new RFID scanner we want, Maurice will be busy for the next week or two getting the driver software in order to make it work.  We will also be printing housings and laser cutting face-plates for our newest prototype.

Hello my friends. Another week another challenge!

This week the software team had to tackle a few challenges. These challenges consisted of connecting to a server, converting the code into a script that runs on boot, and looking into RAM issues from the Raspberry Pi running indefinitely. The software team was only able to tackle the challenge of connecting to a server only by connecting the Pi through Ethernet and was also able to use it for authentication. In other words, the User’s card is scanned, and is then asked for a PIN. If the user exists and the PIN is good, then the user is able to turn on power, otherwise, re-enter PIN.

Going deeper into the software:

When the python code for the Pi is compiled, the user has 3 seconds to place their card on the card scanner before the program terminates. Software team is working on having the card reader input stay alive until the user decides to take their card off of the card scanner and back on, at their leisure. Challenges keep being presented whenever the software team changes some of the code. For example: when code is compiled and user enters the database successfully, then power is turned on, but the power only turns on for 2 seconds until it shuts off and exits the program. This is one of the problems the team is working on fixing.

The hardware team also had a few challenges to tackle. These challenges consisted of drawing a housing design for the PCB, writing a first draft of poster for the upcoming ISAM event, and creating a Pi case. The team also talked about bill of materials. They discussed the pricing values of RFID Reader, Rasberry Pi 3, Power tail 2, power cord, SD Card, Tall Pi Header, RGB LEDs, and PCB was added to the list, but no pricing details because the team does not have final pricing of it.

Both the hardware and the software team are working together to get the software and the product up and running for ISAM. The teams are trying to get the bugs out and most of the minor and some of the major problems and challenges that the teams have encountered fixed before ISAM.

So far the teams doing a great job working together to get it all done!

That will be all for this week my friends. Hope to see you all back for next week’s blog.

It’s been another exciting week with the CATS teams.  Cold and flu season is upon us, but that did not keep the teams from meeting to keep a steady pace.  This week, the CATS teams acquired a power control module that both the hardware and software teams will utilize.

The hardware team presented diagrams and plans for the PCB and housing in which the system would be contained.  The team also kept in mind potential problems that they may encounter.  The alpha prototype of the system uses different hardware than what is intended for the final design of the system, so the team ensured that the hardware changes would not affect housing and PCB plans.  The hardware team continued to plan and prepare for the trip to ISAM.

The software team made progress this week with a function that will turn a machine on and off.  In this early stage of the function, a card swipe will turn on the machine for a short time before it powers off.  However, the software team also encountered some problems.  The team discovered that the SQL server can only be accessed through Ethernet or VPN.  While this is not detrimental to early stages of the system, it presents a sizable obstacle to the late stage design since connectivity to both Ethernet and WiFi is part of the needs.  The software team will have to work with data locally until the teams find a solution to the problem.

Looking ahead, both teams are focusing on ways to overcome the difficulties that the SQL connection limitations present.  The software team will also work to advance the function so that  the control of power is more reliant on user ID and keypad entries.  Both teams are working hard to ensure that the alpha prototype of the system works and is presentable for ISAM.  

It’s been another great week for the CATS team! This week we are changing things up with a photo blog.

The hardware team developed the Alpha Electronic Schematic using fritzing.

A visual perspective of the schematic.

The software team found open-source python coding to determine keypad presses. Source: Chris Crumpacker’s blog

The hardware team’s parts arrived.

And were quickly assembled.

That’s it for this week!

It’s the fifth week of CATS and there is finally some action to get excited about. The Bill of Materials was finally completed this week, and after lots of planning and lots of debating the pros and cons between different materials, the total amount summed up to $241.51.

Although this price is over our original aim, the carefully chosen material is worth the extra pennies. For example, the RFID Card Reader we chose specifically reads TigerOne cards (Clemson University’s ID cards) so users won’t have to lug around a card shaped key in their wallet,”as if one walks around with unassigned slots in one’s wallet.”

We also chose to use a Raspberry Pi, basically a computer that fits in your pocket, for our mother board because it has WiFi that works well with eduroam around campus and because it has USB ports that make it easy to use. It also has Bluetooth capabilities and a plethora of accessories that are designed to be compatible with the Raspberry Pi.

Along with the Bill of Materials, multiple potential algorithms for the software operations were presented. They ranged from a simple pass or fail technique to a complex system of pass-codes and card scanning. The actual algorithm has not been chosen yet, but it was agreed that each one was satisfactory.

The Housing team has yet to give any feed back, and we anxiously await their plan. It’s sure to be spectacular.

 

We’ve been working on CATS for 4 weeks now. We’ve made a lot of progress, and we’re working very hard to ensure that we properly manage and design our prototypes. Our Product Manager, Brad Hord, has greatly assisted us in working through the best practices laid out in “Product Design and Development” by Ulrich and Eppinger.

At our first meeting we worked through defining our problem, and performing background research. We recognized that the problem we are trying to solve can be broken up into two parts:

1. Need for a system to control the use of machines
2. Need for a simple common identity among our users

Over the next few meetings we brainstormed possible needs, anonymously ranked all of our needs, and then brainstormed concepts based on the needs, and anonymously ranked the concepts.

This week we discussed the rankings of our concepts, and analyzed what aspects of each concept resulted in their rankings. We then generated requirements for our prototype based upon the results of our needs, and concepts rankings.

The members of the team then self-divided into a hardware, software, and housing team. The teams were then tasked with generating a prototype BOM, algorithm block diagram, and an enclosure mock-up.

 

Next week we will discuss the different prototype proposals, and we will finalize the design for the CATS Alpha model.