Building humanoid similar to Asimo and Qrio

[siempre.aprendiendo]

Muchas gracias por mostrarnos Choreonoid, Nicolas Gomez! Tiene muy buena pinta!

Thank you very much for showing us Choreonoid, Nicolas Gomez! It looks great!

Even it's open source! I've been playing a bit with it and my impression was very good. Have you been using it to create motions or using it otherwise?

[limor]

The new fishing wires works like a charm. No stretching or dead zones.



We measured the strength of the hanging pegs torsion spring.
A bit over 2kg at 90deg.


3D printing the new knee bracket. (there are some issues with current printing parameters or extruder on one of the 3d printers in the office. the sticker marks the value proportional to the amount of plastic extracted per second)




the rod is a kite fibreglass rod. it has a strange off-center hole and its diameter is about 7.7mm. the hole in the knee bracket was set to 8 but with the plastic deformed it was more like 7 so it needed to be expanded using a hand drill with an 8mm drill bit.

[limor]

and here's the foot. I'd dare say not bad for a first attempt but i should know better. the structure is too fragile and it flexes too. the spring measurement was incorrect. the suspension i have now is longer then the 6cm one that I just ordered from China. etc.

[PaulL]

Hi

Since i have been the one mainly using the cnc i thought i should answer this.

The Kress max rpm is 20k. However it was not run at this speed.

The feed rates i have been using are based on what the cam software recommends for aluminium : 15K RPM and 17mm/sec (40 inches/minute).
However the machine vibrates too much if i use these speeds so i have lowered them to 40/30% of those values. From my understanding you should keep the ratio between feed rate and RPM constant.

I don't have the parameters for the IPM right now, but i think they were ok, because i was getting nicely sized chips. About 2 to 3 mm length and a few tenths of a millimetre thick.

From what you are saying, i interpret that you are worried about too high of an rpm and to low of a feed rate, causing the flutes to rub the aluminium rather that digging into it.

Given the size of the chips, i believe the problem is mainly caused by aluminium building up in the flutes (i had to put one in lye to dissolve the aluminium). I have used WD40 to lubricate the bit and the aluminium, but after just a few seconds of cutting, the aluminium builds up, causing the bit to loose it's cutting ability. It them just rubs against the material, melting it and pushing it out of the way.

I believe the problem is mainly cause by the end mills i am using :

http://www.ebay.com/itm/160828340580?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649

They are probably not sharp enough and the flutes are too shallow. I got a bunch of these cheaper ones, because i was already expecting to break quite a few of them.
We are also planning to add a mist system, since that seems recommended by most CNC user, to blow the chips away to prevent re cutting of chips, and to continuously lubricate the tool.

Have some better end mills on the way.

What would you recommend from this? We have collets for 8,6,4 and 3.175 (1/8inch).

Regards

2 to 3 mm chips - how thick is the material, and how deep is the cut? I think those chips are too much for a 1/8" tool.

Regarding recommended surface feed rate for alu, I'd say take it with a grain of salt. For a heavy, high horsepower industrial machine, sure, but for smaller machines, it's just too much metal to take out that fast. Those machines are massive and often have flood coolant systems to keep the heat down because they're taking out a lot of metal pretty fast (and with larger dia tools). And, they generally don't worry about the cost of tooling - that's factored into the cost of whatever a machine shop charges for work. They can run harder and wear out tools, passing that cost on to the customer, while getting jobs done faster.

For smaller tooling (1/8 inch end mills are pretty small), higher speed setups are typically used, taking fast cuts at high RPM's (50k+) at shallower depths. They call it High Speed Machining, and that is a game (IMO) for people with deep pockets.

On the other end of the spectrum are smaller machines with less physical mass, not designed for industrial use (my mini mill is one of these at 150 pounds of cast iron).

I typically order bits from www.mcmaster.com, like these: http://www.mcmaster.com/#2883A11, cobalt, center-cutting version, 4 flute, 1/8". Their prices are a little steep, but I know what I'm getting. These are VERY sharp - like a razor. You don't want to brush your hand against it once you mount it in the mill! The sharpness doesn't fade as quick as on high speed steel tools.

