How to rotate Multibody back to its "starting" pos

its easy , dont use realative rotatoin but just set absoulte rotatoin to zero
, also sometimes if you try and rotate each axis at the same time can cause glitch's.so sometimes its better to use three commands like below. Also if its on the floor when you call this it could push it through the floor. so do it straight after the move multibody. Also if you want it to drop without changing its XZ posistoin then get the randomlocatoin , so randloc=random[x,y,z] , then when its droping use getlocatoin , so loc=(get locatoin), then just move to (randloc::x,loc::y,randloc::z). this will allow it only to go down on the Y axis , then use the code below.

     self   rotate around-axis (0,1,0) by 0.00. 
     self   rotate around-axis (1,0,0) by 0.00.
     self   rotate around-axis (0,0,1) by 0.00.

Also if you do have any trouble straighting up i LOVE this peice of code.

for each revjoint:
Revjoint{n} set-joint-velocity to -(Revjoint{n} get-joint-angle) . 

sorry if ive bored you hope some of it can be usefull.

OK, thank you for your help NoZ...
It doesn't work with a 0.0 angle, but it works fine with angle value 1.0 rotating only the x axis:

+ to center:
    self move to (0, 100, 0).
    self rotate around-axis (1, 0, 0) by 1.0.
    self move to (0, 10, 0).

The straigting up does not work in this case, since the driver apply its own join velocity at itteration time. But thanks for the hint.

I don't understand very well yet this rotate around-axis (still did not finish reading the doc :( ) but at least now my horse is learning to walk...

I just wonder, is there a way to tell an object: "hey you know your default plane I've defined when I created you, well you gona rotate so that this plane is paralel to this other plane, or perpendicular"???

Also, I've seen that there are sensors, is there something close to an equilibrium sensor? So movement could be adjusted according to a "signal" (value) sent by this sensor or something like that...

Quote:
I just wonder, is there a way to tell an object: "hey you know your default plane I've defined when I created you, well you gona rotate so that this plane is paralel to this other plane, or perpendicular"???

im not exactly sure what your getting to here but when you create a object is has two angles , Absoulte rotatoin and relative rotatoin. say the roatoin is 180, if you say change your absoulte angle to 5, will change its rotatoin to 5. if you say change relative to 5 , then your absolute rotatoin would change to 185. so i find it a bit easer to use absolute rotatoin and just keep track of it.

when you first begin each object unless specidied will start off with absolute roatoin of zero. so if you check the objects and your rotatoin and they are the same then your parallel, else you are perpendicular.

this could be used as a stability seansor, if self get-roatoin on z or x axis is 180 then you creature will be on its back.

its a intreasting idea you got there , ive been thinking about it myself but i cant figure out how to implement code for it to go "ahhh im falling over" and for it to right itself. i suppose if you wanted to make your creature walk in a more level way you could keep a eye on its roatatoin on axis , and only walking algorythems which dont have high rotatoins get to breed. have you kept with the original code or made your own mutatoin etc code?

Also could you do me a bit of a favour and see if you enter the same arguments if you get the same results?keep the same monkey driver for two turns or something? becouse ive written my code but theres i think theres a problem in the breve engine somewhere. thanks alot
NoZ

hmmm... Couldn't you put a proximity sensor on its 'belly' and one on its 'back' ?

The belly should sense it is close to a surface or even see the surface is a certain colours; vice versa, the back sensor has to sense there's nothing close to it (sky is the limit) or 'see' blue sky...

if these two sensors say something is wrong, that means the horse is on its back...

It is almost 1h00 in the morning here, so I'll be short.

NoZ, thanks for the explanation about absolute/relative rotation, I now have a better understanding of it!

About the equilibrium center, I'm looking for something more general, not only for an horse creature. The idea is to let evolving creatures use feedback from the equilibrium center to "adapt/evolve" its own movement behavior. Therefore, creatures that would be able to exploit this feature, would also be most probably more efficient in walking behavior (I guess).

So, Rxke, proximity center may work for the horse, but it would be more tricky if creatures grow parts and stuff like that (I guess, again).

