Communication btwn SSC-32 and Bot Board

I am trying to get the robotic arm to run through a routine when the GPD-12 sensor senses an object at a certain distance. When I set my code so that the arm isn’t in play my robot works fine. By fine it the robot wonders around until it sees the object and stops. But when I put my arm code in it freaks the thing out. The arm tries to go through the motions but is real jumpy and just eventually stops. The motors for the wheels also keep running instead of stopping like before. What I want it to do is sense the object, stop, run the arm program, and then go. Any suggestions. I can paste the code if neccesary.

I also wanted to know if there is a way I can control the speed of the motors for the wheels.

Thanks

We are going to need more information in order to help. Images illustrating the wiring, a copy of the program you are running is an absolute must…

ytyyjj

Sorry. That was a test. It’s not letting me post my pics of my schematics up. Any sugesstions?

Now that you’ve got a few more posts, could you try posting the images again? You can also check out this post regarding posting images, and make sure you’re doing it like shown here.
lynxmotion.net/viewtopic.php?t=2230

I used the same wiring diagram as this but since I am planning on using the analog inputs for the SSC-32, I wired the Tx and ground from the SSC-32 to an I/O pin(14,Rx) andI/O pin(15,Tx) of the Bot Board. Both are using the same ground from the SSC-32. Make sense?

http://i80.photobucket.com/albums/j176/hounddigitydog/ssc32bb21.gif

I am using 2 inductors as anolog inputs(1,2) to the Bot Board as an out of bounds sensor. We have a wire that is electrically charged and oscillates at 10 Khz. That part of our system works fine. Here is my circuit schematic just in case.

http://i80.photobucket.com/albums/j176/hounddigitydog/untitled.gif

The GPD-12? sensor is also going into an anolog input(VS, beside pin 2) on the Bot Board. It works fine also.

Like before my problem occurs when I try and communicate with SSC-32 that I want it to procede with arm moves. The robot won’t stop. It tries the arm moves but is really jumpy. Here is my code.

[code]
'Connections
'Pin 16 Jumper to battery (VS)
'Pin 17 Left right inductor
'Pin 18 Right Inductor
'Pin 19 GP2D12 Sensor
'Pin 0 Left Sabertooth channel.
'Pin 1 Right Sabertooth channel.
'Pin 12 A Button.
'Pin 13 B Button.
'Pin 14 C Button.
'Pin 9 Speaker.

temp var byte
filter var word(10)
ir_right var word
ir_left var word
ir_rear var word

LSpeed var word
RSpeed var word

minspeed con 1750
maxspeed con 1250

LSpeed = 1500
RSpeed = 1500

low p0
low p1

sound 9, [100\880, 100\988, 100\1046, 100\1175]

main
gosub sensor_check

; Numbers lower than 1500 result in forward direction.
; Numbers higher than 1500 result in reverse direction.

LSpeed = (LSpeed - 10) min maxspeed ;accelerates the motors
RSpeed = (RSpeed - 10) min maxspeed

LSpeed = (LSpeed + (ir_left - 10)) max minspeed ;when something is detected, this decelerates the opposite side
RSpeed = (RSpeed + ir_right) max minspeed

;if (ir_rear > 15) then
;LSpeed = (LSpeed - ir_rear) min maxspeed ;if something is detected behind the robot, accelerates both sides
;RSpeed = (RSpeed - ir_rear) min maxspeed
;endif

; Send out the servo pulses
pulsout 0,(LSpeed2) ; Left Sabertooth channel.
pulsout 1,(RSpeed
2) ; Right Sabertooth channel.
pause 20

if (ir_rear > 50) then

LSpeed = 1500
RSpeed = 1500
endif

if LSpeed = 1500 then

gosub arm_move
endif

goto main

sensor_check

for temp = 0 to 9
adin 17, filter(temp)
next
ir_right = 0
for temp = 0 to 9
ir_right = ir_right + filter(temp)
next
ir_right = ir_right / 85

for temp = 0 to 9
adin 18, filter(temp)
next
ir_left = 0
for temp = 0 to 9
ir_left = ir_left + filter(temp)
next
ir_left = ir_left / 85

for temp = 0 to 9
adin 19, filter(temp)
next
ir_rear = 0
for temp = 0 to 9
ir_rear = ir_rear + filter(temp)
next
ir_rear = ir_rear / 85

serout s_out,i38400,"ir_right - ", dec ir_right, " ir_left - ", dec ir_left, " ir_rear - ", dec ir_rear, "LSpeed - ", dec LSpeed, " RSpeed - ", dec RSpeed, 13]

return

arm_move

