[code];[BODY DIMENSIONS]
CoxaLength con 27 ;Length of the Coxa [mm]
FemurLength con 91 ;Length of the Femur [mm]
TibiaLength con 120 ;Lenght of the Tibia [mm]
CoxaAngle con 60 ;Default Coxa setup angle
RFOffsetX con -68 ;Distance X from center of the body to the Right Front coxa
RFOffsetZ con -118 ;Distance Z from center of the body to the Right Front coxa
RMOffsetX con -137 ;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 -68 ;Distance X from center of the body to the Right Rear coxa
RROffsetZ con 118 ;Distance Z from center of the body to the Right Rear coxa
LFOffsetX con 68 ;Distance X from center of the body to the Left Front coxa
LFOffsetZ con -118 ;Distance Z from center of the body to the Left Front coxa
LMOffsetX con 137 ;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 68 ;Distance X from center of the body to the Left Rear coxa
LROffsetZ con 118 ;Distance Z from center of the body to the Left Rear coxa[/code]
Am I doing something wrong? It just flops around on the ground like a drunk!
I know Kurt worked with this too. Change the BodyOffsetX variable to sword. I think there was something more to, can’t remember. You’ll have to search/browse this forum to find it.
Yes, I did have to make some changes like this. Core2 I sent you a PM with the last source code I had working on my HEX which is a CHR-3. It is a modified version of Xan’s 1.2 code with Zenta’s code merged in. If I remember correctly was using the select button to choose which gait and the X button to turn ballance into a couple of different states…
I must have something fundamentally wrong and I fail to see it. Even after loading Kurte’s program things don’t work like they should. I’m using a wired PS2 controller for the time being.
Its as if the legs aren’t being lifted up high enough for them to be repositioned because they just seem to wiggle in place and the bot goes nowhere.
I’m about ready to assemble my Phoenix and scrap this one; but I’d like to get this one working as I have plans for it once I can make it walk.
For all practical purposes, yes, they do the same thing. I don’t think the servo’s (HS-475HB) are the problem because the bot worked/walked just fine with the PowerPod last time I used it.
As far as I know the only thing that needs to be changed are the dimension and pin connections. I thought you only included balance mode in your code like I did later on.
Kurt, Could you send you your code as well. I would like to see what changes that you’ve made to get it to work. Or could you copy your body dimensions and pin configuration to V1.3 and see if it works? There aren’t a lot of differences between V1.2 and V1.3 so it shouldn’t be to hard to do.
The HS-475 shouldn’t be a problem. They’ve got the same interface then the HS-645 that I use. Can you upload a vid to let us see what’s going on? (you can send a private vid on youtube if you don’t want to share your wobbly hex to the world )
ok. the point of the question was to see if unloading the servos of the weight of the bot changes their behavior. If it did then it is possible indicator of a power issue. Based on your observation that doesn’t seem to be the case.
Is it also safe to assume you have used lynxterm or some other application to fully test the range of motion of each axis, verifying the servos all work, and that they are assigned to the channel number they are supposed to be for the code to work?
I don’t need another copy of the code, I already have it But I did send you a PM with the code. I believe that the problem was one or more variables overflowed, so I changed one or two variables from byte to word…
Thanks for the code. It could be possible that a few variables overflow if you use other dimensions. I will compare your code with my version and make it words by default.
One of the problems I think I have is the servo battery I’m using is old and not holding a charge for very long. I’ll replace it with a 4000mA LiPo I have and see what happens.
The bot is running Kurte’s modified Phoenix v1.2 code, that works great oh his CH3-R.
I’ve noticed, with the tethered controller, that you hear the start-up ‘beep’ sequence twice. Does that have a significant meaning?
Currently, the legs start moving immediately w/o ever having told them to do so. Not sure if this a product of my old tethered controller or not.
When logic powered is first applied, you’ll notice that the bot goes to the ‘all 1500’ mode then relaxes. After START is pressed, all the femurs move to a ‘-45’ angle then the bot starts to walk. Why is this?
Note my CHR-3 has type 3 legs as shown in powerpod and it looks like yours are type 1, so some of the dimensions will be different and will need to updated in the basic program. For the two sounds, I need to try mine out again to see if that is the PS2 init sound, or the sound sequence when you press the start button that I am hearing.
The initial position that I had was maybe a bit low as you say the 45 degrees. When I start to walk I will normally rise it up. I either use the 4 button thing on the left part of the PS2 or I think it is the triangle button. This makes it walk better!
Going to 1500 and then relax sounds like either something reset or maybe does your SSC-32 have an initial position defined? I believe the first thing Xan’s code does is to turn off all of the servos…
Now as for starting up walking. I am not sure, It is almost like your PS2 controller does not start up in what his code things is zero. I know when I was earlier trying this code with an RC controller, I had this problem, that I had to get the zero position for the sticks just right or it would start to walk. So I updated that code to do some init checking and would poll the device a couple of times and form what it thought was the zero points at startup time…
I have not tried a wired controller before (never had one). However I am playing with the PS2 code to try to make it work better with more controllers and yesterday a care package arrived that included several different controller including I think two wired ones. Maybe later today I will rehook up the hex and see how it is working with the controllers.
Well, I did not hook it up to my Hex, but I updated my PS2 test setup to now use a new BB2 and BAP that came in the care package. It made it much easier to hook up the logic analyzer then when I was doing with the ABB as I could hook up the PS2 directly to pins 12-15 and then hook up the logic probes to the PS2 connection pins on the BB2 and then use one Y cable to connect up the ACK pin to IO pin 8… But that is off topic here, I will continue on the appropriate thread…
However what I did find, was the Sony wired PS2 controller did not properly zero the four joysticks at 80hex (128), but instead I was seeing things the four values returned for the joysticks were: 7D, 7B, 8E, 71
These values up to 14 away from what is considered center would be enough to make it want to walk on it’s own.
This makes perfect sense! I’ve made it possible to easy adapt the dead band of the remote in V1.3. Check out this part:
TravelDeadZone con 4 ;The deadzone for the analog input from the remote
[code] IF(HexOn)THEN
;Wait for previous commands to be completed while walking
IF(ABS(TravelLengthX)>TravelDeadZone | ABS(TravelLengthZ)>TravelDeadZone | ABS(TravelRotationY*2)>TravelDeadZone) THEN
pause (PrevSSCTime - CycleTime -50) MIN 1 ; Min 1 ensures that there alway is a value in the pause command
IF(BalanceMode=0)THEN
SSCTime = NomGaitSpeed + (InputTimeDelay*2)
ELSE
SSCTime = NomGaitSpeed + (InputTimeDelay*2) + 100
ENDIF
ELSE
SSCTime = 200 ;NomGaitSpeed
ENDIF
GOSUB ServoDriver
ELSE[/code]
It’s easy to include in your V1.2 and put it to the highest error value. This should stop the hex from walking.
A better solution is to check if the error is always the same. You could add the error value to the PS2 sub to get the middle position right. It should be something like this:
PSError3 con xx
PSError4 con xx
PSError5 con xx
PSError6 con xx
But I did send you a PM with the code. I believe that the problem was one or more variables overflowed, so I changed one or two variables from byte to word…