View Full Version : Picking up from both sides
Andrew Lawrence
18-01-2012, 21:40
A subject came up at our meeting today about making it so we have the ability to pick up balls from both sides. It would require no extra pulleys, etc., however would leave the entire middle part of our robot open, relying on other currently unknown ways to strengthen the frame.
I' can go either way, but I want to see CD's opinion on this subject. What are your thoughts on how to do it, and why?
EDIT: Would it be legal in the bumper rules if both sides of a wide-based robot were open for pick-up?
Thanks!
team1759
18-01-2012, 21:52
we were wondering the same thing.
live long and prosper
reply to us when u find out so we can destroy you. lololololol :) :) :) :)
Peyton Yeung
18-01-2012, 21:53
We thought of this but we decided against it because we though it would require some sort of hopper. We didn't think that was a necessity this year with the three ball rule.
David Guzman
18-01-2012, 21:53
I personally don't think it is worth the trouble. It would most likely raise you center of gravity too. Since there is a limit of three balls I don't see a HUGE advantage.
BrendanB
18-01-2012, 21:54
Sounds great for an increased pickup area but would require a lot of extra work and when your drive can pull a quick 180!
If you have a 2006 Behind the Design, someone did do that. I don't remember who, though.
If you have a 2006 Behind the Design, someone did do that. I don't remember who, though.
It was FIRST Team 123 (page 82 if anyone has the book). They specialized in picking up from both ends and dumping, but they didn't have a thrower. They had a big open hopper to store the balls in.
In this game, I think you're not going to want to. Even if we could pick up an unlimited number of balls, it'd still be better to only have one gatherer. Not only is it easier to build and maintain, it'd be easier for most to control. MOST (there are exceptions to everything) drivers have it easier maintaining ONE frame of reference, as in "I pick up from the front." The time it takes to switch orientation from driving forwards to back probably isn't that much faster than pulling a U-ey in an agile robot, so I'd say focus your efforts elsewhere.
That being said, if your team's hearts are set on it, go for it! Let us know how it turns out!
Andrew Lawrence
18-01-2012, 22:36
Thanks everyone for your replies! I'll show my team the results of this.
KrazyCarl92
18-01-2012, 22:52
relying on other currently unknown ways to strengthen the frame.
Hockey Sticks!:::safety::
Squeakypig
18-01-2012, 23:02
Our team has come up with some designs for this exact method and also some strategies to implement it. If you are creating a bot that is not super agile this is a great method, no need to turn, keep the turret lined up on the net, don't always have to rely on the targeting program to aim 100% correctly. With this design you will have to shoot balls more frequently since you can only hold 3 at a time and it is a great way to clear all of the REBOUNDS from your opponents goal. Think about it, line up your robot so it collects parallel to the fender on your opponents side and launch all of the balls over to your side for a "dunker" robot to put them in real quickly.
Every design idea has a good strategy you can implement with it. It just has to be the strategy your team wants to do.
Claimer: This was an idea that was brainstormed and prototyped. This design will not necessarily end up on the final designs for team 2851 Crevolution.
Andrew Lawrence
18-01-2012, 23:19
I added to the question (didn't want to make a whole new thread). What are your thoughts on that?
Thanks all! I really appreciate it!
Our team has been thinking about (and CADing) picking up from both sides, because we want to be able to rush backwards at the beginning of autonomous and grab balls from the coopertition ramp( after firing our initial two preloads). Of course, it all depends on what kind of shooter we build and were we put it on the robot, but we are open to the possibility that we might need to pick up from both sides.
Our team has been thinking about (and CADing) picking up from both sides, because we want to be able to rush backwards at the beginning of autonomous and grab balls from the coopertition ramp.
If you had a robot that loaded from the front, you could position it in the key with the front of the frame (with ball pickup) facing the ramp. Shoot your balls with the shooter pointing behind you, drive forward to the ramp, and get the ramp balls.
Aren Siekmeier
19-01-2012, 00:03
The bumper rules say nothing about the number of openings, so it is very possibly to do this legally.
As for the strategic value, we considered it, but determined that the added complexity in having a second intake and somehow joining them was not worth the saved time of turning the robot 180º. However, this does mean that we are going to be careful and deliberate about which side we put our one intake on (behind or in front of - or even to the side of - our scoring mechanism).
Ben27Lacrosse
19-01-2012, 00:48
My team is planning on being able to pick up from all four sides.:D
I attached what we have in CAD so far!
mathgeek0001
19-01-2012, 02:34
Our team was thinking of the same thing; we decided to do pickup from both sides because it synergies greatly with a swerve (or any other omnidirectional) design. On a swerve especially, having the ability to pick up without turning saves valuable time on a match, and, assuming that your bot can get balls through its system quickly, can starve the opposing team of scoring objects.
Peyton Yeung
19-01-2012, 06:49
My team is planning on being able to pick up from all four sides.:D
I attached what we have in CAD so far!
I was thinking of something similar to this too but our team opted to not have an omnidirectional drivetrain.
Brian Ha
19-01-2012, 06:57
Our team is going double intake because we want to be that robot sitting in the key shooting balls like crazy. Having double intake will allow our partners to shoot balls near us and have ease at collecting them. We are also going wide tank to collect balls even quicker. Haha.
Oh ye of little faith in "adding complexity". You guys need to get out more and prototype it; the design itself isn't difficult with orthogonal conveyor belts. All of the complexity falls on the CAD mentor, and not it's in building a 2-sided conveyor but rather trying to figure out where the electronics board will go because the nice neat place that was there isn't there any more.
Deep breath, heavy sigh.
Andrew Lawrence
19-01-2012, 09:45
Oh ye of little faith in "adding complexity". You guys need to get out more and prototype it; the design itself isn't difficult with orthogonal conveyor belts. All of the complexity falls on the CAD mentor, and not it's in building a 2-sided conveyor but rather trying to figure out where the electronics board will go because the nice neat place that was there isn't there any more.
Deep breath, heavy sigh.
Yeah. With our design, we've ruled out any added complexity. In fact, it's a lot more efficient than our one-sided design, and actually GAVE US ROOM FOR AN ELECTRONICS BOARD! :D
Yes, I'm as shocked as you are here, I just got the CAD this morning
Yeah. With our design, we've ruled out any added complexity. In fact, it's a lot more efficient than our one-sided design, and actually GAVE US ROOM FOR AN ELECTRONICS BOARD! :D
Yes, I'm as shocked as you are here, I just got the CAD this morning
The hardest part is figuring out how to balance out c.g., but there are also other things to think about. We originally had an idea that battery would be on one side of the wide-drive bot and all motors would be on the other side. Now it looks like electronics and the battery will go on one side (to keep the 6AWG wire short) and ... who know what else on the other. Well maybe we want the battery and electronics on the same side, but not so close that someone accidentally knocks into something while changing the battery. Perhaps we'll put the bridge lowering device opposite the electronics and the battery for partial c.g. offset.
Yet if we put the electronics on one side and the motors on the other, won't we need large channels for all of the power cable runs? Well what if we put the electronics board vertically on the back? Then the drivers can't see how many balls they have when the robot faces the other way to score. So maybe we stick to the side.
What about both sides, and a split electronics board? Nope, can't do that because we promised ourselves it's been more of a nightmare than a blessing in the last 2 years. Still need a large wire channel and it's simply harder to figure out what wires go where. Keep everything on 1 board, or at least 1 assembly.
There are miles and miles of questions, decisions, and tradeoffs. Yet as we lay them out we're realizing that they aren't insurmountable or overwhelming, which means they're within our capabilities.
Ben27Lacrosse
19-01-2012, 13:33
I was thinking of something similar to this too but our team opted to not have an omnidirectional drivetrain.
We got our inspiration from team #118's 2006 robot.
mathgeek0001
19-01-2012, 16:57
Yeah. With our design, we've ruled out any added complexity. In fact, it's a lot more efficient than our one-sided design, and actually GAVE US ROOM FOR AN ELECTRONICS BOARD! :D
Yes, I'm as shocked as you are here, I just got the CAD this morning
Are you putting the electronics board on the edges of the robot, by any chance?
one4robots
19-01-2012, 21:17
My team is planning on a block I design for the frame on omni wheels with both wide sides serving as intakes for a centrally located feeder. The two challenges we are currently facing (in order of difficulty) are center of gravity height and elec. board placement. We believe neither challenge to be insurmountable, and that the time saved during a match (1-5 seconds) is worth the trade off.
Andrew Lawrence
19-01-2012, 21:24
Are you putting the electronics board on the edges of the robot, by any chance?
Nope. It's all situated. PLUS, no weight distribution issues, so far it's mostly all symmetrical, and anything not symmetrical is countered be equal and opposite weight. I <3 our design. :D
My team is planning on being able to pick up from all four sides.:D
I attached what we have in CAD so far!
I just wanted to let you know that your Mecanum wheels are placed in the drawing wrong. Not that it makes a difference in the computer but it will play a huge role when build in reality! If you don't know the proper way (which there is only one way) message me and i will explain it to you.
We are also doing a double feeder. It will be quite a challange, but we are upt to it. Plus, our electrical lead is eager, though not thrilled, for the challange.
...Even if we could pick up an unlimited number of balls, it'd still be better to only have one gatherer. Not only is it easier to build and maintain, it'd be easier for most to control. MOST (there are exceptions to everything) drivers have it easier maintaining ONE frame of reference, as in "I pick up from the front." The time it takes to switch orientation from driving forwards to back probably isn't that much faster than pulling a U-ey in an agile robot, so I'd say focus your efforts elsewhere.
The ability to drive backwards is a trainable skill, although we've included inversion buttons on our controls several times. It's more the thought that one side isn't the "front", but rather you can travel in any direction the robot is capable of (which, for most skid steer robots, is one of two directions plus rotation).
Last year, for example, we could do a full field run to the HP station "backwards", then invert and do the whole run "forwards" to score. If driven correctly, our "back" was almost always to the opposing team, we always backed through stuff and came at it head on, since it was just faster to do it that way.
Way back in 2006, we collected from one side and shot out the other. Even further back in 2001, we had a totally invertable (front/back) robot with a claw on both sides that could work either way.
I just wanted to let you know that your Mecanum wheels are placed in the drawing wrong. Not that it makes a difference in the computer but it will play a huge role when build in reality! If you don't know the proper way (which there is only one way) message me and i will explain it to you.
The wheel modules are a separate assembly that was just placed into another assembly 4 times.
My team is planning on being able to pick up from all four sides.:D
I attached what we have in CAD so far!
How are you picking up balls?
Here's how our team is thinking of building a chassis that can do it. Still tweaking a lot, of course.
http://teamwork.saintsrobotics.com/attachment.php?aid=671
Aren Siekmeier
20-01-2012, 02:41
Oh ye of little faith in "adding complexity". You guys need to get out more and prototype it; the design itself isn't difficult with orthogonal conveyor belts. All of the complexity falls on the CAD mentor, and not it's in building a 2-sided conveyor but rather trying to figure out where the electronics board will go because the nice neat place that was there isn't there any more.
Deep breath, heavy sigh.
Cost benefit analysis... That is all.
The thinking is: Why build a heavier, more complicated robot (though marginally) robot when all you need to do is rotate 180º? Of course, the perceived values of each are up for debate - some may think it is worth the time/driver effort to have that extra intake - I don't. But we're hardly shying away from complexity. We're just trying to win.
As an aside, the complexity is beyond just designing it. You need to have an effective way to queue the balls coming in from both sides without jams or other issues, and perhaps take extra measures to keep a 4th ball out. Maybe you write some fancy code to do all this for you and keep matches running smoothly, but you had to write that code. So the question is always, is it worth it? Maybe having to change robot orientation will be a frequent necessity and thus a hindrance if you have only one intake. I am under the impression it will not be.
I should say that our team has made no official decision regarding this (as far as I know). I'm leaning towards a single intake, but the team may feel otherwise, based on predictions of game mechanics, etc.
It turns out that our double intake is the least of our worries, heh. What goes on top of it (after we've staged 2 balls vertically in it) is on iteration #4. That's three full conveyor/shooter systems I've CAD'ed in the wee hours that won't be used.
I think the fourth one's a keeper though. It's simple enough that there wasn't a single objection or criticism to the ball pathing sketch, and the part count is down by about half from the first conveyor, heh. It even looks like our electronic worries will become irrelevant and our secret for success is ... more flexible ... muahahahaha. (Car Nack here we come!)
Even with all the work, it feels like we're so far behind. The lower frame comes back from welding just tomorrow.
Here's how our team is thinking of building a chassis that can do it. Still tweaking a lot, of course.
http://teamwork.saintsrobotics.com/attachment.php?aid=671
cannot reach this link without a login. Saints? or sinners? ;)
The thing about rotating 180 degrees is that it sounds simple, but there are more complications to the rotating than there are to the translating to get to the ball. Other robots for one, rotating into the path of one in the wrong place could score for the other side. Also rotating and touching the ball before you're ready to pick it up will send it off in some other unreachable direction that is not likely to be part of your planned 180 degrees. Seeing a ball on my left side, I want to reach for it with my left hand instead of wheeling about to get the right hand into position.
Oh yeah sorry. I posted a pic up on pinypic now:
EDIT oops too big xD here we go
http://i40.tinypic.com/fvg1dw.png
To make big: http://oi44.tinypic.com/2vrvltw.jpg
Oh yeah sorry. I posted a pic up on pinypic now:
EDIT oops too big xD here we go
http://i40.tinypic.com/fvg1dw.png
To make big: http://oi44.tinypic.com/2vrvltw.jpg
What's going on with all those belts near the wheels?
What's going on with all those belts near the wheels?
Nothing... =p
That's just the drivetrain. 1: 49 reduction from CIM to wheel. The other sprocket on the outside of the mechanum wheels is a secret, though =p
mdiradoorian
20-01-2012, 20:42
It is a good idea but it is not really necessary because this year you can only hold up to three balls at once
Ben27Lacrosse
21-01-2012, 00:33
How are you picking up balls?
We plan on using systems of poly cord and as thay approach the center of the robot from all for sides turn to 4 vertical poly cord systems that will lead the balls to our shooter.
Aren Siekmeier
21-01-2012, 03:14
Nothing... =p
That's just the drivetrain. 1: 49 reduction from CIM to wheel. The other sprocket on the outside of the mechanum wheels is a secret, though =p
You may want to rethink having a reduction that high. At that reduction your top speed will end up at something like 3 ft/s (assuming 8 inch wheels) and actually less because they are mecanum (2ish maybe?). Something like 16:1 or less would be much more appropriate.
And I'm going to hazard a guess that you're planning on running a belt between the mecanums (mecana...? :P ) and riding over the bump like that? Unless it's a hefty belt I don't know if I would trust it with my robot's weight.
Thanks for pointing that out. 7" pulleys are waaaay too big. We will shrink them.
The belt between the mechanums will be supported by a rail. Of the two pulleys that this belt will ride on, one will be fixed to the axle, the other will be free spinning, so as to not force the belt to skip when the mechanums are spinning in opposite directions.
Rogue Leader
08-02-2012, 00:22
Oh yeah sorry. I posted a pic up on pinypic now:
EDIT oops too big xD here we go
http://i40.tinypic.com/fvg1dw.png
To make big: http://oi44.tinypic.com/2vrvltw.jpg
Looks beautiful! Those wheels down there look amazing!
And as for the OP, picking up from more than one side can result in accidental pickup of more balls than intended, leading to a foul (although by now you probably already decided on your pickup mechanism, just my two bits worth :p ).
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.