5485 Sack Attack Robot

This is my team’s 2nd year in Vex Robotics Competition. Last year, we competed as 5088A and were finalists at the Southern Arizona Regional. Now we have a new robot! We love it very much. More details below the photos:

Pre-match position.

Arm down, intake deployed.

Ready to score imaginary sacks in imaginary trough.

6 high-speed 393 motors directly driving 6 4" wheels, 4 omni, and 2 traction: Very fast and can drive over sacks well. Has encoders and gyro for autonomous awesomeness.

2x 393 motors, assisted by stretched latex tubing, powering 4-bar arm with potentiometer-based closed loop control. Can quickly lift 5+ sacks to trough.

Intake folds down at beginning of match. Quickly picks up and dumps 4-6 sacks.

At a scrimmage that we attended with the previous iteration of this robot, all of our match scores were over 100.

Questions? Comments? Suggestions?

You should have another bar to support the axles on the wheels so it doesn’t bend.

To elaborate on Kyub’s point, you’re currently cantilevering your wheels, meaning you’re only supporting them on one side. You should look to add another piece of metal on the other side of the wheels for your axles to go through.

You also seem to have a very fast gear ratio on your intake rollers. but the mechanism also seems to be a secondary intake device after your polycarbonate shovel does most of the work.

Nice robot overall!

That being said, the axles are supported at two points in between the motor and the wheel - so the axles won’t deflect or move about their axis that much, although supporting on both sides is generally a favored option.

Other than that, the best advice I can give is test test test. All of the successful teams I know do well because their robot has played literally hundreds of matches, and so they have the time to work out all of the kinks and make minor improvements as time goes on.

Best of luck with the season!


We did consider supporting the wheels on both sides by putting them between the bar with the motors and the one right next to the wheels. We decided against it for two reasons: First, since the axles are well supported and the wheels are very close to the support, the bending force isn’t very high, and we haven’t observed any problems with the shafts bending. Second, it would have rather complicated to redesign the drivetrain, particularly stand-off placement, since we would need to have 3 4" wheels completely enclosed by 12.5" metal beams. Since we would have needed a complicated solution to something that is almost not a problem, we decided against making changes.

Regarding practice, we have spent most of the last few meetings driving the robot around and practicing scoring in our trough. We will soon have a second somewhat simpler practice robot built so we can work on driving with defense. We will definitely continue to practice and test over the next few weeks.

More updates:
Our team is attending the Skills Challenge event in Sahuarita on December 1st. Therefore, I have been busy with the programming skills code. I’ve written all the basic functions (drive, turn) and tonight, in about an hour, wrote code that quickly scored the 5 match loads and 3 sacks from under the trough. I’m surprised about the lowness of the world Programming Skills high score (110), and think that my team has a good shot at beating it. We’ll see if that can happen…

We have also decided to upgrade last year’s robot, which we modified and used for practice, into a fully competition-ready robot, which will be entered into two Arizona events (not the Skills Challenge) as 5088A. We have started making changes, but are waiting for some part orders.

Just wait until the Asia Pacific…:wink:

I’ll just say that 1492X scored a lot more than 65 at home…

The 45-point autonomous that I just described is just the first part of our programming skills…

Sweet, I can tell that programming skills is going to be highly contested this year. There are a lot of sacks on a good set of lines very close to the troughs. Do you plan to go across the trough or score the high goal?

Since there’s a big worry about bending your axles, you can probably add unpowered omni wheels in the center of your drivetrain like slide/H drive. With this addition, your polygon of support should remain flat, your cob will probably move forward, and without bowing, you’ll probably have a more effective use of motors.

this may create a new problem of catching onto sacks. Which may or may not, depending on your view, be far-fetched. Whenever your intake is down, you will never have a problem assuming that sacks do not pass under your intake. However, then it’s up, that’s when you’ll have the problem. However, its also safe to assume that sacks will never be in front of you when your intake is raised because that would mean that you already grabbed sacks that are in front of you. Now this could be different if you plan to score on the high goal at the start of the match(but from the looks of the arm, it cant reach that height)

