That’s correct. 
Hi Kåre,
Thanks. So what does the 15 degrees on the other two joins do for you? I guess I need to get a graph down on paper (screen?), and study the angles.
I’m going to retire my “Creepy Crawler”, as was hinted at in its creation.
I haven’t looked at the T-Hex 4DOF software yet. And Jonny has just added some COG shifting code that I’m anxious to check out.
Alan KM6VV
Kåre is the main creditor here…
anyway here is the code as current, for you too look at:
4DofHex_V20.rar (32.1 KB)
Thanks,
For some reason, I couldn’t find the posting of the code.
I did finally search and find the main thread:
lynxmotion.net/viewtopic.php?f=20&t=5670
Which I’m re-reading. Funny, I don’t remember much of it. OK, it was some months ago. I’m starting to remember now.
Looks like the code complies with the new studio. Anyone try the old IDE? Oh well, I’ve got it loaded on a machine somewhere.
On to my studies.
Alan KM6VV
02-11-2009? Nothing newer?
Oh, 2nd Nov, 2009. That’s a little newer then 11 Feb.
Thanks,
Alan KM6VV
small details. 
the code i posted is whats running on my quad. it has the body shift and other implementations included. oh just realised that in the codes “gaitselect” you will need to remove the doubletravel var from the gait.
they should be:
[code]GaitSelect
;Gait selector
IF (GaitType = 0) THEN ;Wave 48 steps
GaitLegNr(cLF) = 28
GaitLegNr(cRR) = 40
GaitLegNr(cRF) = 3
GaitLegNr(cLR) = 16
NrLiftedPos = 3
HalfLiftHeigth = 0
TLDivFactor = 40
StepsInGait = 48
NomGaitSpeed = 100
ENDIF
IF (GaitType = 1) THEN ;Wave 24 steps
GaitLegNr(cLR) = 1
GaitLegNr(cRF) = 21
GaitLegNr(cRR) = 13
GaitLegNr(cLF) = 9
NrLiftedPos = 3
HalfLiftHeigth = 0
TLDivFactor = 20
StepsInGait = 24
NomGaitSpeed = 100
ENDIF
return[/code]
i have also implimented a Z axis shift for extra balance and control.
[code]'Walking comp tables:
; GaitLegNr(cLF) = 28
; GaitLegNr(cRR) = 40
; GaitLegNr(cRF) = 3
; GaitLegNr(cLR) = 16
; (RF) (LR)
’ 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, 25,
X_Axis_Shift bytetable 88, 89, 90, 91, 95,100,110,115,120,128,135,145,150,155,158,158,158,159,160,161,162,163,163,162,161,160,|
159,158,158,158,155,150,145,135,128,120,115,110,100, 95, 91, 90, 89, 88, 87, 86, 85, 86, 87,
; 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
; (LF) (RR)
; (RF) (LR)
’ 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, 25,
Z_Axis_Shift bytetable 128,128,128,128,128,128,128,129,130,131,133,135,137,139,140,142,140,139,137,135,133,131,130,128,128,128,|
128,128,128,128,128,128,129,130,131,133,135,137,139,140,142,140,139,137,135,133,131,130,128,
; 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
; (LF) (RR) [/code]
its a very slight, but precise movement. i may need to make the values slightly bigger but looks ok on a simulated test.
you will notice it only moves away from the rear lifted legs and not the front to keep the body moving forward.
But when, when will we notice this effect…?
If only he had posted a video… 
half way down this page.
viewtopic.php?f=8&t=6521&start=15
this only shows the X shift. since the vid i have got it to only “shift” when gait in motion. 
next vid will show Z shift as well.
Hi Jonny,
Sorry for my impatience! I think I got my links crossed, and was possibly looking at Jeroen & Kåre’s T-Hex code (which is for a hex).
I am looking at a 'quad implementation now, and I see your Gait and Comp tables.
Thanks again!
I’m really looking forward to seeing this old cat that has been setting on my bench (for inspiration) do some walking!
Alan KM6VV
look forward to seeing it. after years of trying to get a quadruped walking iv managed to get two working in one year. its a shame i wasnt using bytetables for body shifting when i was working on the quadruped stalker. along with a few other important informative areas would be to get the tilted coxa calculations working. anyways im finding that im making small improvements to the code as i go so maybe one day the stalker will return!
i have found that even using a 24 step wave gait with the X-Axis table (48) is still slow and juddery. you may not be able to see the judder in the next video, (when i post it) but its there.
im still looking for a way to make it smoother.
also one other thing i have noticed is that the GaitStep “update” is slow. what i mean by this is the legs take longer to re-position to their InitPos, once TravelLength is 0!.. would changing SSCtime help speed things up?
I know the feeling. I’ve had this cat on my desk for over a year…
the byte tables are a good idea, as is the body shifting.
Yeah! I really want to see the stalker return!
I’ll have to study the motion (video) before I can comment much. Be sure to use adequate lighting, it will help in the detail.
The GaitStep probably has to “run out” a sequence, and return to a “neutral” postion, no?
I think the SSC time has to reflect the overall time that is being used to complete a gait cycle. (from memory). So you probably have to wait either for the SSC-32 to tell you it’s done, or observe the timeout. (I think).
Alan KM6VV
Great Work!!!
From your comments it sounds like the cycle through the sequence with lots of steps is too slow. So I wonder how are you controlling the SSC-32?
I believe that Zenta was able to speed up the T-Hex sequences by incorporating several things. I wonder if these would help out in this case as well.
- Use the beta version of the SSC-32 firmware that supports binary mode input. If I remember correctly this may have cut the number of bytes being sent in half.
- Use my assembly language serial output functions, that allowed him to output at the baud rate of 115200 instead of 38400 (1/3 the time)
- More accurate timing of when to commit the next step of the sequence. That is we download the complete next step and wait for our timeout to happen and then only output the commit step.
- Speed up the input processing… This was for the XBEE stuff not sure of the timings for PS2 stuff…
Again not sure if this all applies or not, but if you have not already tried them, it might be worth a shot.
Kurt
hi kurt,
Im currently using the 2.04GP Beta firmware
yes iv not tried it at 115200 yet. apart from adding the other jumper and changing it to 115200 in the code is there anything else id need to do?
(assembly language serial output functions)?
its the same code that zenta used so i wouldnt have thought it would need to be changed.
Although…
…
it may well be the input as i know zenta is using your DIY remote and iv noticed it flows better with it. the ps2 is a little jumpy too and not very precise.
thanks kurt.
I know come on i wanna see it.
yeah well i think i will do more testing at some point on the tilted coxa design before committing to the build.
yeah, unfortunatly my camera is very poor for video. ill try my best.
in fact i have already tested the new code and it work fine. weather here is dull and the lights in my house are quite bright but the camera cant pick it up still.
yeah once i have ran some test and scratched my head i will make a new vid.
Hay Jonny,
Did you just go PINK?
In time. New legs will go on “creepy”, till I see how she walks.
You might have a horrendous amount of COG shift to accommodate.
Yeah, I didn’t mean to make that sound like a criticism. I know my recent video was a little dark. Ok, I just called it “effects” for Creepy.
Looking forward to it!
Best regards,
Alan KM6VV
no worries. yeah i maybe able to borrow one. it seems many of use have poor cameras. ill try and get a good one soon. ill make a few more vids with this one and ill try and convert them better. i know the quality is better before conversion. 
Ps, yeah PINK, might have to change that some how!?
Video is funny. I know still photography. Takes more light, and the area to focus on often changes, which creates other problems.
I bought a new camera over a year ago, haven’t really shot much (but it was a good time for the purchase, business-wise). You really need an assistant with video.
Had one of my wife’s cats interested in the MicroMoose last night, took a few pix with her iPhone 4. Nothing great, but wife loves pix of her babies! I forgot all about the video capabilities of the 'phone. But I wasn’t impressed with the tiny on-camera flash as it was.
Yeah, Pink. We must be something special! Don’t tell my wife.
Alan KM6VV
LOL… 
Yes, the serout functions did not work reliably at 115200, so there is a version of the code that I gave to zenta that used my Timer Assisted Serout function which did… But my functions only take a pointer to a buffer and a size, so I had to change the calling code to handle this…
You can tell this if the code was changed from simply calling: gosub ServoDriver
to a couple of calls: gosub ServoDriverStart and later when we are at the appropriate time ServoDriverCommit.
Yep, the PS2 is usually not overly precise or sensitive. That is many times I will find out that the joysticks may only give me something like 5 or so real values in the 128 value range. (Example may jump from 128 to 140…) So you may never get as fine of control as Zenta has with the DIY…
However simple walking where for example you move the joystick most the way up to start walking foreword. I am not sure how important it is if the values change that much (I could be wrong ::shock:)
But what may be more important is how fast and time accurate you can make each pass through the PS2 input, gait, and Servo Driver. That is for example if you wish to double the number of steps in a sequence, but you wish for the sequence to complete in the same amount of time, then you need each new step to take half the time… Obviously there is a limit of how fast you can do each cycle. The question is, are you running into this limit with the current code. That is what all of this is trying to improve. There are also more tricks that can be tried. That is if for example you decide that some of your steps need to happen real quick, than maybe the code could be arranged to detect this and in that case not call of to the controller code, but assume the same input as before…
Some of the earlier code I did for the SSC in binary mode is up on the thread: viewtopic.php?t=5962&p=60028#p60028
My later code I believe I sent to Zenta the servo driver looked something like:
[code]ServoDriverStart:
; Kurt was here
;Kurt was here
#ifdef cXBEE_RTS
gosub XbeeRTSAllowInput[0] ; no - bugbug - should abstract this away …
; also chance that there could be a couple of characters that are received after this
; so maybe should pause 1 to allow this to happen…
#endif
fSSCPinChange = 0 ; initialize to say no pins have changed
; Defer any timer overflow interrupts as we only interrupt 30+ times per second. so
; we should not lose any during the time it takes to output the SSC command.
disable TIMERAINT ;disable timer interrupt
;Update Right Legs
for LegIndex = 0 to 2
gosub ServoOutputPin[cCoxaPin(LegIndex) ,(-CoxaAngle1(LegIndex) +900)*1000/1059+cCoxaOffset(LegIndex)]
gosub ServoOutputPin[cFemurPin(LegIndex),(-FemurAngle1(LegIndex)+900)*1000/1059+cFemurOffset(LegIndex)]
gosub ServoOutputPin[cTibiaPin(LegIndex),(-TibiaAngle1(LegIndex)+900)*1000/1059+cTibiaOffset(LegIndex)]
next
; Give small window of time to handle timer overflow…
enable TIMERAINT ;enable timer interrupt
disable TIMERAINT ;disable timer interrupt
;Update Left Legs
for LegIndex = 3 to 5
gosub ServoOutputPin[cCoxaPin(LegIndex) ,(CoxaAngle1(LegIndex) +900)*1000/1059+cCoxaOffset(LegIndex)]
gosub ServoOutputPin[cFemurPin(LegIndex),(FemurAngle1(LegIndex)+900)*1000/1059+cFemurOffset(LegIndex)]
gosub ServoOutputPin[cTibiaPin(LegIndex),(TibiaAngle1(LegIndex)+900)*1000/1059+cTibiaOffset(LegIndex)]
next
enable TIMERAINT ;enable timer interrupt
return
ServoDriverCommit:
disable TIMERAINT ;disable timer interrupt
;Send
if fSSCPinChange then ; at least one pin changed
gosub ServoOutputTime[SSCTime]
endif
#ifdef cXBEE_RTS
gosub XbeeRTSAllowInput[1] ; yes - bugbug - should abstract this away …
#endif
enable TIMERAINT ;enable timer interrupt
PrevSSCTime = SSCTime
return
[/code]
Sorry if I am confusing things.
Kurt