Hello
Is there any upgrade to the ssc in the works, being discussed or planned.
Reason:
Its great to have 32 servos but there are only 4 abcd sensors ( not considering the prior thread suggestions for possible additions through work arounds).
I wanted to suggest the need for additional sensor inputs as robotics not only needs to provide locomotion and control but access to the surrounding environment and allow the ssc to do more in addition to its enhanced servo commands and motor control.
I am looking at this from the prospective of tethered robotics using a pc that allows enormous processing ability compared to the abb and microprocessor abilities which are great for free roaming robotics.
if you need lots of sensor inputs you use an ABB+BA§ or some other generic i/o platform with lots of inputs. the reason you get 32 intelligent servo outputs is because the ssc-32 doesn’t monkey around doing anything but servos, which it does those pretty well. oddly enough it’s sold as a servo controller not an i/o processor.
as for using a PC to handle I/O, who is to say you can’t use your ABB+BA§ as an I/O processor and just pump the data back to the PC over your tether or a wlan connection? A Lantronix MatchPort will run at 115KBps wireless, and a WiPort will deliver 2 channels of 230kbps. I’ve got no idea what’s sustainable with bluetooth or any of the other shorter range products available, but just how fast do you need to poll bumper switches? even ultrasonics you are not going to get much more than 50-75 samples a second… just how much bandwidth do you need for sensors? think about it.
The BAP has multiple I/O pins that can be used. The same 3 pin headders used to drive the servos can also be used as input pins for sensors. If a SSC-32 is used with a Mini-ABB, then all those 3 pin headders on the Mini-ABB can be used for sensor input since the SSC-32 is doing all the work for driving servos.
All you have to do is set the pin state in the code to use thes pins as inputs.
I can’t imagine needing more inputs than this for most typical applications, but then again, some bots can have very complex sensor configurations.
Well I have been planning an SSC-24 which has direct connections to the processor pins, (the SSC-32 has shift registers in the outputs to control 32 servos from a processor with only 28 pins) Mike was unable to devote the time for this project, but this fall it’s going to happen. Mike told me he thinks he can do more than 24 channels as well. This is going to be a cross between the Bot Board and the SSC-32. Because it’s we are eliminating the shift registers, it’s basicallly a Bot Board with a built in Atmel processor. The proper development tools should be able to modify, or replace our servo control firmware. This will not replace the SSC-32, or the Bot Board. It’s just another option. This may not be a product until early 2008, so don’t get too excited. But at least it is going to finally happen.
We are upgrading the SSC-32 as well. It’s being changed to the Atmega168 processor which has double the memory of the current processor. So when Mike compiles the firmware now it’s 49% - 50% full instead of 99% - 100% full. With this new room for programming it will now be easy to add features, suck as a startup routine, storing sequences in EEProm, etc. We are ending the development of the current firmware 1.06xe as is, which is bug free. We are dropping support of the General Purpose Sequencer (GP) firmware as we had to make some tradeoffs to get it to fit. The improved GP Sequencer firmware will be released as soon as possible. We will also offer the programmed Atmel chip and EEProm chip for a reasonable price. I know this doesn’t address your concerns, but it is the answer to the question.
Fair enough, sn96/eddieb I enjoyed your thoughts on this subject and I am glad that I asked, considering Jim’s response. Thank-you for taking your time to respond in detail.
What about a scenario where bumpers, ir sensors and wireless comm are not as important and pressure/force sensors are used on a tehered bot. Unfortunately affordable force sensors takeup an entire channel to cover a small pressure area, thus requiring many inputs to monitor an area of interest on the bot.
The ssc32 works great with its 4 abcd but there are not enough inputs. Having more analog inputs on the ssc would save alot on $cost by eliminating the need for a abb/pro28
Anyway, I realize that my needs are shaded towards my own interest in bots and probably do not consider the needs of the way bots are used by others.
Direct servo connections to the processor sounds good, but you might consider keeping the SPI (slow it down) for some low speed access to things like sensors and control lines.
Hi Jim
The plans for the ssc24 sound great, the ssc is evolving.
I am new to bots so hopefully my views will evolve as well.
Having said that, I just do not like the basic idea of having to “talk” to the abb then have it “talk” to the ssc.
Having the ssc24 has a sort of hybrid between the abb and ssc32 is what I am looking for.
If the ssc24 could handle the servos like the ssc32
Handle the 3pin channels like the abb and toggle between sensors and servos.
Please consider adding more standard abcd inputs ( 8 to 12 my preference) they do not have to be 3pin, the ± doing several sensors at a time is fine.
The SSC-24 is being designed primarily as a servo controller. However because each pin is bidirectional you can use as many servo channels as inputs as you need. Yes the 3 pin I/O structure with power from a regulator or raw battery voltage is the plan. I do want to retain the three pin setup. It’s plug and play that way.
Another thing, you may be missunterstanding some of the comments. You can write a program for the Atom that will keep track of your sensors and report directly to the PC when queried. Because the Atom is totally programmable your sensor code can be quite intelligent if you think about it. However this method does require two serial ports on the PC. One for the sensors, and one for the servos controller.
Hi Wayne, I think the 4 A/D inputs to the SSC-32 is a hardware limitation as much as anything. If what you are looking for is lots of A/D channels for FSRs that you can scan fairly fast then I have a suggestion that may or may not be far fetched depending on your skill set. If you are not using the GP sequencer in the ssc-32 it may be possible to strip the code for it out and free up some code space. Remember the SSC-32 is an open source product so that is available as a starting point. If memory serves the EEPROM socket on the SSC-32 is an I2C device connected to the hardware I2C port on the micro. It would not be difficult to grab power and I2C from the EEPROM socket and wire that to a breadboard with some I2C a/d converters. Something like a TI ADS7828 or ADS7830 would give you 8 channels of 12 or 8 bit a/d conversion respectively (they are pin compatible), there is a vref output from the chips for nice low noise power to your FSRs, and you can put 4 of these parts on the same I2C bus for a total of 32 analog inputs. You would need to be able to breadboard or make a small BatchPCB board, and modify the SSC-32 firmware to support the interface, but if those skills are within your reach then this is a pretty low cost way to add the level of a/d support to the ssc-32.
Do I understand correctly that the ssc24 could have up to 24 3pin analog inputs or 24 digital inputs or 24 servos or any combination of the above ?
For my tethered project, having to maintain a 2nd program on the ssc24 would be redundant when the program on the pc has access to more processing ability and can query the sensors as desired.
For me its easier to maintain a single program than worry about which location an error might be coming, what version of the software is on what bot and the language on the computer is different from the language onboard the bot.
Anyway just my 2 cents and certainly from the perspective of a tethered application that ignores the needs of a mobile bot where onboard programmable and intelligent sensors would be key.
EddieB it seems that going in this direction would be alot of work for myself (for you its certainly a piece of cake)
I prefer to go the route of Plug & Play.
I have not used the GP sequencer.
Now if you could make available an add-on board with 16 to 32 analog inputs that I could PnP into the ssc32 and poll using VA to V…whatever then I would be interested in purchasing this ability.
Sometimes it hard for me to hear myself say PnP because when I remember back when everyone knew how to tune their car engine, change carb, do their own plug timing - I see the kids now turn the car key and expect everything to work. If the engine does not start, they have absolutely no clue. They want a PnP car.
That there is a whoops! As many servo channels as you want can be used as inputs. Analog inputs would be limited to how many are on the Atmega168 chip. I think it’s the chip he plans on using. Sorry for the mistake.
No problem, you are pushing robotics ahead, that can’t be a bad thing.
I did a google on Atmega168 and read 6 a/d at 10 bit. 24 would be better but if its 6 then its 6. 24 would be better but …
At least the sensitivity is 4 times more.
Actually the processor I am planning for the SSC-24 (or whatever it is called) will be at least an ATmega128, which has 8 analog inputs. I am planning to stick with the AVR processors to leverage the existing code base, but will use a higher-end AVR for the next generation.
