I am probably not the best person to answer electronics questions, as I am more of a software type of guy. However I will give it a shot.
The SSC-32 can control up to 32 servos, plus it has 4 IO bits plus communcation to a host, which is pretty good for a microcontroller ATMega168 that only has 28 pins and that is including pins for other things like power, ground, etc.
So how do do that? One way is with shift registers. I believe these shift registers are using a protocol called Serial Peripherial Interface (SPI) I am generalizing as I have not studied the SSC-32 code or the chips in awhile. But basically what happens is the code: will choose one of the 4 banks of 8 IO pins to update. It will then serialize a byte containing the IO state of the 8 pins, by setting the MOSI pin to the value of one pin and then pulse the SCK pin and then do the next bit… He is probably using the hardware of the Atmega processor to do this work. Once the 8 bits have been serialized out to all 4 shift registers (as they are all connected to each other), he would then pulse the chip select for the chip associated with the bank he is updating, which would latch in this value to the 8 output bits.
Another way you can wire these shift registers in is to cascade them. For example if these 4 were cascaded to each other by I think using QH* pin of one chip as the SER pin of the next chip in line) you could output all 32 bits of data and with the chip selects latch all 32 bits of data at once.
I hope some of this makes sense. If not one of the more hardware savvy members should probably correct this.
From Mike explaination, when 2 pulses are closer to each other, the minimum pulse time between them is 1.49us? So the resolution of 1us is not correct when 2 or more pulses are close to each other?
That’s the way I’d read it. Perhaps Mike can explain more. Or the newer 168 code may have improved specs. I failed to mention that this is from a year or two ago (previous AVR)
Most of the problem (and challenge) for high resolution PWM is when there are 2 or more pulses very close to each other. Imagine 8 pulses which are very close to each other, we will have error of 4us. But still, that is very impressive.
Pretty good description for not being the best person to ask. This not what I expected however. Given that each shift register is, in effect, managing one servo I expected each output pin to be emitting a PWM signal. It sounds like this is not the case though. Does that mean that the Atmega is updating the shift registers multiple times per second?
Hi Alan. Thanks for the info but I have to admit that, at least for the moment, it is a little above my head. I’m sure it will make more sense as learn more though.
I didn’t know that SSC-32 is an open source project. I’m not even aware of such electronic component as shift register. I first saw the pulse out signal of SSC-32 from someone in this forum, was really impress with it. Couldn’t figure out how it was done.
If I have know it earlier… Anyway, I peaked inside the source code, looked so alien to me.
Edit: It looks like my previous reply got completely mess up at the server so I will try a quick retry:
I am a software guy, but I did have a few electronics and microprocessor design classes back in college, but that was a long long time ago.
About 4 years ago I built the Seattle Robotics Society workshop robot, including level 2 and level 3. They had an add on board that I assembled (which was the first time I soldered SMT type components). This board had two sets of shift registers. 2 were of the type that we are discussing and the other two were used to bring inputs back from a set of buttons and the like. I then wrote the code for an Atmega32 that used SPI to interface to all of the components on this board. So I have had some experience with this chip.
Each of these shift registers do control 8 servo outputs. For example: U4’s outputs (QA-QH) connect up to the external connectors on J1-A and J2-A and handle the servos 0-7.
The SPI interface can easily update the latches many times a second. The SPI can change the state of the clk line as fast as every 2 clock cycles, so a full byte can be output in 32 clocks which if the processor runs at 16mhz or so it can do quite a few outputs.
On the SSC-32 the code calculates the start and stop times of each pulse and then when the transistion times come up it simply updates the byte associated with that servo. The code can be pretty accurate as it could send down the next transistion byte ahead of time and then when the next transisition time comes it simply has to toggle the chip select on the appropriate byte and then calculate which byte will need to be updated next and down load it…
IE that is what takes the RS232 level signals that come from the host and converts it to TTL level (0 and 5v) that the microprocessor (ATMega) uses. In other threads you will see mention of other chips that do this like a MAX232…
Wow! A lot of responses to this thread. The SSC32 (at least the 1st version) is open source. You’ll need a CodeView compiler to compile it.
It’s a very complex program, that works in layers. Very tightly coded, and “tweaked” to get the best response times. Not code for a first project, or the timid. It would be difficult to port to another processor. Update algorithms closely tied to the Atmel timer architecture.
SPI and the shift registers can easily work at 10 mHz, although they’re not running that fast here.
The SSC-32 firmware was made open source in an effort to allow users to make and share different “flavors” of firmware for the hardware we sell. The hardware has never been open source and copying it is strictly forbidden. We do not promote, encourage, or allow people to copy the hardware or cross the firmware to other processors. Hope this clears up any questions concerning the SSC-32 hardware and firmware.
Thanks for the info that really helps. Just to be sure I understand let me plug this into the bigger picture. Correct me if I go astray.
Ultimately our goal is to control servos. If we were to interface a servo directly with our microcontroller then we would generate a square wave by pulling the logic pin high for a period of time and then low for a period of time. The amount of time it is high relative to how long it is low directs the servo to move a specific position.
The number of servos we can directly interface with our microcontroller is limited by the number of GPIO pins available (or is the limitation a result of the number of pins that can do digital out?). Placing the serial-in/parallel-out shift register into the circuit allows the microcontroller to interface with additional servos. The microcontroller still generates the square wave for each servo but instead of sending it directly to the servo it loads it into the shift register memory and instructs the shift register to change the state of it’s output pins (i.e. move the data from memory to the output pins) at the appropriate time. The fact that we’re working at such a rapid pace has the added benefit that different square waves can be generated for different servos simultaneously.
For anyone else trying understand this there is an article on interfacing a shift register with an Arduino on the Arduino site: arduino.cc/en/Tutorial/ShiftOut
Obviously my assumption as to why the circuit design is in the manual was wrong. I’m curious as to why it’s there (please don’t take this the wrong way I am new to the electronics world and am truly curious). I have to say I find this position surprising given the success of open platforms like the arduino but then I think the SSC-32 has been around longer so it kind of makes sense. Ultimately that’s your business decision, I don’t mean to question it I’m just taken back. You don’t need to worry about me copying the design as I am only interested in it from an academic perspective as I originally stated.
No offense intended Jim. Which is why I never thought of asking any question of SSC-32 architecture. If I need the SSC-32, it is only fair if I bought it directly, the credit should go to LM. The cost of self-prototyping isn’t worth it also, even with the schematic and source code available.
Arduino is only a dummy circuit, like some demo, starter, prototyping kit for developers. There isn’t any logic and source code available for something as complex and succesful as SSC-32.
The truth is I paid dearly for the complete development of the SSC-32. It was designed exactly to my specifications. Everything from the group move command down to the GP sequencer and 12 servo hexapod sequencer. It was decided to make the firmware open source but with the exceptions listed. It never went anywhere. At this point I question why we continue to make the source code available. All it’s truly done is make me look like an ass when I tell people they can’t port my code to their processor, or make their own SSC-32.
We give away so much information, and we have done our best to promote robotics and educate new and old robot builders alike. Hell I can remember even 5 years ago when I was searching the net for IK solutions for the arms and legs. There was nothing available, period. Now we have three unique solutions in our projects section alone, plus Laurent and Jeroen’s Atom Pro code is all available on a silver platter for anyone looking. I have paid for them as well, but give them away freely.
The schematic for the SSC-32 is included so people can see what is going on under the hood. It’s a courtesy to our customers. If it answers questions then the phone may not ring as much. I hope this explains a bit as to why things are the way they are.
And being the repository of code and designs and SES parts etc. Draws customers.
They may start out wanting to simply experiment with the SSC32 on their own processor, but before you know it, they’re buying a Thousand dollars worth of parts! Good for business, I think.
There STILL isn’t a similar controller targeted EXACTLY at what is needed to control a mass of R/C servos the way the SSC32 does! Maybe something at well over $100, but it’s not competitive, or as complete.
I was introduced to IK on this list, I’d only done CNC machine controllers before. And I probably wouldn’t have thought to try IK without the introduction to a solution to be found on this list.
I wouldn’t worry too much about others copying your products. They’ve all been out for a while, and no one has a solution that even comes close!
Idea: You might think about how you could provide a “custom bracket” shop. I’ll bet others might be able to dream up a bracket, but can’t make it. I don’t know how viable a service it could be, just an idea.
And with the development of SES parts to replace the plastic, well, I’m hooked!
I really don’t know much about the engineer behind the ssc-32, but I know that the output compare register in the Atmega chips is OCCR not TCCR. OCCR is up to Out put compare register while TCCR is for Timer control register.
This not what I expected however. Given that each shift register is, in effect, managing one servo I expected each output pin to be emitting a PWM signal. It sounds like this is not the case though. Does that mean that the Atmega is updating the shift registers multiple times per second?
