SSC NG (NextGen)

[linuxguy]

@miked

My vision for this is not a super bot board, but rather a super servo controller that also happens to be a pretty good bot board. I think most of your comments are leaning in this direction as well.

I definitely think this is as it should be. The SSC-NG should be a PWM/Servo controller first, and then have other capabilities if there is room for the code and such.

@miked

For the SSC-NG I will most likely switch to the GCC toolchain, and provide a library for GCC. My platform of choice is Windows (sorry linuxguy), but I don’t think that would prevent anybody from using the servo control library in a linux-based setup with GCC.

Switching to GCC is an excellent move! As long as the development environment and source code for the libraries are compatible, I don’t see why development could not be done under Linux also for those of us who use Linux regularly. You should be able to develop under Windows and with very few changes we should also be able to build under Linux.

One thing I hope you will seriously consider is making the I2C and SPI buses available for use from the outside. I would hope for I2C and SPI master/slave capability. having a PWM/Servo controller usable with I2C and SPI would be very nice, not to mention way cool.

I am thinking that with an SSC-NG capable of supporting I2C as a master, it might be used to also control things like Open Servos, and as a slave it could be controlled via I2C in a manner similar to a multi-servo Open Servo.

You would definitely have the most useful and full featured PWM/Servo controller on the market with such capabilities, at least from my perspective. I think others would quickly find use for such capabilities also. I believe such capabilities are highly desirable.

8-Dale

[miked-6]

Since the processor on the SSC-NG is surface mount, I plan to provide a 6-pin (standard AVR) programming header. The SPI clock and data pins will be brought to this header, but no chip/slave select pins. If there is room I will have a separate SPI header with the slave select pin.

I also plan to bring the I2C lines to a separate header if there is room. Based on firmware, it could act as an I2C master or slave. If I have to choose between I2C and SPI, I will choose I2C because I think it is more useful for this purpose. (Please comment if you feel otherwise.)

On the topic of data links, the processors I am considering have 2 UARTs, so the TTL and RS232 asynchronous ports will be separate, and can be used at the same time and at different Baud rates. I don’t know yet if this will be useful, but that is how I am planning to connect it.

Something I forgot to mention before on A/D inputs. The SSC-32 actually has a 10-bit A/D, but only returns 8 bits. There are 2 reasons for this. First, I wanted to return a single byte from a query. Second, A/D converters on most microcontrollers don’t have accuracy to match their resolution. The 2 least significant bits are usually lost to noise anyway. The 8-bit A/D results are taken from 10-bit readings run through a software low-pass filter and then truncated to 8 bits. It’s only 8 bits, but they are 8 good bits. There would be nothing preventing me from returning 10-bit values on the SSC-NG, but of course the software interface would need to be different.

So that brings me to a question–backwards compatability in the software interface. How important is it that the interface exactly match the SSC-32? Would it be OK if the analog voltage query commands started returning 2 bytes, for example? Or even returned a value in ASCII? The software interface development is a ways off, but I would like to know the answers to these basic questions before I start working on it.

BTW, I started calling the product SSC-NG instead of SSC-24 because I don’t think it will have only 24 I/Os. In some early discussions with Jim it seemed like it might have that limit, but my current plans are to have 32 I/O points just like the SSC-32. To make the I/O more generally useful, I will (try to) use switchable VServo/5V supplies for some of the I/O banks (similar to the MiniABB). The ABCD inputs will disappear, replaced by analog-capable I/O pins in the main I/O set. The Baud inputs will probably also disappear, replaced by a software mechanism for setting Baud rate.

Thanks again for the comments.

Mike

[zoomkat]

Just some other thoughts, I’d keep the bank concept for the I/O lines such that there would still have the byte out and also a byte input on an eight pin bank. This would make communication with the inexpensive eight bit based chips easy. As long as the rs232 inputs are ascii character based, I’d also add an additional ascii character as a command start byte. I found that the # will not travel well in an http query_string for web control setups. Having another character like an * might make communication thru web server chips like siteplayer easer.

