top of page

Week 10/11 Update: A Whole New Intake and Lift System + Tele-op Code

  • Writer: Batteries Not Included
    Batteries Not Included
  • Dec 9, 2021
  • 10 min read

This'll be a combined blog post for the past two weeks. We've been an extremely busy team over the past few weeks, and I'm just now getting the chance to write this post.


By the title, and from the last blog post, you can probably figure out what this post is about: We ditched the claw and lift idea for our robot almost immediately after our qualification meet a few weeks ago. The design wasn't exactly a total failure, but it was certainly not the most efficient way to move the freight around. With our redesign, we are going to use a lever arm and a bucket to lift and dump the freight pieces into the shipping hub. If you don't know exactly what I mean, check out our last blog post.


Over the past few weeks, there have been a couple of things we've been doing: building this new arm and bucket thing, and working on a new tele-op program and a rough autonomous program. I'll walk you through what exactly we did.


First thing's first, we built the design for the bucket, intake, and arm that we told you about in our last blog post. Building the arm wasn't too much of a challenge. We slapped a couple of c-channel extrusions together and created a pivot in the middle. We stuck this exactly where our lift was, on top of the giant rotating platform/gear thing. Pretty easy, especially compered to the lift design we had last time!

Putting the arm together

Complete arm with intake and bucket attached


The hardest part, by far was getting the right gear ratio for our motor to lift this big, heavy arm. The motors we use only have gearboxes up to a 60:1 ratio, which, for the amount of weight we were lifting on this arm (we have another motor and a servo on the end of the arm) was not enough torque. We spent a couple days toying around with different sprocket ratios between the motor and the shaft that spins to lift the arm. We ultimately ended up with a 15T sprocket on the motor and a 40T sprocket on the pivot of the arm, and this is just barely enough power to lift the arm and still stay in our 18-inch dimensions. It's not a significant improvement in our ratio overall, but it works better than the 60:1 on the original motor.

Our sprocket and chain ratio from the motor (bottom) to the arm (top)


Now, to the claw, I mean bucket. (There's so many changes, I can't keep track!) This is where the creativity took off. Our first initial problem with a plexiglass bucket was that we can't really make plexiglass bend to form the walls and sides of a bucket. We had plenty of plexiglass, but not the resources to manipulate it properly. One of our team members had the idea to use a baseball case (you know, the ones you use to store the baseballs you get signed by famous players and keep the dust off of them) to build this bucket. We didn't use anything fancy in terms of the case we bought, but we had to make some modifications right off the bat.


