Hey, Chief Delphi! This is our #openalliance update for Week 1 of build season. Kickoff weekend will be organized in chronological order (as all the team was focused on strategy throughout the weekend), and then the rest of Week 1 will be organized based on subteam activities.
Saturday (Kickoff Day) - Game Rules
In the morning of kickoff, The 6 team leaders collectively presented a basic presentation about FIRST robotics, followed by sharing our 2023 Season Goals. After that, one of our mentors gave a 5 minute presentation on data analytics, setting the tone for mass multivariate data collection and analysis that would prepare us for better scouting and prototype testing this build season.
Once the kickoff live stream concluded, the rest of the day could be summarized in three words: reading the rules. First, the team split into groups of 5-6 people to begin the rules-reading process for about 40 minutes. Then, the full team reconvened and had a group discussion about the rules, pointing out specific important rules, answering questions, talking about mechanisms solely in the context of strategic advantage, and generally getting every team member on the same page in our limited understanding of the rules at this point.
To expand our understanding of the rules, we moved onto a World-Cafe discussion. Team leads stayed at their table to moderate the discussion; everyone else rotated through each group every 10 minutes. All discussion notes were recorded on paper to be shared with the team at the next full group discussion. Team leads briefly recapped findings so far for each new group they meet with. Our groups were Autonomous & Endgame, Tournament Structure, Robot Rules, Arena, and Match Scoring & Penalties. Each team lead did a quick presentation of their station once the team reconvened.
We wrapped up kickoff by identifying some robot archetypes and strategies. As people were leaving, we gave everyone who ordered our new team T-shirt with a new logo developed in the fall. Like last year, we encouraged everyone to take Citrus Circuits’ Rules Test until they reached 80% correct. At the moment of this post, however, 9 students out of ~30 have passed. This is not an ideal number, and we hope to increase it this week.
Sunday (Kickoff Weekend) - Game Strategies
Sunday is when the team went more in-depth on strategy discussions, figuring out our priorities as well as further studying game rules. From the field walkthrough videos and discussions online, we discussed some notable insights, such as:
- Using limelights to score in the grids would blind drivers
- Field visibility from driver station is not great
- Max point total (discluding penalties) in this game is 193
- Penalty points are much higher this game then in Rapid React, massively discouraging any robot interaction in opponent protected zones
Cycle times for scoring game pieces became an important point of discussion, especially when talking about how hard it would be to achieve the maximum point total. To try and get a better sense of what cycle times would look like in this game, we watched some 2017 match video from Smoky Mountain Regional. We noted that cycle times were ~15 seconds at best and many were longer. We also watched 2011 and 2012 games to get a sense of inflatables, 3 levels of stacking, balancing bridges, and platforms.
After watching past years’ games, we discussed all the potential robot archetypes this season, as seen in the picture below.
We made a list of robot priorities, including our demands, “prefers”, wishes, and no’s. The link to our strategy doc (including the justifications for each reason) is linked [here](Charged Up Strategy Ideas - Google Docs), but here is our list of demands, that must be included on our first iteration robot, set to be completed by February 6th:
Autonomous
- Drive
- Drive for Mobility bonus
- Score cone/cube low
- Drive over Charging Station
- Dock on Charging Station
Teleop
- Drive
- Drive over Charging station
- Dock on Charging station
- Engage on Charging station
- Actively balance w/one other robot on charging station
- Score cones low/mid
- Score cube low
- Receive cone from human player
- Can take a hit
Our “prefers” are still pretty important, but a lot of these are “prefers” so we can complete our first iteration robot by February 6th and achieve our bare minimum demands. If all goes well, most if not all of the “prefers” will appear in later iterations (I might be jinxing it, but I think some of these will show up on our first iteration robot too!).
The last thing we did on Sunday was to start discussing our drivetrain, with our main two options being swerve drive and kit drive. A picture that summarizes the discussion of the swerve drive is included here.
Rest of Week 1
CAD
CAD and mechanical teams were quite overlapped this weekend, but CAD in particular has been occupied with testing different lifter designs in CAD, different grippers, as well as setting the (tight) deadlines for the team so the February 6th deadline for robot completion can be met. The 1st iteration CAD review day (which will include CAD, mechanical, electrical, and code teams) for our robot is set for Thursday, January 19th, so that is when 1st iteration CAD will be mostly finished. Once CAD has been reviewed and changed to different subteam wants, then the V1 CAD release will be announced on the Open Alliance Discord server as well as in this build thread.
One of the highest priorities for CAD was to decide the size for our SDS MK4 swerve drivetrain. The two main mechanisms we wanted to make prototypes of were lifters and grippers, with lifters being the most important to determine drivetrain size. Like many other teams, CAD has been working on the one DOF dream, but with our robot only having mid-scoring, we have found 4 different ways that a 1-DOF lifter is attainable! These are a 2-stage constant angle elevator, 2-stage constant angle telescoping arm, a virtual 4-bar, and an “energy chain” lift. All this is possible with our target drivetrain size of 26” x 26” or smaller.
There haven’t been too many gripper designs translated into CAD, but with the four lifter designs and the three-four gripper designs we have in mind, we have made two whiteboards to compare each mechanism set so decisions can be made quicker. The pictures shown here are only the start of these comparisons, with pros and cons listed and ranked criteria being used to classify certain mechanisms so we can use some Pugh analysis to decide what mechanism concepts we end up going for on Monday, January 16 (I know this gives CAD very little time to finish by January 19th, but trust. Some mechanisms will be designed before then too, just to visualize them in CAD, and some mechanisms + the drivetrain have been mostly designed already). You can find our comparison sheet [here](1466 Prototype Inventory - Google Docs).
Mechanical
While the CAD team was conceptualizing prototypes, the Mechanical team was building and testing prototypes as well as providing input to the CAD team about design for lifters, grippers, and drivetrain. Throughout this week, the team has been proof-of-concept prototyping four lifters and three grippers. Details about each are found below. We are still ironing out the prototypes, so pros and cons are not finalized yet. On Monday, we decided that we would go for a swerve drivetrain this season, due to the multiple maneuverability advantages + it being possible to go over the charging station with the swerve drive.
With the help of team parents, we started field element construction, with the goal of building at least one grid and ½ charging station. As of today, the two columns with two cone nodes + hybrid nodes have been built.
Lifter: Two-Stage Elevator
The plan with this lifter is to have a constant angle elevator that maintains 1 DOF to score for the mid node but with a wrist that can be added to the elevator so it can support scoring high. When we built a proof-of-concept two-stage elevator out of old box tubing and some Andymark elevator bearing kits, we truly realized just how heavy (on the top too) and how wide a two-stage elevator would be, which would make it harder to balance on the charge station during teleop. It would still work at a constant angle for sure, and would be suitable for most if not any gripper design the team comes up with, but it’s not the team’s definite best choice.
Lifter: Two-Stage Telescoping
This lifter would function the exact same way as the two-stage elevator, but would be lighter and narrower, making it easier to balance in the charging station. Luckily, we had telescoping arms from last year so we could see the mechanism in a real state as well as in CAD. In the first iteration of the robot, the telescoping arm would be put at a constant angle, but the stages can be made to easily integrate high scoring through adding rotation to the base of the telescoping arm. However, due to only using the one telescoping arm, this would only work with light and narrow grippers, so the versatility of a telescoping arm for grippers is slightly less than an elevator.
The plan is to use one telescoping arm for the lifter, but we had a set of two in the lab already so we could just experiment with that.
Lifter: Virtual Four-Bar
The lifter would function by having two rotating joints that are both controlled by one motor, in effect making it 1 DOF. Chains would be run through the system, making the VFB somewhat top heavy due to the sprocket that needs to be put on the top, making it harder to balance the robot on the charging station. However, the simplicity of the build is enticing, so we’re not counting it out (yet).
Lifter: Energy Chain (Gary)
The last and most interesting lifter we are prototyping is the energy chain. Inspired by 1477’s 2020/2021 robot, as well as it being something the team did in 2011, we want to use an energy chain with a custom-made gear to spool/unspool the chain, which is something we are currently working on. The main concerns with the chain are 1) how heavy can we make the gripper we put on the chain and 2) how can we prevent the energy chain coiling upward when we don’t want it to or controlling the coiling of the energy chain so it can coil back and straighten out when we need to. More prototyping will definitely provide more information on the legitimacy and/or severity of these concerns.
Gripper: Succ
From the pretty self-explanatory title, this gripper uses suction to hold on to game pieces, for both cubes and cones. From preliminary testing, we have already figured out what region of the cone and cube the suction cups need to attach to grab either piece. However, when testing this gripper, the holder of the gripper would need to push onto the game piece to actually establish working suction, so the next steps with this gripper would be to figure out how to get a spring, string, or motor to provide the push force that establishes the suction. If the gripper works, it has the potential to be the lightest gripper that we use. However, wiring the air compressions would be difficult, and it has potential to use the most motors (2) out of any gripper we prototyped.
Gripper: Top Roller
Again, the title is fairly self explanatory: it’s a top roller gripper that can intake both cubes and cones (with the same length roller, those cubes are durable!). Although it works, there was some difficulty to pick up the cubes (which isn’t too important; picking up cones is the top priority). The gripper would as well be wide and relatively heavy, which would prevent some lifter designs from coming to fruition.
Gripper: Chopstix
Chopstix is the last gripper we are prototyping, with it being the most conventional gripper that we are designing. Like the name suggests, it uses a pincer system to grip both cubes and cones, with the in-and-out motion controlled by a string + spring system with the string being spooled up and down by the motor. The gripper would be (relatively) wide, but it wouldn’t be too heavy as the motor could be moved to the bottom (unless it is the energy chain gripper, then the motor would have to be near the gripper, making it heavier).
Code
The code team has mainly been focused on setting up a reliable swerve drivetrain that includes absolute positioning and feels natural to the drive team. We also did a lot of experimentation with Shuffleboard and have been reading the docs of PathPlanner and PhotonVision, two of our new libraries, to learn how to utilize them. A full list of what we did and the specifics is included below:
-
Before CANcoders were wired, we were only using the TalonFX integrated encoders to control module angle. We had problems with the positions of the wheels, since when driving translationally, directions were completely fine, but when driving with rotation, two of the wheels were driving the opposite directions they should have been. We tried reversing the motors (drive and position) and resetting encoders in almost every permutation, with constants eventually being easily updated via Shuffleboard and a toggleable module switcher was made with the drive controller to center and reset encoders. The solution turned out to be two of the SwerveDriveKinematics constants being reversed, which promptly fixed the issue.
-
We have written experimental autonomous code using the PPSwerveControllerCommand from the PathPlanner Library. The autonomous code has not been tested yet.
-
We experimented with network tables and the Shuffleboard layout. Two tabs were added, “Telemetry”, for simple read-only telemetry data, and “Tuning,” for modifiable constants, like PID constants and motor direction booleans. Some issues have popped up with Shuffleboard, mainly that the values do not update consistently and sometimes tables don’t show up. When trying to add a box via the side menu, values show up and are changed in the menu, but do not show up on the interface. This could do with a stale client interface that needs restarting, but further debugging is needed.
-
After CANcoders were wired, we switched to a WPIlib PID control loop using CANcoders as feedback and the normal SwerveModuleState rotation as a setpoint into a percent output motor. This ended up causing a fair amount of trouble, as there were issues with the wheels not being lined up exactly and PID not going to setpoints as well as it could (took a while and seems to be inconsistent across modules). This results in translational drift with turning (e.g. when going with only vx, no vy, it would have a slightly off heading and end up in a curved trajectory, instead of straight).
-
Because of the quick refresh rate of integrated falcon encoders and its greater ease of use (although sad lack of continuous pid), we decided to switch to that as our control loop. The cancoder’s absolute position with an offset will be used to reset the rotation motor’s position to ensure constant direction on boot.
-
The cancoder offset is planned to be derived from lining up wheels with something like a plank of wood, having cancoders initialize to 0 upon boot, then calculating the offset by looking at the difference between normal position and absolute position.
-
To prevent drift throughout the match, we plan to either keep an offset that’s applied to the position throughout the match (either derived experimentally and multiplied with current signed rotation count or updated periodically with cancoders) or simply reset the position motor encoders with cancoder data. This does rely on cancoders, so it’ll depend on if cancoder drift is significant or not.
-
Our Orange Pis arrived, which we plan to use as a coprocessor for vision with AprilTags using PhotonVision. We plan to power them with the 5V/1.5A VRM but if there is too little amperage, we will use a buck-boost converter supplied with 12V and create greater amperage. The Orange Pi hasn’t been set up yet, but we plan to use the base Debian install.sh with Orange Pi OS.
-
Some problems that we believe could be potentially harmful are odometry updates while going over the charge station (wheel slip and the fact that it’s at an angle translating pose further than it should be). This could be minimized by creating a custom update function that takes into account IMU data (needs to be accurate or have a deadband likely) or using AprilTags to reset pose. There also seems to be a decent amount of swerve skew when rotating, which seems to either be minimized with either doing a Twist2d ahead one command loop or implementing second order kinematics. Further experimental testing is needed to see how much each one actually affects the skew, as they haven’t been implemented yet.
Post written by Dmitri, Noah, Nicholas, Emily, and Dr. Lawrie
)
