SSC NG (NextGen)

[wayne]

Hello Mike

Not to pin you down but do you have a rough estimate as to when this ssc24 will be available from lynxmotion or is it too early in the process ?

Just a wild question but I have to ask. Would it be possible to somehow double the analog inputs, not physically but by having 2 wires in each analog input and then switching between the ± pins of the analog channels and giving up some of the digital ports and using their ± for the additional 8 channels. To toggle back and forth between both sets of 8 analog, could their be a special pin say digital P9 that when High turns digital P0-P7 power on and Analog 0-7 off.

[miked-6]

My plate is pretty full right now, but I expect to get to the next generation servo controller this Fall. After I have layouts, parts list, firmware and prototypes, Jim still has work to do on testing, documentation, manufacturing, etc. I wouldn’t expect to see anything in the catalog before Spring 2008.

If I use a microcontroller with 8 A/D inputs, it will not be easy to multiplex those into 16 inputs. It would probably be more practical to choose a different micro or add an external A/D. There is an AVR with 16 A/D inputs, but it is in a 100-pin package that is a bit oversized for the purpose.

I’ll keep your request in mind, and invite other comments on what people would like to see (new or changed from the SSC-32) in the next generation servo controller. I can’t make any promises, because technical and cost considerations need to be factored in, but I’d like to hear what folks are looking for.

Mike

[km6vv]

How about a board with two MEGGA8, MEGGA168, etc. chips. One to run SSC32, the other would be a replacement for the Atom. C programming for both. Link could be RS-232 (or direct) selected by jumpers to also allow terminal control. Or even a nibble, SPI, or I2C interface between the two.

Alan KM6VV

I’ll keep your request in mind, and invite other comments on what people would like to see (new or changed from the SSC-32) in the next generation servo controller. I can’t make any promises, because technical and cost considerations need to be factored in, but I’d like to hear what folks are looking for.

[linuxguy]

@miked

There is an AVR with 16 A/D inputs, but it is in a 100-pin package that is a bit oversized for the purpose.

Would that chip be the Atmega2560?

How much larger would the board have to be to use this chip?

8-Dale

[linuxguy]

@KM6VV

How about a board with two MEGGA8, MEGGA168, etc. chips. One to run SSC32, the other would be a replacement for the Atom. C programming for both. Link could be RS-232 (or direct) selected by jumpers to also allow terminal control. Or even a nibble, SPI, or I2C interface between the two.

From the sound of things, if the 100 pin Atmega chip is a bit oversized, then this would probably make the board way oversized.

It would be really cool to have a dual MCU Super Bot Board with all the nice three pin headers for sensors and servos. I don’t think making a replacement for the Atom chips would be an option though.

I wish I had training in schematic capture and board design. I can actually design circuitry, but when it comes to creating the schematic in CAD and designing the PCB for it, I fall far short in training and experience. It seems really difficult to find the appropriate part in the Eagle EDA libraries.

8-Dale

[km6vv]

I’m only familiar with a few ATmel MEGA chips. If I recall, the 8 and 168 are only about 28 pins? the 168 was supposed to be a drop-in for the 8, which is currently used. What’s the 100 pin chip?

You might check out Eagle, it will allow you to lay out small boards free.

Why not just compile code for an AVR chip instead of a BASIC Atom chip? Users could boot load different versions for different legs/control/etc.

Advanced users could use the AVR compiler (C or BASIC).

I can design boards, and with Eagle, I can lay them out myself at home. At work we have Altium, I’m starting to use it as well. But I have a few projects ahead of that one! Currently I’m working on a PIC18F4550 chip to drive an SSC-32.

Alan KM6VV

From the sound of things, if the 100 pin Atmega chip is a bit oversized, then this would probably make the board way oversized.

It would be really cool to have a dual MCU Super Bot Board with all the nice three pin headers for sensors and servos. I don’t think making a replacement for the Atom chips would be an option though.

I wish I had training in schematic capture and board design. I can actually design circuitry, but when it comes to creating the schematic in CAD and designing the PCB for it, I fall far short in training and experience. It seems really difficult to find the appropriate part in the Eagle EDA libraries.

8-Dale

[miked-6]

The 100-pin chip is indeed an ATmega2560 (or ATmega1280). I meant “oversized” as much in the sense of overkill than physically too large. I want to make the board routable on 2 layers, and minimize the bill-of-materials cost. That’s not to say I wouldn’t use one of these chips, but they would chew up more real estate and add to the cost, so the benefit would need to be compelling.

