Obstacle avoidance with an UGV -HELP PLEASE-

Hi,

Just to make sure I understand what you what the sensors to do, no code thoughts here.

You are using the sensors strictly to determine how close you are to an object and ideal stay a given distance away to avoid collisions, or to stay centered in a "lane" between obstacles.

If I am correct, try mapping the sensor cones on paper. Then put obstacles in to the cones figure out what you would need to do to avoid the collision. In most cases it will be nothing, I think your approach will result in constant left / right servo movements that will result in a net nothing.

I agree with PaulS that there has to be a simpler way to code it. I think you are over thinking the collision sensors.

Start with the front, left and right, ignore the two corner sensors. Set a given distance where you think a collision is likely to occur for each group, all you initially do is check if you are over that range, if you are keep on motoring. At the point any of the groups goes under the range then deal with the problem. I would also set a dead stop range, where you know there is no way to avoid a hit easily. Get the code for the 3 sensors working then deal with the corners.

I may be telling you how to suck an egg, in which case I apologize. But when I look at it I think of driving down nasty little roads in my 4 wheel drive. If in doubt stop look and hedge to one side. Move ahead slow and easy, with small corrections,and always remember hit the mountain don't go over the cliff.

Given the gps and compass, I'd be tempted to start there, assuming that points a and b are known gps coordinates. Solve it for the simple case where there are no obstacles and simply drive along the rhumb line until you arrive. Then add obstacle avoidance algorithms.

The reason I posted here was to get help improving the algorithm!! Is it possible to use for loops to improve the algorithm? My current setup with this algorithm works well with hallways and enclosed spaces with walls. I'm going to have to buy longer ranged sensors soon, but my main provider is out of stock! And I'm not entirely sure where I will mount them.....that block of wood in the front actually adds a lot of weight and makes it hard for the car to steer if it isn't moving--maybe I'll buy a more powerful servo while I'm at it.....

And wildbill, I've tried starting there, and I've also made a post about that, but I've had no one really help me with that, and everyone is saying my GPS will not be accurate enough, and that I'll need to set up GPS differential--but I plan on saving that for the next model of the robot. Is there any way you'd be able to start me off with the basics of going from point a to b? And doesn't that require the use of interrupts? I started to use interrupts and I've not been very successful--Is it possible to have all the statements in the same main loop instead of having to use interrupts?

-Matt-

What I've been trying to suggest is that you're confusing the algorithm with the code. There are very likely more efficient ways to write the code, but the real problem is figuring out how to use the information the sensors are giving you and the code follows from that. Assuming that you were wearing a blacked out motorcycle helmet with the compass, gps and five ping sensor data on a heads up display, what would you do to navigate between your waypoints using that info?

Having said that, what scale is your course? You mention walls and enclosed spaces, so I'm guessing not very big, and likely has no gps reception, so my previous suggestion seems moot. You're down to dead reckoning now, so encoders on the wheels would be nice. Without that, how do you plan to tell where you are and where your destination is? How nasty will the obstacle course be - will you need to navigate a little maze or is it just avoiding a few small cushions strewn along the way?

Depending on the answers to the above, this could turn out to be very hard and likely require additional storage for mapping data, or reasonably easy but with no guarantee that the robot will always be able to find its way.

It isn't really a set made course, most likely going to be a local park (with trees) and another test using this algorithm specifically would be inside my high school hallways, which are about 10 feet from wall to wall. It won't be navigating through tiny obstacles, most likely large courses to get from point a to b, and there will most likely be a large gap between the two points. I'm thinking of using some rotary encoders on the wheels not to see how far the car has traveled, rather to see how fast it is going. I want to keep this as simple as I can, without spending too much. Have you ever heard of the AVC by sparkfun?

well, I probably should have looked at that before I mounted them....the readings seem to be fine though.......and Paul, sorry about that...I'm a bit lazy with commenting and stuff.....And aren't sonars a lot of money? Do they make cheap ones?

Ping sonars cost $25 or so. Rather than spend a lot on many fixed sensors, I've usually mounted
one [of each type] on a panning servo head. The reason I mentioned the measurement problem
with the Sharp IR rangers is that I once built a robot to test that device, although it only had a
single ranger, and a lot of times it tried to climb up the wall instead of turning at it. And it wasn't
my algorithm was the problem either.

The thing about robot sensors is that the people who have the most experience with them realize
they are the real Achille's Heel of robotics, and you need to use multiple redundant types for
best results. Jo Jones goes on and on about this in his book, good read,

It isn't really a set made course, most likely going to be a local park (with trees) and another test using this algorithm specifically would be inside my high school hallways

