/sigh
I have had the best luck playing around with the Initial position…
#define cHexInitXZ 80
#define CHexInitXZCos60 40 // COS(60) = .5
#define CHexInitXZSin60 69 // sin(60) = .866
#define CHexInitY 80 //30
This is what I am using on CHR-3…
Kurt
As I mentioned, I was using an CHR-3
If you are using an AHR… Then the leg information needs to be updated: My guess is that:
#define cXXCoxaLength 29 // This is for CH3-R with Type 3 legs
#define cXXFemurLength 57
#define cXXTibiaLength 141
#define cXXTarsLength 85 // 4DOF only...
Should go to:
#define cXXCoxaLength 38// This is for AH3-R with Type 1 legs
#define cXXFemurLength 57
#define cXXTibiaLength 124
#define cXXTarsLength 85 // 4DOF only...
I grabbed these values from Powerpod…
As for the initial position, You will need to experiment with the values of the variables I mentioned late yesterday. I did this with the CHR. I got the X/Z values to something that looked like it worked good. Then I adjusted the Y until the body was on the ground and the legs were just touching…
Kurt
Alright Just to make sure i’m playing with these values for the initial legs positions?
[code]//[START POSITIONS FEET]
#define cHexInitXZ 80
#define CHexInitXZCos60 40 // COS(60) = .5
#define CHexInitXZSin60 69 // sin(60) = .866
#define CHexInitY 80 //30
#define cRRInitPosX CHexInitXZCos60 //Start positions of the Right Rear leg
#define cRRInitPosY CHexInitY
#define cRRInitPosZ CHexInitXZSin60
#define cRMInitPosX cHexInitXZ //Start positions of the Right Middle leg
#define cRMInitPosY CHexInitY
#define cRMInitPosZ 0
#define cRFInitPosX CHexInitXZCos60 //Start positions of the Right Front leg
#define cRFInitPosY CHexInitY
#define cRFInitPosZ -CHexInitXZSin60
#define cLRInitPosX CHexInitXZCos60 //Start positions of the Left Rear leg
#define cLRInitPosY CHexInitY
#define cLRInitPosZ CHexInitXZSin60
#define cLMInitPosX cHexInitXZ //Start positions of the Left Middle leg
#define cLMInitPosY CHexInitY
#define cLMInitPosZ 0
#define cLFInitPosX CHexInitXZCos60 //Start positions of the Left Front leg
#define cLFInitPosY CHexInitY
#define cLFInitPosZ -CHexInitXZSin60[/code]
Can you give me a clue as to what the first four values mean? I’ve only ever worked with 2D ik…
The First number 80, is a guess on how far out we want each of the legs… I had to play around with different robots to get different values that work. The values (CHexInitXZCos60, and CHexInitXZSin60 are simply the Sin and Cos of 60 degrees times the first value (CHexInitXZCos60). The CHexInitY value is how far up we should init. Again done by experiments… Note: These values are more or less the same as the BAP28 type setup…
[code]cHexInitXZ con 105 ; was 105
CHexInitY con 80
cRRInitPosX con (cHexInitXZ * 0.5 + 0.5) ;Start positions of the Right Rear leg
cRRInitPosY con cHexInitY
cRRInitPosZ con (cHexInitXZ * 0.866 + 0.5)
cRMInitPosX con cHexInitXZ ;Start positions of the Right Middle leg
cRMInitPosY con cHexInitY
cRMInitPosZ con 0[/code]
But I simply did the Mult by .5 and .866 up in constants above…
The initial position isn’t what is causing the crash. The ground position is the problem. When you first press start to turn on the bot the g_BodyYOffset is set to 0 i believe. I Think this is what’s causing the crash. This should be the case with your CH3-R as well…
I’ve attached the code that we’ve made changes to.
Things I changed:
at the top:
line 223:
word SpeedControl = 100; //Adjustible Delay
in setup():
line 358:
GaitType = 1;
ps2Controller.cpp
line 243:
g_BodyYOffset = 65;
These changes simply make the AH3-R Walk more elegantly by default.
Here’s a video (It’s unlisted) of the crashes and bugs we’ve found.
BotBoardDuino_CHR3_PS2-120410a.zip (28.8 KB)
Sounds good, I will try it out on mine sometime… currently my CHR-3 is set up with Arduino Mega and No SSC-32… Will also look into it on my 4DOF version which I now have the Botboarduino on…
Hint: it would be nice if all of these changes were put into a Source Control System, like Source Forge or GitHub… That way we could all be able to see what changes in builds and automatically merge…
Kurt
Hi guys,
Jim asked me to jump in. So here I am, hope to be of some help. By now Kurt is already a super master in the Phoenix code. I doubt I can add much new stuff for him but who knows I might squeeze out something new! 
Configuring the software for another bot sometimes seems try and error but there actually is some logic/math behind it. I think most of the stuff is already known but I’ll start at the beginning.
I don’t have the code with me right now so I need to do this from my memory…
NOTE: The global coordinate frame is an 3D frame. The hexapod is located in such a way that: X is sideways (left, right), Y is vertical (up, down), Z is (forward, backward). This need to be kept in mind at all times
-
Body Lengths
Fill in the correct lengths for the body and joints. All length are measured from joint to joint. Or as for the tibia, from joint to the tip (tars). For the body the lengths are measured from the centre of the body (0,0,0) to the joints. The best way to measure this is to stretch the leg totally horizontal. Then measure the lengths by keeping the measurement tool horizontal as well. This is important for the length of the coxa. The length of the coxa is measured from the hub of the servo to the heart of the other servo. Not from hub to hub since this is a diagonal length. We only want the horizontal lengths. -
Init positions
The init position has 3 variables for each leg. InitPosY refer to the vertical offset between the body and the tip (tars) of the leg. If set to zero the tars should be in the middle of the body. This value should be set to let the tars rest on the ground when the hex is in the init position.
The initPosX and initPosZ refer horizontal offset between the tars and the body. X is for sideways, Z is for forward/backward. For the middle 2 legs you only need to fill in the X since the leg only needs an offset to the left and right, not to the front.
Now this is the point where the math kicks in. For a round hexapod we want the front and back angles to start at an angle of 60 deg. But we want to have the distance from the body the same as with the middle legs. So you need to use the Pythagorean theorem to take the distance from the middle leg, and transfer it to an X and Z value with the 60 deg angle.
The best way to find a good init position is to place the hex on a flat surface. Manually set the legs to the ideal init position and measure the distance from the coxa horn to the tars. Remember to only measure the horizontal length. This is your offset for the middle leg. Then calc your way to the front and back legs. The Y value is always a bit of try and error, you can measure the distance from the horn of the femur servo to the ground. Theoretical you should enter that value. But with the play in the servos and gravity pulling down on them you need to adjust it a bit. -
Min/max angles
The code also contains some min and max angles for each servo. These limits are low level which mean that they only prevent the servos from running into mechanical limits and cause them to overload. The min/max angles don’t feed back any information on the IK math so overstretching will result in a strange walking bot. But that is always better than an overloaded bot
It works like this, if your servo can only go to 42 deg because it will hit a bracket once it goes any further you can set the limit to 42 deg. Once the math sends the servo to 45 deg, the angle will be limited to 43 deg and send to it’s max angle.
The way I did this is to connect the SSC to lynxTerm and check out the min and max PWM’s of each servo. I wrote them down and used excel to fast calculate the corresponding angle. Placed those values in the config file. Done -
Travel distance/speed
There are 2 variables who take care of the speed of the bot. If a bot has shorter or longer legs those values should also be checked. In my explanation about how the gaits work I used a triangle to track the motion of the tars. Having the triangle in mind, the TravelDistance is the maximum distance (in mm) the leg moves over the ground (horizontal line). I’m not sure of this but as I remember it correctly it actually is from the center of the horizontal line to the front. So the horizontal line will be TravelDistance*2. If the bot has shorter legs, this value should be reduced to prevent over stretching
The travel speed is the time it takes to do one step (going from 1 to 2 in the triangle)
That’s about it. Let me know if you’ve got any questions.
We should make a tutorial for this…
PS. I totally second you Kurt, globals are horrible! Since the Arduino does support classes with there own scoped variables it is way better!
Xan
Great input Xan!
I believe many people would finding this information useful!
Good to see you around too 
A side note: I just wanted to shoot in that the (now rather old) excel program PEP is also a very useful tool for testing out init positions. You can use the X,Z,Y values from the leg sections in the body&coxa sheet.
Thanks Xan,
For the most part I was trying to not have to worry about it too much 
That is, if it worked on the BAP and I ported the code properly, it should work on the Arduino with the same, lengths, angles, inits… But sometimes I find that when I tried to merge in some of the changes from the 2.1 changes on the BAP, I may have missed a few…
Some of the hidden gotchas of porting the code includes, all math on the BAP28 is done using 32 bit math, whereas with C on the Arduino, the number of bits involved with the math depends on the size of the variables/constants involved. For example if you are adding one byte to another, the code will generate 8 bit math instructions… That is why there are lots of castings in the code, to tell the system to up-size…
Earlier on I had instrumented versions of both the BAP and Arc32 and Arduino code and would run restricted input and check the outputs of different functions to verify the code… Stripped most of that out.
Probably need to put the BotBoarduino back on the reclaimed CHR-3, to check out the changes that were Devon’s changes and to follow along with other issues. My problem is that too many fun projects to do… My version .02 of the Atmega644 boards arrive tomorrow. So will be busy soldering.
Kurt
I put in the changes you did, although they are just simply startup changes. Like instead of starting off with legs such that body is resting on ground, you have the body up a ways…
I could not tell from your video where the crsahes were… Here is an updated version. Note: This has some changes in it to factor stuff…
Kurt
BotBoardDuino_CHR3_PS2-120520a.zip (29.1 KB)
Alright. Saying I know anything about git hub is a huge lie; However, I just set one up correctly… I think… Have a look and let me know if i messed anything up or if i need to do anything.
Dito - to say I know anything about Git hub would be a lie… I have only used (abused) it enough to post a couple of fixes for the PS2 code… That is also true about my knowledge of the other locations like: SourceForge and Google code… I will have to get back up there and see if I can recreate the steps to enlist… Probably someone needs to go through their helper guides and come up with a quick and dirty cheat sheet to say, to enlist do: X, to fork do Y, to push in changes, do…
Thanks
Kurt
Guys,
Totally correct! The PEP can also be very usefull finding good values for the init position. I used the PEP to find good init positions for the T-Hex
Just a note: As you know a 32-bits processor processes it’s instructions with the full 32 bits. Converting variables to 32-bits will add some additional steps and always slows down the calculations. If you have enough memory free to store your variables, it is always better to make your variables match the amount of bits used in the CPU instruction set. But this is easy talking for me, as I develop programs for big massive servers on a daily basis
Xan
We’re making an announcement on the forum about the github page. We’re hoping that some more knowledgeable users can help us out with this project.
Saw it… Thanks.
One issue so far, is that Arduino wants the main sketch file (xxx.ino) to have the same name as the directory it is contained in. So far example when I open the BotBoardDuino_CHR3_PS2.ino file in the BotBoarduino directory it will complain that the file is not correct and would you like it to create a folder…
Kurt
Hi,
Are you still having the bugs you posted in the video or does it perform ok now?
Yes, while in translate or rotate mode the bot crashes when you increase the body y offset to the max.
I have not see the crash on my CHR-3, but maybe I am not doing what you are doing to reproduce this. Or maybe this is because of the mechanical limits of the CHR-3 that the it can not go up any higher as the tibia parts run into the C-Bracket. Might be different if I used Tall c brackets, but I didn’t…
What we may need is for you to instrument the PS2 code or the like to see what inputs are causing it to crash…
Like maybe right at the end of the PS2 input like where the code is:
//Calculate g_InControlState.BodyPos.y
g_InControlState.BodyPos.y = max(g_BodyYOffset + g_BodyYShift, 0);
Maybe print out some variables… like:
The g_InControlState.BodyPos.x and g_InControlState.BodyPos.y and g_InControlState.BodyPos.z, g_InControlState.BodyRot1.y, maybe also (g_BodyYShift, g_BodyYOffset). Could put this in conditionally and with the ability to turn on and off…
#ifdef DEBUG
if (g_fDebugOutput) {
Serial.print(...)
}
#endif
If you go that route and you have the serial connection, then hit D at debug terminal to turn debug on or off…
If it is only at the extreme values we should probably update the code, that looks like:
[code] if (ps2x.ButtonPressed(PSB_PAD_UP))// D-Up - Button Test
g_BodyYOffset += 10;
if (ps2x.ButtonPressed(PSB_PAD_DOWN))// D-Down - Button Test
g_BodyYOffset -= 10;
[/code]
And maybe add some defines in the …CFG…H file that says something like:
#define MAXBODYYOFFSET xxx ;
And then update the above code to make sure we don’t exceed that maximum… Maybe need for minimum as well???
Kurt