NbN OpenLift concept - legally lift with 16 motors

VEX Robotics Competition Discussion VRC > Nothing But Net (15/16)
1

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):

  1. NbN OpenLift specification only defines simple robot-to-robot interface, not a lift implementation.

  2. 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.

  3. Passive liftee robot, will essentially sport a permanent fixture that you will define for #2

  4. Active liftee robot, will be sporting liftee part of interface, and will be providing lifting power.

  5. Active Lifter robot, will be sporting lifter part of interface, and will be providing lifting power.

  6. SuperLifter will be able to play dual role of #4 and #5.

  7. 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.

2

What about this?

The lifter uses verticle rope/winch system to hook onto the liftee, while liftee has Omni wheels on the base sticking out. As the winch pulls, the wheel of the liftee natually latches onto two stripes of vertical structure on the lifter. The liftee transmit down their 8 motor drive to low gear and use their wheel to try to vertically drive up the lifter, providing assist to the lifter’s motors.

Sounds cool. And yes, 8 motor drive 8 motor drive 8 motor drive! Make one if you can make one.

3

See, this is what I was afraid of in all the threads about “Open-source lifts.” This kills originality and will cause design convergence to occur even faster than last year. It also effectively negates the elevation bonus for matches where everyone uses it, and actually penalizes teams that don’t or can’t, because their robot design can’t support it.

4

Realistically, did you not expect design convergence to exist this early, especially in a game such as this where you are forced to directly interact with your alliance partner. I know if I was still competing at the HS level, that I would very much want some sort of standard to arise, so that teams could be on the same page. As an honest question, how do you expect elevation to exist without some level of design convergence? If you have two teams with wildly different strategies for elevation, I would wager a guess that in most cases, both wouldn’t work with the two robots, causing two potentially brilliant, creative teams to lose to teams with design convergence that can actually work together.
Also nothing is inherently bad about design convergence. As long as teams take what they see and improve upon, not just clone, then it is absolutely fine. Everything we do in VEX is an inspired idea, either from ourselves in previous seasons, old robots, the rest of the world, so what is wrong with taking inspiration from another competition robot?
As an aside, I understand the frustration about design convergence, as a lot of what is seen is just blatant copying, but design convergence in and of it self isn’t the cause of that.

5

I’m neutral when it comes to whether or not an elevation standard should be sought, but I do wonder about the implications of NBN’s elevation aspect. It’s not unusual for a single school or organization to show up at a tournament with a small army of robots that look somewhat similar. Kids in a club tend to borrow ideas from each other, or receive guidance from a mentor, or from a dominant team, etc. So I could easily see the kids from a single organization showing up with their own home-grown “standard”, which at the end of the qualification rounds might cause teams from a single organization to pick each other during alliance selection. I’m not sure that’s a good thing or a bad thing, but I can see how it might result in larger organizations dominating tournaments in ways we haven’t seen in the past.

6

Actually, fairness was one of the requirements, that went into this concept: two robots that provide active power should always outlift (save time) another alliance of compatible lifter and passive liftee.

Another consideration was to provide as much freedom as possible for the actual design implementation. In this standard all you have to do is have an attachment point on top of your center of gravity. And it is totally up to every team to implement the rest of hardware.

This standard mandates minimum hardware requirements for the interface and leaves everything else to be designed, tested, redesign, … forever and still be compatible every single time.

Myself I could see at least two different designs for the lift and I couldn’t decide which one better. There could be many more good designs for lifters. One of them as simple as 3 1/2 c-channels + some attaching hardware for the SuperLifter. It will be all about effective management of center of gravity.

7

Please use graphs in the “rev2” version of that analysis.
Motor torque-speed curves - REV2

Long story short, spec for the 393 motor was originally incorrect in the documentation and was revised in 2012.

I think 20% is a bit on the pessimistic side. The linear lift I was working with last year seemed to achieve somewhere around 70% when I aligned theoretical calculations with actual performance.
triple lift preview - post #47

