I would advise not putting your radio down in the belly pan of your robot but up as reasonably high and facing outward as you can manage.
Thanks for the advice, Iāll update our Cad accordingly later today
JEEZ! Yaāll have got an amazing design so far, i look forward to watching yaāllās matches while working on school stuffs! Do Tell Romina that Aires says hi too, Sheās the reason i love 8738 so much Keep up the great work!!!
Tell Romina that Zoe says hi as well! Yāall are cooking
2/2 Programming Deep Dive
With our team finally settling on a design for our robot, the programming team has finally begun our work for the season in earnest. This deep dive is a large one, detailing our process for designing our code and the problems we have encountered so far.
A Description of Our Robot from People Who Arenāt Mechanical Engineers
The side profile of our robot shown above isolates all the parts that programming cares about for our robot. According to the sketch above, the main outputs are:
- Lower intake bars to grab notes (1 motor)
- Upper vectoring bar which aligns notes to the center of the robot (1 motor)
- Two indexer bars to hold notes while traveling (1 motor)
- Two large flywheels to launch notes (2 motors)
- Pivot point of the entire shooter to aim up and down (2 motors)
We will also have two laser distance sensors, one at the upper intake bar (2) and the other at the indexer (3).
Note that the climber is not included in this side sketch because it is currently undergoing design changes, so the programming team is holding off on extensively programming this for now.
Subsystem Design
Given the design of our robot, our very first task as a programming team was to split up our 5 outputs and 2 inputs into subsystems. The key criteria Slice considered when sorting components into subsystems are:
- Independence - When you make a command, you can use the addRequirements function to declare that the command must have exclusive control over that subsystem. This is really important to do if you are directly controlling any motors with a command to prevent fights for control, but it can also cause an issue. If we put too many motors into one subsystem, then all of them will have to be controlled with a singular command rather than multiple, which can lead to unnecessarily complex commands.
- Interdependence - If the actions of one component, especially an input, are directly pertinent to the control of only 1 other component, they should probably be in the same subsystem
- Simultaneity - If two components are always controlled at the same time, they should probably be in the same subsystem.
- Intuition - When code is discussing the subsystems with each other and with other teams, itās helpful if the grouping of subsystems matches what people would instinctively expect so that communication is as unambiguous as possible.
Given these criteria, the subsystems we created are:
- Intake - When intaking a note, the vectoring bar is always run at the same time to move the piece to the indexer. Whatās more, both will need to know if a piece is currently in the robot in order to prevent intaking more pieces.
- Intake bars
- Vectoring bar
- Vectoring bar laser sensor
- Indexer - The indexer laser sensor is exclusively used to stop the indexer bars from moving the note into the flywheels before they are ready to shoot, so the two are a natural pair.
- Indexer bars
- Indexer laser sensor
- Shooter - The flywheel and pivot point rely on the note trajectory math, and will work in tandem while shooting, so we put them together.
- Flywheels
- Pivot point
Controls
After making our initial code, we held a discussion with our drive team to discuss how we wanted to control the robot. Our main takeaways were:
- As long as the intake limelight sees a note in front of the intake and we donāt already have a note, it should automatically intake.
- Assuming it is not too large of a draw on our battery, we will also as a precaution intake at a slower rate even while it does not see a note.
- As long as our robot has a note stored and is close to a position from which it can shoot into the speaker, it will begin to spin up the flywheels
- Our shoot button will force the robot to face towards the speaker, spin up the flywheels fully, and aim the shooter. If we are unable to achieve shooting while in motion, it will also wait to shoot until the driver has fully stopped.
- Both shooting into the amp and into the trap will involve holding a button down to have the robot automatically line up using AprilTags, and then automatically score when it is aligned.
- Our operator will control which trap the robot scores into when the driverās trap button is pressed using a trio of selector buttons.
Shooting
For our initial shooter testing, we are using the trajectory generation math provided by team 1757, according to their build thread here.
However, our shooter design offers a unique problem with using this formula. Pivoting our shooter to aim up or down changes the position of the ālaunch pointā between the flywheels from which the note is shot, which completely changes the trajectory of our note and requires a new angle to aim at. If youāre having trouble visualizing this, try moving this interactive shooter diagram around. As you aim the shooter, the note comes out at a completely different point.
If our trajectory depends on the launch position, but our launch position depends on the angle of the trajectory, how do we aim at all? While theoretically you could solve a complicated system of equations to figure this out, itās difficult to do. Believe us, we tried:
Instead, we will use an iterative solution. First, our trajectory generation will assume the launch point is on the pivot point of the shooter. Then, using the angle it generates, we can calculate the new launch point and calculate a new trajectory. We could repeat this loop as much as we like to get an arbitrarily precise answer, but the below graph shows that after just 3 loops, the maximum amount the launch can change from the second to third iteration is 0.05 degrees, which is hardly enough to cause us to miss.
After all this math, we now have the launch angle and velocity for our note, so itās time to put them into real life. The below video shows our programming teamās current project of testing our trajectory math with a prototype shooter in order to empirically find a function that takes the noteās launch velocity and finds the corresponding flywheel rpm. Essentially, we keep increasing the flywheel speed until the note goes in and then record this. Once we have enough data, we can create a function that automatically finds the right flywheel speed.
2/4/2024 CAD Deep Dive
With the launch of the 2024 season, CAD has had a lot of work to do these past couple weeks. From prototyping ideas, analyzing strong concepts, and ultimately CADing our main season robot, hereās what the SLICE CAD team has been up to this build-season:
KrayonCAD Prototypes:
As soon as kick-off occurred, SLICE quickly started brainstorming ideas. CAD was a great way to visualize these concepts, and we heavily relied on KrayonCAD to get simple mechanisms down without CAD expertise needed. Ultimately, we decided to take a vote on the three strongest KrayonCAD designs:
1. Elevator Arm:
Elevator Arm features an under the bumper dual roller ground intake, with a dual fly-wheel shooter that is mounted onto an elevator. The shooter is also able to pivot, allowing us to score on the amp, speaker, and trap (while on the ground). Hooks on the elevator would latch onto the chain when extended.
Pros:
- Fits under stage
- Amp scoring
- Speaker scoring
- Ground intake
- Climbs
- Trap scoring
- Decent e-board space
Cons:
- Complex
- Requires many custom parts
- Experimental drive-train design
- No source intaking
2. Ground Scoop:
Ground Scoop features an under the bumper ground intake, with an over the bumper roller to pull notes towards the intake. The whole intake/shooter would be able to pivot, allowing us to shoot at varying distances. For amp scoring, we would be able to drive up to the amp and lightly shoot the note straight up. A tall bar towards the back of the robot would ensure that the note consistently falls into the amp opening.
Pros:
- Fits under stage
- Amp scoring
- Speaker scoring
- Ground intake
- Very simple
Cons:
- No climbing
- No trap
- Poor e-board space
3. Double Pivot:
Double Pivot features a single roller over the bumper ground intake. Index rollers would pull the game piece toward the pass through shooter. Angling the shooter down and passing the game piece through the shooter would provide an optimal angle for amp scoring. Both the intake/indexer and shooter would be on a pivot (hence the name) to allow for simple mechanism stowing.
Pros:
- Amp scoring
- Speaker scoring
- Ground intake
- Abundant e-board space
Cons:
- No climbing
- No trap
- Doesnāt fit under stage
- Sketchy hand-off
Although a very close race, Elevator Arm ended up winning the vote, becoming our main season robot. Speaking of which, howās that going?
Main Season Robot CAD:
While albeit a tad behind schedule, the CAD for our main season robot has been going great. The biggest learning curve we have faced is designing with the ability to create custom parts using both FeatureScripts in Onshape, and a real-life CNC machine! Over the weekend of the 27th, we were able to CNC a temporary e-board using plywood, as well as test out cutting metal for our many custom plates. This is what we have so far regarding the actual CAD:
During our design review on February 1st, our mentors gave advice regarding possible design oversights or general improvements to our robot. A more in-depth final CAD review will be coming soon once these final touches are made.
Plan B Robot:
While more experienced CAD members have been designing the main robot, less experienced members were tasked with CADing the plan B robot. This was decided to be the āGround Scoopā design, as it had the second most votes out of the three designs. While progress has been expectedly slow, once the main robot CAD is finished we will be able to guide the less experienced members more thoroughly. The hope is that by next season, these members will be able to CAD a significant portion of the main season robot. Participating in off-season CADathons is just one additional way we hope to prepare our members.
Conclusion:
While not perfect, the 2024 CAD team has thus far proved vastly more successful than last year. Leaps and bounds have been made in quality, efficiency, and teamwork. The ability to CNC a large portion of our parts has been a real game changer. However, our biggest improvement has been time-management. During the 2023 season, weeks were spent before we even had a concrete idea of what our robot would be doing. That caused our design to be rather simple and unambitious. With every passing year, the CAD team learns and improves. Better CAD, lots of driver practice, and improved robot efficiency is what will cause our team to be much more competitive during the 2024 season.
2/5/24 Electrical Deep Dive
This Deep Dive will cover what the electrical subteam has mainly focused on for the past week or two: E-board Prototyping, and Knowledge. These past few weeks have been slow for the electrical team so there wonāt be too much to cover, which is why Iāll try to include as much detail as I can.
Prototyping in CAD:
As covered in the last post the electrical team is working with our CAD team to come up with a clean, organized, and functionally efficient design for our E-board. The placement of electronics and routing of wiring is extremely important in this stage of the process, as well as spacing and orientation of those electronics. Weāve decided to move our radio outside of the E-board belly pan for faster, easier, and more stable connections to the drive station. This not only gives us the above benefits, but also makes wiring ethernet a whole lot easier because making longer ethernet cables is way easier for me to do than really short ones. With those new design modifications underway after our latest mentor design review, electrical has had to adapt to the new robot frame/structure and other mechanical components. Weāve decided to modify the Spark MAX cases weāve been using to help with wire management and keep a clean E-board as to ensure no wires get caught in these new modifications.
New Ideas:
We plan on using our recently purchased LaserCAN sensors for detecting notes entering our intake and indexer. Since this is a new device Iāve never worked with it may take a little time to get used to it, but I can see this being a fairly easy addition to our robot. Another nice thing about these little sensors is that they can be daisy chained for up to 8 devices to distribute power. The daisy chaining only works because of the low power draw for these sensors. Although we are yet to experiment with this device and canāt confirm its functionality, we have high hopes for LaserCAN and its many possibilities. Below is the pinout for the LaserCAN.
(LaserCAN ā Grapple Robotics) (A little further down the page)
Kraken Motors for Swerve:
Our team has made the decision to replace our NEO āDriveā motors with Kraken motors for increased speed and torque, ~14.5-17 ft/sec, and control on the field and during testing. Although these wonāt be arriving for about a month or so, weāve prepared our drivetrain, mechanisms, and wiring around them. They use a different type of wiring pinout rather than the usual motor controller and motor layout, with a built-in motor controller (Talon FX) for easier, more reliable, and more robust connections while minimizing failure modes. As mentioned earlier, new components will take a little getting used to, but I can also see these integrated motor controllers coming in handy, especially at competitions. Below is a model of what the integrated motor controller looks like on the Kraken X60 Motor. It includes a direct CAN bus connection with a direct live and ground connection as well.
(Kraken X60 powered by Talon FX) (Fifth image on the product preview images)
Robot Design Review
Our CAD is mostly complete for the season. The purpose of this post is to go in-depth into our design and why we approached each aspect the way we did. If you still have any questions after reading this post, Iāll gladly answer them.
Overview
For this yearās robot, we chose to go for a full width between the bumper intake, feeding into a pivoting indexer and shooter combo that is capable of amp, speaker, and climbing. This was designed around effectively achieving our top priorities of ground intaking, shooting from almost anywhere in the speaker half of the wing (we refer to this as medium-range shooting), and scoring in the amp.
Chassis
During our early season strategy, we determined that this yearās game would be very reliant on high-speed full-field cycles. For this reason, we decided that we will use Krakens as our drive motors on our mk4i L2 swerve with new speed adapters. This will allow us to reach top speeds of up to 17.5 ft/s while still having a lot of power to push through defense if it comes down to that. We will continue to use Neo V1.1s for steering. We decided to go with a 23.5ā x 29ā drivetrain on a 30ā x 29.5ā chassis. We went as wide as possible to allow for as wide of an intake as possible. For the length, we wanted it to be as long as possible to avoid tipping, while still utilizing an in-the-bumper intake.
Superstructure
Originally intended to contain an elevator for climbing, this superstructure will hold up our shooter. We located our pivot further back from the shooter to allow for supports on both sides, in addition to making the center of gravity of the shooter closer to the support when stowed. For vision, we have a Limelight tilted upwards to detect Apriltags at both close and long range. Our radio is placed in the center of this tower to bring it into a more open position while not putting it at risk of collisions.
Intake
Our intake utilizes silicone-covered polycarb tubes on dead axle hex to intake the notes. We chose this over wheels to save weight. This will be driven by a Neo motor on a 1.5:1 ratio. The intake is 29ā wide, with an optimal intake area closer to 25ā wide. It is attached to the rest of the drivetrain using a Ā¼ā aluminum plate on each side. All of these decisions were made based on our guiding principles: durability, reliability, repairability, and efficiency, in addition to our build principle of having an efficient touch-it own-it intake.
Lower Indexer
Our lower indexer is based on a fairly extensive list of tests conducted by other teams. It utilizes a 3d printed vector, sliding the note up polycarb using a roller with compliant wheels and a Neo. The gradual slant of the vector should allow notes to center quickly and enter the pivoting indexer. The wheels are only placed in the center of the indexer so that the note is rolled up the vector walls instead of being compressed into it.
Shooter
We have a pivoting shooter mounted on top of the superstructure. It utilizes two independently driven axles, each with a Neo Vortex motor near the pivot. We chose this setup over split axles due to its simplicity. The shooter pivot was designed such that it is capable of subwoofer shots while fully stowed, in addition to being able to pivot over the top for amp scoring. For long-range shots, the shooter will pivot partway, making it tall enough to easily shoot over almost any potential defender. 2 Neos drive the pivot on 80:1 gear ratios, which we calculated would allow for the optimal travel time without straining the motors. The upper indexer will hold the note during shooter alignment. It uses similar rollers to the intake to reduce weight and is driven by a Neo 550. The gap between the indexer and shooter is fairly large so we donāt risk dropping the note if we have a high-speed collision with a defense bot.
Climber
For most of the design process, we intended to use an elevator in the superstructure for climbing, but we realized that would be fairly redundant since our amp scoring position reaches a similar height to where we wanted to climb from. To prevent damage to the shooter, we reinforced it with metal plates (disclaimer: the image shown below is not up to date). The hooks then secure onto the end of that plate, allowing us to easily replace them later in the season if we have issues with the current geometry. To climb, we would pivot up the shooter, align in front of the center of the chain, or push into the sides and latch. From there, we close the shooter, which will lift us off the ground.
Programming Deep Dive
This shorter deep-dive goes into greater detail about how the some of the code behind Sliceās shooter works.
The Issue
As mentioned in our last code deep dive, Sliceās shooting code uses team 1757ās shooter trajectory calculator to calculate an optimal shot. However, this calculator only gives us the optimal velocity and launch angle of the note. Itās a more complicated process in order to convert the launch velocity into the rotational velocity of the flywheels.
The naive approach would be to assume the launch velocity is the speed that the outer surface of the flywheel is moving at. The below equation shows how to convert from a linear velocity to the rotational velocity of the flywheel.
This equation is theoretically perfect, but realistically the flywheels are not magic devices that instantly accelerate the note to precisely the correct speed. Both inertia and a lack of friction cause the note to accelerate to a slower speed that the above equation assumes, so this will always undershoot.
The Solution
There comes a point where the system becomes so complicated that it isnāt worth doing the physics equations to solve it. Instead of trying to come up with a complex model of the acceleration of the note inside the shooter, Slice is instead opting to use empirical data. Hereās the process:
Firstly, we are using the equation above to predict the correct rotational velocity of the flywheels.As previously stated, this will always undershoot, but afterwards we manually adjust it until we make the shot consistently. From this we collect two data points: the original velocity of the flywheels, unadjusted, and the actual speed that made the perfect shot after adjustment. By repeating this for a few distances, we can create a plot. Hereās an example of what it might look like.
After collecting data, we created a function to predict the actual speed given the theoretical velocity. From a glance, it looks like this example data fits a quadratic function, so by typing the equation for one into desmos, it will automatically find the constants a, b, and c for a parabola that best fits the data.:
Of course, itās possible to use any function, but polynomials are usually easiest to work with. If you are using desmos, you need to load all your data into a table by pressing the + button in the corner, and when typing your equation you should use the tilde (~) sign instead of the equals (=) sign in order to get it to make a prediction.
Note the R2 variable directly below the equation. That represents how well the function fits the data: the closer to 1, the better. After finding a function with a reasonably high R2, we can plug it into the code and test it out to ensure it works.
(Beware, just because a function has an R2 of 1 doesnāt mean itās perfect, in fact an R2 of 1 is usually too good to be true, because that means the function is āoverfittingā and basically guessing anywhere other than where it was tested. For polynomial function this can be easily prevented by using a polynomial that is at least 2 degrees less than the number of data points collected)
A benefit of this approach is that it not only accounts for the imperfect acceleration of the note, but is also able to compensate for air resistance, thus encapsulating numerous complex physics equations into a single, simpler function.
Itās been a while since weāve posted hereā¦
We hope to remedy this next year by shifting posting responsibilities away from leadership onto a group of semi-dedicated OA writers/videographers.
Anyways, our 2024 Season Recap is premiering at 2:30pm est today. You can watch it here: https://youtu.be/xs1JTAqzQFA?si=x5v9LLUARVdUay_e
If you have any questions about our robot or season, Iāll be glad to answer them.