Hands on Learning

2.007: A Carnival Journey

stevenjens — Tue, 15 May 2012 00:31:00 -0400

And here’s my completed 2.007 Robot minutes before I sent it off to impound.

But how did it came to be!? I’ll try my best to recount the events of designing and what went through my head…

The 2.007 game this year is carnival themed.

Here is MIT’s article this year http://web.mit.edu/newsoffice/2012/2007-robotics-competition-0511.html

I’ve always done robotics competition with a group or at least with another person. This is the first time I’ll be designing, manufacturing and assembling the entire robot.

Tasks include: pressing a button to grab a ticket, blowing up a balloon, hitting the high striker and spinning the ferris wheel.

Here’s the point distribution:

Pressing+Grabbing ticket: 1pt for every ticket

Blowing up a balloon: 2pts/Liter

HighStriker - Max of 25pts for ringing the bell. Otherwise it is 10pts, 5ts, 3pts or 1 pt depending on where the slug ends.

Ferris Wheel- Score multiplier. (Max of x3 to current score. Depending on net angular displacement)

Finally, there’s a 30 second autonomous period where any points you earn in this period is bonus excluding the multiplier.

…

As a veteran in robotics competitions, I immediately knew that I will be aiming for the most yield in points as well as do the multiplier. Naturally, I selected the High Striker and the Ferris Wheel tasks.

To approach the high striker problem, I wanted to keep it as simple as possible. I thought doing a vertical hammer for the challenge was probably the simplest way to do the task.

I didn’t know how my robot would look like, and I wanted to keep the option of doing other tasks a possibility. So I wanted to save space as much as possible. A vertical hammer conserves space in the x-y plane in exchange for occupying the z-plane primarily.

It seems I’ve been out of touch with CAD during the beginning of the semester because I could not create anything substantially interesting, creative, or something that looks like it can do the task.

This was version 1 of the Pile Driver:

I thought that I didn’t really have to use strings, so maybe I can just use a 4-bar linkage instead?

I tried making this in lab with just calipers and a drill press. I didn’t get to take a picture of it because I was trying to get back into manufacturing mode. It’s been almost a year since I last used a drill press. >.<

To say the least, version 1.0 was a complete failure. The vertical displacement of the arm doesn’t even go that high! Plus, if I were to make the arm longer, I will be occupying more space than needed. If I did try to go for this design, I will be occupying space in all 3 directions. My complete reason for doing a vertical hammer will be trashed.

I felt very rusty. So I tried to attempt the problem again.

This was version 2.0

I still felt rusty with my CAD, and I couldn’t understand why I couldn’t design anything properly. I wasn’t happy with version 2.0 either. The structure is blocky with weak structural supports. It’s like all my engineering experiences have suddenly disappeared in the first few weeks of the class. wtf right?

It’s better, but it could be so much more… I just didn’t know what I was lacking. Anyway, it’s about 5 weeks into the class already and my progress has been extremely slow. I needed to have something built by the next lab section. Being sick, loaded with other classes, and “losing” my CAD ability left no time for me to change this design for the class’s milestone. So I just had to build it for the next meeting, get a grade and just scrap it when I have time.

There. I built it half-willingly. The structural supports aren’t even there. There were so many problems with this build that I wanted to scrap it as soon as it came to be. Don’t get me wrong, the sliders worked fine… but I approached the problem incorrectly.

Instead of building the structures before the sliders, I built the sliders and tried to constraint the structure. BAD MOVE. There was no way to salvage this build. Since I’m scrapping it anyway, I might as well just trash the design.

So… on to version 3.0.

What now? I had 2 tries so far and they’ve failed miserably to my own expectations. It was difficult to desire high precision holes and work with band saws and drill presses. Robotics needs precision and unless I only use the lathes, mills, the waterjet or a 3D printer, I’ll have a hard time gaining the precision that I want.

I thought to myself that maybe I should just stick to designing everything in CAD. And for that matter, maybe I should just stick to a standerdized way of building things…

What better reason is there to abuse the water jet machine?

So Version 3.0 had that in mind…. But again, my CADding ability is still not with me.

Here’s what version 3.0 looked like:

Where is my CAD MOJO!?? As I made version 3.0, I realized I was using almost all of my aluminum sheets. This is not desirable if I want to create the rest of my robot with the abrasive water jet.

Again, I did not like my 3rd design iteration. But I wasn’t going to give up. I was increasingly getting frustrated because it’s already spring break, and I don’t have anything useful….

And then i tried to do it for the 4th time:

I thought I hit the jackpot. The design resonated with me, and I felt very confident about it. I got my CAD Mojo back.

The design combined both abrasive water jetting and square stock machining. The water jet pieces were primarily there to accurately space critical dimensions.

The first half of spring break was making this 4th design iteration. Now that spring break is half done, I needed to start manufacturing.

It was a lot easier to manufacture things when you know exactly what you need to build:

Instead of waiting for 2.007’s system for waterjetting, I decided to just make it my own and used MIT’s hobby shop water jet machine.

I then plotted the holes on the square stocks very carefully and assembled the main pile driver structure.

Assembly was a huge pain… But in almost no time, i managed to finish the primary structure of the pile driver.

I had a lot of problems with tolerances, as I seem to always miss a few thousandths with the water jet… Particularly this unique triangular bracket:

This holds the pile driver tower up and I had a lot of issues when I forced myself to make the slots fit in and work. Vincent Kee told me that it doesn’t seem as strong as a regular L-bracket… Vincent was right and I would soon be proven wrong (much later into the semester).

For now, I went ahead and finished other stuff:

This was the hammer with a rubber end. The carrier is an aluminum square stock. Again, I waterjet an aluminum piece to connect them together. It was completely unnecessary to use the waterjet like that I know, but you know what? I might as well since I’m on the machine anyway.

Now that my hammer was up, I also needed to make the gearbox that will physically pull up the hammer:

It’s a 9:1 gear reduction. (bBig Gears are 36 tooth and small gears are 12 tooth).

The white cylinder at the left end is a pulley. The idea is that the hammer is reloadable. BUT HOW? There’s a gapped tooth on the 36tooth gear connected to the 12 tooth output. When the output spins to a gapped tooth, the final output shaft free spins as the hammers tries to pull it down.

As for the shafts, they are a combination of hex axles with .25in diameter ends

Anyway… After much turning with the lathe, here’s version 1.0 of the gearbox:

I think I did not account for the material properly because I had to use washers on top of the stand offs that I turned down… but there’s no point in changing this now since time was winding down.

Ok…. so I have part of the pile driver built, part of the gearbox built, now I need to start designing the drive base…

I’m very behind in the class… but I’m betting/hopping that my ridiculous amount of time spent on CADding will be paid off.

