Xevelabs

To content | To menu | To search

Tag - Xachikoma

Entries feed - Comments feed

Tuesday, April 5 2011

Nearly final sillouette

A lot happened since last post, and things are getting very close to their final shape.

Xachikoma_20110404_1.jpg

Xachikoma_20110404_2.jpg

The robot got some brand new 3D printed motor mount (thanks i.materialise!), all the required electronics in the legs, a second camera and a rotating laser distance sensor (the Neato LDS, from the XV-11 vacuum cleaner robot)!

New 3D printed parts

From front to back row: a part used to lock the ball bearing in place, the lower bearing mount and the motor mount, motor_mounts.jpg

That's what the motor + motor mount + pulley looks like when everything is assembled. This goes inside the aluminum tube. The motor is taken between two layers of 0.25mm aluminum sheet. With this, there is no risk of deformation of the polyamide part, plus it allows for two M2 grub screws (both in the bottom of the part, one close to the front, one close to the back) to secure the motor and reductor in place without blocking the gears. motor_mounted.jpg

The motor mount and the part with the ball bearing are now two distinct elements. With the new motor mount design, it was necessary to split the two, as one is fixed and the other has to be adjusted to have the right belt tension. support_bearing.jpg

My first thoughts when I designed the mechanism was that little to no effort would apply to move the bearing out of its hole, but torsion in the tibia support part quickly showed that it was not the case. This little part keeps the bearing where it is. Here it's demonstrated with an old motor mount. bearing_lock.jpg

Leg Control Board

Each leg is fitted with a Baby Orangutan B-328 that controls the motor, the magnetic encoder, the wheel orientation servo, and talks on the Dynamixel Bus as a real Dynamixel device. Right now, it masquerades as an AX-12+ and can communicate with Roboplus :)

finished_lower_tibias.jpg

In order to have it talking on the Dynamixel bus, I had to apply two important modifications on the B-328 board: change the oscillator to a 16MHz one, and remove the user LED (the red one).

Having a 16MHz oscillator instead of a 20MHz one is needed to join the bus at 1Mbaud. I found the perfect replacement here (Murata CSTCE16M0V53-R0) .

