Xachikoma, a 4 DOF quad

[Xevel]

Hi everyone,

So here is my first thread around here, and what I will talk about is my current tachikoma-inspired 4DOF quadrapod.

On this project, I work with my photographer/blacksmith/tachikoma-fan friend : http://landrycollet.fr/


Genesis


Since the Ghost in the shell series release (6 years ago here), I have been a huge fan of the tachikoma. When Tomotaka Takahashi built a robot tachikoma for the release of the Ghost in the Shell: S.A.C. Solid State Society film, I was thrilled. But I had unrealistically high expectations, so I felt a little disappointed. Sure it is cute as hell, but the legs are 3DOF only (vertical-horizontal-vertical axes, not the typical vertical-horizontal-horizontal axes) and it did not walk as well as I hoped. Also, it doesn't have functional wheels.

Fast forward two years ago when I came across this robot : http://www-robot.mes.titech.ac.jp/ro...rwalker_e.html
For some reason, it triggered a kind of revelation : "it can be done". I spent the next year working on my own skating robot (maybe I will talk more about it in an other thread) with the pretext of entering it in the French qualifications of Eurobot.
[ame="http://www.youtube.com/watch?v=2Vf6lhof93U"]skating robot[/ame]
In the meantime, I discussed at length with my blacksmith friend what would be needed to start building a tachikoma.

Lately, I came across Zenta's hexapods. Their smooth and lifelike motions stunned me. It was exactly the kind of smooth motion a tachikoma would need! The fact that the code was freely available encouraged me to start the project (thank's Xan, Zenta, Kurte and other contributors!).



We settled on doing this project progressively :
First, a prototype of one leg with small and inexpensive servos, then the first version of the body + 4 legs, but without any load (external power source, external brain ...), and then the "real" version, bigger, with better servos, and everything inside the body. A last step would be to add foot pressure sensors, IMU, camera, you name it... and to add some AI.

We may or may not go all the way with this project, depending on the success of previous milestones, time and available disposable income, but at least it will be fun to go as far as possible.

Leg description

Here is the kinematic model of the leg:

H = hip
K = knee
F = foot
The axes of the first 3 joints (starting from the body) all cross in one point, making the system nearly equivalent to a spherical joint between the body and the femur, and a hinge joint between the femur and tibia.
Alan KM6VV worked on a similar but slightly different design but if you know of some other similar projects, I would be delighted to hear about it.

To build this, one of the cool things is that we can make a module with two servos with orthogonal axes and use two of these modules (+ other brackets) to make a leg. I considered printing some using a 3D printing service, but it ended up being too costly compared to the rest of the prototype, so I built it from 1mm aluminum sheets.

First leg Prototype

Here are some pictures of the very first leg prototype. The servos are the cheapest available, so if I damage some during the software development phase, it's no big deal. The "real" tachikoma will have better servos. The wooden tibia is just for show.














Second Prototype

The second leg prototype has some slight modifications : the 3rd and 4th servo are permuted. This does not change anything in term of kinematics, it just shortens the femur. The second servo has been replaced by a stronger (but equally cheap) one.
The body the leg is mounted on is a tough (and heavy) test body. The wheel is fixed and currently just for style. The sort of decoration on the tibia was just to test the possibility of making a shell around the leg to make it look like the original tachikoma... but this is not going to happen anytime soon :/









I designed a lighter and cuter body to be used when the bulk of the testing is over. It is made of 2mm styrene sheets, with spacers cut from 5mm styrene. In the pictures, all the M2 screws are metal, but I switched most of them to nylon to save weight (went from 36g to 30g). it is not very rigid by itself, but when the legs are in place, it looks sufficient. It it proved to be too flexible, I will rebuild it with aluminum.









Detail of the rotation axis:





That's all for today!
Soon, some info on the (epic) quest to find an IK solution for this beast ^^

[TeamThinkTank]

Very cool! I am not a massive fan of the show, however, I am a fan of these tank units. I wanted to build one as well, but I was going to try to make it very small with powered wheels. Maybe when I have more time in the future I will sit down on this project, but I am sure to reference your build to aid me in mine!
I actually wanted to build it specifically for http://www.mech-warfare.com/ so I would have to attach a real bb gun, hah.
Can't wait to see the rest of the report!
-Bradley Hanstad
Team Think Tank
www.teamthinktank.net
www.twitter.com/teamthinktank
www.fb.me/teamthinktank

[Xevel]

Very cool! I am not a massive fan of the show, however, I am a fan of these tank units. I wanted to build one as well, but I was going to try to make it very small with powered wheels. Maybe when I have more time in the future I will sit down on this project, but I am sure to reference your build to aid me in mine!
I actually wanted to build it specifically for http://www.mech-warfare.com/ so I would have to attach a real bb gun, hah.
Can't wait to see the rest of the report!
-Bradley Hanstad
Team Think Tank
www.teamthinktank.net
www.twitter.com/teamthinktank
www.fb.me/teamthinktank

Great!
We have thought of powered wheels too, they are in the works (waiting for the ordered ultra light servos do arrive). To be exact, we want to try a system that allows for the weels to be either fixed, free or powered... However, this will further destroy the silhouette of the leg on the first proto. On the bigger one, it might be better looking.

[DresnerRobotics]

The new 'Open League' in Mech Warfare allows for wheeled vehicles, btw. =)

[Xevel]

While my friend finishes the set of legs, I worked on a simulator to develop and test the inverse kinematics (IK) algorithms.
The leg IK problem can be treated separately from from the body translation and rotation problem. Also, the future orientable wheel is considered an end-effector and does not change the position where the foot touches the ground, so we can ignore it for now.

The current state of the Simu (full leg IK, 3DOF body translation, 3DOF body rotation):

Code : http://code.google.com/p/xachikoma/s...svn/trunk/simu (not ready at all for prime time but can be interesting just to have a look...)
To use it, you need to install the VPython library (free and portable).



The 4DOF leg IK problem

Solving the IK problem means finding the servo angles we have to feed the system to have the leg extremity (the foot) at the desired position. The input is the foot target position (which is a 3D vector, (x,y,z)) and the outputs are the 4 servo angles. The number of possible solution for a given input is infinite, but this does not mean that we can't solve this problem, just that we will need to add in the mix a constraint to help us narrow it down to one.

The leg IK problem here is a bit more complex than with the usual (Phoenix-like) 3DOF leg, or than the T-Hex 4DOF leg. Contrarily to Zenta's T-Hex legs, we can't split the problem into a 3DOF leg + an end effector, so we have to find an other trick to choose one solution. Since the ultimate goal is to have it run on a microcontroller (atmega 328, 16MHz), a computation-intensive way (like an iterative method) to solve this problem is out of the question.

I chose to try to find a simple heuristic function taking the foot target coordinates as parameters, and returning a value that would be used as a fourth parameter for the IK computations. My intuition was that this fourth parameter could be the rotation angle of the leg around the (virtual) axis hip-foot. It has the advantage of not modifying the hip-knee-foot triangle, just rotating it: it is an extension over the 3DOF problem, allowing for incremental development of the IK code. I named this fourth parameter "Rho", as nearly all the other Greek letter I know were already used by the 3DOF computation ^^

The leg IK computations had to be developed in 4 steps :
- implement 4DOF forward kinematics,
- implement 3DOF IK,
- implement 4DOF IK for a given Rho,
- find a simple heuristic function to compute Rho

4DOF FK

