I tried this tripod gait to :
It must be the fastest one to my mind.
Itâs still a ways out. But the basics are 256 or 512k code space. 24meg ram. Runs at 50mhz. Clock for clock itâs better than 2x faster than the AtomPro so 50/16*2=6.25 times faster minimum.
Wow sounds interesting. Do you have more information? Would be great together with SSC NG. Any ETA?
No ETA, itâs very early in the development. They didnât want to let me announce it yet. I was persistent. 
There is no additional information. SorryâŚ
Itâs ok⌠someone will start a thread on this board instead of the basic micro forum and ask every couple of weeks if itâs ready yet. 
Sounds like a fun new chip. Hopefully soon!
On a different subject. I have Zentas code in and I still donât think it is working properly on my machine (CHR-3). So I started to try to debug. The first thing I noticed is what I think is my Right Front Leg does not appear to be postioned properly. For example at initial setup it looks like:
http://i416.photobucket.com/albums/pp245/Kurts_Robots/DSC03075.jpg
Note what I think is my right front leg appears to have the wrong angle. I am assuming that I have edited the default sizes/positions and the like. I think the front is toward the top as when I press the left joystick up it goes toward the top of the image. Hopefully later I will figure out what setting I have wrong. Just out of curiosity I looked at the phoenix build instructions to see if it looks like the left and right hand legs are different as they are on the CHR-3, which I pretty sure they are.
What is confussing 
me about these instructions lynxmotion.com/images/html/build131.htm is trying to figure out what is left or right. Looking at figures 12 and 13 I would think what I am calling Front Right is Front Left. However I guess everything is OK in either case we are using servos 8-10 for it RFCoxaPin con P8 ;Front Right leg Hip Horizontal
RFFemurPin con P9 ;Front Right leg Hip Vertical
RFTibiaPin con P10 ;Front Right leg Knee
It is probably just meâŚ
But back to the actual integration, I will try to see what is off about that one servoâŚ
My Body dimensions are:
[code]#else ; Kurtâs round
; 3DOF-C Leg Dimensions (TibiaAngle constant = 20)
CoxaLength con 29 ;1.14" = 29mm (1.14 * 25.4)
FemurLength con 57 ;2.25" = 57mm (2.25 * 25.4)
TibiaLength con 141 ;5.55" = 141mm (5.55 * 25.4)
CoxaAngle con 60 ;Default Coxa setup angle
RFOffsetX con -69 ;Distance X from center of the body to the Right Front coxa
RFOffsetZ con -119 ;Distance Z from center of the body to the Right Front coxa
RMOffsetX con -138 ;Distance X from center of the body to the Right Middle coxa
RMOffsetZ con 0 ;Distance Z from center of the body to the Right Middle coxa
RROffsetX con -69 ;Distance X from center of the body to the Right Rear coxa
RROffsetZ con 119 ;Distance Z from center of the body to the Right Rear coxa
LFOffsetX con 69 ;Distance X from center of the body to the Left Front coxa
LFOffsetZ con -119 ;Distance Z from center of the body to the Left Front coxa
LMOffsetX con 138 ;Distance X from center of the body to the Left Middle coxa
LMOffsetZ con 0 ;Distance Z from center of the body to the Left Middle coxa
LROffsetX con 69 ;Distance X from center of the body to the Left Rear coxa
LROffsetZ con 119 ;Distance Z from center of the body to the Left Rear coxa
#endif[/code]
My Initial position is:
[code]#else
'CHR3 - with 3DOF-C legs
'Feet Positions
RFPosX = 52 ;Start positions of the Right Front leg
RFPosY = 80
RFPosZ = -91
RMPosX = 105 ;Start positions of the Right Middle leg
RMPosY = 80
RMPosZ = 0
RRPosX = 52 ;Start positions of the Right Rear leg
RRPosY = 80
RRPosZ = 91
LFPosX = 52 ;Start positions of the Left Front leg
LFPosY = 80
LFPosZ = -91
LMPosX = 105 ;Start positions of the Left Middle leg
LMPosY = 80
LMPosZ = 0
LRPosX = 52 ;Start positions of the Left Rear leg
LRPosY = 80
LRPosZ = 91
#endif[/code]
Zenta the beginning of my Main looks like:
[code]main:
'Start time
GOSUB GetCurrentTime], lTimerStart
;Gait
GOSUB GaitSeq
;zenta stuff start
TotalTransX = 0 'reset values used for calculation of balance
TotalTransZ = 0
TotalTransY = 0
TotalXbal = 0
TotalZbal = 0
TotalYbal = 0
if BalanceMode <> 0 then
gosub BalCalcOneLeg -RFPosX+BodyPosX+RFGaitPosX, RFPosZ+BalCompZ+BodyPosZ+RFGaitPosZ,RFGaitPosY, RFOffsetX, RFOffsetZ]
gosub BalCalcOneLeg -RMPosX+BodyPosX+RMGaitPosX, RMPosZ+BalCompZ+BodyPosZ+RMGaitPosZ,RMGaitPosY, RMOffsetX, RMOffsetZ]
gosub BalCalcOneLeg -RRPosX+BodyPosX+RRGaitPosX, RRPosZ+BalCompZ+BodyPosZ+RRGaitPosZ,RRGaitPosY, RROffsetX, RROffsetZ]
gosub BalCalcOneLeg [LFPosX-BodyPosX+LFGaitPosX, LFPosZ+BalCompZ+BodyPosZ+LFGaitPosZ,LFGaitPosY, LFOffsetX, LFOffsetZ]
gosub BalCalcOneLeg [LMPosX-BodyPosX+LMGaitPosX, LMPosZ+BalCompZ+BodyPosZ+LMGaitPosZ,LMGaitPosY, LMOffsetX, LMOffsetZ]
gosub BalCalcOneLeg [LRPosX-BodyPosX+LRGaitPosX, LRPosZ+BalCompZ+BodyPosZ+LRGaitPosZ,LRGaitPosY, LROffsetX, LROffsetZ]
gosub BalanceBody
endif
;zenta stuff end
'Reset IKsolution indicators
IKSolution = False
IKSolutionWarning = False
IKSolutionError = False
;Right Front leg
GOSUB BodyIK -RFPosX+BodyPosX+RFGaitPosX, RFPosZ+BodyPosZ+RFGaitPosZ,RFPosY+BodyPosY+RFGaitPosY, RFOffsetX, RFOffsetZ, RFGaitRotY]
GOSUB LegIK [RFPosX-BodyPosX+BodyIKPosX-RFGaitPosX, RFPosY+BodyPosY-BodyIKPosY+RFGaitPosY, RFPosZ+BodyPosZ-BodyIKPosZ+RFGaitPosZ]
âŚ
[/code]
Which of the gaits would you recommend debugging this to see if the gestures is working well?
Thanks again
Kurt
Found at least part of the problem with the one leg⌠It was the servo was not centered properly any more. This hex as been torn apart several times and this servo was not aligned properly⌠Probably will wait until tomorrow to work on ballanceâŚ
Hi Kurt,
The 12 step ripple or the 9 step quadripple should work fine. Also the 6 step tripod. The balance part is also easier to see when using higher value for the leglift in swing position (LegLiftHeight)
Hi Galegu,
The same gait is in V1.2 only position 4 is right above position 2. This makes it easy to stop and start walking. 
Hi All,
There has been a lot of activity since the last time IĂ¢ââââ¢ve posted so sorry if this post is kinda messy. Just see it as a multi answering post
I included ZentaĂ¢ââââ¢s to new gaits and they are great! The 8 steps tripod is very solid and the new wave isĂ¢ââÂŹĂÂŚ letĂ¢ââââ¢s say as fast as a wave gait can getâŚ
Good work!
A new (faster) chip sounds great! I cantĂ¢âââ⢠wait to try it out but we will first try to get the terrain adaption to work on the 28 pro.
I know exactly what you are talking about. IĂ¢ââââ¢m thinking of switching to the hardware serial port to increase the speed and win some time. The only problem is that they are currently used for the PS2 remote. So I need to check if I can connect the remote to other pins. Maybe I need to add some pull registers to get it to work. But I didnĂ¢ââââ¢t checked that yetĂ¢ââÂŹĂÂŚ
I checked the manual and you are totally right. The text in figure 11 isnĂ¢ââââ¢t correct! Jim, can you switch the left and right texts? Front and back texts are correct. This should make it correct. I didnĂ¢ââââ¢t checked the rest of the tutorial so it might be in there more then onceĂ¢ââÂŹĂÂŚ
I like the Ă¢ââÂŹĂ âZenta stuffĂ¢ââÂŹ
What the heck⌠Itâll be fixed on Monday. Sorry we missed this error.
This is a video with the balance code integrated. At first I had it walking in tripod mode. Then set Balance to 1 then 2 and then back to 0âŚ
Sorry about being not a great video
i416.photobucket.com/albums/pp245/Kurts_Robots/th_ShowingbalanceNot.jpg
I donât think it is working rightâŚ
Kurt
Hi Kurt,
It sure dosenât look correct. I would also recommend using a bit slower speed while doing the balance code. But itâs hard to me to figure out whats wrong with your code. I and Xanâs spent a evening to make his PS2 version to work. I think Xan are going to share a new version pretty soon.
You could send me your code pr mail or just post the complete code here. Iâll send you a PM about my mail adr.
Hi Zenta,
I sent you the whole thing in emailâŚ
On a different subject:
My XBees arrived (although 1 of the 3 I ordered wrongly so will try to swap U.FL for Chip⌠I think the 2 carrier cards will arrive Monday. Now I need to figure out what else I need to order to make up a new DIY remote. Also may need to get a phoenix, especially since they have this sale going onâŚ
I didnât read through this whole thread so donât blast me if this has already been pointed out butâŚ
Right now it looks like you are doing your IK in floating point. Floating point is very slow(even on the AtomPro). You can get a couple thousand calcs a second with it and thats about it. If you switch to fixed point math you can get a ten fold improvment on most of your calcs.
To do fixed point you need to decide in advance how many decimal places of information you need. A LONG variable can be any value between Âą2147483647. If you want 4 places of accuracy then you split your integer variables decimal value into Âą214748.3648. You just multiply and divide by 10000 to get the integer portion. You can replace most if not all your floating point with fixed point methods and increase your calc speed by 10 fold.
Just remember three basic rules with fixed point.
-
Adding and subtracting work without modification, just + and - as ussual.
-
multiplication and division between to fixed point numbers have to be divided or multiplied before hand by the fixed point offset or you will get incorrect values and probably overflow the variable.
-
you must convert a fixed point number to itâs integer value before using in a command by dividing by the offet(eg 10000 in this example).
example. In the examples the decimal points are just fro reference. Actual code will contain no decimal points.
Normal addition:
10000 + 10000 = 20000
Fixed point addition:
10000.0000 + 10000.0000 = 20000.0000
To use in a pause command:
pause (20000.0000 / 10000)
Normal multiply
100 * 100 = 10000
Fixed point multiply
100.0000 * 100.0000 = 10000.00000000
which is too big for a long so you have to divide both sides by the square root of the offset(100) before multiplying.
100.0000/100 * 100.0000/100 = 10000.0000
Division works in reverse. Multiply both sides by 100 before oding the division
10000.0000100 / 100.0000100 = 10.0000
You may also see how using an offset of 65536(2^16 power)can make extremely fast fixed point math. All you have to do to handle the offset is left or right shift by one(divide/multiply by 256) or two(divide/multiply by 65536) bytes instead of multiply or dividing by 100 or 10000.
If you go with an offset of 65536 your range of values is approx Âą32768.0000.
For what you guys are doing 4 decimal places should be sufficient.
Just so you have some comparison it takes approx 8000 clock cycles to do a 32bit floating point multiply or divide(just a ball park). it takes about 100 cycles to do a 32bit integer multiply or divide and it would take(assuming you used assembly code) approx 12 cycles to do a byte shift of a long and 4 cycles to do a word shift of a long so you can see there is room for a huge amount of speed up just by switching to fixed point calculations.
Hi Acidtech,
YouĂ¢ââââ¢ve got a good point there! I was aware that floating point calculations cost a lot more clocks then fixed point calculations but I didnĂ¢ââââ¢t know that the difference was that much! Some time ago I started rewriting the IK to fixed point calculations but getting sin and cos didnĂ¢ââââ¢t make any sense at the time. In one of my first releases I had a todo list with this point in it!
As youĂ¢ââââ¢ve might have noticed weĂ¢ââââ¢re (Zenta and I) are working on terrain adaption and we are at a point that calculation speed is going to get a issue. After reading your post I think it is worth the time to rewriting the IK to fixed point calculations and hope that we will win the amount of speed that youĂ¢ââââ¢ve mentioned!
Thanks!
Xan
Ps. If youĂ¢ââââ¢ve got a good example with the sin and cos functions it is more than welcome
Hi Kurt,
ItĂ¢ââââ¢s more of a dance mode for you I like the way she twist her hips! 8)
Xan
Hi Zenta (and Xan)
I did a compare of my merging in of your code intot he 1.2 release. Some of the things I did see that were different is some of the variables in your code were word size and in the 1.2 code were byte sized, so I made those word sized. I am not sure yet how much that has helped or not yet. Some other differences should not matter, like I think Xans code depends on the servo zero offsets stored on the SSC-32 where you have specific ones in your code. Likewise you have a hard coded 60 degrees where Xan uses a variableâŚ
At some point soon it might be good to configure this back for a phoenix and see if maybe my offsets, angles, zero points are causing problems. The problem is I donât have oneâŚ
Kurt
Hi Kurt,
Iâve tried to figure out whats causing the balance problem in your code. Since your hexapod has much larger dimensions I think the variable BodyOffsetX as a sbyte is too small since your RMOffsetX and LMOffsetX are set to +/- 138 . Try to change it to a sword. What puzzle me is that if this variable should cause an error it would also affect normal body rotation (via the BodyIK sub).
I changed many variable to sword (especially GaitPosY) because I needed higher values when doing oneleg balance (like I demonstrated in the balance video).
I think that all variables contain the value 0 at first, but maybe just to be sure set the BalCompZ = 0 at the start.
Another thing, the #ifdef PHOENIX used at the start of your code, I couldnât find PHOENIX as a defined constant. But maybe thats not necessary?
Other than that, I canât see whats wrong with your code. Maybe its a math phenomenon caused by the circular body
I think you will see significant speed up. Thats why I mentioned fixed point. Jim pointed me to this post where you guys were talking about needing 10 times the speed.
Also if you are using floating point sin and cos you are taking a very large hit there too. Fcos and fsin use the cordic algorithm to calculate which is more cycle intensive then other methods to calculate sin and cos but had the advatage that it also handles most all trig functions which saved on code space). But IIRC you are using the int sin and cos functions and just converting to float in your code.
Just converting to float can take more then 200 clock cycels(worst case is over 284 cycles). Removing the necessity to convert to and from float should give a pretty big improvement.
The hitachi processor just doesnât have any hardware to help improve FP calculation much so itâs all done the hard way. Itâs a pretty massive hit. Of course no other module comparable to the AtomPro can do better or even come close AFAIK.
I will give it a shot!
I will double check
If you define PHOENIX then it should use the sizes, angles and the like of the phoenix hex otherwise it will use my definesâŚ
Yep it is a bigger sucker. Some time I would like to get a phoenix⌠Just trying to decide if to order it today to take advantage of the sale!
Kurt