BlackWido

[robotdude]

@Xan

I found the source for the SSC-32 I think that i’m gonne play with that in time. It look like I need to include something for the servo error to get a good and precise position. But before I can experiment with that I need to replace the mega8 with the mega168. So I’m thinking of going with a fast correction in the ATOM for now and change this in a later stadium.

What’s the version of the SSC-32 included in the phoenix kit jim?

Xan

I will send you an upgrade chip for your mega 8 board. We have been shipping the SSC-32’s with the mega 168 since January I think.

[robotdude]

@kurte

The AtMega168 has twice the programming space as the Atmega8 so hopefully there is still some room left. May play with programming the SSC-32. I thought it would be fun to add a command or two. Like maybe allow other IO pins to be used for inputs…

After chatting with Mike yesterday I have been reminded that although the mega168 does have more program memory there is still a big limit on variables. The SSC-32 uses shift registers for the outputs. There are only 4 I/O pins that go directly to the outside world. That’s how we were able to get 32 servo outputs from a 28 pin processor. Mike recommends we hold off on trying to implement servo scaling for the SSC-NG. Servo scaling sounds pretty straight forward at first, but when you look at the complex group moves, it gets pretty dicey. Mike said it took him three attempts to get the servo offset command squeezed in there.

[xan]

@Robot Dude

I will send you an upgrade chip for your mega 8 board. We have been shipping the SSC-32’s with the mega 168 since January I think.

Thanks Jim!

@Robot Dude

After chatting with Mike yesterday I have been reminded that although the mega168 does have more program memory there is still a big limit on variables. The SSC-32 uses shift registers for the outputs. There are only 4 I/O pins that go directly to the outside world. That’s how we were able to get 32 servo outputs from a 28 pin processor. Mike recommends we hold off on trying to implement servo scaling for the SSC-NG. Servo scaling sounds pretty straight forward at first, but when you look at the complex group moves, it gets pretty dicey. Mike said it took him three attempts to get the servo offset command squeezed in there.

That sure sounds like it is pretty hard to squeeze some extra functionality in the SSC. With this information I think that it is better to keep the scaling in the ATOM 28 pro. Thanks for the information!

Xan

[kurte]

@Robot Dude

After chatting with Mike yesterday I have been reminded that although the mega168 does have more program memory there is still a big limit on variables. The SSC-32 uses shift registers for the outputs. There are only 4 I/O pins that go directly to the outside world. That’s how we were able to get 32 servo outputs from a 28 pin processor. Mike recommends we hold off on trying to implement servo scaling for the SSC-NG. Servo scaling sounds pretty straight forward at first, but when you look at the complex group moves, it gets pretty dicey. Mike said it took him three attempts to get the servo offset command squeezed in there.

Sounds good. I may still play around some, but obvlously it would only be for my own boards, (Unless of course I come up with something interesting).

As you said it would not be possible with the current board design to use some of the servo lines as more general inputs as the 74HC595 chips only allow you to do outputs…

I hope it won’t be too long untill the SSC-NG…

Kurt

[xan]

Hi all,

Yesterday I received a box that had “Lynxmotionâ€

[robotdude]

Hey wow, sounds like we’re getting very close.

The PS2 cable did have a wire or two change color on the last batch. The online tutorials and stuff are correct, but the Bot Board manual is not up to date. The Bot board manual is to be replaced with an HTML version soon. We just finished the SSC-32 manual conversions, although we will be adding more example code and more detailed troubleshooting stuff.

Here is the new SSC-32 (2.01XE) Users Manual.

lynxmotion.com/images/html/build136.htm

You will notice in the shorting bar jumpers and connections diagrams I’ve standardized the bidirectional communications connections. It can easily be done with a modified servo extender style cable.

We will post your code as soon as we receive it. Thanks Xan!

[zenta]

Hi Xan,
Congratz with your new Phoenix kit!
Looking forward to see your new code. If its correct that your code is too fast without the synchronisation part, that is somehow good news? I think…
Hopefully you’ll figure it out!

Have a nice trip!

[xan]

Hi Jim,

@Robot Dude

Hey wow, sounds like we’re getting very close.

We sure are, but still I’m having some problems initializing the PS2 remote. Here is a sample of the code that I’ve borrowed from powerpod.