First thing to do was to implement the FK of the 4DOF leg in the simulator, to be able to see if the leg was going where it should. The simplest way to look at it is that it is a 3DOF leg on which the femur can be rotated along its axis, and I used the 3D library VPython to get it done quickly. It just had to represent accurately the movements of the real robot leg, so I did not even bother to make it look good.
I named the 3 rotation angles of the hip "h1" (1st servo - vertical rotation), "h2" (2nd servo - horizontal rotation after h1 has been applied), "h3" (used to be the 3rd servo in the first leg prototype, now it is more likely to be the 4th but this does not affect the movements, and it's convenient to represent it on the model as the 3rd hinge - rotation around the femur axis) and the rotation angle of the knee "k". So setting these 4 angles defines a unique position of the leg, and each of these angles have a linear mapping on the servos of the physical leg.



3DOF IK

The physical configuration of the leg makes it easy to use it as if it was the usual 3DOF leg, I just have to set h3 = 0.
Many are familiar with the resolution of the inverse kinematics problem for the 3DOF leg most hexapods use around here. In my case, the fact that the first 2 servos (usually called coxa and femur servos) have crossing axes simplifies a tiny bit the computation, but the problem is still the same.

For people familiar with Xan's Phoenix code : I do not use the same coordinate system! For me, +z is UP, like in 3DSMAX. Also, I chose +x to be forward.


4DOF IK for a given Rho

Using the previous formulation, let's now consider the triangle HKF in 3D space. When we compute the 3DOF solution, this triangle is contained in a plane that contains the z axis too. Now we are going to change that.
As the hip and the foot position are the ones that are fixed by external factors (the hip position is considered the origin, and the foot position depends on the input target position only), a rotation around the axis hip-foot (HF) would is possible without the need for any input change. In fact, this rotation makes it possible to obtain all of the possible solutions to the 4DOF IK problem.
The good part is that we can reuse the solution we found with the 3DOF IK as a start. The bad part is that rotating around this axis affects the output rotation angles h1,h2,h3,k in non trivial ways.

I won't go into the details of the computations here, but I can try if people are interested.

For this demo, the femur length is 35, the tibia length is 90 and the hip is at 80 above the ground. The target position is given relative to the hip, not the world coordinate system. The axes where different at this time, so the for Target value in the image, y and z are inverted, sorry.
The red ball is the hip, the green ring shows the foot target. The yellow cylinder is the knee, and the yellow ball indicates the position where the knee would be in 3DOF mode (for h3=0, and rho=0).
On the graph are plotted the values of h1, h2, h3 and k as functions of Rho. The blue vertical line indicates the current value of Rho, which is set by the user with a slider. Angles are in degrees.
Here are a few examples of what it looks like when we vary the Rho parameter for a given foot target:

Target = (13.87, -8.85, -80)
rho = 0

rho = 26.3 deg


Target = (40.35, 7.09, -80)
rho = 0

rho = -10.8 deg

rho= -24.8 deg


target = (75.67,47.5,-80):
rho = 0

rho = -58.8 deg



Finding an heuristic to compute Rho

Now that we have a way to use our mysterious fourth parameter, it is time to search the magic function that will compute it for us. The problem with this kind of solution is that there is no given direct way to get to it, and we are not even sure we will find a good enough one... I have to emphasize heavily on the good enough part: what I present below is one way to solve this problem, and I found it to be good enough for a first version. Don't come screaming at me that it's just a dirty hack, I know it, and I just think that as a first approximation it will do the trick.


The first idea was to search a way to minimize the sum of the travel lengths of all the servos from their default position when the robot is walking. This way, moving to a position would be as fast as can be, since the movement would be optimally spread on the servos. A more mathematical way of stating this is that we want to minimize the sum of the squared distance of the servo angles to their default value.

I started by having a look at the graphic representations of h1,h2,h3,k as functions of rho for a given target position, to try to get a feeling of the influence of Rho on the output angles for various target positions.
Here are a few more examples just to scare you: (click to enlarge)


It is interesting to note that while the 4 of them are cyclic of period 2PI, h1(rho) is an odd function and h2(rho) is even. h3 seems to be antisymmetric. k(rho) is constant, and it is not surprising, since rotating HKF around its (HF) side will not modify the opposite angle k. But apart from that, the h1(rho), h2(rho) and h3(rho) functions are severely non-linear and often far from the basic trigonometric functions.

One interesting thing however is that h1(rho) and h3(rho) always have just one intersection on the [-PI,PI[ interval (the vertical red lines are just artifacts, h1 is periodic of period 2*PI).
Why is it interesting you ask ? h1 is the angle of the servo that rotates around the vertical axis of the body, in 3DOF it is the one that contributes the most to the forward-backward movements. h3 is the angle of the rotation around the femur axis, so when the femur is not too far from horizontal, rotating it will move the foot mostly on the forward-backward direction. The two other angles have very smaller impact on the forward-backwards movements. Considering this, we can reformulate our first idea as trying to minimize the sum of the travel lengths of h1 and h3 from their default position. The cool thing is that this condition will be fulfilled when h1(rho)=h3(rho). So the fact that there is on and only one value of rho in the considered interval that yields this particular result makes me confident that an acceptable solution can be found.

A few tests using a brute-force algorithm to compute Rho (try incremental values of rho until h1(rho) is nearly equal to h3(rho) ) shows that the result looks good enough when moving the target position around. With this, we now have a way to find the values that the heuristic function have to return.

With a way to find a value of rho for a given target position, albeit a very computation-expensive and slow one, we can try to visualize the function we are interested in. As it is a function of 3 parameters (target_x,target_y,target_z), visualization of the results for the whole input space is not really practical, so I just did a few tests where the input space is reduced to an horizontal plane.

The following image shows the value of Rho for all the accessible position on the plane z=-75, which is not far from the default height at which to robot would operate when walking. On the vertical axis are the values of Rho scaled for ease of comprehension, so when the point is at the ground level, it means that the result of the equation h1(rho)=h3(rho) is rho=0 for the corresponding position (x,y,-75) of the foot target. When the point is above the ground, rho is positive etc...
This example is in the repository (rho_visu.py), you need to get all the .dat files too to use it.
(click to enlarge)




Not exactly evident, but we can see (well, with the model before your eyes, you could see...) that on all the planes containing the vertical axis, the value of Rho is not too far from being constant, as long as we stay in the zone where the values are not too big. And this is great, because these planes are defined by atan(y/x) = cst.
I tried to visualize the function atan(y/x) on the same graph, and it appeared that it was not bad but needed some fitting. A few tries later, I settled for the function :

Rho(x,y,z) = 0.75*atan2(y,x)

On this graph, the red squares are the values of my Rho(x,y,z) function, the blue ones are the same as previously. It look good enough don't you think? (click to enlarge)




Results

Here is what it looks like when the Rho heuristic function is used :














Further development

The heuristic found seems to be ok when I look at it in the simulator (where most servo limitations are not implemented) but it may not survive the test on the actual robot.
Also, their is a discontinuity around +/-PI due to the 0.75 coefficient that needs to be ironed out.
Finally, when we look at the values of the theoretical Rho and my approximation on planes farther from the default position, it appears that the error quickly grows... I may have to look into that if I want the robot to be able to take quite extreme poses... but for now it's good enough ^^.


Next, body translation and rotation.

[animeunplugged]

Wow I love ghost in a shell!!! And keep up the good work!!! Oh and do you have any new updates on this project?

[Xevel]

I wanted to take a little break from coding and do some physical prototyping instead. The post on body rotation will come, but I am still pondering if I should include the gait rotation speed into the body orientation code (like it's done in the Phoenix code) or not.


So here is the first proto of the lower part of the leg.



The goal here is to get a little closer to the original Tachikoma not in terms of design, but in terms of motion abilities.

With this assembly, the bot can switch its wheels from fixed, to free, to powered, without need to lift the wheel from the ground.
To be able to drive the robot in good conditions, the wheel needs to be orientable, and the first 4 degrees of freedom of the leg are not ideally suited for this, so I added a servo turning around the axis of the tibia (I consider it as an end-effector, since it does not change the contact point with the ground : the leg is still 4DOF).

The proto weights around 19g this proto, next units should be lighter.

And for a little video of the thing. Fixed mode is not shown (not yet implemented).




Have a look in my gallery for more pictures!

[Xevel]

Last week, we finally assembled the beast, and tonight I finished implementing a quick bridge between the robot and the simulator.

Note that the servos are, indeed, very low quality and as a result, the movements are very jerky and approximative (as an eminent member of this community often puts it "you get what you pay for").

[darkback2]

While the motions may be jerky because of the cheap servos, the control system is really cool. You can always get better servos as money permits. Good job.

DB

[Xevel]

Thanks darkback2

I am slowly buying some Hitec servos to build a reasonably better version of this bot, one after the other... maybe I'll have enough in a few months, who knows ^^
In the meantime we can still work on the control program, we have a lot of things to implement