Here’s version 1.0 of the drive system:

It was a rough sketch with no screws, but I didn’t like how I had to create more gearboxes to make the drive system work… So I needed to revamp it.

Here’s version 2.0 of the drive:

I removed the gearbox and made it a 1:1 gear ratio. It has a very low drive base so that I can maximize my 12”vertical limitation.

A closer look at the 1:1 direct drive module:

A hex axle connects with the wheel. The wheel connects to the servo arm. The hex axle has a 0.25in shaft diameter to support the wheel on both sides.

I really dislike working in a machine shop without have any idea what to do. But now that my robot is slowly coming together in the CAD, I knew exactly what tools to use to make the drive system relatively quickly.

Back to waterjetting:

And here are the awesome waterjet pieces:

The ABS plastic makes a great stand off. I was getting really tired of making my own stand offs with an aluminum axle, so this was a nice change.

Assembly for the drive modules didn’t take long either:

Alright. Now that I have my modules together, I can finally assemble them all into a robot:

First…. I cannot tell you how painful it was to assemble the robot. There were way too many sharp edges that I should have fillet or filed. I should have really thought about designing for assembly. I think you just get into CADding so much that you forget that your fingers have to go in there somewhere to put the parts physically together.

Now that my 2.007 project is actualky starting to look like a robot… I couldn’t wait to try the hammer!

I really should have done testing much much earlier than doing it now… And only now do I realize how naive of me to not even do any testing..

So what happened? Remember that my output gear was a 12tooth? After 2 tries with the hammer, the piece was destroyed because it didn’t have any structural strength.

Also… I realize that I didn’t really support my input gear… After a days worth of machining I have a new gearbox:

Now that looks much much better…

I tested it once, and it worked… Although I don’t know if it can achieve the maximum 25 points that I’m aiming for. I figured that because my design is tunable, in that you can change the number of springs and the ending position of the hammer, I should be able to find the right configuration that will hit the high striker.

But I needed to start designing my ferris wheel mechanism. I really need to make sure that I get it right the first time so again I’m relying on Solidworks to do my “theoretical testing”

Here’s my ferris wheel arm attempting to spin the ferris wheel.

I was satisfied with how it was working on CAD.

Since I was really getting back into CADDing very quickly with satisfactory results, I did this tower in one try:

It’s a mechanism attached to a ratcheted four bar linkage. The spinning mechanism also had its own ratchet.

Here’s a close lookup of the ratchet deisgn:

CAD works. <3.

Finally… I have a 100% complete CAD of the robot:

All that is left is to finish manufacturing everything…

I went back to water jetting, and because I had a lot to do, I completely forgot to take pictures… sorry. But… I do have this:

I spent so much time on the water jet that my accumulated minutes was ~112 minutes. Woah. That’s around $224.00 or $336 if the department funds it… Thankfully they said they will fund it. PHEW.

Alright… Then I had to make a bunch more stand offs for the ferris wheel mechanism

It really did take a long time to finish. And this is not even all of it. I also had to turn down the spacers and remake them because of measurement errors

I now have reached the point where I am completely done machining the robot.

I did the finishing touches on the drive base by connecting the timing belt threads:

The Ferris wheel tower goes up:

Assembled the ferris wheel spinner:

I wasn’t done just yet… I still needed to make the VS-11 Servos continuous so I quickly took them apart and removed the mechanical tab which prevented it from spinning 360degrees.

And you just take this gear and remove the mechanical tab:

NOW…. all the hardware is done. There’s 2 days left before impound and I was thinking I could pull it off.

Assembly again was a real pain… but after much work it’s finally together completely:

Ahh yes… Finally… I quickly wired everything, and programmed it. I have much experience with servos and motor drivers that it wasn’t really a challenge to put them together.

Also, we were using a PS2x controller so programming was really easy for me since I did that for my UROP last summer when we worked with making the omnidrive robot.

For final touches, I labeled the robot ”Orthanc and Barad-dur” in spirit of FIRST robotics and labeling your robot as well as in spirit of Lord of the rings and the two towers. =D

The MIT Copy Tech is a great place to get laminated labels. :]

By impound time, my robot was drivable and could do the tasks that I wanted… However, it wasn’t do them so well. I only scored 1 pt during seeding cause I thought the hammer wasn’t working.

Results:

So how was the competition? It definitely gave me the robotics competition feeling to say the least.

Just like FIRST, there’s a place where the robot resides:

The competition floor is captivating and beautiful:

And finally, the people in it make it super fun and amazing!

(The guy on the far left wearing an orange shirt is professor sungbae kim. He’s one of the leading roboticist in the world. The cheetah robot and stickybot for example).

…

During the competition I was eliminated on the first round after I scored 5 pts. I wasn’t paying attention to the competition so I misfired my hammer twice. By my 3rd try, there was no time left to do the multiplier. Oh well…

I took the class with an arrogant attitude and that definitely back fired. I couldn’t even CAD for the first 2/3’s of the semester for some reason… Was I too sick? Or maybe I was really burned out from IAP for working 18 hours a day? I wasn’t sure… But 2.007 definitely was a big learning experience surprisingly.

Also, I’m glad I got beaten out completely. If MIT’s 2.007’s best student is me, then the world is in trouble because I have much to learn.

You can watch the full competition here:

http://amps-web.amps.ms.mit.edu/public/courses/2/2.007/2011-2012/finals/

I am just glad that my robot turned out exactly as how I wanted, it could be better, but it is what I designed:

2011: 6.270 Robot

stevenjens — Mon, 14 May 2012 18:36:00 -0400

Since I’m trying to make an online portfolio of things I’ve made, I might as well preserve my team’s 6.270 robot from the 2011 competition.

My teammates, Matt Times and Naomi Schurr have done most of the writing below. My only contribution was the programming and strategy sections.

The Robot: Pac-Man

The winning robot of the 2011 6.270 competition!

Quick Specs:
   2-Wheel Tank Drive w/ 125:1 Gear Ratio
   Motor Driven Intake Roller w/ 125:1 Gear Ratio
  Continuous-Servo Driven Chain Lift w/ 1:1 Gear Ratio

Below the Cardboard

Overview of system: Rollers in front draw tennis balls onto tray.

Elevator system in back lifts entire tray to rift height. Rollers reverse to score balls.

Starting Position

Roller Arm begins vertically to meet starting size restrictions. Motion of robot as match begins causes roller arm to fall to collection height.

Tray Specs

Sensors: Tray has two photogate sensors to ascertain possession of a ball.

Gray and black plates on green surface are angled slightly, preventing tennis balls from getting trapped at the back of the tray.

Cutouts from side of tray allow casters to rotate freely without interference.

Black axle with gray collars serves as hard mechanical stop for roller arm.

