Day 4: Ground cone intake & cones on the substations
Updated Favorite Sketch:
Today’s update allows us to lower the cone pinch intake to the floor.
Our starting configuration would have the elevator raised slightly to allow us to fully retract the slider.
With this we will likely need more extension than a single-stage elevator can provide, but we are still working on the sketches. A two-stage elevator is easy enough for us to build.
A two-stage elevator will also let us have a lower starting height and lower CG when fully retracted, so there are additional benefits for the added complexity.
Cones on the Single Substation:
We played around with multiple ways to stage the cone on the single substation so it is stationary. This allows a robot to intake it without waiting for the HP to drop it.
This specific setup is likely not repeatable but using a third cone with the cone flange past the rear lip of the ramp or by using the chute door to stop the rear cone from sliding should work well.
Cone Orientation on the Double Substation Shelf
It appears possible to place the cones sideways on the shelf in the double substation. This allows robots that can intake cones in this orientation to use the shelf instead of intaking from the floor. This orientation also lowers the tip of the cone so a robot doesn’t have to extend as high to pinch it. It may be possible to place the cone in a way that allows the tip to hang over the edge of the shelf as well.
our team is too, i dont see any downside to a retracting arm with a semi fixed angle (has to go down to pick up) other than that it will likely be the design of the everybot based off its goals and the fact that everyone has a climber from last year that they will use for the same or similar thing.
Day 5: Idea Refinement, Pincher and Launcher prototype.
It’ll be a short one today yesterday!
Today we refined our current design, including working out most of the 2d geometry before moving on to 3d geometry. We will be building an “alpha” robot this weekend to prove our current theories and to be able to rapidly iterate on game-piece manipulator prototypes with the strictness of a robot chassis. It will also allow our controls team to have a robot to test control ideas with.
A significant change to our design is that the elevator is now in 2 stages. This allows us to keep our CG lower overall and extend higher. Here is the sketch now; it might be more confusing than helpful at this point, but I’m willing to answer any questions you might have
I just wanted to make sure I understand how the reference cube works. For each part studio in each Subsystem document, you first create a reference cube in that part studio. Then you can insert that reference cube into the main assembly document, aligning it with the reference cube in the main assembly. Then you can edit the sub-assembly part studio in context while in the main assembly document?
Each Part Studio derives in the reference cube (you could make them in each document it doesn’t matter that they are the same)
Insert the reference cube into the System Assembly (intake, elevator, etc)
The system assembly is in the Main Robot assembly and when you update references in the system assembly you’ll be able to right-click on the correct reference cube and edit in the context of the whole robot.
Oh I forgot deriving is specific command. I made a couple of test documents, does this model tree look basically like what you are talking about? And when you insert the sub assembly in the main assembly you just do a fasten mate between the sub-assembly reference cube and the main assembly reference cube to constrain it?
Apologies if this is kinda off topic to your build thread, thank you for putting this all together!
A short video showing how to set this up within part studios/assemblies, and how to use them in the intended way (for editing in context, simplifying top robot assembly, etc.) would be quite helpful, if you are ever able to make time to do that! I feel like this tool can be really useful but it’s a bit confusing how it works.
Also, in reference to your Q&A question, I believe the wording within these highlighted parentheses in R402 points to your scenario being illegal, since the robot configuration would change (the component/extension/stinger would have to flex or move upward) in order to rest flat on a floor.
This is my own interpretation, it is possible that LRIs or referees would interpret this rule differently.
The exact quoted text in our question is from a Q&A in 2018. They gave a similar response today as they did in 2018 and in 2018 you were allowed to deploy forks/ramps below your robot as long as they couldn’t support the robot weight (folded up when robot transposed on to a single flat plane). I wouldn’t assume the intent of the rule and ask more Q&A questions to gain clarification.