My gut tells me that teams will lift alliance robots with far less than 16 motors, we saw plenty of fast “high hangs” in toss up with 4 or 6 motors. Same back in roundup when we had even less total motor power available. I think a bigger problem will be management of the COG, my 10lb robot tries to lift your 10lb robot and we just tip over when I start to lift you.

8

I was thinking about rope and pulley when I wrote 50%. Yes, if you use chain on a larger gear you could, probably, get higher number. My main concern is the friction for a pulley or gear on top of the boom (or another structure).

But this could be countered if both robots apply the power. Then Lifting robot could pull the rope at half (or less) the speed.

Yes, 16 motors is definitely overkill - I just put it in to underscore that with dual power source it is legal and possible. 12 or 10 wouldn’t look that good on the subject line - my problem is that I keep thinking in terms that would be resonate with early teens. :slight_smile:

The COG is a concern, but I could imagine a couple of very good stable geometries that could be implemented with significantly less materials and complexity than ramps or forklifts. Managing it should be a very interesting challenge and great source of design diversity.

9

Additional OpenLift properties:

  • simplicity

On the lifted robot attachment point could be a simple 2" zip tie, rope reinforced, ring. It should be mounted above robot’s COG at 16" height. To accommodate deformation of non-rigid ring lifting robot needs to make sure its lift could move at least 15" up.

  • linear power profile

Winch is a natural choice for this type of lift. However, depending on the other design choices and the way power will be sourced from the robot, anything else that could move attachment point 15" up should work.

  • efficient resource utilization

Alliance may use all of its combined lifting motors and battery power at once. This will result in time savings.

  • reliability

Having two lifting power sources will provide a number of backup options

  • adjustable power contribution

Depending on partner’s weight and power availability some designs may be able to adjust lifting gear ratios before the match. Also, alliances may decide how much lifting power each robot will provide if it may be needed for other tasks.

  • parallelizing tasks

There are three lifting phases: lifting structure unfold, OpenLift interface hook up, and actual lift itself. Depending on robot designs and power availability some robots may continue scoring driver preloads during some or all of those tasks.

  • design convergence concerns

There are a number of different designs suitable for lifting robot. I find one of the crane types to be almost a perfect match for NbN game, but it is a personal choice. Anything that could lift attachment point 15" up considering COG concerns should work. Unfolding of the lifting structure as well as decisions on how to source power for the lift should lead to multiple good designs.

  • limitations

First of all, 2" ring concept and possible hook designs need to be field tested. Particularly for the easiness of hook up. Several relatively easy designs to stabilize the hook may be used.

Simplest mode of operation is if lifting robot provides all the power and lifts attachment point from 16" to 16"+15" = 31".

If both robots provide lifting power and attachment point starts at 16" then it needs to move inside the lifted robot. It will be very easy for some of the low built robots and will give them competitive advantage.

If high built bottom robot needs to provide all lift power and if top robot has high geared wormgear winch then top robot could first pick up the slack before motor slows down under load.

  • Unresolved choices / future specification considerations

However, if hook needs to travel inside the high built robot then slimline and standardization of the hook interface may be necessary. This would put additional requirements on both robots.

A workaround in this case would be for a bottom robot to come with its own hook to be attached to lifter that will be slim enough to go inside.

Alternatively, there could be a nonlinear winch design where bottom robot leaves some slack and top robot picks up the slack on the first turn. This puts additional requirement only on top robot.

Finally, if bottom robot has a release mechanism it may deploy attachment point to start in predefined (before the match) location anywhere between 16"-30". This puts additional requirement only on the bottom robot.

Without some field testing it is unclear which option is the best or if power sharing will be an important enough competitive advantage to justify extra design complexity.

10

You seem to favor lifts. Any thoughts about deploying ramps?

11

Actually, when TaborRamp thread was created I started thinking hard about ramps.

Initially, it seems to be very good choice because any robot could just drive up. But there are way too many unknowns.

