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
That is my biggest hangup with using the maveric board. Unless I feel like either breadboarding each of the IO pins, you end up having to make custom cables or the like. Which is a reason why I like your board.
I like being able to do both. It is nice to have JTAG available. I end up dong a lot of debugging by serial I/Os as well, but sometimes it is really nice to be able to single step and find the oops.
I also find having it on the board a mixed blessing. For example on the Rover, I would prefer to put the board somewhere inside the body, but thaqt makes it a pain to update. If the two were seperate, you could position the board where you want it and then independantly position the serial port somewhere easy to connect to, or if you don’t need it, remove it.
Anyway I also find it fun to work on these projects…
One thing also liked about the SRS (Arc 1.1 by Larry Barello) board was that the PC was setup to install connectors for all/most of the pins on the AVR processor. In his case it was not as difficult as there were only 40 pins. By default the boards did not have the connector installed, but they sure made it easier to connect jumpers or the like to breadboards or Oscilloscopes and to add daughter boards to add additional functionality:
For example here is the SRS workshop robot with a daughter board designed by Cathy Saxton. (I am glad the photo does not show my bad soldering as it was my first board with surface mount components…)
http://img182.imageshack.us/img182/264/dsc01353mh1.jpg
Again I will be one of the first ones to order them once they are available.
Edit: After looking at the Atmega644 it looks like it only has 40 pins (or 44 depending on packaging). So maybe it would not be so hard… Anyway I would be very interested. I can easily live without JTAG on the board. I could always order a 40pin Dip version of the chip and plug it into the STK500 and debug parts of it there…
Also do you do most of your development with the free compiler (WinAvr) or do you recommend purchasing the CodeVision compiler? So far I have used WinAVR…
I’ll talk w/Jim about the DB9 connector.
I used CodeVision for the SSC-32 development, but I am switching over to WinAVR for the NG.
Mike
Now that I have CodeVision, How about continuing to use it for projects. How different is it from WinAVR? Seems like a simple compile switch might take care of it.
NG is coming along!
Alan KM6VV
The majority of the code will be portable to either compiler. I will try to localize non-portable constructs such as
- Data in flash or EEPROM
- Assembly routines
- Interrupt service routines
In the SSC-32 I sprinkled assembly in the C code to save space, and reserved a set of registers for interrupts to reduce latency. These are both non-portable practices and I will try to avoid them in the NG library. Since I have CodeVision I can put compile flags around non-portable constructs and build two versions of the library. I don’t promise to do this, especially at first when I am just trying to get something out, but that will be my eventual goal.
There are two reasons for the switch to WinAVR. The main reason is that I am trying to make a general platform for people to develop C code for robots, and the cost of entry is much less with WinAVR. That was not really a goal for the SSC-32.
The other reason is that WinAVR is a better product than the avrgcc that was available a few years ago when I started working on the SSC-32 and other ATmega products. I kept having to work around bugs, and eventually I got tired of it and purchased CodeVision. (I have no interest in going into the compiler source and fixing problems.)
Of course, Linux users will give a third reason. WinAVR is just avrgcc, which runs on Linux. That lets them into the party. I want to include as many developers as possible. (I don’t know if there is a solution for Mac users.)
Mike
Ummmm, yes, I suppose we Linux users would like this better… I want as much of my development under Linux as I can manage. I’ve been able to spend much more time in Linux than Windows lately, and I like that very much. I only have to boot to Windows to work with the Basic Atom/Atom PRO and do 3D CAD now. 
8-Dale
That’s great. Always helps to start out early with multiple ports in mind.
Yes, I recall that the tough area of the ISR was coded in ASM. Hopefully there won’t be too much of that needed. EEPROM access shouldn’t be too bad.
The registers can make it hard! Flags will be a great help. Much appreciated.
Oh I can see that! And if the robot community can be supplied a detailed tutorial for getting WinAVR up and running (it can be quite hard to get GNU-type tools up and usable), it would greatly profit from it.
I’m sure it will please quite a few to be able to use Linux tools! Mac? I don’t know.
This could make a nice little board for a 'bot like my Loki project. Let me know when a proto or first production is available!
Alan KM6VV