Wednesday, June 5, 2013

Senior Project

For my high school senior project, I set out to build a Quadcopter.

Day 1:
The initial step was to construct the copter.  In order to write the code that would make this copter fly, I would need the hardware to be in place, so I began by fully building the structure of the coptor.  Thus, the first day was spent entirely on construction.  And a remarkable amount of progress was made.  I was able to fully construct the structure of the copter in just one day.

The first task was to assemble the four arms, one at a time.  This required attaching the legs and the motors to each arm.

All four arms assembled with motors and legs.
Next the four arms had to be secured to the mainframe, and the motor wires routed to accommodate the electronic speed controllers and circuit boards that would be later installed.
The coper with the four legs attached to the mainframe, and with the motor wires routed appropriately.

Above the base of the copter sits a "tower" that stacks higher, and allows for additional circuit boards and sensors to be mounted.  This was the next section to be attached.

The fully assembled copter with the tower stacked on top and the propellers attached to each motor.

Day 2 - 4:
The ESCs attached to their motors
I focused on arming the Electronic Speed Controllers (ESCs).  Every motor on the coptor would be powered by an ESC, and it is the ESC that sends a specific and regulated amount of power to the motor, which determines the speed and direction of rotation.  As such, it is vitally important that the ESC function correctly and that I can properly control them via code.  Having never used ESCs before, I was starting from scratch on using them.  Through research online, extensive trial and error, and some dumb luck, I was finally able to write an Arduino sketch to make a propeller turn.

The copter with the power distribution board install.
This board would later be remove and replaced via an
alternative wiring scheme.

The copter was set up so the power supply would feed into a main board, and the main board would be attached to the Arduino, which would control the entire copter.  I choose to bypass the power, so I had to solder all the ESCs power supplies together, and then to a connector which would go directly the battery.  This kind of modification could not be foreseen, and it is why projects like this are develop largely as they are constructed.  It would've been very difficult to foresee this change until it was time to solve the problem of bypassing the power distribution board.

In the process of connecting the four ESCs together, I indavertantly wired one ESC in reverse polarity, and then ran current through it.  This created smoke (and a small fire), and destroyed that ESC.  It was at this point I had to solve the problem of only having three ESCs.  On the one hand, I could've purchased another ESC and had it shipped from California, but that would've taken almost a week.  I could've bought a generic ESC; however, every model ESC run on a different current and would produce different levels of output at certain motor settings.  So this was a bad choice.  So I decided to remove one of the four arms, and adjust the third arm, making the quadcopter into a tricoptor.

Once I had the copter's motors working, I was able to reattach the tower and focus on the programming of the copter.  Which was how the balance of the first week, and the second week was spent.

In this project, I really felt like a professional engineer.  I arrived daily and worked on completing a project as would a professional designing and constructing something.  It was especially fun having an office where I could work everyday.  An office I would arrive in and be able to pick up where I had left off the previous day.  And an office where various friends could drop by and "help" throughout their days.
And of course, I got by with a little help from my friends.

Wednesday, January 30, 2013

Text Statistics Project

Hello World Again,

This week I got distracted from the project I've been plowing away on (an app for the Jones Institute), and spent a few minutes on a text statistics mac app.

A little background:
Earlier this week Mr. Warden told me his wife is a medical transcripionist, and she is paid by the typed line, with lines that have no text being excluded.  So he needed a computer program/text editor that can determine how many blank lines are in the text.  He said after conciderable searching, he couldn't find any Mac apps that count the number of blank lines in the text.  This didn't surprise me because it is a little bit of a wired metic to measure.

So, I decided to play around with some code that would count the number of blank lines.  It ended up taking me about 20 minutes to have a Mac app scrapped together that gets the job done.  And the majority of that 20 minutes was figuring out what how to work with a Mac app, as opposed to the iOS apps I'm much more familiar with (they're mostly the same [the same language], but there are also many differences).

Going Forward:
I now have to decide whether or not to put the app on the store.  My dilemma is it is a very simple app with a very limited usefulness for a small set of people:

- Learn Mac Development through finishing the project
- Learn the process of publishing a Mac App (as opposed to an iOS App)
- Publish my first Mac App!

- Have to get credentials as a Mac Developer (at the moment, I only have them for iOS), which will cost me $99/year
- For an app this simple, with such limited applications, is all this really worth it (Afterall, I can always just send the hacked together version to Mr. Warden)

I'm leaning towards publishing, but still very much undecided.

Any feedback would be appreciated!

Post a comment below.


PS - Next week I'll be getting back to the Jones Institute app.

Tuesday, November 6, 2012

Lately... November 6th

Hello Again,

