I’m not sure if this helps you or not, but you don’t really need the initialize legs at all 1500 at start, you can de click this, or when you turn your robot on it will be tall then 2 seconds later it will fall to the ground.
You really don’t need that option, although It’s good to check to see if all your legs are aligned properly.
I’m a bit confused with you’re story. Are you talking about the SSC registers for the initial pulse offset or for the initial pulse length?
The only thing you need to do is set the registers for the pulse offsets and make sure the option is enabled in the enable register (R0). Don’t forget to check bit 15 which enables all functions. (The table in manual talks about bit 12 but it should be 15.) Don’t use the SSC initial pulse lengths.
After hitting the start button the legs should snap in to the init position. Check the vid at 0.03
Phoenix getting up is just me hitting the triangle button
It’s also possible to use the d-pad up/down buttons to adjust the body-ground clearance.
I made a quick test-setup started debugging this Saturday. I had the servo following the direction when my girlfriend pulled me away from my PC. I think I can get the servo to move on rotation as well tomorrow. Then you’ll have a ready to rock sub.
as im not a programmer at heart (having only really modified codes) i have noticed the importance of these breakets. what do they reall do/mean?
and what changes when adding another? ))
The brackets are simply used to define the order of operations. In this case it’s not only for adding and multiplying but also for converting to floats and backwards.
I also had to made some small changes to the calculation to get the servo in the middle position (0 deg). But as I said, this was just a simple scratch. I didn’t even tried to compile it.
Here is the code to make the body servo move in the walking direction. You will see that the middle position is a bit bumpy. This is caused by a error in the FACOS function. The error is somewhere in the compiler and is out of my hands. Jim and Nathan are both aware of this error. I’m using cos tables in V2.0 so it doesn’t have the same problems which makes the whole setup much more stable. I’ll hope to release it soon. There still are some balance problems to solve. Anyway, here is the code:
[code]BodyDirection:
;Return to the middle position
BodyAngle=0
;IF ((ABS(TravelLengthX)>TravelDeadZone | ABS(TravelLengthZ)>TravelDeadZone) & TravelLengthZ<TravelDeadZone) | ABS(TravelRotationY*10)>TravelDeadZone THEN
IF ABS(TravelLengthX)>TravelDeadZone | ABS(TravelLengthZ)>TravelDeadZone THEN
;Calculate walking direction X and Z
TravelLengthXZ = SQR((TravelLengthX * TravelLengthX) + TravelLengthZ * TravelLengthZ)
BodyAngle = TOINT(FACOS(TOFLOAT(TravelLengthZ) / TOFLOAT(TravelLengthXZ)) * 180.0 / 3.141592)-180
;Add sign depending on the direction of X
BodyAngle = BodyAngle * (TravelLengthX/ABS(TravelLengthX))
ENDIF
;Calculate body angle depending on rotation
IF ABS(TravelRotationY2)>TravelDeadZone & ABS(TravelRotationY3) > ABS(BodyAngle) THEN
BodyAngle = -TravelRotationY3 ; Rotation max = 166 to get max range of 90 deg.
ENDIF
RETURN[/code]
I only included the bodydirection sub. I guess you’ll figure the rest out
I hope it will be pretty painless trying to implement this in the code Zenta modified for RC control, doing the 7 Pulsin’s really causes the phoenix to become pre occupied with reading those channels and you can see the gait lagging.
It’s too bad the atom pro isn’t 2x as fast… cause you can always fix slow code with throwing in a faster cpu “cough Microsoft cough”
cool cool, looking forward to taking a look at that code.