I’m working on a senior project at my university, and I’m planning on buying this board to control my robot. My robot will be bipedal, similar to some of the kits on the website. The robot will have sensors on its feet to tell if it has ran into an object and needs to walk over it. The robot will be controlled by a PC. Would I be able to read the inputs from the SSC-32 (fast enough) and stop the servos from their current movement once the sensors have been activated?
I’ve read the manual, and some similar posts on the forums but I wanted to make sure I would be able to do this.
Also, how fast would my program be able to query different inputs from the board?
Also has anyone engineered an easy way to get more inputs to the board? Maybe a multiplexer?
Be sure to post pictures of your project for all to enjoy.
The ssc32 currently does 4 analog inputs, other threads in this forum have several suggestions for increasing inputs but require some work and electronic knowledge beyond the basic board setup.
Fortunately there is a ssc32 NG in the works which will have additional inputs. I seem to remember 8 analog and possibly some digital.
Mike how many are there going to be ?
Mike has also mentioned a multipler board being considered. I do not know where he is at with this.
There are several things that will affect the turnaround time from sensors to servos.
Delays in the sensors and servos themselves
Delays in the SSC-32 firmware
Delays in communication
Delays in the PC software
I can’t address the first and last, but can comment on the other two.
The SSC-32 performs some filtering on the analog inputs and debouncing on digital inputs, which will add about 5 milliseconds of delay for analog inputs and 15ms for digital inputs.
The SSC-32 will begin to respond to a query command within 100us or so of receiving the last character of the command, so that is insignificant.
The biggest delay in the SSC-32 firmware will be in responding to a servo move command. The delay could be up to 30ms from receiving the last character of a command to when the new servo pulse width appears on the output. Most of this is due to the fact that the SSC-32 outputs pulses on a fixed schedule every 20ms. The worst-case delay depends on which servo. Servos 0-7 are output first and have the least delay (up to about 23ms). Servos 8-15 are next with up to 25ms, then servos 16-23 with up to 28ms, and finally 24-31 with up to 30ms delay. Average case delays will be less than this.
The other source of delays is in communication. On the SSC-32 end you have some control over this. If you select a Baud rate of 115.2kBaud, each byte transmitted will take 87us. You can set the transmit delay and pacing to 0 and get minimum delay in SSC-32 responses (typically less than 10us per byte). If using ASCII commands, omit unnecessary spaces; or use binary commands for max speed if you don’t need timed moves.
The above figures all apply to the new ATmega168 firmware that is shipping in new boards. The older firmware was 10 to 20ms slower to respond to servo move commands, and had fixed transmit delay and pacing of 600us (delay before sending first byte) and 70us (pacing delay between bytes).
The SSC-32 is light on inputs, and there is not really a good way to expand the number of inputs past 4. Like Wayne mentioned, there is a next-generation product in the works. It will have a total of 20 general-purpose I/O that can be inputs or outputs. Eight of the 20 I/O can be analog inputs. I have a prototype built up, but it is still a ways from production.
