Summary of Recent Events
- We made a decision on overall robot design and strategy on 1/16, as scheduled
- The team had 4 main intake and lift systems that were developed and compared
- We decided on a virtual 4-bar to focus on low and mid levels and a claw that could intake both cones and cubes
- We appeared on FUN’s Open Alliance show this week!
- Code team has field-oriented drive functional and some basic autonomous drive happening. Worked with drive team this week to make sure that the controls are intuitive and responsive
- Robot is structurally complete in CAD, and parts for swerve chassis are being cut
- We’re still deciding on whether our MK4’s will mount on top or bottom of box tubing. We want the flexibility to be the 3rd robot up on the charging station and are worried about breakover angle. We will be testing this week.
- Media & art made progress on pit banners, team buttons, and team avatar
Code
This week, code was focused on finalizing setting up swerve and making it have a good feel to the drive team. We also tested autonomous using PathPlanner in auto and have written code for autonomous routines in TeleOp. We set up our OrangePi 5 with photonvision and calibrated the camera. For a full list of what we did, see below:
- We initially tried to set up cancoders to control integrated encoder position on boot, but after continually lining it up, and after a lot of wheel turns, there seemed to be a heavy amount of cancoder drift to the point of unusability. We switched to integrated encoders that boot to zero (so the robot always has to be aligned perfectly before the robot turns on). In the future, we hope to diagnose the problem and set up absolute cancoders since aligning the wheels isn’t optimal, but this is enough for now.
-
We encountered a problem that, when there’s suddenly a new direction for the angle motors, they don’t go to the setpoint immediately, so there’s a bit of translational movement in a direction other than intended motion. The position PID for the angle motors was tuned to minimize this.
-
A Joystick instead of an Xbox controller was tested, which seems to be a lot more driver friendly with swerve, and likely what we’re going to switch to for controlling the drive. Everything is controlled with the one joystick with the forward, sideways, and turning functions of the joystick. Certain buttons (which are conveniently numbered) control some of the other things on the robot, like resetting the gyro, field oriented toggle, and going to a specific pose.
-
Auto routines were tested, both a straight forward test, a turn test, and a turn in place while turning test using PathPlanner. With initial measurements with meter sticks it appears to be pretty on point in terms of how it moves, but we plan to further tune both encoder measurements and add photonvision for vision pose updates.
-
We tested the theoretical swerve skew when going one direction and turning, but it doesn’t seem to be significant. We still have attempted to calculate a pose ahead one controller loop (which didn’t work, likely because the loop time was wrong). We also have added a modified version of the SwerveDriveKinematics class to take into account the math for 2nd order kinematics found in this paper: Whitepaper: Swerve Drive Skew and Second Order Kinematics (big thanks to 3181 for the implementation) and also implemented it wrong in our code, so further testing needs to be done.
-
We took inventory of the coprocessor equipment for setup of an Orange Pi with camera equipment, everything has arrived and is there. Some initial temperature control includes heat sinks over the cpu and ram, but there likely needs to be a fan to ensure longevity. The fan that we have, the Noctua NF-A4x10 5V, does need to be mounted, so a case will probably need to be 3D printed to fit the geometries. We set up an interface for connecting to the pi with peripherals and a monitor. We then installed photonvision using the default Debian installation instructions (install.sh and uncommenting the AllowCPUs line). We also had to install openjdk-11-jdk via the apt package manager to get the systemd service to start. Photonvision works with the web interface and we also calibrated the camera we have (Global Shutter AR0144) for all three resolutions.
-
We tested the 21” square swerve on the charge station (it works!) and tried different configurations. It has to be at a decent speed to get onto the charge station when it’s at 35°, but can pretty easily balance when on it. Future plans for balancing include a gyro pid in auto, but the code hasn’t been written yet.
-
We have written a collection of classes to create scoring zones on the field (the areas in front of the scoring). When the robot is within these areas and a button is pressed on the Joystick (out of three options) and the robot goes to the specific scoring position. Unfortunately, because of some initial problems with the code and later not having a testable robot, the code hasn’t been tested. Future expansion would include the rows of scoring in addition to columns (for intake commands or small modifications of pose), which hasn’t been written and can be tested after the scoring mechanism is built. We’re considering buying new driver controllers for the team this season, so this could be controlled by a 3x3 keyboard, or will be controlled with buttons on the joystick.
-
We also created some code from scratch as a training exercise for our KOP defense bot (which we plan to put Gary, one of our scoring designs, on), and successfully got that working with differential drive kinematics. We also tested a simple auto that goes forward and turns.
Mechanical
Mechanical team was quite busy with building the V1 Robot this week.
- Decided on Virtual 4-bar lifter and Chopstix-style gripper (Gary is too slow
) - Finished building grid and charging station
- Assembled V1 Robot Drivetrain (26” square, MK4)
- Cut some pieces for virtual four-bar
Field Construction
As of this post, we have one full grid section and a ½ charging station complete. We are still waiting on the official hinges we ordered from AndyMark to ship, but the 1” box tubing solution in the Team Field Elements is working well.
We’re less sure of what specific polycarbonate sheeting to use on the surface. If anyone has suggestions, we’re open to them! Otherwise, we’re going with some thin (0.02”) polycarb sheets from McMaster-Carr.
The grid structure really helped us with testing lift system geometry, in addition to the work in CAD. Overall, we had a fixed angle elevator and a fixed angle telescope both mocked up in CAD and built by mechanical team. For the energy chain lift and virtual 4-bar, we put together more developed prototypes, but had less detail in CAD.
Intakes Goals:
- Light
- One or two moving parts
- Active capture and release of cone/cube
- Room for development/iteration over the next 8 weeks
Top rollers - prototyping teams looked at using compression to trap cube and cone between two rollers. One fixed, one powered roller did not hold a cone or cube, but two spinning rollers did a great job of capturing both cone and cube. The roller system worked best with 2” green compliant wheels spaced about 2”-3” apart on the axles. Ultimately, the team working on this prototype felt the design was too heavy to make it onto the robot. To be fair though, code team and drive team have both requested some additional testing in this area, as this seems like an actual “touch it, own it” intake possibility.
Suction - #teamsucc had a lot of momentum at the beginning of the weekend and developed some prototypes using a vacuum pump kit from Sparkfun. It did not have an FRC-legal motor, but we were confident we could swap in a 775pro. Some pneumatic tubing and basic small suction cups from McMaster-Carr worked great to pick up cones and cubes. Mechanical team built some angled arms to hold suction cups in place to wrap around the cone or cube. Surprisingly, the team found it was easier to pick up a cone with the suction left versus the cube. One challenge was getting good suction cup placement on the cube. It could help to have the cone or cube funneled into the robot in a repeatable way so suction could grab the same way every time.
The Claw - mechanical team decided to continue developing the side pincher claw. It will likely be actuated by motor. We tested pneumatics, but don’t want to add that system for one piston. In order to study this mechanism, we designed and then laser cut some mockups to check the geometry. The team favored this design over the other options and will continue to develop it on our v1 of the robot which we plan to complete by the beginning of February.
Lifter Goals
- Mid-row and hybrid node capable scoring
- Quick and reliable robot
- Minimize the number of moving parts
- Simpler, well-tested
- Mechanically complete for >6 weeks of development time.
We explored:
- Fixed Angle/Slanted Elevator which we explored in off-season
- Thriftybot Telescope which we assembled for 2022
- The Snail (Gary)
- Virtual 4-bar
We mentioned the elevator and telescope in a previous post, so we’ll add a bit more detail about our late-week developments: the energy chain “snail” and the virtual 4-bar prototypes.
Some notes on the inspiration for The Snail… we had the “Unofficial FRC Mechanisms Encyclopedia” open for kickoff day and the “Unique Mechanisms” playlist running. We saw the FUN interview with 1477 showing their hefty Igus energy chain climbing hooks. It deployed from a large spool. We had rookie CAD team members design the gear to turn it, which was a great learning experience. We cut the gear on our Glowforge and were able to drive the energy chain for mid and high scoring.
And of course, here’s a video of Gary the cone delivery snail in action. Unfortunately, Gary’s not as fast as we’d like. He’s likely going to be moved from alpha robot concept to defense bot entertainment.
Virtual 4 bar was suggested based on this video. It’s geometry, man! Our team has built 4-bar designs in 2015 and 2016, but the virtual 4-bar would be new to us. The advantage of carrying the cone or cube inside the robot seems nice, while still being able to pick up and score from outside the frame. We usually try to find over-the-bumper solutions before frame cutouts, and this fits that criteria.
Here’s a video of us testing the range of motion with a quickly mocked up virtual 4-bar.
We had a team meeting to review the pros and cons of each on Monday. While we could probably run any of these and learn a lot from them, the floor pickup possibility with the Virtual 4-bar was the deciding factor. Code team wants to floor pickup in auto, providing alternative routines. They want floor pickup on our v1 of the robot, so there’s plenty of development time. Our team was successful with a gear floor pickup in 2017, and it seems appealing here. We know there will be other robots specializing in the top level, but we don’t think it needs to be us right now.
CAD
This week in CAD was all about decisions being made. With all our prototypes being adequately tested to where decisions could be made (deciding on a virtual four-bar for a lifter and chopstix-style gripper) on Monday 1/16, it was up to CAD team to have enough of a robot so mechanical team could start cutting parts by our meeting on Thursday 1/19. While most of the measurements are done, to build our virtual four-bar mechanism properly, we need to test some things with our drivetrain (such as seeing if it will meet breakover angle) before finalizing some four-bar dimensions.
- CAD team has been able to fit the virtual 4-bar architecture into a 26”x26” swerve chassis design. This should enable our team to be a good alliance partner for charge station balancing.
- Dimensions for box tubing for the drivetrain and some for the four-bar were already finalized at that point, so the mechanical team got to work constructing the drivetrain for testing and as many lifter pieces as we can early.
- We are keeping an eye on some clearance issues in the robot design. For example, the sprockets on the 4-bar arm come pretty close to the Falcon motors. We don’t want to hit those. We’ve talked about switching to the MK4i setup, but our conversion kits aren’t expected until some time in February. Swapping to inverted configuration could also impact our ground clearance - we’re not sure the MK4i configuration makes sense if we want to bolt our box tubing frame to the top plate of the motors.
There’s been a lot of CAD work over the last several days, and we’ll likely have a dedicated post to that topic soon. For now, our CAD is public and can be found here.
Drive Team
With only one swerve chassis to work with, we are scheduling separate meetings for drive team and code team to be able to work with the robot. On Friday, we had an extended drive practice to help drive team learn to maneuver with the field-oriented swerve drive. We’ve not run swerve in an event before, so we want some time to switch from the tank drive mindset to swerve. Main driver and backup drivers got a chance to drive on the charge station and run drills with the 21”x21” swerve chassis.
Driving drills setup in this video! We think the L1 MK4 gearing seems plenty fast, but want to order L2 gears when they are in stock.
One big issue we ran into was with bolts rattling loose from the MK4 swerve modules. Use loctite on everything! Out mechanical team was in the process of checking connections and reapplying loctite, but two of the MK4 modules hadn’t been checked yet. The result was a 10-32 bolt holding the Falcon 500 pinion in place backing out and dropping into the turning gears! We’ve chipped a tooth on the 15t hex bore gear, but the chassis still seems to drive just fine. This was a lesson to drive and mechanical both to inspect regularly and lock down connections. We don’t have spare swerve parts yet, so we don’t want to see anything get damaged!
