TigerTronics Blog

For anyone who didn’t already know, in the second-to-last qualification match at the 2010 FIRST Buckeye Regional in Cleveland, OH, TigerTronics’ robot Soccerates suffered a serious breakdown.  The cRIO computer on the robot (which acts as the robot’s controller) suddenly stopped powering on.  This paralyzed TigerTronics for the last two qualification matches.  We tried to get the robot working again with a borrowed cRIO before the alliances for the finals were picked, but we weren’t able to.  As a result, although we were selected to compete in the final elimination brackets, we were forced to decline, since we couldn’t in good faith accept not knowing if we would be able to repair our robot before the first quarter final.

The good news is that now, after the competition and with some time to investigate the problem, its been discovered that the problem was a blown fuse in the cRIO.  With this fixed, Soccerates (and its cRIO) are now back and running fine.  Not only is it good to have a working robot again, but its nice we were able to repair our cRIO, since they are rather expensive and teams do not get a new one every year with the kit of parts.  Had we been unable to repair the cRIO, we would have had to purchase another one, which would would have been a significant unplanned expense.

For our roller, we tested a few different methods, but the most promising method was a piece of 1 inch PVC pipe wrapped in baseball-bat grip tape.  The PVC was connected to an axel, and mounted on the front of the robot.  We connected the axel to a CIM motor through the use of PowerBelt ( PowerBelt is like bicycle chain, except its made of rubber).  We geared the roller down so that it had enough torque to give the balls backspin.

To center the balls on the roller, we used pieces of Lexan (Like acrylic, except it’s almost impossible to shatter).  We heated the Lexan up until it was hot enough to bend, and we made a funnel out of it.  These pieces then got mounted to the front of the robot.

Another feature of the robot is its ramp/ball blocker.  The roof of the robot is mounted on an axel, so that a pneumatic piston can push it up to be vertical.  When the roof is up the robot has a much better chance of blocking the goal (think about a very short goalie, and then a goalie that’s so big that it fills the entire goal…which one is better at blocking balls).

During the last 20 seconds of a match, the robots are allowed to extend outside of there frame perimeter in order to get on top of a tower in the middle of the field.  We decided to make a ramp, so that other robots could drive up us onto the tower.  We made this ramp be the same as our ball blocker.  During the last 20 seconds, one of the drivers presses a switch which tells the robot to drop the ball blocker.  The blocker falls to the ground forming a ramp on the back side of the robot.  Mechanism that allows the ramp to drop is an exact copy of the mechanism that holds our kicker back (a gate latch released by a servo)

To fix the issue of our electromagnets pulling too much current we decided to replace them with a mechanism made of a gate latch and a servo. When the kicker pulls back, it latches into the gate latch. To kick, the servo pulls up on the gate latch, and releases the kicker. This method needed very little refining, since it worked almost straight from the get-go.

Early in the season, the team decided the robot should have a roller, to keep the ball in its possession. Unfortunately, we never considered this when making the kicker. To put a roller in, the kicker needed to be modified. As it was now, the kicker would kick the roller instead of the ball. To get around this issue, we replaced the straight kicker, with a curved kicker (there is an indent that goes around where the roller is). Although this took a few days to implement, the results were great).

While we were at it, we also decided to fix a few other issues we were having with the kicker. Mainly, when the kicker pressurized it would bend the frame outwards. To fix this, we connected a rod end bearing from the kicker axle, to a turnbuckle, and from the turnbuckle to the back end of the frame using strong cable. Now, instead of the frame taking the strain of the pressure, the cable/turnbuckle mechanism took all of it. Not seeing the frame bend every time we wanted to kick put a great deal of ease into everyone’s mind.

