Xan's Phoenix Code

You’re in the right direction. Simply copy the free all servos sub and change “P0” to “P1500”.
The showed code is right except for the double “#”. The right code should be like this:

ALL1500 for Index = 0 to 31 serout SSC_OUTPUT,SSC_BAUD,"#",DEC Index,"P1500"] next serout SSC_OUTPUT,SSC_BAUD,"T200",13] return

I’m not fully sure what you’ve changed on those constants. There value?

Xan

ill compile this tonight when i get time. thanks bud.
only changed the name:
SSC_OUT,SSC_BAUTE,
to
SSC_OUTPUT,SSC_BAUD

Hey Xan,

Any eta on when you might share your 2.0 code? I’d like to poke around and try and implement this in the RC code zenta shared with me.

–Aaron

Actually I’ve been meaning to ask with your original 1.3 code did you have any idea how much cpu processing headroom you had with that?

I know with the RC code It’s getting pretty scarce , hopefully lookup tables will solve that.

No ETA yet. a couple of weeks I guess.

hi Xan,

yet another question as usual… bout time. LOL.

Regarding:

[code] BodyPosX = (Dualshock(5) - 128)/2
BodyPosZ = -(Dualshock(6) - 128)/3
BodyRotY = (Dualshock(3) - 128)/6

  BodyRotX = (Dualshock(6) - 128)/8
  BodyRotY = (Dualshock(3) - 128)/6
  BodyRotZ = (Dualshock(5) - 128)/8[/code]

what are the last section of numbers doing?
Eg: [code]

  • 128)/8
    [/code] :wink:

I bet you I could answer that.

The dual shock controller … Guessing here probably starts out with values at 128 when centered.

so as an example 256 being max 128 being centered and 0 being opposite direction

subtracting 128 from that makes 128 become max 0 to become centered and -128 to become opposite direction

The max and min values of 128 are pure guessing here they could be more or less, the main thing is just to subtract the number it puts out on initialization so you can obtain a zero value for centered.

The same thing has to happen when doing Pulsin reads on a RC controller as the value it puts out is 1500 so all servo code using pulsin 1500 is always subtracted from it so that you can measure the change of the input

(ABS((RCInput(0)-1500)/4)

As an example this takes the input of an rc input subtracts 1500 and divides the change by 4 to make the output of this a smaller value roughly 900-2100 which is roughly + or - 400, so the output of this whole thing would be +100 and -100

Then the ABS line makes that output +100 to zero to +100 “zero being stick centered”

Let me know if that cleared that up for you?

–Aaron

Had to answer for him Xan our timezones are quite a bit closer :slight_smile:

i see thanks. great explaination. :laughing:

thanks for the PM, i will think about it. :wink:

Innerbreed

The thing that has honestly really helped me learn is the fact that you can do things like this

serout S_OUT, i9600, "Whatleg=", sdec Whatleg, 13]

What this actually does is it outputs text “Whatleg= then the value of the variable whatleg”

You have to connect up your botboard with the basic micro software on the “terminal 1” tab and set the comport settings accordingly…

Here’s another example with variables that your probably familiar with

serout S_OUT, i9600, "GaitPosX=", sdec GaitPosX," GaitPosY=", sdec GaitPosY," GaitPosZ=", sdec GaitPosZ, 13]

I think this might have been in the original code Xan had used to debug his own code, and I think it was left in when Zenta modified it for the RC control, either way using things like this really really helps in trying to determine the values of the variables when the code is running…

I managed to make a modification to adjust the values of the Initialization values of RFPosX,Y and Z to see how they actually position the legs , and I did this with a couple push buttons … I think with enough patience you could figure out where each leg was in 3d space and make the phoenix have some neat poses, I think this is how Xan and Zenta probably did this… then there was that extra chip on the ssc32 that stores the pre set values…

I know it would help me If I had a 6volt power supply putting out a couple amps so I could power my phoenix on my desk without constantly using and charging my battery.

If anyone knows how to get 6v from a computer power supply I’m all ears!.. although I could probably just pick up a 6v linear voltage regulator… anywho!

–Aaron

I agree!

Nice s2k video zoomkat!

Yeah, I have to leave that type driving to the pros and settle for some long local interstate on ramps. :wink:

My question is Regarding BodyPosY.

using D-pad we can move the body up using this command:

BodyPosY 	= BodyPosY+10

Now, bodyPosY is sWord and BodyPosX and Z are Sbyte. i have changed these to sword and added the same command line
e.g:

IF (DualShock(1).bit4 = 0) and LastButton(0).bit4 THEN ;D-Up Button test For forward move BodyPosZ = BodyPosZ+10 Sound P9,[50\4000, 50\4500] ENDIF ;------------------ IF (DualShock(1).bit6 = 0) and LastButton(0).bit6 THEN ;D-Down Button test For back move BodyPosZ = BodyPosZ-10 ENDIF ;------------------ IF (DualShock(1).bit5 = 0) and LastButton(0).bit5 THEN ;D-Right Button Test For right side move BodyPosX = BodyPosX+10 ENDIF ;------------------ IF (DualShock(1).bit7 = 0) and LastButton(0).bit7 THEN ;D-Left Button Test For left side move BodyPosX = BodyPosX-10 ENDIF

the reason why or the intented command was to get the body to move on its horizontal X/Z plane front to back and left to right. rather than up and down. I.e manual body moves in small +/- numbers using D-pad!

