Liam K.

Hi, my name is Liam! I am a rising senior at Regis High School, and this summer I took part in BlueStamp Engineering for the first time. My starter project was a portable USB charger, which I chose because I figured it would be a useful project. My intensive project was the line following spider. I chose this project because it would combine electrical engineering, which I had developed an interest in from high school physics, and coding, which I had never really done before but I wanted to learn.

Reflections

I learned a lot this summer at BlueStamp. I learned how to write code in Arduino and Python and learned general coding techniques like de-bugging and good code practices. I became better at circuit analysis, as I learned about components like diodes and transistors and how to apply them. The lesson on transistors, in fact, was one of my favorites: the mechanics of an NPN transistor, for example, which uses a potential from the base to emitter in order to allow more electrons across the depletion zone which previously had been saturated (in other words, a switch that is turned on by current), fascinated me.

The whole experience made me confident that I want to pursue a major in electrical engineering. I decided this not only because I loved working with circuits and writing code, but also because I was able to appreciate what it means to be an engineer. After finally perfecting my code for a program that let a user move a spider in a game on the computer and then would send serial data to my robot so that it would mimic the moves in the game and spraying down the robot’s motor and gears in order to reduce static friction, my Xbee, which sends serial data wirelessly, died on me. Upon hearing me curse my luck, one of my mentors, Mark, simply remarked, “Welcome to the field of engineering.” Setbacks were inevitably part of my time in the program. However, reflection, for me, was an incredibly important part of every step I took. Were I to start my project over again, I would do many things differently, especially in the mechanical construction, and I would likely be able to construct it more quickly. However, I look at my robot as a mark of all the progress I’ve made as an engineer, and I feel extremely confident and excited about the problems that I will face and solve in the future.

Last Video

My last video is a python program that lets a user move a spider around on the computer, stores their moves in a dictionary, converts those moves into a single serial message that the arduino on my robot is programmed to understand, and finally results in my robot mimicking the user’s moves. I relied on the pygame library in order to write most of the code, as it has a lot of cool functions that can detect key states and also display images. The program works by briefly explaining the directions to the user, then opening the game. The user then uses ‘w’ to move forward and ‘a’ to turn. Each key has a counter so the program knows how many times each key has been pressed. Every time the user presses a, the program checks the value of a variable called keyLast, which is assigned 1 after the user presses ‘w’ and 0 after the user presses ‘a’. If keyLast = 0, the program does nothing, but if keyLast = 1, the program stores each key’s counter in a dictionary and then resets both counters. The idea behind this is that I look at each move as x rotations and y steps forward. In other words, if the spider turns three times, takes two steps forward, turns once, then takes one step forward, I would store two moves in a dictionary like so: {0: (3, 2), 1: (1, 1)}. That way, I can easily send data to the robot that tells it that its first (or 0th) “move” should be to turn twice then take two steps forward, and its second (or 1st) move should be one turn then one step forward. I also added an input to the program that lets a user press ‘p’ and causes the spider to shoot out a red ‘fireball’. Unfortunately, my robot does not currenly have the ability to parallel that action.

The Python Code

Circuit Diagram:

.fzz of circuit diagram

Here is the bill of materials for the build:

– Arduino UNO  http://www.adafruit.com/products/50?gclid=CjkKEQjw_tOdBRDv9tuvl7eAtNEBEiQA9Qm5IpWy5sn_No-0xZE-Ce2dM_tQWSoMMweA17W-s5EflJjw_wcB

– Hexbug Spider http://www.hexbug.com/mechanical/spider/

– QR1113 IR Sensor (Analog) https://www.sparkfun.com/products/9453

– 9V Battery

– Wires

Build Plan:

1. Remove old microcontroller and replace with Arduino UNO

2. Test motors with Arduino UNO

3. Test 9V Battery power source

4. Attach IR analog sensor

5. Upload final code

Third Milestone

My third mile stone involved creating a few python programs in order to control the spider in a few different manners. I created a new arduino program which essentially looked for serial feed and responded accordingly. For example, if it received the byte ‘L’ in the serial feed, it would run the the line following mode loop. However, I also created python programs that would allow me to set a speed, direction, and distance for the spider to travel. I determined all of these by plotting several data points of velocity v. voltage and then creating a linear regression model that gave me a good approximation of the spider’s velocity for a given voltage. I also created a python program that lets me control the spider all the time with the keyboard and alter its speed with the arrow keys.