Yellow and red vertical beams guard against tennis ball loss on sides.

Roller Arm and Tray Mount

Bound three-gear system used to attach carriage to chain.

Black axle in center allows for rotation of roller arm.

Roller arm is currently in position, resting on hard-stop.

Continuous servo motor drives chain on 1:1 ratio.

(Notes: Despite various mounting methods and gear ratios, the regular motor was unable to raise the lift. The continuous servo provides the necessary torque, but requires additional programming, as the stop value tends to drift.)

Rollers

Because the rollers span the front of the robot, relatively little precision is needed to collect tennis balls, simplifying programming.

(Notes: The Roller Arm was orignally mounted lower, such that golf balls would also be taken in. Theoretically, the Roller Arm would pivot up when encountering a tennis ball to accommodate its larger size. This generally worked, but sometimes the torque required to bring in a tennis ball at the low height was too great for the motor. In the current iteration, the Roller Arm sits at a height that is incompatible with golf balls, but optimal for tennis balls.)

Roller Gearbox

Gear ratio is 125:1. Motors are very fast, and torque is needed more than speed to intake tennis balls.
(Notes: When the rollers contacted a wall, they would start to roll the entire lift arm up the wall, releasing tennis balls. After the failure of various front guards, the motor speed of the roller was reduced to correct this issue.)

Tray Height Control

Sensors: 2 Limit switches to bound the maximum height the tray can go and the minimum height it should go.
Limit switch at top of lift’s travel allows lift to be held at rift height.
Another limit switch at the bottom of the lift’s travel allows the tray to be stopped at ground level.

Tank Drive

Two independently driven wheels, gear ratio 125:1, large wheels. A higher drive gear ratio provides more than enough torque to move the robot. To compensate for RPM lost in the motor, the size of the wheel was maximized to give the greatest possible speed for a given torque.

Caster

Two casters support front of robot.

(Notes: Casters have a relatively large footprint, but the two in combination gave the support needed for a heavy front.)

Electronics

Happy Board and Battery provide weight in back of robot to counteract heavy Roller Arm.

Lower Limit Switch and gyro are also visible.

Encoder

The encoder is mounted on the bottom of the robot at the center of rotation to measure the forward distance traveled by the robot.

Programming

The robot was programmed under C with built in joyos libraries to give compatibility with the Happy Board microprocessors.
Overview of Code Structure:
   The code runs on 3 main threads: umain, navigation_loop, articulation_loop
   umain: Sent high-level commands such as MoveToPoint(x, y, speed), TurnToPoint(x, y, tolerance), MoveStraight(x,y, speed), and DeliverBalls(). Each function takes in the given arguments, and simply passes the values to the other threads using global variable assignment. For example, TurnToPoint(x, y, tolerance) takes in the arguments x and y, calculates the theta and puts this value in a global variable called desired_theta. The global variable can then be accessed by other threads such as the navigation_loop or the articulation_loop, and each separate threads can act accordingly.
   navigation_loop: This thread runs in the background and simply acts on any value passed by umain. Going back from the previous example, once desired_theta gets a new value from the inputs in umain, the navigation_loop gets updated and will move accordingly until the desired state is achieved. (In this case, turning to a point). Once the state is achieved, the navigation_loop will stay put doing nothing until umain tells it to do something else. The advantage of tjis multi-threading programming is that while the navigation_loop acts on the background, umain can freely do other things such as planning the next moves, tracking the movement of the targets, etc.
articulation_loop: Like the navigation_loop, this thread acts on the background and waits for any command from umain. For example, if umain calls a function StartIntakeRollers(), the articulation_loop will change its state and run the intake rollers until umain tells it otherwise. Likewise, if umain calls LiftTray(), this thread will lift the tray until it reaches a desired state usually indicated by a sensor a timer, or umain. In the same way, placing the articulation_loop in a different thread gives umain more flexibility.
Navigating the Playing Field:
   PID controllers: Since the robot uses a 2 wheel tank drive system, the robot doesn’t necessarily drive straight even if they get provided the same output. For example, setting both motors at a value of 150 will cause the robot to drift at an angle over time. This is usually caused by the slight differences between the two motors. To fix this problem, a Proportional, Integral, and Derivative (PID) controller is used. In this robot, a gyroscope is used to indicate the current heading of the robot. Using the gyroscope, we can make the robot go relatively straight at the correct heading. The PID controller provides the proper correction amount to each side of the motor and tries to minimize the error to 0 thereby retaining a constant heading. Since the motors get the proper correction amount, the robot moves relatively straight towards the desired heading.
   Localization: To get somewhere, you need to know where you are first. In previous years, navigation was done by dead-reckoning. In essence, if you know how far you’ve gone and in what angle, you know your x and y coordinates using simple trigonometry where x = cos(theta) and y = sin(theta). This year, we have found that the Vision Positioning System (VPS) overhead gives a precise location of our robot with little to negligible latency.
   Navigation: Now that the robot’s position is localized, the robot can now move to specified points in the playing field. Our robot has one primary function for moving around and it’s called MoveToPoint(x, y, speed, tolerance). MoveToPoint actually breaks down into TurnToPoint(x, y, tolerance) and MoveStraight(x, y, speed). For example, if the robot is currently localized at pt (0,0) and I want it to move to pt (2, 2), the robot will 1st: Calculate the heading using the given x and y points which is 45 degrees. 2nd: The robot will turn to the point (which is basically turning to the pointed heading). by rotating each wheel opposite of each other 3rd: The robot calculates its distance from the point, and finds out that it needs to travel 2*sqrt(2). 4th The robot will then MoveStraight(2, 2, speed). Using the encoders, the robot will know how far it needs to go. The encoders record how much the wheels have spun. Using a conversion factor, the encoders can tell the robot if it has gone a distance of 2*sqrt(2). If it has, then the robot will stop moving. If we localized the position again, the robot should be at pt (2,2) at a heading of 45 degrees.

Using a simple TurnToPoint then MoveStraight to point function, the robot gets to where it needs to be. Granted, this worked for this competition because collision between the opponent and your robot was impossible. Which means that so long as the robot is not hitting anything, it can move to a desired point without fail.

Finding Proper Ball Targets:
Before the robot moves to a certain target, it needs to know which are tennis balls and which are golf balls. In the beginning before making any commands, the robot has a SortBalls function. It takes all the objects in the field and figures out which are tennis balls and golf balls based on the radius of the ball. It then checks if it has the same sign as our y coordinate. If it has, then that ball is in our field and its ID is stored into a new array. A list of balls in our side of the field is then generated. The robot then runs a for loop program which figures out which is the closest ball using the distance formula. The ID of the closest ball is then given and it takes it back to the original list of objects in the field. It’s x and y is calculated at that instantaneous moment, and the robot will move using the MoveToPoint function.

