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.
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.
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.
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.
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.
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.
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.
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.
