Code Orange is proud to present our 11th robot “Eclipse”!
Thanks so much to all of our students, parents, mentors, and sponsors for making all of this possible, especially in such an uncertain year.
2022 Robot Summary.pdf (440.4 KB)
Reveal Video! https://youtu.be/sENzTtd2u-4
Please feel free to ask any questions! Also please keep an eye out for our technical documentation which we will be releasing in a few days.
Not named after a surf-related term… I’ll allow it.
i think Eclipse is a surf break in Costa Rica
where’s the turret, I know it’s hiding somewhere
just 4 of em, upside down. It’ll be twice as good as 2017!
Love me a Code Orange reveal! I’m really digging this bot and the relative simplicity of it. Can’t wait to watch it play some matches!
Can’t wait to get slayed by this thing at LA. Excellent work Code Orange!
Amazing robot! Just curious about how color sensor works, are you shooting cargos with wrong colors in different angles or just simply not intaking them?
Yep! Originally the idea was to just shoot wrong cargo at a different angle than the correct cargo but we never fully implemented the color sensor before OCR. At our next regional at LAR, we plan to have the color sensor working and maybe have a outtake on the side of our robot to drop out wrong alliance cargo.
Here’s our technical documentation if anyone would like to know more about how we designed the robot, specifics about each subsystem, and our programming!
2022 Technical Documentation.pdf (8.8 MB)
Just curious, what specific breakbeam sensor did you use?
We’re planning to use this one: QS18VN6LV W/30. We didn’t implement it by OCR but we are planning to have it by our next regional in Week 5.
Here is Code Orange’s scouting data from OCR! For each data field with coordinates, each coordinate corresponds to a pixel on the image.
For drawing out the Auto Path, we used the image below (600px by 460px).
For marking shot locations, we used the image below (600px by 300px).
The cycle count and teleop path fields are used together to mark shot locations and shot percentages. For example, a cycle count field with this data: [[1, 2, 0, 0], [2, 1, 1, 0], [3, 0, 2, 0]] and a teleop path field with this data: [[326,77],[382,185],[459,66]] allows us to display the image shown in the image below. We color the different location squares based on the shot percentage, with Green indicating 100%, Yellow indicating 50%, and Red indicating 0%.
Here is the code that we’re using to limit our robot’s acceleration to prevent us from tipping, wearing out our threads, and damaging the field. This is in addition to other best practices, such as current limiting.
This is our 2022 robot CAD! Thank you for waiting patiently. https://workbench.grabcad.com/workbench/projects/gcZahsXaAOFD_m5puOimv1a-sylE1OqdRKYpahC_cl0Eh5#/space/gc2HnxnEsjSlu9xxcBaJU9lIz4wxy8D6-6Tr4Ahz7Pxk1B
Hi! After seeing your tech binder and your code. l have some questions about your robot’s hopper, climber.
Hopper
How does your hopper work? Is it automatic? You have said that breakbeam sensors are used ensure robot never controls more than two cargo, so how do you achieve that? Can you explain with your code?
Climber
Besides, can you introduce how your scouting works and is it possible to customize your scouting?
Hi there! I’m the robot programming lead for our team so I can answer the questions you have about our robot code.
Our code is public now, I forgot to make an announcement about that (sorry!)
FRC3476/FRC-2022 (github.com)
For context our hopper is large enough that we could easily fit 3 cargo inside of it. To try and stop us from getting penalized for this we added a beam break sensor where the 3rd ball of the robot would lie.
When we initially detect that the beam has been broken, we force the hopper to run. We do this in case we really only have 2 cargo and one just happens to be over the beam break sensor. This would move the cargo and unblock the beambreak if there was only 2 cargo.
FRC-2022/Hopper.java at main · FRC3476/FRC-2022 (github.com)
If the beam has been broken for over a second or so we procced to automatically hood eject a cargo to prevent us from getting a penalty (with the 3 second rule).
FRC-2022/Robot.java at main · FRC3476/FRC-2022 (github.com)
We could have used a second beam break sensor (or just better placement) because sometimes it was still possible for the third ball to get in a position where it wasn’t breaking the sensor.
For our climb we’re checking our roll angle and roll direction at certain parts of the climb to ensure we’re climbing at the correct parts of our swing. Here’s one of the cases where we do that.
If you’re taking a look at our climber code, it’ll probably be a bit confusing. Our climb steps are stored in our ClimbState enum which contains a ClimbStep Object. Each ClimbStep contains a begin action, a wait condition, and an end action. In our climber’s update loop, we’re checking the wait condition and if the condition returns true, we run the appropriate end actions and begin actions for the appropriate states.
If you have any more questions, feel free to ask away!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