These are two very different requirements. If the ultimate goal is the park and the distances are large enough, gps and the compass can play a major part. The moment you go indoors though for testing, all that's changed. Can you test outside instead at your school? You can of course do both - use the gps if it's getting signal and revert to dead reckoning if not, but then you've made everything significantly harder.

I usually do testing outside, but given the season and the weather in New York, U.S., it's rather difficult to do that kind of testing---And I don't dare take those electronics outside unless everything is dry and the parts have been somewhat warmed up. The reason I want the longer ranged sensors as well is so I can work the code both inside and out, with accurate results. But the mainly they'll be used outside. And are there any good tutorials on how to get an arduino rc car to work the way I want it to with a GPS? I've definitely seen tens of hundreds of AGV's, but no real tutorials on how to get an AGV from point "a" to "b"

I suspect the longer-range Sharp IR rangers will do even less well than the shorter
range ones with a moving/turning robot, for the reasons mentioned = triangulation
and 50-msec sampling times with multiple samples. OTOH, sonars should do a little
better, especially if you get the ones with larger beam patterns. Check out Maxsonars.

It does all seem to be flight based that's for sure. But can you define your parameters a bit better, when you say navigate via gps do you mean move from known starting point to a known waypoint ? Or from a known start point to a waypoint that is identified by a system other than gps coordinates ?

If it is the 1st option try this link http://letsmakerobots.com/node/19554 you may have found it already but there is some useful info there.

And are there any good tutorials on how to get an arduino rc car to work the way I want it to with a GPS?

First, explain how the GPS will see any satellites when indoors? Do you have several satellites on your ceiling?

Sorry--I'm not planning on using the robot indoors, only to test the IR sensors. I wish I had that kind of money to install satellites in my ceiling :stuck_out_tongue:

But seriously, are there any tutorials for OUTDOOR use and what I explained earlier?

rgallant:
It does all seem to be flight based that's for sure. But can you define your parameters a bit better, when you say navigate via gps do you mean move from known starting point to a known waypoint ? Or from a known start point to a waypoint that is identified by a system other than gps coordinates ?

Sorry--didn't see your post!

what do you mean flight based? And navigating for starters will consist of the Arduino knowing its current position and the coordinates of the goal it want to get to. Later programming might involve other waypoints, but right now I'm sticking with going from point "a" (current position) to "b" (another, known position--but not the current position)

Also a next revision is probably going to include GPS differential, but that's a bit out of my reach currently

Sorry that was badly worded most of the examples are for some form of aircraft. But that link I added should give you a start on navigating from waypoint to waypoint.

I cannot tell you how much this is really going to help me!! The GPS library is the same one I use, but for a different GPS, and I have the same digital compass! Thanks a bunch!! But back to the obstacle avoidance---any advice/ ideas to get me going?

I have some ideas, but currently I have just started playing with ping sensors ,the mail man was good to me today.

I will play around a bit and see what I can come up, I want to build an autonomous tank so it fits in.

The big issue I see with the small servo movements, is sort of a constant left/right turn effect if the the range and time is too small.

If your current code gets you down halls pretty centered then perhaps the problem is more defining a minimum distance. So if we are with in X distance on the left side adjust to steer right a bit and move forward. You have a forward arc set up it should be possible to tweak the settings to curve away from or around obstacles. Which is what you want to accomplish in general terms.

Let me put some thought into this, I need to scrawl some stuff on paper and scan it so it makes sense. I can see in my mind what you want to do, but it is the end of a long work day and I keep coming up the gibberish.

Do a search on "robomagellan" for background material on GPS and
outdoors travel.

So the whole reason I started this project was for a program in my high school called the Authentic Science Research Program. I'm not sure if you've heard of it or not--we apply to the Intel talent search senior year. I'm currently a junior. Currently, I want to do a study on something in the robotics category, but it looks like I'm going to study obstacle avoidance. Does anyone have any ideas for a research topic for me? I need some sort of "question" that hasn't been answered or something that has never been done before. Maybe create a new obstacle avoidance method, I'm not sure---but any ideas?

For algorithms, consider using a Braitenberg "algorithm" for you avoidance mechanism. This works well as a "background" always on behaviour.

Also consider Potential fields - might work better with your multiple sonar setup:

http://www.cs.mcgill.ca/~hsafad/robotics/index.html

I've seen the potential field method before, and it seems to have its various drawbacks. Maybe improving one of these methods might make a good research topic.......also, would I have to use interrupts to make the GPS tell the car to go from point "a" to "b" and have the car avoid obstacles along the way?