First modification: more sides. The case we bought only had three of the six faces of a cube, all adjoining, and in a sort of U-shape. We needed really, about four and half faces. Let me explain. For our bucket design, we needed to have one completely open face to let the freight in and out. We had that one covered, but we needed a face that was slightly longer than the square side of the bucket on the face directly below it (I'll put a picture below, because this is really hard to describe). On the face opposite of the long one, we needed one that was slightly shorter (by about 1/4 inch) so that our intake spinners wouldn't hit it. The back and vertical sides of the bucket are part of the original baseball case.

Our bucket with a short side on top (covered in black tape) and a long side on the bottom


And now how we put this complicated little bucket onto our arm that we built. The bucket is attached to a short extrusion on the back to a servo on the end of the arm. This servo is super important in keeping the bucket upright while we are lifting the arm, and then dumping the bucket and the freight when the arm is at the right height. There's nothing worse than dumping out our freight before we are in a position to score, so this servo is going to help eliminate that potential.


Last thing: intake. In our last blog post, I said we'd attach some wheels with bendy, silicone spikes that will push the freight into the bucket and attach them directly to the bucket. Turns out, the bucket was too small to attach them directly to the bucket. This got us debating back and forth for about a week on how to attach these little intake wheels. The first proposal was to have the intake attached directly to the chassis so that we could just lower the bucket down and have the intake slide the freight on the floor and into the bucket. It sounded like it would work at first, but after a little prototyping (and by prototyping, I mean holding up different pieces to the robot to see how they would go together, we realized this configuration wouldn't work because it would block the arm and bucket from lifting upward, which was kind of critical to our design. So we scratched the idea of attaching the intake to the drivetrain. The other idea that we bounced around (and the one we ultimately went for) was to attach the intake to a freely swinging extrusion with a motor. This extrusion is able to swing up and bounce a little so that the freight can slide underneath and into the bucket. The freely swinging part is so that the intake flips up and out of the way of the bucket when it goes to dump out the freight. The intake is powered by a motor. We did have to make some creative modifications to our intake wheels that we purchased. We duck taped some short shafts onto the ends to make them a little longer. The silicone on the part closer to the axis allows it to still flex when it's pushing a piece of freight.

Some initial sketches of intake designs

The intake folded on the arm to help us fit in 18-inches

The intake in the down position and ready to put freight in the bucket

Our modified intake wheels (ft. duck tape!!!)

Testing out or modified intake wheels before mounting them on the robot


Well, that wasn't really the last thing, there's one more thing our hardware team did, and then I'll tell you about something that doesn't get mentioned a whole lot on the blog: software.


This isn't a major change, but we added a small chain and some sprockets to our carousel spinner to make it spin a little faster. We didn't have problems with the carousel working, per se, during our meet, but it wasn't particularly efficient. We didn't want to attach the spinner to a full-blown motor, though. There is a sweet spot between spinning the carousel fast and spinning too fast. If you spin it too fast, the ducks fly off the outside, and you aren't able to score those points. We created about a 2:1 ratio between our servo and wheels that spin the carousel. It's not a super intuitive change or anything major, but it's worth mentioning.

New sprocket ratio between our servo (right) and the wheels that spin the carousel (left)


And now, PROGRAMMING!

It's been a neglected topic on the blog, and trust me, we know. But there hasn't been much to talk about, if I'm being honest. Our first robot design (with the claw and lift and everything) was just a program of spinning motors one way or another and adding limits on only a few motors (like the one powering the lift and on the servos). Now we have a more complicated program that's worth sharing, including a rough autonomous program (We haven't tested autonomous yet though!).


I don't want to spoil all our team's secrets for autonomous, so I'll just go through what our tele-op program has so far and save autonomous for the next blog post when we've actually tested it out!


We have two drivers for our team and two controllers. One drives the robot (operates the wheels and drivetrain) and one controls the arm, bucket, etc. (except the carousel spinner; we had to put that one on the drivetrain controller because we ran out of buttons on the other one)


The drivetrain controller is fairly simple. The joysticks on either side of the controller correspond to the wheels on either side of the robot. Pushing both forward moves the robot forward and pushing them both backwards moves the robot backwards. Pushing one forwards and one backwards spins the robot one way and flipping them spins the robot the other way. The two bumpers at the top of the controller turn the carousel spinner in different directions, so that we can turn both the blue and red carousels with the same spinner.


The arm/bucket controller is a little more complicated. After some insane amount of testing on the part of our programmers, we created preset settings for the arm and bucket to lift to the correct height and then dump out the freight. There are four settings for the arm height: down/intake, level 2 of the shipping hub, level 3 of the shipping hub, and as high as possible. Each of these is controlled by the click of the A, B, X, or Y button (I don't remember which goes with which button, but you get the idea). The down/intake setting is pretty self-explanatory; it move the arm all the way down and straightens out the servo and bucket so it's ready to intake. The level 2 setting moves the arm up to the right height to score on the level 2 of the shipping hub (this one can also be used to score on the shared shipping hub), and, likewise, the level 3 setting moves the arm up to the top level of the shipping hub. The last setting puts the arm in an almost vertical position so that the drivers can avoid the post on the shipping hub if they need to position themselves to score. The down arrow button sets the bucket to a position to dump the freight out and the up arrow button sets the bucket to the upright, non-dumping position. The two bumpers turn the intake wheels in either direction when they're held down. Last control: the joystick. Moving the right joystick left or right turns the arm platform left or right to score from any position relative to the robot. There's a lot more buttons on this controller, but our drivers have it all down to muscle memory at this point. Hopefully they'll get some more practice in before our next meet!

Testing for different positions for the arm in tele-op

First round of complete testing for tele-op with our drivers!


Since we've been lacking on programming and software updates in the blog posts, here is a special update and some important reminders from our lead programmer on our team:


STARTING WITH PROGRAMMING

USING ANDROID STUDIO - Our team uses Android Studio for programming our robot. There are plenty of resources available online teaching how to use this application, and many teams have posted their code publicly to allow others to learn from existing code.

  • We’ve found that Android Studio’s ability to integrate libraries such as OpenCV is extremely helpful. Our team uses the Logitech Webcam to detect different things during autonomous (such as the position of the duck or team element on the barcode during this year’s autonomous) with the help of OpenCV. While it was difficult initially to incorporate such a library, many people use this method, so there are many resources available to learn from.

  • Android Studio also automatically detects any errors before the build is even executed, which makes it a lot easier to debug!

  • We’re also able to use GitHub so that our programmers can easily share code and work on it together. Make sure you’re always communicating within your software team though so everyone’s on the same page, especially if you only have a free account under GitHub. You don’t want anyone pushing code that overwrites previous ones without complete approval from the rest of the team!

  • The FTC SDK is updated every season. Make sure to download it each year. It also provides sample codes of different functions in both autonomous and tele-op; if you’re just starting off programming, definitely go through these, they’ll be extremely helpful.

TIPS FOR PROGRAMMING - We encountered many issues while programming. Here are some tips to keep in mind!

  • COMMENTS COMMENTS COMMENTS. This helps keep your code organized and easy to understand by anyone who may want to view it. Also, instead of just deleting an entire section of your code whenever you need to test things out, just comment it out in case you want to go back to it.

  • TELEMETRY IS YOUR FRIEND. The ability to display data while the robot is running is immensely helpful in debugging your code and determining needed positions.

  • BEWARE SERVOS. If using REV servos, you need to use the SRS programmer to set whether you want it to be a continuous rotation servo or one with angular limits. We spent hours trying to set limits to a servo through the code only to realize the mode could only be changed with the SRS programmer! Also, the servos’ positions are fixed, so make sure your servo can move the desired path before mounting it to your robot. You can do this by programming the servo to go to certain positions before mounting it. This way, you won’t have to take it off, reposition, then put it back on, which we learned is a huge hassle!

  • THE INTERNET EXISTS. Anytime you have a problem or error, it's likely someone else has had that same problem too. Search it up on the internet, and if you can’t find an answer, try asking your question on an online forum (there’s specifically FTC forums, too) or on the FTC discord. There will always be someone happy to help!

  • HARDWARE HELP. Sometimes, your hardware may be at fault, not the program.

  • CHARGE YOUR THINGS. There have been way too many times where we’re about to modify the program or drive the robot only to find that the driver hub’s at 5% or the batteries are all dead.


Well, that's all the information for this blog post. I know it was really, really long! We have one more week before our second qualification meet and we hope to be able to perfect our driver's skills and debug any code or hardware issue that pop up in these last few days. There will be one more blog post before our meet recap post, so look out for that later in the week!


Side note: our schedule is getting kind of crazy now that our league has started competitions, so blog posts may be more and more sporadic and not strictly to our weekly schedule, though we will try to post at least once a week!

Comments


bottom of page