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.
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.
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.
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.
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.
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.
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.
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.
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.
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…)
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…
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.
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.)
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.
Actually I am fine with the dsPIC and PIC24 architectures, but don’t like the old PIC architecture.