The LED had to go because it's tied to the ATMega328p's UART TX, and caused the idle tension on the line to be as low as 1.8v (using only the inbuilt PD1 pull-up resitor) when it should have been 5v. This does not play nice with the original usb2dynamixel, which often saw 0x00 bytes that were not there. Unsoldering (or... destroying -_-") the led solved the problem.

CMUcam3

Having a second camera might seem overkill, yet it addresses one of the most important sensory question for this year's competition: "what color is the square In front of me?". It also be used for line-following, and identification of the team's color at startup (one less switch to flip myself... yeah I'm lazy like that ;) ).

I will write a simple custom firmware for it, that will probably do segmentation (it's quite easy in HSV with the colors used on the playing field and playing elements), basic line following, and maybe some rough position tracking based on the grid. The observable area varies with body height and rotations, and the lens distortion is quite important in the corners. Fun times ahead to extract meaningful information ^^.

Owing to last year's disappointment with the light conditions during the approval phases (very different light conditions in different parts of the playing field, hard shadows, yellow lights...), I decided to add some powerful white LEDs on the camera to try to have at least a spot of well-lighted ground... cmucam_lights.jpg

Neato LDS

The lidar is mounted upside down, below the body. During normal operation, the sensing plane of the LDS will be around 8 or 9cm above the ground, and it's aim will be to detect obstacles I can't go over (like the opponent :p ). I'm still working on a protective cage around the sensor to avoid any damage to it. I don't want to know if it can support the full robot weight ;). Lidar_mounted.jpg

As always, a lot more pictures are available in the gallery!

Saturday, February 26 2011

Shinny!

Behold Xachikoma's new aluminum body!

mP1000772_1365x1024.jpg

Also to try and improve the quality of the pictures, thanks to my friend Landry I have a new big lightbox (still a WIP though)!

A lot more photos - and a more convenient viewer - in the gallery!

Friday, February 11 2011

Some leg movements

These legs have some real potential for doing fun stuff :)

Go watch on Youtube, 1080p!

Some (unpowered) leg movements

Tuesday, February 8 2011

Xachikoma body prototype

At some point last month, before I received any of the manufactured parts, I became tired of building the robot only as a CAD model, and wanted to make some physically tangible progress.

So I disassembled completely the Bioloid humanoid, and started assembling the Dynamixel part of the legs. The two plastic plates in the middle of the leg proved to be too flexible, so I replaced them with a 3mm aluminum part. I also took this opportunity to correct the alignment of the third servo axis, so that it intersects with the axes of the first two servo in a single point.

But that was not enough for my thirst of physical manifestation, so I built a prototype of the body, using black and white 2mm styrene sheets. It works as a prototype, but I would not even try to have it walk with such a flexible body.

I later replaced the bottom plate by a more rigid 3mm medium one.

mP1000574_1365x1024.jpg

Wiring still needs a little work, but I like where it's going :)

Having the things in my hands made me see how big it will be, and how I could improve a few things. For example, I adjusted the distance between the front legs so that the Beagleboard fits snugly with my shortened RS-232 connector plugged in.

I also added the CMUcam3 as a giant color detector, watching the ground. It will be in charge of looking at the grid to provide absolute positioning information every time the robot crosses a line, and also will be used to dock nicely on the playing element the robot wants to move. The idea is to have an easy alternative if I can't get a reliable positioning system using only the Neato LDS lidar, as it won't be parallel to the ground most of the time! Communication between this camera and the Beagleboard will use the shortened RS-232 showed above.

mP1000584_1365x1024.jpg

Tadaaa!

Cut Belts and 3D printed pulleys

Driving the wheel without ruining the general shape of the Xachikoma leg has proved to be an interesting problem.

Also, remember that I'm not a mechanical engineer, so I may miss some well-known techniques and solutions here and there.

TachiLegs

<otaku>

Tachikoma leg shapes are a little different from a source to another, even when you consider sources related to the first season only. Each action figure has its own, and even in the anime it's not extremely consistent between the opening credits, the cell-shaded ones you see during the episodes and the hand-drawn ones in the art-books.

</otaku>

Now back to the robot. The main concerns when designing the tibia were:

  • keeping down the leg width around the wheel (for aesthetics and to avoid blowing the max perimeter too quickly)
  • closed-loop control of the wheel.
  • control precision: little or no backlash, no slipping.
  • having a way to tell if the wheel is touching the floor or not
  • decent driving speed (30cm/s at least)
  • being able to switch from fixed to powered to free wheel.

The last one has been abandoned, due to the complexity it would add. Too bad, the Xachikoma will not be able to actually skate like last year's robot (but it still can fake it ;) ).

First designs had either the wheel directly on the motor or a gear-based transmission, both of which had advantages but were at the time way too large since I wanted to use an optical encoder for control. This led me to consider using another synchronous transmission that allowed more freedom for relative placement of the driving and driven axes: a timing belt. I also came across an off-axis magnetic encoder, that allowed me to reduce width even more.

The size of the magnetic ring for the encoder (32mm diameter) determined the minimum size of the wheel, and from there I chose the Banebot 41mm, 30A shore, as it has very good grip and the tire is fused with the wheel core, so no risk of slipping. Only problems would be the color, and the non-metric grub screw I had to buy an hex key specifically for... why on earth put a non-metric screw on a hub with a metric, 4mm axis?

Now with the size of the wheel determined, I had to start looking for pulleys that could make this mechanism a reality.

Pulley design

First thing I learned when looking at the pulley offer is that I would not find easily what I wanted. Whatever the type and size of timing belt (and there are a lot), impossible to find a pulley that is either less than 20mm wide or reasonably priced (often neither on nor the other). So I chose to make my own, 3D printed.

Choosing the type of belt got down to the question "what kind of pulley teeth are big enough to be accurately 3D printed, and small enough so the ~25mm of diameter pulley would have at least two engaged at any time". My choice went to the HTD 5M specification, since its size is OK (5mm from one tooth to the next), it's availability at various short length is very good and it's a metric belt, not an imperial-unit-based one. The smallest standard width however is 9mm, way too much for me, all the more considering the extremely low torque it would have to transmit. After cutting a few belts to see the smallest width I could reach, I settled for 3mm, to be perfectly sure I keep at least one inextensible thread intact in each belt.

Then I had to design the pulleys themselves. It's surprising to see how little information is available online on timing belt teeth. I had to cross reference various slightly different designs from different manufacturer to get something susceptible of functioning.

Pulley Design

The one mounted on the motor is made so it covers partially the motor, and has a central hub with perpendicular holes for two grub screws. The other does not have a hub, but instead has a hole large enough to let the Banebot wheel hub through, and 6 threaded holes for screwing it to the wheel (only 3 would have been enough but the other are there for backup, if one thread is damaged). This allows for easier assembly and disassembly.

Cutting the belts

To reduce cost, I bought two 15mm wide HTD 5M belt with the idea of using one for tests and cutting the other in 5 pieces, so as to have one spare belt.

My first try was to put a cutter blade on a 3mm spacer, and turn the belt against it... took me some time but the result was nice. Problems: it took half an hour, I nearly cut my finger twice, and blunted the cutter blade completely. The teeth are very hard and trying to cut them like you cut your steak, going back and forth with the blade, tends to take a long time and kill the blade in the process.

Second try, with scissors, was a big failure, with uneven width.

So I made this little one-time-use tool from stuff lying around.

On a base plate, there is a 3mm spacer, on which is bolted a cutter blade. A pole is mounted for the belt to press against. You maintain the belt firmly against the base plate and the pole with the thumb while pulling it with the other hand, and in 30 seconds you have a shiny new 3mm wide belt (actually, the width is more around 3.2mm since the blade has its own thickness... Should have accounted for it when choosing the spacer). Also, no need to change the whole blade each time, just break the tip after two cuts and start again.

Current state

As seen in the previous post, I received the parts not so long ago, including the 3D printed pulleys from i.materialise.

Here is what the whole tibia looks like, still without electronics.

Tibia partially assembled

Tests with the belts showed a little too much friction here and there, mainly due to the fact that my cutting technique is not very accurate (width precision is around +/- 0.2mm I would say) and the printing material is a little rough. A solution I'm looking into is to add a little bevel to the side of the belt teeth, and so far it looks promising.

Most of the requirements should be met, at the exception of the powered/free/fixed wheel modes and maybe ground detection. After seeing the amount of tension needed for the belt, I think my initial plan to sense when the wheel touches the ground with a FSR will not work. The sensor seems to be already under too hight pressure compared to what will be added by supporting the weight of the body. Testing will tell, but considering that on these sensors resolution decreases when pressure increases, I'm not very confident :/

P.S : I'm all for open source, but cleaning things up to make them presentable takes time, time that I don't have much of, and time which is lost if nobody cares. If anybody is interested in further details, 3D models, etc, don't hesitate to say it and I'll try to release stuff.

page 2 of 2 -