What if the other robot is too wide to go on 18" ramp? You need to provide extra flaps.

Where would be other robot’s wheels? How heavy is it? You need to know how strong the ramp should be, where to have supports.

Will any robot be able to drive up to steep ramp? If not, then you need to have a winch. Which needs easy and speedy attachment. It will take time, you may just as well use crane.

Then you will need to either have flat part of the ramp, above 12" where robot needs to park. Or you need to lift the ramp once robot is on it.

When everything adds up there is no place on robot for everything else except unfolding ramp.

To remove unknowns everybody needs to build to some roughly predefined wheel base and drive-train specification which is nonstarter.

Real life flatbed vehicle transporters are good, but main trick there is a winch and you need a person to hook it up to random car.

Then there are alternatives to ramps discussed in this Open Source Elevating Mechanisms thread. Some of them are better then the ramps.

But main objective is still you either need to put something complex on the random partner robot, or the mechanisms to support a random robot makes your robot too complex.

So I started applying the optimization to all those unknowns and logically concluded than a linear vertical lifting motion by hooking it at single point is still the best option in a very limited time we have to do it.

So we are back to real life analogy - what do you need to lift an arbitrary heavy object? Crane.

12

I’m confused. A roughly predefined wheel base is a non starter, but everyone agreeing on similar “open” lift designs isn’t?

From my VEX experience almost all robots have always used a generic 17.5" x 17.5" style chassis. I would think a ramp would be relatively easy.

Anywho…I personally am not a fan of all this ‘open’ concept stuff. I can already think of several ways to achieve low or high elevation without any special fittings on the robot that is being lifted. I’m sure others have ideas as well, but prefer not to share for the sake of the design convergence issue. (if you believe that is an issue)

That being said, I also have no problem with people seeking a universal lifting mechanism…it’s just not my cup of tea.

(rational = if everyone gets the high elevation bonus because of all this open concept stuff…then whats the point?)

13

Ok, I have pretended that I am building a ramp and run some calculations.

Worst case for power: if your partner robot has two-motor direct drive on 3.25" wheels (assuming 0.75 efficiency) it could barely make it onto 30" ramp, maybe not. Four motor drives should make it.

Assuming no robot is narrower than 15" then worst case for dimensions: 5" omnis in X-Drive and 1" placement uncertainty will require two 5" ramps with guides. You can put plastic sheets on 1x5x1x35, but then you have to add anti-slip on top of them and you cannot use glue. You must secure it properly or X-Drive or mecanum could damage it.

Double 5" ramps will take at least 2 x 18"*5"*3" space + deployment mechanism and weigh at least 8 lbs.

If you are building ramp without gap in the center that it must weigh even more and could take all your top space above 12".

I am not going to argue that ramp has two huge advantages:

  1. You do not need to modify the other robot at all.
  2. You don’t need to allocate motors to it - partner’s driving motors double for “lift” function.

And it ties with OpenLift on linear power profile.

But there is one huge disadvantage of the ramp:

Do you know what percentage of the robots that are going to make it up to the ramp. I’ve certainly seen some robots that will never make it, especially with the gap. Do you simply not care about partnering with them in qualifiers? Based on what I’ve seen I would say 8% will not make it, but that is just a guess.

On the other hand, if somebody creates a thread, and asks people to post details about their last or current drive-train specifications: configuration, wheel type, dimensions, number of motors, gearing, weight of the robot. What is the highest inclined slope covered with anti-slip that their robot could climb? How long it takes to climb it?

If numbers are good then it will turn into advantage.

OpenLift could work with any robot, regardless of their drive-train.
By weight I think on OpenLift implementation could be under 4 lbs.

Also, can you build a ramped robot that will shoot driver preloads while the ramp is extended? If yes that it is big plus.

Let’s put it this way - if people are going to dedicate motors for the lifts then OpenLift is way to go. However, if few are going to do that then it makes sense to be building a ramp.

14

