If this is your first visit, be sure to check out the FAQ. You may have to register
before you can post: click the register link above to proceed. Please email info@fightingrobots.co.uk if you have any questions.
lol sorry to go off topic but just looking at a link from that site, I love the fact that typhoon 2 is still ranked number 5 (botrank.com) even though it has been ages since it last faught
Wedgio is a really nicely made bot. To be fair to Storm 2, heavyweight lifters are harder in a sense because the stresses required to overcome gravity at their larger scale is roughly double that in a feather.
Has anyone tried a non-flat 4 bar linkage ? I have a picture of what I mean on my profile, it works great in K*bots, the k*bot on the profile has a 13ft flip record with a robot of iits own weight
Cool, I made it onto the UK forum! :-p Wedgio is now ranked #1 ! ! ! :-) I like the batt 4-bar over the pneu just because of the amount of times that you can use it. Mark only has x amount of pops, I can lift whenever I want + it can also clamp. I still have a few new attachemnts that I have yet to use on Wedgio. Maybe at RoboGames I will have to get some out of the box and take pics for yall.
I made a program that simulates the static conditions of a 4 bar lifter(one powered by the front bar).
I found this thread while I was searching to see if it had already been done, so I thought Id post to let you guys know I finished it.
It plots the start/finish orientations and a torque vs angle plot.
Enjoy!
PS-this only works if you are powering the front bar with a motor... dont try to convert a piston force to a torque, this is a different condition. Im going to be making a new simulator soon for piston powered 4-bars (hopefully itll be a dynamic simulation, so itll tell you how far youll toss the other robot, total time for the lift, etc).
I got an e-mail from John Reid expressing some concern that my calculations were incorrect. He noticed that there are spikes at the end of the torque graph for most 4 bar systems. This is caused because the force applied begins to act perpendicular to the path of motion. Its similar to this situation:
Sorry for the bad mspaint drawing, but Im just trying to get the point
across. Imagine the blue slots are immovable. The purple arrow is some
weight, and the black lines are perfect links. As the green forces are
pulling, once they get to where the black links are almost horizontal, the
green forces will need to be infinity, to hold the purple force steady. The
forces start acting perpendicular to the path of motion they are trying to
create. The same thing starts to happen at the end of some 4 bar motions.
This is why they never reach full extension if they are powered by the front
bar (they might get really close, but they never get all the way out. This
is good, because it keeps the rear link from binding on the retract).
I went back anyway to make sure my calculations were correct. I found a different error in my calculations (a sign error) which throws off the graph a little. I suggest anyone who downloaded the program to re download it, as the previous version is giving out incorrect results.
Ba! I found some other stuff wrong. The programs code matches that of my spreadsheet which I was using to test out the concept, but the results arent matching up. I need to look it over some more. I hate programing...
Sorry again to drag up an old thread, but I updated the program.
First off, I did this a while ago but never posted here. I changed the method by which it calculates the torque. Instead of using a bunch of statics calculations, it just does a work balance. So basically, it uses trig to iterate through the motion of the arm by changing the powered arms angle slightly each iteration. This generates the trajectory of the arm. Over each iteration, it looks at how far the tip of the arm moved vertically, and how far the powered arm moved in radians. It knows the force the tip lifted, so it just does F*D=T*A where A is the angle change in the arm. The iterations are very small, so it generates a smooth graph. The results it gives are the same as the spreadsheet I had made earlier which relied on statics, but this method is much simpler, and less error prone. It also allows me to add in a rear lift without changing much of the programming, see below.
Other than this, I added in a variable for rear lift, so you can raise up the lower pivot point of the rear bar. This is in a lot of designs, so I thought it was an important addition.
Also, I added in support for rear bar powered lifters. Its still at the same url:
The next thing I want to do is make a dynamic calculator for pneumatic powered systems, and a static calculator for systems powered with electric linear actuators. But dont hold your breath...
Comment