Although we did get the robot to kick, we soon found that the software still had some major flaws in the kicking portion of the code, and to add on to all that, our electromagnets that we were using to hold the kicker back pulled to much current. Once again, we looked through the code. Unfortunately we realized that this wouldn’t be an easy fix. Our kicking code is made up of a string of actions that run depending on the conditions. For example if we only want to do a 30psi kick, but the actual pressure is 60 psi, the software has to tell the robot to dump some of the pressure etc… The problems that we saw happening was that once the pressure on the robot got up to a certain point, we couldn’t get it to dump the pressure to go back down. Also, when the foot kicked, the back side of the cylinder was still pressurized. This meant that when we tried to push the foot back to re-pressurize the kick, it couldn’t make it all the way back to the latching mechanism. We decided that to fix this we would need to figure out how to use the debugger. We asked around on Chief Delphi (a robotics forum), we got allot of replies, but it took about a week before we could fix our particular issue. Finally we were able to start fixing the kicking code. To fix the problem of the kicker not coming all the way back, we added three more phases to the kicking code so that it could dump the fire pressure when it was time to retract. After a bit of testing, we also figured out why we couldn’t get to a lower pressure from a higher pressure. (we had a few values set to true when they should have been false). We fixed these issues, and we were ready to roll. …Or so we thought. When we started to drive again, our wheels would stutter, and lock up. Having seen this in previous build seasons, I thought it might be the breakers switching. We picked the robot up so there was no weight on the wheels, we started spinning, but the wheels continued to lock. The wheels couldn’t possibly be pulling enough current with no weight on them, so we figured that it was something else. We took the electro magnets off, and suddenly our driving was fine

First off, I’d like to say that yes, I do know that this update is extremely late. I didn’t have time the last few days of the season to update. Then, the team went to the Rochester Regional. I haven’t updated since then because, honestly, I needed a break. Since this is so late, I guess I’ll break up the next few posts roughly in the spots of the build where I would have posted if I had time

The last post I made we left off with moving the battery box and fixing the drive code. With all of this figured out it was time to get our kicker working. The kicker we used was made of straight pieces of t-slot with a block on the end to emulate a foot. To power the swing of the leg, we used a pre-pressurized pneumatic cylinder. When the foot pulled back, it engaged an electromagnet. After this, the front end of the cylinder depressurizes, and the back end pressurizes. To kick, the electromagnet disengages.

Preliminary software was written to control these processes. We soon found that this software didn’t quite work as planned. We couldn’t figure out how to use the built in debugger, so we had to fix everything by printing data back to our laptop. (Note: Compared to using a debugger, this printing method is extremely hard. Its harder to understand what part of the code is running and so it takes a lot longer to fix). 3-5 days later, we finally got the kicking code to work. Our first kick was a great moment for everyone. With a full powered kick, we were able to kick about 25 feet with no bounce, and about 40 feet with 1 bounce.

Its come to my attention that in addition to the FOX 40 (WICZ TV) news coverage of TigerTronics, Time Warner Cable’s News 10 Now has also run a brief story on TigerTroncis.

Watch it online at:
http://news10now.com/cny-news-1013-content/496613/u-e-team-hopes-to-kick-competition

News 10 Now’s footage includes a great view of TigerTronics’ robot driving over a center field barrier and shooting a soccer ball.

Binghamton’s FOX 40 (WICZ TV) recently did a story on TigerTronics.  They got a few good quick interviews and some great shots of our robot driving around.

You can watch their piece on TigerTronics online at:
http://www.wicz.com/news/video.asp?video=02-09-10+tig.wmv.flv&zone=News

We have a snow day today, so I thought I’d take some time and write another update

Our first test drive of the robot didn’t go so well. The code acted up, the robot couldn’t drive up the ramp, and to top it all off, when finally after some help it did get over, the battery holder broke off. Needless to say, we had our work cut out for us.

We had our battery mounted underneath our electronics in between the two back wheels. We thought that the clearance provided by the wheels would be sufficient to keep the battery from hitting the ground, but, as can be seen above, that was not the case. Our first plan of action was to find another spot to mount the battery. We decided that the reason the robot couldn’t make it up the ramp was because we didn’t have enough weight in the front. Thinking this, we made another battery mount out of aluminum sheet, and mounted it in the front (this time above everything else). With this new mount, the old power connector didn’t reach the battery. After a quick lengthening of the wires this problem was fixed. Our only problem left was that of the misbehaving code.

