![]() |
Linkage Design Problem
I'm thinking about a revision on the crab design, but I have a problem. I need a rather complex linkage, but I have no knowledge in vector calculus. The linkage needs to transform a linear force into a 90* arc. Anyone versed in 37 bar linkages?
![]() (Sorry, about the horrible illustration, but Paint isn't my forte') |
Re: Linkage Design Problem
A lot of these sorts of mechanisms will have sinusoidal motion—the path can be anything, but the timing between points is sinusoidal. So, in general, are there any timing requirements? (This also doesn't account for the actual behaviour of the actuator, since it also needs time to accelerate; this assumes that the thing is operating without regard to dynamic effects.)
Also, what's following the arc; can you put a pivot at the centre of the arc, for example? One simple example of this kind of motion would be a flexible rod attached to a piston and a pulley. Start with the rod wrapped around the pulley, and pull it to go one way. Push on it (so you can't use chain or string) to go the other way. If you don't mind pivoting the piston, and don't mind rather uneven forces, you can also just attach an arm from the rod of the piston to the centre of the arc, and pin the tail of the piston in place. When the rod extends, the change in length causes the centre joint to move along an arc determined by the arm length. Another idea would be to take a section of a gear, and a piece of rack. Just design it so that one extension of the piston corresponds to 90° of rotation. (Are the given direction arrows critical? Because if so, you'd need to actually reverse the piston output as part of the linkage—that seems like a waste.) Lots more possibilities exist; a better idea of the application would help. Are you trying to move the drive modules with this, and if so, why only 90°? Also, what level of complexity and cost do you want? |
Re: Linkage Design Problem
Perhaps I'm misunderstanding the design problem, but why not apply the same design used as a steam locomotive driver to this circumstance? It's quite like one of the solutions Tristan mentions above, but you can fix the piston or screw in position.
|
Re: Linkage Design Problem
Basically, the concept is to simply slam the drive module around a pivot 90*, so as to afford a sort of reversable drive- in one position, you drive length-wise, slam it the other ways and you drive long-wise. The problem with the locomotive type linkage is that you basically cannot complete the entire turn in such a way. Either you straighten out the piston and it locks itself from further motion in the opposite direction, or you stop it prior to locking, and you don't get the full 90* turn.
This full angle is crucial to keeping full driving ability once the modules are turned: If the wheels aren't parallel, especially with a high traction wheel like we use, you grind your wheels and get horrible efficiency. And Tristan, the arrows aren't really important, the linkage will need to go back and forth, but the piston may pull or push either way- no problem. If such a linkage is possible, it would allow for a very quick reacting, smooth, "slam steer" type drivetrain. Push a button, and you're going sideways, almost instantly. And you get to keep the full traction of a four wheel drive. |
Re: Linkage Design Problem
1 Attachment(s)
Since you only care about the end positions, all you need is a piston and a lever. The piston does not need to go to its stops, put mechanical stops on the lever that can be adjusted to set the alignment for each wheel.
if fact, it could be spring loaded in one direction, so the robot will default to one direction if your pnuematics fail (or simplify your pnuematics so they are only driven in one direction. |
Re: Linkage Design Problem
I think you're trying to make what is known as a crab (aka swerve) drive. There are many post / half completed designs you could find.
|
Re: Linkage Design Problem
Quote:
Quote:
Well, it's more of a variation on the crab/swerve. The problem with crab/swerve drives is that because of their go-anywhere design, they require that their modules be turned by motors. This results in, generally speaking, a slow direction change, and long lengths of chain/ belt, or an elaborate gearbox- linkage mechanism. The advantage of simply choosing two module angles is twofold. First of all, you can more easily achieve near instantaneous direction change. (i.e push against a robot, and in 1 second be ten feet away sideways). Secondly, pnuematics in this circumstance offer a nice reliability factor. They are light, easily mounted, offer simple changeout, and if you jam a module somehow, they won't burn up trying to move that single module. Another benefit to this design is that you may stray away from traditional crab construction, which subject the bottom of the module to high levered loads. They are normally supported only by a teflon ring at the bottom of the module. If you only try to move the module 90 degrees however, you can move the pivot from the top of the module to the side, sort of like a heavy duty door hinge. In this way, you may make the hinge as beefy as you like to support the robot's weight loads, while the hinge's structure can more easily withstand horizontal impulses, the type most likely to see during a match. |
Re: Linkage Design Problem
Quote:
|
Re: Linkage Design Problem
1 Attachment(s)
Quote:
Keep in mind the piston linkage pivots at both ends (connected with bushings). As the piston in my drawing extends the piston will angle to the left. When the piston is at the center of its travel it is perpendicular to the lever. As the piston extends all the way it pivots back to the right, to end up in line with its starting position. At no point in its travel is the piston parallel to the lever. At the end points the piston is 45 degrees to the lever, which will give you 70% of the applied force holding the level against its mechanical stops. |
Re: Linkage Design Problem
i think the simplest idea would be a rack and pinion set up with the piston linked solid to the rack and the pinion would be at the rotation point
|
Re: Linkage Design Problem
Ha! I misunderstood your picture! That really is a good idea- I hadn't realized that you shifted the 90* movement 45*! Thanks! Evidently I can't use or understand Paint!
|
Re: Linkage Design Problem
Quote:
|
Re: Linkage Design Problem
Blair,
I think you are getting close to understanding why crab systems have evolved to where they are now. With the system that Ken has suggested (which I think is exactly the solution you were looking for) the side loads and frictional loads remain the same as a traditional crab drive without the ability to change directions incrementally. With only the 90 degree motion, you are limiting yourself to a defensive move that may not accomplish what you want. A true crab drive needs to back away before "exiting stage right" in order to break the friction with the robot it is pushing against. The side loads of an instantaneous change are significantly higher than a motor driven steering system. |
Re: Linkage Design Problem
Quote:
-dave ![]() |
Re: Linkage Design Problem
![]() Heres a quick drawing. The dimensions and proportions are way off, but it illustrates the idea well. Al, I did think about the friction between robots and the fact that you would still be locked in somewhat if you changed direction while pushing, but we normally have so much pushing force that I doubt it would be a problem. But even if we did get stuck, you could just back away slightly before switching direction. The other nice thing here, that I can't really illustrate without a full drawing, is that you aren't turning the wheel in place like a traditional crab, you are instead turning it in an arc, so the force required to swing the module should be far less, especially with a high traction wheel. |
Re: Linkage Design Problem
Andrew,
It would seem that frictional and side forces would diminish in the design, but in fact I think they are just transferred to a different part of the mechanism. Hopefully a mechanical person will step in here. Think about your scenario, the force of the robot pushing you is transferred to the floor through the pivot point for your steering assy. and wheel, bearings, etc. However, a move to disengage will add to those forces the turning forces that occur when the linkage is actuated to rotate everything. That plus the added weight of the robot puts a lot of friction on that vertical shaft about which the whole assembly is turning. Now that we have a drawing of your proposal, run some rough calculations on the amount of space you need within your robot for the mechanism and I think you will see why crab systems become more a vertical assy. If you can commit to the real estate, this might prove an interesting design. |
Re: Linkage Design Problem
You're completely right about the space requirements Al, and they'll run easily a square foot a module. However, we've used a six wheel drive platform for quite a while now, and that takes up even more space! I'll have to definently design something first, and see what type of resources and space that'll burn up, but I think it's a feasible spin on swerve drive, under the correct circumstances.
|
Re: Linkage Design Problem
Quote:
|
Re: Linkage Design Problem
Are you planning on four of these units per robot? If so, are the pivots all moving in the same direction or is their a mirror layout with two pivoting one way and two the other?
It looks like you will have to drive the wheel at the same time as you pivot in order to avoid the turning friction of the vertical crab design. There will most likely be some frame motion during the pivot due to differences in the speeds and programming. The wheels may be scrubbing as they move out of sync with each other. This is an interesting design. Take a moment to evaluate the interaction between all wheels with the robot frame and the floor. Also do an evaluation on pro/con of effectiveness if you plan on using on your FIRST robot next year. |
Re: Linkage Design Problem
Quote:
Also, the piston now needs to hold its position. When the wheel is exherting full force (pushing another robot...) the wheel will want to pivot to the other position. The only thing stopping it would be the piston force. But...this could be a good thing? Maybe you dont need the pistons at all. Maybe all you need is a latch in both positions. To turn the wheels you release the latches, and back up sharply (or move forward sharply) - the traction of the wheels will twist them around to the other position, where they lock in place. Maybe? |
Re: Linkage Design Problem
![]() Heres another terrible Paint drawing that may or may not explain things better. There are four independent modules, with pivots in the center. All modules must move generally together, although it should be so fast that it won't make a difference. Turning the wheels, or making sure that they're recieving no power during a shift will allow it to move smoothly. Pnuematics should more or less be fast enough and forceful enough that syncronization won't be a problem. M. Krass, that area figure was just a guess, taking into account the framing around the module, a beefy support frame, and the area required to arc a 6" wheel. Ken, you are completely right about piston force needing to keep the wheel in position. I really haven't put too much thought into this, and the original idea was that a complex linkage would be used, and it's structure and friction would more or less soak up some of this force. Not so anymore, so perhaps I'll need to think up a locking mechanism that engages when the piston fully moves the module. |
Re: Linkage Design Problem
I'm liking your general idea, very innovative. However, 6" wheel seems quite large for this application. You may want to consider making your wheel smaller (3"?), that would decrease your module size. If you bring down the wheel size, you can also run your pivot point right on top of the wheel, which throws out the whole frame swinging issue, or wheel under power while shifting. This idea has really made me think. From this idea, you could make quite an interesting bot. Good work, and I look forward to seeing your progress on this idea!
|
Re: Linkage Design Problem
This brings into play an interesting problem in forces. As the wheels attempt to change orientation their rotation is counter to the robot. So do the wheels move and the robot stays in the same position, do the wheels stay and the robot moves? Could have some interesting action in competition but will it give you an advantage? Don't forget you have to include the arc of the wheel diamter in your calculations. In your drawing, an assembly rotating to a new position, inscribes and arc with both the leading and trailing edge of each wheel. The clearance on a 6" wheel, off the top of my head, will be about 1.5-2 inches greater than the length of the assy. from pivot point to outside structural member. With that kind of clearance, you might be able to gain an a little in the outside dimension of the outer axle support.
|
Re: Linkage Design Problem
Quote:
|
Re: Linkage Design Problem
1 Attachment(s)
This design of yours keeps perculating in the back of my head, and I keep thinking there has to be a way to do this
if you put the pivot point behind the wheel, instead of next to it, then the pushing and pulling force of the drive-action of the wheel will not have any tendancy to turn the wheel to the side. like this (top view of wheel and pivot point) You might also design this so that one position pivots the wheels outside the normal frame of the robot, giving you a much longer wheel base (more stablility) - the other postion pulls them into the starting-outline of the frame, pointing at a right angle. |
Re: Linkage Design Problem
Right, and this is what I had originally. However, this would mean that you have to drag a highly tractive wheel sideways, instead of rolling it. But I'm glad it's got you thinking! I'm thinking about a vise grip type locker at the ends of the arc. But the problem is disengaging them when you want to move.
|
Re: Linkage Design Problem
Why is it that you don't want to pivot the wheel about its center?
|
Re: Linkage Design Problem
Quote:
On our robot we see this issue when we need to move cylinders multiple times and need air faster than the pump can resupply. Add in the restrictions on storage tanks and extraneous tubing and you can see why I would be concerned. I suggest that you build a quick prototype to test your hypothesis. The data you collect will provide direction on your decisions for wheel diameter, linkage length and force requirements. Don't underestimate the interaction of the floor or the movement of the frame in this mechanism. Good luck! |
Re: Linkage Design Problem
Quote:
This would be a good thing to mock up with a VEX or Edu kit to get a feel for the action. The lock on Vise Grips is called an over-center latch. You can design them to work with very little release pressure. This is what they use on some ambulance gerneys - when they pull it out of the ambulance the legs drop down and latch. When they push the gerney against the rear bumper of the ambulance the over-center latch is released and the legs fold back up. |
Re: Linkage Design Problem
Quote:
|
Re: Linkage Design Problem
Here's a simpler solution to the problem that a friend of mine came up with.
![]() In this design the force is constant and tangential. Here's the formula and derivations you'll need to determine the stroke length, sprocket diameter and angle of rotation. Let the angle of rotation be theta Let the sprocket diameter be d Let the stroke length be L Arc Length = (theta)x(d/2)*(pi/180) - from the diagram we know that Arc Length = L Therefore: L = (pi)(theta)(d)/360 OR d = 360L/(pi)(theta) OR theta = 360L/(pi)(d) This solution is simple, elegant and definitely doable within the constraints we see in the FRC. |
Re: Linkage Design Problem
I was toying around with ideas very similar to these earlier in the season, before deciding that they would not be strategically worth the added weight, complexity, real estate, cost, and complexity in a typical FRC game.
A standard scrub steering system can escape most situations that a system like this would be useful for (and many of the situations it could not, this wouldn't be able to either, such as the areas immediately in front of the corner goals this year). A system like this grants a limited amount of increased ability, for a cost almost equivalent to that of a "normal" sweve system. The one area it saves a great amount of complexity would be in the programming (but the load may be passed along to the drive crew, depending on how you decide to control the system). Also, to get greater usage from the system would demand an on-board compressor, especially if you use pnuematics elsewhere on your robot. And that compressor also drains the battery, which was one of the reasons you decided to use pistons over motors (lesser battery drain). |
Re: Linkage Design Problem
When I began considering this design, the idea was not to gain full swerve capability, but to offer some swerve mobility to a defensive base. The problem is that holonomics have little pushing ability, and Crab/swerve drives have inherent mechanical weakness that do not lend them to really, really aggressive driving. But that's not what they're designed to do in the first place. This more or less bridges the gap, and creates a more agile base with fully defensive capabilities. The costs are high- not in complexity, but in space and weight. The trade off is some mobility for robustness.
|
Re: Linkage Design Problem
While obviously being more agile than a standard scrub steering system, I fail to see how it is more robust or better defensively than a more traditional crab or swerve system.
Drive system styles are no more or less powerful than eachother, just more or less efficient. That is, you can create a holonomic system that has more speed and/or pushing power than any other drive system. But it recquires more motors and/or current than it would with a different system. A 4-wheeled holonomic system get's 50% of the efficiency of a scrub steering system when driving in a straight line (but has the equal efficiency when spinning in place, as all 4 motors can be fully powered and applying the same % of their power to the final vector of movement as a scrub system would). A swerve system applies the force of it's drive motors identically to how a scrub system would, but it losses 100% of the power of its steering motor(s) (or pistons in this case). Assuming a "traditional" crab system has 5 identical motors, it would have a theoretical 80% efficiency. In short, your system is less efficient in terms of driving power than a scrub system, but posseses added agility. Depending on the game, I do not beleive that the added agility is worth the price of weight and space (and complexity) for the limited increase in agility it gives. But that cannot really be decided until the new game is revealed. |
Re: Linkage Design Problem
Quote:
but with a swerve drive (steering) you only need a little bit of power to point the wheels in the direction you want to go, the drive motors to the wheels dont need that full-power-scotty to turn and depending on whether your wheels are driven independantly, you could angle them 45º to each other, and have a sit-and-spin mode for quick turning, that would take very little power on the wheel drive motors. The effeciency of the drive/steering system isnt a function of the number of motors driving or steering, its how much power they take to drive and to turn that counts. |
Re: Linkage Design Problem
Sean,
I am going to throw in with Ken here. We use two globe motors for steering control when we use crab. Each with a stall current of what, 23 amps. (don't quote me, I'm on vacation and too lazy to go look it up.) However, a four motor drive with no steering provision will run each motor to stall in a turn on carpet. Use Chalupas and that will be 129 amps per motor or on a fully charged battery 500 amps. I have discussed this phenomena on many occasions, even the most efficient transmission design will still stall during turns. The effect, and this is critical, is a 500 amp induced voltage drop across the internal resistance of the battery. At 11 milliohms 500 amps will produce a 5.5v drop if you neglect all other system losses. 12-5.5=6.5 volts available for the RC which is 2.5 volts below the point that the RC goes into protection and all drive to PWM outputs stop. At that point efficiency is zero, no power out. That is not to say you are seeing in your estimate the mechanical losses of four transmission for crab where you might have two in a traditional tank drive. Many crab systems, do not efficiently (de)couple the structure from the robot so that movement causes the drive to move, which changes friction with the floor, adds friction in the bearings, etc. |
Re: Linkage Design Problem
Quote:
You are correct that if you are comparing every system with identical transmission losses, motors, etc., that you output the same amount of power from each equally. Each system has losses in transmission to the floor, holonomics especially, and you can possible correct for holonomic losses by increasing motor power in the system. But this inefficiency at providing physical translation makes them somewhat resigned to extreme mobility applications, where there inefficiencies can be tolerated for the advantages they have. But to try and make up for the inefficiencies to compete defensively eats up power resources, something that could be avoided by not making a holonomic defensive base. Swerve drives are a whole different animal. They *can* use high traction wheels, translating to high power to floor transmission, but this results in slower or less efficient module turning. Many crab/swerve drives choose to simply trade off traction for better mobility. Power to floor is directly related to gearbox efficiencies and coefficient of friction. Where crabs fall behind in the defensive game is not pushing force as much, but strength of the module. You can build a module to stand up to a completely destructive defense, but generally speaking, you still put a lot of load onto the pivot of a crab module because it's so long. The pivot is up top, and the only thing keeping the bottom's of crab modules in place to reduce loads up top is a teflon ring. Tolerance and use wears the ability of this to reduce the loads incurred on the top pivot. It's not a huge deal, but still a weakness, especially with very violent defense. In terms of driving efficiency, the design is no less efficient than skid steer (unless you consider the power required to charge the cylinders before driving). In fact, even with the power required to move the modules, it's probably more efficient than a long-ways skid steer, because you can switch to wide-ways and avoid high turning current. Ultimately, it all depends on the game. And it helps if you already intend to, or could use pneumatics. But it's kind of like shifting gear boxes- you get speed, mobility, and power, but is it worth the weight, the worry, and the pnuematics? |
Re: Linkage Design Problem
Quote:
i'm also confident that you can achive what you want by motors. we (312) used 2" wide roughtop covered wheels, and initially turned the modules at ~60 RPM. we had to tone it down a bit because we had issues with stability when our high CG robot changed directions suddenly. |
| All times are GMT -5. The time now is 04:25. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi