Hands on Learning

PAMM2 System Overview*:

Figure 1: A traditional walker is integrated with the PAMM sensor-kit

The Personal Aid Mobility and Health Monitoring (PAMM) system is an affordable sensor-kit that easily installs in a traditional walker, which will be used to quantitatively measure the effectiveness of drugs against Parkinson’s Disease. Family doctors, researchers, and hospitals can use the tool to recommend better medication to patients.

Figure 2: Wheel modules with quadrature encoders and handle grips with force sensors integrate seamlessly to existing walkers.

Components:

  Figure 3: Electronics board for PAMM2 shows an arduino for processing, a 16G 3-axis accelerometer sensor, a SD card for data logging, and an RJ45 Female connectors to interface with the external sensors. This board will go inside an electronics enclosure box

Figure 4: A closeup view of the simplistic design of the wheel-quadrature encoder module.

Figure 5: A closeup view of a standard RJ45 connector which connects the external modules to the electronics board.

Data Collection Specifications:

Table 1: The table shows an overview of the individual sensors and their specifications which will be useful for data scientists.

In 2.12, my teammates and I develop a leg exoskeleton attachment that made a mannequin walk

Here is a video of it walking:

VIDEO LINK

During our final presentation I won the Most Valuable Engineer Award while the team won Best Design Award for the mechanical design and the generality of the solution towards the problem.

While the exoskeleton can attach to the mannequin, we designed the system as if it was a separate bipedal walker that carried a mannequin load.

I made the 1st design iteration (CAD model above), water jetted the primary components, and wrote the majority of the code with Bitzy Flamholz.

The control loop block diagram can be seen below:

Elements of Feedback Linearization with Position and Force control were used to give the robot compliant control and robustness to the system dynamics.

This project was a joint effort with:

(Kinematic Diagram Courtesy of Shannen Kizilski, [email protected])

 The robot puncher project has two components, a computational experiment that is programmed in matlab, and a physical experiment that attempts to perform and cross-validate the simulation results.

Matlab was used to derive the equations of motions symbolically, simulate a robotic puncher as well as optimize for activation/deactivation timing of each robot joint to maximize impact force.

A hardware implementation was made first using Solidworks to create a CAD model. Then, major components were made using a 3D printer. A belt and pulley drive was used to remove distal mass from the arm links.

This project was a joint effort with:  Jack Clark, Issac Fenta, and Shannen Kizilski

The sound of an acoustic guitar with different strings sets are quantified such that the best sounding combination can be obtained via a criterion. A microphone and an accelerometer is used to measure the overall sound and guitar body response respectively. 

Download Report PDF here

In this class project, we attempted to control the the non-linear dynamics of a helicopter’s vertical altitude.

Matlab’s Simulink was used to simulate and control the system

Back in 2010, I was co-drive leader with Chani Martin.

We designed and built a mecanum drive system for the FRC team.

Additionally, the modules were made such that it can be switched between mecanum wheel modules and crab drive wheel modules

Here is the robot getting featured at KCAL9 news in California:

Back in Highschool from 2006-2008

I was teammates with John Arakaki, Shivam Desai and Naomi Schurr.

We built a variety of robots, and won multiple competitions. The above image shows all of our robot collections including our trophies from the events.

Awards:

2008 VRC Division World Champions,

VRC Pan Pacific Champions,

2006 VRC 1st Runnerup

2007 VRC Build Award,

2008 VRC Engineering Design Award

2008 VRC Judges Award

2008, 2009 FTC 1st runner up,

2009 FTC Community-Service Award

Below is an action shot of us winning a competition.

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).

...

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

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.

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.

Syren 25Amp Speed Controller Wiring

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.

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:

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

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