Ps2Input:
	
	low PS2SEL
	shiftout PS2CMD,PS2CLK,FASTLSBPRE,$1\8]
	shiftin PS2DAT,PS2CLK,FASTLSBPOST,[DS2Mode\8]
	high PS2SEL
	pause 1

	low PS2SEL
	shiftout PS2CMD,PS2CLK,FASTLSBPRE,$1\8,$42\8]	
	shiftin PS2DAT,PS2CLK,FASTLSBPOST,[DualShock(0)\8, DualShock(1)\8, DualShock(2)\8, DualShock(3)\8, |
		DualShock(4)\8, DualShock(5)\8, DualShock(6)\8]
	high PS2SEL
	pause 1	

	if DS2Mode <> PadMode then
		low PS2SEL
		shiftout PS2CMD,PS2CLK,FASTLSBPRE,$1\8,$43\8,$0\8,$1\8,$0\8] ;CONFIG_MODE_ENTER
		high PS2SEL
		pause 1

		low PS2SEL
		shiftout PS2CMD,PS2CLK,FASTLSBPRE,$01\8,$44\8,$00\8,$01\8,$03\8,$00\8,$00\8,$00\8,$00\8] ;SET_MODE_AND_LOCK
		high PS2SEL
		pause 1

		low PS2SEL
		shiftout PS2CMD,PS2CLK,FASTLSBPRE,$01\8,$4F\8,$00\8,$FF\8,$FF\8,$03\8,$00\8,$00\8,$00\8] ;SET_DS2_NATIVE_MODE
		high PS2SEL
		pause 1

		low PS2SEL
		shiftout PS2CMD,PS2CLK,FASTLSBPRE,$01\8,$43\8,$00\8,$00\8,$5A\8,$5A\8,$5A\8,$5A\8,$5A\8] ;CONFIG_MODE_EXIT_DS2_NATIVE
		high PS2SEL
		pause 1

		low PS2SEL
		shiftout PS2CMD,PS2CLK,FASTLSBPRE,$01\8,$43\8,$00\8,$00\8,$00\8,$00\8,$00\8,$00\8,$00\8] ;CONFIG_MODE_EXIT
		high PS2SEL
		nap 4
		
		;sound P9,[100\4000, 100\4000, 100\4000]
		return
	endif
	
	serout s_out, i9600, [dec DS2Mode, " ", dec dualshock(0), " ", dec dualshock(1), " ", dec dualshock(2), " ", dec dualshock(3), |
						  dec dualshock(4), " ", dec dualshock(5), " ", dec dualshock(6), 13]
return

I call this subroute from the main loop. What it does right now is just start beeping which means that it is initializing the whole time (DS2Mode <> PadMode). But the strange thing is, when I open the connection from my pc to read out the data. It stops beeping and starts sending me the data of the controller!! Once done, I can disconnect it from my pc and start using it!!!

Maybe you can have Laurent take a look at it?

@Robot Dude

The PS2 cable did have a wire or two change color on the last batch. The online tutorials and stuff are correct, but the Bot Board manual is not up to date. The Bot board manual is to be replaced with an HTML version soon. We just finished the SSC-32 manual conversions, although we will be adding more example code and more detailed troubleshooting stuff.

Here is the new SSC-32 (2.01XE) Users Manual.

lynxmotion.com/images/html/build136.htm

You will notice in the shorting bar jumpers and connections diagrams I’ve standardized the bidirectional communications connections. It can easily be done with a modified servo extender style cable.

I like the html format and it doesn’t take long to open Great that you’ve included the bidirectional communication. Since I needed to reconnect everything for this test I’m not using it for this test but I will use it again after the tests.

@Robot Dude

We will post your code as soon as we receive it.

Thanks, it is on his way!

Hi Zenta,

@zenta

Hi Xan,
Congratz with your new Phoenix kit!
Looking forward to see your new code. If its correct that your code is too fast without the synchronisation part, that is somehow good news? I think…
Hopefully you’ll figure it out!

Have a nice trip!

Thanks, I can’t wait to put everything together once I’m back! My code being to fast is a very good thing!! Check my latest video, I’ve disconnecting the synchronization and increased the speed of the servos. It is so fast right now, it even gives me the creeps
But I still need to figure out how to make the synchronization part faster. Maybe I’ll think that over on the beach 8)

