I would vote for I2C if you have to make a choice between it and SPI. From what I have looked at, it seems that I2C has more potential for PWM/Servo control and is what the Open Servo folks have chosen. It seems easier to return status information via I2C. Also, from what I have experienced, it seems much easier to use I2C with the Atom chips, and I don’t know if SPI is even possible with them.
If one UART port can be used while the other is used to communicate with the host MCU, then I can definitely see a use for having them usable at the same time.
The SSC-NG should not be confined to only working well with 8 bit MCUs. There are many new 16 bit and 32 bit MCUs available reasonably inexpensively now. We now also have inexpensive Linux based embedded boards avaiable such as the NGW100 from Atmel which uses the 32 bit AVR7000 series chips. So, yes, please do return the full 10 bits of information from the analog ports or at least provide the option of getting the current 8 bits or full 10 bits of data. Returning 8 bits could be done exactly as it is with the SSC-32 now.
I believe you are definitely on the right track here, Mike. I like the direction you are heading with the new SSC-NG. I can definitely see possibilities for I2C here.
SSC NG it is, hey Mike what about SSC NextGen instead ?
I would like to see the 10 bit and have software massage the returning values, but do what is easiest.
8 bit still returns enough variation to work with.
If you stay with 8bit then you might as well return as a byte, keeping things the same.
If you feel 10bit will be the resolution people are looking for down the road then perhaps this would be the time to decide between bytes or an ascii character. I would prefer the ascii character over parsing 2 bytes but either way is ok.
The software interface does not have to be the same, you are offering more capabilities and features with a new board, software needs to evolve with you.
Thinking outloud… allowing the SSC NG to access its own healthy number of pressure sensors in both feet, arms and hand/fingers could compliment the SSC NG’s servo/motor movements.
How many analog inputs do you think could be possible ?
I think an appropriate question to ask is anybody actually using the four analog inputs on the current ssc32 for any application? If anybody is, then some real world feedback on the use and its relialibility would be nice. If anybody isn’t using them, then is there really a practical justification for adding more?
You shouldn’t have to worry about that. Just add a new command to the basic SCC-32 command set that lets you switch between backwards and advanced command version. You coul dget even sillier and make a lot of different options for backwards/advanced modes but the idea would still be the same. The command set on SSC-NG becomes a superset of SSC-32.
RIOS uses the A to D’s for gripper control. It actually allows the analog input to effect the flow of the sequence it is playing. You can start a sequence if the analog value goes above or below a certain value. You can even close the gripper servo until the analog voltage reaches a preset amount for instant gripper control. People are using the inputs on the SSC-32. Having 8 inputs would allow a hexapod robot to evenly distribute the weight of the robot to it’s 6 legs with two to spare.
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…
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.
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…
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.
We now also have inexpensive Linux based embedded boards avaiable such as the NGW100 from Atmel which uses the 32 bit AVR7000 series chips. So, yes, please do return the full 10 bits of information from the analog ports or at least provide the option of getting the current 8 bits or full 10 bits of data. Returning 8 bits could be done exactly as it is with the SSC-32 now.
Having 8 inputs would allow a hexapod robot to evenly distribute the weight of the robot to it’s 6 legs with two to spare.
