Team 2980 2013 Open Source Robot

Hey Everyone,

Now that the kick off is over and build season has officially started, Its time for team 2980 to begin posting our ideas.

As an off season project we designed a box to enclose all of our electronics. We incorporated the talons, because they are small, enclosed, and can drive the CIM motors.

As soon as I figure out how to have an attachment I’ll stick it in here.

We’ll post more ideas as we have them.

Edoga

Today was relatively productive. Our team divides up into four separate groups for the first week of the build season. Each group is supposed to come up with their own design, which we present to the community on Friday. The community then votes on which design they think is best, which is what we then have to build.

We currently have four ideas being kicked around.

Kat’s group is designing a shooter which has a vacuum to lift disks off of the ground, and then uses a spiral conveyer to lift the disks up into a quarter circle shooter which uses a spinning wheel in the center and a teflon tray on a gimble which can tilt…They want to use a camera to help with auto aiming.

Kyle’s group is also designing a shooter, going with a half circle shooter which is loaded from the feeder station. He also wants to put a tilt mechanism on it, They want a scoop to fold out of the front of the robot for floor loading disks. Kyle’s group wants to have their robot be 29" tall, use a piston to lift the robot, clamp on to the bar on the tower, and then lift the wheels up off the ground.

Rachel’s group wants to make a dedicated climber capable of basically driving up the side of the pyramid. It would use weird 3 wheeled rollers to drive over the horizontal poles, and have a bucket for dunking disks into the top of the pyramid.

Mallory’s group wants to make a speedy currier that loads at the loading station and then rushes back to shoot into the top slot. They want to focus on aiming.

As soon as we have sketches or drawings or something, and I figure out how to post pictures and files we will start posting images…I seam to have forgotten how.

Edoga

How did you determine voting should be included as part of your engineering design process?

So the voting bit…

It is really a way to take what we build out of the hands of the kids so that it isn’t a popularity contest. We act as though the community is our client, or as our board, who has commissioned us to design and build a robot for a competition. The community, and now Boeing are the ones who are footing the bill after all. The kids present to their client in such a way that the client can make an informed decision about the product being presented.

I think of the kids as thinkers and tinkers…The thinkers tend to dominate things like the design process, while some of the tinkers have really good ideas that they just can’t put out into the world in such a way that they are easily understood. In smaller groups those ideas that would get lost are often able to see light…(the big trees are sparser making room for the small trees to grow…) The team also has a bias towards listening to a thinker over a tinker…The things a thinker says have more weight, while they may not have more value…When the community walks in, they have little to know idea which is which. The community assumes all of the kids are thinkers, just because they are in a club where we build robots and do math and physics and stuff…So to the community each group has equal value, and it is just the strength of their ideas that matters.

While this hasn’t always led to the best robot, it has prevented hurt feelings…and I would argue it has led to the best robot we as a team are capable of thinking of at the time. The community tends to want to see our team stretch both mentally and physically, so they usually don’t pick easy designs, or designs that seam like cop outs. Also once the community decides it is a lot easier to bring the team back together because no one feels left out of the design process. We didn’t not choose team A’s design, the community did, and we can all stand by that impartial judge a bit more easily.

In the end it really comes down to ability to present ideas in a way that makes sense to people who may or may not understand any of what you are talking about. :stuck_out_tongue:

I hope this response makes sense in the way that I intended it to.

Edoga

just know that with dumping the discs into the pyramid goal that only the alliance colored (red/blue) discs count for points

Yeah…the climber plan has a really simple drive train for getting to the loading slots, and then back to the tower…or at least that is the idea.

Edoga

So I’ve been yelled at by my team for not keeping this thread up. We are now half way through week two and our team has been designing like crazy. We are trying to solve ALL of the problems BEFORE we start building. I am especially excited about how much we have grown as a team. The students are working hard, and learning Autodesk Inventor under tremendous pressure. We are also learning how things fit together so we should SAVE money this year!

The team spent week one divided into 4 design teams. Each team came up with their own design which we presented to our community partners. (We are partnered with the NAVY, and we also have a number of community members who help us out.) After seeing the presentations the community voted.

Below are descriptions of the different designs and what the community thought of each.

C.L.U.E.
(Coolest Launching Unit Ever)

Description

This robot was designed primarily as a shooter to fire Frisbees in the goal as well as hang from the first level of the pyramid. It was designed to be short enough to aim from underneath the pyramid for an optimal firing angle; however, it can fire from anywhere on the field. Its only defensive ability is to evade other robots. Teflon was used to decrease friction resistance in the Frisbee shooter. Mecanum wheels would be used for optimal movement. All materials would be cut out using laser cutters.

What went wrong?
The main issue with the design was it attempt to do too much at once. The sponsors were concerned about the various moving parts of the shooter. Height was also an issue, as the other robots could easily block ours.

Stormtrooper

Description

The robot was designed as both a climber and a shooter. During the autonomous period, it will use computer vision to file 3 pre-loaded disks at the 3 point zone. During the teleoperated period, the drivers will follow a rehearsed path through the field. It would have a capacity for 4 disks and will include a 360-degree horizontal swivel. The design is a tested and simple design with a highly maneuverable drive train and allows good mobility.

What went wrong?

The designs were not chosen because the presentation of the design was poor. The design was also deemed to similar to others. (taken directly from the internet with little modification)

Agent 2980

Description

This design is a 90 degree launcher with a pneumatic wheel at the center to launch the discs rapidly and precisely with a manually fed queue hopper that pushes the Frisbees into the shooter with a piston. Agent 2980 also has a four wheel drive to insure accurate launching capabilities. Agent 2980 would be able to successfully launch and score points in every game. It can also evade other robots. Thanks to the basic design of the robot, more time can be devoted to troubleshooting and perfecting the system.

What went wrong?

The robot is unable to climb the pyramid, and cannot pick up Frisbees off the ground, forcing the players to feed the robot often

Agent M

Description

This humanoid robot runs around the arena throwing disks through the top slot just like any human player would. It is controlled using a kinect skeletal motion capture just like the robot in REAL STEELE! At the end of the match it climbs up the pyramid like a monkey and dunks four disks in the top scoring zone all while singing the national anthem!

Bumpers! We don’t need no stinking bumpers…This robot carries a big stick to swat the competition!

Did we mention IT CLIMBS LIKE A MONKEY!

(Just Kidding!)


Description

Agent M is made to climb the entire pyramid. Unlike the other designs, this is not a shooter, but rather an extended arm that dumps buckets of Frisbees in to the goals. The protocol is to climb up the 3 levels of the pyramid, and dump all 4 allowed Frisbees into the 5 point box, guaranteeing 50 points.

Why it was picked

While it not a long range scoring mechanism, this robot was chosen because it offers the most efficient path to 50 points. The community especially liked how daring the design was.

(My students wrote the above descriptions with the exception of the bit about the humanoid…I through that in for fun. :slight_smile:

I am sure we will see all of the above ideas at the Microsoft Seattle Regional!

Can’t wait to see it all come to life!

Edoga

Major Problems being worked out…

So our goal with Agent M was to drive up the pole…This would be hard enough, if the pole was just a straight shot, but with those stupid rails in the way…

Our original thoughts were that by using these weird “tri-wheels” we could drive up the pole, and when one of the small the wheels met an obstacle the entire wheel would simply flip over driving over the problem areas on the pyramid…

In the original design had four of these wheels mounted at 90 degrees, so that the wheels would sort of cup the pole as the robot drove up. The idea was that the robot would flip the wheels as it went over the horizontal bars robots can hang from.

We realized that as the wheels rotated around they would do two things…First the wheels would crash into each other and bind. Our next solution to that problem was to switch to three wheels, and off set them so that only one wheel would be flipping over at any given time. Here again we ran into trouble. As the wheels flip over the longer leg moves down into the center position. This would push the robot side ways instead of up and over. When the robot came back down it would no longer be lined up with the pole which would result in an expensive fall!

We were seriously close to giving up on the plan all together and starting over when we noticed an old robot I made a number of years ago that had a suspension system. I keep it up on top of a cabinet where I am sure it will fall off and crush me some day. :slight_smile:

In any case after reviewing how it works we came up with the plan of mounting the tri-wheel assembly’s on springs. It is our hope that when the wheels encounter the barrier and begin to rotate around, as they lift up the springs will absorb the travel smoothing out the robots ascent and maintaining the wheels contact with the pyramid at all times.

The shock mounts give the triwheels 3 inches of travel. Of course we are banking on a whole lot of things working together…We can only hope that things will work the way we expect them to. If not…I guess we can dump disks in the 1 point slot.

(It will work…It will work…It will work…Our new team mantra)

Finally today we worked on making the shocks smaller. Garret and Mr. McGinnis managed to shave about three inches off of them which will give us much more room for electronics. We have to work hard to keep as much of the weight possible low and forward which means this robot isn’t going to handle very while it is on the ground.

Maybe we should rename it SLOTH. :-p

I’m sure we will run into more problems as we continue on with this design and build. Here is to it all coming together in the end.

Edoga

Just a friendly reminder that you will need 8" of bumper on each side of the triangle cut out to fit the pyramid. The model makes it look like it is okay but I can’t see the dimension to be sure.

You’ll have to let us know how the chassis holds up over the season. The climbing design we’ve been tossing around involves a similar cut out to fit the pyramid inside it, but I’m concerned about building a rigid enough chassis that would hold up if we stick it in the middle of our chassis like that. If we do end up building a climber I think it is more likely that the mechanism will be mounted on top of our robot and we’ll flip over to climb.

So the robot is really wide, 30 inches, and 24 inches long. We plan on skinning it with polycarb at least on the sides, or atleast that was the plan as of a few days ago. We should be publishing all of our CAD files over the weekend. The frame mouns on the front and back are 8 inches long. :slight_smile: We will hopefully have our final final final drawings by the end of today to post and share! We have 1 or 2 more major problems to overcome first though.

Edoga


Hey all,

We have made detailed annotated PDF files of all of the parts of our robot so far, but I need an administrator to give me permission to include them as an attachment.

I made the files an attachment on the TrossenRobotics forums. I personally spend a lot of time over there when working on my own personal robots. In anycase You can download the PDF files that our robot is being built based on. If possible we will find a place to host our Autodesk Inventor Files in the near future for anyone who is interested.

http://forums.trossenrobotics.com/showthread.php?5946-Team-2980-s-Open-Source-FIRST-Robot&p=55106#post55106

Enjoy!

Edoga

Hey All,

So we are making progress, slowly, but progress none the less. Our frame is starting to come together. Our robot looks a lot like a cube right now…We’ll have to figure out how to break up the shape to make it more visually attractive, but it it coming together nicely.

We are in a sort of holding pattern though, We are having a few parts cut out for us by a material sponsor/mentor. We can’t really continue doing much until those things get done.

We also have a small sub team that is welding up our frame. So again, until the frame is done being welded and powder coated, we will be waiting patiently. During the down time some members have been planning out our pit area. Some of the team members are researching for our theme this year. Some are working on our robot reveal video…This one has stunts and fast cars in it!

Me…I am a happy lead mentor who is actually stress free during build season for the first time ever. This plan of ours will work, or it won’t, and if it doesn’t we will modify it until it does…

Here is to turning a bunch of 1s and 0s into cold hard reality.

Edoga

We’ve started the programing and building the electronics. We just got a large shipment of gears, gearboxes, bumper materials, and other parts, so it’s a lot like Christmas around here.

This is a really neat design. Have you guys prototyped the climbing tri-wheels at all?

Also, I can’t tell how you intend to get the robot from the floor to the climbing orientation.

Hey Nuttyman,

SO…the tri-wheels were a sort of…all or nothing sort of idea. The kids made something out of legos…but as for a genuine prototype I don’t think they did anything. I’m sort of hoping they got it right. They modeled it in inventor and are going to town building it/ordering parts…At this point it might be a suicide mission where they end up with no robot. I’m sort of hoping that isn’t the case. In the least the idea is that they will keep fixing/figiting until it works.

As for the transition…I’m not sure the kids have figured that one out either. The original idea was to just ram into the pole…There is an arm mechanism that mounts on the top and folds down which they will probably end up using, and they are planning on having the tri-wheels whirring away as they drive into the pole. Worst case they are going to mount a teflon-V in the center square to slide onto pole.

Absolute worst case situation the kids will add a pusher to the back to help tilt the robot up.

great…now I’m worried.

Edoga

Lego prototypes are often sufficient, and any prototype is better than nothing. most of your weight is centered around the bar or below, so you shouldn’t be dealing a large torque trying to pry your robot off the bar.

As far as getting on to the bar, if driving up it with the tri-wheels spinning doesn’t work, I could see a wheelie-bar linkage or two (Like 33’s stinger last year) that just props the front of the robot up on omnis and drives on the rear wheels towards the bar. You’ve got plenty of space on the top of the robot if you need it.

All-or-nothing designs are not inherently a bad thing, and neither is letting the students try and fail. If they’re excited about it, that’s what matters. If it works, they’ve really accomplished something. If it doesn’t, failure is a very good lesson if you analyze what happened. As long as they learn something either way, it’s a successful exercise. Some of my most memorable design lessons came from things that DIDN’T work in FRC (ie don’t use set screws instead of keys on a CIM shaft to transmit torque to your drivetrain).

What’s your estimated weight at? With all these 5-gallon bucket, pneumatic fed, small wheel banebots shooters we’re seeing here on CD, I wouldn’t be surprised if you could fab one of those quickly and slap it on top of the robot for a quick HP load 2 or 3pt shooter. If I recall correctly, Discotechs 1099 had a video on youtube where they used the kit-channel as shooter guide rails with great success. Just some food for thought, if you’ve got the weight I’m not convinced this has to be an all-or-nothing design.

So I am going to post some things to consider since I really don’t want this thing to fail to an unrecoverable point. Here are some questions / suggestions:

  1. Are you depending upon the actual weight of the robot to generate the normal force required for the wheels to drive up? If so, please realize that you will need a coefficient of friction greater than 1.732 (tan (60)) to get enough traction no matter what your weight.

  2. If not, then your coefficient of friction + other method has to generate an effective coefficient of friction of 1.732 or this will not work.

The above is THE limiting factor for this type of design. I have analyzed this to the nth degree and it is a undeniable fact that you must figure out the traction problem before proceeding down this road. These poles are slippery, really slippery.

I hope it works …

Paul

I shortened the quote but I hope I didn’t change the meaning at all.

Hey Paul, I hope it works too, The kids did a bunch of math and then ordered a specific rubber from McMaster Carr. A few sheets of it are here and to be honest it doesn’t seam very sticky to me, but if I put any weight on the sheet it is relatively hard to slide across my counters. I’m hoping it is sticky enough, if not I hope we can find a way to find softer/stickier rubber in time.

We may have to go with a stinger or wheelie bar idea, and in I have an idea as to how we could maybe do it, I’ll have to look at the cad drawings.

As for the room in the top of the robot, there is a bucket that goes there for dumping disks in the top of the tower.

Thanks for the advice, I’ll share it with the kids!

Edoga

What I believe Paul is getting at is that you can’t rely on a tractive surface alone. No rubber from Mcmaster has a CoF of 1.7 on a smooth steel pole, coefficients between two objects must mechanically interlock for the coefficient to get above 1.0 and steel poles really don’t offer much of anything to interlock with. Even Roughtop wheels against carpet are only 1.4 when brand new. Basically you need something actually attached/ reaching around the pole to keep the robot from sliding/falling down… I would have your students begin brainstorming ways to do this so when the traction-only plan doesn’t work out you have a plan B.

I really hope you can pull it off.
Good Luck, Bryan

Looks like we are going with electromagnets run off of a solenoid breakout. I’m hoping this is a legal, and b doesn’t melt the battery or cRio. Won’t know until wednesday if the magnets we ordered will work, but I have fingers crossed.

Edoga