To make these programs more user friendly, I created an html interface which contained .exe links to the programs. However, for the .exe files to run, they have to be in a folder with other files, which meant I had to make the download a .zip. Though that is the way the interface currently works, I want to find a way to make the program launch straight from clicking the link, thereby making it more user friendly.

I faced a few problems along the way. First, my spider usually needed around 5V to overcome static friction (the passive resistance of one surface against another when both are at rest); this problem was exacerbated by the additional weight of the Xbee which lets the arduino send and receive serial data wirelessly with the computer. So, to give it a greater range of voltages, I connected the motor directly to the 9V battery and then put a transistor after the load that went into the arduino. That way, I could control the voltage across the load using the arduino, and I could go to higher voltages than if it were connected directly to the arduino.

However, even with this configuration, I could still only go to about 230 pulses per cycle without static friction preventing the spider’s movement. So, I altered the code such that before writing the analog voltage to the motor, I would write a high voltage to it for a tenth of a second to overcome static friction. This let me go down as low as about 180 pulses per cycle, thereby giving me greater range.

Python Program #1 (User Input)
Python Program #2 (Line Follow)
Python Program #3 (Keyboard Control)

And finally, here is the complementary arduino code

Second Milestone

My second mile stone was the completion of the main project, getting the spider to follow a path. After putting the components back into the new arduino board and testing the code I had written, I encountered new problems. The sensor was wobbling and moving around, causing it to move when it was not on the black line, and the spider would also rotate around and detect the line behind it, causing it to move backwards.

To get around these issues, I taped the sensor in place with a wooden cotton swab stick, a crude but mostly effective solution. Furthermore, I realized that following a black line was always going to lead to issues. This is because looking for a black, which reflects very little IR light, is looking for the lack of IR light, which would mean my spider would often move even when the sensor was not over a black line (for example, if the sensor bounced up and was too far from the ground to receive the threshold intensity of light). Instead, I reasoned, I should detect the presence of IR light; I facilitated this by switching the operand in my code so that the spider would following a wide path placed on a dark background. Furthermore, I changed the code so that the spider would rotate about 30 degrees at a time instead of rotating constantly which allowed it to sense more effectively. Finally, to avoid the spider spinning around and detecting the line behind it, I put an if statement in the code that checked the last state of the legs motor. If the legs had just been on (and not the rotate motor), then I told the spider to rotate about 220 degrees (not 180 because the path could be as wide as 3 or 4 cm).

First Milestone

My first mile stone involved getting the spider to walk on its own. Within a few days, I had removed the previous micro-controller, put in the arduino micro-controller, soldered the wires to it, uploaded code, put an external 9V battery on it, and had it walking around and spinning. After that, I started working on the sensor. After playing around with the pin connections and code for a while, I finally got the sensor to give me values that logically corresponded to the color of the surface beneath it. Everything seemed to be going excellently, and I was ready to write the final code and perhaps be done with the project.

However, nothing goes perfectly, and my spider was no exception. When I uploaded the final code, I found that the spider was not responding at all. I began de-bugging the code, checking the sensor, the motors, everything, until I finally concluded that the problem was with the chip. This was corroborated by an error message that the arduino software started to give me. My instructors and I determined that I likely did damage to the board or microcontroller by soldering on or near the board.

I had to get a new arduino board, and I treated it far more carefully this time, conscious of everything that I was doing. Through a few hours work, I was able to put the board back on the spider, put the motor and battery wires back into the pins, and get the spider walking with code. So, two steps forward and one step back, but at least along the way I have learned to be far more cautious with delicate components. Next up, the goal is to get the sensor working and have the spider following a path.

This is the code I wrote for the line following spider

Starter Project

My starter project was the minty boost USB charger. It uses batteries to charge a phone. The voltage source, as noted, is two 1.5 V double A batteries which have connections soldered to a circuit board which has several components. There are resistors which are used to decrease voltage to make sure certain components don’t receive too much. There are capacitors which store charge and are used to make sure there is a steady current in the circuit. Also, there is a diode which uses electric fields to ensure that current only travels in one direction; if it were allowed to travel in the other direction, the current could do damage to some of the components in the circuit. The chip and the inductor are used to convert the DC voltage to 5V, the correct voltage for USB.

Constructing the minty boost USB charger was lots of fun. I learned how to solder and desolder. I learned about some of the components and their uses such as the diode and the chip. Furthermore, I learned that DC voltages can be increased or decreased, which is something I didn’t know. Though much of the construction was simply following directions, I made sure that I understood what each component was and how it would affect the circuit. The intensive project, however, will likely require a bit more innovation.