Thanks everyone, The gait looks way better than before when held in the air, you can see both the steps and shifts.On the ground it still needs some work but it sure is better than before , i’ll test out different shift magnitudes till i get the perfect values and get back to you 
.
Here we go, The 1st video is using a table with a max shift value of 40 while the body is shifted to the front by 20 , that is 108 to 188 bytes from innerbreed table:
NOTE !!! : you might wana lower your speakers volume, the workshop was quite noisy x)
The 2nd video has a max displacement of 80 and shift of 40 to the front ( 88 to 248 bytes ) so it looks a little more wild, but still the back left leg didn’t lift. I’m starting to think that the fact im using “sine” as a function to get the displacement value is wrong and i should use something different, here is the video :
Im not quite sure I see an improvment. If you add the shift code directly under the part in the code that says [main] we will see it shifting while standing still. This will help identify if the body is moving correctly. The center of the body should be going round in a circular motion. Try that…
Looks interesting. What happens if you try walking backwards? Does the rear (now logical front) legs move and the others don’t?
Also I would check things like your minimum and maximum values for servo joints. I have been bit before when they were set such that a leg could not move where I thought it should be…
I took the day off from that type of quads and was playing around with different types of quads…
But that is a different subject. Also please pardon the wires hanging out and the like as I just updated Lynxmotion one to Botboarduino, may also update it to Roboclaw for the two encoders on it…
Maybe today, probably tomorrow, will get back to trying to make my quads walk.
Kurt
I think the problem is in the shifting values. I did what innerbread mentioned, normaly the robot should shift in circle with its legs fixed to the ground, but mine shows too much sliding, then the battery died… hehe . I remember when we tried the shift table values for the 1st time, the robot kept swinging in a circle because the code wasn’t in the right please, i think i’m rolling back to that since it was working properly, ill charge the batteries, test that out and get back to you.
Permafrost
So i rolled back to the old values from innerbread, did a little tweaking so that Z-axis have the same shift distance as the X-axis. The robot now shifts in a smooth circle but still no gaiting, today when i was snapping a few pictures of my robot’s poses i noticed that when on tilt mode (L2) when i hit forward the robot tilt forward, same thing for backwards. but when i hit left the robot tilts to right and vice versa, and i noticed that the gait should go RF RR LR LF ( clockwise ), but it is actually going counter clockwise ( LF LR RR RF ) which happens when you reverse the left and right , i tried reversing the pins through the code but that had no effect at all. Any idea what could be causing this ?
Is there are part at the start of the code that looks like
cRR=0
cRM=1
cRF=2
cLR=3
cLM=4
cLF=5
.?
This is the sequence that the legs will go in. You can simply move these about so it runs the other way.
yep found it, but if that’s the sequence then why do we use of this piece of code :
[code]Wave24: ;Wave 24 steps
GaitLegNr(cLR) = 17
GaitLegNr(cRF) = 5
GaitLegNr(cRR) = 11
GaitLegNr(cLF) = 23
NrLiftedPos = 3
HalfLiftHeigth = 0
TLDivFactor = 20
StepsInGait = 24
NomGaitSpeed = 100
return[/code]
The defines you are seeing (cRR=0), or probably in an enum statement is simply the order the values are stored in arrays of values. Things like Pins, Mins, Maxs, values…
The Gait values for the Wave24 are a definition for a gait… They define what each leg does, in particular the GaitLegNr values defines which GaitStep the leg should be in it’s full up position (mid point of the leg high). My version of the Quad code was updated, such when used in quad mode the middle legs are not there and I am defining a Wave16 instead. When I say Half up or down, the actual percentage up or down is influenced by HalfLiftHeight which in your case 0 probably means fully up…
Note The NrLiftedPos - defines how many GaitSteps of a gait a leg is up…
But From your defines: you have the gait working like per GaitStep:
1, 2, 3 - All Legs are down
4 - The RF leg is half up Back
5 - RF - Full up
6 - RF Half up Fore
7, 8, 9 - all legs down (Actually RF will transition down here)
10 - RR leg is going half up
11 - RR full up
12 - RR half up
13, 14, 15 - All legs down (rr…)
16 - LR Half
…
22 - LF - Half UP
23 - LF - Full
24 - LF Half
1 - All legs down (LF going down here…)
Hope this makes sense.
Kurt
yea, i think i understood that.
So if you put NrLiftedPos = 6 (24/4) there will always be 1 leg in the air and it would take it 3 steps to lift and 3 to land, or does it have to be an odd number so that the leg has a step in which to be fully lifted ?
Don’t know if 6 will work or not. The code normally reads for NR=1(none that I have seen), 2, 3 or 5
The version I am hacking with currently on my quad (not syaing it is right…)…
//Wave 16 steps
GaitLegNr[cRF] = 1;
GaitLegNr[cLR] = 5;
GaitLegNr[cLF] = 13;
GaitLegNr[cRR] = 9;
NrLiftedPos = 3;
FrontDownPos = 2;
LiftDivFactor = 2;
HalfLiftHeigth = 3;
TLDivFactor = 12;
StepsInGait = 16;
NomGaitSpeed = DEFAULT_GAIT_SPEED;
g_fQuadDynamicShift = true;
Disregard the last line as this is something I am playing with…
Note: Mine has 16 steps in gait. My legs go in the order: RF(16, 1, 2), LR(4,5,6), RR(8, 9, 10), LF(12, 13, 14), RF (16, 1, 2)
So you will see that all legs are on the ground on Gaitsteps 3, 7, 11, 15
Note: If you change NrLiftedPos, other values need to be updated to correspond, like: FrontDownPos, which is the number of GaitPos units after the leg value for the leg to go back down… Likewise TLDivFactor is the number of steps in StepsInGait that the leg is on the ground…
Hopefully I explained this correctly… Note the order of the legs moving I have may need to change. As it is neither CW or CCW but more crisscross. So may need to be adjusted. Also not sure if only 1 down step between steps will be correct for what I am trying so may need to adjust to maybe be a 20 step or a 24 step, depending on how many we need.
Good Luck
Kurt
How is it going?
Just wondering where are you doing the code:
BodyPosX =(X_Axis_Shift(GaitStep))-128
BodyPosZ =(Z_Axis_Shift(GaitStep))-128
I believe you removed the subtraction and changed from using a Bytetable…
One thing I am wondering is I believe GaitStep is 1 biased as looking at the code:
IF LastLeg THEN ;The last leg in this step
GaitStep = GaitStep+1
IF GaitStep>StepsInGait THEN
GaitStep = 1
ENDIF
ENDIF
But arrays are 0 biased. So when GaitStep is equal to 24 you may walk off the end of your shift tables.
Kurt
Going fine i guess , except that I’m a little bit crushed in time here, the college’s second semester is starting tommorw and i am making a project with our FabLab team for my country’s independence day (exactly 1 month from now) so i hardly had time to test out the robot.
I returned to using this code :
[code];[GAIT]
GaitCurrentLegNr var nib
Gait [GaitCurrentLegNr]
;Clear values under the cTravelDeadZone
IF (TravelRequest=0) THEN
TravelLengthX=0
TravelLengthZ=0
TravelRotationY=0
ELSE
BodyPosX =(X_Axis_Shift(GaitStep)-128)
BodyPosZ =(Z_Axis_Shift(GaitStep)-128)
ENDIF[/code]
and to using this bytetable :
; (RF) (RR) (LR) (LF)
; 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24,
X_Axis_Shift bytetable 100,110,120,130,140,150,151,152,153,152,151,150,140,130,120,110,100, 89, 88, 87, 86, 87, 88, 89, 90,
; (RF) (RR) (LR) (LF)
; 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 ,19 , 20, 21, 22, 23, 24,
Z_Axis_Shift bytetable 152,153,153,152,151,150,140,130,120,110,100, 89, 88, 87, 86, 87, 88, 89, 100,110,120,130,140,150,151,
but im not sure what you mean by “walking of the bytetable”
“Walking off” - As in using garbage…
- actually looks like your tables have 25 elements each so may not be an issue, except the first elements will probably never be used. That is gait step has the values: 1-24 and your table has 25 values for indexes 0-24. I thought maybe the table only had 24 elements so when you asked for
BodyPosX =(X_Axis_Shift(24)-128) it would have gone off of the end of the table and grabbed the next byte, which your case probably would have been the first byte of the Z shift table… And likewise the Z one would have grabbed whatever byte was stored after your table. But you are probably fine.
Kurt
Just a few more questions… Earlier you generated the table:
X_Axis_Shift sbytetable -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 sbytetable -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
Note: I slightly changed your table here to show how to correct for negative values (sbytetable versus bytetable)
This was the table I thought you probably would walk off the end…
Now looking at your latest post:
; (RF) (RR) (LR) (LF)
; 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24,
X_Axis_Shift bytetable 100,110,120,130,140,150,151,152,153,152,151,150,140,130,120,110,100, 89, 88, 87, 86, 87, 88, 89, 90,
; (RF) (RR) (LR) (LF)
; 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 ,19 , 20, 21, 22, 23, 24,
Z_Axis_Shift bytetable 152,153,153,152,151,150,140,130,120,110,100, 89, 88, 87, 86, 87, 88, 89, 100,110,120,130,140,150,151,Where your legs center up step numbers are: RF(5) RR(11) LR(17) and RF(23) So with your earlier table you had X,Z for these as:
RF (-28, 40), RR(28, -40), LR(28, 40), LF(-28, -40)
Where with the one you just posted, you have after you subtract 128
RF (22, 22), RR(22,-39), LR(-39, -39), LF(-39, 22)
There are a couple of things that catch my eye. First off these tables are out of sync with each other (like maybe 90 degrees). Also the values of the current table don’t look like a normal type ellipse… Was the weight off center or the like and needed adjusting?
Kurt
i forgot to mention that the 1st table was made for a crisscross gait type, the 2nd table is made for simple clockwise gait starting from RF. if you were comparing these two tables, then they should be out of sync since they use different gaits.
Today on my college break i tried switching this order:
cRR=0
cRM=1
cRF=2
cLR=3
cLM=4
cLF=5
to:
cRR=3
cRM=1
cRF=5
cLR=0
cLM=4
cLF=2
but still the tilt on the X-axis is reversed and i think the gait got a little more messy so keeping things as they were was better.I’m thinking about adding a minus sign at the BodyPosX. If right and left are actually reversed then the minus sign should fix that in the gait shift , but it wont affect the tilt mode and it wont exactly be a solution x) .
cRR=0
cRF=2
cLR=3
cLF=5
And
cRR=3
cRF=5
LR=0
cLF=2
Will run in the same order. Whether you start with LR or RR your numbers are still in a numeric order. Its not the numbers you need to change. Its the order of rotation.
The leg order should be (notice that it selects each leg going round in a circle rather than crossing fron RF to LR.)
RR=
RF=
LF=
LR=
So change your numbers to this sequence…
cRR=0
cRF=1
LR=3
cLF=2
Be careful,
There is code in place that says all of the legs 0 to N/2-1 are on one side and the legs n/2 - (n-1) are on the other side.
Kurt
this is the numbers i have at the moment:
cRR con 0
cRM con 1
cRF con 2
cLR con 3
cLM con 4
cLF con 5
If you remove the middle leg, they’re already in the sequence you mentioned