The OMG only 2 weeks to competition update
Hi folks, it’s been a while! So, the key phrase for our last couple of weeks is “chasing down the gremlins”, which is a part of the design process we all know and love…right? Yeah! Once you get a robot all built, then you get to see all of its major flaws and fix them. Sometimes, it’s a small quick fix, sometimes it’s a larger one, but they all need to be done! * knocking heavily on wood * I’m hopeful we’ve managed all the major gremlins on the robot at this point.
For reference, here’s a picture of our robot as it sits now:
While it is 98% complete, we’re still fixing up some issues here and there while allowing our programmers time to dial in the code and getting some drive practice when we can.
Gremlin 1: Intake actuation (a.k.a. slamming the intake into the floor)
This one showed up quick. While we tried to lighten the intake as much as possible, we really needed it to glide on the carpet, which means placing the intake onto the concrete floor. We learned when you do this quickly with pneumatics, the results can be…unnerving to say the least. I winced each time it hit the floor. After enough times of this, we actually cracked and fractured the 1/4" polycarbonate. It was at that moment we knew we had to make a change. We went from this:
To this:
Instead of using a 4-bar pneumatic linkage, we’re now using a combination between non-pivoting pneumatics and a winch. We reasoned that we can use a trapezoidal motion profile on a winch to ease the intake onto the floor, and the pneumatics are only there to move the intake off of top dead center to deploy it. Both are using nylon straps. The winch uses a 1" nylon strap on a 3" diameter 3D-printed spool, and the pneumatics use a simple 3/4" strap sewn around a 1/4" steel shaft held by the piston clevises. It slides through a UHMW pivot and pulls the intake about 60 degrees, at which point it falls slack.
In all, it took us about 1.5 work sessions to get this in place. Our CNC manufacturing capabilities have been excellent this year! We generally never wait more than 1/2 of a session for new parts!
Gremlin 2: Arm rotation
The first surprise we got when we get the robot all together was our belt system for the arm rotation. We had plenty of torque, but we were still slipping belts right off of the gearbox at the bottom. We added some tensioner posts for the belts, but still had some issues, so we switched out the belt for #25H chain and sprockets and added more UHMW tensioner posts to keep everything snug and happy. We further ran into some more problems with even the chain skipping some teeth, and when we found a high-friction handoff issue (more on that below), we pushed a bit too hard and snapped our chain! Since then, we’ve shored things up a bit more, added an extra bearing for the maxplanetary shaft, and we plan on ordering #35 chain and sprockets to swap out if we need to.
Gremlin 3: Arm Extension
Just like the rotation, the extension was also skipping some HTD5 teeth just because of the longer belt runs and higher torque situation. So we switched these out with chain as well just to be safe. The 15mm HTD5 belt for the actual arm extension remains, however, and we’ve had some issues with skipping teeth in the last 8 inches of travel as the UHMW slides get closer. This especially happens when we have a cone loaded due to the extra weight. We are mitigating this by 3D printing a belt tensioning system where we can use 1/4"-20 screws to tighten the two ends of the open belt together, and also we added a 1/4" shaft with a small UHMW roller on it that goes right up next to the drive pulley for the extension for extra tension and wrap on the drive.
Gremlin 4 The hand-off
We knew this could be a tricky one. Handing off game pieces from the intake to the claw is an operation that requires accuracy and fairly close engineering tolerances.
First issue we found was that top bar of the intake we originally used for pneumatics and then used for our winch pull point? It was too high and interfered with the claw. We could have made it work, but we would have had to rotate our arm out of the robot and synchronize it with the intake coming in when we pick up. Instead, we opted to just chop off the top extension of the intake and mount that pull bar lower. That helped a lot.
Second issue was that the open part of the claw was sagging a bit and the tip of the cone would hit it as it entered. After looking at this and wondering for longer than I should have, I remembered that we had the dogbones in the wrist to change as needed. With extending the dogbone links only 1/4" (really!) the claw pivots up and out of the way, clearing the tip of the cone by at least 2 inches.
Bonus gifts from the intake gremlin!
Fixing our intake pneumatics gremlin and adding a winch instead allowed us a few other benefits:
-
We can rotate the intake out slightly to ease the exit of the cone base as we lift it out with the claw.
-
We can score in the hybrid nodes even easier just by rotating out the intake a little and reversing it.
-
We gain the ability to tilt our intake up and receive a cone or cube from the single substation ramp as a kind of hopper setup. But we will probably still primarily take from the floor as we think it will be faster. We will definitely test both though.
-
Shooting cubes?? We had to try it out:
Success! And for the high?
Not quite as solid, but possible. We think we could ensure our success on this a bit more by switching the 775s to NEO 550s as they have a bit higher stall torque. We may get around to that before our first competition if we have time. We’re not pursuing shooting cubes as a primary method of scoring, but we may incorporate it into auto modes, where we have more control of the inflation level of the cubes we use. We may also set our mid-cube scoring to shooting if we can get that one reliable enough, and just use the arm to place them high.
Control System Updates
Our programmers have finally been getting to run their code on our mechanisms, and it’s actually been going fairly smooth. I don’t know if we’ll have as much time to automate as we want, but we’ll definitely have vision-based scoring commands for all 6 possibilities (mid/high/low and cube/cone). That’s our baseline. From there, we’ll have our most basic auto mode score a cone and then go balance on the charge station. After that, we’ll get into the more interesting stuff:
-
We’re going to plan on 3 “convergence points” in the community, one in front of each april tag. We’ll be able to run a single command to score on any of the 27 nodes from any of these 3 “convergence points”.
-
We’re going to map multiple “entry points” on the edges of the community. We’ll use PathPlanner to map a path from each of these “entry points” to one of the 3 “convergence points”
-
The driver will be able to hold a shoulder button as they enter the community area. When we get close enough to one of the “entry points”, we will have the robot take over and run the path to the “convergence point” and then go score on the selected target node.
How do we determine which node to go to? Let me introduce you to our grid button array:
This uses the Adafruit NeoKey 5x6 array, modified to a 9x3 array, each key is RGB lit and yes, it has the clicky keys. This will be the centerpiece of our new button board this year:
The quick rundown of how this works in software, is it uses our existing Arduino USB JSON code we made for sensors, interfaced with a Java console app running on the Driver Station, which sends data between NetworkTables and the Arduino over USB serial. We send a target row and column to the robot via NetworkTables, and that’s how it knows where to score. Will we complete this all before Heartland in 1.5 weeks from now? Not sure, but I bet we do before Tulsa in 3 weeks after that!
From the department of extra software, we’ve also been working on some grid game piece tracking. It’s a bit tricky because it requires a color global shutter camera, which are hard to come by. But we’ve got some code working where we believe we’ll be able to see which nodes have already been scored and which ones haven’t. We’re just using a Raspberry Pi 4 with WPILibPi and AprilTags library in Python for this. From there, we send a grid over NetworkTables. The robot doesn’t read this, but the driver station sends it over to the button board and the grid buttons light up yellow or purple as is appropriate. We’re mounting two cameras front and back to get the best view of the grid for this, and we’ll also be using this setup for our pose estimation corrections.
Other than that, we’ve been working on our existing drive station case to make sure it’s all ready for the season.
The pit crew are finally turning their attention to setting up the pit for competition, and our fabrication team is churning out spare parts. We started our drive practice last week and our goal is to have drive practice every day from now until competition, even if it’s just an hour.
Oh, one more thing, we sent our scouting and strategy students/mentors up to Team #5013 Trobots’ shop on Saturday to practice scouting on some week one events! One of our mentors has made some new comfy seats for the scouters and our strategy team has finalized the match sheet format. Our drive team is very excited to get detailed intel before each match this year!
Hope you all are having fun in your seasons! I’m tired, but starting to catch up on some sleep, I’ll get there eventually!
but we’re still on track to get at least 2 weeks of drive practice and autonomous tweaking before our first competition. We’ll be putting in extra time as needed to ensure we get there.
