random direction L298 driver

I am using a Solarbotics L298 driver board to run a geared motor, random direction, random speed. The speed should be determined by an Max sonar sensor. The sketch stops randomly, but direction is only one way and doesn't respond to the sensor which reads 120 ~ 15. Must be doing just about everything wrong! I have scoured the web for examples have found nothing helpful.

int randNumberDir;  // variable to store the random direction value
int motorSpeed = 8; // motor speed
int motorDir = 9; // motor direction
long previousMillis =0;
long interval = 500;
int enable = 10;
int sonarPin =A0;
int value;

void setup()
{
Serial.begin(9600);

randomSeed(millis());

pinMode(motorSpeed,OUTPUT);
pinMode(motorDir,OUTPUT);
pinMode(sonarPin,INPUT);

digitalWrite(motorSpeed,HIGH);
digitalWrite(motorDir,HIGH);
digitalWrite(enable,HIGH);
}
void loop()
{
randNumberDir = random(255); // random number from 0-255
analogWrite(motorDir, randNumberDir); // outputs PWM signal
delay(500); // pauses for half a second

value = analogRead(sonarPin);
Serial.println(value);

int motor_speed = value/4;
analogWrite(motorSpeed,motor_speed);
}
void motorStop(){

if(millis() - previousMillis  > interval) {
   digitalWrite(motorDir,HIGH);
   digitalWrite(motorSpeed,LOW);
   digitalWrite(enable,LOW);
   previousMillis = millis();
}
delay(1000);

}

If speed is controlled by a sensor, is it random?

I am familiar only with a cheap ultrasonic sonar module. It emits an 8-wave sound pulse when I toggle 1 pin HIGH then LOW. Another pin then goes from LOW to HIGH and drops back to LOW when the echo returns. I have to time the HIGH to LOW and turn that into distance. All those are digital, the analog is distance is calculated.

Where did you find a sonar that gives analog data directly? That would save code and cycles!

i did some digging so heres a link that might interest you https://content.solarbotics.com/products/documentation/kcmd_manual_v1-4.pdf and you should find the L298 Datasheet

to simplify
if you pwm the enable you could actually control the speed
for direction you need to make the 2 other pin inverted from each other
meaning that if pin1 high pin 2 must be low and vice versa
anyway could you please explain what you want your aduino to be doing?

i did serch his sensor type, i think youwould love this link

Thanks Ash, that is cool but the sensors I have cost me less than $2 each!

They have 15 degree spread and supposedly can be good to 2mm. I get maybe 1 or 2 cm just using a +/- 33 usec deadzone to kill the variation coming back rather than data averaging. That's just setting the thing down on the desk with object or wall inches to a foot or so away. I am pretty sure I can do better but all I wanted then was to check function. The idea was for a car-backup helper but since then weather became an issue. IMO the thing needs to be coupled with a temperature sensor to stay near correct from summer to winter.

I endorse what Ash has said.

The board has 2 inputs that control the direction of each motor and 1 that enables/disables the motor

Setting input L1 HIGH and L2 LOW and Enable HIGH will should cause the motor to run in one direction and reversing the states of L1 and L2 will make it run the other way. Putting a PWM signal on Enable will allow you to control the speed of the motor.

In your sketch you have pins defined as follows

int motorSpeed = 8; // motor speed
int motorDir = 9; // motor direction
int enable = 10;

Which inputs of the motor board (L1, L2, Enable) are each of them connected to ?

There are alternative ways of controlling the motor speed by putting PWM on the motor inputs (L1, L2) but that is more unusual although it is how the on line manual for the board suggests that you do it.

Forget the sensor for now. Have you written a sketch that runs the motor at different speeds using either method ?

Yes, I have a sketch that runs the motor in different directions by alternating the two pins - HIGH/LOW - LOW/HIGH. The problem is random direction. I wonder if a dumb dumb method might involve creating random numbers of say, 1000, then an "if", "else" statement that runs the motor forward >500, or backward <500?

  randNumberDir = random(255); // random number from 0-255
  analogWrite(motorDir, randNumberDir); // outputs PWM signal
  delay(500); // pauses for half a second

This is putting a PWM signal on the pin that you seem to want to use to determine which direction the motor spins. PWM signals swing between LOW and HIGH very quickly but the direction pin must be set to HIGH or LOW in order to set the direction.

As you suggest, it would be better to generate a random number then, depending in its value, set the direction explicitly by setting the direction pin to either HIGH or LOW explcitly.

technically speaking, since there is only 2 state why not just put random(2)?
0 being forward and 1 being backward?

random() is, of course, not random at all as it generates the same sequence of numbers each time depending on where it starts. This can be influenced by using randomSeed().

When I was experimenting with a vehicle, I called random() each time through loop() and discarded the result, then called it to determine which way to turn when backing away from an obstacle. My theory was that the function would be called a variable number of times before the value was needed because the number of times that it was called depended on how far the vehicle travelled.

Was this a fair assumption ?

If I use the "two state", I assume a delay for the minimum duration is necessary?

UKHeliBob:
random() is, of course, not random at all as it generates the same sequence of numbers each time depending on where it starts. This can be influenced by using randomSeed().

When I was experimenting with a vehicle, I called random() each time through loop() and discarded the result, then called it to determine which way to turn when backing away from an obstacle. My theory was that the function would be called a variable number of times before the value was needed because the number of times that it was called depended on how far the vehicle travelled.

Was this a fair assumption ?

If the run time is going to have any slop in it then the low order bits of micros() should make a good random seed. User action timing is another good one, I've worked that with PC keyboard clock ticks (something like 18.2/sec) before. Even at that scale, humans are quite random.