Also, some grades of alu tend to gum up in a tool pretty badly. 6061-T6 is a staple in machine shops - it is one of the best aluminums for machining. You'd be amazed at how one grade of alu compares to another when you machine it! Results range from clean breaks of chips to just kind of pushing the aluminum around (like gum).

That tool from Ebay looks like a Dremel bit I have - it was horrible to machine with, not at all rigid enough to make decent cuts - it's long in the flute area. The flutes are also steep, which causes problems in clearing metal. You want to mount your tool way up in the collet. The goal is to keep the working part of the tool as close to the axis as possible. This increases rigidity. For drill bits, you'll find that they like to walk - especially smaller ones. For starting small holes, I have a few bits like on the right here http://www.mcmaster.com/#drill-bit-countersinks/=j8u572 - they're blunt, meaning they won't flex like a regular bit. After starting with one of these, a regular bit will stay centered.

I don't use coolant or a mist system - the cobalt end mill doesn't need it - no overheating, no clearing issues. I also have bought HSS tools from McMaster, and they're OK, but the cobalt ones stay sharper longer.

My chips are smaller, and they fly clear off the part - nothing to clog when the chips do that! I can cut at 7 IPM at .020" depth and 4k RPM on those 1/8" bits with no issues. Minimum step resolution on my machine is .001 inch full step, .0001 inch microstep (but microsteps typically aren't accurate). I should also say, I'm more concerned with decent cuts than I am with speed - but I use my mill for prototyping, not production. I don't want to trash a tool or a part because I went too fast.

When you get the new bits, try a much slower IPM (forget what they recommend for alu surface speed!), and a shallow depth of cut. If the heating is being caused by loading up the tool with chips, you'll be fine with a shallower cut and slower feed that won't clog your bits.

IMO, the way to get your speeds and feeds right is to ramp up a machine slowly, starting with what works at slow speeds and very light cuts, and keep pushing to whatever performance level is required or desired. As you bump up the depth and speed, you'll see your problems crop up one by one - machine rigidity, spindle RPM limit, axis speed limit, tool limits, spindle horsepower limits, etc, etc. At some point, you reach "good enough" - no such thing as perfection.

... I was picturing a 20k RPM spindle full speed cutting a 1" deep slot in 5052 plate with a 1/8" bit at a very slow (<1 IPM) feed rate.

My apologies if I'm telling you things you already know, just trying to be thorough.

[limor]

another part designed.
this time the ankle joint pulley had to be modified so that it also serve as structural axis

[tempusmaster]

The new fishing wires works like a charm. No stretching or dead zones.

Glad that's working out well for you.

[limor]

the new inverted servo joint axis proves to be useful for the arm.
The left arm includes twice the new joint axis.

The head with the embedded Xtion (kinect) was designed for another project where the humanoid had an embedded Intel I7 cpu. I'm more inclined to design this robot for a more affordable Rasberry-PI which currently can not process the USB signal from the Xtion. Hence maybe stereo camcorders will be used instead.

[limor]

Finally yesterday I had a few hours to work on the hand.
The robot fingers are ok but the palm is still not there.



This palm is shaped in a way that puts the fingers in some kind of symmetry. This has an advantage of allowing objects to be grasped in different angles. I took some inspiration from the Sandia robotic hand sponsored by DARPA (10k$ per hand)

[limor]

My apologies if I'm telling you things you already know, just trying to be thorough.

Thank you very much for the valued information!

[limor]

todo: palms of hands, head, iron-man shell
todo2: fit somewhere battery, controller, Rasberry-pi

The arms have been fitted with 2 extra servos near the hands. That's to give the hands 2DOF. which can be used to move finger sets independently.
I re-did the chest to give narrower shoulders and to allow the angle of the shoulders to be such that the arms can rest parallel to the body.

there are now 24 servos on the robot.
i'll start looking at weight distribution to see if the AX12s can handle not only the knee but also other parts of the body..

[siempre.aprendiendo]

Wow! It looks great

For controller, do you mean microcontroller?

Have you considered Beaglebone instead of Raspberry? It has ready to use GPIO ports and mechanically is easier to attach (Raspberry has no holes!)

[limor]

I just received 2 rasberry-pi with 2 holes on the PCB

beagle bone is yesterday's star. rasberry-pi is currently the king by popular choice. i'll try to make itso that the actual cpu board can be one of several by using a designated 3d printed intermediate structure to attach the cpu board.

microcontroler board in this case will have to be custom built to better deal with power spikes, sensors, arduino firmware and multi-UART channels to lower latency with so many dynamixels. and possibly allow using standard pwm servo in place of AX12 for some of the DOF for example fingers.

[siempre.aprendiendo]

Good news!, the Raspberry Pi without holes is really annoying. Could you post a photo of the new RPi?

Yes, the "adapter pattern" is useful in software and in hardware. With the hexawheels "ninja prototype" I used an improvised Lego Technics structure as adapter to use Pandaboard or Raspberry.

That microcontroller board sounds very interesting. It would be great if it could run the Robotis firmware!

[PaulL]

microcontroler board in this case will have to be custom built to better deal with power spikes, sensors, arduino firmware and multi-UART channels to lower latency with so many dynamixels. and possibly allow using standard pwm servo in place of AX12 for some of the DOF for example fingers.

This is what I was saying on my "Roboard Experience" thread!

The future in 'bot control is a PC based board with a custom 'bot board as a peripheral.

Next issue with this notion: Standardization. I am not fond of standards unless they make sense - and many don't. BUT! What we're trying to do outside of the PC is pretty basic: move servos, handle gyros, accelerometers, etc, etc. What doesn't exist today is a standard way to approach interfacing these kinds of devices in the hobby realm.

I think it's still too soon to get overly specific, but here are my thoughts thus far:

My current methodology is to send a "Command Host ID" to the device (Arduino / AVR in my case) along with whatever command and parameters, and respond from the device with this ID (and associated data when applicable) when whatever request is complete. This allows the device / controller board to prioritize and handle requests as necessary. For example, the device / controller might have to do some serial work (I2C, serial, whatever) that will cause some asynchronous responses while doing other things. You wouldn't want motion to pause while handling an ADC read, for example.

USB seems to be the most popular peripheral interface to a PC, so I'm going with that. Since I don't want to write low-level drivers and wish to keep coding simple, I'm sticking with emulated serial over USB.

IMO, it doesn't make sense to set speed and motion characteristics in a servo beyond the needs of the servo hardware itself. When multiple servos must move together as part of a singular motion, it should be a higher-level controller that coordinates the motion, and this means controlling speed.

So, from an abstraction perspective, 3 layers: Servo internal controller handles servo aspects, dead zone, aspects relating to moving to a specified position within the physical capabilities of the servo. Motion controller coordinates motion of multiple servos. Host PC moves groups of servos as a function of intent - the desired action to be taken from a supervisory standpoint (figures out how and why to move the servos).

It gets gray at the point of complex motions like "Walk" - does the motion controller handle the sequencing of motions, or does the host PC dictate this? I think this aspect will be debatable for a while yet, and I think that the latency of a serial link and the processing power needed by a host PC puts the coordination of motions comfortably on the PC for now. But, it wouldn't be too hard to set up a stack in the motion controller to chain motions together - but then, you'd be handling the limits of the stack on the PC side. It gets complicated quick when you have to interrupt motions and such, which leads me to my opinion that a motion controller off the PC board would only handle moving a collection of servos at a time (though, multiple collections concurrently with different start / end times, like wave arm while walking).

Just my opinions...

[limor]

I agree that the standard robot these days should incorporate microcontroller and embedded linux (see our Linuxified.net efforts). The feedback loop should be with the linux IMHO. the microcontroller's job is to relay information back and forth at 100 times per second and the servos should do the same at much higher speed.

Anyway, here are the Rasberry-pi's we just received with the mounting holes.