Sorry I haven’t gotten back with you yet. It looks really good, Mike. A lot of the things you implemented here are the same as what I’ve been working on…
One central consideration I’ve had that I’m not sure you worried much about was the need to keep the fingers from swinging backward in general and especially when there is a load on the fingers. That is, when the hand is grasping something the finger joints need to move forward but otherwise you want them to be plumb with the palm surface rather than moving backward. One way to deal with that would be to use the springs creatively (having the “free” position on the springs be in the flat position) but that solution doesn’t work if you are trying to support a weight on the hand with fingers extended…
In order to address that:
(1) My finger joint designs look very similar to the rendered one you showed earlier with a couple of differences. On the single peg part I have it rounded on the top but flat (i.e. 90 degree angle) on the bottom. This flat portion keeps the joint from rotating backward because it presses up against the flat surface of the two prong side (or of the connection with the palm if it is flat). I also made the wall on the single peg side vertical all the way up and left about a 1.5 mm space between this wall and the fully rotated joint that would be attached to it. This allows the holes to line up so that a 1.5mm solid height compression spring can be placed between each of these joint segments.
(2) I’m not sure why you have those circular indents at every joint. Those would interfere with the mechanisms I mentioned in (1).
(3) The thumb doesn’t seem like it grips in opposition to the fingers. There should be a way to have the thumb swing to the sides but also grip in the opposite direction to the fingers. One way would be to have a separate piece that attaches to the rod that swings the thumb to the side, I’ll work on it. Hopefully I can figure out a way for it not to cost much extra…
(4) I’m not a big fan of the angled fingers as suggested above because I think it would complicate the gripping control mechanisms. I’m ambivalent about making the thumb location closer to the middle of the hand…
(5) I’m been working on making room in the palm for some micro servos to actually implement the gripping action.
I’m learning the ems software myself so it has taken a bit of time. If you are interested in my designs just let me know and I can mail them to you; my email is in he memberlist.
In one of the other discussion threads for ground contact sensors I have been following I had an idea, what do you guys think of using those in a gripping hand assembly?
My thought was if these could be used on a bots feet, why not its hands? This would give the bot the ability to stop the force of the grip once a certain amount of pressure were applied.I’m not so concerned with the hand crushing the item in its grip, rather providing feedback for the servo to stop rotating and avoiding burning it up.
What do those of you with more experience think? Would this work?
yes, all I was suggesting though is that there will be some lag introduced by the micro detecting the levels it wants and responding, time to get the command from the micro to the servo controller, upwards of 20ms delay to get the signal from the servo controller to the servo, and some overshoot caused by the servos PID. All these things working against actually grasping an egg without crushing it, but the FSRs are sensitive enough
I Agree, and you can’t stop the servos before the point of crushing, because the sensor have to first detect something (contact) all the while the sequence of stopping the servo would have to finish but it may be to late for that cats tail in it’s grips.
The only thing I can think of is using FSM (Finite State Machine) where the code is running in a multi-task state. Without FSM, the code executes in a linear fashion where event #1 must wait to finish before event #2. FSM will do #1, #2, #3, etc. all at seemingly the same time, and if a new condition occurs, it will exit that current event.
I have read about some of this FSM concept along with Subsumption architecture, but I have yet to really study and try to understand it.
Don’t get me wrong guys, all the above is very interesting… However,
It was brought to my attention a while back that there were some drawbacks to using gripping hands like the ones Jim sells for the bipeds. One of the basic problems is when the servo needs to stop turning to avoid burning it up.
I think there must be a reasonably simple solution to this problem.
The robosapien v2 utilizes a feedback method to know when it is grasping an object. But how do you make the hand maniopulate objects of varying size without stressing the servo? I.E. grip a single sheet of paper or an object like a ball? Robosapien2 is not able to do this, it senses either the object is grasped or not. I have experimented trying different ojects. The hand either opens 100% and closes 100%, no ability to grasp different sized objects.
The Lnyx hand is fairly small so the solution must use some feedback method which is compact. Since the hand is really a modified pincher the thumb and the “mitten” fingers would be all that is required to have sensor input.
I realize I am very new to this and alot of it I still do not understand, so I apologize up front but I think there must be a reasonably simple solution .
By the way Mike I looked into the Finite State Machine. This is used in alot of PC games, primarily to control ememy AI. Very interesting, but it does not appear to be easily done.
Well, you’re right, there may be a simpler solution.
(Although it would probably not be sensitive enough for an egg.)
What about using the stress feedback like Andy does on his hex?
There’s also microswitches.
You could directly switch off a servo when the microswitch touched the egg, but that would lead to a vibration of on-off servo movements, which would probably not be able to grip the egg.
You could also just have your microcontroller monitor the microswitch, but that leads to the same delays as FSR’s.
Another option is video monitoring, but this would have really complex geometric algorithms, which defeats the purpose.
Besides, it’s probably not enough.
The truest answer that I can think of would be to use both vision and FSR.
The vision would compare the object’s physical attributes to previously memorized attributes of similar objects.
Then, the vision feedback would give the servos the estimated thresholds for new objects, or the known thresholds for memorized objects.
The FSR’s would provide feedback to correct for errors in memorized objects, and to they would function more importantly for error minimization in new objects.
This is pretty much what humans do.
However, that’s pretty complicated too.
Wow! that is a little more ambitious than my skill allows.
I was thinking of something more along the lines of Mike’s sound board. Instead of mics use FSR’s, instead of a parameter based on sound to move a servo, difference in resistance based on the pressure on the FSR’s to move a servo.
Couldn’t that work?
My design doesn’t quite work like that. It compares both mics at the same time and gives the difference.
I think you were on the right track however, using the FSR’s and using code do something when the threshold is reached. Andy is basically doing the same thing with his quad legs. When the leg hits the ground, it stops the servo. The only difference is instead of a leg making contact with the ground, the gripping hand is making contact with an object.
I’m not sure what’s involved with Andy’s FSR sensors to make it work the way it does, but I think using the same type of system, you can get the desired result you are looking for.
I wasn’t trying to say that it couldn’t be done with FSRs or that the lag was a deal killer, only that the lag is one of the challenges. Simply moving the servos commanded positions slowly would decrease the effect of the lag on overshoot.
On the use of the current sense data: This is incredibly hard data to interpret while the servo is in motion. The servos internal controller decides output simply on deviation of actual position from it’s goal. Trying to separate out the external disturbances from reasonable output of the in-servo controller requires both knowledge of the internal algorithm as well as a very good physical model of the servo. Tough stuff.
Mike,
I like your idea, I am a long way from that level of robotics, but I was wondering hole big is the hand and fingers? Looking at the pictures I can tell. Are yours joints 1" long shorter.
I’m not sure what you mean about 1" longer or shorter. The picture posted on page one was a quick rough draft of a possible hand. There is a scale drawing of the hand in the same image.
I have put the idea on the back burners for now. I am focusing on the bot head and sensor board for now.
Mike,
So if I open that picture and print it it would be to scale? The length of one of the knuckles is what I was talking about.
I have been reading thru the post on your robots head. Very cool. I look forward to finish reading the posts and seeing you project progress.
Sure, no problem. I can give you the actual dimensions when I get home if you want. Did you say that you were good with solid works? If so, I can give you an exported DXF file.
