Categoryubcec

UBC Engineering Competition 2011

Just like last year, I participated in the UBC Engineering Competition again, except this time, I competed with a different team.  Although the winning team would have a chance to compete in the next level of competition (I don’t even know where that would be – last year it was in Saskatoon), two of our teammates couldn’t make it even if we won.  One of them would be flying to Hong Kong and another was starting a Co-op work term in the Silicon Valley working for NVidia.  It didn’t matter though, because we didn’t win first place this year.

This year’s competition problem involved the following scenario: normally solar panels are able to rotate toward the sun, but sometimes they get stuck, therefore it requires people to go out there and rotate them manually.  Also, undersea transmission lines sometimes get severed and also require manual repairs.  Our task was to build an autonomous vehicle using a VeX Robotics Kit in about 5 hours to use in a small scale arena emulating similar conditions.  A wooden pole represented the solar panel, that we had to rotate and a plastic pipe represented the transmission line.  To “repair” the transmission line, we had to build a repair module using newspaper and popsicle sticks that could physically cover up the pipe.  Additionally, in order to reach the transmission line, the vehicle would have to cross a rice field (represented by uncooked rice) and cross a river (ensuring that no electronics get damaged, they had to be above the “water line” at all times – represented by the dip in the arena).  After designing our vehicle, we would also have to present our design to the judges.

When I heard what the problem was, I thought to myself, “this is an impossible problem given the time we have to build it ands lots of teams aren’t going to be able to perform the task”.  I guess it was supposed to be like that.  The problem couldn’t be too easy or otherwise everyone would be able to do it.  Despite the difficult task, we approached it with a super chill attitude throughout the entire competition.

As a group, we planned out what we wanted to do.  We thought that it would be straightforward to go across the river, but it turned out that it wasn’t that straightforward.  We had trouble keeping our electronics above the “water”.  The line follower kit we used could follow the black line quite accurately, but it had to be about an inch above the ground.

To make matters worse, the wheels kept falling out.  Normally, one should just have to insert the shaft into the motor clutch and connect the clutch to the motor, but the connection was quite loose. 

One of our teammates spent about 3 and a half hours trying to fix the wheels and he succeeded. It took up a lot of time that we needed for the other design tasks, but we couldn’t leave that along since movement along the ground was a critical function.

In the meantime, we brainstormed how we would rotate the vehicle to face different directions when needed, how we would pick up the repair module, and how we would rotate the solar panel, and how to protect the line followers while crossing the river.    We also had to think of what we were going to say for the presentation.

We couldn’t really get the rotation to be accurate without using an encoder (which would increase our product cost), so we tried to see what we could do without being able to rotate the vehicle.  We could drive straight toward the solar panel, rotate it, and return to the base.  If we focused on just this task, we didn’t have to figure out how to figure out the other tasks.  We figured that most teams wouldn’t be able to perform that task anyway.  With that in mind we modified our design drastically and came up with something that kind of worked.

The end reached high enough such that we could just bump into the top of the solar panel and rotate it and then go back to the base.  We didn’t need to worry about the other task of repairing the underwater transmission line.  There wasn’t enough time for that.

When it came to the presentation, we talked about our design and answered the questions quite well, but one of the competitors asked us a question that a lot of people seemed to feel was a very jerk question to ask.  He asked “how would the client feel that we delivered a product that could not meet all the stated requirements?”  I guess he was bitter that my team beat his team last year and felt threatened by me this time around.  We answered the question by saying that it’s better to do one task well, than to fail at both. 

In the competition, a lot of teams did in fact fail the tasks and did absolutely nothing.  When it came time for our device to compete, we did what we could.  It did reach the solar panel and rotate it a bit, but not enough to rotate it all the way.   It couldn’t even complete one task, although we had tested it before and saw that it did work.

The winning team (the same team as the guy who asked us that terrible question), used a design that would travel align the walls, past the river and to the broken line.  It picked up the repair module (shaped like a table) using a flat pad to slide underneath to pick it up.  It managed to do a 90 degree turn by following the wall (push sensors would tell the vehicle that it had in fact touched a wall).  It was clear that their design won out over everyone else’s, and they totally deserved the win.

UBC Engineering Competition 2010

UPDATE: Pictures here!

A couple weeks ago, a classmate of mine invited me to participate in the UBC Engineering Competition in Senior Design.  After checking the calendar to see if I was free that day, I accepted.  I later found out that the winners of this competition would represent UBC in the Western Engineering Competition in Saskatoon, which will take place in January.  The problem with this was that three out of the four people on my team had a Co-op work term (myself included).  Despite the fact that we knew we weren’t going to the competition, we went to compete anyway.  There was little pressure for us, and winning or losing didn’t matter.

