Pages: [1]   Go Down
Author Topic: Broken PING))) hack?  (Read 808 times)
0 Members and 1 Guest are viewing this topic.
Ohio USA
Offline Offline
Jr. Member
**
Karma: 1
Posts: 57
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hello,
I have built an object avoidance robot using an old RC car frame and motors.
It is coming together quite nicely, and at this point I am fine tuning the code.

I am using a PING))) ultrasonic sensor to detect objects, and it has some issues I am trying to solve.  This buggy moves pretty fast, and with the shortcomings of ultrasound, it doesn't avoid objects coming at it from an angle.
Early in this build process I was careless with my setup and burned out the main chip on my first PING))) sensor.  Now I have an idea, but I am not sure it will work.

I would like to pull the "eyes" off the broken sensor and put them to use on my robot.
point them out to the sides at a slight angle to increase the robots vision and perhaps pick up those odd angles a bit better in the process.
Is there a way to use these sensors without the circuit they come on?  I don't have the equipment or experience to use the tiny surface mount parts that comes on the sensor, but I hate to throw out the bad one, they cost too much to just junk it.
Is there a circuit I can build that would allow me to use these additional two eyes?
is it possible to wire the other two eyes in parallel with the two on the working sensor?  (this one sounds like a super long shot, but it was an idea I had so I figured I would ask)

I looked around on the web and noticed some of these sensors do not come with a circuit, so I figure this task shouldn't be out of the question, but I do not know how I would go about making them work without the board they come on.

I am also not sure if both eyes on the sensor are used together (one to send out signal and the other to receive), or if they both send and receive and come up with an average of both readings?

lots of things I don't know at this point, and would really love some guidance.

I am going to keep searching on my own, but if anyone out there has some suggestions, or could point me in the right direction, I would greatly appreciate it!

thanks in advance
N8

Edit to add:
I have done a few google searches, and it seems to me the most likely scenario is the two eyes on the sensor are different.  one to transmit a signal and the other to receive it back.  Most of the transducers (just learned that is what they are called smiley-razz ) you can buy in pairs without a circuit already built onto them are Tx and Rx.  Still no luck finding a way to use them without the pre-built circuit.
confirmation that they are tx and rx and some idea on how to drive them correctly would still be greatly appreciated!
« Last Edit: February 11, 2013, 01:46:19 am by Neight » Logged

absence of proof is not proof of absence

Ohio USA
Offline Offline
Jr. Member
**
Karma: 1
Posts: 57
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley-razz

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 smiley-razz
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.

Code:
// 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
Logged

absence of proof is not proof of absence

Ohio USA
Offline Offline
Jr. Member
**
Karma: 1
Posts: 57
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I have some hope of my idea working now.
Just watched a youtube video of a guy using two different robots at the same time.
both had PING sensors, and they didn't seem to interfere with each other.  In fact, at one point, they avoided each other.
So at least I know my idea is somewhat feasible.

Now if I could only figure out how to drive the second set of eyes without the pre-built circuit they come on...

making progress, I guess.

Sorry I keep posting, but I am trying to figure this out on my own, so I want to keep what I know updated, that way the scope of my question is limited to only what is left to figure out smiley
Logged

absence of proof is not proof of absence

Toledo, OH
Offline Offline
God Member
*****
Karma: 35
Posts: 508
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I have some hope of my idea working now.
Just watched a youtube video of a guy using two different robots at the same time.
both had PING sensors, and they didn't seem to interfere with each other.  In fact, at one point, they avoided each other.
So at least I know my idea is somewhat feasible.

Now if I could only figure out how to drive the second set of eyes without the pre-built circuit they come on...

making progress, I guess.

Sorry I keep posting, but I am trying to figure this out on my own, so I want to keep what I know updated, that way the scope of my question is limited to only what is left to figure out smiley

To be successful with a fast moving robot, first you're going to need to not use any delay statements.  Secondly, doing 10 ping iterations won't be a good idea (takes too long).  I also don't think the max distance of 400cm is a good idea either (maybe 200-300 cm).  Why two different max distance values?

With some cleaning up and rethinking how you will schedule the pings and motor control I think you'll have much better success.  You don't really care about accuracy with something that's moving fast so that's worthless.  More important would be pinging more frequently or using multiple sensors to detect objects better.

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Ohio USA
Offline Offline
Jr. Member
**
Karma: 1
Posts: 57
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


