Neight:
teckel:
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