After thinking about the best way to play the game, our team decided not to worry about scoring in the high goal. To reach the high goal, we would have had to design and build a heavier, less reliable, and more complicated arm. In addition, the high goal can comfortably hold only 2-3 sacks, based on the match videos that I’ve watched, and is relatively easy to descore. A sack in the high goal is worth 5 points more than one in the trough. Therefore, to offset any loss of points by not scoring in the high goal, it is only necessary to score about three additional sacks in the trough, less than one normal intake-load for us. I believe that it is possible for us to do even better than 3 extra sacks because we don’t have to deal with a cumbersome high-goal scoring mechanism. I also believe that the time it would take to design and build this device could be better spent on software work and driver practice.

So yes, as was subtly mentioned in my above rant, our robot is not designed to score in the high goal. :slight_smile:

Regarding drivetrain, I realize that cantilevered wheels are not the best option, but in my opinion, “If it ain’t broke, don’t fix it.” We have not had any problems related to cantilevered wheels, either on this year’s robot, or on last year’s, which had a very similar drivetrain design, although with four wheels. Our team did consider an omnidirectional drivertrain, although using Mecanum wheels. We decided against it because we thought that the additional power available to forward-backward movement offset the advantages of being able to move sideways. Currently, we have 6 HS 393 motors on our drive, more motors than most other teams. This very powerful drive arrangement allows us to move faster and push harder than almost everyone else. This is an advantage that we don’t want to give up. Also, as DracoTheDragon pointed out, having a slide drivetrain would compromise our ability to quickly drive over sacks.

More robot progress:

Here’s a photo of our robot testing autonomous code.

Our team is attending a Skills Challenge event on 12-1-12, so we are busy getting all the software ready. We added some new sensors: a line tracker to complement the gyro/ encoder dead reckoning, and an encoder on the intake to detect when it is jammed. We have also spent many hours perfecting the autonomous software (Tuning PID ;)). Hopefully our robot will be good at doing interesting things by Saturday. After the event, I’ll try to get some video up.

Well, we got 2nd for Robot skills by 5 points and, we got 3rd in program skills because of the field elements.

How much did you score?

Official 1st and 2nd place scores at the Sahuarita Skills Challenge yesterday were 140 by 1471A (me) in robot skills and 130 by 5485 in robot skills. I believe programming skills was 88 by 2114A and 57 by team 52.

Luther, what was your complaint about the field elements?

old_luther’s was complaining about the practice field. Because it did not have troughs, we were unable to test our autonomous on a field with troughs. Therefore, on 2 of our programming skills runs, we ran into troughs. The other problem we had with programming skills is with our software. Since we did not smoothly ramp up speed, our robot was somewhat inaccurate in autonomous, as we had an annoying tendency to do wheelies to the detriment of the encoder and gyro readings. Version 2 of the software is in the works and should hopefully be ready by our next competition on December 15.

My FRC team, the Bit Buckets, has decided to enter a second robot in this competition as 5088A. This robot will share the same arm and drivetrain, but instead of 5485’s roller intake, it will have an adjustable-angle Lexan spatula with closed-loop potentiometer control. It will also lack 5485’s gyroscope. I expect that it will be slightly less effective at scoring than 5485, but able to descore quite well.

No offense to you guys, but it is highly unreasonable to blame the lack of a practice field for your autonomous not working. If you want your program to work you need to get it done ahead of the competition like other teams do.

The views expressed in old_luther’s post do not represent the opinions of the whole team. They are from a person not involved in software development. Anyway, we had written the software before competition, but had had no opportunity to test it on a field until the competition.

In his defense, coding almost always needs calibration, no matter how much preparation work you do. Field conditions and robot conditions can and will change between home and competition.