I did! 
First thing I checked, I read the instructions in the code at top.
Still no go.
Hi Tyberius,
It should be plug and prey… uhm play 
Do you hear a beep when you hit the start button?
If not it have to be something in the SP2 remote.
If you do hear a beep, it must have something to do with the SSC or the communication to it. Check the pin layout in the top part of the code. You can switch between 2 setups by defining a value in the top.
Be aware: If you are using V1.2 or higher you need to put the servo offsets in the SSC registers.
Let me know if you find something…
Xan
Hi EddieB, Kurt and Acidtech,
Sounds like a good idea! And a resolution of 0.175 degrees will result with steps of 0.23mm on the knee. Sounds more then enough for me! I don’t know why I only need values for 45 degrees. I though that 90 degrees was the minimum to get the full range. 
But I’ll start generating all the values in excel and just see which ones I can shift on each other to get the table as small as possible.
Maybe a stupid question but what do you mean with 8.8 
I think I’ve read that somewhere but I need to look that up.
Yeah I do have plenty of room left so I’m gone see what resolution that I need for the application. And check if I need a table for 45 or 90 deg.
Thanks!
Xan
8.8 is shorthand notation for a fixed point format where 8 bits are the integer and 8 bits are the fractional part. In your sin lookup table you probably would want 0.8 as there is no integer part to the values. When you do math with fixed point vars it is important to keep the decimal place in the correct location for add/sub and know how many bits to shift for mul/div.
and you are correct and actually need 90 degrees in the table. sorry.
kurte answered the constant storage question above and illustrated the use of the BYTETABLE command.
where you guys are using spreadsheets for all these IK calculations you may want to look at reworking portions using the limited precision of fixed point representation. the order of how you apply terms in a mathematical equation when doing fixed point is important to prevent overflow or a complete loss of the fractional portion of your answers. this is similar to how recursive digital filters illustrated/tested using floating point math may fail to converge when implemented with finite precision variables. another classic extreme example is device modeling in circuit simulation actually being limited by the precision of even an 80-bit floating point value. if something in the IK process is real time and recursively uses positions calculated for other joints you could, in a worst case scenario, wind up with ocsillation. just something to think about anyway.
Well, thing is, the PS2 controller works perfectly fine using v1.1 software on the Lynxmotion Phoenix project page.
I do not hear a beep when I hit the start button. I turn the robot on with the power switch, all servos go to 1500, the PS2 conntroller connects (both lights on the receiver on), and then I hit start, but nothing happens.
Already have servo offsets set in the registers.
Hi Eddie,
Thanks for explaining the fixed point notation. This will come in handy in any future discussions. I think that I need to use a 1.8 notation since the result of sin/cos could be 1. Or is it only possible to get parts of 8 (byte) like 1.7. Or I could also return +/-1 without looking it up in the table 
I’ll see what the best way is.
I think that I know what you mean but I can’t think about when this should happen. I’m already working with limited precision on the positions and this isn’t a problem right now. I could be wrong and it could happen but I think that I need to think about that when it actually happens so I can visualize the problem better!
Thanks!
Hi Tyberius,
All the servos will start free in version V1.2 and V1.3. If you press the start button the servos will go to the init position which is NOT 1500 but a position where the body is down. Check my latest video to see how it should work.
But back to the remote, I did change something between V1.1 and V1.2. I don’t know which ATOM you’re using but the current IDE for the 28 pro happens to have a bug in the nap command. So we changed “nap 4â€
I’m using 8.0.1.7 IDE and a Basic Atom Pro.
Yeah it’s not starting in the ‘free position’. The v1.1 code does that when I start it up, but like I said, both 1.2 and 1.3 just set servos to 1500 and doesn’t respond to the start button or any other controls for that matter. I followed the instructions in the Phoenix build article for using the CD spindle to set the offsets in the register, so that is all done correctly.
This is the code I’m using from the Phoenix tutorial that works:
lynxmotion.com/images/files/photri01.bas
Perhaps if you have time you could see if that code still works on your phoenix?
Hey Andy, Sorry if this was mentioned before, I’m having a busy day. Do the red LED’s light up on the receiver. Note, this will happen even if the Atom chip is not in the circuit. If yes, then the PS2 transmitter is communicating with the receiver. Next, can you modify the program so it doesn’t need the start button press to enable the robot? I think this is one of the things that changed from 1.1. That’s all I can think of right now.
Both lights come on once I turn on the PS2 controller, so I know its establishing a connection.
I’ll remove the Start button code when I get into work and see if that works.
Removed the “Start button” code that turned the bot on in 1.3. Still no go.
v1.1, I turn on the bot, I get a quick beep, and it goes to it’s free position with the body on the ground. Takes commands from the PS2 controller without issue.
v1.3, I turn on the bot, no beep, and it goes to all 1500 position. Non responsive to the PS2 controller.
Any ideas?
Jim have you tested v1.2 or v1.3 on your Phoenix hexapods?
Hi Tyberius,
This really doesn’t make any sense to me! 
Especially the 1500 part, there isn’t a sub in there which drives all to 1500…I’ve got some free time on Saturday, I’ll try the “oldâ€
We’re unable to work on this today. I will see what Monday looks like. Sorry 
Have you tried, power up the robot, turn off the PS2 controller, turn it back on, hit the analog button and then try hitting the start button? I assume you tried fresh batteries.
Also for the fun of it, try putting some sound at the start of the program, and see if by chance your robot is resetting.
You might also put some different sounds or serouts to S_OUT at some strategic locations, like before it goes into and after it gets valid input from the PS2 controller to make sure it is not getting hung up there.
Other than that I know the 1.2 worked on my CHR-3 with changes. I have not tried the 1.3 yet.
Good Luck
Kurt
Whoops! I forgot. We have already installed 1.2 on our Phoenix. The start button thing stumped us for a little while, but yes it works great. We haven’t tried 1.3 yet.
Yes, Kurte is right, lets not get blinders on. We have to check the basics. Can you try powering the logic separately?
I always power logic separately on my bots, batteries are all fresh and/or charged. Like I said- works with 1.1 without issue.
I’ll try adding some sounds to it to assist in troubleshooting though.
Hi guys,
Found a dead PS2 receiver at the heart of my communications problems. I probably over-volted it during build and setup. Bought a new wireless PS2 - (thanks LM!), no problems. The new Bot Board II made things work better as well. Already started with 1.2 and everything responds as Xan programmed it to — Great Program!!
Only problem I have is the coxa/femur joints on my bot are responding inverted. I can re-wire the pots on these servos or change the code. Code sounds easier. Where is the best place to make such a change. Knowing this will help me to learn how to play with variables on BAP code; I might even improve my programming skills. 
Can’t wait to play with 1.3 . . . . .
Well I figured it out.
Did a lot of digging through the code and testing things out, PS2 controller was certainly communicating with the BS2 without issue.
After a lot of tinkering with the code, I went back into the SSC-32 Reg settings and tried something.
This picture in the Phoenix tutorial shows Initial Pulse Width enabled:
The fact that the hex was going to 1500 at startup seemed odd to me, so I tried disabled this since it affects the hex at startup, and everything started working.
Looks like you can’t have Initial Pulse Width enabled if you’re using the newer versions of the codes.
Hi Tyberius,
I’m glad to hear that you’ve solved the problem with the SSC. V1.1 uses a serout command to set up the offsets at the beginning of the code. The offsets are moved to the SSC’s registers in a later version. It looks like the serout command for the offsets disables the Initial Pulse Width and the SSC register offsets. I think I remember Jim saying something like that about the offsets. But I’m not sure about the Pulse Width… Anyway, now we know thanks for the test! 8)
Is it fully working right now? I can’t see how the Initial Pulse Width caused the program not to “beepâ€
Hi brlippincott,
Thanks for the comments, I’m glad you like the program 8)
This isn’t to hard. In the beginning of your code you will find this constant:
SSC_LM_SETUP con 1 ;Changes the SSC pins corresponding to the setup
;1 = Setup with connector to the front
;0 = Setup with connector to the backThis one decides if you are using a setup like lynxmotion (SSC connector to the front) or the setup like BlackWido (connector to the back and… I forgot to mention… upside down ). Anyway, if you’re not using either of them you can make your own custom SSC pin layout. I suggest you change the constant to 0 and adapt that one.
A little bit further down you’ll find the pin numbers. Go to the part that says #ELSE and assign the right pin to the right servo by changing the Px values.
[code]
;[PIN NUMBERS]
#IF SSC_LM_SETUP ;Connector to the front
RRCoxaPin con P0 ;Rear Right leg Hip Horizontal
…
LFTibiaPin con P26 ;Front Left leg Knee
#ELSE ;Connector to the back
RFCoxaPin con P2 ;Front Right leg Hip Horizontal
RFFemurPin con P1 ;Front Right leg Hip Vertical
RFTibiaPin con P0 ;Front Right leg Knee
RMCoxaPin con P6 ;Middle Right leg Hip Horizontal
RMFemurPin con P5 ;Middle Right leg Hip Vertical
RMTibiaPin con P4 ;Middle Right leg Knee
RRCoxaPin con P10 ;Rear Right leg Hip Horizontal
RRFemurPin con P9 ;Rear Right leg Hip Vertical
RRTibiaPin con P8 ;Rear Right leg Knee
LFCoxaPin con P18 ;Front Left leg Hip Horizontal
LFFemurPin con P17 ;Front Left leg Hip Vertical
LFTibiaPin con P16 ;Front Left leg Knee
LMCoxaPin con P22 ;Middle Left leg Hip Horizontal
LMFemurPin con P21 ;Middle Left leg Hip Vertical
LMTibiaPin con P20 ;Middle Left leg Knee
LRCoxaPin con P26 ;Rear Left leg Hip Horizontal
LRFemurPin con P25 ;Rear Left leg Hip Vertical
LRTibiaPin con P24 ;Rear Left leg Knee
#ENDIF[/code]
Good luck!
Xan
How could you forget Jim 
But i’m glad i’ve got yah with the start button
(just kidding)