Accessing Keyboard and mouse by using Breve

the links of a body dont have to touch at all and it'll still work.
when you built your qaudratic body did you have quadratic legs? try cubiod legs maybe? sorry i cant be much help.

Noz

as i mentioned before, i used the same polydisk-legs in my quadratic testrobot, so i think this is not the reason ..

well i cant really investigate unless i can see your code BUT!! i think becouse of the nature of your multibody shape you could use a little hack. i dont think your main disc shape needs physics enabled? so instead of using the disc as your main part make a small sphere with a radius of like 0.2 or something then connect your legs , remember that the legs can be a millon miles away and it'll still work. then make the disc shape as a normal agent. set this agents posistoin and roatoin to the multibodys and it would look exzactly like you have done it but it might solve your problem, it would look and act like it does now but shouldnt slow down.

this is the best solutoin i could think of with what youve said.

good luck and have fun
Noz
btw your program looks quite intreasting.

I tried your very promising and replaced the shape of the MultiLink-object through a 0.2 Sphere. For the beginning I did not use any additional "dummy-body". Sadly, nothing changed.

If you are interested, i uploaded the code:

http://zeus.fh-brandenburg.de/~huellein/elfe.html

I dont know WHY the simulatoin is slowing down so much BUT there are two differnt ways of fixing it. the first is to use cuboid legs ,the simulatoin seems to work fine then. the secound is to allow the legs to move a bit , they dont seem to like being at there normal. i got a bit of code in there to do that.
its up to you. if i had time i would think about the normals or spring strenth or something like that becouse the simulatoin only seems to slow down when the legs are discs and there in normal posistoin. so its up to you , sorry i couldnt help you more but i did put a bodged fake body in for you and some other tiny bits to help you debug :)

good luck and have fun

@use Link.         # changed these becouse my breve couldnt find controller     
@use Genome.         
@use Terrain.        
@use PhysicalControl.
@use Shape.
@use Stationary.
@use MultiBody.
@use Drawing.
@use Line.

		@define ELFE_BODY_RADIUS        5.
		@define ELFE_BODY_HEIGHT        1.
		@define ELFE_BODY_SIDES         11.
		@define ELFE_BODY_NUM_LEGS      11. #11

		@define LEG_HEIGHT              2.
		@define LEG_RADIUS              0.3.
		@define LEG_SIDES               11.

		@define PI                      3.141592653589793.


#changed to make it easer for me , not any prob changing them back
Controller Walker.              # Defines the main class as Walker