Here is a quick update on what I've been working on lately:

  • I've started a project with the Jones institute, which would become an app for pregent women in the Jones hospital system
  • I've also been researching bluetooth technology.  I want to invent a product that could revolutionize child safety, and I think bluetooth is a great medium for this.  However, I've found bluetooth is not ubiquitously understood, and can at times be hard to understand.  So I've been doing quite a bit of studying into how the protocols, and hand-shaking works.  Something that is likely going to be my most difficult project to date, but quite possibly the most rewarding.  More info to follow
Smaller, less time intrusive, projects:
  • Studied some of the new API's in iOS 6 via Ray Wenderlich's new book
  • Some work on connecting a Parse based backend to a website, in order to facilitate a technological approach for the CHCS Academic Team
  • Some updates to the Cape Henry App
  • A basic mac app to get my feet wet.  I had never done Mac programming before.
  • Worked with 6th Grader JR, on submitting his first iPad app to the Apple App Store

Future Projects:
  • I'm very interested in building a physical Tetris game.  So interested, I think I'm going to start shopping for parts.  It would be a rather large build, plus a fairly complex programming task.  However, I found some great starting points online.

Friday, September 21, 2012

Sept. 18th - 21st

Hi again, this week was an interesting one.  With the unveiling of iOS 6, I did some reading on the new APIs; particularly the social API's and Passbook.  The passbook tutorial was great.  Now I'm really excited to build some passes!

I also built my first Mac App.  I followed one of the terrific tutorials from Ray Wenderlich, who runs an amazing site.  The tutorial I followed is available here.  I only got through part one, but hopefully next week, time permitting, I'll do some more.  I'd like to learn more about mac apps in general, as the bulk of my skill is in iOS.

Finally, I worked a new project for Chris Herren.  After speaking with him this weekend, I wrote a proposal, and talked it over via conference call with his staff.  Once they have return the updated proposal to me, I'll be set to get started.

- Andrew

Friday, September 14, 2012

$10 Robot Challenge Submission

Math Player


This submission is a category two robot controlled via an Arduino Uno with an ATmega16U2 processor.  The robot is designed for primary education.  The robot is a fun, constructive game for younger children to use while learning simple arithmetic.  It randomly generates an addition problem within set parameters and displays it to the user in a simple, comfortable format.  The user can then enter their response on the colorful, attached keyboard.  The user's inputted response is displayed, and can be submitted.  The robot will check a user's inputted solution and immediately provide feedback for correct or incorrect results.  If the user's answer is correct, the robot lights up, and then generates a new problem.  If the user is incorrect, the robot vibrates, and allows the user to try again on the same problem.

This robot would likely be built in a factory and then shipped to end users as wiring and soldering are required  The only necessary accessoriey for the unit is a $1 9V battery.

This prototype was produced for $90.13.  I believe this robot could be massed produced for 53.87 per unit when produced in quantities of 100 units.  I would expect this number to be significantly lower if production was 1000 units, for example.

Educational Application

This device has tremendous educational applications.  It is designed primarily for primary education; specifically younger children learning simple arithmetic.  The robot randomly generates math problems for the user to solve.  The robot will then check the user's inputted solution, and immediatly notify them if they are correct or incorrect.  Incorrect answers require the user to try again before moving on.  The robot entire functionality is educational.

Tools & Materials

All parts and equipment are easily found and readily available from many resources, including most general electronics stores.

For a total cost of $90.13.

* The included I2C Backpack is necessary to daisy chain the displays (reducing the number of Arduino pins necessary).

Construction Process

The robot was constructed in two phases: Hardware & Software.


  1. All parts and materials were compiled
  2. All 3 4-Digit 7 Segment displays were assembled according to Adafruits included instructions (available here).  They are very easy to follow, so I won't reproduce them here, although here are a few project specific points:
    • Jumper wires were soldered directly to the board.  Adafruit's instructions provide for male header pins to be soldered to the board, however, I'm not going to be attaching this board  a breadboard, so jumper wires work a lot better.
    • Since this project uses 3 individual 7-segment displays, daisy chained together, we need a way to address each display individually in code.  In order to accomplish that, one display will be left alone, another will have the A0 pad bridged, and the final will have the A1 pad bridged.  The A pads are on the side of the display opposite the adafruit logo (shown on the left edge of the board in the picture below).  This step is very important.  If forgotten, all the displays will show the same thing (a lesson I learned the hard way).
    • Further, since we are daisy chaining the displays together, all of the leads of the same type can be soldered together.  For example all of the "SCL" leads coming from each of the boards were soldered together, and then to one extending lead (Note the joint where the three individual leads meet with the extending lead was covered to prevent shorting when the project is put together into the final case).  This extending lead will eventually be connected to the Arduino.
