A lot of great ideas for lifting will be bounced around in the coming weeks and months. Based on recent discussions on an overly long bus ride home with VRC and VEX-U teams, it seems ramps will be a popular choice for teams. The problem is the variations of implementations that will undoubtably will arise, making it seem impractical. Like international rail gauges, it would be good to have some agreed guidelines, not implementations, so that alliance partner’s can have an expectation of driving up relatively effortlessly. The intent of this thread is to discuss the parameters for ramps and, hopefully, generate a general TaborRamp design document.
After reading the rules, I’m afraid ramps will likely be illegal. I encourage someone to inquire about the rules however a direct quote of rule
This technically only means that the HEIGHT Limits may be broken. No other limit (width or length) may be broken at this time.
I am interested to look into this and get an alternative, more detailed ruling at a later time.
Great job at worlds everyone, I had a blast!
James
The robot can expand horizontally at any point while it is completely within the climbing zone, and can also expand above 18" when there is less than 30 seconds left.
So ramps are definitely legal.
My naive interpretation is that if the robot is of legal perimeter and height in the Climbing Zone, the robot is allowed to expand as much as it needs from that point in the last 30 seconds in all three dimensions as long as the robot is in the Climbing Zone volume. I did not see any indication of not being allowed to completely expand inside the Climbing Zone, which is greater than 18x18
Still remains to see if ramps are practical way of lifting. Good to have engineering challenges.
Worlds was indeed a blast! VEX-U was epic - awesome robots by QCC’s Blue Roosters!
The big problem with this is to lift anouther robot you are going to have to lift them on thr side of your robot. Your robot will have to be more heavy than theirs in order to lift it otherwise your robot will just tip over so i think a ramp is going to be the most effective way to “lift” another robot.
I’m confused as to why this is called the TaborRamp, is this endorsed by Griffin?
I don’t think there is any connection, but it’s most likely being called this due to the hanging mechanism he made in toss up, which, to my knowledge, was a fairly universal and simple way to achieve a hang. I could be wrong about that though, as my first season was Skyrise.
Imagine the weight the other robot would put on your robot. Especially if it is heavy. Would be a huge pain in making a ground supported ramp. Ramp seems impractical for a good shooting robot.
Personally, I’ve been considering an idea with two c-channel ramps on either side of the robot, placing each ramp structure on an angle with the rest of the robot. The ramp would be flipped out using pneumatics, and the alliance partner could drive up the ramp without interfering with any of the systems on the robot. When I have a chance, I can also post a sketch of this idea.
Pretty sure that Griffin will weigh in on design and implementation of such a solution. So, might as well have the cachet associated with the approach to assure excellence in the discussion.
Well instead of relying on the other teams drive motors to have enough torque to get up your ramp why don’t you use a upside down scissorlift so that your robot can get above 18inches and let the other robot drive under you, then you lift the sisscor lift up so you are above 12 inches. That way you would be able to test the design your self and know you can lift yourself up. You can also leave the lift halfway down once your ontop of them to stabilize yourself. You can also cover your robots bottom with adhesive foam to make sure you don’t damage them and they don’t damage you.
Your not the first person who had mentioned this on the forums. personaly, I think you are more likely to find a ally that will drive on top of you using a ramp, than a team that will let you rest a big robot on my possibly very precise and important mechanisms. I know I would not want your robot sitting on my robot. What if you break something and now I am out for the competition? Or what if your robot doesn’t sit on my robot properly and your robot falls off and breaks? There is just too much risk in this design for both teams involved.
Nobody has ever made a robot with a ramp before, must name it after someone.
SarcasmI hereby claim that any robot that uses a battery must be named after me.Sarcasm
Seriously guys? :rolleyes:
I’m in - BrennanBatteryBot framework it is! 
Clearly, a requirement of a TaborRamp should be to not damage your ally’s robot. Perhaps a winch mechanism will aid those underpowered robots to make it up the incline.
How steep is too steep of a grade?
I would be very curious to see how a winch mechanism would work. Would it somehow hook onto the robot and pull it?
I’m sorry. I did not make it clear in my earlier post. That post was about robots trying to land on top of other robots and lift themselves up. That’s why I thought it was a bad idea. in that situation, something is bound to break. A ramp on the other hand, is a lot safer idea. you have roughly 30 inches of room for a ramp which allows for a 20-30 degree slope. and the robot that is under the other robot, is built to hold the weight of the robot on top of it.
Seems to work with a lot of tow trucks - so why not robots? That way you may be less dependent on the ability of your alliance partner to climb inclines.
It does work with tow trucks, but you have to pull the winch line out and attach the hook to the car. Attaching the rope to another robot seems difficult, especially as each robot has different points where it needs to be attached.
The point of this thread is to identify the issues around a ramp approach and propose standards that other teams can use, such as max ramp grade, width between wheels, … so suitable implementations can be constructed. Otherwise, as you rightfully point out, there are too many variables that would cause ramp solutions to fail.