Hello and welcome to Team 1806’s 2024 Build thread.
Links:
2024 Code: GitHub - frc1806/Crescendo-1806: FRC Team 1806's 2024 Robot Code
2024 CAD: Onshape
Also check out our Team History Page for links to past robots and cad/code links for robots we still have cad and code for.
I’ll make another post before kickoff with some catchup with things we’ve been working on and doing over the offseason, including our swerve testbed, and a new pit that we’re still working on.
For 2024 We are competing at the Northern Lights Regional Week 1 and the Greater Kansas City Regional Week 6
We have gained a new sponsor for the 2024 Season in the form of Meta, which we are incredibly grateful for. Their contributions, combined with the continued support of exiting sponsors such as our School District and Gene Haas Foundation, we are able to invest in things like Swerve, new motors, and shop upgrades.
For a long time team 1806 has operated on handbooks that either didn’t exist or went completely unenforced. Starting this year we have instituted a new team handbook adapted from team 1678’s handbook as a starting point and for the first time in a long time we have team leadership roles again. We will track how we do with this organization structure and make adjustments as we learn more in terms of effective organization and ourselves.
We also have a new motto, inspired by both our new sponsor, and team 1678’s triple E motto: Motivate, Empower, Teach, Accomplish.
So ahead of the 2024 season we have purchased 2 new toolboxes to serve as our pit, and thanks to one of our students, we’ve finally painted a wall in our shop that had been raw, yellowing drywall for 30 years. We also got rid of one of our worktables in an effort to reduce clutter in our shop.
Note that cleaning up our shop is an ongoing process, and we’re still moving things into the new toolboxes. Also the lighting mounting in wide toolbox is very temporary as we will need to give the top of the box a bit of a trim so it can fit in our trailer. We also need to put a banner mount on the big wide toolbox.
I didn’t get a picture of it, but we also now have our own whiteboard that belongs to the team for the first time in a long time.
We’re also in the process of making a new smaller powered robot cart, which will be unpowered at competitions through shifting our old 2020 robot gearboxes into neutral (high gear has been removed) as well as potentially a software lockout. The new cart will also feature a lift table reusing a HAB Climber prototype from 2019 as well as both aesthetic lighting and work lighting. We’ll be using 8” swivel casters on the front and 8” colsons on the rear. Many of you may be familiar with our current powered cart, which we’ve had since 2008, which is still cool and would be functional if we bought new batteries for it, but we made the determination that we need a smaller robot cart to free up more space in our pit.
We believe that a powered cart, even if it has to be off during during competition, is part of our team’s identity at this point, and will still prove useful for outreach events. Plus we want an electrical system on it anyway for the lift, the lights, and maybe even an inverter to charge the driver station at some point.
Here’s our swerve testbed that we’ve been running over this offseason, we have it driving fine non field oriented with YAGSL but we have weird issues with field centric drive translation getting flipped when pointing backwards and point-to-heading having issues when trying to go to a heading pointing back at the driver. CAD for this is here (with different electronics mounting) and our code is here: Commits · frc1806/YAGSL-Control-Mockup · GitHub note that we both haven’t updated YAGSL in a while, and we also have changed the heading control from a PID to a ProfiledPID (which aside from the glitch above seems to work great), both of which may be contributing to the issues above.
Inspired by Broncobots having several limelights on their robot, but not wanting to spend $1200 on one set of limelights, we are going to try a different solution.
We have 4 of these cameras on hand, and will attempting to connect them all to a Minisforum UM773 which will be powered by this regulator set to 19V
The only testing that’s been done is confirming that it can run photonvision with 2 cameras plugged in, and that yes, a full x86 laptop CPU is in fact pretty fast at detecting apriltags. We were getting 1280 x 720 @ 40-50FPS with 10ms of latency.
Addendum: Oh yeah, I forgot, we do have all the stuff on hand to make a Zebraswitch 2.0 but we can’t fabricate it until after kickoff.
Yesterday evening, we set goals for the season. I forgot to grab a picture before we left, so I may be missing some goals, this is what I could reconstruct from memory and a very blurry picture from a student.
Competitively our main goal is to win a regional as a captain or 1st pick.
To do that we will
Get the robot done early (4 or 5 weeks into build season)
Get driver practice before the 1st event
Control our own destiny in alliance selection
Have scouting with actionable data and only actionable data, and an automated system to analyze the data.
Have everyone meet requirements to attend travel events (in this case Northern Lights and fingers crossed for Houston)
Achieve 97% on field reliability
Our outreach goals are to
Have demos at our school and the middle school
Have an open house during build season with adjacent dinner
Build towards being able to host a summer camp either this summer or next summer
Looking forward to competing with you at Northern Lights! Should be a fun and competitive event.
As you all know, last Saturday was Kickoff. After reading the manual and doing some analysis of how to score, how to get ranking points, etc. we came to the following categorization of tasks
After that we made some shooter prototypes that we have on youtube.
Belt Launcher Prototype
The idea here was to have a belt shooter that we activate with either a flywheel on a dog clutch or moving a grippy wheel to contact the belt in order to very quickly accelerate the note without having the need for separate indexing motors, and also the need to make the robot longer to have a staging area for the game piece. After having many issues with the belt slipping off, we remembered our past struggles with polycord and polybelt reliability and went a different direction.
Wheeled Launcher Prototype
After some tests with this, we have (for now) abandoned the idea to be able to disengage a flywheel to allow it to spin up, as with just CIMs, we had enough power to launch from a standstill without the need to charge anything up, and the NEO Vortexes that just arrived today or yesterday should have even better performance.
Our normal meeting schedule is Monday, Tuesday, Wednesday, and Saturday, and for this week, every weekday meeting was impacted by inclement weather. As we copied 1678’s handbook, there wasn’t much in the way of a provision for snow days, so what we chose to do is make meetings optional for all 3 week day meetings this week, and allowed attendance either in person or by working on robotics related things from home to count towards future excused absences.
We settled on a robot concept of having an under-the-bumper intake with a swerve drive, and the many-wheeled prototype mounted as an arm we can rotate down to handoff from the intake and then up to shoot. This is to keep the robot COG as low as we can while traversing the field. We expect this game to be absolutely brutal in terms of impacts.
Frame
Right now we’re looking at a 28” by 28” square frame, but we have changed out the traditional 2” x 1” x ⅛” rectangular tubing for solid 1”x 1” aluminum bar. This should both be strong and allow for more room for notes to go under our robot.
We have in-progress CAD for our launcher here Onshape
You can see the 3” X 1” tube and hub we are using to make this into an arm.
As for our climber, we have some ideas whether it be just a COTS telescoping tube, but we have also purchased 2 rollable boat hooks as seen on Howdybots’ Shrinkydink to see if we can turn them into a compact way to climb, potentially by spooling the boat hook with nylon strap inside it.
Practice field progress is good (by our standards) as we already have a source and an amp, we’re going to work on the stage and speaker/sub tomorrow.
We haven’t done much with our vision tracking solution mentioned in the pre-kickoff update, other than we’ve assembled 2 Zebraswitch 2.0s.
We also seem to have resolved most of our swerve drive control issues, after looking at both our odometry and control inputs, we thought we had the only mk4i where the drive motors don’t need to be inverted, but instead we have the only NavX2 that doesn’t need to be inverted. Hopefully tomorrow we can spend our time refining our controls a bit before tuning path planner and getting our testbed to run some paths. If we get that all working and as the practice field comes together we’ll be able to start looking at integrating everything with april tag tracking.
For your belt shooter prototype, were you holding the shaft/bearings with your hand?
It was a large stack of bearings and the CIM motor itself.
The boat hook tube works in that application. We’ve been playing with them too! 
Note: This update is produced in collaboration with our Business team, just wanted to make sure they get credit so people know that it’s not just me writing these updates.
Week 2, Workin Hard (pt. 2)
Last week we had a couple snow days which took away a majority of our meeting times, but our team still worked hard to get lots of work done and we’ve already gotten to work on a lot of things. We have settled on a robot concept of having an under-the-bumper intake with a swerve drive, and the many-wheeled prototype mounted as an arm we can rotate down to handoff from the intake and then up to shoot. This is to keep the robot COG as low as we can while traversing the field. We still expect this game to be absolutely brutal in terms of impacts.
This week in S.W.A.T. all of our subteams are getting started working on this season’s robot!
Starting with our hardware design subteam,
They have started with our hook climber by brainstorming ideas on how to assemble it and what it looks like. We were impressed with the strength of the boat hooks and are moving forward w ith that design. Hardware design has also been designing things like our shooter angler and intake design.
Now, time for our hardware fabrication team!!!
Fabrication is working on welding our frame. Our frame design is still the same as we described in the previous post. Welding the solid 1x1 has been a struggle that’s been kind of solved by going with a larger tungsten rod, but the welder still overheats a lot which stops us from having the frame welded as quickly as we’d like.
Also, the robot we’re building now will be our practice robot. We intend to build 2 robots, and have a primary robot that we compete with and mostly use for autonomous practice, as well a this practice bot which will be used for heavy drive practice and make an appearance at events as a “NOT-A-ROBOT” with the swerve modules removed and serve as a pile of spare parts.
They are also working on adjusting our launcher we’re deleting the back set of launcher wheels, and moving to a pair of “indexer” wheels (the pair of wheels furthest from the front) and then having the 2 front pairs of wheels be the actual launcher. We could not get enough acceleration from a dead stop to be able to hit the goal. We also still need to work on mounting lights in and trimming our toolbox! Also, we still need to get the RGBs on our team sign and get that hung up in our shop, as well as our TV. Our pit monitor also needs mounting as that will be mission critical for being able to troubleshoot issues with our vision solution if they pop up.
Next, our controls team :OOOO
Our controls team has been working very hard on a bunch of things. Such as Path Planner, april tags, launcher subsystem, intake subsystem and launcher angler subsystems, and alot more. We have our camera mounts printed, and are waiting on some nicer 4-40 hardware to arrive before final assembly, and we also finally have our hands on a compatible barrel jack to power it with off the robot.
Progress is looking good. It’s clear that you guys have had many years of sustained success with 9 blue banners in the last decade. Have you always welded your frame?
I recall early in my time in FRC we had an issue where our aluminum weld joints broke in a bad collision and it proved very challenging to repair in the pits. If you’re having trouble with the frame welding process slowing you down, what do you think about bolting or riveting the frame together?
We’ve welded the frame for a long time, at least since before I joined 1806. Once in a great while we’ll break a weld but we usually fix it with a quickly made riveted patch. Normally our welding process is a lot faster but that 1x1 solid bar is making things more difficult than normal. It’s not really slowing our build down that much and the resulting welds seem fine. I really just kind of made a note of that in case other teams decide solid 1x1 is the way to go.
Are y’all still playing with the boat hook climber?
Oh okay! Solid 1x1 is pretty beefy.
Yeah, that’s still our leading climber concept because it packages well with our design (mounted on top of the shooter), we haven’t made much more progress on it, once we finish our practice field we’ll probably start making more progress on that.
Team 935 has purchased a couple of the boat hooks to use in our climber/elevator concept. Haven’t had much design progress, but we are excited to see how much it can push rather than pull.
Week 3,
Another week of working hard and making good progress on our robot, despite the weather conditions. Like said previously, we are constructing our robot with an under-the-bumper intake that will shoot the game pieces out of the arm, and swerve modules. All of our subteams have continued to work on each important aspect of our robot.
Our hardware design subteam!
On our to-do list, the hardware team is striving to work on multiple things. Such as a hook & climber, intake design, shooter angler, electronics, camera mounts, and finalizing our launcher. Starting the week, hardware design is finalizing on perfecting the gear ratio for the angle of the shooter. Also converting our designs in CAD to parts with the hardware fabrication team.
Also, after all that we found we needed adjustments to our launcher again, both for serviceability and for being able to interface with the intake we needed to remove the cutout in the front of the bottom launcher plate. We also started to mock up electronics in this small form factor robot which will be quite a challenge to fit everything. Luckily we have no plans to add pneumatics. This is further exaggerated by the fact we found out that we needed to shorten the planned electronics area half an inch to have it not run into the launcher when at handoff position with the intake. The most up to date document is here.
Hardware Fabrication team!
The fabrication teams to-do list consists of a few things like bumpers fabrication. Mounting lights on our toolbox, and trimming our toolbox. Last week there to-dos were working on welding our frame, and adjusting our launcher which they have finished! *For more details go to week 2
They ran into some issues with ease of assembly of the launcher pivot, so hardware design and fabrication are collaborating on a solid block mount that has a hex hole broached into it, bolt holes drilled and tapped from the top, and then sawn in half so removing the launcher can be accomplished by removing 4 bolts. Here’s a quick side view sketch:
Also, during assembly we damaged 2 redux through bore kits, and in response to that we’ve modified the redux case from the STEP files on their website to be something very robust that we can 3D print and use. These will be getting printed tomorrow.
Damage to the stock mounts
Finally, our controls team. Last week they had a big list of things to work on. They have gotten their april tags reading with the minipc, path planner, launcher, intake, and launcher angle subsystems completed. On their to-do list, are things like working on calibrating our cameras, and shooter and angler subsystems.
We found that we were having issues with the reset pose function provided by YAGSL, but in the meantime we seem to have at least one path planner path running well enough that we’re confident that we’ll be able to leverage it for auto when we get to that point.
We’re also planning to add sensors to our launcher to help with indexing and wasting less time waiting for game pieces to launch.
The yellow circles are to represent photo eyes from a top down perspective, 3 is used to detect once a game piece is all the way in to keep the note from getting destroyed and also just not waste precious battery power and time. We may have this rumble the driver’s controller on the rising edge so they know they have the game piece and should move towards scoring it. 1 and 2 are more interesting, when launching, once the 1st two wheel sets are up to speed, the 3rd wheel set moves the note through the launcher. The launch command can then wait for a state where there is nothing in front of photo sensor 2 but something in front of photo sensor 1, at which point we know the note is exiting, but has not fully exited yet. After that, once both sensor 1 and 2 are clear, we should be able to stop the launcher and return the arm it’s on to a position ready for intaking another note, and probably once again give the driver some cue (LEDs, controller rumble, etc.).
This arrangement may also be useful for amp scoring, as the note could be staged at the very end of the launcher before gently kicking it out.
Also we have the parts to make harnesses for these photo eyes to plug them into the Spark Flexes on the arm so the wiring doesn’t have to run back to the rio, nor do we risk having a Rio 5v rail failure (we’ve noticed in the past this seems to be very sensitive to brownout and/or metal shavings causing the entire rail to shut down) derailing an entire match.
Also controls and hardware design has been working together on camera mounts. We’ll put all of our OV9281s in modified versions of this case, and have mapped out the hFOVs of our camera to determine mounting points, and made mounts for them in this OnshapeDocument
Here’s that map of our camera HFOVs from above, this is assuming that apriltags can be read from about 20 feet away.
Some pictures of the current state of our practice bot. Also, not much in the way of updates on the climber at this moment, seeing others mockups we’re reasonably confident we’ll be able to make one and have it on the robot for Northern Lights, so we’ve effectively deprioritized it in favor of having the rest of the robot available to start driver practice and autonomous.
That solid block mount for the pivot we mentioned earlier will be modified to allow for clearance such that the camera can exist right on the corner. These mounts all tilt the camera 20 degrees upward and 20 degrees outward.
The reset pose issue was resolved in 2024.4.7. I am so happy to see your path being followed that well!!
We switched our driver controls from using 90 degree snap rotations to 45 degree snap rotations with polar coordinates. If you wish to read through all my yapping you can read the big long breakdown below.
Throughout our meeting today we decided to give our swerve controls an overhaul. This was going to happen at some point, that point was today. So first of all for those who aren’t familiar, our old control scheme was left xbox joystick for translation (x and y) and right xbox joystick to snap rotate to any 90 degree direction (for example, moving the right stick to the right would rotate the robot to 270 degrees so its facing to the right field relative.) You could also hold right trigger to rotate freely without being locked in to only rotating in increments of 90 degrees.
This system worked fine because the snap rotate would allow us to quickly rotate to a common angle that we would need to rotate to in competition very quickly and accurately. However, we wanted a tiny bit more precision so now we changed it to increments of 45 degree angles.
To do this we would need to change how the current program worked, because previously if you wanted to center the robot back to zero degrees it would only check if MathUtil.applyDeadband(driverController.getRightY()) > 0. This works perfectly fine for 90 degree increments but for 45 degree increments it would not work entirely as expected because there would be some clashing between 90 degree snap rotations and 45 degree snap rotation. 90 would only require the right joystick y to be above 0 but 45 (CCW) would need to have both the right joystick x and y be above 45 if we were to adopt the same setup which would cause a problem.
Which lead us to want to overhaul our snap rotatation completely. We decided to go with a polar coordinate system where you treat your joystick x and y like a cartesian plane and you convert them over to polar coordinates, so we quickly wrote up a class to use static methods to operate similar to WPILib’s Unit class. Source code for our PolarCoordinate converter class can be found here. Next in our DriverControls subsystem we remove all the old snaprotate methods and made a new method which will update the current desired angle from snap rotations. First we convert the right joystick x and right joystick y into polar coordinates to get r and theta values. It’s important to make sure that the joystick values you convert to polar coordinates are field relative. In our case we needed to make both x and y negative and then flip them (pass y first then x to the PolarCoordinate.toPolarCoordinate() method.) Once that is all situated we then first checked to make sure we were getting any joystick input which is determined by making sure r is greater than some arbiturary deadzone value. If it isn’t then set the robot’s wanted angle to the angle it’s currently at. Lastly you need to do a simple formula to convert your nasty super precise doubles into clean rounded integers. We used this formula:
theta /= 45;
theta = Math.round(theta) * 45;
This allowes us to only have theta values that are either 0, 45, 90, 135, 180, 225, 270, or 315. Last but not least we then updated our FieldOrientedDrive combine our old and now deleted SnapRotateDrive and PreciseRotateDrive commands to be all in one package and of course removed the triggers for them as well leaving us with a nicer and neater control system for our swerve drive.
Also, one other thing is we re-enabled heading correction and this it works wonders now compared to the old iteration on YAGSL. It’s super useful for our practice offseason swerve bot (which is not our actual practice bot) that had it’s electronics thrown on real fast with no considerings of weight and weight distribution. Because of that issue it caused this test bench swerve drive to drive a bit when we drove it too hard but YAGSL’s heading correction does a great job of keeping the robot at our desired angles. So i would like to thank all the YAGSL developers and contributors for making our first year of using swerve a whole lot easier.
Now that we’re at the end let’s see a quick demo of the new snap to 45 degree angles now, and of course, if anyone wants to view our entire source code it can be found here
Correction on the photosnesors we use, it’s these NOYITO E18-D80NK
Week 4, Only Slightly Behind (This is a good thing)
The goal by this week was to have our practice robot running! We knew on Tuesday that we would have to work hard to reach our goal. All the teams had things to do to help, here is what we worked on week 4!
Below is our teams to-do board for this season, we are still adding and revising ideas on our list.
Our hardware design subteam!
The hardware design team used cad to figure out good positions for the electronics and created cad for an electronics board to be cut out and assembled with electronic parts. This design had to be messed with a few times and ended with this ↓
Here below is a design that we tried to use, but we decided we didn’t want the battery to be so low because we would have to cut the electronics board which would make it less sturdy. ↓
Our design team also further refined our rear camera mounts so they mount to the bottom of the top 1x1 rail of our frame so as to not interfere with… anything really.
Hardware fabrication team!
The hardware fabrication team is making bumpers for the robot, including the vanity bumpers for the practice robot, using solid core pool noodles. They also made and welded on the pivot mounts for the arm.
So the bumper fabric we’re trying for the vanity bumpers is Performance Nylon & Spandex Fabric in black (of course), after hearing Team 1339’s success with stretchy material and with Schoeller® Schussmeister Stretch Woven Fabric being out of stock in blue and red, we’re going to try the Performance Nylon on our vanity bumpers and see if that holds up, if not we’ll fall back to a tried . Our numbers are cut out of Tackle Twill heat press material on our Epilog Laser Cutter and we plan on pre-stretching the fabric before applying the numbers to avoid wrinkles, though we aren’t actually sure that’s needed. Also, we managed to find some B/BB Baltic Birch from MakerStock.
Also it is of note that all but our intake side bumpers will be between 1/2" to 1" from the ground, and then our intake side bumper will live in the very top of the bumper zone. That is to avoid having notes go under our robot when we don’t want them to.
Business, media, and outreach
Business and media has been writing these weekly posts as we go along, and brainstorming a possible battery-naming fundraiser. We also made some T-shirt designs to submit for the Open Alliance, and we have been taking photos of what’s going on. For some more outreach and fundraising, the team is having an Open House, Mac & Cheese dinner event mid-February.
Controls was mostly helping Design with electronics placement, we made sure we have SSH access to our coprocessor so we don’t have to plug it into a monitor every time we need to get into the filesystem.
Where are we at: So we now have a goal to only miss our goal of having the practice bot running week 4 by a couple of days. Considering we have gotten a grand total of 0 driver practice before our 1st event every year since bag and tag ended, we’re still way ahead of our normal pace so long as we continue to execute and don’t hit a major snag, expect much better 1st event performance than our usual. So we’re in a situation where we have to be proud that we’re in a position as a team where we can set a goal and only just miss it, but also be hungry for the future and learn from this so future goals are accomplished when we say they will be. Also we really probably need to get on that climber now.
Other Random Stuff
We’re playing around with a post-Northern Lights upgrade idea to throw an intake pointing backwards out of our robot that instead of putting the game piece in our shooter, just immediately throws it over the robot for use exclusively in auto for the center notes via a sweeping path through them.
We are trying to as much as possible have the robot not have to stop and drive backwards. That means whenever possible turning cycles into laps (see: 2017), trying to shoot on the run (we’ll see when we get a robot moving, and vision running on the robot), and figuring out something for the amp. Not to bog ourselves down in details.
