What are the upper and lower limits to allowable values for the S parameter in a servo move command? The reason I want to know is that I’m writing a Ruby software library to control the SSC-32, and I couldn’t find that info in the manual.
Thanks.
I’ll ask Mike to chime in. 
The valid range is 0 to 65535. A speed of 65535 will result in a move as fast as possible (unless constrained by the speed of another servo or by the T command). A speed of 0 will result in a move time of 65.535 seconds (the slowest possible move).
That is the valid range. A practical range would be more like 100 to 10000. At 100us/s it would take 15 seconds for a servo to travel end-to-end, assuming the pulse width range was 750 to 2250us. That should be slow enough to protect linkages, which is the main reason to use the speed command (I think). At 10000us/s it would take 0.15 seconds for end-to-end travel–faster than any servo I know of.
Mike
Thanks - exactly what I was looking for. I’m 75% finished with a Ruby library that will allow code like this:
controller = SSC32.new
controller.port = # serial port info goes here
channel = 1
pulse_width = 550
time = 1200
controller.servo_move!(channel, pulse_width, speed = nil, time)which will output an SSC-32 command to the serial port. I’ll post when I’m finished.
What is a Ruby library?
Alan KM6VV
Ruby is a programming language similar in some ways to Python (high level, interpreted, easier to work in than C, more or less cross-platform). I’m just writing some functions that can be used in Ruby programs that will interface with the SSC-32 without having to constantly worry about some of the detail.
so instead of
port.print "#3 P1500 T1000"I can write
servo_move(leg2.femur, 90.degrees, 1.second)That kind of clarity comes in handy when the program gets bigger…
Looks just like C or Java. But you said it was a script?
Alan KM6VV
It’s a lot closer to Java than C. You don’t compile the code - its interpreted at run time. Ruby has a lot of dynamic flexibility, but can be slow because of this (compared to C).
Check it out - it’s free and open source:
ruby-lang.org/en/
I’m writing all the control software for my non-yet-built robot using Ruby. I’ve broken off a set of functions that apply just to the SSC-32 that can be reused if I (or someone else) decide to write software (in Ruby) for a different robot or device that uses the SSC-32.
Although I haven’t seen anyone else using Ruby for this kind of stuff here, I can’t think of a good reason not to (or I haven’t found one yet). You could run it on-board from a Linux system, for example, and not have to write any low-level code. I will be running mine from my Mac OSX laptop. Not sure if Windows would work.
There is JS (Java Script) some of our software engineers use it to write scrips to “peekâ€
That is one of my two main concerns.My hope is that the program will be simple & fast enough so that it won’t be the bottleneck. But I’m no real programmer, and I’ve not yet built any hardware. What I have done is write some methods to control my newly acquired SSC32 and one servo. So far, I’ve been able to make it work without any perceptible delay, and have been able to string multiple commands together resulting in smooth movement. (Granted, it’s one, unloaded servo, and I’m not running any of the kinematics through yet).
Basically, my approach is: calculate positions -> send command -> wait for servos -> repeat.
I don’t know at what point (if at all) this will become too burdensome for Ruby orr how slow a processor I can get away with. I’m guessing that if my laptop can render sophisticated real time 3D graphics, it can probably keep up wiht a robot, even while interpreting the code. I’m not as sure about an embedded computer with lower processing power.
Complied C would seem much more suitable, but I don’t know C very well, and I’ve been spoiled by Ruby while doing web development. It really is incredible how easy it is for me to decipher my own Ruby code after a long break. My own C code may as well have been written by someone else after a couple days. I have to go back and figure it all out again.
The other concern is that Ruby is a young language, and the tools that have low-level access to things like serial ports are not very mature. If I hit a roadblock on something like that, I’m screwed, because that sort of stuff is way over my head. (People write these extensions in C, but wrap them in Ruby classes to keep the performance hit to a minimum.)
Stay tuned to see… hopefully it will all just work.
OK, if you’re on a PC, then you can afford more interpreting! You might even get away with it.
Yes, Ruby being a young language could be a problem. I have the choice of several C compilers to program my PIC controllers with. And any driver for a PIC hardware function is either available to me or I can write it to suit my needs.
The servos take time to move. Actually, you want to send out many small moves. But once the move (a step in a gait cycle) is calculated, the interrupt system takes over and continues to output the new positions for the servos. In the case of Loki, my Biped ‘bot, the interrupt system outputs 4-8 PWM values to the servos (no SSC32) directly. In the case of Shelob, my hexapod ‘bot, I have an SSC32, so instead I output a SET of positions in one RS-232 message to the SSC, and it generates the smooth moves. In the mean time, the controller is busy calculating the next step of the gait. I don’t really “waitâ€
Yep… I guess that’s the bigger point. I hope it does work out the way I’m planning, but if not, no big deal. There’s something appealing about trying something that nobody else (that I’m aware of) is doing. I suppose I’ll head back to the drawing board and brush up on my C if it doesn’t work. I’ve basically assumed that I won’t be using any inexpensive microprocessors to run this thing, just my pc or maybe one of those little gumstix-style mini computers running linux.
Right now I have a kinematics routine that breaks the gait up into tiny steps and calculates the required commands for each gait cycle all at once. Then it sends the signals to the SSC-32 one after another until the gait cycle is over. Then calculate the next cycle (based on a new direction vector), then send more signals, etc. It looks like I’ll be able to just time the signals rather than querying the controller as the exact path of the foot isn’t that critical, and if a command gets stepped on, I’ll still wind up in the right place.
So, as I have it now, there will be a gap between gait cycles while the next batch is calculated. I’m hoping it’s a small enough one that it won’t be noticeable.