Nothing too exotic about it. Two VexPro ball shifters, #25 chain drive, dead axle, 6in colson wheels, standardized 10-32 hardware as much as practical. We also tried to use as many OTS parts as possible, like the hex standoffs, dead axles, sprockets, and a few other little bits.
The side plates on the drive pods were all cut out on our CNC plasma cutter. “Just wing’in it” our tolerances were garbage… typically -0.03in. With a good setup, fine-cut consumables, and a little more experience we were landing between +/- 0.010 and 0.005in tolerance.
Two of the drive plates were cut out completely on the plasma cutter, then cleaned up by hand. Two were profiled by the CNC plasma cutter and then all of the holes and slots were milled by a proto-trak CNC knee mill. All things considered it was about the same total time to do both, but the milled parts came out a little nicer. Still though, if you gotta knock out a lot of parts, it’s REALLY hard to beat 100ipm single pass to cut out 1/8in aluminum plate.
Our most ambitious pre-season project yet, and it turned out pretty well. The ultimate goal, which is still in-process, is to have PID drive control with automatic shifting.
Some really nice features I can spy. Loving the cutout on the gearboxes to get them out of the chassis easily along with the slots on the wheels for tensioning. Looks like it can tackle crossing a bump or two. Seems a little lean on the crossbeams for competition but for an off-season robot it looks awesome!
Any ideas on how much it weighs?
Tolerances can be annoying. Last season we got our first taste of sending out parts to be made and soon learned if you need a hole drilled, add some wiggle room so you don’t have to drill every hole out by hand when it comes time for assembly! :o
Hello, I am Daroc Alden.
My coach requested that everyone create an introductory post here, so here I am. I didn’t work on the drive base itself, as I programmed the preseason robot. It is pretty simple; it just puts the right and left sticks directly into tank drive and uses the encoders to automatically shift gears. We’re using java and the iterative robot template, so a lot of the work was done for us.
What is the flex like in that chassis? Just looking at how it has no supports up the middle, it seems like it would flex rather easily.
Edit:: I did not see the plate for the electronics before (I was only looking at the top picture). Does that work well as a middle support? (I am assuming so, at it is a big, flat plate plate, but weight-wise how is it?)
The thoughts on chassis rigidity would be to do a really good job of tying in the bumper plywood to the chassis and use it structurally reinforce the chassis on a competition bot, and/or just add more standoffs.
Not sure on weight… but the side plates are 1/8in, so it’s not too bad.
Flex is pretty well controlled as far as we can tell… but more testing is in order.
The ‘belly-pan’ works very well to connect everything together and provide good chassis stiffness. Right now it’s a ~3/16in thick aluminum plate, so very stiff, but huge overkill and a bit heavier than it needs to be IMO.
Don’t sell yourself short – as I’m fond of saying, without programmers, robots would just be expensive paperweights.
What was your thought process behind your autoshifting algorithm? Are you using the encoders to predict the current draw of the motors, and trying to minimize that, or are you trying to maximize your acceleration?
I definitely agree with Brendan… I really love the slots over the Transmission shafts so you can just lift the gearbox right out (rather than pulling it through the center). I also like how narrow your pods/drive channels are… especially with the smaller frame perimeter rules, that can be a big gain!
I have to say, I’m sure you could get some big weight savings if you were to re-iterate this for the build season… going to 4" or 5" wheels (smaller wheels, smaller sprockets), making your drive channel plates shorter (perhaps 3-4" tall rather than 5-6" tall), and obviously doing some lightening on the belly pan… you could probably save 5-10 pounds fairly easily!
I’d definitely guess that you’d want more tying the two pods/drive channels to each other for stiffness… but I guess with giant bellypan may go a long way…
The control algorithim will look at speed and joystick input ‘magnitude’ and make a gear selection from there, like an automotive automatic transmission controller. If you’re lightly on the accelerator pedal the transmission will up-shift very readily to reduce fuel consumption, but if you floor the accelerator pedal the transmission will downshift as many gears as it can to maximize acceleration.
Now, this is somewhat simplified with only 2 gears, but that’s the idea!
Very good suggestions, thanks! We definitely plan on iterating this design, though since we’re really hurting for funding this year (government lab as flagship sponsor + sequester = sad robotics team) we’ll likely recycle the 6in components. The main weight-loss strategy will be ‘trussing out’ the side plates. Hopefully that will make them look a little sexier as well as reducing weight. That, and making the belly pan out of plastic instead of aluminum!
Upon further consideration I think that for a competition robot we would mount all of our game-related mechanisms to a plate that bolts on top of the drive base. This would potentially make game mechanisms modular and divorce the drive base design from the manipulator design, allowing them to be developed independantly. A top plate, coupled with the belly pan and bumper panels, would result in a VERY strong chassis structure.
And, frankly, bumpers have really reduced chassis strength requirements… hitting robots at full-speed just isn’t what it used to be!
We have a CNC router in our shop that lends itself well to building “side-plates + stand-offs” drivetrains. They’re straightforward enough for younger students to design. To machine, just throw a big sheet of plate on the CNC router, and cut 4 identical side-plates out of it in one setup. Dead-axle means you can use bolts as shafts, and the precision is moved to the wheels, bearings, sprockets, all which you can just buy. It’s very forgiving, and is one of the most student-design friendly non-KoP drive setups around.
In fact, I think every single one of 610’s “best” student designers have designed a 6wd “side-plates + stand-offs” drivetrain during their time on the team. It’s pretty common to hear a mentor tell a student:
“You want to design WHAT? Design me a simple 6wd side-plates + stand-offs drivetrain first… then we’ll talk.”
Not only that, they’ve worked wonderfully for us on the field for the past two years. Aside from chain that stretches over time, carpet bits getting stuck in the sprockets, and wheel wear, they’ve been pretty solid for us.
I love seeing how other teams approach these same drivetrains. We’ve “gained inspiration” from a lot of other teams designs, and used them to improve our own on many occasions. I like your cut-outs for installing/removing your gearboxes.
A lot of the suggestions you’re getting in this thread are identical to the ones we’ve fought with over the years. If you’re curious to see our version of the “side-plates + stand-offs” drivetrain, we had one on our 2013 robot:
Picture w/ Electronics:
Some of the little tricks that went into it:
CADs:
Thanks for sharing, and hopefully we’ll cross paths again sometime! Competing at BAE was an amazing experience last year!
This was our first non-KOP design in several years, and thus the first in several years with heavy student involvement. It was partly inspired by 610’s 2013 chassis (hat tip) and a 2011 chassis from a NJ team with two a two-digit number that I can’t, for the life of me, recall.
I really like the cable+tube handles, I definitely want to use them in the upcoming season.
GSR was a blast, I just wish our climber had been working as well as it did at CT…
Quick questions: are your side plates 1/4in? And what did that chassis wind up weighing?
Thanks for the hat-tip! But we certainly didn’t invent the side-plates + stand-offs drivetrain, nor have we perfected it. One of the examples we show our students is one of 548’s from a few years ago:
Our drivetrain was quite heavy by most people’s standards. I want to say that everything in the Electronics Board picture was over 60 lbs (not including battery).
That’s working off a weak memory, although if I made an egregious error, my hope is someone from the team can chime in and correct me.
Hello I’m Grayson! On this project I helped out a little bit with a lot of different parts, including machining, CADing, and assembly. My main contribution was putting together most of the left (I think) drive pod and doing the chains (which took me longer than I care to admit )
As far as controlling that setup with a PID, I would use two separate PIDs for each side of the drive train, and control them via speed. Also, because you will be changing the setpoint a lot, I’d remove the derivative term from the equation, because that’s just going to provide a large unintended movement every time you quickly move the joysticks.
Also, be sure to reset your integral term every time target speed = 0 and current speed = 0 (or close to it), or else after a bit of driving your robot, it will begin to overshoot your speed every time.
As far as gear changes go, I’d have it default to low gear and if speed >= n ft/s, shift to high gear, and change the PI controller values, and joystick_input_to_target_speed_conversion algorithm accordingly.
And that’s not to say you can’t use a position mode during autonomous, but for teleop, that becomes very weird because you need to integrate change in distance based on the joystick values, which will tend to lead to a lot of overshoot.
Actually, after thing about it, what I said probably would not work well at all, mainly because PID controllers don’t work well when using speed as a set-point for something that isn’t a flywheel.
However, you may be able to do something like this.(pardon my python-esque syntax, I’m not a C++ or Java programmer)
c is a constant set to make the robot not try to turn at say 13.5FPS at full turn.
)