The ball may move, but this is negligible. If the robot misses the point, the robot will repeat its SortBalls function and this entire process and go to the new point specified. In addition, tennis balls have more friction and take quite an effort to move. From mock-competitions, the tennis balls hardly moves at all unless its hit by your robot. So in essence, taking its instantaneous x and y point is a good approximation of its location.

Capturing the Balls:
To capture the balls, the robot has its intake motors always ON in a direction which forces any tennis ball to go in and not out. More often than not, tennis balls get in by luck and the robot gets a free tennis ball even without having to navigate to a certain point in the field.

Delivering the Balls:
Likewise, to deliver the balls, the intake motors have to spin the opposite way forcing the balls to go out.

Ball Detection:
There are two breakbeam sensors inside the tray. If either of them gets broken, the robot will realize it has a tennis ball and will immediately deliver the ball. We realize that this is an inefficient method, and a better way to have done this is to try to capture at least 2 balls before delivering the balls.

TimeOuts:
One of the most important part of the robot’s code is a timeout. This is a code which prevents your robot from doing the same exact thing over and over again without producing results. For example, if your robot wants to turn to a certain point, but is wedged in a corner, the robot will forever try to turn and will never get to its point. This causes motors to burn out and die. In our robot, we have 2 simple timeouts. Our robot’s timeout occurs on either TurnToPoint or MoveToPoint.
   TurnToPoint timeout: For turning to point, we gave the robot 3 seconds to turn. If it doesn’t turn within 3 seconds, then it has to move back.
   MoveStraight timeout: For moving straight to a point, we used our encoders as our timeout. In essence, if the robot’s state is moving forward but its encoder value is still 0, an internal timer will start ticking. If the timer goes on for x miliseconds (in this case it was 700), the robot needs to back up.

Other Safety Timeout Prevention Features: 1. The robot will only lift the tray if it’s a certain distance away from the wall. 2. After delivering the balls, the tray needs to lower. Lowering the tray can cause problems because if it lowers on top of a ball, then it will get stuck. To prevent a tray from lowering into a ball, after the robot delivers the balls, the robot backs up, turns a complete 180 degrees pushing all the balls away and then lowers the tray. 3. If a target x and y position is beyond a certain x or y value, the robot will go to a maximum value where it knows it can’t get stuck.

Game Strategy

A preprogrammed routine runs in the beginning: Using the VPS, we tell the robot to deliver the first 4 golf balls. Then, the robot turns on its intake rollers. The robot proceeds to a specified point which automatically gathers 2 tennis balls. The robot checks if it has any tennis balls, and proceeds to deliver them. After this pre-programmed routine, our team has already scored 10pts in the first 20 seconds.
Programmed AI: Robot sorts all of the balls in its field and figures out which is a tennis ball. The robot turns on its intake rollers and moves to the x and y of the ball. The robot checks if it has anything on the tray. If it does, then proceed to deliver. If not, then repeat the programmed routine.
In the event that the there are no more tennis balls on the side of the field or the robot can’t get to a certain tennis balls, the robot proceeds to sorting and targeting golf balls.
Since this doesn’t really happen in the game as there are always tennis balls in the field, the robot usually focuses on the tennis balls. This is the integral part of the strategy. For the most part, the robot ignores all golf balls and concentrates on the tennis balls.

Doing a simple math, this makes sense. Each team starts with 4 tennis balls and 8 golf balls. Your opponent can only score a maximum of 8 golf balls equaling to 8pts. Which means that in order to win, you need at least to deliver 3 tennis balls which equals to 9pts. Delivering 3 tennis balls is the same thing as saying that there should only be 1 tennis ball in your side of the field at the end of the game. If there’s only 1 tennis ball in the field, then your team automatically wins. For every 3 golf balls that you score, you can afford 1 extra tennis ball on your side of the field.

In our case, we already score 4 golfballs in the beginning. We can then afford 2 tennis balls on our side. But since our preprogrammed routine scores 2 tennis balls in the first 20 seconds, we’ve already secured an advantage since we only have 2 tennis balls on our side.

The strategy then boils down to this: At the end of the game: If you have 1 tennis ball in your field. You win. If you have 2 tennis balls and scored 3 golf balls, you win. If you have 3 tennis balls and scored 6 golf balls, you win.

Who's Steven?

Sat, 28 Jan 2012 13:52:23 -0500

The author of this page. ;-]

Time to start updating this blog… The the week before IAP...

stevenjens — Sat, 28 Jan 2012 11:23:00 -0500

Time to start updating this blog…

The the week before IAP started, I spent a good amount of time in lab writing a detailed guide on how to use 6.270’s “happy board” with motors and sensors. There were online course notes which introduced students about how sensors and motors would work, but not really how to use them using the specific board and the exact programming routine.

The guide was made due to my and my friend’s frustrations last year about using happy-board and trying to interface with it. Last year, teams were still calibrating gyros and testing sensors near the 3rd week of 6.270… It meant that no one was really doing productive programming. Instead, everyone was stuck just trying to figure out how to operate the damn thing.

Anyway, this motivated me to make the guide to make life easier for this year’s contestants. I really think it helped. I wrote the document in my own voice… I think you can even hear it when you read through it. =]

Before the start of the 1st mock competition (students had to drive to specified points in the field) 15 out of 24 teams were scoring above 20 points. This was a great increase from last year’s 4 out of 29 teams performance last year. Teams actually got to do useful navigation program. I was very satisfied & happy to see the students see their programs work (after multiple tests =] ).

Happylab can always be improved, but I’m glad that the platform is set for future teams.

The PDF document is available for download here

6.270 Happy Lab and Other IAP Plans

stevenjens — Fri, 23 Dec 2011 12:49:52 -0500

tl;dr: Learn LaTex, Build Scooter, Work for Vishwa, build other sh*t, post old stuff

Yes! Finally the winter break!!

I have time to work on my projects now. How glorious! Until January 4th, I will be under the comforts of my family in California. So the only thing I can do is really just prepare for the IAP.

Which means Programming! and lots of CAD! and Budgeting! ahh.. I’m so excited for this IAP.

Alright. First off, it is essential to learn how to use LaTeX.

In essence, it’s an awesome word-processor used by researchers, professors and ambitious students. XD Really though, almost every report published is written in LaTeX. It’s far far superior than Word (Or so I have heard). Anyway, the best way to find out is to just use it and see for myself.

#1 on my list is to finish Happy Lab for 6.270. And I think typing it in LaTex would be great practice.

#2 Aside from learning LaTex, I really want to build my own electric scooter. Recently, it’s getting more common for MIT students to build their own because it teaches you a lot of things from MechE, EE, and CompSci. It should be a good learning experience! And since I’ll be at home from Dec 22nd to Jan 4th, I can really utilize this time to just design the CAD and plan the electronics needed.