I like the idea of a board that is C-programmable (or Basic using BascomAVR, etc.) I want to provide a C library that handles the servo movement, so others could write high-level control code, combine it with the servo control library, and load the whole thing onto the AVR. The servo library would take over a timer and its interrupts for servo control. The main code would need to call an update function in the servo library at least once every 20ms, and would need to avoid blocking interrupts or using long interrupt service routines. Servo updates use less than half of the CPU cycles, so there would be >50% of a powerful CPU available for high-level control. Any I/O unused for servo control would be available for use by the main code.

Well, that’s my dream anyway.

BTW, I highly recommend Eagle. There is quite a learning curve, but it is so powerful once you learn it. It’s free for personal use, and quite inexpensive for the commercial license for small 2-layer boards.

Mike

[km6vv]

The 100-pin chip is indeed an ATmega2560 (or ATmega1280). I meant “oversized” as much in the sense of overkill than physically too large. I want to make the board routable on 2 layers, and minimize the bill-of-materials cost. That’s not to say I wouldn’t use one of these chips, but they would chew up more real estate and add to the cost, so the benefit would need to be compelling.

Is it that big? As a surface mount part (it’s probably ONLY available as a surface mount part) I’d use at least 4 layers. That leaves out isolation routing on my Sherline mill!

I don’t think you can have too much processing power if you’re going to both keep the servos updated and do gait generation AND maybe some navigation!

I want to provide a C library that handles the servo movement, so others could write high-level control code, combine it with the servo control library, and load the whole thing onto the AVR. The servo library would take over a timer and its interrupts for servo control. The main code would need to call an update function in the servo library at least once every 20ms, and would need to avoid blocking interrupts or using long interrupt service routines.

That’ll be a nice way to handle it. But how many C libraries are cross-compiler portable? The C source code might be, or pretty close.

Going from an imbedded BASIC to C can be a pain! The old vanilla BASIC wasn’t to bad, but some of these “special” constructs have me scratching my head! I might have to get a Stamp just to prove out what I THINK some combinations of Boolean and integer calculations should do! And the use of min/max is DEFINITELY not what I normally have my min/max MARCOS do! I much prefer working in floating point, with full sin/cos/acos/etc. functions!

Getting there is still MOST of the fun! 'Tho I do have a young nephew who’s REALLY going to be in for a shock when he first sees the 'bot walking across the floor to meet him! My boys will really appreciate it too.

Alan KM6VV

[linuxguy]

@miked

The 100-pin chip is indeed an ATmega2560 (or ATmega1280). I meant “oversized” as much in the sense of overkill than physically too large. I want to make the board routable on 2 layers, and minimize the bill-of-materials cost. That’s not to say I wouldn’t use one of these chips, but they would chew up more real estate and add to the cost, so the benefit would need to be compelling.

Personally, I really don’t think there is such a thing as overkill as far as capabilities and computing power goes. There simply is no such thing as a processor or MCU that is too fast or has too much memory (or flash). It would be great to have a board that has 16 analog inputs and still has plenty of I/O for servos and sensors. However, I think that might be getting into the area of a super bot board and is not appropriate for a board designed to be the best PWM controller it can be. Being able to have 16 full resolution 10 bit analog ports would be very welcome, even on an SSC-24. I would love to use such a PWM controller in an eight legged multipod one day. I say “PWM controller” when referencing the SSC-24 or SSC-32 because PWM can be used to do more than just control servos.

@miked

I like the idea of a board that is C-programmable (or Basic using BascomAVR, etc.) I want to provide a C library that handles the servo movement, so others could write high-level control code, combine it with the servo control library, and load the whole thing onto the AVR.

I would very much like to have such a board, which just one reason I am moving gradually away from using modules like the Atoms. One big reason is I can get other chips (AVRs and PICS specifically) for a lot less money and it won’t hurt as much if I fry one.

@miked

The servo library would take over a timer and its interrupts for servo control. The main code would need to call an update function in the servo library at least once every 20ms, and would need to avoid blocking interrupts or using long interrupt service routines. Servo updates use less than half of the CPU cycles, so there would be >50% of a powerful CPU available for high-level control. Any I/O unused for servo control would be available for use by the main code.

This would be wonderful to have. However, I think if such a PWM controller were created and made available to us here and other places, a lot of software and libraries would be created for it. One thing I would like to see for such a board is that it be programmable using Open Source tools such as GCC, including under Linux. I would stand in line for such a PWM controller or super bot board.

@miked