Photo from Adafruit Learning Technologies.

  1. The case was then cut to accommodate the three 4-digit 7-semgent displays
    1. A rough sketch of the placement was made, and then a scizzors was used to make an initial, rough hole in order to put the nibbler into the plastic.
    2. The nibbling tool was then used to cut a rectangular slot for each display.
    3. Each slot was then filed down to smooth out the edges and facilitate a better fit for the displays.
  2. Each display was then glued into the case.  An initial, small amount of glue was placed inside the case to secure each display, and then the majority of the parimeter was glue to ensure a snug fit and a tight seal.
  3. The case's door was then measured and cut to accommodate the Arduino's USB port.  In a production version of this product, this would be unnecessary.  However, in order to facilitate easier testing and debugging in this prototype model, this hole was cut.  The inital hole was again made with a scissors, and then cleaned with the nibbling tool and a file.
Photo of the project case - including the door and included screws
Photo from

   4.  The Arduino was then placed inside the case.  It's a close fit, but a drop of hot glue was added to ensure it wouldn't move.
   5.  The keyboard matrix was then wired to the Arduino.  It requires 7 pins, so I attached 7 jumper wires to the keyboard, and then plugged them into 7 consecutive Arduino pins.  The keyboard was then lightly glued to the outside of the case to hold it in place, with the keyboard sticking out, and the wires inside the case.
   6.  Turning back to the displays, recall we previously soldered all like leads together; now we need to connect those leads to the Arduino.  The big solder joints where the 4 wires meet was lightly glued to the case in order to prevent the wires tangling or obstructing the closing of the case.
   7.  The vibration motor was then soldered to two leads, and then attached to the case (an adhesive came attached to the motor).  The leads were connected to the Arduino.
   8.  Finally the LEDs were wired and glued into their positions.  Their wires were carefully placed under the other large bunches of wires already present.


  1. Using the Arduino IDE, a new program was created and set up.
  2. All necessary variables and hardware were declared and initialized.
  3. Some basic setup was preformed in the default setup method.
  4. The standard loop method was then set up to check if a key was pressed on the keyboard:
    1. If a number key was pressed, update the internal variables and display the user's inputted value on the screen.
    2. If the "*" key was pressed, check the user's inputted solution and respond accordingly.
    3. If the "#" was pressed, clear the board.
  5. A method to generate new problems was also established:
    1. It first resets the displays to ensure they are prepaired for the new data.
    2. It then randomly generates a new value for each display, and prints it to the display.
    3. Finally, it makes sure the user's input display and the associated variables are clear.
  6. A method was also created to check the user's inputted solution:
    1. This method begins by comparing the value the computer knows to be correct, with the value the user entered.
    2. If the user is correct, the computer turns on the LEDs, and fades them out.
      1. When the LEDs are done, it tells the computer to generate another problem
    3. If the user is incorrect, the computer blinks the displays, and vibrates the unit for two second.  It then clears the user's display and the associated variable, to allow the student another opportunity to work that problem.  The computer requires a student to successfully solve a problem before generating a new problem.*
Note: these directions follow the overall flow of the code.  The code is also extensively commented.  To get the source code (available open source), see below.

*This is one of the tremendous benefits robots and computers provide for education; they are infinitely patient.  The robot will continue to present the same problem until the student masters it.

Mass Production
This robot can absolutly be mass produced and thus, the cost significatly reduced.  One inital (and major) cost reduction would come from the processor itself.  In this prototype, an untire Arudino Uno was part of the robot.  However, only the ATmega16U2 (the processor) is essentially the only absolutely necessary part of the robot's brain.  The rest of the Arduino board provides an easy way for the chip to be programmed (and a few minor, but required parts, such as resistors).  So in mass production, the ATmega16U2 could simply be programmed in an Arduino Uno board, then removed, and inserted into the robot.  The chip itself costs usually retails for $5.95, which amounts to a saving of $24.00 per robot.  And in bulk, a discount of $1.19 is available on order of over 100 units from Adafruit.

Similarly, the 4-Digit 7-Segment displays retail for $9.95 each, however, orders of 100+ save $1.99 each, for a savings of $7.96 per unit.  In addition, the keyboard matrix can be purchased for $0.79 less in orders of 100+ units.  Orders of 100+ cases save $2.39 per case  The vibration motor will also cost $0.99 less per 100 units.  And $0.79 can be saved on the battery case for orders of 100+ units.  The LEDs will also be $0.07 cheaper in 100 unit order.

Therefore, the overall cost per unit would become $53.87 per unit, assuming at least 100 are purchased.  This is a savings $36.26 per unit.  And that just the start.  This is for 100 units.  The savings would be further compounded if 1,000 or 10,000 units were purchased.


This is a video of myself demonstrating the robot.  There is no sound.


I tested the robot with a group of second graders.  Initally I started with two students, and with minimal instruction, let them play with the robot.  The results are truely astonishing.

Note in the videos, the robot is being powered by a computer, instead of a 9V battery, as described above.  In these cases, I wanted more analytical data to be recorded as the student were using it, so I connected it to a computer instead of a battery.  To the robot, it makes no difference where its power source comes from.