Here is the latest video, sry for the bad light, I was in a hurry
youtube.com/watch?v=w92gXdfE1kY

The tape on the legs is just for calibrating, I would never hurt a innocent bot

CU in a couple of weeks!

Xan

[xan]

Hi Jim and Beth,

I’ve just send you my new code (V1.1) by mail.

The code works with the bidirectional cable between the botboard and the SSC. If you want to use a single cable you can comment out this part:

;Wait for previous commands to be completed SSCWait: serout SSC_OUT,SSC_BAUTE,"Q",13] serin SSC_IN, SSC_BAUTE,[SSCDone] IF SSCDone <> "." THEN goto SSCWait ENDIF

I didn’t tested the code on the phoenix yet. But as far as I know, the only thing that needs to be done is changing the pin layout and add the correct servo offsets. Those can be easily found in the code.

Current status:

;NEW IN V1.1 ; - 6 steps Ripple Gait ; - Lynxmotion PS2 controller support ; ;KNOWN BUGS: ; - Synchronisation PS2 controller (for more information see: http://www.lynxmotion.net/viewtopic.php?t=3979&postdays=0&postorder=asc&start=0) ; - Maximum height of the body. If BodyY > 128 it will overflow and gets a negative value which causes the hex to drop down with the legs in the air. ; ;TODO: ; - Include Deadzone on the controls ; - Replace sin, cos, atan with a byte table to improve calculating speed ; - Replace All Floats with sword * 1000 to improve calculating speed and free some memory ; - Implement 12 steps Gait ; - Run some synchronisation tests ; - Include balance calculations

I hope that somebody can get his phoenix up and running with this
I’m looking forward to see some videos!!! 8)

Good luck,

Xan

[plingboot]

Just checked out the vid and I !!REALLY!! want to get my hands on this - it looks absolutely great.

Final bit (bluesmirf) for my phoenix arrived today, but i’ve also got the botboard, Basic Atom 28 pin (NOT PRO) and LM PS2 controller sitting waiting to be used.

[robotdude]

@Xan

Hi Jim,

We sure are, but still I’m having some problems initializing the PS2 remote. Here is a sample of the code that I’ve borrowed from powerpod.

Have you tried the second controller just to make sure it’s not a hardware defect in one of them?

@Xan

Here is the latest video, sry for the bad light, I was in a hurry
youtube.com/watch?v=w92gXdfE1kY

Very cool video! Great job! 8)

[snailkeeper]

I’ve updated the project page. Let me know if you’d like any changes made!

lynxmotion.com/images/html/proj102.htm

[zenta]

Hi Xan!

Excellent video, now we are talking! Much better speed and smooth movement. Can’t wait to test your code when I’m back from vacation. Also have to play with the GP sequencer too. Imagine some cool GP sequences combined with your awesome realtime control!! 8)

You said the tape was for calibrating? Did the tape mark make it easier?

[xan]

Hi,

Thank for all the positive feedback. I hope that my code will work out for the both of you. I’m cunnently in Singapore so this will be a quick note 8)

@Robot Dude

Have you tried the second controller just to make sure it’s not a hardware defect in one of them?

I didn’t tested the 2nd controller yet. It sound like a good thing to do. I will check that in a couple of weeks.

@zenta

You said the tape was for calibrating? Did the tape mark make it easier?

Yes it sure did! I used the tape to draw a straid line between the feed and the axis of the tibia. this made it much easier to check the different angle-pulse relations. I wasn’t finished yet so that’s wy the tape is still on there. I hope to finish that afther my vacantion.

I saw that LM also has got a distributor over here, maybe I’ll drop by if we’ve got some time left

Xan (@ Singapore)

[zenta]

Hi Xan!

I just had my LM Phoenix up and running with PS2 remote with your code!!! YEAH! 8)

THANKS XAN! (ok I’m a bit thrilled right now!)

[xan]

Hi Zenta,

@zenta

I just had my LM Phoenix up and running with PS2 remote with your code!!! YEAH! 8)

THANKS XAN! (ok I’m a bit thrilled right now!)

COOL! It looks like you are the first one that has my code working on the LM phoenix!! Great!! I would love to hear what “problems” you’ve encounterd…

