Senior VEX-U teams will say: “Ha, cheap headline, we knew this trick for years”.
16 motors is definitely possible and legal. But do you really need so many of them?
To answer this question we have to talk about power and how it relates to time. This thread has Motor curves that everybody should know.
Let say our partner robot weights 20 lbs. To lift it 12" you will need to perform 2012 lbs-in units of work.
If we run a single motor @ 60 rpm it will deliver 5 in-lbs torque. Even though units look the same they are different.
The easiest way to imagine how it relates assume a winch with a spool of 0.25" radius. At that radius winch could conveniently pull 20 lbs weight and on each rotation will pull 2pir = 2pi*0.25" = approx 1.5" of rope.
At one 1 rpm (rotation per sec) you will need 8 seconds to pull up a 20 lbs robot 12" up with just one motor. Wow!
Middle school physics says one motor is enough! Engineering 101, is more pessimistic. Even the best teams will not be able to pull it up without some noticeable loss due to friction.
On average you are, probably, looking at 50% efficiency or worse. There is no bottom, depending on your lift design. Usually the more parts are in your lift the more friction you have. Also, note that our ideal winch has constant pulling force, while complex lifts will sport nonlinear relation. For example, some periods of the lift may require twice as much peak torque while other only half. It all will depend on your design.
But let say that you are smart to pick a linear design and your efficiency is 25%. This means that with a single motor you will need 8*4 = 32 seconds to lift the other robot. If you had 2 motors it will take 16 sec. With 8 motors - only 4 sec. And if you managed to employ all 16 motors it will be up less than 2 seconds! So 16 motors are clearly overkill, but 2 motors are just to slow.
So how many motors you should allocate? I don’t know, it is up to individual designs. You have to decide how much time you are willing to spend lifting your partner. If you don’t have enough motors to spare you pay in time.
In all robotics competitions you have limited time. There is always not enough time to finish all your tasks. Only few teams in a handful of matches manage to score all their objects and dance.
Time is everything. For example, we started Skyrise season late. We didn’t have enough field time for our iterative engineering process. We choose reliability first, accuracy second, and just didn’t have enough those engineering cycles to improve our speed. We did ok and manage to get to states, but I keep teasing technik jr that in their best semi-final matches they were consistently achieving in full 2 minutes what Team 62 did in their 15 sec autonomous (full Skyrise + 1 cube).
As you may have guessed it, the main idea of the OpenLift is that both robots could provide the lifting power for faster operation.
Lifting robot would essentially be some sort of a crane with a winch or arm going down. There is a number of possible implementations.
The lifted robot could have a ring that will be hooked or vice versa. Once both robots hook up one or two could start the winches.
Lets list all the requirements for the future Open Source lifting interface (NbN OpenLift v1):
-
NbN OpenLift specification only defines simple robot-to-robot interface, not a lift implementation.
-
There should be no requirements expected from non-complaint partners, other than simple modifications that should take no more than 5 minutes to implement and do not require re-inspection. If partner refuses modification you just don’t do the lift.
-
Passive liftee robot, will essentially sport a permanent fixture that you will define for #2
-
Active liftee robot, will be sporting liftee part of interface, and will be providing lifting power.
-
Active Lifter robot, will be sporting lifter part of interface, and will be providing lifting power.
-
SuperLifter will be able to play dual role of #4 and #5.
-
The interface should be optimized for reliable speedy connection. This is just important as lifting time itself.
For example one robot just drives with a string loop onto a hook.