For example, the "#" key on the keyboard is used to clear the board.  Within minutes, and without being told, the students figured out what that button does and how/when to use it.

Here is a short minute video of them using it and answering questions about the game

I was unable to embed this video - so click here to view it on youtube.

After allowing them to play with it for less than ten minutes, we brought in two additional second graders. This time, we told the original two students to explain to the second group what to do.  Again the results were tremendous.

I was unable to embed this video into this post - so it is available at this link


The code specific to this project is available open source (click here).  From this link, head over to the downloads tab to grab a copy of the source code (in the format of .ino - The Arduino IDE's format)

As previously mentioned, this robot is controlled via an Arduino with an ATmega16U2 processor.  The  Arduino was programmed via the standard Arduino IDE (available for free here).  I used serval free public libraries, including Adafruit's LED Backpark Library, which was necessary in order to use the I2C Backpack chips on the 4-Digit 7-Segment Displays.

Future upgrades

  • data logging
  • more colors
  • sound
  • internet connectivity
  • water proof
  • multiply, divide


Andrew Rosenblum is a software and hardware enthusiast focusing primarily on iPhone/iPad apps.  Andrew is a senior at Cape Henry Collegiate School in Virginia Beach, Virginia, and will be attending Johns Hopkins University Engineering in the fall.

Friday, September 7, 2012

Sept. 4th - Sept 7th

Hello Again,

This week has been filled with work on my African Education Robot.  I spent Tuesday and Wednesday working on the paperwork associated with my submission (which is currently an unpublished blog post).  A couple of times I tried to put into practice some actual coding (although hardware coding without the hardware in front of you to test it on is a little bit boring becuase you can't test your code).

Thursday, I finally got to actually getting my hands dirty with some construction.  I did all the soldering for the 4-digit 7 segment displays (there are 3 of them), and I soldered leads onto one of the buttons!  Now that I have functioning displays to work with, I can start playing with the code for the robot and more effectively constructing it.

Friday I began working with the Arduino (the brains of the operation).  I connected the 4-digit, 7 segment displays to the Arduino, and ran some code to ensure they worked, and start to learn how to use them (I've never used 7 segment displays before - and I'm starting out with 12 of them!).  It worked first try, which is awesome.  I also loaded up some of the example sketches to get a feel for how these pieces of hardware work and communicate with the IDE.  The 4-digit 7 segment displays are so cool, and I was playing with some cool sample sketches which looked ridiculously awesome.  I also started working on my Arduino Sketch, getting a few basics in code.  The Arduino is a lower level C language, so I'm very familiar with how it works, but unused to the fact that it's a lower level language.  I much more used to higher level languages, so I had to do some research to figure out how to do primitive tasks, such as converting chars to ints.

After school I also came back for another hour and a half, and began laying out out the electronics in the case.  The case turned out to be much smaller in-person than I was expecting (I hope everything fits).

I spent the hour and a half drawing a few templates and using the nibbler tool to cut (mostly) straight edges.  It occurred to me I should file the edges straight and clean (a task for next week).  And that rounded out the week.

Thus far all goes well with my robot, and I'm making good progress as the deadline of September 15th fast approaches.

Anyway, thats all the rambling I have for now.



Tuesday, August 28, 2012

Hello World

Hello World!

My name is Andrew Rosenblum and I'm a high school Senior in Virginia.  This is my first post on my blog that will accompany me through my journey in Hardware & software engineering.  Throughout the year I will undertake a variety of projects encompassing mostly iOS and Arduino development.

My first project will be to enter the $10 African Robot Challenge, which will require me to build an education themed robot for approximately $10.  The idea stems from students in Africa who already use expensive lego robot kits.  These kits cost $280, which means most districts can only afford one kit., which must be shared among the various classes in multiple schools.  So in order to make technology more ubiquitous in African education, the challenge is to build a $10 robot.  For the prototype version I will build, I'm allowed a maximum budget of $100 (and from my planning I'm squeezing pennies under this limit).

I'm planning on building a simple math game/primitive Gameboy for use by younger children to learn simple arithmetic.  This game will follow the general idea of an iOS app I've already created called Math Player (from which I plan on stealing some of the code I've already written - Oh the power of C programming languages!).

This project will be my primary focus for the first few weeks of this class because the robot is due September 15th!

Once this project is completed, I have a slew of other ideas to explore, including

  • An update to the Cape Henry App
  • A unified database for Cape Henry to track Community Service
  • A stock Market Game App (to improve upon the Virginia Economic Education Council's website
  • A Chris Skinner App
  • An Arduino based Jeopardy style Game Controller
  • Explore the possibilities of Arduino/iOS connections (both wired and wireless)
  • An iOS/Arduino controlled car
This list is a great starting point as I go forward in this class.

I hope to keep this blog updated at least once every week.