Did you need to change anything more than the offsets and pin-numbers?

Xan

[zenta]

@Xan

Hi Zenta,
COOL! It looks like you are the first one that has my code working on the LM phoenix!! Great!! I would love to hear what “problems” you’ve encounterd…

Did you need to change anything more than the offsets and pin-numbers?

Xan

Hi Xan,

I only changed the offsets (servo and body dim.) and the pin numbers.
I found the servo offsets from the SSC32 SEQ setup, just subtracted 1500 from the centre (0 deg) position. I didn’t change the max/min angles yet.
Made a short 3-wire cable from pin 4,5,6 to the A,B,C led/buttons, then a 2 wire cable between P11 and P10 to the SSC32 RX and TX.
And finaly the PS2.

About the PS2 init, I just hit the reset button (sometimes I have to reset twice ) and then she was walking!

Added speed function to the R1 and R2 buttons and changed the BodyPosY values for the Triangle and Circle buttons to make them fit with the LM Phoenix (the femur servo joint is a bit higher then our design).

I’ve just started to study your code, so far it has been relative easy to understand (and I’m no programming expert either). I think a 12 step ripple would be great too. But I like how you solved the gait part, correct me if I’m wrong but the GaitPos(X and Z) and GaitRotY = 0 are the middle position for travel and also the position (step) when the leg is lifted?

Anyway it’s great to confirm that my PEP are now compatible with your code. When I find time for it I’ve to try out the GP-sequencer on the SSC32 ver2.

[zenta]

Hi Xan,

I’ve been experimenting with the GP sequencer together with your code.
What I discovered was that the offset values your code initiates to the SSC32 gets in conflict with the stored GP values. Probably because the GP values already has been offset adjusted by the SEQ?

Anyway I altered your code by removing the offset initation at the start of your code. And then just added the offset values in the servodriver:

;Front Right leg serout SSC_OUT,SSC_BAUTE,"#",dec RFCoxaPin,"P",dec TOINT(TOFLOAT(-RFCoxaAngle +90)/0.10588238)+650+RFCoxaOffset]

By doing this your code and the GP sequencer player worked fine together!

I’ve not worked much with GP player yet, just some test code with one GP sequence with a 12 steps ripple (smooth 8) ).

[km6vv]

Hi KÃ¥re,

That may means more calcs are done each time a move is sent. But maybe the constants are pre-calculated.

I think SEQ sends offset commands as well, I could be wrong!

Alan KM6VV

@zenta

Hi Xan,

I’ve been experimenting with the GP sequencer together with your code.
What I discovered was that the offset values your code initiates to the SSC32 gets in conflict with the stored GP values. Probably because the GP values already has been offset adjusted by the SEQ? :?

Anyway I altered your code by removing the offset initation at the start of your code. And then just added the offset values in the servodriver:

;Front Right leg serout SSC_OUT,SSC_BAUTE,"#",dec RFCoxaPin,"P",dec TOINT(TOFLOAT(-RFCoxaAngle +90)/0.10588238)+650+RFCoxaOffset]

By doing this your code and the GP sequencer player worked fine together!

I’ve not worked much with GP player yet, just some test code with one GP sequence with a 12 steps ripple (smooth 8) ).

[zenta]

@KM6VV

Hi KÃ¥re,

That may means more calcs are done each time a move is sent. But maybe the constants are pre-calculated.

Hi Alan,
Yes you are right, but I didn’t see any difference when running the code. Maybe it could be solved by making a pre calculated constant that contain the value: RFTotalCoxaOffset =650+RFCoxaOffset. So if RFCoxaOffset is 47 the contstant RFTotalCoxaOffset would be 697.
new code:

[code]
RFTotalCoxaOffset CON 697
;-------------------------------

;Front Right leg
serout SSC_OUT,SSC_BAUTE,"#",dec RFCoxaPin,“P”,dec TOINT(TOFLOAT(-RFCoxaAngle +90)/0.10588238)+RFTotalCoxaOffset][/code]
Would that make the code faster?

@KM6VV

I think SEQ sends offset commands as well, I could be wrong!

To be honest I’m not sure, but I think SEQ sends the offsets too, but I was thinking of the exported EEPROM data/sequences used for the GP sequencer. It seems like these values are corrected for the offsets.