To be successful with a fast moving robot, first you're going to need to not use any delay statements.  Secondly, doing 10 ping iterations won't be a good idea (takes too long).  I also don't think the max distance of 400cm is a good idea either (maybe 200-300 cm).  Why two different max distance values?

With some cleaning up and rethinking how you will schedule the pings and motor control I think you'll have much better success.  You don't really care about accuracy with something that's moving fast so that's worthless.  More important would be pinging more frequently or using multiple sensors to detect objects better.

Tim

Thanks for the reply Tim!

My original code had a handful of delays in it, and I have wrote them all out but that first one.  The 30mS delay at the beginning was in the sample code for the NewPing library, and I wasn't positive that it could be removed.  I was already considering taking out the iterations, or at least reducing them to 3 or 4.  Without the iterations in there, my first bot would stop and turn around at odd times, so they did help that some.  I may just leave 3 iterations in the code to help clean up the occasional bad read from the sensor. 

I have two max distances because I wanted the bot to be able to see out to 400cm, but I wanted it to start reacting at a shorter distance.  That way I could have a full speed ahead mode, and still get the bot to react at different distances.  It is mostly wrote in there for debugging purposes.  If the code gets longer, or more complicated as I make it better, I can still play with the distances it works with and only have to change them in one spot in the code.  That helps me keep things consistent, and not have to search for values to change as I change the code.
It probably isn't needed with how simple the code is right now, but it seemed like a good idea at the time.

The code as it is wrote right now works pretty well, it needs a few minor adjustments, but as long as the bot can see whats coming, even at full speed it does a pretty good job of stopping and dodging.  My first code was horrible, delays in it, my original max distance was 160cm and the thing hit nearly everything it could.  I have come a long way so far refining it, and only have a little bit of adjusting to make it as good as it can get with one fixed sensor in the front.

Eventually I would like to have at least one sensor in the back to it doesn't back into objects when turning around, and minimum two sensors in the front to expand its point of view and angle of view.  Is there a range finding sensor that works better than ultrasound?  I know there are other types out there, but the only one I have right now is the PING.  I would really like to add the transducers from the broken PING sensor, and get them working, but it is really starting to look like it may just be easier to buy more working sensors and use them.  I need to find a cheaper sensor option, these PING sensors are a bit too expensive to justify putting three or four of them on this toy project.
I actually started this just to learn how to accurately drive motors, and this was an easy way to do that with the parts I had available, and still have something fun to use it on, rather than just watching the motors spin on my bench with no purpose.
It helped me understand how to take a sensor reading and get a quick reaction from the sensors based on that.  I have had enough fun building this bot that I am going to leave him together rather than use it's components for something else, but I also don't want to sink a whole lot more money into it, already had to buy the RC car battery he is powered by, and a second PING sensor to replace the one I broke.

I will look around at some different sensors and see if I can't find a cheaper option and buy three or four of them.

Thank you very much for the suggestions!  I will remove that last delay and reduce the iterations.  I agree these things will make it a bit better and response time faster.

N8
Logged

absence of proof is not proof of absence

Toledo, OH
Offline Offline
God Member
*****
Karma: 35
Posts: 508
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


To be successful with a fast moving robot, first you're going to need to not use any delay statements.  Secondly, doing 10 ping iterations won't be a good idea (takes too long).  I also don't think the max distance of 400cm is a good idea either (maybe 200-300 cm).  Why two different max distance values?

With some cleaning up and rethinking how you will schedule the pings and motor control I think you'll have much better success.  You don't really care about accuracy with something that's moving fast so that's worthless.  More important would be pinging more frequently or using multiple sensors to detect objects better.

Tim

Thanks for the reply Tim!

My original code had a handful of delays in it, and I have wrote them all out but that first one.  The 30mS delay at the beginning was in the sample code for the NewPing library, and I wasn't positive that it could be removed.  I was already considering taking out the iterations, or at least reducing them to 3 or 4.  Without the iterations in there, my first bot would stop and turn around at odd times, so they did help that some.  I may just leave 3 iterations in the code to help clean up the occasional bad read from the sensor. 