PhysicalControl : Walker {      # the main contoller for the simulatoin
		
		    +to init:
		        ground(object).
		        bgImage(object).
		        draw(object).
		        elfe(object).

 
		        bgImage = (new Image load from "images/clouds.png").
		        draw = new Drawing.

		        print "Setting up Elfe simulation.".

		        # basic graphic settings
		        self enable-lighting.
		        self enable-shadow-volumes.
		        self enable-smooth-drawing.
		        self set-background-texture-image to bgImage.

		        # floor configuration
		        ground = new Floor.
		        ground catch-shadows.

		        # some visual aid: painting coordinate system axis
		        draw set-color to(1, 0, 0).
		        draw draw-line from(0, 0, 0) to (10, 0, 0).
		        draw set-color to(0, 1, 0).
		        draw draw-line from(0, 0, 0) to (0, 10, 0).
		        draw set-color to(0, 0, 1).
		        draw draw-line from(0, 0, 0) to (0, 0, 10).

		        draw set-color to(1, 1, 0).
		        draw draw-line from(0, 4, 0) to (0, 4, -5).

		        #self point-camera at (0, 0, 0) from (-1, 15, 10).
		        self point-camera at (0, 0, 0) from (0, 15, 0).

		        elfe = new ElfeBody.
                        1 new mainshape. #this creates a object without physics, it will look right BUT WONT AFFECT ANYTHING
		        #self watch item elfe.
                        


		}

		MultiBody: ElfeBody
		{
		    +variables:
		        bodyLink(object).
		        joints(list).
		        legs(list).
		        bodyShape(object).
                        n(int).
                        age(float).
		    +to init:
		        # local declaration
		        joint(object).
		        i(int).
		        dx, dz, alpha, radiansBetweenLegs(double).

		        ###########################
		        # INIT BODY
		        ###########################
		        bodyLink = new Link.

		        bodyShape = new Sphere init-with radius 0.2.
		        bodyLink set-shape to bodyShape.
		        bodyLink set-color to(1, 0, 0).
		        self set-root to bodyLink.
		        self show-axis.


		        ###########################
		        # INIT JOINS
		        ###########################
		        joints = ELFE_BODY_NUM_LEGS new RevoluteJoint.

		        foreach joint in joints:
		        {
		            self add-dependency on joint.
		        }


		        ###########################
		        # INIT LEGS
		        ###########################
		        legs = ELFE_BODY_NUM_LEGS new Leg.
		        # calculate the angle between each leg in radians
		        radiansBetweenLegs = 2*PI /ELFE_BODY_NUM_LEGS.
		        # rotate startangle of first angle so that each leg is centered on
		        # the polygon's sides
		        alpha = radiansBetweenLegs/2.

		        for i=0, i<ELFE_BODY_NUM_LEGS, i++:
		        {
		            # new vector in direction of position angle
		            dx = cos(alpha).
		            dz = sin(alpha).

		            if i==0: legs{i} set-color to(1, 1, 0).

		            joints{i} link parent bodyLink to-child legs{i}
		                with-normal(dz, 0, -dx)
		                with-parent-point( dx*(ELFE_BODY_RADIUS+LEG_RADIUS), 0, dz*(ELFE_BODY_RADIUS+LEG_RADIUS) )
		             #   with-parent-point( dx*(ELFE_BODY_RADIUS), 0, dz*(ELFE_BODY_RADIUS) )
		                with-child-point( -dx*LEG_RADIUS, 0, -dz*LEG_RADIUS).


		            alpha += radiansBetweenLegs.
		        }


		        self move to (0, 3, 0).

		        joints set-double-spring with-strength 300 with-max 0.8 with-min -0.8.
		        joints set-strength-limit to 400.

                        + to iterate:


         #       for n=0, n< |joints|, n+=1:                      ### I JUST PUT THIS IN TO SEE HOW WELL IT WORKED,
         #       {
         #       age=(self get-age).
         #        joints{n} set-joint-velocity to (sin(age)).
         #       }

		}

		Link: Leg
		{
		    +variables:
		        myShape(object).

		    +to init:
		       # myShape = (new PolygonDisk init-with radius LEG_RADIUS
		       #                                      sides  LEG_SIDES
		       #                                      height LEG_HEIGHT).    
                        myShape = (new Cube init-with size (0.2,1,0.2)). 
		        self set-shape to myShape.
		        self set-color to (0, 1.0, 0.0).

		}
                
           Mobile : mainshape 
             {
             + variables: 
              body(object).
                        bodylist(list).
            + to init:
                       
                        
                  self  set-shape to  (new PolygonDisk init-with radius ELFE_BODY_RADIUS
		                                               sides  ELFE_BODY_SIDES
		                                               height ELFE_BODY_HEIGHT).
                                                               
            + to iterate:

            bodylist=all ElfeBody.
                        foreach body in bodylist:
                        {
                       self move to (body get-location).
                        
                        }
                     }

	

Wild guess... Try to create an iterate method in your Controller class:

+ to iterate:
    print "Am I alive?".

Apparently breve does not like not having an iterate method in the Controller class. Don't ask me why...

BTW, it seems, you could also use only one leg shape instead of intantiating a new one each time...

hes right about the legshape, define the legshape in the controller then referance it for each leg. Although the controller class shouldnt make a differnce. I DO ALOT OF WORK within the controller class. That said my latest breve code crash's without warning. but if its the iterate method then it shouldnt make a differnce if the legs are moving or not though.

Pterodactylus wrote:

+ to iterate:
    print "Am I alive?".

Apparently breve does not like not having an iterate method in the Controller class. Don't ask me why...

BTW, it seems, you could also use only one leg shape instead of intantiating a new one each time...

Ooh, be careful with this -- the iterate method will probably make things worse! Two problems: first, printing out a line of text will actually make the simulation run slower because outputting line after line of text can be surprisingly time consuming. Second, and far more important, this iterate method lacks a call to "super iterate". Without the "super iterate" call, most of the internal simulation code will not get run correctly. The Control class iterate implementation must always be run!

- jon

