OK, so I let curiosity get the better of me, and I went ahead and pulled the transducers off the circuit board and was pleasantly surprised to see they are marked with a T and an R. That absolutely answers one of my questions.
This does lead me to a new question though.
Lets say I am able to get this second pair working.
If I mount them on the front of my bot, with a transmit on one side, pointing at an angle and I set the receiver on the other side of the car but pointing the same angle as the first one, then take the second set and do the same but pointing at a different angle.
(horrible sentence structure, I know but I am starting to confuse myself here...)
with the way I picture this setup, the ultrasonic pings would basically cross each others path. would the sound waves interfere with each other and cause my data to be bad?
seems likely they would interfere, but I don't know.
That does seem like a good way to get a nice wide range with them and not overlap too much or leave too much of a blind spot in the middle.
position them in a way that the transmission from one wouldn't be able to hit the receiver of the other. point them just off from each others angles so they don't overlap, but they do point away from each other.
if this is making any sense at all I am thrilled. communication of ideas isn't my strong suit. I am much better at just building what I think about and try not to venture into asking questions when I don't have to
So basically, it sounds like I would at least need a temperature sensor for the pair without a circuit, because sound waves travel at different speeds in different temps (something else I learned on this search!)
What I am hoping is, I can use a temp sensor and the transducers off the bad ping sensor with just the arduino clock and get results, then use the other PING sensor that is still working to feed in the other result, and allow my bot to make decisions based on more incoming data.
What I would eventually like to get to, is the bot will take in both sets of data and then steer himself into the most wide open spaces he can, rather than just try and dodge at the last minute. Then I might be able to set up a maze style obstacle course and see if the bot can navigate the paths. I don't expect it to solve the maze or anything, just be able to steer around in tight environments without having any outside input, and without having to constantly stop and back up to adjust steering.
If you have followed along this far, thank you. You are clearly a patient person
I figure if I share what my goals are here, perhaps someone might even be able to suggest an easier option that what I am thinking of, mostly because I am pretty sure what I have in my head wont work due to interference and the complication of only having one working PING sensor and some loose transducers...
Just for good measure, this is the code I am using at the moment.
// Using Seeed Motor Shield with L298 dual H bridge and PING))) distance sensor to drive a converted RC car robot
#include <NewPing.h> //use NewPing library for the PING))) sensor.
#define triggerPin 4 // define triggerPin on Arduino Pin 7
#define echoPin 4 // define echoPin on Arduino Pin 7
#define maxDistance 400 // define maxDistance as 400cm
#define Iterations 10 // define Iterations as 10
NewPing sonar(triggerPin, echoPin, maxDistance); // set sonar with the triggerPin, echoPin, and set maxDistance
const int minDist = 0; // set minimum distance = 0 for switch case
const int maxDist = 300; // set maximum distance = 160cm for switch case
const int motorA2 = 8; // set L298 input 1 as motorA2 on Arduino Pin 8
const int motorA1 = 11; // set L298 input 2 as motorA1 on Arduino Pin 11
const int motorA = 9; // set L298 output 1 as motorA on Arduino PWM pin 9 (drive motor)
const int motorB2 = 12; // set L298 input 3 as motorB2 on Arduino Pin 12
const int motorB1 = 13; // set L298 input 4 as motorB1 on Arduino Pin 13
const int motorB = 10; // set L298 output 2 as motorB on Arduino PWM pin 10 (turn motor)
void setup()
{
pinMode(motorA1, OUTPUT); // set motor pins as output
pinMode(motorA2, OUTPUT);
pinMode(motorA, OUTPUT);
pinMode(motorB1, OUTPUT);
pinMode(motorB2, OUTPUT);
pinMode(motorB, OUTPUT);
}
void loop()
{
delay(30); //delay 30 milliseconds
//this sets the data coming from the PING))) sensor to integer uSeconds. This takes 10 readings
//from the sensor and avrages them for better accuracy.
unsigned int uSeconds = sonar.ping_median(Iterations);
//maps the data coming from the PING))) sensor to one of 4 options to be handled by the switch case
int Speed = map(uSeconds / US_ROUNDTRIP_CM, minDist, maxDist, 4, 1);
//if statement to handle any sensor readings higher than 160cm
if(uSeconds / US_ROUNDTRIP_CM >= maxDist)
{
analogWrite(motorA, 255); //Drive forward at full speed
digitalWrite(motorB, LOW);
digitalWrite(motorA1, LOW);
digitalWrite(motorA2, HIGH);
}
switch(Speed) //This switch takes the distance readings that were mapped to four options and decides what to
//do based on how close the robot is to an object case 1 is farthest away, case 4 is closest.
{
case 1: //drive forward, but at a slower speed
analogWrite(motorA, 200);
digitalWrite(motorB, LOW);
digitalWrite(motorA1, LOW);
digitalWrite(motorA2, HIGH);
break;
case 2:
analogWrite(motorA, 150);
digitalWrite(motorB, LOW);
digitalWrite(motorA1, LOW);
digitalWrite(motorA2, HIGH);
break;
case 3: //slow down even more and turn right while still going forward
analogWrite(motorA, 125);
analogWrite(motorB, 175);
digitalWrite(motorA1, LOW);
digitalWrite(motorA2, HIGH);
digitalWrite(motorB1, HIGH);
digitalWrite(motorB2, LOW);
break;
case 4: //stop and back up while turning right for a half second, then stop again
digitalWrite(motorA, LOW);
digitalWrite(motorB, LOW);
analogWrite(motorA, 150);
analogWrite(motorB, 175);
digitalWrite(motorA1, HIGH);
digitalWrite(motorA2, LOW);
digitalWrite(motorB1, LOW);
digitalWrite(motorB2, HIGH);
break;
}
}
Still have some minor tweaking to do on this code to get the bot to stop and back up just a pinch earlier. He doesn't hit too many objects anymore, but he does tend to just nudge them with the front bumper before he actually starts to back up. probably try and get him to stop one or two inches earlier, and keep him from hitting anything he can see.
only having the one pair of eyes facing only forward isn't the best way to do this.
I have seen some people using servos to turn the eyes to look around, but this also seems clumsy to me, and I would like a pretty smooth running machine if it is possible with this kind of simple setup.
I am pretty happy with the code as I have it wrote though, it is easily tweakable, and simple enough to follow, and it works when things are coming up right in front of the bot. Now I just want to increase his field of vision and make him a bit smarter. buying more PING sensors for this kind of project doesn't seem all that cost effective, which is why I started looking down this path in the first place.
OK, so...
This is everything I can think of to share that may be pertinent information, that way if anyone has any better ideas, or some guidance on how to get my dead eyes working again, I would love to hear it!
don't be afraid to criticize me here, I am posting to find where I may be going wrong, and to get suggestions for improvements.
Thanks
N8
