Whoa, this thread died before I saw these questions
Quote:
Originally Posted by NotInControl
So just a few questions from your friends on 2168.
1. Can you share a little bit more about how you arrive at shooter geometry (compression, contact time, exit speed etc.) required to make the shot. Every year these factors seem to be areas teams must learn from trial and error, wondering if the poofs have a more polished process.
|
Nothing too polished here, just prototype-driven iteration. We knew that our overall design concept would not result in a whole lot of contact time/wrap, so we made sure our prototypes convinced us that we could still shoot consistently despite that. We went through dozens of variants of our prototype to play with various factors.
Embarrassingly, the robot that we competed with at CVR shot nothing like our prototypes. We transferred over all of the geometry, contact materials, and speeds correctly, but our initial competition shooter could deform during the shot and did not cradle the ball as consistently (after driving over defenses) as we had hoped. We found out about these issues before the event, but did not have time to address them until SVR.
Quote:
Originally Posted by NotInControl
2. Can you share more about what drove the Team to a turret all together, as far as I know this is the first turret 254 has used in competition. I am curious what drove the design, where did 254 pull the inspiration from if anywhere, did any team mentors/students have prior experience with turrets in FRC applications in the past? I find it typical for teams to avoid certain solutions because they have never fielded them in an event and would rather choose a solution they have more experience with. That definitely is always a good approach in my opinion, just wondering how 254 gets over that idea to follow a solution they never fielded.
|
Even though 254 has never rocked a turret before, a number of mentors have used them while on past teams (ex. 973, 341, 190). We chose this design because we were more confident that we could quickly and accurately aim with a turret than by servoing a pneumatic drivetrain. The traditional wisdom is that if FIRST gives you a protected area to shoot from, you should build the simplest robot possible and shoot from there. But we figured that most good teams would do this, and moreover thought that shooting from the outer works would lead to congestion and more difficulty aligning. So we set out to differentiate ourselves from the pack. As it turned out, while we ended up being one of the quickest shooting robots on the field, other teams were able to optimize their outer works shooters to be nearly as good (at a cost of a fraction of the complexity).
Quote:
Originally Posted by NotInControl
3. Can you share a little more about how you determine whether to go chain #25, #35, or belt. This has been an age old question, and I am not really asking which you think is better, but how do you go about choosing which one for the application. The reason I ask is some teams use belt, and use it for everything, some teams use chain and use it for everything, and other teams kind of are in the middle, they use one, have failure, and use the other, and keep bouncing around. I am wondering if 254 has a more scientific approach to the choice because it seems like 254 chooses different solutions more purposefully.
4. Going back to the chain question. I recognize that in certain years 254 has went from belt to chain or #25 chain to #35 chain etc. When this occurs do you have to redesign your drive rails or are their certain considerations into the design that makes changing from one to the other easy without much modification? (i.e certain spacing common to all)
|
254 has never used belt in the drive, and had only used #25 chain in the drive (in the bumper era) until 2016. Chain is nice because it is easy to replace, easy to tension, cheap and modular, etc. We started our build with #25 chain in our drive, but knew that this year the tensile load would eat into our safety factor (small sprockets, big wheels). After busting a few chains on our practice field, we swapped out for #35 chain. The chassis was designed to support this contingency from the start.
On non-drivetrain mechanisms the team has used belt exclusively since I joined the team (on things like intakes, flywheels, and elevators). None of these have been super high load applications.
Quote:
Originally Posted by NotInControl
5. Your Vision on the Nexus was stated to come out of necessity due to the unreliability of the Tegra, I am curious if the android solution seems like something 254 would use in the future or if there are equal pros and cons to possibly look for another? We did use a tegra, and after soldering come caps off to make it boot reliably we did not have an issue with the board. But again thats besides the point, looking for 254's opinion on the next best solution. Could you share some pain points, or cons/hurdles which needed to be overcome before the android solution was put into practice. I am sure many teams are testing an android solution in the off-season (we may be one).
|
We would definitely consider going the Android route again (if a simpler solution doesn't make more sense...Pixycam is pretty sweet). A lot of the biggest hurdles were integration questions that we largely were able to answer. Adb port forwarding for communications (which allows charging over the USB cable), the fact that you get a screen and input device build-in, the availability of great APIs (seriously, Camera2 is awesome) and IDEs for development, relatively powerful hardware and a nice camera, and low cost...it all just makes sense.
Pain points were (a) figuring out the comms and power interface (including ways to make sure that you can unplug/replug the cable and reboot either side and have the link come back immediately); (b) physically mounting the thing such that the camera was facing the right way (phones are not designed for ease of mounting on a robot); (c) finding the most performant way to capture an image and process it (there are a bunch of ways available - we tried em all). Also, we noticed that we got lots of tearing in our images at times due to the camera being mounted so close to our flywheel (likely because of optical image stabilization capabilities...the camera is basically mounted on a tiny spring). Our vision code was able to deal with this, but it was a nuisance.
Quote:
Originally Posted by NotInControl
6. Can you share more on the servo solution? How did you ensure the servo was meshed properly and never skipped? We tried to use a servo this year for our articulating hood, but slippage was a big issue so we pulled it for a multi position pneumatic solution right before our first competition. Typically on this team if it failed once we never try it again. I am curious how 254 was able to have a successful servo implementation. Would you mind sharing which servo was used, and how it was interfaced to the hood and did you have any issues with slippage?
|
We used continuous rotation servos that drove a pinion along a curved gear rack on our hood. We used a separate encoder for feedback, so slippage wasn't a big deal. Someone else should be able to lookup the servo part we used (we also used a digital programmer to make sure that the servo stopped when the robot got disabled...it didn't out of the box!).
While this worked, it was a big pain in the butt. I wish there was a tiny, lightweight, low-speed motor in the kit last year appropriate for such an application and we could have used a Talon and been done with it. We burned out a lot of servos during testing while we tried to find the best ones, and still shredded gearboxes from time to time (typically when we would accidentally lower our hood onto a still-spinning flywheel, such as if we accidentally drove into the low bar).
Quote:
Originally Posted by NotInControl
7. How was the hood angle determined from vision? Was it based on distance to target, center of target to center of camera frame, or some other method?
|
We calculate the pose of the goal relative to the robot origin (where we started the match) for each camera frame. We then track the pose over time (keeping track of robot motion using encoders and gyro while tracking) so that the goal remains roughly in the same place during tracking. We can determine range by taking the distance from our shooter to the goal pose (both relative to robot origin). Of course our estimate of robot position (and therefore goal position) drifts significantly over a match (especially after going over a few defenses), but it doesn't matter since this error cancels out during aiming.
Once we know the range, we use a lookup table to determine hood angle.
Quote:
Originally Posted by NotInControl
8. How many drivers were used this year for the machine? I have heard that some years 254 has 2 drivers, some years 254 has 1 driver with a bunch of automated stuff. Could you share what was automated, requiring little/no commands vs what was always manual for this years bot?
|
2 drivers this year and every year since I've been here. This year the base driver controlled all things drive (shifting, traction control mode) and had the "fire" button (since the driver knows what he wants to do, this way we don't have issues pressing "fire" just as the robot changes direction). The operator was responsible for our utility arm (hanger and defenses manipulator), intake, and state of the turret assembly (low bar configuration vs. intaking vs. auto-aim). For shooting, the operator basically just holds down the auto-aim button until the driver shoots.
That's a lot of responsibility on the operator, so aside from auto-aim, we had a massive state machine for the robot to help automate transitioning from intaking to low bar, to shooting, to hanging, etc. The operator presses buttons that command a "wanted" robot state, and then the state machine transitions through the correct sequence of operations (ex. stop the flywheel, center the turret, bring back the hood, stow the hood, etc.) with the correct timing and/or sensor events to ensure that no matter how the operator console gets mashed, the robot always gets into the goal configuration as quickly and safely as possible.
We can help make those dreams, maybe. ;) - Adare180 [more] 
11-30-2016, 03:06 PM
Linear Mode