Some time later, I realized that my friend’s birthday party was the day before the competition, which meant I probably wasn’t going to get a lot of sleep.  Indeed I was right.  I got home at about 2:30 in the morning and had to arrive at the competition at 8:30.  Before I slept, I read an email that told us to read over the competition materials and to prepare a PowerPoint presentation template for the competition.  Seeing that we weren’t aiming to win the competition, I neglected to do any of this preparation.  My teammates neglected this as well.

On the morning of the competition, we went through all the registration procedures and find out what the design problem was.  Our task was to build an autonomous vehicle that could transport an object and bring it back to the starting location.  The only parts we were given was the Vex Robotics Kit, which came with a microcontroller, motors, wheels, and parts to build the frame.  We would be scored on how many objects we picked up, the weight of the vehicle, and the team’s presentation performance.

Since we didn’t really aim to win the competition, the team ended up being super chill through the entire competition.  One of the officials said to us, “Your team is the least stressful team we’ve seen!”  We made so many lame/funny/stupid jokes during the competition and had such great laughs.  Throughout the entire competition, I was probably super sleepy, and found no time to rest at all.  Despite the fact that we didn’t aim to win, we still tried hard in the competition.

Our strategy was simple: KISS.  Keep It Simple Stupid.  We realized that in the 5 hours we were given to design it, we did not have time to make anything complex.  It made the most sense.

The biggest design issue was the question of how the vehicle was going to know how to return back to its starting location after it leaves.  The only sensors we were given were buttons that would be pressed when the vehicle ran into an object.  None of these sensors would help us achieve this.  We thought of making the robot do a 180 degree turn, but this was difficult since we didn’t really have a way of measuring how many degrees the vehicle had turned.  We tried to time it, but the time it took to turn varied depending on how heavy the cargo was.  One of my teammates came up with the terrific idea of not rotating at all.  The vehicle would drive straight, pick up and then go in reverse back to the starting location.  We would then orient the vehicle in another direction to pick up the next object (we were allowed to do this since teams are allowed to touch their vehicle when it is in the starting location).

Going with this strategy, the vehicle would drive in a straight line toward the target object.  A sensor placed in the front of the object would be activated when the vehicle hit the object.  This would signal a cage to come down and enclose the object.  Then the vehicle would go in reverse back to its starting location.  The cage was simply a “fence” that was initially raised and then lowered to enclose the object.

After a lot of testing, we were quite confident that ours was going to work.  While doing all of this testing and designing, one of my group members made the PowerPoint presentation.  It basically talked about how the device worked and our design strategy.

The only preparation for the presentation that we had was just 5 minutes of telling who would present which slide.  When it came time for us to present, we looked at the slide and pretty much made up what we were going to say on the spot.  Because of this, our presentation seemed quite natural.  The fact that we all worked on the project allowed us to all know what we were talking about, so we didn’t stutter a lot.  I figure we did okay on the presentations.  Nothing spectacular.

After the presentations, each team took turns demonstrating their device.  There were a few designs that were definitely innovative, ambitious, and simple.  Among these, there was one that lowered a large arm onto the ground and sweep in a 360 to catch all the objects and return them all home at the same time.  It was a interesting design, but there was no way for the robot could do a perfect 360, since it was impossible to get the timing for it right and the power the motors gave would not be enough to move the entire load.  There was also a design that relied on randomly searching the entire field for an object and then moving around the perimeter of the field to return home.  This was the most ambitious design, but it didn’t work out because its random searching didn’t find any objects to grab.  Another team relied on the same principle as ours but were heavier.

As each team demonstrated their vehicle, it became apparent that our team had a big chance of winning.  We were very confident that we would get at at least one object, and our vehicle was the lightest one.  The team with the lightest vehicle would score the most points in terms of weight.  But for object retrieval, no team retrieved more than one object.  It was either one or zero.  If our vehicle grabbed even one object, we would be in first place for vehicle performance.  When it became our team’s turn to demo, our vehicle worked exactly the way we wanted it to.  We grabbed one.  We went on the grab another, but due to us failing to aim the vehicle properly, we failed to grab a second.  But it didn’t matter, we were in the lead in points.  Since no team grabbed more than one, we placed first in terms of vehicle performance.  We had a chance to win.

After the officials calculated the totals of all the scores, my team placed first out of twelve teams!  The best part about this is that even though we did zero preparation, we came out on top because we executed our design strategy better than the other teams.  We made use of the testing time to make sure our project actually worked.  It seemed like a lot of the projects weren’t tested that thoroughly, but that might have to do with the intense time pressure and a complex design.  The lack of pressure to win allowed us to perform so much better.

© 2017 Henry Poon's Blog

Theme by Anders NorénUp ↑