DPRG List  

DPRG: Sbasic , gambling , and probability

Subject: DPRG: Sbasic , gambling , and probability
From: Eric B. Olsen robojoc at worldnet.att.net
Date: Sun Jan 11 12:19:37 CST 1998


I'm glad to see someone talk about the need for random generators in robotics
.... you're right, it's a very important ingredient.

As I work in the gaming equipment manufacturing field (as in gambling!), I may
be able to help you a little.  Do you need help with a random number generator
for you application?
I'd give you some stuff now, but it's going to take a little research first.

Eric Olsen.

Corey Hansen wrote:

> Hi,
> Alright here's the thing:
> I'm building a robot that will learn , or at least I hope it will. To do
> this I am attempting it with Sbasic. My plan is to have a simple
> platform;wood , wheels , motors , caster , batteries , brain , and some
> stray electronics. The brain is HC11 based. The robot , for now , will have
> 8 inputs , 3 IR , 4 bumper switches , and a Cds cell set to be tripped at a
> certain light level. The motors will be driven by a classic H-bridge.
> OK , there are 8 inputs , which can be represented by a one byte wide
> variable. Since there are 256 different combinations of sensor input , there
> will be 256 different situations for the robot to learn what is best to do.
> To know what is best to do , the robot needs a goal , which will be to stay
> away from things. To learn the robot needs to experiment , and have some
> randomness , mixed with probability. To do this all of the combinations have
> 7 variables to represent motor output. What the robot needs to have is a
> number of effectiveness inside each variable , to start say 128.
> The robot needs to choose which of the motor outputs to use , according to
> probability and randomness. For this to work the robot needs to stage a
> 'gambling' effect with the motor outputs. At the start all the variables
> have 128 probability of being chosen , here's where randomness is needed. I
> need the robot to choose which output would work best by experience.
> Whichever output is chosen must be tested for effectiveness. After the
> output is executed the robot needs to wait for the inputs to change , when
> they do it needs to determine if more sensors went on or off. Since the goal
> is avoiding things , the lower the byte wide variable
> representing inputs is , the better , or vice versa. Now that it has
> determined if that move was a good or bad , the robot needs to change the 7
> variables. If the move was good , then the robot needs to add 1 to the
> variable representing the move , and minus 1 from the rest. Now the cycle
> repeats.
> What I'm having a problem with is 'gambling' for the right motor output ,
> while pay attention to the necessary probability. If anyone would like to
> help it would be greatly appreciated.
> :David
> davehansen at geocities.com

- --

"Time will tell if the human race can handle the responsibility of it's own

Spectronix, Inc.
Email:  robojoc at worldnet.att.net
Henderson, NV


More information about the DPRG mailing list