Continuing My Project

Lynxmotion Legged Robots
141

Ok i’m back, after making few swaps in the leg order i found out the leaving things as they are, although they’re confusing, will keep things working. I went back to changing values and i got quite tired from changing them back and forth so i thought about the following:

Since i designed my robot to have a circular symmetry ( the coxas are all on the same circle ) i thought why not use two sine functions of 24 steps with :

      For X-axis
                       Min value  : Step 2
                       Max Value : Step 14
                       A Period of 24 steps

      For Y-axis
                       Min Value  : Step 11,23
                       Max Value : Step 5,17
                       A Period of 12 steps

I’m working on making such functions at the moment. One question though, can the position shift be a floating value or it has to be an integer ?

Edit: GOT IT :slight_smile: !, I’ll be using this formula http://s2.postimage.org/ceaf58jyx/Shift_Formula.png

Where:

X : is step number
Mid: is the mid point where the shift is 0
T : is the period

142

You don’t really need to change the legs over…
The robot is correct.

I mean,
1
2
3
4

Is the same sequence as

3
4
1
2

Being that once its completed the forth move it starts at one again.

143

hmm, yea, that seems about right. I’m Having a problem with float math when i added the function, i got this code here :

BodyPosX =100.0*FSIN((tofloat GaitStep-8)*((2.0*3.141592)/24.0)) BodyPosZ =100.0*FSIN((tofloat GaitStep-2)*((2.0*3.141592)/12.0))

It’s giving me an error saying “Error: FILE H:\POTATO\CREATIVITY\ROBOTS\PHOENIX BETA 2_1 T-HEX SSC-32 PS2\PHOENIX_CORE.BAS(LINE 724) : [TOKEN BODYPOSX] : LET argument INTEGER/FLOAT type mismatch”

I’ll work on a table generator in excel until i get a reply.

144

First off looks interesting, I am following along with my Quad(s) using Arduinos… (Still have to assemble 2nd one).

Have you tried:

BodyPosX = toint 100.0*FSIN((tofloat GaitStep-8)*((2.0*3.141592)/24.0)) BodyPosZ = toint 100.0*FSIN((tofloat GaitStep-2)*((2.0*3.141592)/12.0))

To tell the system to convert back to integer value in much the same ways you used tofloat to convert integer to real…

Kurt

145

still getting mismatch error

“Error: FILE H:\POTATO\CREATIVITY\ROBOTS\PHOENIX BETA 2_1 T-HEX SSC-32 PS2\PHOENIX_CORE.BAS(LINE 724) : [TOKEN BODYPOSX] : LET argument INTEGER/FLOAT type mismatch”

146

Try this, it compiles with a real small test program

Kurt

147

still same error :confused:

148

Strange.
Which version of the compiler? I am running .18+ on mine. The + has to do with some stuff I am helping test, before it become 19…
My whole test program is:


BodyPosX var sbyte
BodyPosZ var sword
GaitStep var byte

BodyPosX = toint (100.0*FSIN((tofloat (GaitStep-8))*((2.0*3.141592)/24.0)))
BodyPosZ = toint (100.0*FSIN((tofloat (GaitStep-2))*((2.0*3.141592)/12.0)))

Does this compile on yours?

Kurt

149

I’m not sure how to check the compiler version but i got Basic Micro Studio 2.0.0.15, I’m also done with the table :slight_smile: :

the column with magnitude “1” is just to show how the sine function work through out the steps

150

Yep you are running build 15. If my test program does not compile on your machine, you might want to download the latest and greatest from the Basic Micro download page: basicmicro.com/Downloads_ep_43.html

Kurt

P.S. - You can also use the fixed math sine and cosine functions built in to the Phoenix code base:
It is the function: GetSinCos[AngleDeg1]
Which uses tables for fast lookup.

151

The table from the excel worked rather well :slight_smile:, that is before the battery died. There is still a problem with the legs on the back, they never lift no matter what the shift magnitude is, the robot just leans back on them while the ones on the front work fine :neutral_face: . i really have no idea whats wrong with them.

I’m waiting for the robot to recharge so i can work on that problem

Edit: yea, i saw the table but the values were in the thousands so i decided to use excel. Thanks for the note though :smiley:

152

I’m back again. I reduced the shift magnitude to 40 since 80 was quite hectic. But still the gait isn’t going very well. i tested the gait on different surfaces and this is what i saw: the front legs lift and swing (step) ok (not great but still ), the back legs do not lift instead the body leans on them and then they swing on the floor.

has anyone had this problem where the robot feet slide instead of lifting and stepping forward ? if so, how did you fix it ?

153

When holding the robot in the air does the gait look normal? I feel your just experiencing an un balanced center of gravity. If the body is tipping backwards then those legs are effectivly lifting.
A video will help me understand…

154

The gait seems normal except at some point the robot shivers as if its starting the gait all over, and he does that periodically. unfortunately i don’t have my dad’s camera with me to snap a video, ill see if i can get it by the end of the day.

Note: i traced the shift values, there isn’t any point where the legs might shift unexpectedly and cause a shiver. Here are the values :

X_Axis_Shift bytetable -35,-39,-40,-39,-35,-28,-20,-10,0, 10, 20, 28, 35, 39,40,39,35,28,20,10,0,-10,-20,-28, ;Magnitude 40 Z_Axis_Shift bytetable -35,-20, 0, 20, 35, 40, 35, 20,0,-20,-35,-40,-35,-20, 0,20,35,40,35,20,0,-20,-35,-40, ;Magnitude 40

155

Sorry that took long, here is the video :

the gait kinda looks random :neutral_face:

156

Really curious how you’ll incorporate the extra DoF into the walking gait…
Do you already have a gait for the 12DoF quad?
Refresh my memory - which microcontroller are you using?

157

Well, the extra DOF is always at max angle when gaiting, just act as if it’s not there ( its connected to unused pins anyway ). I’m using Basic Stamp Pro with Bot Board 2 as a carrier connected to SSC-32 Servo Controller

158

Hi. Thanks for posting a video. Although unfortunately I cannot tell anything from it. Id need to see it walking on the ground as its hard to the difference between actual gait and body shift.

Second, im not quite sure what work you have done regarding your tables as it doesn’t look like the one I posted, where the value 128 is center not 0?
If your robot is symmetrical and weighted correctly then the shift values when going forward should work on the rear also.

159

the values you posted had 128 as center because of the subtraction by 128 in the code,i removed the subtraction in these line :

BodyPosX =(X_Axis_Shift(GaitStep))-128 BodyPosZ =(Z_Axis_Shift(GaitStep))-128

so the center is 0. But i just noticed something, when i changed the values it’s still a byte table… byte tables cant have negative values right ? If so then that might be the problem, i’ll change the table type and see what i get.

160

Yep, that will cause an issue like that!..

Kurt