#3 MATLAB! I’m going to be taking a class this coming IAP. MatLab is heavily used by engineers to do intensive calculations. Engineers don’t have time to do algebra. XD

#4 I got hired by Viswa robotics around late October, but I really haven’t been doing much for them. School was extremely busy so all my energy was focused on doing well on academics. Although, I did calculations on my own time, I never did submit them… So I need to work pretty much full-time for them this IAP if they even decide to take me back.

#5 Build Other Sh*t. Yes. I have lots of things lined up to increase my knowledge base beyond theory.

#6 Post old stuff to this blog. I’ve built lots of things before so I should really just upload all of them here. Also, I’m really thinking whether or not tumblr is a good place to host my build blog. A lot of people in MIT are using wordpress. We’ll see.

Anyway, this should be a good IAP for learning. Let’s go!

Syren 25Amp Speed Controller Wiring Currently creating a...

stevenjens — Wed, 31 Aug 2011 14:50:26 -0400

Syren 25Amp Speed Controller Wiring

Currently creating a detailed build report of the OmniDrive. This is an excerpt which details exactly how the speed controller should be properly wired.

Lab planning progress update.

stevenjens — Tue, 23 Aug 2011 10:10:06 -0400

Last week, I met up with one of the MIT staff, Steve Banzaert, who handles a lot of the edgerton center and lab spaces in the campus.

It was definitely an eye-opener because he addressed issues I hadn’t thought about.

One of the things mentioned again was that money and equipment wasn’t the problem. However, instead of effort being in the way, it was logistics, politics, ownership, management and safety.

It turns out, every 2 years or so, a few people from dormitories, fraternities and other living groups come out and propose a laboratory space. So it’s not uncommon that he’s meeting up with me to talk about this kind of idea. haha.

Anyway, he said that most fail because of the planning stages. After reviewing the proposal draft I had, he quickly addressed these issues:

Constitutional Space: Who owns it? Is it a commercial space or an academic space?

Insurance Policy: Depending on the ownership, there are liability issues that needs to be addressed. If it’s MIT, then they have their own protocol. If it’s a commercial or private owned, a 3rd party insurance company needs to get involved.

Other Important Logistics:

How is access granted?
Who manages this place? Is there only a single person in charge?
How is this going to be maintained? Long term is the goal here but once the person managing it graduates, somebody needs to take over.
What are the safety protocols?
What is the sustainability plan?

If you notice, there is nothing mentioning money at all. It’s all politics, liability, safety, and management. The Yale accident recently doesn’t help either.

Anyway, the next step is to talk to the EHS (Environmental Health and Safety) in MIT. I also need to meet up with the alumni board again and report about the progress.

But before I meet up, I need to make a compilation of tools, materials, and safety protocols attached with it.

OmniDrive Completed: Speed Assembly above The video shows a 16x...

stevenjens — Fri, 19 Aug 2011 20:44:56 -0400

OmniDrive Completed: Speed Assembly above

The video shows a 16x Speed Assembly of almost the entire thing. The bloggie battery kept on dying after being on for 3 hours at a time. I did manage to capture some key moments, but otherwise, it does give a general view of how the robot was assembled.

The past 2 weeks have been pretty crazy to say the least. When the parts came in, we started building as fast as possible, and the first run through was completed by Friday of last week. The sample video can be seen here:

As for specific engineering & construction notes, I’ll start from where I left off last time.

Assembling and Wiring

After building the main chassis frame, it was time to mount the electronics and the motors.

Because the wormgearbox motor has a lot of torque, it’s very common to use a direct drive. In many cases, this simplifies design and construction a lot.

The best way to show how we mounted the wheels to the motor is using the exploded view from SolidWorks:

Spacer and a 1/4-20 Screw keeps the omni-wheel place. The NPC motor happens to have a 1/4-20 tap hole at the center of the shaft, so this was pretty convenient.

The spacers on the other hand wasn’t so convenient. If you’ve cut spacers before using a hack saw or band saw, you’d know that it’s never accurate. On a plus note, it was a bit idiotic for me to purchase spacers that had an EXACT 0.5in Inside Diameter (ID) delrin tube.

We had to cut the delrin to simulate a C-Clamp, and pretty much force it to work. On the plus side, this gave room to the key of motor so that both wheel and shaft turn in sync.

After doing one successfully, we just repeated this pain/reward cycle 3 more times:

(guess what the mallet did there? Yup. Forced the ~0.5in ID Delrin to the ~0.5in OD shaft).

After the wheel and motor module was assembled, it’s really a matter of putting it all together.

The electronics was also straightforward. I’ll give a paint drawing of the schematics, but really it’s just:

12V Battery -> Motor Controllers - > Motor.

The 12V battery also powers the Arduino using the female VIN pin header on the board. The arduino has a 5V voltage regulator that can handle around 20V of battery input.

Here’s an attempt to demonstrate the wiring through paint:

Anything multiplied by 4x tends to look more complicated than necessary.

Look at the wiring though:

Messy Christmas lights. (If you have a keen eye, you’ll notice there aren’t any VICTOR 883 speed controllers. I’ve explained this below).

Addressing Other Issues

Primarily, there are 2 issues with the design. One was addressed properly without much change, but the other is a bit more difficult.

High PWM Frequency - If you notice during the video testing, the motor has a very loud whining sound. Initially, we tried changing the PWM frequency sent by the arduino using this PWM Library.

This led to unfruitful results. I spent a lot of time trying to figure out why changing the arduino frequency doesn’t do anything. When I contacted Shane from MITers, he said that the VICTOR 883 Speed Controllers will receive the standard RC signal from the Arduino, and the VICTOR will use its own 100Hz frequency.

He suggested to change to a different speed controller.

Here’s a cool fact. The human hearing range is from 20Hz - 20kHz. All you have to do is put the PWM frequency in the » 20kHz range and humans won’t hear it anymore. It’s still there. You just don’t hear it. Cool huh?

I ended up just following Shane’s recommendation and asked my supervisor to buy Four of these:

It’s a Syren 25A Regenerative Motor Controller. EXTREMELY EXPENSIVE! In essence, it acts the same as a VICTOR controller but its transistors switch at a rate of 32kHz. 12,000Hz above the range of human hearing, so there’s no way you would be able to hear the PWM frequency.

That did just the trick!

I have another video of us testing the new motor controllers, but I’ll save that for another post.

Addressing Traction/Slipping: If you watch the test run video again, the wheels slip whenever only 2 of the wheels are only functioning. The quick easy fix is to always maneuver using four wheels. But there are some movements where you just want to use 2 of the wheels…

