BlackWido

Xan · **Posted:** Mon Jun 16, 2008 6:27 am

Robot Dude wrote:

The SSC-32 V2 has registers to hold the servo offsets. It's easy to set up and when done you no longer need to send servo offsets in your program. In fact even sending software position offsets of 0 will mess up the offsets. So comment these out when the register offsets are used.

This does not require the external eeprom to be installed. It uses the one in the atmel 168. There is no way to implement servo profiling in the SSC-32 as it is right now. Perhaps in a future update.

Here is a tutorial explaining how to do it. (Steps 5 through 10)
http://www.lynxmotion.com/images/html/build128.htm

Even if you implement some sort of profiling scheme, I highly recommend you calibrate the SSC-32 to your servos. At least 1500uS results in perfectly centered servos.

Hi Jim,

I did the calibrating for the middle position over again this weekend. I already did this when I mounted the hex the first time. Iâ€™ve noticed that even when the legs are perfectly calibrated in the middle position there is an error in position when the legs are in the â€œhomeâ€

Robot Dude · **Posted:** Mon Jun 16, 2008 9:39 am

The SSC-32 isn't really true open source. The code has been made available, but no one has ever submitted any modified code for the product. The original SSC-32 (mega8) limitation wasn't in processor cycles but in code and variable space. The new mega168 version may be able to do this. I will ask Mike to get his opinion.

kurte · **Joined:** Sat Apr 15, 2006 1:42 pm **Posts:** 2191

Robot Dude wrote:

The SSC-32 isn't really true open source. The code has been made available, but no one has ever submitted any modified code for the product. The original SSC-32 (mega8) limitation wasn't in processor cycles but in code and variable space. The new mega168 version may be able to do this. I will ask Mike to get his opinion.

I have thought about playing with the SSC-32 source code, but have not yet as I do not have codevision AVR. All of my AVR C programming has been with WinAVR.

But taking a quick look at the code, I don't think it would be very difficult to add some simple scalling to the code. You could add a command to enter the 90 and -90 degree values in the same way as Zenta did with a command like the Offset command. You would then simply need to change the convert_servo_cmd_to_pulse_arr function to use the factor to convert to the right pulse...

But I could be complete off....

Kurt

Xan · **Posted:** Tue Jun 17, 2008 6:55 am

Hi Jim, Kurt,

kurte wrote:

Robot Dude wrote:

The SSC-32 isn't really true open source. The code has been made available, but no one has ever submitted any modified code for the product. The original SSC-32 (mega8) limitation wasn't in processor cycles but in code and variable space. The new mega168 version may be able to do this. I will ask Mike to get his opinion.

I have thought about playing with the SSC-32 source code, but have not yet as I do not have codevision AVR. All of my AVR C programming has been with WinAVR.

But taking a quick look at the code, I don't think it would be very difficult to add some simple scalling to the code. You could add a command to enter the 90 and -90 degree values in the same way as Zenta did with a command like the Offset command. You would then simply need to change the convert_servo_cmd_to_pulse_arr function to use the factor to convert to the right pulse...

But I could be complete off....

Kurt

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

kurte · **Joined:** Sat Apr 15, 2006 1:42 pm **Posts:** 2191

Hi Xan,

I am not sure if there is a phoenix kit yet that includes electronics? But I am pretty sure that all new SSC-32 are the new mega168s and I think they come with: 2-01XE.abl installed on them.

I decided to pay the $220 purchase the codevision C compiler, just received the confirmation email so I can unzip the files...

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...

Robot Dude · **Posted:** Tue Jun 17, 2008 8:36 am

Xan wrote:

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.

Robot Dude · **Posted:** Tue Jun 17, 2008 8:47 am

kurte wrote:

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 · **Posted:** Tue Jun 17, 2008 9:35 am

Robot Dude wrote:

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 wrote:

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 · **Joined:** Sat Apr 15, 2006 1:42 pm **Posts:** 2191

Robot Dude wrote:

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 · **Posted:** Tue Jun 24, 2008 3:27 am

Hi all,

Yesterday I received a box that had â€œLynxmotionâ€

Robot Dude · **Posted:** Tue Jun 24, 2008 8:38 am

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.

http://www.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 · **Posted:** Tue Jun 24, 2008 1:41 pm

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.. :roll:

Hopefully you'll figure it out!

Have a nice trip!

Xan · **Posted:** Wed Jun 25, 2008 5:33 am

Hi Jim,

Robot Dude wrote:

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.

Code:

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 wrote:

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.

http://www.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 wrote:

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

Thanks, it is on his way!

Hi Zenta,

zenta wrote:

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.. :roll:

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 :twisted:

But I still need to figure out how to make the synchronization part faster. Maybe Iâ€™ll think that over on the beach

Here is the latest video, sry for the bad light, I was in a hurry
http://www.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 · **Posted:** Wed Jun 25, 2008 6:22 am

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:

Code:

  ;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:

Code:

;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!!!

Good luck,

Xan

plingboot · **Posted:** Wed Jun 25, 2008 8:04 am

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.

Lynxmotion Tech Support

BlackWido

Who is online