Our first test of the robot showed that the code wasn’t working properly:  pushing the joystick forward made the robot turn,  strafing didn’t really do much of anything, and trying to turn the robot made it go forward.   After a quick look through the code, we realized that the wheel direction hadn’t been negated for the wheels on opposite sides. (This had to be done because of the motor orientation. A positive voltage always spins the motor clockwise. On the left side, a clockwise spin drives forward, but when you turn the motor around so it is on the right side, a clockwise spin will drive backwards). By the time this was complete, it was already time to leave.

This brings us to yesterday when we had our first successful drive in front of FOX news. At first the robot was acting up again. One of the wheels wasn’t spinning. Although this was a nerve-wracking situation, we soon found the problem, and fixed it (the PWM signal cable was plugged in backwards…oops!).

Finally, the moment we had all been waiting for. The robot climbed the ramp with ease, and descended without a flaw. We could even strafe along the top. Although there was a little bit of drift in the movement, we plan to fix this by adding a dead band to the code, and by calibrating the motors to spin at the same speed. (a dead-band basically means that there is a little leeway, if the joystick is only leaning left/right a small distance, the robot won’t count that as a signal to turn).

To answer a few questions I have received in the comments:

• Our robot is still under 18″, and as such can still go through the tunnel, as well as over the bump.

• I decided to use C++ this year just because I wanted to try it out. Although I did like programming the robot in LabView last year, there was a lot of things i didn’t like about it  (couldn’t figure out how to use variables,  always had to scroll sideways to see the code,   couldn’t write your own functions etc…)

After what feels like our most productive day of the season, TigerTronics’ yet unnamed robot is nearing completion. After almost a week of frustrating work trying to get our C++ drive code to build, the software team finally found the source of their troubles.  It seems to be a reoccurring theme with the team that the easy fixes take the longest time to figure out, and this was no exception.  A simple renaming of a header file, and changing a “.” to a “->”and the code built without an errors.  

All of the electronics were mounted to the chassis.  All that is left to be done is wiring everything together.  (This would be a fast process, except I keep misplacing the wire crimpers).  

The drive train team has been working on finishing up all the wheels.  Spacers were put in between the sprockets and the wheels, the chain was connected and tensioned, and the motors were connected to speed controllers.  As of yesterday, the drive train is complete.  

The kicker team has pulled through also.  The air cylinder, compressor, and the kicker itself are mounted.  The kicker team plans to mount all of the solenoids, and the air storage tanks in the coming week.  

Finally, the Bumpers are beginning to get made.  A clever mounting system allows us to place, and remove the bumpers very quickly. 

Although in the last post I stated that we were behind schedule, the hard work done today has nearly caught us up.

Tiger Tronics started the season strong this year.  Unlike previous years, we actually tested prototypes before we built the robot.  We now have a finalized plan of build, and we are working hard to finish the robot.  The main systems of the robot include the chassis, the drivetrain, the kicker, and the flipping mechanism.

Our chassis once again will be made out of 80/20 aluminum T-Slot.  For the drivetrain we will be using four “Nothing But Dewalt”  transmissions.  We previously used these modified dewalt hand drill transmissions in the 2008 season with Apollo.   Attached to these transmissions with chain are four mecanum wheels.  Although we will lose traction, we believe that the incrieced manuverability will overshadow this loss.

For the kicker we decide to use a pneumatic powered pendulum.  Our 15 inch stroke, two inch diameter Bimba piston was able to kick the soccer ball around twenty feet in our prototype testing.

The Chassis, and Drive-train are fully assembled, except for a few spacers, the Kicker is fully designed, but has yet to be built, and our flipping mechanism is still in the design phase.

Finally, we have received our new team digital camera, so pictures will be up soon.