This would’ve been easily solved using a suspension system. This would’ve been a bit more complicated and a bit more expensive. My previous design had it, but it did seem overkill and I believe $1000.00 more expensive.

In any case, I’ve been thinking about how to add a spring system to what we have now, and after a week of doing the problem, there’s no easy solution unless I create a new motor module.

So how do you attain traction at all times without using suspensions? There’s another design that we’ve been thinking of doing. Instead of using 4 omni-wheels, we would just use 3.

This is the tri-omni design:

We would’ve built it this week, but unfortunately the water jet wasn’t really available. In addition, I hate dismantling a successful, functioning robot to create an unsure robot.

There’s a few issue with the tri-omni design. The Center of Gravity is the most obvious one.

As for controls, it’s a simple linear algebra problem where you only use 2 of the vectors and make the 3rd vector dependent on it.

Anyway, We ended up not building this design, but maybe future UROPs can try this out. I’ve already figure out the wiring, programming, and mechanical design so all that is needed is manufacturing and assembly.

Other Traction Solutions:

I weigh 140lbs. When I rode the robot, it had a bit more traction than usual, but it’s not that great. Putting weight on the robot obviously increases your dynamic friction but it really won’t help unless the floor is even.

So how did we solve the traction problem? We didn’t. It’s sad that it has this critical flaw when it was first addressed from the very beginning of the design stage.

Other Aesthetic Development:

We proceeded to make the robot look more presentable.

Look, Black acrylic sheets:

And look how awesome it is when we mounted it:

I think I’ve addressed all of the assembly, wiring, and how we addressed all other issues.

Also, here’s a quick summary:

TL;DR: Robot is finished. Awesome Speed Assembly Video. Awesome Robot Testing. Assembled the Wheels. Demonstrated Wiring. Changed Speed Controller to Syren for quietness. Didn’t address traction. Covered the bot with black acrylic for style.

Machining + Assembly. The deadline of this project is next week....

stevenjens — Thu, 11 Aug 2011 22:20:00 -0400

Machining + Assembly.

The deadline of this project is next week. The progress thus far? Way ahead of schedule. ;]

There’s been a lot of progress in terms of machining and assembly, and it just got better when all of the parts came in yesterday.

In order for the robot to be built, I had this mental task list:

1. LaserCut Acrylic Electronics Base

2. WaterJet Motor Brackets

3. Cut 80-20’s in the Bandsaw.

4. Purchase all accessories from McMaster

5. Assemble and Wire Electronics

Here’s what happened this past week.

Monday 8/8/11

Turns out, there was a bunch of 80-20 parts downstairs in the basement. Upon acquiring them, my coworker and I marked them, and went straight down to the machine shop to cut them to size in the bandsaw.

Typically, this should be about a 30 minute job at most. But, the band saw we used had a really out-dated blade. It cuts 1/10th of the time, and caresses your stock 90% of the time. -_-.

Still, we managed to just cut all of the essential pieces to make a the simple square shaped base.

We couldn’t really do much with the 80-20 pieces without having connector pieces. So we went ahead and started laser cutting the electronic base.

The solidworks drawing was saved as .dxf, imported to AutoCad, RESCALED and then printed on a 10% speed, 70% power setting.

Later in the week, we would find that the piece didn’t account for inaccuracies. Regardless, it was already 6:00pm, so it was time to go home.

Tuesday 8/9/11

I scheduled a meeting with Ken, director of the MIT Hobby Shop, to help me water jet the motor mount pieces.

Ken was very helpful, and we finished manufacturing the part with minor issues ~~such as almost ruining the waterjet nozzle and z-axis~~.

This piece costs around $30 to make. It’s not so bad when you only have to do it once, but we have 4 of these, so it’s actually $120.00! It’s $3 a minute so manufacturing time was around 40 minutes. Note to self: Don’t have too many fancy rectangles. Those spike manufacturing time and also price very quickly. XD

Still, water jetting is pretty awesome. Observe:

It’s a perfect fit. ;]

We tried to do other machining stuff back in the lab, but it was futile since we didn’t have the right tools.

Anyway, at the end of tuesday, I made sure all of the parts we need would be ordered from McMaster. Which means, parts won’t be coming in pretty soon. Or so I thought…

Wednesday 8/10/11

I decided to come in late to work, and by the time I got there all of the parts was delivered. Talk about awesome timing. :D McMaster hasn’t failed me yet! The parts list was around $300.00. 80-20 parts from McMaster are pretty ridiculous. If you’re worried about price, don’t buy 80-20 from McMaster! It’s exactly like buying from a middle man instead of the actual supplier.

In addition, an L-bracket from them cost about $5.00 ea. Unthinkable! So my supervisor said I should just make my own. >.>

Anyway, we spent too much time machining on this day. No actual assembly was done. By machining, I mean making these annoying L-brackets:

Again, we used the same weak band-saw which cut 10% of the time and caresses your part for the most part.

After cutting them to 1in( + or - 0.2in) pieces (This was ridiculously inaccurate. Damn band saw). We had to drill the holes. The holes have about a 0 tolerance in terms of being lined up.

Lucikly, this machine was there to save the day:

After using an edge-finder, a digital read out (DRO) and a part stop, I made 24 accurate L-bracket holes. If you’re mass producing something, Use the same reference point and a part stop! Super helpful and increases productivity.

But seriously though, I need to stop designing with these crap. But the only alternative I know is using plates or welding (a skill I still need to learn). >.<

Anyway, that took a whole day to do.

Thursday 8/11/11

Come Thursday, I thought we would be assembling the entire day. But again, unforeseen problems unfolded.

I had to mill out certain pieces to make room for a notch on the motor I decided not to model earlier. I knew not modeling that piece would hurt me later on! Here’s what I mean:

And here’s our solution:

Anyway, the remainder of the afternoon, (3pm - 5:50pm) was spent on assembling.

Here’s how far we got:

Not too bad. And plus! The manufactured L-brackets worked. Real high tolerance holes can be achieved with consistency and good setup.

Main chassis + Speed controllers are setup.

Also, if you notice, the acrylic base is now black. Again, this is because of the brackets. I modeled the brackets to be the ones from the 80-20 retailer. But when we made our own brackets, I didn’t take this into account. So we quickly laser cut a new piece.

Tomorrow, motor assembly and wiring will be done.

Let’s review my checklist again:

~~1. LaserCut Acrylic Electronics Base~~

~~2. WaterJet Motor Brackets~~

~~3. Cut 80-20’s in the Bandsaw.~~

~~3.1 Do extra Machining with 80-20s~~

~~4. Purchase all accessories from McMaster~~

5. Assemble and Wire Electronics

Assemble and then present! We have 24 hours. :]

OmniDrive Version 2.0 10 Hours later, an initial CAD model is...