I don't know so much about equilibrium center, but I guess it should be related to the position of the center of gravity relatively to the body/mass... something like that... Anybody knows how it works for human being and animals?

NoZ, I've twikle a bit the original mutation code... It was going a bit to slow for me... I'll try to check if breve engine is cheating on us (though, not now... this week probably). Also, I don't know if it is related, but I've noticed that when you switch drivers, the creature keeps its motion, so it won't land exactly the same place and the same way. I've use this line in the simulation to stop having strange starts from time to time and not risking to ruined a good "seed":

    bodyLink set-velocity to (0, 0, 0).

Still, I find it a bit strange that I cannot give this "order" directly to the MultiBody.

OK, time for bed. BTW, my horses are not going bad...

im thinking somewhere in breve theres code for center of gravity. intreasting though becouse the centre of gravity would change while the creatures moving. if ive got time i'll do a google but if the creatures evolves new bodyparts , it could mean that the creature would travel best on what it considers its back. so equlibrium could hurt the GA.

also ive made my own genetic algorythem. i cant find any error in my logic . i create 36 lists of random numbers. so i have 36 "seeds" or trails. i then reset the body,then allow the creature to be controlled by one list.i get the distance of this list and attach it to it. i do this 36 times and then keep the best five lists with best distances. i do not change them at all , i then make 31 new lists from the best five lists and do it all over again. i even reset the time varible each time i try a new trail.so if the breve engine is being constant , my distances should never start to go down, unfortnatly they do. Got any ideas? all i can think of is the breve physics is reacting in differnt ways each time.

sorry for rambling. im off to do a google on centre of gravity.

Well, after several tries, it seems that there is a little bit of random in breve physics. I've tried to use fixed genome data values for all drivers (no random at all) and of course no mutation either. I've disable fast physics and, to rule out possible time effect, I get a reference time at the last step of the "init" and "pick-drivers" methods:

   referenceTime = (self get-time).

so the iterate method use the time elapsed since the last reference time:

    + to iterate:
        seats{currentSeat} control robot wigglyThing at-time ((self get-time) - referenceTime).

But still, the distance difference between the faster and slowler drivers is approximately 2.3 (no matter what I do). So obviously, breve physics is not very accurate.

Maybe it is inherent to the integration-step vs iteration-step scale and rounding errors!??? But I really have no idea why there is such a difference. I guess you should ask jk.

Otherwise, I don't know so much about GA, I just though that picking two out of four (original walker code) was not very optimal, so I've expand the choice over all drivers. And breed the 5 bests replacing the 7 worsts. That's all. I have no idea if it is the best mathematical choice or not (wonder if there is such a thing!?). Nevertheless, it speed the evolution process and the population of drivers converge to a "stable" state quickly.

Didn't check on equilibrium either yet... Later this week I guess.

So long!

In case it might be helpful to other beginners and to close the subject, here is the final solution to the original question (using the original TerrainWalker demo):

+ to center:
    self move to (0, 100, 0).
    self rotate around-axis (1, 0, 0) by 1.57.
    self rotate around-axis (0, 1, 0) by 0.
    self move to (0, 4.5, 0).
    bodyLink set-velocity to (0, 0, 0).

I'm not sure the first line is really needed, but have no time/don't want to test...

This peace of code, will make sure that all drivers will start in the same orientation, velocity and height.

My own comment:

1. IMHO, it shouldn't hirt to recall to the reader in the definition of "rotate around-axis" method that the REAL world vertical axis is the Y axis, not the Z axis (hope that one is not to obvious... :?).

2. For what it is worth, from an OO point of view, I would have expected that MultiBody class has a global "set-velocity" method or at least a "get-root-link" method. So that, instead of writing "bodyLink set-velocity..." we could write "self set-velocity..." or "(self get-root-link) set-velocity...". But again, I'm just a beginner that still didn't have read all the documentation yet... :oops:

Anyway, breve is fun!!! I Like it very much.
I'll be very glad if I could help improving it (after having read all the doc, "bien entendu").

Regards,
The END.