For Sack Attack, as with Gateway, we had a total of 7 weeks to complete a fully working robot for the REX tournament here in Maryland.
Our robot’s intake was originally based off of our alpha Gateway design, released here. It consisted of a single spinning vacuum cleaner beater-style roller. The roller would then pull the sacks onto a flat-laying ramp, where around 10 sacks would be stored. Then, the entire ramp & roller assembly would be lifted by an altered 4-bar, which would increase the angle of the ramp as it raised, allowing gravity to aid scoring.
The single roller intake was much like last year’s, in that once a couple game objects were collected, it would begin pulling game objects in, then right back out the top. To fix this, we added another sprocket, to sort of make a top-roller version of the “chainsaw” intakes last year. It worked well once we added polycarbonate sheeting as a guard to keep the sacks from getting caught in between the sprockets and the chain/tread. The intake is powered directly by two 393 motors.
Our drive, we decided would be a 6-wheel tank drive, geared 1:2 for speed with six 393 motors. All wheels are omni-wheels for the best traction and “climbing” performance, as our drive was high-riding to drive over top of the sacks.
The 4-bar is geared 9:1 via a compound gear ratio with two 393 motors and plenty of rubber bands. We’ve tested lifting 7 sacks and it has performed beautifully, but we have yet to test our goal of at least 10. In order to keep the gears from stripping, we had to add bar locks to hold the axles together in the center, between the two vertical metal bars. (shown below)
Our code was quite simple, but had one rather unique feature. Our drive function includes a look-up table for motor power, converting the motor control value-to-actual speed graph (graph supplied by jpearman here) to be linear, making the drive much easier to control in the low and mid-range speeds. It also makes it smoother overall.
So, we finally finished this robot at 5:30 AM Saturday morning, June 9th, for the tournament we’d be arriving at just two hours later, but it ended up performing well. Unfortunately, the one part of the robot we had issues with was the drive. It was not overheating, but instead was clicking due to the chain wrap being insufficient. We kept trying many different wraps and tightening chain to no avail. Eventually, the drive began to overheat because of how tight the chain was, even though it continued to skip.
After going 3-3-0, we finally decided to switch all the 6-tooth sprockets we were using on the output shafts to 12-tooth gears, giving us a 1:1 gear ratio, but making the chain wrap much better. A temporary fix, but it worked. We won our next match, and were 4-3-0, in 8th place going into the Elimination Rounds. (There were only 4 alliance captains at this tournament.)
In alliance selection, we were selected by the 2nd seeded team, 1727D, who then picked 929W. They both made a great alliance, and 929W was a very great find by 1727D; they actually ended up being the best team at that tournament, from my perspective. Our alliance went undefeated in the elimination rounds, and ended up winning the second Final match (which 929W competed in along with us) 176-6. I want to say thank you to both 1727D for picking us, and both 1727D and 929W for being such great alliance partners.
Saw the deisgn looks awesome as I have already told you but what you should do is post the pictures into a private facebook or google + album and it formats the pictures nicely to a uniform size for forum posting I found
We actually are not. Any sort of holonomic robot would most likely increase complexity and decrease strength/speed/our robot’s ability to drive over the sacks. Right now we plan on going back to 1:2, but with much better chain wrap.
We wanted to use all omni wheels because of the traction we’d get. Last year we had a dropped center high traction wheel, with omni wheels on the front and back. Whenever we’d be pushed from the side, we were practically immobile, because we’d start moving, and any driving we tried to do with our wheels would just make them spin because of the wheels skidding sideways. The omni wheels allow us to be pushed from the side, but still maintain full traction for maneuvering away from the pusher. We found that this “strategy” worked well.
I’m not sure of the exact angle of the ramp when we are scoring. It isn’t very great of one, and isn’t quite enough. Sometimes we would need to jolt forwards-backwards a bit with the drive to get the sacks to slide down the ramp to the tread so that we could score.
Yes, we are using ten 393 motors. It worked perfectly fine, and I didn’t notice hardly any times when we would trip breakers. When our drive chain was tightened crazily, sometimes it would stop working, but once we fixed it, no other problems ensued.
Also sorry, I messed up the links on the Wiki. I have fixed them now.
This was originally our main plan for this robot. Unfortunately, it did not work as well descoring. We could have cut the front bit off of the ramp, so that the rollers would hit the sacks first, and we could drop the tread down into the trough. We’ll be trying this soon, I hope.
Nice post and great pictures.
I’d love to see your code for re-linearization, if you’d be willing to post it, or PM it.
you didn’t say if your 6x393 wheel motors are geared for torque(100rpm) or speed.
If torque, then nominal (vexchart) wheelspeed is about 3.48 fps at 200%.
Here are some brainstorms to address chain tension:
use the speed internal motor gearing, and smaller sprocket ratio
us larger wheel sprockets to reduce the chain tension; 24:18 or 18:12 maybe, instead of your current 12:6
have each motor drive each wheel independently to get 180 degree chain wrap, then use other chains to tie each pair of wheels together also.
maybe move one motor to power the top of the loop also?
Consider that when doing a sudden start forward from stopped position,
weight shifts to back wheel, yet back wheel has the longest chain loop to get to a motor sprocket.
Have you ever tested high traction with nonslip vs Omni wheels? Or High Traction with zipties? I’ve never done it with drivetrains but i think last year in frc, surface contact resulted in greater force on the balls, so it might lead into greater traction (can someone confirm/correct me). I don’t think the thickness of the padding is enough to lift the robot back/front wheels off the ground when you apply sinking from the field tiles.
I was thinking that if you added high traction, you would have some resistance to defense. that way, you could score your pieces without wasting time from fending off defense.
What are your current plans with fixing that issue? The robot i’m designing is similar, but im still worried about that same jamming. Currently my specs say somewhere between 37 to 41 degrees.
Yes, the 393 motors are all in their factory-setting, geared internally for torque with a 100rpm output.
Thanks for the suggestions! We were originally thinking about larger sprockets, but we very much wanted a 1:2, and would rather not have to change the internal gearing of the 393 motors, if possible.
Right now we are working on redesigning our drive such that all the motors are clustered in the back of the robot on either side, with a much better chain wrap around the sprockets. This will allow us to have a wider intake, as well.
I’m not exactly sure, we haven’t tried adding things to the outsides of the wheels much. I actually like the effect of having all omni wheels. It allows easy almost-holonomic ability on the wall, adding extra sideways motion as we try to maneuver a bit, which is sort of helpful when both collecting along the wall and when scoring along the troughs.
Simply increasing the angle, most likely. Hopefully only increasing the amount which it increases when we raise, but keep it rather flat when on the ground for collecting.
Thanks. Yes, the intake tank tread does have rubber bands pulling it down to add pressure, but when collecting it can angle to accommodate large amounts at a time and/or the changing shape of the sacks.
Thanks for answering that question; yes, our capacity is around 10, but I’ll have to see how many it can actually hold and/or lift. Also, yes, we usually gathered around 4-6 sacks before we would go to score. This was because at that point, the metal on the bottom of our ramp, towards the front would start to drag on the tiles and would make it difficult to drive around to collect any more.
When plotted, it looks like a sag vs linear, which will counteract the bump vs linear of the MC#29 transfer function. Table lookup should be fast in EasyC, and appropriately moves calculating the table into compile time, rather than run time.
I imagine the code is something like this (untested pseudocode)
X = GetJoyStickAnalog;
X = abs(X) <= 127 ? X : 127 * SGN(X); // limit to +/-127 with trinary like jpearman (I think)
Xlinear = SGN(X) * TrueSpeed[X];
If RobotC has array size limitations less than 128, they may have to come up with a different method.