stevenjens — Sun, 07 Aug 2011 00:06:00 -0400

OmniDrive Version 2.0

10 Hours later, an initial CAD model is finished!

Upon reviewing the first design of the the omnidrive all-purpose-platform, there was a lot of talk between my supervisors about being too heavy-duty and overly designed. Naturally, a redesign is much needed.

The biggest opposition beforehand was the complexity of the suspension system. And arguably, it turns out the platform won’t be experiencing any rough terrain and probably won’t need much dampening system anyway, so this really had to go. I actually wanted to see if I can make a custom drive system with a working suspension, but I suppose practicality dictates the situation.

Regardless, this time around, the specs of the robot was more defined. I finally know the boundaries I need to work with. My supervisor also decided to start buying the materials. Because each part cost almost $100.00, it’s pretty much guaranteed to be used once bought. Which means, It HAS TO BE IN THE DESIGN.

In some cases, this can be problematic because your design will be restricted. BUT! I actually prefer this because before the design specs were completely open-ended that there was a bunch of solutions. Selecting some constraints lets your final design converge.

-“Specs” for the new design:

-Must be as small (length and width) as possible

-Must be as short as possible

-No more crazy suspensions

-“Modular”

-Cheaper

-Must be able to carry arbitrary load (~200lbs)

In addition to specs, certain materials are also narrowed down. These babies were finally bought:

It’s a dualie-omni wheel because it’s literally 2 omni-wheels in one. The primary difference is that the wheels were offset from each other.

As for the motors, the real goal is to make them operate as quietly as possible. I asked for MITers for assistance and it seems that the best way to go is to use wheel chair electric motors. But these are extremely expensive… So upon further “research” I stumbled upon wormgearbox motors. It was a battle between:

http://www.robotmarketplace.com/products/NPC-2212.html

and

http://www.robotmarketplace.com/products/NPC-41250.html

I tested the motors, and running them on a 20% duty cycle (around 2V) with the VICTOR883 showed that the latter motor(NPC 41250) was quieter. I’m actually glad because this motor has mounting holes perpendicular to the drive shaft so it’s a lot easier to mount. All it needs is some water jet part.

Here’s the motor mount:

SolidWorks makes it really easy to make custom mounts and faceplates using circles lines and offset entitites. You can also make them fancy with fillets. XD

In the design, I also wanted to maximize the room for electronics but at the same time not ruin the symmetry of all the motors. The limiting factor to this is the motors.

In order for the platform to be as short as possible, the motors needs to be mounted horizontally. But since the motor is not symmetrical, the entire platform must be bigger to compensate for this.

Here’s an example trying to optimize space but losing symmetry:

You can clearly tell that the motors aren’t aligned.

I’ve put lots of constraints so that it’ll be symmetrical everywhere giving a square base while having the geometric centroid on the center of the robot:

Thus, this is the minimum required shape to retain perfect symmetry given the motor dimensiosn.

The design can actually be further simplified by not having shields that protect the omniwheel:

Practically, this is the way to go because it conserves space. It’s only 21”x21” from its maximum points. But, I think you’ll agree with me when it doesn’t look as COOLas having shields:

Design notes:

No Shields:21”x21”

With Shields: 23.5”x23.5”

It’s only a 1.5 inch gain for more space for payload and *cough*coolfactor*cough

Overall, I’m pretty content with the design. It stands 7 inches tall from the ground to the maximum height. It’s pretty short, but wide and powerful enough for almost any payload.

Motors, Microcontroller and Speed Controller are all working...

stevenjens — Thu, 04 Aug 2011 15:44:00 -0400

Motors, Microcontroller and Speed Controller are all working together.

After a 3-day headache, with the help of a coworker, we finally got the motors to run with the Arduino UNO. I finally have a further understanding of how this works.

The picture above has 2 VICTORS daisy-chained together powered by a 12VDC power supply. We’re trying to test 2 different types of motors since we’re still not sure which one to use in the final design. Preferably, I like the one with the face mount.

In any case, here’s the basic diagram of the wiring:

I recommend not following the program code because that analogwrite command is not the correct PWM signal that the VICTOR controller wants.

What I’ve found out is that VICTOR controllers wants “Standard RC” type PWM. It turns out that PWM is a commonly misused word in the microcontrollers world. So instead of PWM, VICTORs actually want PPM (Pulse Position Modulation). Many thanks to MITers for clearing this issue up.