im getting no movement at all by just using these buttons, like you can with Y. the button itself works as i have added a sound that i can hear when button pushed, but no movement!!? except when i use L1 and D-pad!

i have looked though the rest of the code but i cannot find what i need to change or add?

how close am i with this?
thanks.

Innerbreed,

I’m not familiar much with how the ps2 remote works since I have the RC remote, the code base is still pretty much the same as the code you and I have both worked with.

I would however toss this line in your code to try and figure out what value the variables are to see if your button pressing is actually adding 10 to BodyPosY

 serout S_OUT, i9600, "BodyPosY=", sdec BodyPosY, 13]

… You know

I guess you’d have to re explain this I popped open the 1.3 ps2 code I had and it seems like what your trying to do is possible…

Although You changed some variables to Sword? … I guess first off why did you find it necessary to do this?

I have found the variable type Xan had used to be exactly what’s needed to work, plus a lot of these max and min values of variables is well within the limits of the variable type… so increasing that won’t help or actually let you gain anything…

I found that to be the case with RFPOSX,Y,Z …

As an example, setup your main code to add and subtract values from RFPOSX, Y, Z and pick a single leg “RIGHT FRONT” for instance and each button press add 1 or subtract 1… so for all 3 variables you would use 6 buttons, make sure you connect your debug cable and monitor the values of all 3 variables and watch the leg move, you will see what I’m talking about…

I spent around 4 hours one day having the phoenix sit on a desk while I kept track of how far its legs can move out before the legs stopped moving due to mechanical limits and the values were well within the Sword…

I think the height was Z and the max was ±127 and I believe that was in mm so you couldn’t raise the phoenix higher then 127mm off the ground… so saving space in memory with that variable…

Anywho!.. put in that code snippet and see what happens, its quite possible your not changing the value of the variable or there is a problem with your code else ware…

–Aaron

An interesting idea :bulb:

can something like this be implimented?

i have started joining the “sensor” side of robotic for research but i like the idea of this.
i have already added the GP2D12 sensor to pin P0 on ABBII and ready to recieve signal. :wink:

Hi Innerbreed,

Sorry for my late reaction. I totally missed this post since I looked at it at work but didn’t had the time to react at that moment.

You’re getting no movement because the value of BodyPosX/Z is proberbly set back to 0. If you check the code some down you’ll see the part where the BodyPosX/Z is set originally. Commend it out to make sure it isn’t overwriting it and do a search to make sure the value isn’t set somewhere else.

BodyYShift = 0 IF (DualShock(2).bit2 = 0) THEN ;L1 Button test ; BodyPosX = (Dualshock(5) - 128)/2 ; BodyPosZ = -(Dualshock(6) - 128)/3 BodyRotY = (Dualshock(3) - 128)/6 BodyYShift = (-(Dualshock(4) - 128)/2)MIN-(BodyPosY-10)

This is really easy to implement. The GP2D12 sensor gives a analog value according to the distance. Simply read the input and add it to the BodyPosZ. You might need to divide the value from the input to decrease the result.

I hope you’ve got the information to do this yourself since I’m pretty occupied with some other changes I want to do on the phoenix and DIY RC.

Let me know if you have any questions. I’ll try to respond faster then the last time :wink:

Xan

Thanks for responding. I respect you are busy so please dont feel you need to apologise for that. Yay another phoenix vid? Always an enjoyment. I actually found the problem you mentioned but i also didnt update this thead so i will apologise. I soon figured out that the bodypos was set to 0 as you said. But thanks for responding. Also last night i was starting work with the sensor so i think i will be ok there. Cheers. Will let you know how it goes once i have posted the tilted coxa rotations. Thanks xan.

when i try changing the ##PosX,Y,Z (Init pos) im not getting any response!
What would course this? over shooting the values? they dont effect it even if i use true values.

The XXPosX,Y,Z variables are used to define the “home” position. Changing these values can make it a bit “messy”. But changing the values should make your leg move of course.

Its hard to say why you don’t get any respons without seeing the whole code. The fault must be somewhere, because it works fine in the original code. In my GP ONCE demo I demonstrated how to alter the init/home positions of the legs by using a sequence combined with altering the XXPos values.

I’ve been fiddling around with the RxPOSx positions, made up a whole chart how they move when I change the variables, quite interesting.

if you make a modification to the code so you can change the position of a single leg all 3 axis with 6 buttons +1 and -1 for each value you sorta get an idea what they are doing…

Honestly Ive been slacking lately. I’m not really sure why the Z axis is forward and backward when in the US its usually up and down, not sure if its a diff coordinate system.

Honestly I learned a lot getting the individual leg control working! I just need something that’s quicker then 16mhz or wait till Xan dumps his 2.0 code with lookup tables, should speed things up considerably!

Zenta :: I did remember seeing one of your videos where you modified the position’s of the middle legs so they were initialized so they were closer towards the back legs rather then in the middle… Had a very slick look to it!

Actually, forward to backward for the Z axis is normal in the US. :wink:

Z is up and down in all of the CNC, Aircraft, Ship, amd Submarine conventions in the U.S.

I did run into this coordinate system in Visio. Y up/down, X across the paper. So maybe it’s an outgrowth of “paper” axis coordinate systems? They just tacked on a Z Coming towards the viewer?

When one one draws in 2D CAD, X and Y are used. If the drawing is “extruded” into 3D, then the XY plane is rotated in a 3D view to be the “floor” (plan) of the 3D cube, and the object is extruded vertically in Z.

Perhaps there is a better explanation out there.

Alan KM6VV