Hmmm, you’d be a leg short there then, eh? 
You could always tell everyone it has a broken leg… 
I admit that 20 is kind of an odd number when it comes to multipods. This board would run a hexapond nicely though, without any help.
I think the proposed I/O expander is what you would add to this board for more features.
8-Dale
Thanks for the comments.
zoomkat, I will take these suggestions into account. The first prototype has AREF decoupled but not connected to any reference voltage. Software can select an internal 1.1V reference, internal 2.56V reference, or external AVCC (5V) reference. On the next iteration of the board I will try to find a place to put a header for an external AREF connection. The command string start character selection would be based on a configuration register setting rather than a physical jumper, but otherwise there should be no trouble supporting that.
linuxguy, I appreciate the feedback. If you get into AVRs I think you will like the architecture. I much prever AVR to old PIC, but the dsPIC/PIC24 is pretty nice, and has better performance. My biggest issue with dsPIC/PIC24 right now is lack of 5V support across most of the product line. In the hobby world, 5V is still important. I’ll check out the Acroname I2C connection scheme. Board space would be the issue in putting a “daisy chain” header for I2C, but I’ll see what I can manage. Master/slave select and such would be configured using EEPROM registers rather than physical jumpers.
Alan, yes this is more-or-less an ABB that will run 20 servos. With I/O expanders you will be able to get 24+ servos–the expander servos will act as though they are part of the base set, i.e. they will participate in group moves, etc. I am not certain what the max number of servos (including expander) will be, but at least 32. The ATmega644 will have plenty of time for this. The servo updates actually use only a modest fraction of the CPU time, much less than 50%. And the servo control for 32 servos only takes around 1K of RAM, out of the 4K available on the chip.
Mike
Oh, I will definitely be getting into AVRs. I wish I could get registered with AVRFreaks, but there is always a problem and I have no way to contact anyone there.
Here is the Acroname I2C Standard. I will be using this scheme to interconnect smart modules using I2C.
8-Dale
Hi Mike, Dale,
I’d prefer to see a CST-100 style polarized locking connector. The pin order is OK. Two connectors can be used for daisy chaining.
But I have another question. Will some sort of Atom BASIC be made to run on this board? Perhaps it’s already available for this AVR. C is fine with me.
Alan KM6VV
I doubt that there will be an Atom BASIC for this. I believe the Atom compiler is designed for PIC processors. There is at least one Basic compiler for the AVR (Bascom), but I suspect people who want to program in Basic will continue to use a Basic ATOM and Mini-ABB combination.
Yeah, kinda what I thought. How about a PIC instead? ;>)
Not having BASIC might limit it’s desirability to the majority of LM customers. Or encourage them to buy the CodeVision AVR compiler and learn C!
If the board is to be programmed in C, would you supply a LIB for some of the often-used devices? i.e. servos, PS2 controller, etc? Serial in/out should already be in LIB.
Let us know when it’s available; I’d be interested in one!
Alan KM6VV
Another suggestion might be a built in delay function between commands sent in a single command sequence. Something like below where servo (or digital output) would be sent to the 1000 position, then a 1000 ms delay, and then sent to the 2000 position. As an example, the below could be used to have a servo pull the trigger on an air gun or push the zoom button on a cam for 1 second then release the trigger/button. I’ve used similar delays in cgi programs used for controlling servos over the internet. This would allow the delay sequence to be handled by the servo controller instead of by the software sending commands to the servo controller.
#0 P1000 *1000 #0 P2000
Sorry, no PICs allowed Actually I am fine with the dsPIC and PIC24 architectures, but don’t like the old PIC architecture.
I am planning to provide a (gcc) library for this board to make it easier to use for C programmers, and of course will have a canned SSC32-like application for those who want to use it as a serial slave.
I like the command delay idea for the new board. That would have been difficult to implement on the SSC32 because of the additional RAM required (that processor is stretched so thin that everything is difficult), but should be doable on the '644.
I’m just now getting to look at the DsPIC.
Great! A library and the alternative of a canned SSC32 should be plenty.
I’d also suggest LIBs for sensors like ultrasonics, IR, and compass; these could be “contributed” by developers. The C code should also be portable with a little care.
Alan KM6VV
Will there be a “bank” command where each pin in a bank of 8 pins can be set hi/lo as desired with a single command? In the past I’ve used the 74HCT259 8-bit latching chips with the eight parallel port data pins to have a lot of individually controlled output lines (~120). Having the bank command feature would allow for a simple and cheap DIY digital output expansion board.
Mike
Just to clarify for me. Will I still be able to use this new ssc32ng attached to my laptop computer in the same manner as now. ie cpu power is on a computer and functional ability is carried out by the ssc32 and the I/O expander.
I am concerned that this ssc32ng is turning into an enhanced Mini-ABB board and this on-board control processor will get in the way of the ssc32’s ability to control servos, motors and accept analog input from a laptop or on-board mini-computer.
AKA in industry as feature creep. 
If it can be used as a servo slave using the Mini-ABB and it has a dsPIC, I would want it for sure. It has the best of both worlds in this case and I would at least then try to learn C.
If you decide to go with a dsPIC, what package would you use? a DIP package, QFP, SOIC?
Sorry folks, I lost track of this thread over the holidays.
There will be a “bank” command of some sort. The current SSC-32 has that capability via serial commands. I am planning to keep the ability on the NG, but make it more flexible.
The “enhanced Mini-ABB” aspect ot the NG is a result of my desire to have, well, an enhanced Mini-ABB for my own use (C-programmable, of course). But that doesn’t mean that it cannot also function as an enhanced SSC-32 as well. It’s just a matter of loading the appropriate firmware. I expect that the default firmware will be SSC-32 emulation with extensions to take advantage of additional A/D inputs, bi-directional I/O, etc. So you will definitely be able to use the NG as a slave, with your computer providing the main CPU power.
The current design uses an ATmega644, and I will probably stick with the AVR. Learning curve and inertia, you know. I have a lot invested in learning the tool set for AVR development. (But I am going to keep a close eye on the new 32-bit PICs.)
Whatever processor I use will be SMT, most likely a TQFP of similar. BGA and MLF are too difficult to prototype, and DIP is too large and bad for automated production. The processor will also be a 5V part, since I think 5V support is still important in the hobby electronics world.
Mike
20 servos is ideal, perfect for a hexapod, 18 for the legs, 2 for a Pan-tilt camera setup.
24 for an Octapod’s 3DOF legs, 6 for an arm with 2DOF gripper, 2 left over.
8-Dale
I hate to advertise vaporware, but eventually the SSC-NG will have a solution for your 24 servos. There will be an I/O expander board with 8 I/O points that can be connected to the SSC-NG. Current plan is that each I/O expander will use one of the 20 I/O points on the main board, but provide 8 new I/O, for a net gain of 7 I/O. At least 2, and probably up to 4, I/O expanders will be supported.
The nice thing is that the SSC-NG will be able to use I/O expander ports for servo group moves as though they were on the main board. The SSC-NG will support up to 32 servos, and will have registers to map servo number (0-31) to any port pin on the main board or a pin on one of the connected I/O expanders. Once the mapping is set up, this will be transparent to the user.
Bear in mind that this is the long-term vision. Right now I am just trying to get the prototype SSC-NG board up and running with a “new and improved” bootloader, and the I/O expander has not even been laid out yet.
Mike
I just reread this thread after Jim Posted images of it up on the website.
This board is along the lines that I am very much interested in. I prefer to program in C and at one point I was just starting to convert the code for the HEX to C. The first project was for the PS2. The project is still in my todo list. I think I may instead start off with my Rover instead.
I was starting off with a Maveric 1B as it had lots of IO pins, JTAG and the like, but I wonder if I should wait for your board. Here is a picture of the Maveric, next to an ABB and also a SRS workshop board.
http://img519.imageshack.us/img519/1158/atmelboardski6.jpg
One thing I like about the other two boards is that they removed the big 9 pin connector from the board and connect them with a wire. The picture included the one from the SRS. The nice thing of removing it from the board is it gives you more space to add other things. The other is it easier to place the board on the robot and still make it easy to position the serial connector where it is easy to plug it in. Just an idea…
I have an older version of the Mavric IIB. It’s a nice board and if the I/O mix suits your needs there is no reason not to go with it for C programming.
Personally, I like the 3-pin (signal, V, GND) headers for servos and sensors. You never seem to have enough power and ground pins nearby otherwise. I guess that preference shows in the SSC-NG board.
One thing to note, the SSC-NG board does not have a JTAG header. The JTAG connections are not even brought to port pins–they are used for the buttons and LEDs. JTAG is nice but I didn’t have the free I/O or board space for it. I am generally inclined to use the serial port for debug anyway. Again, my personal preference shows up in the board design.
I am conflicted about that DB9 connector. It is clunky and not always needed, but the standard serial port is still the closest thing we have to a universal communication port. And it’s very inexpensive to put on the board.
A primary reason for this board’s existence (as a commercial product) is for servo control, as an enhanced SSC-32. (Fewer I/O, but functionally enhanced.) That also drives some of the design decisions.
Mike
I agree completely! It would be SO much nicer to be able to put the DB9 connector(s) where we want them, rather than have them permanently attached to the board. I would much rather have a header with a short cable that has the DB9 connector on it - MUCH more flexible for robot mounting. My BRAT is stuck with the DB9 coming out the side of the Bot Board II, rather than from the top where I would rather have it mounted.
8-Dale