In any case, if you’re trying to use VICTORs as speed controllers and you want to interface it with the Arduino, treat the VICTOR as a Servo and send a servo.writeMicroseconds(#val) from 1000us to 2000us where 1500us is the neutral point.

Also, the source of the problem I’ve been having the past few days was very trivial (as it always is). The PWM cable doesn’t line up properly in the VICTOR, so you really have to make sure there is a secure contact. How do you make sure? Wire everything correctly and test it with a working servo code.

Anyway, now I can move on from the electronics and programming, and continue working on the final mechanical design.

LED Wiring Design Tool I present to you, the most intuitive...

stevenjens — Tue, 02 Aug 2011 23:14:00 -0400

LED Wiring Design Tool

I present to you, the most intuitive planner for LED wiring.

My next small project deals with LEDs. LOTS of it. I haven’t played with LEDs much, but I knew the theory behind them. It’s really just a glowing diode with a built in resistance. This is where experience helps more than theory.

Although I trust my own math, I referred to someone/thing that can do it for me reliably. So I looked for an easy wizard that can easily plan out LEDs.

Ta-da. This site is extremely intuitive and easy to use. All I had to do was look at the LED spec sheet, look at the voltage I’m giving, and I get a proper solution.

No more repetitive LED calculations.

Comment Box Added

stevenjens — Tue, 02 Aug 2011 09:37:00 -0400

I’ve implemented a comment feature on every post so that even outsiders can also be part of discussion.

Full Scale OmniDrive Intro I’ve built full scale robots...

stevenjens — Mon, 01 Aug 2011 23:57:00 -0400

Full Scale OmniDrive Intro

I’ve built full scale robots before, but my involvement was strictly limited to just designing the drive system. This time around, I want to also handle the programming and electrical systems. It’s true that I’m trying to do everything, but my coworker is also helping me develop this platform. I’m not alone in this, but I do think I’ll be more involved, which is pretty great.

This summer, I’m UROPing for the MIT Museum Lab. I’ve already proven that this drive system can work. Now, it’s time to scale it up.

Above is the first full-scale design iteration. It’s quite heavy duty and that’s the problem. I personally want to add a suspension system in it, but my supervisors worry that it might be an overkill design. To an extent, I do agree. If I remove the suspension, the dampening of the chassis will be gone but the overall weight of the robot will substantially decrease.

My supervisor and I were throwing ideas together to try and implement the suspension system while decreasing the overall weight of the system. I’m open to suggestions, but unless it performs just like a suspension, I can’t go with it,

Anyway, besides Mechanical Design, some of the parts have already started coming in:

The parts above in total costs about $250+. Which means this robot will definitely cost a lot of money. Anything that will decrease the robot’s weight will greatly be beneficial.

I’ve also started fiddling around with the motors.

I hooked it up directly to a DC power supply and changed the voltage there, but I’m still having trouble sending a PWM signal from the Arduino. It seems I need a signal driver, which I completely forgot to tell my supervisor to buy.

I have come to conclude that I lack the fundamental knowledge of things. For one, I don’t understand what kind of signal is sent by the arduino to the VICTOR controller. I can’t test it because I don’t know how to read an oscilloscope. I can probably use an Op-Amp, but again, I don’t know if that’ll send a Voltage signal or some sort of current.

I absolutely cannot wait to take classes for this because it’s a bit hard to find reliable information from the internet.

It doesn’t help that we probably ordered the wrong motor controllers. This is a VICTOR 883 which operates at a nominal voltage of 24V. But our motors operate at 12V. I speculate that it doesn’t matter, but I could be wrong. And this uncertainty just adds an extra unknown variable.

I’ll update more next time when there’s legitimate progress. For now, I’ll be designing the mechanical system more.

Transforming a Basement into a Laboratory / Project Space I am...

stevenjens — Mon, 01 Aug 2011 23:18:00 -0400

Transforming a Basement into a Laboratory / Project Space

I am fortunate to be in a fraternity that owns two houses. This summer, I was able to talk to our Alumni board and give a proposal to transform this basement into a working project space for students.

So far, the idea was taken well, and there seems to be quite a few funding remaining left to really make this place happen.

This idea has been around for quite a while, but due to school work, it hasn’t been executed. Summer has given me a lot of free time and I’m prepared to handle any paperwork to get this done.

The funding and support are there, all I have to do is put effort and make it happen.

OmniDirectional Drive Prototype Mechanical Design Since this was...

stevenjens — Mon, 01 Aug 2011 22:33:00 -0400

OmniDirectional Drive Prototype

Mechanical Design

Since this was just a quick prototype, we wanted to get one working as quickly as possible. Not knowing the budget that we have for the project, we decided to use an Acrylic base because it was readily available in our lab’s stock. As for the other components, we decided to use VEX components because I have dealt with it before so construction should be fairly easy.

We created and rendered our design in Solid Works. (See image above)

For time efficiency, We used a laser cutter to create the acrylic base. But, given that the CAD file contains all the geometry for the hole positions, it can also easily be plotted and drilled with a regular drill press.

Below on the right is the “built” prototype. None of the electronics are mounted securely. If you didn’t notice, that’s yellow duct tape holding it in place. Next time, electronics mounting should definitely be put into account.

Controls

This means that given an x, y value we know the proportional power each wheel will need to go to that location giving us a complete span of the 2-D subspace.

This calculation is appropriate because our transmitter is a PS2 Controller:

The Left Joystick gives us a position x and y, and based on this coordinate, we can change it into a column vector [x,y]^T. Now we just use our equations for and to get the proper proportion.

This controller has its wires ready to be plugged into the arduino board. It can be purchased from: http://www.lynxmotion.com/p-552-ps2-robot-controller.aspx

Electronics/Wiring:

We used an Arduino UNO board as the robot microcontroller. All software and hardware is available on their website @ http://www.arduino.cc/.

The wiring is pretty straightforward. The 7.2V battery powers both the Arduino-Board and the VEX motors. I will try my best to illustrate what we did. If I insult your intelligence, I apologize.

I. The VEX Motor has 3 pins which corresponds to 3 wires.

Signal Goes to the the digital input of the Arduino Board. In our case, we used this wire to send a PWM signal to the Motor Controller 29 of the VEX motor.

Power Goes to the Positiveterminal rail powered by the 7.2V Battery

GND/Ground- Goes to the Ground of the Negative terminal rail of the 7.2V Battery and the Ground of the arduino board. This is crucial! The entire electronics component must have a common ground. So the Ground of the Arduino, battery, and the motors must be connected together. (This is because the signal going from the arduino to the motors needs a way back to the arduino board. Otherwise it’s not a complete circuit!)

II. Powering the Arduino Board

The arduino board requires 5V of regulated power to operate. Conveniently, the Arduino has a Vin pin input which can take up to ~15V of unregulated DC voltage. Take the +7.2V power railing and connect it to the Vin of the Arduino board.

III. PS2 Controller Wiring:

We pretty much followed instructions from this website: http://www.billporter.info/playstation-2-controller-arduino-library-v1-0/.

Programming Code:

You need the PS2 Controller Library v1.6 from http://www.billporter.info/playstation-2-controller-arduino-library-v1-0/ and import it to your Arduino Library. If you’ve never done it before, simply extract the files on the filepath/arduino/libraries folder and restart the arduino software.

As for the code, it is Available for download at:

Bill of Materials (BOM)

· VEX Chassis: http://www.robotmarketplace.com/products/VEX-276-2024.html

o The Chassis Rail was cut into halves to give 8 pieces that constitute the drive base

· VEX Motors with Motor Controller 29 http://www.robotmarketplace.com/products/VEX-276-2181.html

· Arduino Board UNO http://www.sparkfun.com/products/9950

· 5V Regulator http://www.sparkfun.com/products/107

· 7.2V VEX Battery http://www.robotmarketplace.com/products/VEX-276-1456.html

· VEX Hardware

o 8-32 Screws http://www.robotmarketplace.com/products/VEX-275-1005.html

§ For Structure Mounts

o 6-32 Screws http://www.robotmarketplace.com/products/VEX-275-0659.html

§ For Motor Mounts

o LockNuts http://www.robotmarketplace.com/products/VEX-275-1027.html

Obligatory Introductory & Test Post

stevenjens — Mon, 01 Aug 2011 21:26:00 -0400

Hello.

As I continue my education, I have made this blog for the Sole Purpose of Understanding anything interesting, curious, innovative, and intellectually engaging. I am a believer of the motto “Mens et Manus” which means mind and body. A more interpretive meaning would be “learning theory and concept through hands on work.”

For my personal experiences, I learn and retain knowledge better when I do hands-on work. Theoretical statements simply stay for an incredibly short amount of time before I only have a slight idea of what it actually means or how I can actually try to use it.

Thus, the purpose of this blog is to document any hands-on learning I do throughout the remainder of my college career and post college experiences. The idea is that documenting your work is also beneficial in memory retention. In addition, this can also be a convenient place to store my portfolio online.

I will first try to import as much of my work and other useful information I have found throughout the internet.

May this blog be successful and full of wonderful creations and ideas.

See You Later