In order to simplify the design process, it was suggested on initial thoughts threads of the new game to start collaborating early for the late game elevating points. In this spirit, this thread would serve as an idea board to see what would work for multiple teams to easily achieve the elevating points with an open source interface, thus one can add ideas as well as modify and critique ones already posted to improve open source interfaces.
For the first idea put up I saw many good ideas on how to lift partners or have them drive up a ramp, but its hard to depend on the design of your partner to get the bonus (which includes where you could pick them up, would they let you pick up their bot, how heavy are they). Therefore, I suggest not worrying about if you can lift your partner. Instead design robot to lift itself which would simplify things in that you require one thing to grab on, you know how much robot ways, and you can do it every time no matter the partner. Say you put an eighteen tall pull up bar made of c channels on the back of your alliance partner’s robot. You grab on and pull yourself up using the wall for balance similar to toss up. In order to not tip your partner use a one time piston to release an anti tip bar(s). Even better use a winch on the back that hooks on and you also have a 18 in pull up bar on the back of your robot too and now the c-channels on each bot can help guide the robot lifting straight up just like a linear slide.
Pictures:
Side View Normal
[ATTACH]9245[/ATTACH]
Side View Elevated
[ATTACH]9247[/ATTACH]
Back View Normal
[ATTACH]9246[/ATTACH]
Bill of parts
Pull up bar structure:
4 1x5x35 c-channel
2 1x2x35 c-channel
Anti Tip Release:
1 single acting piston
1 solenoid
1 1x3x25 c-channel
2 standoffs
Hook:
1 1x5x5 c-channel
2 Rubber bands (to keep the hook at the top of robot during match before it gets pulled down)
Elevating Mechanism:
whatever your want, early season suggestion 1 motor winch and string.
Disclaimer: I have not read all the rules so some of these ideas could be illegal. Second you can use any design you want; this is just to simplify the challenge for teams that would like to discuss ideas on this thread instead of designing for a cooperative element of the game in isolation ways to pick up bots between 10-20 pounds with multiple different shapes and unique designs.
Let’s just let teams come up with their own interesting & innovative lift designs…let them work their minds creatively…this open source thing is horrible for design creativity…especially at this super early time of the season…what fun is it to have a bunch of robots with the same kind of lift…
I can prove that no three positive integers a, b, and c can satisfy the equation a^n + b^n = c^n for any integer value of n greater than two, but this margin is too narrow.
The idea isn’t to standardise robot designs, just to standardise the interface between robots. An example of an interface standard is USB - you can make all kinds of devices that have USB ports, and all kinds of devices that plug into them, but the standard means they can work together.
Or heres another idea, instead of lifting robots, what if you have a fold down ramp that allows other robots to drive onto a platform on top of your robot? i think 18 inches in the air is a high lift
After analyzing the game for a few minutes, I have devised a way to get the most guaranteed points (implying the robots can live up to highly theoretical situations).
To start, the two robots on an alliance are guaranteed 32 balls. Now if both teams manage to create a fool proof scoring system that is fast and reliable, they will score all 32 balls in the high goal. 32*5 = 160 points, the amount of points that they are “guaranteed” since the opposing alliance could some how score all of the balls on the field.
Now to introduce the climbing aspect. A “simple” method of climbing would have one robot lift the other to a low elevated position, scoring 25 points which is 15.625% of the current score in this theoretical match. A better method would have one robot lift the other to be deemed high elevated, scoring 50 points, or 31.25%. In skyrise, the highest scores in the season were around 100 points, which would make the autonomous period worth about 10%. Autonomous was a deal breaker this year since matches would start to become nearly completely scored at the end. Because of these scoring percentages, we can understand how important it will become to elevate the robots.
Now in order to receive the maximum amount of guaranteed points, both robots should be high elevated, scoring 100 points, or 62.5% of their match score. The definition of elevated is as follows:
It is touching the other Robot on its Alliance
The Robot that it is touching (see criteria #1), is entirely within the Climbing Zone
It is not touching any Field Elements, excluding the field perimeter.
The entire Robot is completely above the plane parallel to the foam field tiles, formed by the
top of the field perimeter.
so technically 2 robots should be able to be elevated.
In order to achieve maximum elevation, the following “universal climbing mechanism” could be used:
note how the robot is balanced on the corner of the field so that both can be above the perimeter.
Because the robots both would start inside of 18, any robot could utilize this method, and any robot should be able to be lifted. Of course, the way it is accomplished can vary so creativity can still be applied.
It’s so crazy, it might just work. But then it could also violate some rule I may have missed. That’s just my super theoretical two cents.
You’ve missed something, both robots have to be fully within the climbing zone. The robot that’s extended over the field perimeter isn’t fully within the climbing zone, so only one of the two robots is considered elevated.
darn my selective seeing eyes. I skimmed and thought vertical was horizontal:
The volume formed by the infinite vertical projection of the outer edges of the tape
lines and field perimeter bounding the four (4) foam field tiles located in the corners of the field
adjacent to the Alliance Stations.
The lifting robot could perhaps balance on top of a few game objects, achieving a low elevation and high elevation, scoring 75 points.
Wouldn’t work. The balls are only 4" tall. Even if you managed to get the robot on top of them, they will either smash down dropping you below the Low Elevation height, or your robot will tip and drop below the height.
You would need to build a sizable pile of them first. Which is a waste of time.
Good point. So even without the second robot 50 points is still a decent amount, I think a forklift style elevator could still work, especially with 30 seconds to lift it. If I recall correctly, in round up some robots could hang or lift the heavy field objects with elevators, so it might work in reverse.
SG 10: Robots may expand beyond their normal maximum **perimeter **of 18” by 18” only while completely within the volume of the Climbing Zone. Robots may expand above the 18” height limit while completely within the volume of the Climbing Zone and with less than thirty seconds (0:30) left in the Match.
Actually the way I interpreted it, these mechanisms are legal (I have the important word bolded). A perimeter only includes the length and the width so as long as the expanding robot stays inside the climbing zone’s volume it should be able to expand in all directions. Therefore, as long as the tip bar or forklift and the robot stay inside the climbing zones lines they should be legal at all points of the match. Now to lift above the height that would come with thirty seconds left or less within the volume of the climbing zone. (which is why it is explicitly stated on its own). That’s is how I interpret it.
Working off this idea, I was thinking about what common structure on the past robots that could act as the interface with which teams work off of when designing their robots to achieve the elevating points. With respect to ideas for elevating mechanisms that have already been discussed on the forum including ramps, pull up bars, forklifts, rack and pinion jacks and others just hinted at, I looked at what they relied on to work. These include drives with wheels certain distances apart to go up the ramps, cross bracing and vertical structures to be used as a pull up bar, raised chassis to slide fork lifts underneath, and top supports to hold a robot jacked up onto the other. I see the common component that they rely on to work as the 18" cube size restraint applied for most of the match this year. Since teams will need to be inside this restraint except for certain zones and times it is assumed that they will use the full extent of its size in which to put the functions of their robot. Therefore, if teams had 18" long support structures on their robot so that all dimensions of the cube were formed, a designer can rely on this to design how they can use those beams as places to attach, lift, or land on to get elevating points. Thus I propose, the interface to be that a robot has the shape of an 18" cube formed by cross bracing with which teams can interact to get elevating points. I think this would allow the ideas already expressed to work and provide a basis for multiple mechanisms to be designed off of.
tl:dr) In order to provide an interface that works with multiple elevating mechanisms, I suggest using the standard 18" cube size restraint as the general shape of the robot through the use of support structures. This will provide points to lift, grab, land on, and place a ramp under. What are your thoughts on using a the size restraint cube as the interface?
I don’t really think “Open source” elevating mechanisms should be a thing. I went to worlds this year to watch, even though my team did not make it, and design convergence is real. I saw one or two robots that weren’t a double reverse N-bar or a scissor lift. If everyone on the forum agrees on one elevating mechanism, it just causes the robots to all become more similar.
Robotics is about innovating and making your own design that works well, so I don’t believe that this is very healthy for the competition.
When I decided to create this thread, I did so understanding that people dislike blatant copying and other things of the sort that lead to design convergence as seen in previous threads over the years (https://vexforum.com/t/copying-robots/17227/1 and https://vexforum.com/t/depressed-over-me-too-designs/23240/1).
I have now fielded two posts feeling that this type of discussion is not healthy and horrible for VEX as well as just wanting the game to play out without collaboration between teams. I am aware of your concerns, but the real point of this thread is not to force design convergence upon teams but to do what Oliver W said.
I have highlighted some of my main points as well below from my previous points.
Therefore, the only designs that have been discussed on this thread are ramps for teams to drive up which does not require any convergence between teams as long as they can drive and using support bars to allow other teams to grab, lift from, land on (which I think is dangerous but it has been suggested) or drive up.
If teams decide to use support bars (which they inevitably will, though not specifically for elevating purposes) or ramps, then yes robots will look similar. That is not the goal. As a designer I wanted to simplify the design process of the robot by collaborating on the VEXforum to determine an interface from which elevating mechanisms could utilize. I repeat a final time that the lift or whatever you want to get the elevating points is up to you. If I knew ahead of time that most robots have an interface from which my elevating mechanism work better it would take the really complicated challenge of safely obtaining the elevating points and make it much simpler. If you still feel that this is in someway degrading the learning aspect or spirit of the VEX robotics competition by promoting blatant copying and unwanted similarities between robots while ruining innovation please voice your concerns in the discussion. I want everyone to enjoy creating their own way of getting the elevating point; I just feel that nobody is seeing the point of this thread.
Taking a second look into this thread, I should’ve looked at it closer before replying. I guess it does make sense to collaborate on interfaces, I just took this whole thread the wrong way in my head. Thank you for clarifying that!
