BunnyBots Recap
On December 16th, we ran our annual offseason event, BunnyBots. Each year, our mentors create a unique game, released in early September, that always involves bunnies. This year, the goal was to move bunnies from one side of the field to the other, and shoot bucket targets attached to opponents with fuel from 2017, inspired by paintball capture the flag. FTC-sized robotic bunnies made a repeat appearance this year, roaming the field (terrified, we’re sure) attempting to aid in collecting stuffed bunnies. It was a hard-fought and chaotic competition, but in the end, congratulations to 3674 CloverBots, 2521 SERT, 1540D Flaming Chickens (yay) and 7034A 2B Determined for the win, and 2471 Team Mean Machine, 2733 Pigmice, 3636 Generals, and 3218B Panther Robotics for a competitive finals series!
Event Links
Livestream VOD
Game Rules
Match Results and Rankings (TBA)
Robots
This year, we made three robots, these being Enigma, Chief and Delphi, all with different concepts and subsystems we wanted to test.
Enigma
The first of our three robots, Enigma, was created without a CAD, in order to get new members more involved in the design process and get them started working with tools and on construction techniques as soon as possible. As such, it was finished much earlier than our other two bots and was the only one with more than a day or two with software.
Drivetrain
Enigma used six colsons, powered by four Falcon 500s, all of that and the bellypan taken from our Rapid React robot.
Bunnies
In order to intake bunnies, Enigma used a pneumatic claw on an elevator. This claw was our prototype pneumatic intake for Charged Up that we never ended up using but found it fit well here. This intake was mounted on an elevator taken from one of our BunnyBots from 2022 so that we could pick up bunnies from the top of totes and the floor.
Shooting
Enigma had no ground intake and was human player-loaded. We decided to experiment with a pneumatic shooter with five side-by-side cells where balls are loaded. We initially struggled with having too little power and the balls not shooting far enough. However, after some questionable testing, we discovered that if we didn’t plumb the exhaust, it would shoot just about as far as we wanted it to.
Chief
GitHub Link
*This CAD is not 100% representative of the final build.
Chief was always intended to be the swerve robot of the three 1540 robots entered in Bunnybots this year. We decided early on that we wanted to have the capacity to fire balls, and instead of having a turret, the plan was to use the swerve drivebase to automatically adjust to shoot. Our robots’ design was less focused around trying new design elements for the team, and more simply to provide practice designing robots with effective mechanisms we’ve used frequently in the past. Our larger ambitions for the robot were to create a high-accuracy, rapid fire “sniper” bot, that could acquire balls from anywhere on the field. During actual gameplay, we realized that long distance shots were nigh-hopeless, which led us to stick to firing close-range. However, because adjustment for aim is centered around the drivebase itself changing position, we couldn’t effectively utilize a pin and shoot strategy to fire accurately on a still robot–something that would be accessible with a turret. Despite this, Chief ranked third, and captained the third alliance alongside 2374A Jesuit Robotics, 3218B Panther Robotics, and 7448 Santiam Christian Robotics.
Drivetrain
Chief’s drivetrain used four SDS MK4i swerve modules (L2 gearing) with Colson wheels, powered by Falcon 500s. This was our first time utilizing Colsons on our swerve modules, and we found no noticeable difference in terms of driving.
Intake
Chief uses an over-the-bumper, full length motorized intake, with the raising and lowering powered by two NEO 550s with versaplanetaries geared 100:1. The main body of the intake consists of two rollers with spaced compliant wheels and a backing plate, along with churros across its length for support. The first roller is placed to immediately pull the balls it contacts against the bumper, before pushing them up for the second roller to fire them back into our indexer. Both rollers are powered by a Falcon 500 on the inside of one of the intakes’ side plates. The backing plate is polycarbonate bent and riveted into place in order to keep balls from flying out of the intake. The supports for the intake consist of four polycarbonate and aluminum linkages, a short and long linkage on either side of the intake mounted to the side tubing of the robot, through bushings on shoulder bolts running through the robots’ side rails. The full length of each roller is ¼ inch polycarb, with ⅛ inch aluminum running about halfway up each linkage from its mounting point. The motorization consisted of the motors and versaplanetaries mounted on tubing riveted to the bellypan, which connected to a short polycarb linkage, which in turn connected at its end to another short polycarb linkage, which was attached to a point on each shorter linkage.
Through testing and assembly, we discovered an issue with displacement of the intake from the position we desired for it, mainly due to the weight of the Falcon on one side. To resolve this, we added surgical tubing to counterbalance it. Because the majority of the intake consisted of flexible polycarb, we held some concerns about structural integrity, which we attempted to mitigate through the distribution of forces on connection points through washers and the aluminum supports. However, the main point of failure we encountered was the attachment of the mounts of the versaplanetaries used to motorize it, which we resolved by utilizing steel rivets. The major problem we encountered with the efficacy of the intake was due to software setpoints for its raised and lowered positions becoming off over the course of the match. This led to the intake not being able to raise, and slamming into the ground when “lowered,” which was ultimately a major issue we were unable to resolve during the competition. Thankfully, the intake survived these unfortunate conditions without any damage rendering it physically unusable. This could have been due to a series of bolts attaching the aluminum support to each linkage scraping and getting stuck against the bucket mount.
Indexer
Chief uses polybelt running over three live axle rollers in an L-shape, with hex axles running through 3D printed covers making up their structure. The rollers are driven by a NEO with maxplanetaries geared 12:1. The backing of the indexer consists of ½ inch diameter round standoffs running across its width, in a curved shape towards the shooter. We faced some issues with axles slipping out of place, but fixed them relatively quickly through adding missing constraints on the ends of the axles, such as shaft collars and washers.
Shooter
Chief’s shooter was a static angle hood with a main and secondary shooter wheel. The 6-inch diameter main nitrile wheel was geared at 1:1.375 and was driven with 25 chain attached to two Falcon 500 motors mounted at the front of the shooter. The secondary 4-inch diameter compliant wheel was directly driven by a single Neo motor. During play the main shooter wheel ran at 6000 RPM while the secondary wheel was not used. The initial use of the secondary wheel was to affect the ball spin and shot angles however this did not end up being an issue for the shots we were making. Additionally, the main wheel was geared to spin at a higher speed but it was not needed to run at that speed for the shots we were making, meaning that the gearing on the Falcon 500 motors was unnecessary. The spin-up time of the main wheel was longer than the one-second interval of shots initially intended for this game, however, the recovery time was less than a second so we experienced no problems with that.
The shooter hood was made of ¼ inch polycarbonate with standoffs holding it together. The side panels of the hood were pocketed to reduce weight and in all reduced about 1 pound of weight from the shooter assembly. The hood contacts the ball with two rails also made of ¼ inch polycarbonate. The rails were designed to be easily removable so they could be replaced to adjust compression. This feature was never used as we ran out of time to fine-tune the shooter. We needed to increase the compression so instead of making new rails we added foam and surgical tubing to increase the compression to the desired amount.
There was also a 3-inch compliant loading wheel located at the top of the indexer that would move the ammo into the main shooter wheel. The loading wheel was driven by 25 chain attached to a Neo 550 motor with a Versa Planetary gearbox. The overall gearing for the loading wheel was 10:1.
There was a Limelight 3 camera mounted in front of the secondary wheel at the top of the shooter. The limelight was mounted using a 3D-printed ABS case. The limelight was mounted upside down so the cables would not interfere with the path of the ammo. There was a Coral USB Accelerator mounted to the shooter side panel with zip ties.
Software
The software for Chief was done in Java and used the WPILib Command-Based framework and also the AdvantageKit framework. The initial code was based on the AdvantageKit 2024 example swerve robot code. The initial code used the 2024.1.1-beta-3 version of WPI lib and also the 2024 version of many other libraries such as the AdvantageKit library, all of which needed to be downgraded. The Limelight 3 ran a vision pipeline created by FRC team 3636 to identify the positions of the buckets.
Targeting the buckets involved first receiving a list of targets from the limelight and identifying the best target based on chosen criteria. The criteria we used was the closest to the center to find which robot the front of Chief was pointed at. It also disregarded all buckets of the same color as the alliance Chief was on. It then used the horizontal angle of the bucket from the center of the limelight field of view to run a PID controller to aim at the bucket. Once the target was in the center of the screen, the firing could begin. The firing initially planned to use the distance from the bucket to calculate the RPM of the two shooter wheels required to hit it but without time to properly tune this we used a constant 6000 RPM for the main wheel and 0 RPM for the secondary wheel.
The intake was deployed using a PID controller for the two Neo 550s that powered it. Due to the extreme difference in mass on each side of the intake, different control loops had to be used for each side of the intake in order to consistently produce the desired results.
Delphi
*This CAD is not 100% representative of the final build (though fairly close).
Our original ambitions for Delphi were rather extensive: re-exploring west coast drive (since no one on the team had experience building one), testing a folding and detachable superstructure, building a turreted shooter, and even the combination of a bunny intake and launcher. In other words, it was exactly what shouldn’t be done when strategically designing an FRC robot. While it may not have started as such, the main goal morphed into growing our design knowledge (including testing many CAD practices and standards), and straining our teamwide systems to see where they would break.
We did exactly that: with an original mechanical completion deadline in early November, the robot wasn’t fully mechanically complete until the day before BunnyBots, after dropping all ambitions of bunny interaction (aside from just pushing). This limited the electrical and software teams from taking away nearly as much as mechanical, but we were able to practice moving the robot through necessary steps extremely quickly. The end result was a highly imperfect and untested robot at BunnyBots, but nonetheless an FRC quality robot and effective mechanisms, even if they weren’t the best for playing the game. Apparently they were enough for the second pick of the first alliance, though, and we had the awesome opportunity to work with 3674, 2521, and 7034 to win the event!
Drivetrain
Delphi’s drivetrain is six wheel west coast drive powered by four NEO motors, with four colson wheels and two omni wheels (in the front) to ensure turning would happen in a predictable manner for accurate autos. This had the added benefit of making the robot easy to push from the side of the intake, meaning it was extremely unlikely to break from a sideload (with the tradeoff of the whole robot being easier to push around). It was geared 6.11:1 with a free speed of 16.21 ft/s to focus on moving fast.
There were some power consumption issues with the drivetrain, since the battery voltage would sometimes drop to around 6-7 volts at full acceleration, and there was more than one match where we ended up browning out by the end. Even when rate limiting and current limiting the drivetrain motors in software, the power consumption issue was never fully resolved and we are still unsure as to the root cause of this issue.
Superstructure
One of Delphi’s coolest experiments is the use of a foldable/detachable superstructure. It is supported by ⅛” c-channel aluminum on each corner of the drivetrain with cuts out of the long 2x1 side beams to allow for it to fold up in the back (where it pivoted around bolts). It was secured to the frame in the front by 2 quick release pins. As can be seen in the picture, this made work on the upper structure much easier and allowed easy access to electronics on the belly pan, which were able to be mounted before the rest of the robot was finished. Though we should have been much more careful to not get metal shavings on them!
Intake
Delphi uses a pneumatically deployed, full length (around 22 inch) vectored intake to get the wiffle balls into the indexer without taking up space on the other side of the robot (that space was originally planned for a bunny intake and launcher, the the shooter set closer to the center of the robot). The first contact roller ensures the intake is touch-it own-it, and then the second roller rolls the balls along the back until they meet the compliant wheels, which launch the ball into the indexer.
We found, in testing, that the balls tended to jam around the input hole to the indexer, but when the intake is stowed they transfer into the indexer just fine. We also found that the pneumatics didn’t have quite enough force to raise the intake in its lowered position, and once they did raise it they would do so with an extreme, possibly damaging force. To resolve these issues, we added surgical tubing tied to the bucket support to help it raise and hardstops to limit how far back the intake could swing into the frame perimeter and also on the front to ensure we complied with the 0.5 inch ground clearance rule.
Indexer
Delphi uses a series of dead axle rollers (very similar to those on 2910’s 2023 intake) powered by one NEO motor and connected with a polybelt to store up to five wiffle balls and cycle them into the shooter as needed. To ensure we didn’t need any extra sensors, the indexer ends with two separately powered feeder rollers (each with their own NEO 550 on the final build due to accidental interference with the Falcon 500 on the turret). These can pop the balls up, through the turret, and into the shooter.
The sides of the indexer are 7.3 inches apart to make room for a battery between them on the back—this was a helpful place to put the battery, but this was only done after the decision to remove the bunny mechanism, since a less wide indexer (and shooter further back) would have freed up room for that. That distance also gives the balls a lot of room to roam in the indexer, and since it is always running that allows them to apply strange forces to the polybelt, which often causes the polybelt to separate and let the balls fall out the back. We solved this by adding ¾” pieces of wood to either side to reduce the wiggle room. But even that didn’t solve all the problems, as the belts (especially at the roller with both an input and an output) would try to merge on top of each other, generating a lot of extra work for the motor and actually breaking a belt at one point. To solve this we added tape to adjust the rollers (polybelt moves to the area of highest velocity, so with the largest radius) until the problem was eliminated. We also disabled the back belts, because that was far more force than necessary for the balls and was causing them to fall out the back.
Shooter/Turret
Delphi’s shooter is at a fixed angle designed to hit targets anywhere from 0-20 ft away from the robot, running the 6 inch pneumatic shooting wheel at 2215 RPM. The motors directly drive the wheel, since that was the ideal manner to have the fastest spin up and recovery time with the super light game pieces. The turret is a large 3D printed pulley on a lazy susan bearing we bought from Amazon, powered by a belt from a 36T pulley with an overall gear ratio of 166.7:1. It has a magnet mounted on the bottom to trigger hall effect sensors at its limits, giving it a 260 degree range of motion.
The shooter worked great but we didn’t get time to properly test it, which missed the problem of using the wrong RPM (we assumed faster was better), since we didn’t realize it would be overshooting other robots. By the end of the event we turned down the RPM much closer to the design spec, and few shots were overshooting (more time could have led to no errors).
Software
Delphi’s software was written in Java, using the WPILib Command-based framework as well as the AdvantageKit framework for logging and simulation (replay functionality was not used, as there was insufficient time to add support for it).
Delphi’s autos were created using the PathPlanner library for trajectory generation and following. A Ramsete controller was used to smoothly and accurately follow the generated paths. Our autonomous sequences generally consisted of ramming into the totes at the center of the field, in order to interfere with other robots on the opposing alliance running bunny-scoring autos. Although initially these sequences included targeting and shooting other robots to score more points, it was found that shooting was too inaccurate for this to be reliable and this functionality was removed in order to preserve the pre-loaded balls. Because of the simulation capabilities of AdvantageKit, autonomous modes could be created and debugged without access to the physical robot, allowing us to have autos ready to go as soon as the robot was handed off to software.
Targets were identified using a Limelight 3 mounted on the turret, using a detection model trained by Team 3636. The centermost target belonging to the opposing alliance was selected as the “best” target, and its tx angle was fed to a position controller on the turret. We discovered that continuously feeding the target angle to the turret produced undesirable jittering and oscillation when the turret tried to track the target, likely due to vision measurements becoming delayed and changing too often when the turret and camera were rotating quickly. To solve this issue, the turret setpoint was not changed based on vision measurements until it was detected that the turret had reached the previous setpoint. Although this produced a noticeable delay in the motion of the turret, it allowed for much smoother motion and less mechanical stress and still achieved an acceptable level of target tracking accuracy.
Ideally, turret tracking would have considered the absolute pose of the target and the position and velocity of the robot on the field, such that the turret could easily track the target while the robot was moving. Although some of the math was worked out to convert vision measurements into absolute field positions and to calculate the turret angle based on the robot and target positions, there was ultimately too little software time to properly implement these features.
Position control on the turret was achieved using the MotionMagic functionality built into the TalonFX motor controllers, in order to create smooth motion with both velocity and acceleration constraints and to reduce mechanical stress on the turret caused by the rapid acceleration when using a standard PID controller.
Overall Takeaways
- With many new members joining our team this year, we found that Bunnybots was a motivational and applicable way to train new members so that they had the skills to actively participate in build season.
- We have a team with a high percentage of less experienced members and made some changes to the normal training processes.
- The Robot Software department, for example, previously required a basic knowledge of Java or programming concepts. This year, however, we removed that prerequisite and made the department open to all who were willing to learn. New members with no prior programming experience were able to take a course to learn programming concepts in parallel to learning how they apply to FRC software. They could then directly apply these skills to mechanisms on the robot, like the intakes and indexers. This meant that more new 8th and 9th graders were able to get involved, but consequently the department isn’t as ready for competition season as we would like.
- The Fabrication department has in the past been managed by the same people who also manage the Design department, so designers of mechanisms take their mechanism through the whole process from CAD to final assembly. It became clear this was unsustainable given the limited number designers being unable to get enough work to occupy so many members. For the time being we occupied members with our numerous mechanical bunnies and CADless robot with higher levels of mentor assistance, but for build season we split the departments completely and brought on more managers to hopefully allow for better distribution of work.
- The influx of new members helped us identify the difference between small and medium-scale teams. In the past, the team operated informally with managers and members communicating tasks to one another verbally and completing tasks autonomously. However, we realized the need to have more formal policies, structure, and documentation in place to ensure the team operates safely and efficiently.
- Strategic design and game analysis are really important. Similarly to Charged Up, we ended up designing a mechanism to do a task before we fully knew what we wanted to do. We also ended up designing to do lower scoring but more difficult tasks, without much of a good explanation.
- Deadlines, and more particularly well-planned deadlines, are very important. Just about everyone missed a deadline (or five), which left us scrambling for time the day before the event and without crucial software testing and driving practice.
- In order to meet deadlines, our design and fabrication processes need to be rethought for the build season with the goal of distributing work more evenly across our large team.
- This was the first time we used the AdvantageKit framework in our robot code, and we found it extremely helpful to have not only a way to efficiently record large amounts of telemetry data, but also to be able to easily run the robot in simulation, allowing us to debug code logic and create autonomous modes prior to testing on the physical robot. During build season, we hope to use AdvantageKit, as well as block CAD programs like KrayonCad, to streamline the software development process by simulating a simplified model of the robot, allowing us to have more code developed for the robot by the time it is mechanically complete.
- “If it ain’t broke, don’t fix it.” Each build/off season, the application software department has historically created a scouting system from scratch using new technologies. For BunnyBots, our scouting system was not able to be used due to issues with our team server where we normally deploy the app. While the strategy team adapted to collect data with Google Sheets, this event demonstrated that rewriting our entire data collection system each year is not sustainable. Going forward, the application software department will use the technologies they are familiar with and focus on other projects once the scouting system is complete.
- This year, we had hoped to use a custom FMS system based on Cheesy Arena. However, an unfortunate series of problems relating to the wireless environment and team configuration issues meant that it would significantly increase delays between matches. Given the limited 1-day timeframe of the event, we made the decision to revert to a FMS-less mode for the scoring system and use the traditional BunnyBots starting system of years past. Critically, this prevented the robots from being disabled after every three hits, one of the unique rules for this year’s game. The decision was made to not adjust point values for each hit, because cooldowns on the hit rate were removed. This was especially unfortunate for us, given that most of our robots were intended primarily to shoot. Despite these problems at the start, the rest of the event went smoothly. From this experience, we have decided that the level of support needed when using an FMS is not something we can feasibly provide to teams, and we therefore, do not plan to use an FMS like this in future BunnyBots events.
- Be careful with the polybelt! Rollers should be 3D printed with correct geometry (see Chief, not Delphi, where we used AndyMark’s roller geometry) and having both input and output belts on a singular roller is risky. Also in a ball tunnel, both front and back belts are tricky, especially if there is a lot of force involved.
- With Delphi’s flipping superstructure, it took a little bit longer to wire, but made electrical fixes and maintenance much easier. It’s not certain that we’ll do this in the main season, but it is definitely a consideration. Last year, we had a lot of little, hard to find problems, and this could be a solution to that.
- Given our delays and limited robot software time, we experimented with simulations. This was very helpful, and allowed us to have mostly functional code, despite limited time with the actual robot.
- We need to be much stricter with ourselves in terms of documenting our processes. One of the reasons we joined the Open Alliance was to force ourselves to have better documentation, but throughout BunnyBots, we really fell behind on this. We’re hoping that only having one robot, instead of three, will make this easier, in addition to creating stricter guidelines.
As always, we had a ton of fun and learned so much. Thank you to all the teams who attended, and we look forward to seeing you next year!