8 lbs! Holy cow…entire robots have weighed that much. That’s one heavy ramp!

There are designs that do not require anything special from the alliance drive-train or special attachment structures. I have 2 ideas on paper that should work already…I’m sure others do as well, but prefer to not give all the secrets away.

Your assuming I need a ramp. I do not. I have a design that does not involve a ramp and does not require the alliance robot to have any special fittings to grab onto.

There are more ways to get a robot into the air than just a basic ramp or hook/lift style setup!

15

4149G,

You brought up several very interesting points. I would like to address all of them. But, first, let me describe how I came up with my numbers.

When calculating worst case power scenario I assumed a 15 lbs robot with 2-motors directly driving 3.25" wheels with 0.75 efficiency. At max power, provided by motors, you need ~30" ramp just to get over the gravity to 12" height. Anything steeper and you simply don’t have enough torque to move it up the ramp. I could be wrong in my calculations, please, verify if you think it is too conservative.

Then for the worst dimensions, I assumed X-Drive with 5" omni wheels. If there is even 2" uncertainty where they will be placed you will need 5" wide ramps at the very very least. Also you need to provide some guides on the outside, but they need to be designed carefully so that back omnis don’t run into them and jump off the ramp. Let say, we figured that out.

I was thinking about 6 * 1x5x1x35 aluminum c-channels for ramp base. With 5" wide plastic sheets covering 30" ramp + 16" flat top.

But let’s be extra frugal. Instead of 16" flat top we will mount last segment inclined, so that when robot arrives at the top, then it will flip. This will let us shorten ramp + top side, to say 40". Finally, we will use 1" narrow 1x2x1x35 for ramp supports.

We need stands in the middle of the ramp and stands for top segment. Also, we need some cross supports, because mecanum and X-Drive will generate some horizontal forces. When everything is done you will need at least 10 * 1x2x1x35 aluminum c-channels @ 0.361 lbs each.

Then you need to extend both ramps from 1" to 5" width with some tough plastic and bend some guides. In my estimation you will need about 1.3 lbs of ABS to cover both ramps.

So there you have it - 5 lbs just for basic parts. When you add deployment mechanism, anti-slip cover, fasteners, connectors, gussets, nuts and bolts - it will easily add another 1.5 lbs.

I think you cannot build the ramp with less than 6.5 lbs, unless you cut more corners and exclude more partners.

I cannot read your mind, 4149G, so I’ll just stick with ramps.

The main advantage of the ramp is that you don’t have to allocate any motors to it. Your partner provides its own drive-train power for lifting. And it has linear profile.

The limitations of the ramps are:

Static robots, too narrow wheel bases, kiwi drives, or underpowered drive-trains will not work.

If partner suffers some issue it will not work either. You always need both robots to work, in order to get elevation points with the ramp.

Its weight is not insignificant and it takes some premium space. I am sure those cross supports will pose challenges for designing other sub-systems.

Then there are game strategy concerns - you need a lot of space to unfold. So you need to make sure there is no balls there. What if opposing robots push some balls at you when you unfold the ramp? What if they park in front of the unfolded ramp, just outside of climbing zone, to prevent your partner from maneuvering onto the ramp?

So at the end you have a design which wouldn’t work in 10% of matches on the state level and 5% on the worlds’ level (I am guessing but it will never be 0%). Or it could be even more once people figure out successful denial strategies against the ramp.

If everybody were building their drive-trains to some common TaborRamp standard it would be much more tempting to build the ramp. But I don’t think it is the case.

16

I guess I just think your being fairly pessimistic with those numbers. I may be proven wrong though. Lets just say this…we had a Skyrise scissor lift that reached 6 feet tall and it didn’t even weight 8 lbs (with our intake attached to it!). (yes we documented all of this)

Anywho, my main point was that there are other ways of obtaining elevation that do not require ANY assumptions about your alliance robot. All of this “open” discussion stops people from brainstorming more ideas because they may feel like they need to be a part of the trend (so that they will make good alliance members). They then accept these ideas on the forums and do not push themselves to consider alternatives.

