The Mechanical Limits for the front Left Femur are reversed… they read
cLFFemurMin1 con -550
cLFFemurMax1 con 900
Where they should be like all the other Femurs
cLFFemurMin1 con -900
cLFFemurMax1 con 550
…but yeah, we’ve fixed it.
A quick update on running the phoenix code on CHR-3 robots. I have read and seen reports of some issues running the code on the CHR-3 especially with things like the body rotate. (In fact I think Nathan mentioned this as well in his porting to Arc-32). Since I never had a phoenix (until now) I was not sure what it was supposed to look like 
I am now sure there is a problem here. if using the XBEE interface and move the Right joystick Left/Right some of the legs are no longer hitting the ground…
On the Phoenix it looks like:
On the CHR-3 it looks like:
Note the leg on the left is off the ground…
When the joystick is moved LR it is setting BodyRotY1. I have tried updating a few variables from sword to slong, without it helping.
Will look into it more. Xan or Zenta suggestions?
Kurt.
P.S. - Please disregard all of the wires hanging out. Many of these are for me to hook up logic analyzer… Still trying to figure out PS2 on Arc32…
Hi Kurt,
I can’t say I’ve experienced the same problem on any of my three hexapods (Phoenix, T-Hex or A-Pod). They have all very different body shape though. I’m a bit unsure if you mean Z or Y-rotate since you mention Right joystick L/R (Z-rotate in Rotate Mode) and BodyRotY1 (Normaly controlled with the left joystick). Anyway, all feet should stay fixed to ground when doing all kind of body rotations (X,Y,Z). The only thing I can come up with is that calibrations and correct configuration (body shape, initpos, leg length…) are very very very important.
Hi guys,
Sorry for beeing “off” for so long…
I might have an idea why this is happening. The body of the CH3 is a bit bigger. Because of this the BAP needs to calc with bigger numbers. It can be possible that one of the numbers overflows. You can see this by rotating very slowly. The leg will move correct and if you move a bit further it will suddenly jump in the air. This is when the overflow occures. I’ve seen this when I used the same code on the AL5D arm. It can be debugged by writing the numbers for the “jumpy” leg to the PC and see what value overflows.
I hope it helps
Xan
Thanks Xan, That was my first guess as well. So I tried changing all SBytes to SWord and SWORD to SLONG…
And no difference.
So I then started tracing differences between Phoenix and CHR-3. The debug outputs only happen when BodyRotZ1 is not zero and not equal to the last one as to minimize looking through the stuff.
Here is a sample when the value for BodyRotZ1 is -54 on CHR-3
B IK -254 0 -52 91 164 0 0 57 0 67 == L IK 97 112 8685 14816! 53193856 3149 12566! -202 -317 -43 SWE: 100
B IK -254 0 -105 0 164 0 1 70 0 10 == L IK 154 146 7700 21220! 283968400 11739 0! 0 459 900 SWE: 101
B IK -254 0 -52 -91 164 0 2 57 0 67 == L IK 97 112 8685 14816! 53193856 3149 12566! 202 -317 -43 SWE: 101
B IK -254 0 52 91 164 0 3 81 0 -35 == L IK 199 66 3203 20965! 273211225 11431 0! 473 717 900 SWE: 101
B IK -254 0 105 0 164 0 4 68 0 21 == L IK 143 8 554 14322! 38799684 2376 13305! 0 106 -92 SWE: 101
B IK -254 0 52 -91 164 0 5 81 0 -35 == L IK 199 66 3203 20965! 273211225 11431 0! -473 717 900 SWE: 101
IKS W/E0 1
and likewise on phoenix:
B IK -254 0 -53 91 104 0 0 34 0 50 == L IK 54 96 10595 11014! 66708196 3984 11642! == L IK -135 -374 -173 SWE: 100
B IK -254 0 -105 0 104 0 1 27 0 81 == L IK 23 103 13552 10553! 56765809 3539 12135! == L IK 0 -572 -212 SWE: 100
B IK -254 0 -53 -91 104 0 2 34 0 50 == L IK 54 96 10595 11014! 66708196 3984 11642! == L IK 135 -374 -173 SWE: 100
B IK -254 0 53 91 104 0 3 53 0 -30 == L IK 134 62 4312 14764! 163375696 7280 7576! == L IK 300 219 169 SWE: 100
B IK -254 0 105 0 104 0 4 60 0 -60 == L IK 164 16 985 16477! 216891529 8660 5359! == L IK 0 537 384 SWE: 110
B IK -254 0 53 -91 104 0 5 53 0 -30 == L IK 134 62 4312 14764! 163375696 7280 7576! == L IK -300 219 169 SWE: 110
IKS W/E1 0
I will describe more in a second, but the end of each line is in the LegIK and shows Solved/Warning/Error. As you can see on the CHR-3 I get into an error condition starting on the 2nd leg.
I will describe the data in the reverse of what I discovered. If you look at the parts of the line between !'s that is from this code in LegIK:
;IKA2 - Angle of the line S>W with respect to the femur in radians
Temp1 = (((cFemurLength*cFemurLength) - (cTibiaLength*cTibiaLength))*c4DEC + (IKSW2*IKSW2))
Temp2 = ((2*cFemurlength)*c2DEC * IKSW2)
GOSUB GetArcCos [Temp1 / (Temp2/c4DEC) ], IKA24
#ifdef DEBUG_ROT
if fDebugRotDisp then
hserout"! ", sdec Temp1, " ",sdec Temp1 / (Temp2/c4DEC), " ", |
sdec IKA24, "!"]
endif
#endif From this you will see we are passing a value: 11739 to GetArcCos, which exceeds it’s maximum value and returns 0…
I used a calculator to verify the Temp1 and the computed value that was passed in. The values after this on each line were the computed angles and as I mentioned above the computation state.
The beginning of each line is the stuff that was computed in BodyIK. Debug code at the end of that function:
#ifdef DEBUG_ROT
if fDebugRotDisp then
hserout "B IK ", sdec BodyRotZ1, " ", sdec TotalZBal1, " ", sdec PosX, " ", sdec PosZ, " ", sdec posY, " ", |
sdec RotationY, " ", sdec bodyIKLeg, " ", |
sdec bodyIKPosX, " ", sdec bodyikposz, " ", sdec bodyikposy]
endif
#endif
On the CHR-3 the dimensions are:
;[BODY DIMENSIONS]
cCoxaLength con 29 ;1.14" = 29mm (1.14 * 25.4)
cFemurLength con 57 ;2.25" = 57mm (2.25 * 25.4)
cTibiaLength con 141 ;5.55" = 141mm (5.55 * 25.4)
I am still trying to figure this out, but it appears like the calculation with Temp1/Temp2 are maxing out.
Ideas?
Kurt
Hi Kurt,
Did you also debug the IKSW2 ? It sounds like this variable exceed the constant femur+tibia length (19800). The next question is why and why it only happends when doing the Z-rotate and not translations 
. I’ll see if I can duplicate this error too by using the CH3-R config on my phoenix this evening.
Those bugs are always the worst. I always debug this by focusing only on the “buggy” leg and debug every output value in the Leg IK function. I always have Zenta’s PEP as reference to see where the values get out of sync.
Sorry I don’t have my pc in to my new home so I’m not much help right now…
I’ll receive my internet connection on 14th of april. I make sure I’ve got my pc up and ready by then 
Xan
Thanks guys, hopefully we will figure it out. It is more fun to play with the phoenix, but I know that I have seen other reports of this (including Nathan when porting to Arc32), so I thought that since I have both configurations it would be a good time to investigate…
Yep that sounds like a reasonable plan. I may also see if I can extract the code and run it under the debugger. In the case I captured above, actually there are three bad legs.
Three more weeks 
I will take a look, thanks for the tip.
Kurt
I forgot to mention in the post that I had the data. That Just before the ! output I am outputing this information:
GOSUB GetATan2 [IKFeetPosY, IKFeetPosXZ-cCoxaLength], IKA14
;IKSW2 - Length between femur axis and tars
IKSW2 = XYhyp2
#ifdef DEBUG_ROT
if fDebugRotDisp then
serout s_out,i9600, " == L IK ", sdec IKFeetPosY, " ",sdec IKFeetPosXZ-cCoxaLength, " ", |
sdec IKA14, " ", sdec XYhyp2]
endif
#endif
So the last field before the ! is IKSW2, which you can see in the first one that errors out: 21220
Likewise for the other two that error out! Now to figure out why
Another thought on this one, looking at the two robots next to each other, I think I can pull in the CHR-3 initial positions such that they are slightly closer in to the body. It looks like the phoenix is more that way. I am not sure how much I will be able to get, but I will try a little…
Kurt
Ok, I just tried the numbers in PEP and the IKSW2 calc is correct. But looking at the inputs makes it logic why we get an IK error. IKFeetposY = 154 and IKFeetPosXZ = 175 is way over the physical limits. The IKA14 are also correct. This mean that the IK are working ok. The inputs are comming from BodyIK sub, so thats where we have to look.
I’ve to go (making dinner… 
).
Yes that can help a little, since the relative short femur make it easier to exceed the limits when doing body rotations. And the matrix calculations doesn’t pay attention to physical limits.
Now that I am thinking about it, I don’t think this is ever going to work well here, that is this rotation will never work well in this axis. 
If I understand this. In the worst case I am passing in an angle of 25.4 degrees. And with such a wide body at this point, the TotalZ will be something like 295, which when you take this and try to move it by that many degrees will move the leg up or down by a very large value, which will easily exceed the leg limits. I am understanding this correctly???
Thanks
Kurt
P.S. - Not sure what to do here, other than how hard would it be to limit the rotate degrees to something that is doable. Also how hard would it be to have it when it does error, at least have the leg in error point in the right direction…
Hey stranger!
Glad to hear you are moving in! Hope you get back on the matrix soon! Take care. 
Yes I think you got it, I did a test on PEP starting with the legs (all joints) in the 0 deg positions. And you’ll get an IK error on the middle legs when Z-rotate exceed 16,2 degrees. Doing the same test on Phoenix ends up with an angle of about 33,8 deg.
Beside using some max/min limits in the BodyIK or limit the BodyRotZ in the Control file I’m not sure at the moment.
Don’t ignore the possibility that it could be a Basic bug also…
Alan KM6VV
Hi Kurt,
Do I understand you correctly that you got this error when BodyRotZ = +/- 54 (=5,4 deg) ??
I tried running the CH3-R config on my Phoenix but that was simply impossible to get something useful from at all. At the moment I can’t see anything wrong since PEP seem to perform ok.
Actually it was 254 or 25.4(or in your case 25,4) degrees. I know it also error earlier, but that is why the joystick full right…
Kurt
Follow up on my last post. I actually start seeing things go bad real quick. It is obviously bad when I go out to the extreams, but it starts to go semi-bad early on. I am talking about 6 or 7 degrees… When I go toward the right the one leg in line starts to raise, but so do the other two legs that are part of the logical tripod of legs. If I go the other direction the other tripod of legs start to lift. Not sure if that makes sense.
A Trace of the data like before at around 7 degrees:
B IK -74 0 -53 91 90 0 0 9 0 15 == L IK 75 81 8254 11039! 4250506817 4294963763 19281! -43 -677 -427 SWE: 100
B IK -74 0 -105 0 90 0 1 11 0 0 == L IK 90 87 7700 12517! 4285322585 4294966621 16324! 0 -476 -272 SWE: 100
B IK -74 0 -53 -91 90 0 2 9 0 15 == L IK 75 81 8254 11039! 4250506817 4294963763 19281! 43 -677 -427 SWE: 100
B IK -74 0 53 91 90 0 3 12 0 -14 == L IK 104 70 5913 12536! 4285798592 4294966655 16324! 56 -374 -272 SWE: 100
B IK -74 0 105 0 90 0 4 10 0 2 == L IK 88 66 6468 11000! 4249647296 4294963682 19343! 0 -579 -427 SWE: 100
B IK -74 0 53 -91 90 0 5 12 0 -14 == L IK 104 70 5913 12536! 4285798592 4294966655 16324! -56 -374 -272 SWE: 100
IKS W/E0 0
None of the results show any errors or warnings. For comarison here is from Phoenix:
B IK -74 0 -53 91 35 0 0 3 0 12 == L IK 23 77 12812 8036! 9977296 816 14907! == L IK -15 -688 -403 SWE: 100
B IK -74 0 -105 0 35 0 1 2 0 20 == L IK 15 78 13860 7942! 8475364 702 15092! == L IK 0 -759 -417 SWE: 100
B IK -74 0 -53 -91 35 0 2 3 0 12 == L IK 23 77 12812 8036! 9977296 816 14907! == L IK 15 -688 -403 SWE: 100
B IK -74 0 53 91 35 0 3 5 0 -11 == L IK 46 73 10102 8628! 19842384 1513 14229! == L IK 21 -494 -364 SWE: 100
B IK -74 0 105 0 35 0 4 5 0 -20 == L IK 55 71 9178 8981! 26058361 1908 13798! == L IK 0 -416 -336 SWE: 100
B IK -74 0 53 -91 35 0 5 5 0 -11 == L IK 46 73 10102 8628! 19842384 1513 14229! == L IK -21 -494 -364 SWE: 100
What is noticable here is that for three of the legs here the CHR-3 went negative first thing after ! so maybe some overflow…
OOps 
- Actually the first value is Temp1, which is unsigned. Updated to dec instead of sdec to output. Updated the values above…
Kurt