BS2 decision making time
Archiver
Posts: 46,084
Hello everyone. I have a problem with my robot. A little background: It is a
Firefighting robot for Trinity. It uses a single Basic Stamp to monitor
ultrasonics (Devantech SRF04s) and avoid walls accordingly. My problem was that
the stamp took too long to check the sensors before it came back and decided on
a different gosub, causing the robot to "studder". I thought using 2 stamps
would eliminat the problem by having one always monitor the sensors and the
other one make the decisions (serial communication). This did not solve my
problem. I'm all out of ideas. The only thing I can imagine would be to try to
use an extra servo controller, but would that still take too long? Would and
extra controller shorten the code and therefor the stamps reaction time?
Thanks to all with input :-)
John Baker
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
Firefighting robot for Trinity. It uses a single Basic Stamp to monitor
ultrasonics (Devantech SRF04s) and avoid walls accordingly. My problem was that
the stamp took too long to check the sensors before it came back and decided on
a different gosub, causing the robot to "studder". I thought using 2 stamps
would eliminat the problem by having one always monitor the sensors and the
other one make the decisions (serial communication). This did not solve my
problem. I'm all out of ideas. The only thing I can imagine would be to try to
use an extra servo controller, but would that still take too long? Would and
extra controller shorten the code and therefor the stamps reaction time?
Thanks to all with input :-)
John Baker
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
Comments
possibilities for you.
Possibility A:
If you're using servos as the drive system, it could be that polling the
sensors takes so long that it can't output pulses to the servos often
enough, so the go in fits and starts. If this is the case, I'd think that 2
stamps would solve the problem. It's exactly the problem I wrestled with
when I built a robot that used serial communications from my laptop to
control it. If you make the stamp responsible for outputting to the servos
output in a loop, making use of the SERIN statement's timeout feature, then
it will always output to the servos. There may be a tiny hiccup when the
sensor stamp actually sends new data to the PWM stamp, but it will be minute
(assuming your baud rate is decent... 4800 or 9600 should be fine).
Possibility B:
The problem isn't anything at all to do with your stamp taking too much time
and is instead a problem with your finite state machine. I'm assuming that
when the sensors detect an object, it enters an "avoid obstacle" state. It
could be that the sensors are intermittently detecting the obstacle (perhaps
it's at the edge of range, or by turning slightly it is no longer being
"seen"). Depending on your FSM architecture, this could cause rapid state
shifts and thus the jerky movement.
There are no doubt more possibilities, but they require more knowledge of
your project. This doesn't fit the current situation perfectly, but here's
a link that everyone on this list should read before posting a message, to
get an idea of what to include:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Hope I helped,
Ryan
Original Message
From: John Baker [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=Mct2anFvf33N3Ws0L7O3s6oq1NrbLC0OxWdZGs1WvajJvNgdv0RQamde-i8tqZhQuu5CAw9r07cbNIzxZGD_7hdJdQdrxg]johnbaker_erie_pa@y...[/url
Sent: Thursday, August 07, 2003 1:59 PM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] BS2 decision making time
Hello everyone. I have a problem with my robot. A little background: It is a
Firefighting robot for Trinity. It uses a single Basic Stamp to monitor
ultrasonics (Devantech SRF04s) and avoid walls accordingly. My problem was
that the stamp took too long to check the sensors before it came back and
decided on a different gosub, causing the robot to "studder". I thought
using 2 stamps would eliminat the problem by having one always monitor the
sensors and the other one make the decisions (serial communication). This
did not solve my problem. I'm all out of ideas. The only thing I can imagine
would be to try to use an extra servo controller, but would that still take
too long? Would and extra controller shorten the code and therefor the
stamps reaction time?
Thanks to all with input :-)
John Baker
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[noparse][[/noparse]Non-text portions of this message have been removed]
problem more.
'{$STAMP BS2}
'Decision making stamp
Letter VAR Byte 'incoming Serial data variable from check (ultrasonics)
a VAR Word
LOW 14 'left servo
LOW 15 'right servo
start:
GOSUB check
IF Letter = "F" THEN nextpartofmaze 'turn left after first hall (front sensor)
IF Letter = "L" THEN Radjust1 'too close to wall on left
IF Letter = "R" THEN Ladjust1 'too close to wall on right
GOSUB forward
GOTO start
Check:
SERIN 10,16468, [noparse][[/noparse]Letter] 'Get sensor status
PAUSE 10
RETURN
forward:
FOR a = 1 TO 10
PULSOUT 14,1000
PULSOUT 15,500
PAUSE 20
NEXT
RETURN
Radjust1:
FOR a = 1 TO 5
PULSOUT 14,1000
PULSOUT 15,700
PAUSE 20
NEXT
RETURN
Ladjust1:
FOR a = 1 TO 5
PULSOUT 14,800
PULSOUT 15,500
PAUSE 20
NEXT
RETURN
'{$STAMP BS2}
'Sensor Stamp
F_dist VAR Word 'Variable for front sensor
L_dist VAR Word 'Variable for left sensor
R_dist VAR Word 'Variable for right sensor
'
============================
F_init CON 0 'P0 is the Pin for front's initial pulse
F_echo CON 1 'P1 is the pin for front's input
L_init CON 2 'P2 is the pin for left's initial pulse
L_echo CON 3 'P3 is the pin for left's input
R_init CON 4 'P4 is the pin for right's inital pulse
R_echo CON 5 'P5 is the pin for right's input
'
============================
Main:
GOSUB check
IF F_dist < 10 THEN sendf
IF L_dist < 15 THEN sendl
IF R_dist < 15 THEN sendr
GOTO main
check:
PULSOUT F_init,5
OUTPUT F_init 'Delay
RCTIME F_echo,1,F_dist
PAUSE 10
PULSOUT L_init,5
OUTPUT L_init
RCTIME L_echo,1,L_dist
PAUSE 10
PULSOUT R_init,5
OUTPUT R_init,5
RCTIME R_echo,1,R_dist
PAUSE 10
RETURN
sendf:
SEROUT 10,16468,[noparse][[/noparse]"F"]
PAUSE 25
GOTO Main
sendl:
SEROUT 10,16468,[noparse][[/noparse]"L"]
PAUSE 25
GOTO Main
sendr:
SEROUT 10,16468,[noparse][[/noparse]"R"]
PAUSE 25
GOTO Main
My problem persists. Please help. Thank you.
Ryan.D.Meador@e... wrote:
Your post is lacking the details I'd like to see, but even so, I have two
possibilities for you.
Possibility A:
If you're using servos as the drive system, it could be that polling the
sensors takes so long that it can't output pulses to the servos often
enough, so the go in fits and starts. If this is the case, I'd think that 2
stamps would solve the problem. It's exactly the problem I wrestled with
when I built a robot that used serial communications from my laptop to
control it. If you make the stamp responsible for outputting to the servos
output in a loop, making use of the SERIN statement's timeout feature, then
it will always output to the servos. There may be a tiny hiccup when the
sensor stamp actually sends new data to the PWM stamp, but it will be minute
(assuming your baud rate is decent... 4800 or 9600 should be fine).
Possibility B:
The problem isn't anything at all to do with your stamp taking too much time
and is instead a problem with your finite state machine. I'm assuming that
when the sensors detect an object, it enters an "avoid obstacle" state. It
could be that the sensors are intermittently detecting the obstacle (perhaps
it's at the edge of range, or by turning slightly it is no longer being
"seen"). Depending on your FSM architecture, this could cause rapid state
shifts and thus the jerky movement.
There are no doubt more possibilities, but they require more knowledge of
your project. This doesn't fit the current situation perfectly, but here's
a link that everyone on this list should read before posting a message, to
get an idea of what to include:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Hope I helped,
Ryan
Original Message
From: John Baker [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=kE3VI9xu9pci7QTY6RypCkz260LMv9w2Mw-yrtwvUnUIfrykaT25v1OypdSk19G7TYXnliVBWqpgAJHuq6YR0jRtxw]johnbaker_erie_pa@y...[/url
Sent: Thursday, August 07, 2003 1:59 PM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] BS2 decision making time
Hello everyone. I have a problem with my robot. A little background: It is a
Firefighting robot for Trinity. It uses a single Basic Stamp to monitor
ultrasonics (Devantech SRF04s) and avoid walls accordingly. My problem was
that the stamp took too long to check the sensors before it came back and
decided on a different gosub, causing the robot to "studder". I thought
using 2 stamps would eliminat the problem by having one always monitor the
sensors and the other one make the decisions (serial communication). This
did not solve my problem. I'm all out of ideas. The only thing I can imagine
would be to try to use an extra servo controller, but would that still take
too long? Would and extra controller shorten the code and therefor the
stamps reaction time?
Thanks to all with input :-)
John Baker
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and Body of
the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
have a very nasty timing problem. Because the serial that the stamp uses is
asynchronous (unless you do a couple weird things like shiftin/shiftout),
synchronization problems crop up all the time. You seem to have a lot of
pauses in your code for no apparent reason. For instance, I fail to see why
you need the 10ms pause after reading each sensor, and I don't see any
purpose in the 25ms pause after sending. Your decision stamp will wait
FOREVER if it doesn't receive any incoming serial data, and then you have it
pause 10ms after waiting an indeterminate amount of time... You best-case
scenario is going to be a 65ms pause between sends/receives on the serial
line. It's likely to be a lot longer than that because the stamp has no
serial buffer, and if it misses the data once, it has to wait until it shows
up again. I'd suggest putting some timeouts on your serin statements and
removing or decreasing the pauses strewn about your code (unless they have
some purpose I'm unaware of...). Most servos are quite tolerant about their
pulse spacing, accepting anything from 5ms to 40ms or longer. But you're
probably in the 100-200ms range. And then once your code receives a
command, it will output to the motors for an arbitrary number of cycles,
pausing in between them (which means the odds of missing the next command
are very high). By including a timeout on your serin statement in the
decision stamp, you can eliminate the loops that output to the servos. I
believe that will solve (or at least help) your problem.
Ryan
Original Message
From: John Baker [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=F033wT_Oe4VS2A8f4yyezgIal2ECDtUBMhfo5MhJAWdF_bznygtVI5x66_t1A97pyJOEjoGPQTygsQ4V36CizVg]johnbaker_erie_pa@y...[/url
Sent: Thursday, August 07, 2003 3:59 PM
To: basicstamps@yahoogroups.com
Subject: RE: [noparse][[/noparse]basicstamps] BS2 decision making time
Thank you Ryan. Here is some sample code that might help everyone understand
my problem more.
'{$STAMP BS2}
'Decision making stamp
Letter VAR Byte 'incoming Serial data variable from check (ultrasonics)
a VAR Word
LOW 14 'left servo
LOW 15 'right servo
start:
GOSUB check
IF Letter = "F" THEN nextpartofmaze 'turn left after first hall (front
sensor)
IF Letter = "L" THEN Radjust1 'too close to wall on left
IF Letter = "R" THEN Ladjust1 'too close to wall on right
GOSUB forward
GOTO start
Check:
SERIN 10,16468, [noparse][[/noparse]Letter] 'Get sensor status
PAUSE 10
RETURN
forward:
FOR a = 1 TO 10
PULSOUT 14,1000
PULSOUT 15,500
PAUSE 20
NEXT
RETURN
Radjust1:
FOR a = 1 TO 5
PULSOUT 14,1000
PULSOUT 15,700
PAUSE 20
NEXT
RETURN
Ladjust1:
FOR a = 1 TO 5
PULSOUT 14,800
PULSOUT 15,500
PAUSE 20
NEXT
RETURN
'{$STAMP BS2}
'Sensor Stamp
F_dist VAR Word 'Variable for front sensor
L_dist VAR Word 'Variable for left sensor
R_dist VAR Word 'Variable for right sensor
'
============================
F_init CON 0 'P0 is the Pin for front's initial pulse
F_echo CON 1 'P1 is the pin for front's input
L_init CON 2 'P2 is the pin for left's initial pulse
L_echo CON 3 'P3 is the pin for left's input
R_init CON 4 'P4 is the pin for right's inital pulse
R_echo CON 5 'P5 is the pin for right's input
'
============================
Main:
GOSUB check
IF F_dist < 10 THEN sendf
IF L_dist < 15 THEN sendl
IF R_dist < 15 THEN sendr
GOTO main
check:
PULSOUT F_init,5
OUTPUT F_init 'Delay
RCTIME F_echo,1,F_dist
PAUSE 10
PULSOUT L_init,5
OUTPUT L_init
RCTIME L_echo,1,L_dist
PAUSE 10
PULSOUT R_init,5
OUTPUT R_init,5
RCTIME R_echo,1,R_dist
PAUSE 10
RETURN
sendf:
SEROUT 10,16468,[noparse][[/noparse]"F"]
PAUSE 25
GOTO Main
sendl:
SEROUT 10,16468,[noparse][[/noparse]"L"]
PAUSE 25
GOTO Main
sendr:
SEROUT 10,16468,[noparse][[/noparse]"R"]
PAUSE 25
GOTO Main
My problem persists. Please help. Thank you.
Ryan.D.Meador@e... wrote:
Your post is lacking the details I'd like to see, but even so, I have two
possibilities for you.
Possibility A:
If you're using servos as the drive system, it could be that polling the
sensors takes so long that it can't output pulses to the servos often
enough, so the go in fits and starts. If this is the case, I'd think that 2
stamps would solve the problem. It's exactly the problem I wrestled with
when I built a robot that used serial communications from my laptop to
control it. If you make the stamp responsible for outputting to the servos
output in a loop, making use of the SERIN statement's timeout feature, then
it will always output to the servos. There may be a tiny hiccup when the
sensor stamp actually sends new data to the PWM stamp, but it will be minute
(assuming your baud rate is decent... 4800 or 9600 should be fine).
Possibility B:
The problem isn't anything at all to do with your stamp taking too much time
and is instead a problem with your finite state machine. I'm assuming that
when the sensors detect an object, it enters an "avoid obstacle" state. It
could be that the sensors are intermittently detecting the obstacle (perhaps
it's at the edge of range, or by turning slightly it is no longer being
"seen"). Depending on your FSM architecture, this could cause rapid state
shifts and thus the jerky movement.
There are no doubt more possibilities, but they require more knowledge of
your project. This doesn't fit the current situation perfectly, but here's
a link that everyone on this list should read before posting a message, to
get an idea of what to include:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Hope I helped,
Ryan
Original Message
From: John Baker [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=F033wT_Oe4VS2A8f4yyezgIal2ECDtUBMhfo5MhJAWdF_bznygtVI5x66_t1A97pyJOEjoGPQTygsQ4V36CizVg]johnbaker_erie_pa@y...[/url
Sent: Thursday, August 07, 2003 1:59 PM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] BS2 decision making time
Hello everyone. I have a problem with my robot. A little background: It is a
Firefighting robot for Trinity. It uses a single Basic Stamp to monitor
ultrasonics (Devantech SRF04s) and avoid walls accordingly. My problem was
that the stamp took too long to check the sensors before it came back and
decided on a different gosub, causing the robot to "studder". I thought
using 2 stamps would eliminat the problem by having one always monitor the
sensors and the other one make the decisions (serial communication). This
did not solve my problem. I'm all out of ideas. The only thing I can imagine
would be to try to use an extra servo controller, but would that still take
too long? Would and extra controller shorten the code and therefor the
stamps reaction time?
Thanks to all with input :-)
John Baker
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[noparse][[/noparse]Non-text portions of this message have been removed]
debugging readings with varied pause for a reason I did not understand. The
pauses helped to regulate the flow of data I was recieving on the screen.
I would have never thought of a timeout. Thanks a lot!
John Baker
Ryan.D.Meador@e... wrote:
That's much better! I've got another idea or two for you. I believe you
have a very nasty timing problem. Because the serial that the stamp uses is
asynchronous (unless you do a couple weird things like shiftin/shiftout),
synchronization problems crop up all the time. You seem to have a lot of
pauses in your code for no apparent reason. For instance, I fail to see why
you need the 10ms pause after reading each sensor, and I don't see any
purpose in the 25ms pause after sending. Your decision stamp will wait
FOREVER if it doesn't receive any incoming serial data, and then you have it
pause 10ms after waiting an indeterminate amount of time... You best-case
scenario is going to be a 65ms pause between sends/receives on the serial
line. It's likely to be a lot longer than that because the stamp has no
serial buffer, and if it misses the data once, it has to wait until it shows
up again. I'd suggest putting some timeouts on your serin statements and
removing or decreasing the pauses strewn about your code (unless they have
some purpose I'm unaware of...). Most servos are quite tolerant about their
pulse spacing, accepting anything from 5ms to 40ms or longer. But you're
probably in the 100-200ms range. And then once your code receives a
command, it will output to the motors for an arbitrary number of cycles,
pausing in between them (which means the odds of missing the next command
are very high). By including a timeout on your serin statement in the
decision stamp, you can eliminate the loops that output to the servos. I
believe that will solve (or at least help) your problem.
Ryan
Original Message
From: John Baker [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=22Xbt9_rlZG1RgYb8yM-8hOK8crSeQEDhdzd4SHEr0N9_NNN7gu9refheshw1Ozr09BBex01VZLLE70k9m11XUWJgw]johnbaker_erie_pa@y...[/url
Sent: Thursday, August 07, 2003 3:59 PM
To: basicstamps@yahoogroups.com
Subject: RE: [noparse][[/noparse]basicstamps] BS2 decision making time
Thank you Ryan. Here is some sample code that might help everyone understand
my problem more.
'{$STAMP BS2}
'Decision making stamp
Letter VAR Byte 'incoming Serial data variable from check (ultrasonics)
a VAR Word
LOW 14 'left servo
LOW 15 'right servo
start:
GOSUB check
IF Letter = "F" THEN nextpartofmaze 'turn left after first hall (front
sensor)
IF Letter = "L" THEN Radjust1 'too close to wall on left
IF Letter = "R" THEN Ladjust1 'too close to wall on right
GOSUB forward
GOTO start
Check:
SERIN 10,16468, [noparse][[/noparse]Letter] 'Get sensor status
PAUSE 10
RETURN
forward:
FOR a = 1 TO 10
PULSOUT 14,1000
PULSOUT 15,500
PAUSE 20
NEXT
RETURN
Radjust1:
FOR a = 1 TO 5
PULSOUT 14,1000
PULSOUT 15,700
PAUSE 20
NEXT
RETURN
Ladjust1:
FOR a = 1 TO 5
PULSOUT 14,800
PULSOUT 15,500
PAUSE 20
NEXT
RETURN
'{$STAMP BS2}
'Sensor Stamp
F_dist VAR Word 'Variable for front sensor
L_dist VAR Word 'Variable for left sensor
R_dist VAR Word 'Variable for right sensor
'
============================
F_init CON 0 'P0 is the Pin for front's initial pulse
F_echo CON 1 'P1 is the pin for front's input
L_init CON 2 'P2 is the pin for left's initial pulse
L_echo CON 3 'P3 is the pin for left's input
R_init CON 4 'P4 is the pin for right's inital pulse
R_echo CON 5 'P5 is the pin for right's input
'
============================
Main:
GOSUB check
IF F_dist < 10 THEN sendf
IF L_dist < 15 THEN sendl
IF R_dist < 15 THEN sendr
GOTO main
check:
PULSOUT F_init,5
OUTPUT F_init 'Delay
RCTIME F_echo,1,F_dist
PAUSE 10
PULSOUT L_init,5
OUTPUT L_init
RCTIME L_echo,1,L_dist
PAUSE 10
PULSOUT R_init,5
OUTPUT R_init,5
RCTIME R_echo,1,R_dist
PAUSE 10
RETURN
sendf:
SEROUT 10,16468,[noparse][[/noparse]"F"]
PAUSE 25
GOTO Main
sendl:
SEROUT 10,16468,[noparse][[/noparse]"L"]
PAUSE 25
GOTO Main
sendr:
SEROUT 10,16468,[noparse][[/noparse]"R"]
PAUSE 25
GOTO Main
My problem persists. Please help. Thank you.
Ryan.D.Meador@e... wrote:
Your post is lacking the details I'd like to see, but even so, I have two
possibilities for you.
Possibility A:
If you're using servos as the drive system, it could be that polling the
sensors takes so long that it can't output pulses to the servos often
enough, so the go in fits and starts. If this is the case, I'd think that 2
stamps would solve the problem. It's exactly the problem I wrestled with
when I built a robot that used serial communications from my laptop to
control it. If you make the stamp responsible for outputting to the servos
output in a loop, making use of the SERIN statement's timeout feature, then
it will always output to the servos. There may be a tiny hiccup when the
sensor stamp actually sends new data to the PWM stamp, but it will be minute
(assuming your baud rate is decent... 4800 or 9600 should be fine).
Possibility B:
The problem isn't anything at all to do with your stamp taking too much time
and is instead a problem with your finite state machine. I'm assuming that
when the sensors detect an object, it enters an "avoid obstacle" state. It
could be that the sensors are intermittently detecting the obstacle (perhaps
it's at the edge of range, or by turning slightly it is no longer being
"seen"). Depending on your FSM architecture, this could cause rapid state
shifts and thus the jerky movement.
There are no doubt more possibilities, but they require more knowledge of
your project. This doesn't fit the current situation perfectly, but here's
a link that everyone on this list should read before posting a message, to
get an idea of what to include:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Hope I helped,
Ryan
Original Message
From: John Baker [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=22Xbt9_rlZG1RgYb8yM-8hOK8crSeQEDhdzd4SHEr0N9_NNN7gu9refheshw1Ozr09BBex01VZLLE70k9m11XUWJgw]johnbaker_erie_pa@y...[/url
Sent: Thursday, August 07, 2003 1:59 PM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] BS2 decision making time
Hello everyone. I have a problem with my robot. A little background: It is a
Firefighting robot for Trinity. It uses a single Basic Stamp to monitor
ultrasonics (Devantech SRF04s) and avoid walls accordingly. My problem was
that the stamp took too long to check the sensors before it came back and
decided on a different gosub, causing the robot to "studder". I thought
using 2 stamps would eliminat the problem by having one always monitor the
sensors and the other one make the decisions (serial communication). This
did not solve my problem. I'm all out of ideas. The only thing I can imagine
would be to try to use an extra servo controller, but would that still take
too long? Would and extra controller shorten the code and therefor the
stamps reaction time?
Thanks to all with input :-)
John Baker
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[noparse][[/noparse]Non-text portions of this message have been removed]
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and Body of
the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
<commercial>
I'd really like to sell you a Co-Processor to replace one of your
Stamps and do the servo driving. www.bluebelldesign.com
<commercial over>
That being said, lets look at what you have already and what you
can do with it.
Several things come to mind when looking at your code.
1. Look at forward: - you are doing PULSOUTs of 3 ms followed by a
20 ms wait. While you need the wait for the servos, you could reduce
the PAUSE to 17 ms for a total time of 20 ms. Notice though, you are
looping 10 times for a total "blind time" for the Stamp of 230 ms!
During that time nothing happens in the Stamp except the pulsing. (A
servo controller would take care of that for you.) However, if you
could integrate the sensing into the loop, it would be much more
responsive. (See more about that below.)
2. When you get the sensor status you get 3 BITs if information by
sending and receiving 3 BYTEs of message (with delays between them
too). Why not compose the message by using 3 of the bits of a single
message byte? That way you can send only one byte and be lots
quicker.
3. Doing RCTIMEs for the SONARs means you don't know how long the
code takes to finish. If you did know, and it was quick enough, you
could use just one Stamp for the job. Added benefit, no serial
issues to contend with.
(I must be missing something here - RCTIME is in units of 2 us. You
are looking for less than 10 or 15 on the outputs. That is 20 or 30
microseconds. Is that correct? I believe round trip for sound takes
147.7us/inch. I don't think most SONAR is accurate at fractions of
an inch. What distances are you looking for?)
Anyway, back to my point. Instead of measuring the pulsewidth from
the SONAR, why not ask if it is done by the limit time.
PULSOUT L_init,5
OUTPUT L_init
PAUSE ' If PAUSE is too coarse
' in resolution, use dummy
' instructions to delay the
' right amount of time (distance).
IF L_echo THEN ... ' If it is done by now, you are too close
Depending on the distance you are looking for, this could have two
advantages. First, you know how long the test takes. Second, if the
time is small enough, you can integrate it into the servo code and
do away with one of your Stamps (HEY! Then you wouldn't need my Co-
Processor either! - er, forget I said that).
Integrating sensing while controlling servos is the subject
of "Chapter #8: Real-Time Programming" in the new "Advanced Robotics
with the Toddler - Student Guide - VERSION 1.2". It now available on
the Parallax website. Good reading - and FREE!
Harry
Stamp Robotics to the next level
www.bluebelldesign.com
--- In basicstamps@yahoogroups.com, John Baker
<johnbaker_erie_pa@y...> wrote:
> Thank you Ryan. Here is some sample code that might help everyone
understand my problem more.
>
> '{$STAMP BS2}
> 'Decision making stamp
> Letter VAR Byte 'incoming Serial data variable from check
(ultrasonics)
> a VAR Word
> LOW 14 'left servo
> LOW 15 'right servo
> start:
> GOSUB check
> IF Letter = "F" THEN nextpartofmaze 'turn left after first hall
(front sensor)
> IF Letter = "L" THEN Radjust1 'too close to wall on left
> IF Letter = "R" THEN Ladjust1 'too close to wall on right
> GOSUB forward
> GOTO start
> Check:
> SERIN 10,16468, [noparse][[/noparse]Letter] 'Get sensor status
> PAUSE 10
> RETURN
>
> forward:
> FOR a = 1 TO 10
> PULSOUT 14,1000
> PULSOUT 15,500
> PAUSE 20
> NEXT
> RETURN
> Radjust1:
> FOR a = 1 TO 5
> PULSOUT 14,1000
> PULSOUT 15,700
> PAUSE 20
> NEXT
> RETURN
> Ladjust1:
> FOR a = 1 TO 5
> PULSOUT 14,800
> PULSOUT 15,500
> PAUSE 20
> NEXT
> RETURN
>
> '{$STAMP BS2}
> 'Sensor Stamp
> F_dist VAR Word 'Variable for front sensor
> L_dist VAR Word 'Variable for left sensor
> R_dist VAR Word 'Variable for right sensor
> '
============================
> F_init CON 0 'P0 is the Pin for front's initial pulse
> F_echo CON 1 'P1 is the pin for front's input
> L_init CON 2 'P2 is the pin for left's initial pulse
> L_echo CON 3 'P3 is the pin for left's input
> R_init CON 4 'P4 is the pin for right's inital pulse
> R_echo CON 5 'P5 is the pin for right's input
> '
============================
> Main:
> GOSUB check
> IF F_dist < 10 THEN sendf
> IF L_dist < 15 THEN sendl
> IF R_dist < 15 THEN sendr
> GOTO main
> check:
> PULSOUT F_init,5
> OUTPUT F_init 'Delay
> RCTIME F_echo,1,F_dist
> PAUSE 10
> PULSOUT L_init,5
> OUTPUT L_init
> RCTIME L_echo,1,L_dist
> PAUSE 10
> PULSOUT R_init,5
> OUTPUT R_init,5
> RCTIME R_echo,1,R_dist
> PAUSE 10
> RETURN
> sendf:
> SEROUT 10,16468,[noparse][[/noparse]"F"]
> PAUSE 25
> GOTO Main
> sendl:
> SEROUT 10,16468,[noparse][[/noparse]"L"]
> PAUSE 25
> GOTO Main
> sendr:
> SEROUT 10,16468,[noparse][[/noparse]"R"]
> PAUSE 25
> GOTO Main
>
> My problem persists. Please help. Thank you.
>
>
> Ryan.D.Meador@e... wrote:
> Your post is lacking the details I'd like to see, but even so, I
have two
> possibilities for you.
>
> Possibility A:
> If you're using servos as the drive system, it could be that
polling the
> sensors takes so long that it can't output pulses to the servos
often
> enough, so the go in fits and starts. If this is the case, I'd
think that 2
> stamps would solve the problem. It's exactly the problem I
wrestled with
> when I built a robot that used serial communications from my
laptop to
> control it. If you make the stamp responsible for outputting to
the servos
> output in a loop, making use of the SERIN statement's timeout
feature, then
> it will always output to the servos. There may be a tiny hiccup
when the
> sensor stamp actually sends new data to the PWM stamp, but it will
be minute
> (assuming your baud rate is decent... 4800 or 9600 should be fine).
>
> Possibility B:
> The problem isn't anything at all to do with your stamp taking too
much time
> and is instead a problem with your finite state machine. I'm
assuming that
> when the sensors detect an object, it enters an "avoid obstacle"
state. It
> could be that the sensors are intermittently detecting the
obstacle (perhaps
> it's at the edge of range, or by turning slightly it is no longer
being
> "seen"). Depending on your FSM architecture, this could cause
rapid state
> shifts and thus the jerky movement.
>
> There are no doubt more possibilities, but they require more
knowledge of
> your project. This doesn't fit the current situation perfectly,
but here's
> a link that everyone on this list should read before posting a
message, to
> get an idea of what to include:
> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
>
> Hope I helped,
> Ryan
>
>
Original Message
> From: John Baker [noparse][[/noparse]mailto:johnbaker_erie_pa@y...]
> Sent: Thursday, August 07, 2003 1:59 PM
> To: basicstamps@yahoogroups.com
> Subject: [noparse][[/noparse]basicstamps] BS2 decision making time
>
>
> Hello everyone. I have a problem with my robot. A little
background: It is a
> Firefighting robot for Trinity. It uses a single Basic Stamp to
monitor
> ultrasonics (Devantech SRF04s) and avoid walls accordingly. My
problem was
> that the stamp took too long to check the sensors before it came
back and
> decided on a different gosub, causing the robot to "studder". I
thought
> using 2 stamps would eliminat the problem by having one always
monitor the
> sensors and the other one make the decisions (serial
communication). This
> did not solve my problem. I'm all out of ideas. The only thing I
can imagine
> would be to try to use an extra servo controller, but would that
still take
> too long? Would and extra controller shorten the code and therefor
the
> stamps reaction time?
>
> Thanks to all with input :-)
> John Baker
>
>
>
>
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
>
> [noparse][[/noparse]Non-text portions of this message have been removed]
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the
Subject and
> Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>
> [noparse][[/noparse]Non-text portions of this message have been removed]
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the
Subject and Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>
>
>
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
>
> [noparse][[/noparse]Non-text portions of this message have been removed]
code (X_dist/29) appox. 29 units in one centimeter from the SONAR. Maybe this
answers your question. I'll take a look at the co-processor.
Thanks, John
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
[noparse][[/noparse]Non-text portions of this message have been removed]
You're very welcome!
If your distances are 10 cm and 15 cm, and your actual SONAR counts
are 290 (= 10X29) and 435 (= 15X29), why do a conversion at all? It
takes time to divide and you are only going to compare to a fixed
number anyway. Just do the comparison to 290 or 435 instead.
Another point I didn't mention, the Stamp doesn't have buffered
serial ports so you can't just randomly send the motion Stamp data
from the sensor Stamp. the motion Stamp needs to be expecting it.
Since you are looking for small time delays (580 and 870 uSec) you
could use a code loop delay like other posts are talking about now
and just use one Stamp instead of two.
Harry
Stamp Robotics to the next level
www.bluebelldesign.com
--- In basicstamps@yahoogroups.com, John Baker
<johnbaker_erie_pa@y...> wrote:
> Thanks alot Harry! By the way, I forgot to include my conversion
factor in the code (X_dist/29) appox. 29 units in one centimeter
from the SONAR. Maybe this answers your question. I'll take a look
at the co-processor.
>
> Thanks, John
The best I remember:
2 Sharp, 1 Devantech, 2 Servos and Buffered Background RS232 up to 57k baud.
All for <$12 - See Timing trace full details here:
www.rhombus-tek.com/SMt_Rob.htm
and BS2 Code here:
www.rhombus-tek.com/GreenBS2.ZIP
David Lawrence
Original Message
From: John Baker <johnbaker_erie_pa@y...>
To: <basicstamps@yahoogroups.com>
Sent: Friday, August 08, 2003 4:46 PM
Subject: Re: [noparse][[/noparse]basicstamps] Re: BS2 decision making time
> Thanks alot Harry! By the way, I forgot to include my conversion factor in
the code (X_dist/29) appox. 29 units in one centimeter from the SONAR. Maybe
this answers your question. I'll take a look at the co-processor.
>
> Thanks, John
>
>
>
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
>
> [noparse][[/noparse]Non-text portions of this message have been removed]
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>