I have two max distances because I wanted the bot to be able to see out to 400cm, but I wanted it to start reacting at a shorter distance.  That way I could have a full speed ahead mode, and still get the bot to react at different distances.  It is mostly wrote in there for debugging purposes.  If the code gets longer, or more complicated as I make it better, I can still play with the distances it works with and only have to change them in one spot in the code.  That helps me keep things consistent, and not have to search for values to change as I change the code.
It probably isn't needed with how simple the code is right now, but it seemed like a good idea at the time.

The code as it is wrote right now works pretty well, it needs a few minor adjustments, but as long as the bot can see whats coming, even at full speed it does a pretty good job of stopping and dodging.  My first code was horrible, delays in it, my original max distance was 160cm and the thing hit nearly everything it could.  I have come a long way so far refining it, and only have a little bit of adjusting to make it as good as it can get with one fixed sensor in the front.

Eventually I would like to have at least one sensor in the back to it doesn't back into objects when turning around, and minimum two sensors in the front to expand its point of view and angle of view.  Is there a range finding sensor that works better than ultrasound?  I know there are other types out there, but the only one I have right now is the PING.  I would really like to add the transducers from the broken PING sensor, and get them working, but it is really starting to look like it may just be easier to buy more working sensors and use them.  I need to find a cheaper sensor option, these PING sensors are a bit too expensive to justify putting three or four of them on this toy project.
I actually started this just to learn how to accurately drive motors, and this was an easy way to do that with the parts I had available, and still have something fun to use it on, rather than just watching the motors spin on my bench with no purpose.
It helped me understand how to take a sensor reading and get a quick reaction from the sensors based on that.  I have had enough fun building this bot that I am going to leave him together rather than use it's components for something else, but I also don't want to sink a whole lot more money into it, already had to buy the RC car battery he is powered by, and a second PING sensor to replace the one I broke.

I will look around at some different sensors and see if I can't find a cheaper option and buy three or four of them.

Thank you very much for the suggestions!  I will remove that last delay and reduce the iterations.  I agree these things will make it a bit better and response time faster.

N8

Instead of using the ping() or ping_median() methods I would do multiple timer interrupt pings using the ping_timer() method with a scheduler similar to the 15 sensor example.  You don't really need an average, what you want to do is to ping as quickly as you can, in the background.  This way, there would be no delay statements, which will drastically slow things down.  The max distance also slows things down, which is why I'd suggest having only one variable for max distance and making that be something in the 200 range probably as 300cm is kind of long for the sensor to be accurate anyway.  If you don't care about anything beyond 160cm, why would you wait for 400cm?  It only makes everything take twice as long.

I would never suggest using ping() or ping_median() for a project with a bot, even worse for something that moves fast.  You should only ever use the ping_timer() method so you have no delays.  It would work a lot like the blink with no delay example Arduino sketch.  You can see the 15 sensor example for how to use the ping_timer() method.

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Ohio USA
Offline Offline
Jr. Member
**
Karma: 1
Posts: 57
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks again Tim

I just noticed you are from Ohio also, nice to see another buckeye on the forum smiley  (I am pretty close to the other end of the state from you, near Dayton)

I will looking into the Ping_timer example and try it in my code.

I took out the 30mS delay and reduced the iterations and it did seem to help.  Now he only hits chair legs (too narrow a profile to the ping to see coming) and does react faster to objects that it sees.

After looking around google for a bit, it seems ultrasound has the widest detection area, so I will likely stick with it.  Need to buy a couple more sensors and mount them up to increase the options for steering anyway.  With a couple more sensors, it would make sense to learn the 15 sensor example anyway.  I work the next two days, but have wed/thurs off, and will probably make my way to radio shack and pick up a 2nd sensor for the front. 

overall I am very happy with how the bot works, I am mostly looking to add sensors to increase the available information so it can make better decisions.  Use a left and right sensor that overlap a bit, then have the bot steer in the direction where there is more open space.  Make it drive smarter rather than simply trying to dodge objects at the last minute.

I really appreciate the suggestions, and I will update this thread when I have tried the ping_timer and added a second sensor.

I would still like to use the transducers from the broken sensor, but until I learn how to drive them, it looks like buying a new one is the easiest way to go.

Thank you!
N8
Logged

absence of proof is not proof of absence

Pages: [1]   Go Up
Jump to: