SSC-32 problem

Hello,

I am working on a project where I am using an SSC-32 controller and four HSR-5980 servo motors. I have two motors moving back and forth (head to tail) and two up and down. Each side of my robot has one motor going up and down, and one back and forth.
My issue is that the two motors on opposite sides of the robot (back and forth motion) are out of sync, i.e. one starts earlier than the other, therefore causing my robot to veer to one side.
Initially I had set the two motors of one side to connect to channels 0 and 1, and the two motors on the other side to connect to channels 16 and 17.
I had suspected that a delay due to channel distance could have been causing my delay in motor function and connected both motors with up and down motion in channels 0 and 1, and the back and forth motion into channels 16 and 17.
This did not solve my problem and I am not suspecting a problem in my code.
I am attaching snippets of my code which controls my movement. I would appreciate help with this issue.

My main aim is to have the motors not delay and start at the same time so that it is not veering to one side while moving forward.

[code]#set all servo’s initial position
ser.write("#0 P"+str(lu)+" #1 P"+str(ru)+"\r") #up
ser.write("#16 P"+str(lb)+" #17 P"+str(rb)+"\r") #back
time.sleep(1)

#Looks at GUI box to see what gait is selected

if Frame.gaitBox.index(ACTIVE)==0:
    for i in range(0,runs):
        gaitSym(ser, step_ms, step_s)
        print '  Run: '+str(i+1)+''
        stopVar=isStoped();
        if stopVar==0:
            break
        
if Frame.gaitBox.index(ACTIVE)==1:
    for i in range(0,runs):
        gaitAlt(ser, step_ms, step_s)
        print '  Run: '+str(i+1)+''
        stopVar=isStoped();
        if stopVar==0:
            break
  
if Frame.gaitBox.index(ACTIVE)==2:
    for i in range(0,runs):
        testProgramTIME(ser, step_ms, step_s)
        print '  Run: '+str(i+1)+''
        stopVar=isStoped();
        if stopVar==0:
            break

#set all servo’s initial position
time.sleep(1)
ser.write("#0 P"+str(lu)+" #1 P"+str(ru)+"\r") #up
ser.write("#16 P"+str(lb)+" #17 P"+str(rb)+"\r") #back
time.sleep(1)
print ‘\nSERIAL PORT CLOSED\n\n’
ser.write("#0 P0 #1 P0 #16 P0 #17 P0 \r")
ser.close() # close port

#Symmetrical Gait
def gaitSym(ser, step_ms, step_s):
import serial, msvcrt, time

ser.write("#16 P"+str(lf)+ " #17 P"+str(rf)+" T1000\r") #forward
wait_for_move(ser)
#time.sleep(1)
ser.write("#0 P"+str(ld)+" #1 P"+str(rd)+" T1000\r") #down
wait_for_move(ser)
#time.sleep(1)
ser.write("#16 P"+str(lb)+" #17 P"+str(rb)+" T"+str(step_ms)+"\r") #back
wait_for_move(ser)
#time.sleep(1)
ser.write("#0 P"+str(lu)+" #1 P"+str(ru)+" T1000\r") #up
wait_for_move(ser)
#time.sleep(1)

def wait_for_move(ser):
import serial, msvcrt
ser.flush();
while True:
ser.write(“Q \r”) #Is move done?
if ser.read(1)==".":
#time.sleep(0.01) #might need a delay to not overwhelm motor controller
break

def isStoped():
return stopVar
def stopProg():
global stopVar
stopVar=0
return stopVar
[/code]

I am new to this and I understand if I wasn’t clear, please ask me questions and I will try to answer them.

Thank you.
Nic

To coordinate the servos better, command them in groups, i.e., both commands into a single serial out statement.

Alan KM6VV

Not to be annoying, but I am new at this and don’t quite understand what you mean? Do you mean have one wire from one channel got to both motors or change my code?

Thanks,
Nic

There is a very small and seriously insignificant delay from commanding servos in different banks of eight. But this doesn’t apply to you because your program has delays built into it! If you want to completely eliminate it then just connect all servos into the first bank… I.e. 0,1,2,3…

I’m not a C programmer, but your program has obvious delays when sending commands. From what I can tell it’s moving left and right servos in the same group move. A group move is when you command more than one servo in a row with either a speed or timed argument at the end. You are already doing this. You are saying that the two sides are out of sync, but that’s impossible with the way the code is written.

  1. move both left and right servos Forward.
  2. wait for them to move into position.
  3. move both left and right servos Down.
  4. wait for them to move into position.
  5. move both left and right servos Back.
  6. wait for them to move into position.
  7. move both left and right servos Up.
  8. wait for them to move into position.

So it’s already built in to move the left and right at exactly the same time.

If the bot is not going straight it could be mechanical, electrical, but I don’t suspect the code.

Yes, after further examination, it does appear that he is using group moves. 0 & 1, 16 & 17. So he shouldn’t see any delays. At least in the first part of the program.