[linuxguy]

@miked

I also plan to bring the I2C lines to a separate header if there is room. Based on firmware, it could act as an I2C master or slave. If I have to choose between I2C and SPI, I will choose I2C because I think it is more useful for this purpose. (Please comment if you feel otherwise.)

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.

@miked

On the topic of data links, the processors I am considering have 2 UARTs, so the TTL and RS232 asynchronous ports will be separate, and can be used at the same time and at different Baud rates. I don’t know yet if this will be useful, but that is how I am planning to connect it.

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.

@miked

Something I forgot to mention before on A/D inputs. The SSC-32 actually has a 10-bit A/D, but only returns 8 bits. There are 2 reasons for this. First, I wanted to return a single byte from a query. Second, A/D converters on most microcontrollers don’t have accuracy to match their resolution. The 2 least significant bits are usually lost to noise anyway. The 8-bit A/D results are taken from 10-bit readings run through a software low-pass filter and then truncated to 8 bits. It’s only 8 bits, but they are 8 good bits. There would be nothing preventing me from returning 10-bit values on the SSC-NG, but of course the software interface would need to be different.

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.

@miked

To make the I/O more generally useful, I will (try to) use switchable VServo/5V supplies for some of the I/O banks (similar to the MiniABB). The ABCD inputs will disappear, replaced by analog-capable I/O pins in the main I/O set. The Baud inputs will probably also disappear, replaced by a software mechanism for setting Baud rate.

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.

8-Dale

[wayne]

SSC NG it is, hey Mike what about SSC NextGen instead ?

Something I forgot to mention before on A/D inputs. The SSC-32 actually has a 10-bit A/D, but only returns 8 bits. There are 2 reasons for this. First, I wanted to return a single byte from a query. Second, A/D converters on most microcontrollers don’t have accuracy to match their resolution. The 2 least significant bits are usually lost to noise anyway. The 8-bit A/D results are taken from 10-bit readings run through a software low-pass filter and then truncated to 8 bits. It’s only 8 bits, but they are 8 good bits. There would be nothing preventing me from returning 10-bit values on the SSC-NG, but of course the software interface would need to be different.

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.

So that brings me to a question–backwards compatability in the software interface. How important is it that the interface exactly match the SSC-32? Would it be OK if the analog voltage query commands started returning 2 bytes, for example? Or even returned a value in ASCII? The software interface development is a ways off, but I would like to know the answers to these basic questions before I start working on it.

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.

The ABCD inputs will disappear, replaced by analog-capable I/O pins in the main I/O set.

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 ?

[zoomkat]

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?

[acidtech]

@miked

So that brings me to a question–backwards compatability in the software interface. How important is it that the interface exactly match the SSC-32?

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.

[linuxguy]

@Acidtech

The command set on SSC-NG becomes a superset of SSC-32.

I agree totally. This would be the perfect setup and would allow ALL existing software to run with the SSC-NG as well as SSC-32.

8-Dale

[robotdude]

@zoomkat

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?

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.

[robotdude]

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.

[sn96]

Ok I give up…

What does “NG” stand for in the name SSC-NG?

[snailkeeper]

The “NG” stands for “Next Gen”.

[wayne]

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.

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.

[robotdude]

@Snailkeeper (Admin)

The “NG” stands for “Next Gen”.

Then after that will come the SSC-Deep Space 9, lol

[wowy7]

@Robot Dude

@Snailkeeper (Admin)

The “NG” stands for “Next Gen”.

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

[linuxguy]

@Robot Dude

Then after that will come the SSC-Deep Space 9, lol

No, no, no, this would require calling the new version of the SSC, the SSC-TNG… Gotcha!

8-Dale

[spacejunk]

Pro version!

[sn96]

Yeah! SSC32-PRO

 Professional Robotic Output! Yeeee Haaawwww!  :stuck_out_tongue:  :laughing:

[italian_guy299]

I didnt realise NG was speceified in the topic title. Now I get it…

SSC-32 PRO!

[miked-6]

@Robot Dude

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

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