BTW, I highly recommend Eagle. There is quite a learning curve, but it is so powerful once you learn it. It’s free for personal use, and quite inexpensive for the commercial license for small 2-layer boards.

I really need to start spending time learning Eagle. I have it installed and have loaded as many part libraries as I can find that are applicable to what I want to do. I would love to tinker with the design of the Mini Atom Bot Board if I had schematic files I could load into Eagle and manipulate. I could come up with a design for a super bot board if I had something like that to start out with.

My last wish for such a PWM controller, but probably more suitable for a super bot board, would be at least two sockest for EEPROM as well as a socket for an optional DSP chip that could be accessed and used by the main MCU as needed.

So, now you know my wishes for a PWM controller and/or super bot board.

8-Dale

[wayne]

linuxguy

I would very much like to have such a board, which just one reason I am moving gradually away from using modules like the Atoms.

I certainly agree with alot of what linuxguy has to say, being able to work on robotic projects that go beyond the abb/pro is the direction that I am looking at.

The ssc32 already has the fine servo and motor skills required, having an adequate number of analog/digital sensors for environmental awareness/interaction along with the processing power of onboard computers (that seem to be getting smaller and portable enough) will make the ssc24 the future board of choice.

[linuxguy]

@wayne

The ssc32 already has the fine servo and motor skills required, having an adequate number of analog/digital sensors for environmental awareness/interaction along with the processing power of onboard computers (that seem to be getting smaller and portable enough) will make the ssc24 the future board of choice.

I don’t think a single board with everything on it that’s needed to run a robot is necessarily the best solution. I actually prefer the component approach best because it gives me more flexibility. I would rather see the SSC-24 be the best PWM controller it possibly can be, with perhaps 8 or 16 full resolution 10 but analog ports.

I would put all the number crunching and control circuitry on a separate super bot board (mini abb on steroids). I would rather deal with the wiring for power and control cables this approach requires rather than be stuck with a single board that has perhaps what many people require, but not really what I want in all respects. Give me powerful components I can put together to create the solution I need, and I’ll most likely be quite happy to use them.

8-Dale

[wayne]

…cut… I would rather see the SSC-24 be the best PWM controller it possibly can be, with perhaps 8 or 16 full resolution 10 but analog ports.
I would put all the number crunching and control circuitry on a separate super bot board (mini abb on steroids)…cut…

Yes I agree that the ssc24 should not be limited by an MPU and let the abb do this for its mobile robots.

I actually like this approach that you are suggesting. Have the ssc24 with servo/motor/ample analog channels for what it does best.

This would allow flexibility and compatibility for several types of control such as from the abb, a tethered computer or an onboard portable style computer, now that we have more powerful motors and sabertooth to carry everything.

My desire for more analog inputs is my own view of how robotics in the next several years will have to provide more than just mobility but awareness of the immediate environment with such things as pressure, touch, temperature, etc.

.

[zoomkat]

I’d suggest that for extensive analog input needs, a seprerate chip be programmed for this use. I would assume the cost of the suggested ssc24 design will be higher than the current ssc32 price, along with increased physical size. Just make an analog chip that has compatable communication protocol with the current ssc32. The next request will probably be for 10/12 bit resolution instead of the current 8 bit. Putting special needs into a single chip may drive up the cost such that the average user will move to other brands of servo controller boards that are already less expensive.

[wayne]

Hi zoomcat

The next request will probably be for 10/12 bit resolution instead of the current 8 bit

For me 8 bit is ok because it seems like even at this resolution, when you are having other servos/motors react to the analog data, the reacting devices lag significantly behind the incoming analog data. So a higher 10 bit analog resolution does not help at least for pressure sensors.

I like your idea of an addon analog board allowing expansion.

[miked-6]

Wow, lot’s of good discussion! I’ll try to address a few of the comments here.

The size and mounting arrangement of the SSC-NG (next generation) will be identical to the current SSC-32, and the electrical connections will be as close as possible. This will be very important to Jim, so he doesn’t need to re-design his products to support the new board. This means that whatever design I go with will need to fit in the same space as the current design.

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.

Although technically the SSC-NG will be a PWM controller, it will be very constrained in the types of PWM signals it can produce. Some of the I/O will be directly connected to timer output pins, and will be very flexible in producing PWM output signals, but most will be connected to A/D or GPIO pins and will only be able to output servo-like pulses (low frequency, limited range of pulse widths).

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.

Overall, I am trying to make this the most capable servo controller/bot board I can, while meeting the design and cost constraints that will make it practical for Jim to manufacture and sell. Thanks for all your comments and suggestions!

Mike

[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 ?