I didn’t catch what the language was. It is C-like, with structures, apparently. C++? arduino? I don’t know what they’ve done to C for that language.

Alan KM6VV

The language of the program is Python. We have suspected that the controller is cycling through all the channels, and since there is a big gap between 0-1 and 16-17 it takes longer for the controller to reach 16-17. This time gap we have suspected is what is causing the delay. One motor is still visually delayed even after we put the up and down motion in channels 0 and 1, and the back and forth motion into channels 16 and 17. Is it possible that one of the motor is malfunctioned or is it something else?

There are four serial commands in the gait.

Each of them has a T value that is how long the move will take.

  1. #16 P(LF) #17 P(RF) T1000 <- this move will take 1 second.
  2. ask SSC-32 for . meaning it’s done. + means it’s still moving.
  3. #0 P(LD) #1 P(RD) T1000 <- this move will take 1 second.
  4. ask SSC-32 for . meaning it’s done. + means it’s still moving.
  5. #16 P(LB) #17 P(RB) T [this is different] <- this move will take ?
  6. ask SSC-32 for . meaning it’s done. + means it’s still moving.
  7. #0 P(LU) #1 P(RU) T1000 <- this move will take 1 second.
  8. ask SSC-32 for . meaning it’s done. + means it’s still moving.

Why in step 5 is the T value different than the other 3?

You could simplify the program considerably by just pausing for the 1 second rather than poll the SSC-32 for a . to know the move was completed. The move will have been completed in 1 second anyway… Polling the SSC-32 is useful, but in this case I don’t see what it brings to the table.

In my program I actually change the time on one part of the step cycle manually. Since I also change the speed of that part of the step to almost the max speed of the motors, I always want to ask if it finished to assure it travelling the right trajectory. This is what you see in step 5. It is part of my study I’m conducting with this robot.
In my opinion changing the time in step 5 has nothing to do with the delay of the right and left side motor. I mean the right side motor starts moving back visually earlier before the left side starts.

I agree that step 5 is not causing a delay from one side to the other. I was asking out of curiosity.

Youtube it for me… I can’t find any logical reason for what you are saying is happening. If I could see it, it might help… Also it might help if you could post some clear images of the board, wiring, power connections, etc.

Might be nothing. But are these “identical” R/C servo motors for the L & R? You might even want to swap L & R, and see what the visual affect is. Maybe a slow servo loop in one of them? Or swapping the channel assignments. If the problem moves with the swap…

Alan KM6VV

Here is a video I took. You can clearly see the delay between the left and right motor (right starts earlier).

Thank you for helping me.

Nicole

I know what the problem is…

What are the exact position values you are sending?

The position values are:

right Motor forward=2315
right Motor back=2015

left Motor forward= 500
left Motor back=800

It appears that the arms start moving back at the ~same time. You should be able to do some simple test with lynxterm or a batch file to see if a simple command for both servos to move at the same time works without a delay between the starts.

I don’t know what those values are. The spec sheet for the 5980 says it responds to 1100uS - 1900uS. The numbers you gave me will not even move these servos. I suspect your true range of pulses is partially out of range for these servos. In other words the program is sending pulses and the servos are ignoring them until they fall into the proper range of the servos. I further suspect you don’t have the servos properly aligned, I.e. the centered value of 1500uS does not move the assembly into a centered position.

Below is a simple type of batch file I’ve used in the past to do simple servo testing with the ssc-32. You would need to modify for the com port and baud rate you are using.

armtest.bat

@echo off
echo starting test

:: select port used and desired baud rate 
mode com5:9600,N,8,1 >nul

::put arms in initial back position

echo #16P800 #17P2015 >com5
ping -n 3 127.0.0.1 >nul

::move arms to foward position and wait 2 seconds for next command

echo #16P500 t1000 #17P2315 t1000 >com5
ping -n 3 127.0.0.1 >nul

::move arms to back position, and repeat sequence 

echo #16P800 t1000 #17P2015 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P500 t1000 #17P2315 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P800 t1000 #17P2015 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo repeating cycle

echo #16P500 t1000 #17P2315 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P800 t1000 #17P2015 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P500 t1000 #17P2315 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P800 t1000 #17P2015 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P500 t1000 #17P2315 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P800 t1000 #17P2015 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P500 t1000 #17P2315 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P800 t1000 #17P2015 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P500 t1000 #17P2315 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P800 t1000 #17P2015 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P500 t1000 #17P2315 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo #16P800 t1000 #17P2015 t1000 >com5
ping -n 3 127.0.0.1 >nul

echo test done
pause

I’ve an hexabot with 5980s. They responds to a range from 600 uS to 2400 uS (1800 uS for 180 °). So the left Motor is out of range at the forward move.

Greetings
Daniel

Thanks Chaosman… I got the figure I posted straight from a 5980 box, but it was an obvious misprint. The good thing is that is still the problem and he should be able to sort it from here. :smiley: