Team 2363 turret actution

[ToddF]

Of all the concepts we had for actuating the turret, our students liked the concept presented by team 95 here the best.

We made some changes we thought were beneficial, but give credit where credit is due.

Video here.

[akoscielski3]

Looks Great!

We got ours mounted today. Only thing left it to put a belt around it and some tensioners, then we are done the spinning aspect of the turret.

[Andy A.]

Looks pretty snazzy!

[bearfromtx]

That is impressive, we were looking at a direct mount idea for the motor... this has shown me that I HAVE to gear down. Awesome design!

[Grim Tuesday]

At what power are you spinning that motor? We were using one of those for our collector, we may need to rethink.

[akoscielski3]

Originally Posted by Grim Tuesday

At what power are you spinning that motor? We were using one of those for our collector, we may need to rethink.

This motor (alteast the one i think they are using) spins at 84 RPM. We are using the other motor from andymark, that came with a gear box (not in KOP), spinning at 210~ RPM. This is just enough for a ball collector (with 1.9" diameter tubing, and polycord as a conveyor system)

This is the motor we are using

[n1ckd2012]

Out of curiosity, why is the chain fixed to the lazy Susan? Wouldn't a continuous chain allow you to shoot back wards? ( with proper wire routing of course)

Originally Posted by n1ckd2012

Out of curiosity, why is the chain fixed to the lazy Susan? Wouldn't a continuous chain allow you to shoot back wards? ( with proper wire routing of course)

But why shooter backwards? I understand if your robot is facing the other way/driving away, however for the most part most people are going to be facing the area they'll be shooting at instead of away from it, and I doubt we'll see too many people who will be shooting while driving away from their hoops.

[Steven Donow]

Looks very nice! We finally got our turret testing, and we're doing pretty much the same thing, only with a belt cut in half. We also don't plan on shooting backwards. Same motor too.

[LinuxArchitect]

Originally Posted by SuperNerd256

But why shoot backwards? I understand if your robot is facing the other way/driving away, however for the most part most people are going to be facing the area they'll be shooting at instead of away from it, and I doubt we'll see too many people who will be shooting while driving away from their hoops.

No offense, but I always laugh when people use the terms forward/front and backward/rear. When you do, you are limiting your actions. Except for the act of driving itself, who cares? It's not like you are actually sitting on the robot facing the forward direction of the drivetrain and you have to look over your shoulder to shoot "backwards". Your robot can move and face in any direction. Therefore, you might want it to shoot in any direction.

In this case, perhaps you are in the process of collecting a ball. Murphy says the ball will be in the most awkward location possible. Your design decision is, can I shoot immediately, or do I need to rotate the chassis. As mentioned, a small deadzone might be acceptable. But full 180 turns to shoot might not be.

Originally Posted by LinuxArchitect

No offense, but I always laugh when people use the terms forward/front and backward/rear. When you do, you are limiting your actions. Except for the act of driving itself, who cares? It's not like you are actually sitting on the robot facing the forward direction of the drivetrain and you have to look over your shoulder to shoot "backwards". Your robot can move and face in any direction. Therefore, you might want it to shoot in any direction.

In this case, perhaps you are in the process of collecting a ball. Murphy says the ball will be in the most awkward location possible. Your design decision is, can I shoot immediately, or do I need to rotate the chassis. As mentioned, a small deadzone might be acceptable. But full 180 turns to shoot might not be.

Understood, however I don't understand your logic behind the no front/back thing. You can't just drive your car backwards on a freeway and say it's forwards. For the most part, robots are going to have a designated "front" and a designated "back". That means when you go forward on your controller, your robot will go forwards.

I agree. Your robot itself is capable in moving every which direction it wants. So why have a totally separate part of the robot that turns independently of your robot when you can turn your robot just as easily in any way it wants? Unless your robot can hardly turn, or you haven't considered the robot's orientation a factor during the match, turning a robot 180 degrees is the same as turning a turret 180 degrees, if not faster since most drives are powered by 4 CIMs, whereas most turrets are going to be powered by one of the weaker motors. I've seen robots turn 180 degrees pretty fast.

As for limiting actions, isn't that what engineering is all about? Tradeoffs. Torque vs speed is my favorite one. And sometimes you end up limiting things you don't really need anyways.

As for your Murphy's law example (My favorite law ), there are so many ways to engineer your robot so that doesn't happen, and good driver training will easily be able to fix a ball in an awkward position.

I'm not at all saying turrets are bad, and love all of the videos that are being posted. Just that there are ways to make an effective robot without turrets.

[ToddF]

Originally Posted by SuperNerd256

So why have a totally separate part of the robot that turns independently of your robot when you can turn your robot just as easily in any way it wants?

Precision. To make an accurate long distance shot, the yaw angle must be controlled very precisely. During concepting, we knew we could design and fabricate a turret which could mechanically aim very precisely. We suspected that control of the shooter yaw angle via the drivetrain might not be very precise. The software can be written so the vision system can set shooter yaw angle by controlling either the drive train or the turret. We decided to go ahead and built a turret as a reasonable response to reducing technical risk. If it turns out that yaw control of the robot gives us everything we need, we'll keep the turret locked and only use the drive train. On the other hand, if the drive train is unable to position the shooter precisely enough, we have the turret actuator to fall back on, even if it doesn't rotate a full 360 degrees.

If, by some miracle, the computer runs fast enough, and the software is good enough, it is conceivable that we could keep the shooter locked on the target with an accurate "firing solution" such that we just drive around picking up balls and firing them continuously through the hoop, on the move. Can't do that without a turret.

As a mechanical guy, I always want to say, "The robot would be so much cooler if only the software could do ..." I never want to hear, "The robot would be so much cooler of only it was mechanically able to do ..." Of course, both software and mechanical people will always say, "If only the drivers were better, the robot could do ..." and the drivers will say, "If only we had the robot sooner to practice with, we could have done ..." Such is life when asked to do the impossible with too little time and not enough money.

Originally Posted by ToddF

Precision. To make an accurate long distance shot, the yaw angle must be controlled very precisely. During concepting, we knew we could design and fabricate a turret which could mechanically aim very precisely. We suspected that control of the shooter yaw angle via the drivetrain might not be very precise. The software can be written so the vision system can set shooter yaw angle by controlling either the drive train or the turret. We decided to go ahead and built a turret as a reasonable response to reducing technical risk. If it turns out that yaw control of the robot gives us everything we need, we'll keep the turret locked and only use the drive train. On the other hand, if the drive train is unable to position the shooter precisely enough, we have the turret actuator to fall back on, even if it doesn't rotate a full 360 degrees.

If, by some miracle, the computer runs fast enough, and the software is good enough, it is conceivable that we could keep the shooter locked on the target with an accurate "firing solution" such that we just drive around picking up balls and firing them continuously through the hoop, on the move. Can't do that without a turret.

Please do that! I wanna see that so badly!

[Tom Line]

Originally Posted by SuperNerd256

But why shooter backwards? I understand if your robot is facing the other way/driving away, however for the most part most people are going to be facing the area they'll be shooting at instead of away from it, and I doubt we'll see too many people who will be shooting while driving away from their hoops.

O Rly? Get back to me in after a couple of regionals. I think you'll be very surprised by what the top teams do in autonomous mode.

[JamesCH95]

Love it! We have made a few modifications to our original prototype, pictures to come soon I hope.