Converting 2DOF hex code from atom to pro

Lynxmotion Legged Robots
1

Well I’m trying to resurrect some old PS2 code for the 2DOF hexapod I’m working on. It’s this program.

h2prog6.bas (11.4 KB)

I’ve made the change from 4-7 to 12-15 for the PS2 cable and the SSC-32 comms from 15 to 8 and changed the ADIN command. I also forced the GP2D12 sensor off. The PS2 is detected, but after 5 seconds it starts walking backwards on the left side and the right side makes no stride. It’s a gradual left hand back up. :stuck_out_tongue:

I believe the Phoenix PS2 code is better tested and works better. I know some timing sensitive commands may need to be changed though. Any coders want to show a dumb guy what’s wrong with this?

2

I am assuming that the SSC-32 does not have a GP version of the software installed :laughing: Likewise all of the servos are on their predefined servo channels on the SSC-32.

I am reading through all of the comments to see what the program is trying to do :wink: I have never tried the 2dof Hex sequencer before so I am not sure how much help I would be. Think I would have to start by either adding in some debug messages and/or LEDS to see where the program is executing.

Looking at the PS2 init code it looks like some of our other PS2 functions pauses longer after the init, but before it does a read again to see what mode it is in. Also the PS2 read code is different. It only reads in the first three bytes using a loop. Then it starts a read setting the large motor value and then reads in the additional bytes again with a loop. I believe at times the loop may not be fast enough to reliably read in the PS2 data. Would suggest to start with disable the code that does the motor and use more standard input code, like:

low SEL shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8] shiftin DAT,CLK,FASTLSBPOST,[DualShock(0)\8, DualShock(1)\8, DualShock(2)\8, DualShock(3)\8, | DualShock(4)\8, DualShock(5)\8, DualShock(6)\8] high SEL pause 1
That is all for now.
Kurt
Kurt

3

I’ve done much testing. It does give back the correct pad mode. I started to put in serouts for the coordinates, but sigh… ran out of time. :stuck_out_tongue:

4

Sorry I could not resist :laughing:

But I have heard in the past that the for loops may not be fast enough to properly capture the data coming back from the PS2. So I personally at a minimum would change the code:

main ;DS2 low SEL shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8] for index = 0 to 2 shiftin DAT,CLK,FASTLSBPOST,[DualShock(index)\8] next high SEL pause 1 low SEL shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8,$0\8,$0\8,LargeMotor\8] for index = 3 to 6 shiftin DAT,CLK,FASTLSBPOST,[DualShock(index)\8] next high SEL pause 1
To something like:

main ;DS2 low SEL shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8] shiftin DAT,CLK,FASTLSBPOST,[DualShock(0)\8, DualShock(1)\8, DualShock(2)\8] high SEL pause 1 low SEL shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8,$0\8,$0\8,LargeMotor\8] shiftin DAT,CLK,FASTLSBPOST,[DualShock(3)\8, DualShock(4)\8, DualShock(5)\8, DualShock(6)\8] high SEL pause 1
That is assuming that still want to support the motor… Otherwise I would just combine the two shiftins… In fact I might do that anyway…

main ;DS2 low SEL shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8] shiftin DAT,CLK,FASTLSBPOST,[DualShock(0)\8, DualShock(1)\8, DualShock(2)\8, | DualShock(3)\8, DualShock(4)\8, DualShock(5)\8, DualShock(6)\8] high SEL pause 1 low SEL shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8,$0\8,$0\8,LargeMotor\8] high SEL pause 1

Also aways down in the program is a nap statement.

[code]nap 2 ;internal sleep mode, approx 38ms, use value 3,4 or 5 with some slow wireless controller

LastButton(0) = DualShock(1)
LastButton(1) = DualShock(2)

goto main[/code]

I would probably change the nap 2 statement into a pause 50 statement.

That is all I see right now.
Kurt

5

Its not so much that the for next looping method is too slow to get the data from the PS/2. It is syncronous serial so speed doesn’t really matter in getting the data. What the main issue is is the for next loop is much slower than the inline reads which slows down your main program since you have to constantly re-read the PS/2 data. By inlining the reads you optimize your code for speed.

6

Are you saying the loop overhead for a for-next loop is the problem? Or the calls to do the serial in?

Are there excessive PS/2 reads that could be avoided?

The for-next makes multiple calls to do a PS/2 read, rather then one call to do many?

I don’t think I’m following.

Alan KM6VV

7

Alan,

What I think Nathan is saying is that in theory it should not matter about the timing differences between using a for loop with separate input commands versus read them all at once. This is because the pseudo SPI communication that the PS2 is using is synchronous, IE it it uses the clock signal to pace the input.

However I thought year or two ago I was having problems with PS2 input with some devices and I remember being told by someone (I thought Nathan), that on some devices they may be finicky and if there is a pause and they may stop outputting the rest of the packet…
This may not be the case, but I thought it be worth updating the code to remove this possibility of being the issue.

Robot Dude - Any luck yet???

Kurt

8

Try as I might… I just haven’t been able to do anything with it yet. :frowning:

9

Lifes too short. I said the heck with everything and opened it up. It was the nap. I changed it to pause 50 and everything is good to go! Now for the changes I want to implement! Muahahahaha! cough cough, lol
Thanks for the help Kurt! You nailed it.

10

Glad it is working!

Hope you feel better soon! :laughing:

Kurt

11

It’s quite possible some PS/2 controllers have a timeout. In those cases()and I think I had one that had that problem years ago) then while you are reading the data it times out and stops replying to the command. I definitely recommend inlining the reads. It’s much faster and we know it works on most PS/2 controllers.

12

Yes, I’d agree on the in-lining of the reads.

SPI (PS/2) doesn’t seem to document a timeout, but I know other SSI interfaces to things like encoders (Renishaw) do impose timeouts.

I was probably reading too much into the explanation. Not trying to be critical, but i was surprised to read (infer?) of greater call overhead then I’d suspect.

Thanks for the clairification!

Alan KM6VV

13

I utilized the second method.

main ;DS2 low SEL ;Get Buttons shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8] shiftin DAT,CLK,FASTLSBPOST,[DualShock(0)\8, DualShock(1)\8, DualShock(2)\8] high SEL pause 1 low SEL ;Get Joysticks shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8,$0\8,$0\8,LargeMotor\8] shiftin DAT,CLK,FASTLSBPOST,[DualShock(3)\8, DualShock(4)\8, DualShock(5)\8, DualShock(6)\8] high SEL pause 1

I made great progress on the code. Now when you select a leg trajectory using the Triangle, Circle, Box or X it also sets the speed limit, servo range and body ride height. So for example, pushing the square button slows down the speed and maximizes the vertical throw for maximum ground clearance. I’m going to post the code here soon.