Showing posts with label Rapman. Show all posts
Showing posts with label Rapman. Show all posts

Sunday, September 26, 2010

Dem Bones



In which your narrator creates a way to separate parts from an undifferentiated OBJ file scan of the bones in a human hand.

Recently, I came to the conclusion that it was going to be very difficult to achieve anything like the degrees of movement with a human hand in anything like the same size as a natural hand. The Shadow Robot Company gets about as close as you can get by achieving 20 of the 27 degrees of freedom possible with the human hand.


If you look at the kinematics of the hand, which are the best in the industry, you'll notice what amount to pin joints.  While I have no trouble with them, they're extremely hard to do with printed ABS.  As a result, I've begun to look at a more biomimetic approach which has had me looking much more closely at how a hand is put together.



When you look closely at how the joins and joints in the hand are put together you see a series of strip ligaments applied like bandages to the joints to restrict and control movement.  Oddly, the colouring of the Gray's Anatomy drawing twigged my thinking.  The bones are pretty much the same yellowish tint that the ABS I print turns to several weeks after being printed.  The grey-white of the ligaments looks just like the polypropylene that I did a bit of work with a while back.

I found polypropyene a bit too rubbery for my purposes back then but then I realised that polypropylene is famous for being useful as a plastic that can stand flexing, a perfect match for ligaments.  As well, there was the small matter that I'd acquired some 80 lbs of 3 mm polypropylene filament over a year ago at a clearance sale for about $1/lb.

What if I made bones out of ABS and ligaments out of polypropylene?  With the powerful Rapman extruder there was no systems limits on that approach.

First, I had the problem of finding a proper depiction of the bony structure of the human hand.  Several hours with Google led me to this offering from Turbosquid.


Search as I might I was not able to find an open source scan of the human skeleton or parts thereof.  The Turbosquid depiction was inexpensive {please don't write me about better deals, I suspect I've already found them} which suited my tightfisted Scots-Irish nature, but the product was presented as one OBJ file, which made separating out the individual bones a rather daunting task.  Most firms like Turbosquid provide their scans in a variety of formats, most of which work with expensive 3D CAD systems leaving only the OBJ file, which doesn't have intrinsic parts separation, available for use in my preferred 3D CAD system, Art of Illusion (AoI).



I continued my Google search and discovered that if you wanted the bones disarticulated you wound up paying several thousand dollars for a whole skeleton scan.  That was a non-starter.  Thus, I was left with trying to figure out how to separate the parts.  My first notion was to use cutting blocks in AoI.  A few goes at that showed that it was entirely possible but extremely fiddly work.

I then began to wonder how big a task it would be to go in and separate the individual bones in the OBJ file?

The OBJ file format is a rather primitive one that simply includes a list of the 3D points in the point cloud describing the surface of the object(s) followed by a list of triangles containing all the points which make a surface mesh over the object(s) described in the file.  The OBJ format specification is a rather mutable thing and the Turbosquid specification included a lot of textural data and a peculiar triangle specification affectation that I'd never seen before.  Fortunately, when I imported the hand bones OBJ into AoI and then exported it again, it came out in the simple, elegant AoI format.

I wrote a small Visual Basic .NET app to separate out the bones in VB.NET 2008 Express, a powerful development environment which is distributed free by Microsoft.

How it works

The process I followed can be described...

Initially:  break the OBJ file into two lists, the point cloud {List 1} and the triangles descriptions {List 2}.

  1. take the first triangle in the triangle list and put it into a fourth list (List 4) and delete it from List 2.
  2. get the three pointers from the triangle and put them into a third list (List 3) that is sorted from smallest to largest.
  3. Collapse List 3 to include only unique pointers
  4. Take the first pointer out of List 3, delete it from the list and then find all triangle descriptions in List 2 that contain the pointer and add those to List 4 and delete them from List 2.  Add the pointers in each of those triangle descriptions to List 3 and collapse the list again.
  5. Repeat 4 until List 3 is empty.  You've now got the list of triangles describing one of the pieces in List 3.
  6. When List 3 is empty, create a separate OBJ file for the individual piece by copying List 1 followed by List 4 into an individual file.
  7. When this is done Repeat the process starting at 1 until there are no triangles left in List 2.
You will then have an OBJ files for each unique, separate piece in the combined OBJ file that you started with.  AoI doesn't care if there are unused points described in the point cloud.  If you want to get rid of superfluous points you have merely to import the individual OBJ files into AoI and export them again.  This does not happen, apparently, if you import the OBJ file and then try to immediately export it as an STL file.

I've zipped up the code for this little app and put it on my website.  You can access it here.

The hand bone assembly from Turbosquid is not included in that as I read the license I can't redistribute it in its original form.  I'm not sure about that, but I'm not into having that kind of drama with them.

Walking through the app

I'm assuming that you have some familiarity with VB.NET and want to run it from the development environment.  Understand that I'm not happy acting as a help desk for my code.  If you want to use it you're largely on your own.  That said, I'll give you a little walk-through.

Here is what you see when you activate the app.



When you punch the open object file button you're taken to the Object Data folder within the app. 




You can navigate to other folders but this is the default folder that is opened.  You select and open the OBJ file you want to break up.  That leaves you with something that looks like this...





...with the point cloud descriptor in List 1 and the triangle descriptors in List 2.  When you've done that you then punch the Separate Parts button and wait for it to finish.  It's pretty fast on my machine, but it can take a while depending on the complexity of what you are trying to separate.

Once it's done you can go find the Output folder which you can see here...
.



You can also see the Object Data folder in this pic.

Looking inside the Output folder, you will see that your original OBJ file has been broken into as many numbered files as there parts in your original OBJ file.




You can then take those into AoI and convert them to STL files for use with either my own Slice and Dice app, Skeinforge, Netfabb or any of the other apps that prepare print files from STL files.

You can see how this separation process works by looking at the #12 file of the hand assembly.




Like most of my work, I'm more interested in demonstrating methods and approaches than in creating out-of-the-box apps.  I know most of you are much more interested in Java, the good Lord save you, and Python than the Wintel-only Visual Studio and Visual Basic development environment.

Have fun!  :-D

Monday, August 30, 2010

Rethinking the hand



I'm very slow at times. I became enamored of the Meka robotics hand a few months ago and tended to make my own hand project very like it in many ways. As I was completing my first finger/hand segment design, however, the way that both Andreas Maryanto's hand project and Meka's began to trouble me. I had indentified the situation I was calling the "stiff hand" without being able to work out the implications.

This morning, I waked up at about 0300 knowing full well what a stiff hand implied. If you will look at the Meka hand clip you can see what I am talking about.


Notice how the thumb can only engage the forefinger.

Here is a nice photo of the effect as well.




Looking at the the Meka hand design one could extend the range of the thumb and touch all of the fingers.  Even so, and this is the part that I kept missing, you couldn't wrap either Andreas' hand or the Meka hand around a ball and throw it.  You can grip things with a handle, like a hammer, but not a ball.

People interested in prosthetics kept telling me to locate the servos driving the fingers in the forearm like happens in a human hand.  I wanted the hand to be autonomous because of the complexity of routing the tendons contracting the fingers through the wrist joint.

I've now spent several hours trying to evolve my existing design into something that could curl the palm around a ball.  I've concluded that routing tendons through a wrist joint is perhaps not as complicated as making the palm of an autonomous hand curl around a ball ...  or a doorknob.

For inspiration, I began looking at the anatomy of the human hand.  It appears that the ability to curl the palm around an object is controlled by the thenar {attached to the thumb} and the hypothenar {attached to the little finger} muscles.




So it looks like I have at least


  • five servos for finger and thumb contraction
  • one to contract the tendon analog of the thenar and hypothenar muscles
  • one to control the lateral distance between the thumb and the palm
  • one to control the movement of the palm from side to side
  • one to control the side to side movement of the palm.
That makes a minimum of nine servos.  That's definitely going to fill up the forearm.

I wonder how you get the wrist to rotate?

Sunday, August 22, 2010

Getting to grips with the telepresence finger design



Having worked my way through a number of bugs in the Slice and Dice software I managed to get a workable design for the takeup reel of the telepresence hand finger/hand segment assembly. Space constraints reduced the reel diameter to 6 mm.

Last night I did a quick lashup to test the assembly.





I hadn't worked out what effect that small diameter reel would have on the force levels that the gearmotor. When the gearmotor pulled the unglued assembly apart I began to get an inkling of the implications of my design constraints.  Doing after-the-fact calculations I discovered that the gearmotor was applying a maximum of about 4.75 kg to the finger tendons.  That is an almost crushing force.

This feedback had immediate effect on a number of design decisions I had previously taken.  I had been using nylon twine for the tendons.  That was not so much a problem save that I had undertaken to use a simple knot in the twine for securing the tendon to the reel.  It seems fairly clear that that isn't going to work.

I'm currently thinking that lead or steel crimp beads of the sort used in sash cords for venetian blinds may be more appropriate.

Friday, August 20, 2010

Counting on your fingers in binary



I printed up a second finger/hand segment assembly so that I can see how things ought to fit together to make a hand.



I've also bought some of these narrow profile gearmotors from Solarbotics.




If they work out I should be able to create a much more compact telepresence hand.  The dimensions on this puppy are 13x19x53 mm.

Wednesday, August 11, 2010

Servos and firmware



I had a while last evening to work on a bit of driver firmware for the servo for my the telepresence finger.





I had just got it working properly when what appears to be a on-chip fault developed in my 18F4550 MCU that disabled USB comms with the controller board.  I was, however, able to work with the RC Servo long enough to grow not all that impressed with it.

Basically, a RC servo consists of a small gearmotor which is coupled to a potentiometer which acts as a feedback mechanism on position.  A small bit of electronics controls the feedback dynamic and converts repeating incoming analog signal into positioning instructions.  These things were made to be controlled by radio control sets for model airplanes and boats.

In my application, I use a MCU to create the analog signal.  While I was debugging the firmware the little epiphany came to me that there were far too many unnecessary parts in the overall system.  As well, the range of motion of the servo is kind of limited and they are a bit expensive.  I have gearmotors which are smaller and far more powerful than the servo and my MCU can control them.  For feedback for my telepresence finger, a flex sensor...




...makes far better sense than a potentiometer and why have extra electronics when you can dedicate an MCU that controls a gearmotor according to feedback from the flex sensor for about $1?

My friend, Josh Hall, is building a robot starting from the shoulder and working down while I am going in the other direction.  The high torque gearmotors that he is using cost about $500 each.  You can buy hugely powerful gearmotors mass produced for the automotive industry surplus for about $10 and out of the catalog for $30-50.



I think I am going to buy some flex sensors and use this small and very efficient gearmotor directly with my MCU...


...and see where I can go.

Monday, August 9, 2010

Servo reel done



I finished designing and printing the reel for the servo that drives the finger.




Next steps are to design a mounting harness for the finger and servo and program a boilerplate firmware app to run the servo.