Table of Contents
The Space Research Company — Jan 2015-Apr 2015
About the Project
As part of my Technology, Arts, and Media (TAM) Minor, I worked in a team of students on a project for a client affiliated with the University of Colorado (CU). Our team worked for The Space Research Company (TSRCo), a startup headed by a team of graduate students at CU.
Our first task for the company was to design a branding guide, including a logo and color scheme. Originally, while working on the project, we did not know much about the company, only that they planned to manufacture Cube Satellites (CubeSats). With this small amount of knowledge, we began our designs.
The first iteration of logos heavily focused on the cube satellites. We weren’t sure about the actual color scheme, and so for the most part we created black and white logos. The TSRCo team did not like our designs as a whole; they felt the logos limited them too much in terms of the trajectory of the company. However, a few pieces of each logo stuck out to them.
The second iteration, then, was an amalgamation of these logos. They had told us they liked the earth from one design and some of the typeface choices of other designs. We combined these to make two different versions of a singular logo and created a small branding guide for them to peruse.
Once again, TSRCo was not satisfied. Our intent to make them different from their competitors resulted in a logo they considered amateur. They also rescinded some of their earlier likes, asking us to change the direction of the logo design.
To facilitate this, we had them send us their mission statement, along with colors, typefaces, and images they wanted their company to identify with. We used this information to make simpler and cleaner logos that adhered more to their desired color scheme and general “feel.”
This set of logos came closer to achieving the desired goals. TSRCo was more satisfied with this set of logos, but they still felt it lacked the “spacey” and “tron-y” feel they wanted.
For the fourth iteration of logos, we further refined based on their suggestions to different versions of a planet with orbitals. This came even closer to the desired outcome. In fact, they liked the designs a lot, but wanted some color and typeface alterations. With this iteration, we decided to end the logo design phase of the project.
In addition to the logo and branding guide, we were expected to create a power point template, a document header, a business card, and a promotional video for the company.
With the logo decided upon, the branding guide and other templates came quickly. We then only had the video left.
The promotional video was designed as part of their pitch for the New Venture Challenge. The video needed to convey their mission statement, what the company did, and inspire investors.
Collaborating with TSRCo, we created a script and a general storyboard for the video. Because the video was going to be presented as a part of NVC, they wanted to do the narration of the clips themselves. So we created the animation for the project and then timed it to match their narration. We also created a backtrack for the video.
Lessons Learned
The largest benefit from this project was working with clients. The company consisted of three separate students, all with varying ideas on exact details, but a common vision they wanted us to bring to life. It was great getting to work with TSRCo, even if it was sometimes difficult or frustrating to meld the creative process to specific goals. But overall I found the experience enjoyable.
Media/Project Resources
My Logo Designs
Final TSRCo Promotional Video
interactiveFiction — Oct 2012-Dec 2012
About the Project
In my sophomore year I had the pleasure to take Software Engineering Methods and Tools, the first real project-based class for Computer Science majors. The goal of the class was to make a web application of some sort in groups of three to four people. I had had the idea of making a choose-your-own-adventure game, and proposed this to my group-mates, who liked the idea.
Our first iteration began with a simple tool assessment. We knew that our web app would use HTML5, CSS, and some Javascript, but we also decided to research SQL databases and server-side languages and interfaces, such as PHP. During the beginning part of the class we had learned about Java Web Services and experimented with mySQL and PHP, but the experience made us wary of using either technology extensively. Instead, we opted to use only front-end technology: HTML5, CSS, and Javascript. We began implementing our first version of the user interface, which presented the user with a bunch of boxes: a story box, an information box, an action box, an inventory box, and a reaction box. For our first iteration we focused on making the story box and information box work correctly together. The information box was designed to display information about an item, location, or person when the corresponding word was clicked on in the story box. To make it more obvious what words were clickable, we made the words bold and added a hover effect as well. Originally we had hoped to have a simple song playing in the background, but the design of our app would not allow us to keep playing a song on loop. Because each individual part of the story was on its own html page, there was no way to continuously play the song. Instead, we chose to implement sound effects, where different actions would produce different sounds. At this stage we did not actually implement sound effects, however. We focused more on effect creation.
Our second iteration focused on creating content for our web application. It became obvious very quickly that in order to showcase our work we would need a lot of story written and implemented. It also became obvious that we would not be able to completely finish the stories we had started. However, we soon had enough to at least implement features we had originally proposed. For this iteration, that meant making action buttons work so that users could actually advance through the story. That was not very difficult to implement, and soon we had the first few story pages up and running. During this process we decided to declutter our interface and combined the reaction and story box into one. We also implemented the sound effects. Finally, we began to refine the design of the webpage and also looked for a free web host for our site.
The final iteration consisted of some tweaking and implementing a few last-minute features. One item that we never fully implemented was the idea of having some logic-based mini games to diversify the gameplay. We did introduce a riddle into our story tree, but actual mini games were never introduced. We also had wanted a way for players to resume the game from where they had left off and wanted to make it to where people couldn’t cheat by hitting the back button on their browser. We looked into session storage and local storage for storing pertinent information. We decided to use local storage to store the path to the page the user is on. It worked very well. Instead of using the anchor tag to go to the next page, we used javascript to replace the current window location, which did not create a new entry in history. This made it so that if a user pressed the back button on their browser they would return to the home page instead of the previous page in the story. The last large piece of interactivity we wished to add was the use of inventory. The user could pick up items and then use them to interact with other objects in the story. This too was implemented with Javascript.
In the end, we had really only created the beginnings of a web app that was designed very poorly for maintainability. But I was able to create something I was interested in and really explore technologies I had wanted to learn.
Lessons Learned
In the end we had over 65 individual HTML pages organized in a hierarchical structure. Every inventory item, action, and interact-able word was hard coded. The project was not maintainable or scalable. Had we chosen to use a database instead, we could have designed it to use a single page and simply change the text on the page instead. We would have been able to save user sessions in the database as well.
Another technology we could have benefited from was git. We had originally tried to use git, but became so confused that we decided to keep the entire project in Dropbox instead. Dropbox was not a terrible solution — after all, it has version control and is automatically backed up to the cloud. But Dropbox does not allow for multiple users to edit the same document at the same time. Asynchronous editing would have saved many headaches and would have been possible using git. After this course I learned more about git and used it at an internship and I can now appreciate version control a lot more.
Since I had pitched this project, in some ways I was the “leader” of our group. I provided a lot of the direction for the app even though I was not responsible for most of the story. I learned a lot about staying organized and fulfilling a leadership role. I realized very quickly that leadership is about providing direction to those involved, and encouraging them to achieve their own goals while contributing to the larger whole. I think our group was able to do that well.
This was another opportunity to learn about time management. Since we had iterations to stick to it was a lot easier than other, more nebulous projects. But it still required planning and estimating how much we could actually achieve in a given iteration. Overall, we were quite successful, except for actually finishing the story arcs. We would have needed more than a few months to complete the story options since they branched so quickly.
Media/Project Resources
Downloads and Links
Freshman Design Project — Jan 2012-May 2012
About the Project
In my freshman year I took GEEN 1400, Engineering Projects. For this class students form groups and then design a project to be presented in a Design Exposition at the end of the semester.
My class was given free reign in choosing and designing a project as long as it had some impact/greater purpose. So we began by thinking about a need instead of a product. One of the most basic needs is water, and in third-world countries, it can be difficult to fetch. With this in mind, we designed a wind-powered water pump.
Before we could design the pump we had to research wind turbines: which turbines are the most efficient, which require the least amount of effort to begin spinning, which can self-start, etc. We discovered that there are two major types of wind turbines: vertical and horizontal.
At first I found the terminology confusing. The blades of a classic turbine — like a pinwheel — struck me as “vertical.” After all, the blades moved vertically through the air. Likewise, the less-common vertical turbines’ blades moved horizontally through space. But the name of the turbine comes from the axis of the turbine, not the blades.
Horizontal wind turbines had a horizontal axis. The blades spun vertically around this axis. We discovered that these turbines are commercially more widespread, but usually had to be started by a generator before they could move freely in the wind. They also had to be positioned correctly to catch the wind. If the wind blew the wrong direction, the turbine was useless.
Vertical wind turbines had a vertical axis. The blades spun horizontally around this axis. We learned that these turbines are more commonly used by households or smaller companies, most could be started using the wind alone, and would work for any wind direction. They were also safer for the animal life, since it is much easier to avoid a large solid object than constantly-moving spinning blades.
We immediately saw the benefit of the vertical wind turbines and decided to use them for our project. However, further research revealed that there are two major types of vertical wind turbines: Savonius and Darrieus.
Savonius-style turbines are mostly powered by drag. They match the speed of the blowing wind and can start themselves. Darrieus-style turbines are mostly powered by lift. They can actually spin faster than the blowing wind, however they have to be initially started before spinning on their own.
We also researched different water pumps. There are three main types of water pump: Diaphragm, Rotary, and Piston. We learned that diaphragm pumps create the most pressure; they could pump more water faster than any other kind of pump. Rotary pumps are the easiest to use — simply rotate a handle. Piston pumps are the most common type of pump.
After comparing all of our options, we opted for a savonius-style turbine and a rotary pump. We could streamline the process of using the wind turbine to crank the pump just by making sure they rotated in the same direction. We would lose the least amount of energy this way.
We took a very crude sketch then used SolidWorks to design our turbine. Since the goal was to design a low-cost water pumping system, we decided to use recycled parts in the design. We used bike wheels as the “base” for the blades and later decided to make the blades out of a storage shed door. We also looked at buying as many materials as possible at second-hand shops. We did, however, decide to buy a water pump; it was easily the most expensive part of our project, but well worth the cost.
Based on initial designs, we used Betz’s Law to calculate the amount of power we could generate at 100% efficiency, and arrived at 1,072 watts. We then calculated a maximum and minimum torque for our turbine. Maximum torque we calculated to be 3.84 lb-ft, and minimum torque was 0.24 lb-ft.
We then proceeded to assemble our materials. Our first issue we ran into was that our bike wheels we had received were bent. We did our best to straighten them, but this added a lot of instability to our design we were not anticipating.
Our initial design was to have a small pole run through the base of the turbine and act as the axis for our wheels. The size of the pole was constrained by the bike wheels, as the wheels had to fit on it perfectly. We soon discovered that the thinness of the pole made our design extremely unstable. To compensate, we had to edit our base design so that it included a frame that would keep the top of the pole in place.
We decided to wedge the garage door onto the spokes of bike for the blades. This became a long and tedious process. We had to fit the garage door onto the wheels, mark where the spokes overlapped, and then notch the garage door using some knives.
Finally, we were able to attach the water pump. We attached a large gear to the base of the turbine, and then attached a smaller gear to the water pump. We used a bike chain to connect the two gears and allow the blade to turn the pump.
In our classroom, we were able to turn the turbine by hand and have the pump work, with a few caveats. First, turning the turbine required a lot of energy. The pump’s pumping mechanism had a large amount of friction that the turbine had to overcome for it to work. In essence, an average wind could not blow hard enough to turn our pump. Secondly, the bike chain had tension issues. It would periodically fall off after a few minutes of successful turning.
However, the wind turbine itself worked like a charm. It spun in the wind at very fast rates, and had our pump had less friction, would have been able to pump the water fairly easily.
When we had completely finished with our creation, we realized that our Bill of Materials was quite a bit higher than we had hoped. The entire project cost us about $340. Almost a third of that cost was the water pump itself. A more affordable, easier to use water pump would have greatly benefitted the turbine and its intended purpose as a low-cost way to retrieve water.
Lessons Learned
Many of our design issues could have been avoided by simply adding more iterations to our project. In essence, our final result was really our first prototype. We never tried making our design on a smaller scale and were not able to test it in the wind until the day of the Exposition.
Going through this process, and realizing our error, helped me to better appreciate the art of engineering as well as the science of it. I learned the value of making small “throw-aways” that could test designs easily without expending a lot of effort. I would apply this principle in a later class, Startup Essentials. It also taught me the importance of testing often as every given opportunity, even if the entire project is not done.
This was also my first major group project. One of the unique things about group projects with faraway deadlines is that you have complete control over your learning. Everything about this project we had to research ourselves; very little fundamental engineering concepts were taught in the class. The class focused mostly on what it means to work on a project and to work in a group. As a computer scientist, I found this especially challenging. While many of the students in the class were mechanical engineers and had some experience with the concepts necessary to the class, I was mostly in the dark. Not only that, but I was very uninterested in building anything.
I wanted nothing to do with any of the mechanical equipment, I had no desire to really learn how to use different tools, and overall I found the class not very appealing.
Of course, once we began work on our projects, that changed. I still wasn’t too thrilled with the actual building and assembling, but because I liked the idea of our project I really wanted to see it completed. My largest contribution was probably notching the blades for our turbine, and while it didn’t seem like much, I was pushing myself out of my comfort zone. I enjoyed watching our project came together and was downright ecstatic when we had completed it, even though it wasn’t perfect.
Most importantly, I learned how to work with others towards a common goal. I was quite used to working by myself on a project. I didn’t often have group projects in high school, and certainly none of this magnitude. It was my first time having to coordinate a project with four other people while still having other classes as well. In effect, it helped me learn better time management.
Overall, I sincerely enjoyed my journey through the class, even though I had not originally been too thrilled with it, and I am glad I had the opportunity to take it.
Media/Project Resources
Video Demo
Wind 4 Water Development
Downloads and Links
