No one else bridged this topic, so I will. 8) Because RIOS and SEQ really only work with servo motor angles it might be possible to incorporate I2C, and HMI into the SSC-NG. How cool would it be to have a robot controlled from the SEQ program that has traditional servos, I2C servos, and Hitec HMI servos all behaving under the watchful eye of the SSC-NG. Hmm, maybe even AX-12…
Disclaimer, I dunno if this is even possible. 
Ok I give up…
What does “NG” stand for in the name SSC-NG? 
The “NG” stands for “Next Gen”. 
Hi zoomkat ( I apologize for quoting myself)
This was my suggestion too but I did not explain it very well or with enough detail as Jim has done.
I can see this style of interaction benefiting mobile robots as we move into the future.
Then after that will come the SSC-Deep Space 9, lol 
lol 
Well,make shore it says “SSC-Deep Space 9 Collectors Edition” on it in fine print
No, no, no, this would require calling the new version of the SSC, the SSC-TNG… Gotcha!
8-Dale
Pro version!
Yeah! SSC32-PRO
Professional Robotic Output! Yeeee Haaawwww! :stuck_out_tongue: :laughing:I didnt realise NG was speceified in the topic title. Now I get it…
SSC-32 PRO!
Scary idea Jim. But appealing. I2C and AX-12 don’t talk in terms of 500-2500 us pulses like traditional servos, so the position commands would need to be different. Maybe an angle command that would work with any servo:
“#0<90.0 #1<10.1 #63<179” and so forth. Angles 0-180 degrees with resolution 0.1 degree or so. The ‘<’ symbol is my shorthand for “angle”.
Servos would need to be configured to give the relationship between the angle and whatever “language” the servo talks in. Servos 0-31 would be the built-in set and would have a default linear mapping between angle and pulse width (but can be changed as desired). Servos 32-63 would be datalink connected servos, each of which could be configured to be I2C (Openservo), AX-12, or whatever. All servos could participate in group moves.
Ambitious. I don’t know what pitfalls would be lurking, but it would be nice if it worked.
Mike
Well, we know the Open Servo folks are integrating PWM control into their I2C based software designs, so it is workable. I’ve been thinking more along the lines of I2C that would control the SSC-NG, which could then control the servos via whatever means was best for the servo and/or application - I2C or PWM for Open Servo , PWM for regular analog servos, or maybe even HMI for those servos that have that option. This may not be possible within the code space available on the MCU that is finally used in the SSC-NG, but it would sure make one of the most useful controllers for advanced applications as well as the good old standard SSC-32 compatibility.
It would be very cool and very useful for many more applications that is possible now. Using I2C would not transmit as much information, since the commands would and should be byte/word oriented, but packing of the bytes should not be done. By this I mean, let the angles be sent as regular bytes such as 90, 180, etc, and the same with channel numbers - 0, 1, 2 … 32, etc.
Let the SSC-NG go where no servo controller has gone before…
8-Dale
To “Boldly go” that is… 8)
I’ve been doing some voltage checking on a standard servo, and notice that the supply voltage to the internal controller board from the pot is generally ~0.0v-2.0v (or ~2.47v-4.48v using the servo supply voltage as a reference) for full range rotation of the pot. If one wanted to make use of this output for position feed back, then the ssc-ng should have a reference voltage input for the analog inputs on the ssc-ng. Being able to get 8 bit resolution for the 0.0v to 2.0v range would make for a simple way to get fairly accurate actual position feedback from the servo.
edit:
looking at the schematic of the ssc-32, pin 21 (AREF) might could be used for the servo voltage reference input. It is currently tied to the board VCC providing 5.0v as the analog input (?) reference voltage. Connecting this input to the 2.0v servo pot input and connecting the servo pot output to the ssc32 analog input might well give ~8 bit position resolution from any standard servo. The servo would need to be opned and two small wires soldered to the pot and run to the outside of the servo for input to the ssc32.
Based on some previous discussions, I suggest for the new board: 1). make the AREF pin jumpered to the 5v source. Removing the jumper would allow any desired voltage (with in chip capability) to be used as the analog reference voltage, and 2). make the command string start character jumper selectable. With a jumper installed it could remain #, and with the jumper removed, it could be something like * or $. This would allow two ssc32 boards to be used on a single serial port, and the * and $ travel well in an HTTP query_string for easy web control of the board.
For the ATmega128 AREF voltage can be set through software at VCC or 2.56 v.
There could actually be three different versions of a servo move command.
#0 D90 #1 D-90 - Move a servo an absolute number of degrees from center position. 0 degrees would be center (1500 mS).
#5 R30 #7 R-45 - Move relative to current position for those servos that support position feedback. Read the current servo position and move relative to that.
#2 P1400 #4 P1900 - Move to an absolute position just like is done with standard PWM based servos now. This works with Open Servos now too! You can control an Open Servo with standard PWM and read status info back from it using I2C.
We already know there is a direct mapping between the number of degrees a servo goes and the pulse sent to it to actually move it. 90 degrees is 1500 + 900 mS and -90 degrees is 1500 - 900 mS, or maybe I have that reversed. So, just multiply the degrees * 10 and add or subtract that to/from 1500 to get your pulse length to move the servo.
If you have a couple configuration bits stored for each servo that can be set by the user, it should not matter what position on the SSC-NG the servo is connected, and Open Servos servos just need a place to connect to the I2C bus if they are being completely controlled via I2C or status info is being read back via I2C. The Open Servo folks have had noise problems with the I2C bus and longer cable runs, so this would have to be addressed too. You could be looking at a whole lot of connectors if you want to fully implement three or more different types of servo control… You might be able to squeeze two sets of 32 connectors onto an SSC-NG if you leave off the user LEDs, switches, buzzer, etc, but leaving off the buzzer would not be good. Switches and LEDs can easily be added externally and connected to PWM servo/sensor headers.
You might just want to keep the SSC-NG to PWM based servo control, which the SSC-32 does very well. Provide a connection for I2C, both for servos as well as communication with the SSC-NG in place of standard serial commands if desired. You can still send standard PWM servo position commands and configuration info to an SSC-NG using I2C, but would not need to send as much data. It would not be difficult to implement the current SSC-32 command set as an I2C command set also, including configuration commands and such.
8-Dale
I request a nice sneak peek of the new SSC-32NG Prototype Board.
Jim, remove he 5.0 megapixle camera off the try pod and mount a 10 megapixle camera!
Hi Mike,
I’d like to suggest a “HALT immediately” command for the SSC32. This command would stop all servos where they are (could be a group or single servo as well).
The user could then query to find out where the servos are.
If a user’s sensor detects a contact with an object. they’d be able to immediately stop the move of a leg or arm joint.
Alan KM6VV
The new M168 firmware has a STOP command that stops an individual servo in place, e.g. “STOP 0” will stop servo 0. I was not able to extend this to “all servos in a group move” because the SSC-32 doesn’t keep track of which servos are moving as part of which group move. There wasn’t enough RAM to track this.
The hexapod sequencer and the general purpose sequencer both have commands to halt a sequence in place.