jk wrote:
Ooh, be careful with this -- the iterate method will probably make things worse! Two problems: first, printing out a line of text will actually make the simulation run slower because outputting line after line of text can be surprisingly time consuming. Second, and far more important, this iterate method lacks a call to "super iterate". Without the "super iterate" call, most of the internal simulation code will not get run correctly. The Control class iterate implementation must always be run!

- jon

OK, OK... I'll finish reading the doc before giving anymore advices... :-(
Though, without the call to super iterate, the "sort-of" simulation was speeded up... :?

First of all thx a bunch for checking the code, especially for NoZ. I will try a few suggestions and look over your code then I report back.

Ok, ive made a few experiments. Yesterday I took my first walker-file and added to the cubic body eleven PolyDisc-legs, each besides the other. It ran perfectly. So I guess its not the shape of the legs. Then I took a PolyDisk for the body with increasing side number, there you can see how the performance gets worse at a special point of time during motion. I looks like its where the leg could collide with the body, but this shouldn't be a problem since the collision detection between the parts of a MultiBody is deactivated at default.
With a PolyDisk of only ~10 Sides this example runs fine: But this is strange since the same number of sides didn't work for the Elfe-Example. The difference between both programs is the arrangment of the legs. So i think your rigth and the problem lies in linking the objects.

You mentioned before that using a hack like linking simple objects but moving and displaying complex would behave as the original. But wouldn't that mess up my physical results? I could give the simple object the same mass as the displayed one. But the collision detection would be a different one (?!). The displayed object (the one which are closer to the real robot) owuld be moved manually and would have no influence of the motion of the whole MultiBody.

plz watch at the following code

@use Mobile.
@use PhysicalControl.
@use Stationary.
@use Link.
@use MultiBody.
@use Terrain.
@use Shape.
@use Drawing.

Controller RobotController.

PhysicalControl: RobotController
{
    +to init:
        ground(object).
        bgImage(object).
        draw(object).
        robot(object).
        
    
        bgImage = (new Image load from "images/clouds.png").
        draw = new Drawing.
    
        print "Setting up the robot simulation.".
        
        # basic graphic settings
        self enable-lighting.
        self enable-shadow-volumes.
        self enable-smooth-drawing.
        self set-background-texture-image to bgImage.
        
        # floor configuration
        ground = new Floor.
        ground catch-shadows.
        
        # some visual aid: painting coordinate system axis
        draw set-color to(1, 0, 0).
        draw draw-line from(0, 0, 0) to (10, 0, 0).
        draw set-color to(0, 1, 0).
        draw draw-line from(0, 0, 0) to (0, 10, 0).
        draw set-color to(0, 0, 1).
        draw draw-line from(0, 0, 0) to (0, 0, 10).
        
        self point-camera at (0, 0, 0) from (-1, 15, 10).

        robot = new Robot.
        self watch item robot.
        
        
        +to iterate:
            if (self get-time) >= 5 && (self get-time) <=6: 
            {
                print (self get-time).
            }
            
            super iterate.
}

MultiBody: Robot
{
    +variables:
        bodyLink(object).
        #joint1, joint2(object).
        joints(list).
        legs(list).
        bodyShape(object).
        
    +to init:
        # local declaration
        joint(object).
        i(int).
    
        # init body 
        bodyLink = new Link.
        
        # THIS RUNS FINE
        # bodyShape = (new Cube init-with size(5, 1, 5)).
        
        # THIS DEPENDS ON THE RADIUS OF THE SPHERE
        # 0.5 = STRANGE                 1 = OK
        # bodyShape = (new Sphere init-with radius 1).
        
        # THIS DEPENDS ON THE NUMBER OF SIDES
        # 5 = GOOD      
        # if you add more the theres a point during motion where performance cracks down
        # so try sides = 50
        # bodyShape = (new PolygonDisk init-with radius 2.5 sides 50 height 1).
        
        
        bodyLink set-shape to bodyShape.
        bodyLink set-color to(1, 0, 0).
        
        # init legs
        legs = 11 new Leg.
        
        self set-root to bodyLink.
        
        # init joints
        #joint1 = new RevoluteJoint.
        #self add-dependency on joint1.
        
        #joint2 = new RevoluteJoint.
        #self add-dependency on joint2.
        
        joints = 11 new RevoluteJoint.
        foreach joint in joints:
        {
            self add-dependency on joint.
        }
        
        
        for i=0, i<11, i++:
        {
            joints{i} link parent bodyLink to-child legs{i} with-normal(1, 0, 0)
                with-parent-point(2.5+i, 0, 2.5) with-child-point(-0.15, 0, 0).
        }
        
        self move to (0, 1, 0).
        
        #joints set-double-spring with-strength 300 with-max 0.8 with-min -0.8.
        joints set-strength-limit to 400.
        joints set-joint-velocity to (0.50).
        
        
        
}

