All the practice space |
Wahoo! We have a fast robot. This week we got our practice robot fully up and running, we broke it a few more times, and we got more software and drive team cycles. All of this preparation will continue to ensure reliability and performance for our first competition in 2 weeks time. Realistically, with packing, unbag time, and travel, we have just over 1 week to continue our program and make the best of our slow season. Fortunately, though our season may have run slow, this robot is fast. Over 2 days of drive practice, we have been able to consistently beat our baseline scoring cycles by over 3 seconds.
Scouting
For CyberKnights, we use scouting to provide details for planning upcoming matches, and for making alliance selections should we become an alliance captain, or a first round pick. This year, several students wrote a new Android app to be run on Kindle tablets to gather and serialize match data. We will bring 6-12 scouts to every meet, ensuring we have 1 numeric scout for each robot on the field, and are able to run students in shifts. Outside of our quantitative data collection, we have 1-3 students who gather qualitative data - subjective evaluation of robot performances. These students try to identify robot traits for things such as good defense, smart driving, or special autonomous features - things that can't easily be identified with pure numbers.
Our robot and software aren't the only folks practicing this week. We sent our scouting team up to Mt Vernon competition to practice with the new scouting app. They spent Saturday watching matches, recording data, and following up in the evening with a mock alliance selection meeting. Week 1 events usually run slow, as volunteers and staff get up to speed on field reset, and robot connection issues. For our purposes, this is most excellent. Our students can use the extra time between matches to ensure their data input is correct, they have filled in all the fields, and the data synchronization works. We are all learning together.
Practice Makes Perfect
Something broke down there. Not the limelight, that's nice and bright still. But something.... |
We have two drive teams, a software team, and one robot. Lots to do then. Our software team will usually get priority. (Nothing at all to do with myself or head coach being software engineers...) They actually usually get priority because we want the robot to function well. Our drive teams will run their drills, and during practice, they'll record tweaks, button changes, or operational changes to be made. Then software gets the robot and gets to "fix" all the issues that are brought up. These can be things like: "Don't run the intake if the elevator carriage is above the collect position" or "Update the left bumper button to activate just the deploy pistons". Our mechanical team will also be watching drive practice, and they'll have notes for software: "Don't slam the elevator full power into the hard stops" and "The collector stow can't fully retract if we have a cargo collected". Software usually has a big giant list of things like this to fix. And then we ask them to write some new autonomous routines. And we want the camera vision to "work more betterer". And the mechanical team delivered the robot to software late. Software gets priority on the robot for a number of reasons.
Our drive teams have started running drills. Some drills are specific - in an open space, chase and collect a ball, spit it out, chase and collect another ball, spit it out, rinse and repeat for 20-30 minutes. Cargo collection should be second nature. We have a mock loading station created. Another drill is - put a hatch panel into the load station, collect the hatch, drive 3-4 feet away and drop the hatch, insert new hatch panel, collect hatch, rinse and repeat for another 20-30 minutes. In this early drive practice, we focus on specific parts of the game - game element acquisition and deployment. We will run a few full-game simulations, but those are less important right now. To score points, we need to be able to gather game elements. Next, we need to be able to place game elements. Only after we have mastery of those skills will we start running full cycles and game-timed simulations. As we increase our driver training, we also attempt to better replicate on-field conditions. One way we do this is having our drivers wear headphones and/or earplugs. Drivers can practice and then associate mechanical noises with collection or mistakes. This won't happen on the field, so we try to eliminate our drivers from listening to the robot, and using only the visual feedback that they will have on the competition field.
The elevator is supposed to come out... right? |
Our final practice is probably the least fun, but I am very happy when is happens in the lab. Pit stop practice! During software update and/or drive practice, we have and will break the robot. Here at the lab, we fortunately have more resources for dealing with robot mechanical issues. We have time to analyze the issue, understand the root cause, and hopefully repair and replace parts in such a way to have them not fail in future use. Reliability has been a CyberKnight strong point for all of our years (again... let's skip over 2015...). The majority of this reliability comes from breaking the robot early and often in the lab, and understanding why and how failures occur. Break it now, so we don't break it later!
Updates to the Bot
Cardboard is a good material for shields. |
Shields!
Intakes!
Flow Control!
Since we bagged our competition robot, we have found little... things... on our practice robot that need addressing. Other items are general wellness items that we put on our bot every year, that usually get added later in the cycle. Several items are listed above. Shields protect specific pieces of our robots from, ourselves, from other robots damaging them, or from game elements damaging or abusing system parts. Every year we protect our electronics and pneumatics, and make sure that no errant game pieces or robots can lodge into or disable the robot. This year we are making significant use of pneumatics for actuation. Some of the motions are more... violent... than we otherwise would like, so one update to our hatch mechanism is the addition of flow-control fittings. These allow us to tune and control the speed of the piston actuation, making actions more even and consistent. One minor flaw we may run across is tuning multiple flow control fittings across pistons that deploy together.
For major mechanical updates... we don't really have that many. We modified our intake to package nicer in the same space, but all the critical dimensions remained the same. Our elevator is getting more robust cross-members to better hold the width and keep the bearings in contact with the next stage. We do also have an upgraded elevator gearbox that will get mounted during our un-bag period. Our previous gearbox utilized Vex 180* gearboxes, and with the mounting solution we chose, flexed too much causing binding and chain skip issues. Our new design is a custom plate (that didn't take literally forever on the router, we promise) that should remove any reliability and operational concerns.
Any upgrades I wish we had that we don't quite have yet? Well, yeah. I haven't watched every robot reveal, but I've watched a few of them. A few robots have adopted this geometry, and I am wishing we had found a way to make this work: At the lowest elevator position, the hatch collector and cargo shooter are able to collect and score their respective game pieces without requiring elevator motion. It sounds like a simple thing, but there is such a beauty about running entire matches, not needing or caring about running the elevator. Our geometry this year makes that a challenge, as we have a basket to hold the bottom of the cargo ball, and our hatch collector is above our cargo shooter. As it stands, we could run hatches day and night without using the elevator, but scoring cargo uses software synchronized motion with the intake and the elevator to be effective. (Fortunately, we do not have interference to the level that software is <required>, but it is still not as clean a hand-off as it could otherwise be.)
Normally our robots are designated silver and black. This year, silver and chrome. |
Quote of the Week
"If I was in West Valley in 2017, I probably would have died." - Head Coach
No comments:
Post a Comment