Hello there! We are Team 2898 The Flying Hedgehogs. This is our first year with Open Alliance and we’re so excited to collaborate with everyone!
Some info about us: we’re based out of the Beaverton Academy of Science and Engineering (BASE) and Westview High School in Portland, Oregon. We have around 25 members and 3 coaches, along with a couple of online mentors.
We’ve been working on developing more organizational/instructional documentation to plan ahead for the future. We’ll be posting our resources over the course of the build season.
To get to the top scoring nodes, we would have to be very tall
It would be very hard to orient cones and pick them up from the ground
Cubes might pop if we use the same gripper for cubes and cones - we might have to make different types/widths intakes for the game pieces
We created a priority list and a list of archetypes, with more weight on the former. In past years we’ve chosen an archetype within a day or two of the game release, but this year, with the interesting game pieces, we decided to wait until we prototypes to decide between our two main archetypes.
Priority List:
Can drive - just a drivetrain, to play defense
Score low - we can push/snowplow a game piece into the bottom node
Score middle with one game piece - implying that we have some kind of intake able to pick up either a cone/cube
Auto balance - some kind of automated balance system for the charge station, either during autonomous or teleop
Dual game piece intake - being able to reliably do both game pieces in the middle
Score high - being able to score in the high nodes with both game pieces
Our two main archetypes based on this list were:
Substation robot - no ground intake, but able to take pieces from the substation and place in all nodes
The everything robot - has a ground intake able to pick up at least cubes from the ground, but ideally cones as well, and place in all nodes
Here is our strategy sheet, with a strategy matrix to see how many points we think we could get from each action, our priorities, and our archetypes list.
Our Week 1 update will include initial design thoughts, prototyping results, and other progress.
Heyo, I’m Ozy, one of the four programming gremlins on our team.
So anyway…
Programming update!
So far we’ve written the code for a few subsystems we know we need (IE: Arm, Driver controls)
We’ve also started on some ideas we had, like using the navX readings to get the robot to level itself on the charge station, however we are worried about how it will react to other robots docking. Another thing we started was a soft stop for the robot to slow down near the edge of community to not break the robots arm.
The only thing that’s been tested so far is the vision odometry code (Determining the robots position on the field using the distance from the April tags), and we’ve gotten some promising results.
Some other ideas for if we have extra time:
Using the reflective tape (Or hopefully just Apriltags if their precise enough) to automatically deposit game pieces)
Robot path find through the field (though detecting other robots will be a pain)
Hello, my name is Abhi, I am the design co-lead of our team and will be talking about our robot’s current design in week 4 of this build season
DRIVE TRAIN
We started by designing our drive train which is a west coast drive. We decided to use this because we have a lot of experience with this drivetrain and felt it would be effective at driving onto and over the charge station. We also decided to add an Omni wheel to the front to decrease our turning radius. We also decided to have our gearboxes in the back of the robot as we realized through sketches that ours was going to be very front-heavy due to the arm needed at the front of our robot. We also designed our drive train to be pretty skinny so that it was less of a concern that other robots would bump into our robot at the charge station.
ARM
For our arm, we originally decided to have our whole arm pivot so that we could reach the bottom, and the top goal we decided against this as we realized it would result in tall bot syndrome which meant the robot would be prone to tipping over. We also decided against this as it would be really complex and would not be feasible in the time we have. So we decided to design the robot arm to have the capability to be modified to tilt if in the future we wanted to reach the top. Our current design of the robot arm is shown below
MANIPULATOR
Original intake prototype
Our original idea involved having a dual-stage of wheels that are different distances from each other. The front stage is meant for cubes while the second stage is for cones. The main problem with this prototype is that it did not hold the cubes and cones well, meaning if we shake the prototype the cones and cubes would fall out
After creating this prototype we decided that we should have a closing mechanism with pneumatic actuating the manipulator’s arms open and closed after deciding this we created a prototype with static wheels and a pneumatic pivot
Second prototype
One thing we noticed when testing the prototypes was that it was very easy to pick up cubes while picking cones was very difficult as they tend to slip and are hard to pick up when tipped. Our design reflected this as we decided that the manipulator should be able to pivot up and down so that we can pick up cones that are standing up and are tipped down. Later we decided against this and just made it so our arm could be picked up tipped and standing cones in one position
Final Prototype
This prototype has a .75 bore 5 stroke cylinder which allows a higher range of motion which was needed to be wide enough for cubes to fit and have a small enough close position to grab cones firmly we then also had 4 driven wheels which can be used to make grabbing cones and cubes easier and also allows us to launch cubes and cones a little to get them on the high goal if needed (this would only be reliably used for cubes). Manipulator design below
