HI Folks
have been reading up on the commands for the SSC32 and one things that has struck me is that there is no hardware flag to tell a supporting processor that the SSC32 has finished a movement.
Sure it can be done in code
Send Movement
Send Q
do while recv <> "+"
Sent Q
But that means that the supporting processor is tied up just for movement.
If there was a way to set one of the Inputs/Outputs to be a flag then it would be very easy to implement an interrupt system on the supporting processor
This would require a change to the firmware of the SSC-32, which I am pretty sure won’t happen for the current SSC-32, but you might put in as a request for an enhancement for the newer SSC-32u…
With the Phoenix code base we used to do the Send Q wait for response type of loop early on. But later we simply used a timer on the processor to let us know when we should output the next move. We did not do this using an interrupt, but instead would simply check in our code if enough time has elapsed.
That might work… I am thinking od sing an intervening processor that will accept the movement code and then set a pin high, and check with SSC32 using ‘Q’ until it sees the ‘+’ and set the pin LOW again.
But for may main processor it will be handling a lot of things including running a HUD, sonars, and a lot of real time processes so being able to throw the SSC32 a command when it needs it would be very handy.
My application is wearer controlled animatronics where the wearer will interacting with the public in a very realistic animal suit. The suit will be controlling al of the emotions of the character and so needs to be a smooth as possible.
Dave
That sounds like a great feature: we’ll consider adding a variant of the Q command that has an asynchronous response that happens when the movements are done.
If this is not available in the first version of the SSC-32U, it will be made available as a firmware upgrade.
It should be rare that people use ALL of the 32 servo outputs… however it is reasonable for them to use all of the general input/outputs.
So a variant of the Q command that you can designate a servo port to use as a hardware signal where a LOW is not busy - send info, and a HIGH is Busy - don’t send.
That way any supporting processor can use that pin on a interrupt and so jump to the sequence sending routine as soon as it get’s the go ahead from the SSC32
So QAxx where xx being the Servo pin, and QA99 to disable the feature.
FYI - the 32 servo pins are on output only Muxs, so the current design will not allow you to use these for inputs. You do however have I belie 8 IO pins on the new SSC-32u board.
I can understand that - the Hardware signal will only be an OUTPUT for the SSC-32.
here is an example
*source processor (Adruino, Maximite, etc)
Send “QA32” to SSC32 to use servo 32 as the interrupt pin
Set Interrupt on pin 5 on LOW trigger -> connect to servo pin 32 on SSC-32
Send first sequence to SSC32
do stuff, read sensors
do stuff, read sensors
do stuff, read sensors
Interrupt:
’ SSC32 is ready for new sequence.
Send next sequence to SSC
Return
Now the source processor can do whatever it needs to do without needing to monitor the SSC32 because the SSC32 will let it know when it is ready for more data.
Hope this make it more understandable. So - any timeline on the SSC-32u board?
Dave
Note you can do it different ways today. For example the Phoenix code base wants to do things as smoothly as possible, so when it starts to execute a command it remembers the time and the duration of that command, so it knows the time it wants the next command to begin. It then checks all of the inputs and does the work to calculate the next servo positions and then at the appropriate time issues the next command. Note we actually output almost the who command before this point, but simply output the cr at the time the command should execute.
Depending on your processor you can poll clock or potentially use a timer interrupt for this.
But I also agree having the ssc32 set an output at some conditions like this would be nice…
The processors that I am playing with tend to be running and 80mhz plus so I tend to have some spare processing capacity.
My project can be broken down into several sets of servo’s (left ear, right ear, eyes, muzzle) and each set’s movements are stored in 250ms chunks in an SD card.
I can then assemble these chunks on the fly to get a single sequence to be passed to the SSC32 so that all of the servo’s are moving at the same time.
Now I can set an internal tick for 250ms so my source processor can send each new generated sequence to the SSC32 however I am unsure what will happen if the SSC32 has already finished it current sequence and is awaiting the next one (servo stop and then start to move again)
Or the SSC32 is still processing the last sequence when it receives the next one (servo’s suddenly jerk to a new position)
In SpFx you generally have a group of people controlling an animatronic costume with R/C whilst the actor performs. However if you don’t have a team or you are in an ad-hoc environment then you need to try and do the best you can with preprogrammed sequences.
Hence my desire to keep the sequences arriving at the SSC32 as smoothly as possible.
Many thanks for all of your interest and input
Dave
Sounds like an Arduino Due or potentially a chipkit Due32/Uno32… I have played around with these as well and had/have the Hexapod code base running on both of these (at least to a point). Currently playing around with some small Linux boxes like the Odroid U2 which is a quad core processor running at 1.7ghz, so it has a bit more processing speed
When you send a command to the SSC-32 after it completed the previous one that includes a Time or Speed element, it will simply start moving toward that new position and the appropriate speed to get there at the appropriate time or alternatively at the speed you requested.
We found our movements were better and more consistent and smooth when we do our own timings as using the Q method guarantees that there will be some pause between commands. Because it has to wait until the command is done, wait for you to send it the Q command (2 serial character time delay), time for it to receive the command, and send out the response (1 character delay), wait for you to detect that command said it was done and for you send out the next command, which is probably many characters long (so again that long of a delay, before the next command starts).
Versus, knowing that your next command should start in 250ms, figure out what you want to output and if possible output it all to the SSC-32. Then when your timer tick happens, you simply output the which causes the SSC-32 to start the next command with one serial character delay… Now worse case here your timing may be off by probably 1 servo pulse change, which you will never see. That is, suppose your CR comes in slightly early and example wise lets say the previous command including telling Servo 1 to go from 1500 to 2000 in 250ms. Servos are updated 50 times per second or every 20ms. So it changes 25us per servo period. So worst case if we issue the command before the last period completes, to lets say go back to 1500 in 250ms, the servo may start off the move at 1975 instead of 2000 before the move starts back and instead of changing maybe 25us per period it may go at 24us per period… Also if the next command does not have this servo moving, it will continue to go to the previous requested position of 2000…
But for the most part this is not likely to happen as we build in a slight delay as we set the time of last command after we sent the previous command (slight delay), we wait until the time period has elapsed and then send the so again a slight delay.
Yes - your explanation does make sense. The Maximite I am using is a Pic32 processor running MMBasic at 80Mhz, so the code is easy to implement and is very much like an old TRS-80 Level II basic with some disk/file commands. They recently implemented Random file access which make writing a sequencing language very easy.
What’s is the total command buffer size of the SSC32 (and will the SSC-32u increase that) as I can possible send two commands at once and omit the final then repeat the process since the SSC queues commands.
If there also an ‘Abort’ command that will cancel all currently running commands and clear the command buffer of all impending commands.
Buffer size? Not sure also may not matter as the ssc32 will process the characters as it receives them, and in a move case will save the new values out in a secondary set of arrays, and then move those values not the working set and do the calculations on how much it should update the servos per refresh period when it receives the cr. As to cancel, by the manual, the esc key should do the trick. See manual lynxmotion.com/images/html/b … htm#srvmov
Note with my 4dof hexapods output values for at least 24 servos…
Kurt
Many many thanks for your valuable information Kurte
I should be able to easily modify my system to handle this. I found some other info on the forum re time taken to process the commands(several miliseconds) so I can factor that into my sequences.