But as always…to each their own. If people want to participate in this open concept of design and it works out for them…well…good for them.

17

4149G,

If you get an impression that I want to discourage you from developing new ideas, that is not true. Just the opposite. I really want you to consider as many new ideas as possible. I just want you to have more information at your disposal. But it is up to you to make final decision.

I posted my thoughts about ramps - it is just my opinion and I frequently make mistakes. If somebody could spot a flow in my logic they could correct me, but at the end, when you read all opinions, you will have more options, not less.

For example, there are many good things about ramps. If you make a full ramp (without gap in the center) you will be able to accommodate more partners. But you will have to pay for it by extra 1-2 lbs and most of the remaining space above 9" to 15" diagonal plane (if top segment will be tilted). It may end up working very well for you. I don’t know.

Again, I don’t know what is your design. I just want to compare several potential designs with my OpenLift idea. If somebody sees flaw in my reasoning, I will be most happy to know it, so I could either fix my flow or accept their better idea and save myself some time.

There could be only two viable options that fit your description and both involve a lifting platform, as far as I could imagine. I am not going to consider bare forklift, since you have no idea how random partner base is organized. And I am not going to discuss an option where you have some sort of re-configurable grips, that you will change for every partner.

If only assumption that we make is that partner robot has wheels somewhere inside 18" x 18" square, then it has to be a platform without any gaps. To make such platform you will need at least four 1" c-channels and 18"x18" sheet of tough plastic.

Then there are two options. First is a forklift style, where you have two lifts between yourself and platform and balance it by your weight. The second option is to have several lifts around platform with support base that will include your partner’s COG.

In case of the forklift or second option with two lifts, you will need not only have some lifting power, but deal with some non-trivial torque if partners COG is far from your support base. Regardless of how you do it, you need some lifting mechanism, some power source and at least 40" worth of the additional c-channels.

If you go with three lift supports, you wouldn’t need to deal with the torque but will need another 20"+18" of the c-channels. Finally, you need to route power to 3 points. You either need some extra motors or some transmission to source it, for instance, from your drive-train.

At the end of the day you are looking at 8+ c-channels, flat piece of plastic, and some tricky deployment and transmission mechanism. If you can cram it into 5 lbs by shaving all unnecessary metal you are Pro!

I have to leave now, because, tomorrow early in the morning, I am taking kids to science festival. But later, I will do another post, where I will show how you can build two types of cranes (gantry and derrick) with 6 or less c-channels and a single power delivery point.

18

Very true. I appreciate your opinion. Thank you for the constructive discussion.

19

Derrick crane is simplest, most resource efficient type of crane that you can have.

If one corner of your robot has support at 17" height, then you could have there an attachment point for 24" boom and 18" vertical pole. When folded both could be stored at the top of your robot diagonally. Once deployed, there will need to be at least two strings to stabilize the pole to your base. Here is a picture of a derrick:

Note that if both robots’ COGs were at the centers, then diagonal boom placement creates ~12" lever for your weight against your partner’s 9" lever. You may want to deploy some sort of outrigger in front of your robot to relieve load of both robots’ weights from the corner wheel’s axle and to add a few inches to distance from the edge your robot’s support base to its COG. Without outrigger you can only lift a partner of 4/3 of your own weight. Here is a picture illustrating that:

Finally, the boom needs to have some swing around z-axis (pole) to prevent any side loading issues. You definitely don’t want to have a Big Blue collapse moment.

An alternative to a simple Derrick could be a double boom design, where you would replace a complex swinging joint with an extra c-channel. Take a look at AL.SK190 to see how it looks.

Conclusion: the simplest Derrick could be implemented with less than 4 c-channels and some rope.

20

Interesting lift design. This is definitely possible. It is possible to supply the power needed to lift the other robot aside from an effective drivetrain and accurate shooter. I really want to see a good robot with a nice crane style lift that can high elevate.