Steps Bytetable 148, 128, 111, 79, 174, 144, |
148, 128, 111, 79, 174, 144, |
148, 146, 182, 73, 174, 144, |
148, 148, 188, 76, 134, 144, |
148, 146, 145, 58, 134, 144, |
69, 146, 145, 58, 134, 144, |
69, 145, 152, 66, 179, 144, |
153, 164, 166, 58, 179, 144
TimeAndPause Wordtable 1000, 0, |
30, 0, |
990, 0, |
90, 0, |
540, 0, |
1230, 0, |
120, 0, |
1110, 0

JointNB con 6
SSC32 con p14
StepIndex var Word
pause 500

For StepIndex = 0 to 7
	
	serout SSC32,i38400,"#0P", DEC Steps(StepIndex * JointNB) * 10, |
		" #1P", DEC Steps(StepIndex * JointNB + 1) * 10, |
		" #2P", DEC Steps(StepIndex * JointNB + 2) * 10, |
		" #3P", DEC Steps(StepIndex * JointNB + 3) * 10, |
		" #4P", DEC Steps(StepIndex * JointNB + 4) * 10, |
		" #5P", DEC Steps(StepIndex * JointNB + 5) * 10, |
		" T", DEC TimeAndPause(StepIndex * 2), 13]
	Pause TimeAndPause(StepIndex * 2) + TimeAndPause(StepIndex * 2 + 1)
next

goto main

[/code][/code]

OMG what a mess… :unamused:

First off I need to see a real schematic, or an image of the boards to see the wiring The symptoms you are describing could easily be power related.

Have you tested the arm routines to verify they will work by themselves?

I’ve looked through your code and can’t see where you are making a decision to jump to the arm control part of the code based on sensor readings, (GP2D12). Perhaps some comments would help.

Your gosub(ing) into the arm routine and goto(ing) main out of it. Not good.

The stepindex is 0-7, but in the serout you are sending positions based on stepindex * jointnb which is 6. Sorry man you totally lost me on that.

Ok. I figured out how to adjust the speed and make the arm move smooth. I still can’t get the robot wheels to stop when the rear sensor detects an object. They seem to stop when for a brief second when the arm is done with it’s routine.

It keeps moving because you never tell it to stop :unamused:

You changed the speed variables to 1500, but you never actually send it to the motor controller. It stops after the arm sequence because that’s the next time where the program would send values to the motor controller.

Also may I recommend you offload the motor control pulses to the SSC-32 instead of the Bot Board II. This way a single serout will command the motors to stop without worrying about making sure you send enough pulsouts sequentially to stop the motors.

Thanks for all the help so far. I’m not a programmer so this is probally a stupid question but how exactly would I tell it to stop. I mean I thought stop was 1500. Can you give me an example? Thanks.

Yes you “tell it to stop” with values of 1500, but you never actually sent the values using the pulsout command. You can change the value of the LSpeed and RSpeed values till you’re blue in the face, but if the program never uses these values (pulsouts) the robot will not stop.

Program flow 101…

[code]if (ir_rear > 50) then

LSpeed = 1500
RSpeed = 1500
endif

if LSpeed = 1500 then

;add these lines…
; Send out the servo pulses
pulsout 0,(LSpeed2) ; Left Sabertooth channel.
pulsout 1,(RSpeed
2) ; Right Sabertooth channel.
pause 20

;change the following line to…
;gosub arm_move
goto arm_move

endif

goto main [/code]

Thanks for the quick response. That did work but instead of stopping the motors fully they slowly reverse. Any idea why?

Again I need more information. What are the dip switch settings on the Sabertooth? If autocal is enabled then turn it off. This should ensure that 1500uS is stopped on the Sabertooth.

Here are the settings we used. This is what we got off the website for autonomous vehicle.
http://i80.photobucket.com/albums/j176/hounddigitydog/st10rc02.gif

What info do you need?

I meant: What other info do you need?

Never mind. We got it thanks for the help. Probally have more stupid questions later.

You do know you can edit your posts right?

I have asked John at DE to chime in here. If you have the Sabertooth set with autocal disabled I don’t think it should creep backwards when you send it 1500uS pulses.

What we did was set it to 1480 and it stopped the wheels completely.

Your solution is the appropriate thing to do in this situation:

The clock on the Sabertooth family of motor drivers is only accurate ±2%.

In analog or the serial modes, this doesn’t matter. (±2% is enough for accurate UART communications, and analog isn’t clockspeed-dependent)

In R/C autocalibrate mode, again, it doesn’t matter, because the controller will calibrate to whatever the incoming stream is continuously.

However, in fixed throttle R/C mode, “stopped” can theoretically be anywhere between 1470 and 1530. Most of the controllers are somewhat closer than this (you got good results calling 1480 stopped) but its entirely possible that once in a while someone will need an offset to accommodate this.

Your solution is right.

Hope that helps
John