I know that you have not asked me for my thoughts here, so please forgive…
But I thought I would chime in a little…
First I like the idea that the SSC32-NG or UIOC-32 and this will be interesting and make a great product. It will be interesting to see how this product will be used in the end. Mainly as a servo controller, or an Input controller, or as the main robot controller…
Some questions or thoughts.
USB: I have a love/hate relationship here.
a) That is it will be great to get away from having to tell people to get USB to serial adapter X… But I have also seen lots of stuff on BM forum and here with Arc32 and their Dev boards, where the drivers did not install properly, especially with Windows 64, or Linux, or MAC… So will need to have good instructions on how to download and install. FTDI appears to be the best supported.
b) Speed of USB downloads. Probably not an issue if the board is simply a servo controller and seldom if ever reprogrammed, but if GP dev board, I know that at least with the BM boards/chips on my machine it takes 2 maybe 3 times as long to download over FTDI chip set as it does with my Prolific cable (probably PL2303 based). It has to do with them only downloading and verifying 1 byte at a time so may not be specific to FTDI. I know that on the Axon2 he is using an Silicon Labs CP210x FTDI bridge chip for speed, which is great (can download programs in maybe 1.5-3 seconds), but not as well supported
c) Comm port number proliferation, that come and go: Sometimes it easier with external serial, in that with my cable, I always know it is Com4, so when I enter SEQ, or IDE, or Lynxterm, or… they are configured once and you can forget it. But with USB device, One of my Arc32s is Com14, other Com18, or was it Com3… Also when I unplug them they are not there any more. So will need at a minimum all of the software programs to handle dynamic com list. Also with programs like SEQ or Flowstone equiv, it would be nice if they also then queried the devices and only showed those that were appropriate devices (probably need to use API…)
d) USB Power? If you only use the SSC-32 for servo driver USB power probably does not gain you anything as you can not run any (or at least many) servos with the USB, but if you are using as an Input device or as a general purpose controller, it might me nice if you could optionally enable it.
Communication with micro controllers: If you are using the new board as a servo driver that is controlled by another controller, the USB will not help much here. Need some other forms of communication.
a) TTL serial: would be nice if there was more options on baud rate. Still use jumpers? Or store desired speed in EEPROM, with maybe a reset to default? Would be nice if it could talk some more non-standard baud rates as many controllers run at 16 or 20mhz whose UART don’t talk 115200 for example but do talk 125000 great.
b) Maybe something like I2C: Why? Example today with Phoenix code, we enable a timer which causes interrupts, which if these happen today while we are bit banging out serial bytes, the data is corrupted, so we have to liter the code with enables/disables. This code might work better if the data could be sent with the clock…
That is all for now.
Again I think this will be a great product.
Kurt
P.S. - This old dog may have to learn some new tricks as I have not done any Pic programming yet
Everyone that can see these posts are welcome to chime in. I respect you all very much and welcome any and all feedback!
I share your love hate relationship.
I think it’s possible to change the com port number in the driver properties. I remember weird things like having multiple com ports created for the same USB circuit. I would hope all these odd things have been solved by now.
I would not advise allowing the USB power to be used for any servos. USB power should only be used to power up the logic of the board.
We will have to retain the TTL communication capability we have now. If I2C can be supported I don’t know why we wouldn’t want to make it available. Non standard baud rates, maybe we could just autodetect?
I plan to design this as a servo controller with “extras.” Extra I/O types of course, but moving the hard timing stuff to the I/O processors should make it much easier for people to develop applications to run on the main processor, so I hope there will be plenty of use of this as a general-purpose robot controller. I’m also curious how it will play out.
Speed of downloads is important, and I will try to be sensitive to that in the development. You’re right, it is all the more important for a general purpose board.
My thinking right now is that the USB port will power only the FTDI chip and nothing else (except maybe some USB status LEDs). Definitely not servos. But you are right again, for an I/O board it would be useful to allow the entire thing to be powered from USB. I’ll add that to my list of things to try to fit in the design.
I will probably take this opportunity to enhance the Baud rate selections. The 2400 Baud setting is probably never used, so I might use that combination to indicate that the Baud rate should be taken from a register. The other combinations would work as today.
I am planning to include an external I2C interface if it will fit, but don’t have plans right now for how to use it. The first software release will probably not include I2C support. Please make suggestions on what you think an I2C protocol should look like for the SSC-32. My default would be to have something resembling the Binary protocol, extended to include the entire command set. (Which reminds me, I wanted to thank you for doing the write-up on the binary protocol. Good job.)
PIC programming will be new to me too. I played with PICs 10 years ago, before I found AVR, but never got to know them well. The only reason I am going back is that the price/performance ratio is just so much better for the PICs. It helps that the 16-bit PIC architecture is so much better than the ugly old 8-bit PICs. Unfortunately, the I/O processors need to use 8-bit parts to keep the cost down.
I am starting the layout and am wondering about how closely the I/O connectors need to match the SSC-32. I notice that the ARC-32 has shifted the servo headers to make room for additional circuitry on the power connector end of the board. Would this be acceptable for the SSC-32 update, or do you prefer to keep the servo headers exactly as they are?
Next question. Do you need the ABCD header, given that the 32 I/O pins will all be capable of acting as analog/digital inputs?
Next question. Do you want to keep the series 220 Ohm resistors on each of the 32 I/O points? I put these in because I am conservative, but I don’t really know if they are needed, or if the 220 Ohm value really does any good anyway.
Just looked at the ARC-32. I would like to retain the 4 x 4 groups on each side if at all possible. Any additional lines could be added anywhere you could fit them, but if the main 4 groups of 4 I/O lines were in the same place most would not be scared off from it “looking” different.
Prolly don’t need the ABCD ones. We are currently making programs available that connect two arms, so we have:
arm 1 and 2 spares (8)
arm 2 and 2 spares (8)
dedicated outputs (8)
ABCD inputs (4)
So we still have 4 left over if the ABCD were not there. Even the most outrageous biped doesn’t use all 32 outputs. So we should be ok with only 32 channels. Ha! “only” lol
The 220’s are perfect for protecting the output from a direct short. However inputs may not want this series resistance, so I’m ok with losing them.
By the way I was at first afraid of the multiple processors. But I wanted to let you know after thinking about this for a while I’m seeing the light. I really do like this approach. Not sure but the pics used as I/O processors maybe a cool part to sell standalone. Providing there is an easy way to get them working without machine level coding. lol The 8 channel I/O co-processor might make an 8 or 16 channel SSC possible? 8)
Just wondering, as this board is getting more general purpose and the pins can inputs… Wonder if you should try to add the ability like BB2 or Arc32, where you can choose if a bank of pins has +5v instead of VS.
Thanks for the reply. I will definitely keep the 4x4 grouping, but might slide the headers towards one end of the board if necessary to simplify layout.
I’ll keep ABCD if I can, but will omit if necessary to simplify layout.
I’ll keep 220’s if I can, but will omit if necessary…you get the picture. I don’t think any inputs will be bothered by the 220 Ohm resistance, but the resistors might get in the way of placing the voltage select headers.
The I/O banks will be selectable VS or 5V (like Kurt suggested). The voltage selection will be in banks of 8, i.e. all 8 pins connected to a given I/O processor. There are a couple of ways to place the voltage selection header. It could be in line with the I/O headers (similar to ARC32) or off to the side (similar to the BotBoard). Do you have a preference? If not, I’ll go with whatever lays out better.
My thought process was similar to yours. As this becomes more general purpose, supply voltage selection is important. I will do it in banks of 8 though, rather than 4. That fits with the I/O processor architecture. It will work better all around if similar I/O types are grouped together in a bank of 8 (although mix and match will be supported, timing will probably be more precise if similar types are grouped.)
Oops, forgot to comment on using the PIC16s as stand-alone SSCs. The ones in this board will most likely be I2C connected to the main processor. Coordination of group moves will be done in the main processor, since only it knows what all the servos are doing.
With different firmware the I/O processor would be able to handle group moves with 8 servos. To do a 16-servo group move, one of the PICs would need to be in charge of coordination, but that should be quite possible. Or a single 20-pin PIC could (SMOP) handle a 12-servo SSC. Lots of possibilities.
One more question that I forgot to ask. I am looking at replacing the crystal with a smaller and less-expensive resonator. The things are specified at 0.5% accuracy at room temp. Probably a lot better than that most of the time. This is plenty good for serial communications, but would result in a potential error of several microseconds in the servo pulses. (At 1500us, a 0.5% error would be 7.5us.)
Preference on this? Would you feel more comfortable staying with a crystal?
I was trying to envision if the I/O controllers could be useful as a standalone co-processor. For example if we put one on a small board with an I2C interface, could an Arduino make use of it? or would the required underlying sequence code make doing other things problematic? I’m not sure if the average Arduino programmer is able to deal with interrupts or not. I’m guessing no. Basically will the programming be too difficult for most to deal with.
Note: There are standard I2C libraries that are part of the Arduino environment, so that part is not out of the realm for most Arduino programmers. As for Interrupts, probably depends on the interrupt and since many of the devices have libraries for them, that take care of handling the interrupts. The user of the library simply needs to call the appropriate methods…
It should not be difficult to interface to. The I2C interface for driving servos will just take servo number, pulse width, and movement speed for each servo. Similar interface for reading analog/digital values. All the interrupts and timing-critical stuff will be handled in the I/O controller.
The I/O controllers will use their internal RC oscillator for timing, so they will not be very accurate (up to 2% error). I am going to handle that by giving them a pulse from the main processor every 20ms. The pulse will be used to calibrate the timing of the I/O processors and to sync them up with the main processor. If this pulse is not used, then the I/O processor will still work but will be less accurate.
It might be possible to create a version of the I/O processor that uses a ceramic resonator or crystal to get better accuracy without a timing pulse from the master.
Hope all is well. We have received the shipment of 2x of the prototype SSC-32U boards and are looking to finish them so they are ready for production. Jim indicated you would be the person to talk to. Can you give us a status update?
Yes MikeD would be the best one to answer this. But I will try to fill in any information I know…
As per my last email with him which was a few weeks ago. At that point, the firmware status was:
I have one of the prototype boards in my T-Hex connected to a Botboarduino. I have so far verified that the T-Hex can walk when we issue the SSC Text commands. As per the above list the Binary commands are not implemented. I did a little testing with some of the registers stuff, I am waiting for the next update to continue.
Summarizing some of the other things I have seen and discussed in email include:
When I first had it connected to the Arc32, I was seeing sometimes see some garbage characters display in lynxterm, after I turned the power off to the robot. I do not see this with botboarduino. Have not tried with BB2.
Lynxterm did not recognize the SSC-32 as a version of the SSC-32 that supported registers, so it did not allow me to get into register editing mode. So can not use that to zero the servos.
Devon’s hexapod calibration program does see it, but only at 115200
It is nice to be able to hook up USB to do stuff and not have to disconnect TTL io lines. I have not tried anything with XBee yet.
We also have had some discussions about possibility to extend the firmware, once the basic were up and running. Things like:
a) A way to say, if the analog input X goes below some value, shut off the servos…
b) Maybe some support for TA. That is maybe we have something like: If Input X goes low or high, stop Servos (x, y, z). Also maybe extend this to also allow it to set the state of another IO line. That way we could maybe hook up leg sensors to SSC-32, which could instantly stop the appropriate servos when contact is made with the IO pin set High, could interrupt the main processor, which could then query for information, like where each sensor is…