Link: Leg
{
    +variables:
        myShape(object).
        
    +to init:
        #myShape = (new Cube init-with size(0.3, 1.5, 0.3)).
        myShape = (new PolygonDisk init-with radius 0.3 sides 10 height 2).
        self set-shape to myShape.
        
        self set-color to (0, 1.0, 0.0).
}

from what youve said the only thing i can think of is computatoin of physics. i know sometimes physics can act strange when using custom shape objects. So maybe this is the problem. now you can use a dummy body, which should have no differnce in affect for the simulatoin becouse the ONLY parts of your creature that touch anything other than itself is the legs, if it lands on its side the legs will be the main point,if on its frount or back the legs will still be the main point. the only way i can think of is that the physcial mass of the disc might be used in some calculatoins like force etc etc. but scince the pain point in these calculatoins would be the objects furthest away from the fulcrum the legs would be the main point and comapared to that the disc i would think would be minamul. Maybe losing a slight amount of accuracy that breve might not even use. ( i havent looked closely at the physics engine yet).

would you be soo kind to explane what you will be trying to achive in this simulatoin. becouse a dummy body could have serious flaws if there where going to be body muatoins etc.

The main goal of this project is to program via GP a walking algorithm for the Elfe robot. You can get a picture of it here:

http://ots.fh-brandenburg.de/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=54&MMN_position=67:34

Because these walking patterns shall be applied to the real robot it is
necessary to rebuild it as exactly as possible. This includes the main shape of the robot's body as well as the shape of the legs. The Elfe will get equipped with four infrared sensors to measure the distance from the body to the ground.

defently a challange :)

i dont know if this would work but it might. set the disc shape for the main body then instead of attaching the legs attach simple cubes , these can be considered the motors. when joining them to the body use static joint with a high tourqe rating. this would simulate the motors being screwed into the framwork of the robot. you can then attach the legs with revolute joints to the cubes. i think this could solve the problem as static joints dont need much calculatoin and the legs will behave as they are attached to a normal cube , becouse they are :) it also offers the bonus of giving the motors waight which i would think is one of the more heavy factors in waight distrabutoin in the robot. i dont know how much detail breve goes into waight distrabutoin but i would think the more indevidual components you put in the more realistic the robot would be.

like i said i dont know if this would work but it makes seanse in my head. also it will make a more realistic simulatoin.

Sorry to be so late in chiming in on this thread, but I've just now had a chance to run the code with a profiler and see where the actual slowdown is. The slowdown is in the low-level physical simulation code, and it's happening presumably because of the number of points in contact with the ground on each leg. The default physical simulation is roughly O(n^3), meaning that the simulation time grows with the cube of the number of contact points (or other constraints). The number of contact points on your robot is pretty big, and this is making the simulation crawl!

There is a solution though -- the "fast physics" algorithm included with breve (see the PhysicalControl class method enable-fast-physics) is closer to O(n), meaning that you can keep adding constraints to the system and the simulation will slow down in a linear fashion. The fast physics algorithm does not solve all of the constraints at once, like the normal physics -- instead, it uses an iterative approach which operates repeatedly on smaller subsets of constraints. The downside of this is that the accuracy is slightly worse, but I think it should be accurate enough for what you're doing. There's also an iterations parameter which you can use to find the proper balance between speed and accuracy. Unfortunately, I don't know of any way to formalize these tradeoffs -- the only was to figure out if it's accurate enough is trial and error.

When I enable fast-physics on your simulation, it *flies*, and I don't see any differences in the behavior.

So to summarize: you have a large number of constraints in the system in the form of contact points. Either use fast physics, or reduce the number of contact points in the system.

- jon

Aha! Yes, this looks very good. Shame on me that I didn't try fast-physic by myself. Now it runs. Again thx all for the time you invested in my problem. Because I'm going to use breve with this robot in my diploma work I think I will need more advice in the future :D